Para que devemos construir uma CDN?

Oi Habr! Neste artigo, criaremos nosso próprio CDN. Por que não usar soluções prontas? Como o site do autor é totalmente estático, criado em Jekyll, com fotos grandes que precisam ser exibidas o mais rápido possível. O servidor não deve estar armazenando em cache, ele deve armazenar o site inteiro, suportar HTTP / 2 e Brotli e o mesmo certificado deve ser instalado em todos os servidores.

Também faremos tudo isso no IIS em execução no Windows Server 2019 Core.

Brevemente sobre a implementação

Nos nós finais, gerenciaremos os meios embutidos no sistema operacional, precisaremos de:

1. Diretório ativo
2. Dfs
3. IIS
4. Winacme
5. RSAT

Opcional, mas recomendado:

1. Centro de administração do Windows

Em sites com sites, apenas o IIS e o DFS são necessários, o Active Directory é necessário, o DFS, que sincronizará o conteúdo do site entre servidores. O RSAT é necessário para gerenciar componentes e o Windows Admin Center é necessário para editar o registro. Isso também pode ser feito através do Powershell, que também discutirei.

O domínio do autor é chamado ***. ***. Wtf (por favor, não se assuste), e os servidores têm o nome de data centers e têm nomes no formato cache-zur1, cahe-ru e assim por diante. O AD é implantado e os servidores estão conectados a ele. Agora em ordem.

Seleção de ponto

O RUVDS possui 8 data centers - 3 na Europa e 5 na Rússia. Minha escolha recaiu sobre Rucloud em Moscou e LD8 (a de Londres). Rucloud porque quase não é diferente do M9, e através de Londres há um cabo transcontinental para os EUA, então na Europa é um must have. Para uma distribuição mais restrita na Europa, você pode escolher a Suíça ou a Alemanha - isso, em geral, pode parar.

Escolhendo um DNS GeoIP

Se o cliente estiver batendo no site, como entender qual servidor deve transmitir os dados para ele? Usando DNS, é claro. Ou seja, dependendo do endereço IP de quem dirigiu o DNS, uma resposta relevante será dada.

Podemos usar nosso próprio DNS (BIND com um plug-in para Maxmind) ou uma solução pronta para uso (Route53). Uma assinatura dos bancos de dados Maxmind GeoIP custa US $ 25 por mês, e o Route53 custa US $ 0,50 por zona de domínio, mais um centavo se você atender a um milhão de solicitações. Além disso, criar outro ponto de fortalecimento dos ataques DDoS é a última coisa, então minha escolha caiu no Route53.

Este artigo é sobre CDN for Europe; se você precisar de um CDN para a Rússia, a escolha do seu próprio DNS é óbvia, porque o Route53 fornece roteamento por país, não por cidade.
A Microsoft possui serviços semelhantes (Gerenciador de Tráfego do Azure).

1. Instale o IIS

1.1 Instalação do IIS

Instalamos os componentes básicos do IIS, o componente de suporte para certificados centralizados e no servidor principal suporte adicional para gerenciamento remoto. Esse componente é necessário apenas para um servidor - você não poderá gerenciar outros servidores quando ativar configurações compartilhadas, mesmo que o gerenciamento remoto tenha sido configurado.



Via Powershell:

Install-WindowsFeature Web-Server, Web-CertProvider 

No servidor principal, você deve instalar adicionalmente:

 Install-WindowsFeature Web-Mgmt-Service 

1.1.1 Ligar o controle remoto

Para que possamos gerenciar remotamente o servidor IIS, precisamos aumentar o Serviço de Gerenciamento Remoto do IIS. No servidor principal, inicie o serviço:

 start-service WMSVC set-service -Name WMSVC -StartupType Automatic 

E agora incluímos a capacidade de gerenciar como tal através do registro.

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server 

A maneira mais fácil de gerenciar o registro, é claro, é através do Centro de Administração do Windows.



Mas isso também pode ser feito através do Powershell:

 Set-Itemproperty -path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server" -Name "EnableRemoteManagement" -value "1" 

No Windows Server 2012 e 2016, a regra do firewall não aumenta por si só; você precisa editar o firewall.

 Set-NetFirewallRule -Name IIS-WebServerRole-WMSVC-In-TCP -Enabled True 

Verifique se aumentou:

 Test-NetConnection 8.8.8.8 -port 8172 

Três edições em três locais diferentes e agora podemos nos conectar através do gerenciador do IIS ao nosso servidor usando outro servidor com uma área de trabalho. Isso foi apenas para a conveniência do gerenciamento subsequente.

1.2 Cortamos a centralização das configurações

Não há botões para instalar configurações e certificados centralizados no Gerenciador do IIS, eles estão apenas no gerenciador de servidor local; portanto, no Server Core, você precisará fazer tudo através do Powershell.

A centralização de configurações e certificados é realizada através do SMB. Portanto, criei dois usuários sem privilégios (separadamente para configurações e certificados) que têm acesso de leitura apenas à sua pasta e os nomeei de certadmin e configadmin.

É recomendável que os usuários sejam locais no servidor principal - se o seu controlador de domínio morrer, os aplicativos que se apegam à configuração e aos certificados via SMB em nome do usuário do domínio morrerão. O uso de usuários locais elimina essa situação.

1.2.1 Criando uma pasta compartilhada

Duas pastas públicas devem ser armazenadas em um dos servidores, de onde obtemos a configuração e os certificados. Como o caminho para a pasta compartilhada, seguimos o caminho padrão para as configurações do IIS:

 New-SmbShare -ReadAccess configadmin@**.**wtf -Path C:\windows\System32\Inetsrv\Config -Name sharedconfigs 

E para certificados, podemos escolher qualquer. Coloquei-os em uma pasta com o IIS.

 New-SmbShare -Path C:\inetpub\centralizedcerts -Name sharedconfigs -ReadAccess configadmin 

1.2.2 Nós conectamos nós às configurações

As configurações precisam ser feitas apenas para os servidores que lerão essa configuração. Meu servidor principal sob o nome cache-ru será o chefe, então eu configurei nos outros dois.
Digite a senha do usuário que tem acesso à pasta:

 $pass = Read-Host -AsSecureString Enable-IISSharedConfig -PhysicalPath \\cache-ru.**.**wtf\SharedConfig -UserName configadmin@**.**wtf -Password $pass -DontCopyRemoteKeys 

Imediatamente após entrar em uma nova sessão deve abrir. Para verificar se tudo funcionou, você pode abrir RSAT → Gerenciamento do computador → Pastas compartilhadas → Sessões. Veremos as sessões do usuário e o endereço IP do servidor, que neste usuário lê a pasta compartilhada. No lado do cliente, ele é verificado pelo cmdlet:

 Get-IISSharedConfig 

É assim que me parecia:



1.2.2 Conectar nós aos certificados

A próxima linha só pode ser inserida diretamente, tendo uma conexão direta com a área de trabalho executando o servidor com uma GUI; ela não funciona no Server Core.

 $pass = Read-Host -AsSecureString Enable-IISCentralCertProvider -CertStoreLocation \\cache-ru.**.**wtf\centralizedcerts -UserName certadmin@**.**wtf -Password $pass 

Se você tentar inseri-lo através do Winrm, verá a seguinte saída:



Para fazer isso remotamente, você precisa editar o registro. Quão conveniente! Voamos em:

 HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ 

Crie um DWORD de 32 bits "Ativado" com o parâmetro "1":

 Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name Enabled -Value 1 

Em seguida, criamos o valor da sequência CertStoreLocation com o parâmetro \\ cache-ru. **. ** wtf \ centralizedcerts:

 Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name CertStoreLocation -Value <a href="about:blank">\\cache-ru.**.**wtf\centralizedcerts</a> 

Para verificar se tudo está em ordem, usamos:

 Get-IISCentralCertProvider 

A saída deve ser assim:



E somente depois disso entramos:

 $pass = Read-Host -AsSecureString Set-IISCentralCertProvider -UserName certadmin@**.**wtf -Password $pass 

Verifique novamente:

 Get-IISCentralCertProvider 

Tudo pronto para o uso é chamado. Diferentemente das configurações comuns, os certificados centralizados não criam uma sessão SMB ativa.

1.2.3 Brotli

Em cada servidor, baixe e execute o arquivo de compactação do IIS

 Start-Process .\iiscompression_amd64.msi -ArgumentList /quiet 

Já compartilhamos as configurações, portanto, você precisa configurar algo em apenas um lugar. Usando o Gerenciador do IIS, vamos ao editor de configuração no servidor principal.

 system.webServer/httpCompression 

E defina StaticCompressionLevel como 11 para Brotli e 9 para Gzip, este é o máximo que eles podem fazer.

1.2.4 MIME e cabeçalhos

Fora da caixa, o IIS não transmite o cabeçalho de codificação, e é por isso que o alfabeto cirílico se transforma em runas. Também no MIME, não há nenhuma entrada no formato webp que precise ser adicionada.

1. Vá para o expedidor → MIME. Encontre .HTML e modifique seu tipo para: text / html; charset = utf-8



2. Não se esqueça do Webp - você precisa adicionar este MIME manualmente.

2. Emitimos um certificado

Usando o Winacme . Primeiro, você precisa vincular os domínios ao site - isso pode ser feito através do Gerenciador do IIS. Ao criar uma CDN, não selecione a verificação do host, pois Os problemas começam imediatamente com a confirmação da propriedade do domínio. Nossa escolha é a verificação por registro TXT. Você precisará direcionar manualmente o caminho para a pasta com os certificados, além de copiar manualmente o registro do desafio. Agora, coloque ar no seu peito.

Para não imprimir tudo manualmente, ative o RDP no Server Core com o seguinte comando:

 cscript C:\Windows\System32\Scregedit.wsf /ar 0 

É assim que o RDP se parece no Server Core:



Após o desafio, os certificados caem na pasta especificada no Winacme. Winacme coloca a tarefa no agendador para renovar o certificado. Instalado e esqueci.



Bem, quando terminamos, podemos desativar o RDP - instalamos o Server Core por um bom motivo, descobrimos muitas nuances.

 cscript C:\Windows\System32\Scregedit.wsf /ar 1 

3. Certificado Bindim para Nós

Agora você precisa configurar dois outros nós para que o HTTPS finalmente funcione. No momento, no servidor em que os certificados estão armazenados, o HTTPS já está em execução. Para que o restante comece a trabalhar em HTTPS, bem, em geral, isso é feito através do netsh.

Como estamos acostumados, nos conectamos ao Windows Server Core via RDP para executar esse snap-in. Não consulte o site da Microsoft, especialmente neste guia. As etapas nele estão descritas incorretamente.

Usando netsh http show sslcert, no nó principal você precisa obter o appid, que inserimos como descrito abaixo:

 netsh http add sslcert ccs=443 appid= '{4dc3e181-e14b-4a21-b022-59fc669b0914}' 

O valor do appid deve estar entre aspas, caso contrário, não funcionará.

4. Instale o DFS

Não sincronize certificados e configurações por meio do DFS; as ferramentas especializadas foram inventadas por um motivo. Tentei e, por algum motivo pouco claro, as configurações nos servidores que fizeram a configuração pararam de ler as alterações, embora pela primeira vez tudo funcionasse. Não descobri a causa do fracasso e decidi fazê-lo de maneira diferente.

A configuração adicional é feita exclusivamente por meio do RSAT, os cmdlets especificados na documentação funcionam apenas no Windows Server com uma GUI. A implantação da replicação DFS usando o Server Core exclusivamente não é possível. Você precisa de outro servidor com uma GUI ou de um computador executando o Windows 10 Pro com o RSAT instalado, associado ao domínio.

2.1 Instale

Em cada servidor, você precisa instalar a Replicação DFS:

 Install-WindowsFeature FS-DFS-Replication, FS-DFS-Namespace 

2.2 Criando um novo grupo de replicação



Primeiro você precisa ligar para o nosso grupo de replicação.



Escolha a topologia ao seu gosto. Pessoalmente, será mais conveniente adicionar conteúdo a um local, por isso escolho uma estrela.





Um dos servidores deve ser o principal, é a partir dele que a replicação começa. Se você enviar arquivos para ouvintes, o arquivo enviado não será replicado.



Como pasta para replicação, escolhi a pasta padrão com sites:

 C:\inetpub\wwwroot 

Esta pasta é o caminho para o diretório deste primeiro servidor específico. Você pode replicar o conteúdo desta pasta em qualquer lugar, independentemente do caminho.



Dentro de um grupo, podemos replicar várias pastas e, no futuro, podemos expandir sua lista, se necessário.



Terminado.

5. Teste de desempenho

Para entender quanto os visitantes do site realmente ganharam, é necessário fazer medições. Eles serão realizados a partir de dois pontos. PC do autor em Moscou e servidor virtual em Frankfurt. Todos os três pontos serão testados separadamente. Aqui está um resumo.



Entramos no Devtools e observamos a cachoeira. Em média, em um hospital, uma CDN reduzirá cerca de 200 milissegundos antes que um site seja totalmente carregado. A imagem, o maior objeto da página, é carregada assim que entra na janela de visualização; portanto, preste atenção na linha vertical azul. A CDN acelerou os estilos e scripts HTML + puros em 10 a 15 milissegundos e a imagem carregou 220 milissegundos mais rapidamente, essa é uma diferença muito significativa.




Também medi a velocidade de Jekyll em um host local:



Nos voltamos para o farol e vemos resultados estranhos:





Nesse sintético, um servidor em terras distantes ignora o host local. Mas porque?
Por diversão, vamos nos livrar do Google Fonts e transferi-los para nossos servidores.





Resultados entre data centers alinhados. Mas ainda não explica nada. Eu refiz os testes várias vezes, os resultados são absolutamente de ferro e reproduzíveis a qualquer momento.

Agora vamos usar um VPS com dois núcleos e 4 gigabytes de RAM localizado em Frankfurt e ver o que diz. Cachoeiras:




Aqui, com o ponto certo, a economia de tempo apenas em estilos e HTML chegou a 200 milissegundos. Ou seja, no caso de um cliente de Frankfurt, o site simplesmente será mais rápido em 200 milissegundos. Isso também se reflete na casa da luz. Nesses casos, a CDN acelerará não apenas a loja online, mas também um blog fácil.




Agora ative o Google Fonts e olhe novamente para o farol.




Infelizmente, não tenho mais pontos para realizar testes, então vou terminar.

Conclusões

• É necessário um CDN para gerar todas as estatísticas, especialmente quando se trata de imagens pesadas ou scripts longos.
• O uso do Google Fonts é possível e necessário. Em cenários pesados, ele realmente acelera o site.
• O servidor principal, se você decidir fazer tudo isso no Windows, é aconselhável ter uma GUI.
• Os usuários que farão as configurações do servidor principal são melhor localizados - no caso de uma falha no controlador de domínio, os nós podem perder a conexão com as configurações e os certificados e o Pool de Aplicativos será interrompido porque não será capaz de ler uma configuração.