Caches compartilhados com clusters de cache do NGINX Plus, parte 2

Owen GarrettDiretor Sênior de Gestão de Produtos

Editor – Esta é a segunda parte de uma série sobre cache de alta capacidade e alta disponibilidade:

• Caches compartilhados com clusters de cache do NGINX Plus, parte 1
• Caches compartilhados com clusters de cache do NGINX Plus, parte 2 (este post)

Como criar um cluster de cache de alta capacidade e alta disponibilidade usando o NGINX ou o NGINX Plus? Este post descreve como usar dois ou mais servidores de cache NGINX ou NGINX Plus para criar um cluster de cache de alta disponibilidade. (Salvo indicação em contrário, o método descrito aqui se aplica igualmente ao NGINX Open Source e ao NGINX Plus, mas, para simplificar, faremos referência apenas ao NGINX Plus.)

Revisão – A solução de cache fragmentado

A primeira parte desta série descreveu um padrão para a criação de clusters de cache fragmentados e de grande escala.

Esse padrão é eficaz quando você precisa criar um cache de capacidade muito grande que possa ser ampliado conforme necessário. Como cada recurso é armazenado em cache em apenas um servidor, ele não é totalmente tolerante a falhas, mas o balanceamento de carga com hash consistente garante que, se um servidor falhar, apenas a parte do conteúdo em cache correspondente a ele seja invalidada.

Como criar um cluster de cache de alta disponibilidade

Se o seu principal objetivo for minimizar a qualquer custo o número de solicitações aos servidores de origem, a solução de particionamento de cache não será a melhor opção. Em vez disso, uma solução com uma configuração cuidadosa das 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 as 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 instância 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.

Configurando o servidor de cache primário

Configure o servidor de cache primário para encaminhar todas as solicitações ao servidor secundário e armazenar as respostas em cache. Conforme indicado pelo parâmetro backup da diretiva server no grupo upstream, o servidor primário encaminha as solicitações diretamente ao servidor de origem caso o servidor secundário falhe:

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
    status_zone mycache;          # for NGINX Plus extended status

    listen 80;

    proxy_cache mycache;
    proxy_cache_valid 200 15s;

    location / {
        proxy_pass http://secondary;
    }
}

upstream secondary {
    zone secondary 128k;          # for NGINX Plus extended status

    server 192.168.56.11;         # secondary
    server 192.168.56.12 backup;  # origin
}

Configurando o servidor de cache secundário

Configure o servidor de cache secundário para encaminhar as solicitações ao servidor de origem e armazenar as respostas em cache.

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
    status_zone mycache;          # for NGINX Plus extended status

    listen 80;

    proxy_cache mycache;
    proxy_cache_valid 200 15s;

    location / {
        proxy_pass http://origin;
    }
}

upstream origin {
    zone origin 128k;            # for NGINX Plus extended status

    server 192.168.56.12;        # origin
}

Configurando a alta disponibilidade

Por fim, você precisa configurar a alta disponibilidade (HA) para que o servidor secundário assuma o tráfego de entrada caso o servidor primário falhe; quando o servidor primário se recuperar, ele voltará a assumir o tráfego.

Neste exemplo, usamos a solução de alta disponibilidade ativa-passiva para o 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 de alta disponibilidade no cluster. Se você estiver usando o NGINX Open Source, poderá instalar e configurar manualmente o keepalived ou outra solução de alta disponibilidade.

Cenários de failover

Lembre-se de que queremos criar um cluster de cache de alta disponibilidade que continue operando mesmo em caso de falha de um servidor de cache. Não queremos que a carga no servidor de origem aumente, seja quando um servidor de cache falhar, seja quando ele se recuperar e precisar atualizar conteúdo desatualizado.

Suponha que o servidor primário falhe e a solução de alta disponibilidade do NGINX Plus transfira o endereço IP externo para o servidor secundário.

O servidor secundário tem um cache completo e continua operando normalmente. Não há carga adicional no servidor de origem.

Quando o servidor de cache primário se recuperar e começar a receber tráfego dos clientes, seu cache estará desatualizado e muitas entradas terão expirado. O servidor primário atualizará seu cache local a partir do servidor de cache secundário; como o cache do servidor secundário já está atualizado, não haverá aumento no tráfego para o servidor de origem.

Agora, suponha que o servidor secundário falhe. O servidor primário detecta essa falha (usando uma verificação de integridade configurada como parte da solução de alta disponibilidade) e encaminha o tráfego diretamente para o servidor de backup (que é o servidor de origem).

O servidor primário tem um cache completo e continua operando normalmente. Novamente, não há carga adicional no servidor de origem.

Quando o servidor secundário se recuperar, seu cache estará desatualizado. No entanto, ele só receberá solicitações do servidor primário quando o cache deste expirar, momento em que a cópia do servidor secundário também terá expirado. Embora o servidor secundário precise solicitar conteúdo ao servidor de origem, isso não aumenta a frequência das solicitações ao servidor de origem. Não há nenhum efeito adverso sobre o servidor de origem.

Testando o comportamento de failover

Para testar nossa solução de alta disponibilidade, configuramos o servidor de origem para registrar as solicitações e retornar a hora atual para 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 "It's now $time_localn";
}

Os servidores de cache primário e secundário já estão configurados para armazenar em cache respostas com o código de status 200 por 15 segundos. Isso normalmente resulta em atualizações do cache a cada 15 ou 16 segundos.

proxy_cache_valid 200 15s;

Verificando o comportamento do cache

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 a partir do servidor de origem. Isso acontece a cada 15 ou 16 segundos.

$ while sleep 1 ; do curl http://192.168.56.20/ ; done
It's now 9/Feb/2017:06:35:03 -0800
It's now 9/Feb/2017:06:35:03 -0800
It's now 9/Feb/2017:06:35:03 -0800
It's now 9/Feb/2017:06:35:19 -0800
It's now 9/Feb/2017:06:35:19 -0800
^C

Também podemos inspecionar os logs no servidor de origem para confirmar que ele está recebendo uma solicitação apenas a cada 15 ou 16 segundos.

Verificando o failover

Podemos verificar se o failover está funcionando corretamente interrompendo o servidor primário ou o secundário, por exemplo, encerrando os processos do nginx. O teste de carga constante continua em execução, e a resposta permanece armazenada em cache de forma consistente.

A inspeção do log de acesso no servidor de origem confirma que ele recebe apenas uma solicitação a cada 15 a 16 segundos, independentemente de qual dos servidores de cache falhe ou se recupere.

Periodicidade das atualizações do cache

Em uma situação estável, o conteúdo armazenado 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 até que a próxima solicitação seja recebida, acionando uma atualização do cache.

Ocasionalmente, o cache pode parecer ser atualizado mais lentamente (com intervalos de até 30 segundos entre as alterações no conteúdo). Isso ocorre quando o conteúdo do servidor de cache primário expira e ele recupera do servidor secundário um conteúdo em cache que está prestes a expirar. Se isso for um problema, você pode configurar um tempo limite de cache menor no servidor secundário.

Resumo

Organizar caches em camadas entre dois ou mais servidores de cache NGINX, da maneira descrita aqui, é uma forma eficaz de criar um cluster de cache de alta disponibilidade que minimize a carga nos servidores de origem, protegendo-os contra 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 distribui o cache entre um cluster de servidores de cache. Nesse caso, a capacidade total corresponde à soma das capacidades de todos os servidores de cache, mas o conteúdo não é replicado para proteger o servidor de origem contra picos de tráfego caso um servidor de cache falhe.

Experimente o cache de alta disponibilidade em seus próprios servidores – comece hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Owen GarrettDiretor Sênior de Gestão de Produtos

Mais publicações de Owen Garrett