Caches compartilhados com clusters de cache NGINX Plus, parte 1

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

• Caches compartilhados com clusters de cache NGINX Plus, parte 1 (esta postagem)
• Caches compartilhados com clusters de cache NGINX Plus, parte 2

Esta postagem foi atualizada para se referir à API NGINX Plus, que substitui e descontinua o módulo de status estendido separado discutido originalmente aqui.

Como você pode criar um cluster de cache de alta capacidade e alta disponibilidade usando NGINX ou NGINX Plus? Esta é a primeira de uma série de duas partes que apresentam uma abordagem alternativa para atingir esse objetivo. Você pode acessar a segunda parte através do link acima. (Exceto quando observado, as abordagens se aplicam igualmente ao NGINX Open Source e ao NGINX Plus, mas para resumir, nos referiremos apenas ao NGINX Plus.)

Uma visão geral do cache NGINX Plus

O NGINX Plus pode operar como um servidor de cache proxy, localizado entre o servidor de origem e os clientes remotos. O NGINX Plus gerencia o tráfego para o servidor de origem e armazena em cache (armazena) recursos comuns e imutáveis. Isso permite que o NGINX Plus responda diretamente aos clientes quando esses recursos são solicitados, reduzindo assim a carga no servidor de origem. O cache proxy do NGINX Plus é mais comumente implantado em um data center próximo ao servidor de origem e também pode ser implantado de forma semelhante a uma CDN em PoPs distribuídos globalmente.

O cache de conteúdo é um tópico surpreendentemente complexo. Vale a pena se familiarizar com algumas técnicas básicas de cache antes de continuar com este artigo:

• A mecânica do cache NGINX Plus – Configuração principal e a função dos processos do carregador de cache e do gerenciador de cache
• Ajuste fino dos tempos de cache – Implementação de práticas como microcaching para controlar como o conteúdo é armazenado em cache e como ele é atualizado quando expira

Por que o NGINX Plus não usa um disco compartilhado para cache?

Cada servidor NGINX Plus atua como um servidor de cache da web independente. Não há meios técnicos para compartilhar um cache baseado em disco entre vários servidores NGINX Plus; esta é uma decisão de design deliberada.

Armazenar um cache em um sistema de arquivos compartilhado de alta latência e potencialmente não confiável não é uma boa escolha de design. O NGINX Plus é sensível à latência do disco e, embora a capacidade dos pools de threads descarregue as operações read() e write() do thread principal, quando o sistema de arquivos está lento e a E/S do cache está alta, o NGINX Plus pode ficar sobrecarregado por grandes volumes de threads. Manter um cache consistente e compartilhado entre instâncias do NGINX Plus também exigiria bloqueios em todo o cluster para sincronizar operações de cache sobrepostas, como preenchimentos, leituras e exclusões. Por fim, os sistemas de arquivos compartilhados introduzem uma fonte de falta de confiabilidade e desempenho imprevisível ao cache, onde confiabilidade e desempenho consistente são fundamentais.

Por que compartilhar um cache entre vários servidores NGINX Plus?

Embora compartilhar um sistema de arquivos não seja uma boa abordagem para armazenamento em cache, ainda há bons motivos para armazenar em cache o conteúdo em vários servidores NGINX Plus, cada um com uma técnica correspondente:

• Se seu objetivo principal é criar um cache de altíssima capacidade, particione seu cache em vários servidores. Abordaremos essa técnica neste post.
• Se seu objetivo principal é atingir alta disponibilidade e minimizar a carga nos servidores de origem, use um cache compartilhado de alta disponibilidade. Para esta técnica, veja a postagem complementar (em breve).

Fragmentando seu cache

Fragmentar um cache é o processo de distribuir entradas de cache entre vários servidores de cache da web. O particionamento de cache do NGINX Plus usa um algoritmo de hash consistente para selecionar um servidor de cache para cada entrada de cache. As figuras mostram o que acontece com um cache fragmentado em três servidores (figura à esquerda) quando um servidor fica inativo (figura do meio) ou outro servidor é adicionado (figura à direita).

A capacidade total de cache é a soma da capacidade de cache de cada servidor. Você minimiza as viagens ao servidor de origem porque apenas um servidor tenta armazenar em cache cada recurso (você não tem várias cópias independentes do mesmo recurso).

Esse padrão é tolerante a falhas no sentido de que se você tiver N servidores de cache e um falhar, você perderá apenas 1/ N do seu cache. Essa 'porção perdida' é distribuída uniformemente pelo hash consistente nos servidores N -1 restantes. Métodos de hash mais simples redistribuem todo o cache entre os servidores restantes e você perde quase todo o cache durante a redistribuição.

Ao executar o balanceamento de carga de hash consistente , use a chave de cache (ou um subconjunto dos campos usados para construir a chave) como a chave para o hash consistente:

upstream cache_servers { hash $scheme$proxy_host$request_uri consistente;

servidor red.cache.example.com;
servidor green.cache.example.com;
servidor blue.cache.example.com;
}

Você pode distribuir o tráfego de entrada na camada do Balanceador de Carga (LB) usando a solução de alta disponibilidade ativa-passiva no NGINX Plus , DNS round-robin ou uma solução de alta disponibilidade, como keepalived .

Otimizando sua configuração de cache fragmentado

Você pode escolher uma das duas otimizações para sua configuração de fragmentação de cache.

Combinando os níveis do balanceador de carga e do cache

Você pode combinar os níveis LB e Cache. Nessa configuração, dois servidores virtuais são executados em cada instância do NGINX Plus. O servidor virtual de balanceamento de carga (“LB VS” na figura) aceita solicitações de clientes externos e usa um hash consistente para distribuí-las entre todas as instâncias do NGINX Plus no cluster, que são conectadas por uma rede interna. O servidor virtual de cache (“Cache VS”) em cada instância do NGINX Plus escuta em seu endereço IP interno sua parcela de solicitações, encaminhando-as ao servidor de origem e armazenando as respostas em cache. Isso permite que todas as instâncias do NGINX Plus atuem como servidores de cache, maximizando sua capacidade de cache.

Configurando um cache “quente” de primeiro nível

Como alternativa, você pode configurar um cache de primeiro nível na camada LB do frontend para conteúdo muito ativo, usando o cache compartilhado grande como um cache de segundo nível. Isso pode melhorar o desempenho e reduzir o impacto no servidor de origem se uma camada de cache de segundo nível falhar, porque o conteúdo só precisa ser atualizado à medida que o conteúdo do cache de primeiro nível expira gradualmente.

Se o seu cluster de cache estiver manipulando um volume muito grande de conteúdo ativo, você poderá descobrir que a taxa de rotatividade no cache de primeiro nível menor é muito alta. Em outras palavras, a demanda por espaço limitado no cache é tão alta que o conteúdo é removido do cache (para abrir espaço para conteúdo solicitado mais recentemente) antes que ele possa ser usado para satisfazer até mesmo uma solicitação subsequente.

Um indicador dessa situação é a baixa proporção de conteúdo veiculado em relação ao conteúdo escrito, duas métricas incluídas nas estatísticas estendidas relatadas pelo módulo NGINX Plus API . Eles aparecem nos campos Servidos e Gravados na guia Caches do painel de monitoramento de atividades ao vivo integrado. (Observe que o módulo NGINX Plus API e o painel de monitoramento de atividades ao vivo não estão disponíveis no NGINX Open Source.)

Esta captura de tela indica a situação em que o NGINX Plus está gravando mais conteúdo no cache do que está servindo a partir dele:

Nesse caso, você pode ajustar seu cache para armazenar apenas o conteúdo mais comumente solicitado. A diretiva proxy_cache_min_uses pode ajudar a identificar esse conteúdo.

Resumo

Fragmentar um cache em vários servidores de cache da Web NGINX ou NGINX Plus é uma maneira eficaz de criar um cache escalável e de altíssima capacidade. O hash consistente fornece um bom grau de alta disponibilidade, garantindo que, se um cache falhar, apenas sua parte do conteúdo armazenado em cache será invalidada.

A segunda parte desta postagem descreve um padrão alternativo de cache compartilhado que replica o cache em um par de servidores de cache NGINX ou NGINX Plus. A capacidade total é limitada à capacidade de um servidor individual, mas a configuração é totalmente tolerante a falhas e nenhum conteúdo em cache é perdido se um servidor de cache ficar indisponível.

Experimente o sharding de cache 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 .