Editor – Esta é a segunda parte de uma série sobre cache de alta capacidade e alta disponibilidade:
Como você pode criar um cluster de cache de alta capacidade e alta disponibilidade usando NGINX ou NGINX Plus? Esta postagem descreve como usar dois ou mais servidores de cache NGINX ou NGINX Plus para criar um cluster de cache de alta disponibilidade. (Exceto quando indicado, o método descrito aqui se aplica igualmente ao NGINX Open Source e ao NGINX Plus, mas para resumir, nos referiremos apenas ao NGINX Plus.)
A primeira parte desta série descreveu um padrão para criar clusters de cache fragmentados muito grandes.
Esse padrão é eficaz quando você precisa criar um cache de capacidade muito grande que pode ser ampliado conforme desejado. Como cada recurso é armazenado em cache apenas em um servidor, ele não é totalmente tolerante a falhas, mas o balanceamento de carga de hash consistente garante que, se um servidor falhar, apenas sua parcela do conteúdo armazenado em cache será invalidada.
Se seu objetivo principal for minimizar o número de solicitações aos seus servidores de origem a todo custo, a solução de fragmentação de cache não é a melhor opção. Em vez disso, uma solução com configuração cuidadosa de instâncias primárias e secundárias do NGINX Plus pode atender aos seus requisitos:
A instância primária do NGINX Plus recebe todo o tráfego e encaminha solicitações para a instância secundária. A instância secundária recupera o conteúdo do servidor de origem e o armazena em cache; a instância primária também armazena em cache a resposta da secundária e a retorna ao cliente.
Ambos os dispositivos têm caches totalmente preenchidos e o cache é atualizado de acordo com os tempos limite configurados.
Configure o servidor de cache primário para encaminhar todas as solicitações ao servidor secundário e armazenar em cache as respostas. Conforme indicado pelo parâmetro de backup
para a diretiva do servidor
no grupo upstream, o servidor primário encaminha solicitações diretamente para o servidor de origem no caso de falha do servidor secundário:
proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server { status_zone mycache; # para status estendido do NGINX Plus escuta 80; proxy_cache mycache; proxy_cache_valid 200 15s; location / { proxy_pass http://secondary; } } upstream secondary { zone secondary 128k; # para status estendido do NGINX Plus server 192.168.56.11; # servidor secundário 192.168.56.12 backup ; # origem }
Configure o servidor de cache secundário para encaminhar solicitações ao servidor de origem e armazenar em cache as respostas.
proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
status_zone mycache; # para status estendido do NGINX Plus
listen 80;
proxy_cache mycache;
proxy_cache_valid 200 15s;
location / {
proxy_pass http://origin;
}
}
upstream origin {
zone origin 128k; # para status estendido do NGINX Plus
server 192.168.56.12; # origin
}
Por fim, você precisa configurar alta disponibilidade (HA) para que o servidor secundário receba o tráfego de entrada se o primário falhar; o primário receba o tráfego de volta quando se recuperar posteriormente.
Neste exemplo, usamos a solução HA ativa-passiva para NGINX Plus . O endereço IP virtual anunciado externamente é 192.168.56.20, e o servidor de cache primário atua como o nó primário para HA no cluster. Se estiver usando o NGINX Open Source, você pode instalar e configurar manualmente o keepalived
ou uma solução HA diferente.
Lembre-se de que queremos criar um cluster de cache de alta disponibilidade que continue operando mesmo se um servidor de cache falhar. Não queremos que a carga no servidor de origem aumente, seja quando um servidor de cache falha ou quando ele se recupera e precisa atualizar conteúdo obsoleto.
Suponha que o primário falhe e a solução NGINX Plus HA transfira o endereço IP externo para o secundário.
O secundário tem o cache cheio e continua operando normalmente. Não há carga adicional no servidor de origem.
Quando o servidor de cache primário se recupera e começa a receber tráfego de cliente, seu cache estará desatualizado e muitas entradas terão expirado. O primário atualizará seu cache local a partir do servidor de cache secundário; como o cache no servidor secundário já está atualizado, não há aumento no tráfego para o servidor de origem.
Agora suponha que o secundário falhe . O primário detecta isso (usando uma verificação de integridade configurada como parte da solução HA) e encaminha o tráfego diretamente para o servidor de backup (que é o servidor de origem).
O servidor primário tem o cache cheio e continua operando normalmente. Mais uma vez, não há carga adicional no servidor de origem.
Quando o secundário for recuperado, seu cache estará desatualizado. No entanto, ele só receberá solicitações do primário quando o cache do primário expirar, momento em que a cópia do secundário também terá expirado. Embora o secundário precise fazer uma solicitação de conteúdo do servidor de origem, isso não aumenta a frequência de solicitações à origem. Não há efeito adverso no servidor de origem.
Para testar nossa solução de HA, configuramos o servidor de origem para registrar solicitações e retornar a hora atual de cada solicitação. Isso significa que a resposta do servidor de origem muda a cada segundo:
access_log /var/log/nginx/access.log;
location / {
return 200 "Agora é $time_localn";
}
Os servidores de cache primário e secundário já estão configurados para armazenar em cache respostas com código de status200
por 15 segundos. Isso normalmente resulta em atualizações de cache a cada 15 ou 16 segundos.
proxy_cache_válido 200 15s;
Uma vez por segundo, enviamos uma solicitação HTTP para o endereço IP virtual de alta disponibilidade do cluster de cache. A resposta não muda até que os caches nos servidores primário e secundário expirem e a resposta seja atualizada no servidor de origem. Isso acontece a cada 15 ou 16 segundos.
$ while sleep 1 ; do curl http://192.168.56.20/ ; done Agora é 9/fev/2017:06:35:03 -0800 Agora é 9/fev/2017:06:35:03 -0800 Agora é 9/fev/2017:06:35:03 -0800 Agora é 9/fev/2017:06:35:19 -0800 Agora é 9/fev/2017:06:35:19 -0800 ^C
Também podemos inspecionar os logs no servidor de origem para confirmar se ele está recebendo uma solicitação apenas a cada 15 ou 16 segundos.
Podemos verificar se o failover está funcionando corretamente parando o servidor primário ou secundário, por exemplo, parando os processos nginx
. O teste de carga constante continua em execução e a resposta é armazenada em cache de forma consistente.
A inspeção do log de acesso no servidor de origem confirma que ele só recebe uma solicitação a cada 15 a 16 segundos, não importa qual dos servidores de cache falhe ou se recupere.
Em uma situação estável, o conteúdo em cache é normalmente atualizado a cada 15 a 16 segundos. O conteúdo expira após 15 segundos e há um atraso de até 1 segundo antes que a próxima solicitação seja recebida, causando uma atualização do cache.
Ocasionalmente, o cache parecerá atualizar mais lentamente (até 30 segundos entre alterações no conteúdo). Isso ocorre se o conteúdo do servidor de cache primário expirar e o primário recuperar conteúdo em cache que está quase expirado do secundário. Se isso representar um problema, você pode configurar um tempo limite de cache mais curto no servidor secundário.
A hierarquização de caches entre dois ou mais servidores de cache NGINX da maneira que descrevemos aqui é uma maneira eficaz de criar um cluster de cache altamente disponível que minimiza a carga nos servidores de origem, protegendo-os de picos de tráfego quando um dos servidores de cache falha ou se recupera.
A capacidade total do cache é limitada à capacidade de um único servidor de cache. A primeira parte desta série descreve um padrão alternativo de cache fragmentado que particiona um cache em um cluster de servidores de cache. Nesse caso, a capacidade total é a soma de todos os servidores de cache, mas o conteúdo não é replicado para proteger contra picos de tráfego para o servidor de origem se um servidor de cache falhar.
Experimente o cache de alta disponibilidade em seus próprios servidores – comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."