🥇Construindo e configurando seu CDN

Redes de distribuição de conteúdo (CDNs) são usadas em sites e aplicativos principalmente para acelerar o carregamento de elementos estáticos. Isso acontece devido ao cache de arquivos em servidores CDN localizados em diferentes regiões geográficas. Ao solicitar dados via CDN, o usuário os recebe do servidor mais próximo.

O princípio de operação e funcionalidade de todas as redes de distribuição de conteúdo é aproximadamente o mesmo. Tendo recebido uma solicitação para baixar um arquivo, o servidor CDN o pega uma única vez do servidor original e o entrega ao usuário, ao mesmo tempo que o armazena em cache por um período de tempo especificado. Todas as solicitações subsequentes são respondidas pelo cache. Todos os CDNs têm opções para pré-carregar arquivos, limpar o cache, definir a data de expiração e muito mais.

Acontece que, por um motivo ou outro, você precisa organizar sua própria rede de distribuição de conteúdo, e então - deixar que as instruções de montagem da próxima bicicleta nos ajudem.

Fonte: Vetor infográfico criado por pikisuperstar - www.freepik.com

Quando você precisa do seu próprio CDN

Considere os casos em que faz sentido executar seu próprio CDN:

quando há um desejo de economizar dinheiro e custos operacionais mesmo ao usar CDNs baratos como Coelho CDN equivale a várias centenas de dólares por mês
se quisermos obter um cache permanente ou um cache sem vizinhos de servidor e canal
Os serviços CDN não possuem pontos de presença na região que você precisa
quaisquer configurações especiais de entrega de conteúdo necessárias
queremos acelerar a entrega de conteúdo dinâmico, colocando o servidor de produção mais próximo dos usuários
existe a preocupação de que um serviço CDN de terceiros possa coletar ou usar ilegalmente informações sobre o comportamento do usuário (olá, serviços não compatíveis com GDPR) ou se envolver em outras atividades ilegais

Na maioria dos outros casos, é mais apropriado usar soluções prontas existentes.

O que você precisa para começar

É maravilhoso se você tiver seu próprio Sistema Autônomo (AS). Com ele você pode atribuir o mesmo IP a vários servidores e de acordo com esta instrução no nível da rede, direcione os usuários para a rede mais próxima. Vale dizer que mesmo com o bloco de endereços /24 é possível construir uma rede de distribuição de conteúdo. Alguns provedores de servidores permitem que você faça um anúncio para uso em todas as regiões disponíveis para eles.

Se você não for o feliz proprietário de um bloco de endereços IP, para executar um CDN simples, você precisará de:

nome de domínio ou subdomínio
pelo menos dois servidores em regiões diferentes. O servidor pode ser dedicado ou virtual
ferramenta geoDNS. Com a sua ajuda, o usuário, tendo endereçado o domínio, será direcionado para o servidor mais próximo

Registre um domínio e solicite servidores

Com o registro de domínio, tudo é simples - registramos em qualquer zona com qualquer registrador. Você também pode usar um subdomínio para uma CDN, por exemplo, algo como cdn.nomedodomínio.com. Na verdade, em nosso exemplo, faremos exatamente isso.

Quanto ao pedido de servidores, eles devem ser alugados nas regiões e países onde está localizado o seu público de usuários. Se o projeto for intercontinental, é conveniente escolher provedores de hospedagem que ofereçam servidores em todo o mundo ao mesmo tempo. Exemplos: OVH, alugar web и 100Tb - para servidores dedicados, Vultr и DigitalOcean — para nuvem virtual*.

Para nosso CDN privado, encomendaremos 3 servidores virtuais em continentes diferentes. No Vultr no servidor para US$ 5/mês nós conseguiremos 25GB SSD lugares e 1 TB de tráfego. Ao instalar, selecione o Debian mais recente. Nossos servidores:

Frankfurt, IP: 199.247.18.199

Chicago, IP: 149.28.121.123

Cingapura, IP: 157.230.240.216

* Vultr e DigitalOcean prometem crédito de US$ 100 aos usuários que se cadastrarem por meio dos links do artigo imediatamente após adicionar uma forma de pagamento. O autor também recebe um pequeno elogio com isso, que é muito significativo para ele agora. Por favor, seja compreensivo.

Configurando geoDNS

Para que o usuário seja direcionado ao servidor desejado (mais próximo) ao acessar um domínio ou subdomínio CDN, precisamos de um servidor DNS com a função geoDNS.

O princípio e operação do geoDNS é o seguinte:

Especifica o IP do cliente que enviou a solicitação DNS ou o IP do servidor DNS recursivo usado ao processar a solicitação do cliente. Esses servidores recursivos geralmente são DNS de provedores.
O IP do cliente reconhece seu país ou região. Para isso, são utilizadas bases de dados GeoIP, que hoje são muitas. Existem bons opções gratuitas.
Dependendo da localização do cliente, fornece-lhe o endereço IP do servidor CDN mais próximo.

Servidor DNS com função geoDNS pode ser monte você mesmo, mas é melhor usar soluções prontas com uma rede de servidores DNS em todo o mundo e Anycast da Caixa:

CloudDNS de US$ 9.95/mês, Tarifa GeoDNS, por padrão há um DNS Failover
Zilore de US$ 25/mês, Failover de DNS ativado
Amazon Route 53 de US$ 35/mês para uma rede de 50 milhões de solicitações geográficas. O failover de DNS é cobrado separadamente
DNS facilitado de US$ 125/mês, existem 10 failovers de DNS
Cloudflare, o recurso "Geo Steering" está disponível nos planos Enterprise

Ao encomendar geoDNS, deve prestar atenção ao número de pedidos incluídos no tarifário e ter em atenção que o número real de pedidos ao domínio pode exceder em várias vezes as expectativas. Milhões de aranhas, scanners, spammers e outros espíritos malignos trabalham incansavelmente.

Quase todos os serviços DNS incluem um serviço indispensável para a construção de um CDN - DNS Failover. Com sua ajuda, você pode configurar o monitoramento do funcionamento de seus servidores e, na ausência de sinais de vida, substituir automaticamente o endereço de um servidor que não funciona por um de backup nas respostas DNS.

Para construir nosso CDN, usaremos CloudDNS, Tarifa GeoDNS.

Vamos adicionar uma nova zona DNS na sua conta pessoal, especificando o seu domínio. Se estivermos construindo um CDN em um subdomínio e o domínio principal já estiver em uso, imediatamente após adicionar a zona, não se esqueça de adicionar os registros DNS em funcionamento existentes. A próxima etapa é criar vários registros A para o domínio/subdomínio CDN, cada um dos quais será aplicado à região que especificamos. Você pode especificar continentes ou países como regiões; sub-regiões estão disponíveis para os EUA e Canadá.

No nosso caso, o CDN será gerado em um subdomínio cdn.sayt.in. Adicionando uma zona diga.in, crie o primeiro registro A para o subdomínio e aponte toda a América do Norte para o servidor em Chicago:

Vamos repetir a ação para outras regiões, lembrando de criar uma entrada para as regiões padrão. Aqui está o que acontece no final:

A última entrada padrão na captura de tela significa que todas as regiões não especificadas (e estas são Europa, África, usuários de Internet via satélite, etc.) serão enviadas para o servidor em Frankfurt.

Isso conclui a configuração básica do DNS. Resta acessar o site do registrador de domínios e substituir os NSs de domínio atuais pelos emitidos pelo ClouDNS. E enquanto os NSs serão atualizados, prepararemos os servidores.

Instalação de certificados SSL

Nosso CDN funcionará em HTTPS, portanto, se você já possui certificados SSL para um domínio ou subdomínio, carregue-os em todos os servidores, por exemplo, no diretório /etc/ssl/seudominio/

Se não houver certificados, você pode obter um gratuitamente em Let's Encrypt. Perfeito para isso Shellscript ACME. O cliente é conveniente e fácil de configurar e, o mais importante, permite validar um domínio/subdomínio por DNS através da API ClouDNS.

Instalaremos acme.sh em apenas um dos servidores - Europeu 199.247.18.199, de onde serão copiados os certificados para todos os demais. Para instalar, execute:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Durante a instalação do script, será criado um trabalho CRON para posterior renovação de certificados sem a nossa participação.

Ao emitir um certificado, o domínio será verificado usando DNS usando a API, portanto, na conta pessoal ClouDNS no menu Reseller API, você precisa criar um novo usuário API e definir uma senha para ele. O ID de autenticação resultante com uma senha será escrito no arquivo ~/.acme.sh/dnsapi/dns_cloudns.sh (não deve ser confundido com arquivo dns_clouddns.sh). Aqui estão as linhas que precisam ser descomentadas e editadas:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

Agora vamos solicitar um certificado SSL para cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

Nas opções, para o futuro, especificamos um comando para recarregar automaticamente a configuração do servidor web após cada renovação do período de validade do certificado no futuro.

Todo o processo de obtenção do certificado pode demorar até 2 minutos, não o interrompa. Se ocorrer um erro de validação de domínio, tente executar o comando novamente. No final veremos onde os certificados foram carregados:

Lembre-se desses caminhos, eles precisarão ser especificados ao copiar o certificado para outros servidores, bem como nas configurações do servidor web. Não prestamos atenção ao erro de recarregar as configurações do Nginx - ele não estará em um servidor totalmente configurado ao atualizar os certificados.

Tudo o que resta para o SSL é copiar o certificado recebido para outros dois servidores, mantendo o caminho dos arquivos. Vamos criar os mesmos diretórios em cada um deles e fazer uma cópia:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Para atualizar certificados regularmente, crie um trabalho CRON diário em ambos os servidores com o comando:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Neste caso, o acesso ao servidor de origem remoto deve ser configurado por chave, ou seja sem inserir uma senha. Não se esqueça de fazer isso.

Instalando e configurando o Nginx

Para servir conteúdo estático, usaremos o Nginx configurado como um servidor proxy de cache. Atualize as listas de pacotes e instale-os em todos os três servidores:

root@cdn:~# apt update
root@cdn:~# apt install nginx

Em vez do padrão, usamos a configuração do spoiler abaixo:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

Edite na configuração:

tamanho máximo — o tamanho do cache, não excedendo o espaço disponível em disco
inativo - tempo de armazenamento de dados em cache que ninguém acessou
ssl_certificate и ssl_certificate_key — caminhos para certificado SSL e arquivos de chave
proxy_cache_valid - tempo de armazenamento de dados em cache
proxy_pass — endereço do servidor original do qual o CDN solicitará arquivos para armazenamento em cache. Em nosso exemplo, isso diga.in

Como você pode ver, tudo é simples. A dificuldade só pode surgir na definição do tempo de cache devido à semelhança das diretivas inativo и proxy_cache_valid. Vamos analisá-los com nosso exemplo. Aqui está o que acontece quando inativo=7d и proxy_cache_válido 90d:

se a solicitação não for repetida em 7 dias, os dados serão excluídos do cache após esse período
se a solicitação for repetida pelo menos uma vez a cada 7 dias, os dados no cache serão considerados obsoletos após 90 dias e o Nginx os atualizará na próxima solicitação, retirando-os do servidor original

Concluída a edição nginx.conf, recarregue a configuração:

root@cdn:~# service nginx reload

Nosso CDN está pronto. Por $ 15 / mês. recebemos pontos de presença em três continentes e 3 TB de tráfego: 1 TB em cada localidade.

Verificando o trabalho do CDN

Vejamos os pings para nosso CDN de diferentes localizações geográficas. Qualquer serviço de ping funcionará para isso.

Ponto de lançamento
Host
IP
Tempo médio, ms

Alemanha Berlim
cdn.sayt.in
199.247.18.199
9.6

Holanda, Amsterdã
cdn.sayt.in
199.247.18.199
10.1

França Paris
cdn.sayt.in
199.247.18.199
16.3

Grã-Bretanha, Londres
cdn.sayt.in
199.247.18.199
14.9

Canadá, Toronto
cdn.sayt.in
149.28.121.123
16.2

EUA, São Francisco
cdn.sayt.in
149.28.121.123
52.7

EUA, Dallas
cdn.sayt.in
149.28.121.123
23.1

EUA, Chicago
cdn.sayt.in
149.28.121.123
2.6

EUA, Nova York
cdn.sayt.in
149.28.121.123
19.8

Cingapura
cdn.sayt.in
157.230.240.216
1.7

Japão Tóquio
cdn.sayt.in
157.230.240.216
74.8

Austrália, Sidney
cdn.sayt.in
157.230.240.216
95.9

Os resultados são bons. Agora colocaremos uma imagem de teste na raiz do site principal test.jpg e verifique sua velocidade de download via CDN. É dito - feito. O conteúdo é entregue rapidamente.

Vamos escrever um pequeno script caso queiramos limpar o cache no ponto CDN.
purgar.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

Para excluir todo o cache, basta executá-lo, um arquivo separado pode ser limpo assim:

root@cdn:~# ./purge.sh /test.jpg

Em vez de conclusões

Por fim, quero dar algumas dicas úteis para passar imediatamente por cima do ancinho que fez minha cabeça doer naquele momento:

Para aumentar a tolerância a falhas do CDN, é recomendável configurar o DNS Failover, que ajuda a alterar rapidamente o registro A em caso de falha do servidor. Isso é feito nos registros DNS do painel de controle do domínio.
Sites com ampla cobertura geográfica sem dúvida exigem um grande número de CDNs, mas não sejamos fanáticos. Muito provavelmente o usuário não notará uma diferença significativa em comparação com um CDN pago se você colocar servidores em 6 a 7 locais: Europa, América do Norte (leste), América do Norte (oeste), Cingapura, Austrália, Hong Kong ou Japão
Às vezes, os hosters não permitem o uso de servidores alugados para fins de CDN. Portanto, se você decidir repentinamente implantar uma rede de distribuição de conteúdo como um serviço, não se esqueça de ler as regras de um determinado provedor de hospedagem com antecedência.
Estudo mapa de comunicações subaquáticasrepresentar como os continentes estão conectados e levar isso em consideração ao construir uma rede de distribuição de conteúdo
Tente verificar pings de lugares diferentes para seus servidores. Assim você consegue ver as regiões mais próximas dos pontos CDN e configurar o GeoDNS de forma mais correta
Dependendo das tarefas, será útil ajustar o Nginx para requisitos específicos de cache e levar em consideração a carga do servidor. Os artigos sobre cache Nginx me ajudaram muito nisso - aqui e aceleração do trabalho sob cargas pesadas: aqui и aqui

Fonte: habr.com