Capítulo 2 - Infraestrutura

Configurando uma Infraestrutura de Armazenamento em Cache

Introduzimos a topologia básica de um sistema Publish e um dispatcher no Capítulo 1 desta série. Um conjunto de servidores Publish e Dispatcher pode ser configurado em muitas variações, dependendo da carga esperada, da topologia de seu(s) data center(s) e das propriedades de failover desejadas.

Vamos esboçar as topologias mais comuns e descrever as vantagens e onde elas ficam aquém. A lista - é claro - nunca pode ser abrangente. O único limite é a sua imaginação.

A configuração "herdada"

No início, o número de visitantes em potencial era pequeno, o hardware era caro e os servidores da Web não eram considerados tão críticos para os negócios quanto são hoje. Uma configuração comum era ter um Dispatcher funcionando como balanceador de carga e cache na frente de dois ou mais sistemas Publish. O servidor Apache no núcleo do Dispatcher era muito estável e, na maioria das configurações, capaz o suficiente para atender a uma quantidade decente de solicitações.

Configuração do Dispatcher

Configuração do Dispatcher "herdada" - Não é muito comum pelos padrões atuais

Foi daqui que o dispatcher recebeu seu nome: Ele basicamente enviava solicitações. Essa configuração não é mais muito comum, pois não pode atender às demandas mais altas de desempenho e estabilidade necessárias atualmente.

Configuração de várias pernas

Hoje em dia uma topologia ligeiramente diferente é mais comum. Uma topologia de várias etapas teria um Dispatcher por servidor do Publish. Um balanceador de carga dedicado (hardware) fica na frente da infraestrutura do AEM despachando as solicitações para esses dois (ou mais) segmentos:

Configuração "Padrão" do Dispatcher Moderna - Fácil de manusear e manter

Estas são as razões para esse tipo de configuração,

A configuração de "Expansão"

Os servidores Apache são baratos e fáceis de provisionar, por que não forçar a expansão desse nível um pouco mais. Por que não ter dois ou mais Dispatchers na frente de cada servidor do Publish?

Configuração de "Expansão" do

Configuração de "Expansão" do - Tem algumas áreas de aplicativo, mas também limitações e limitações

Você pode fazer isso! E há muitos cenários de aplicação válidos para essa configuração. Mas também há algumas limitações e complexidades que você deve considerar.

Invalidação

Cada sistema do Publish está conectado a uma variedade de Dispatchers e cada um deles deve ser invalidado quando o conteúdo for alterado.

Manutenção

Escusado será dizer que a configuração inicial dos sistemas Dispatcher e Publish é um pouco mais complexa. Mas lembre-se também de que o esforço de uma versão "contínua" também é um pouco maior. Os sistemas AEM podem e devem ser atualizados durante a execução. Mas é sábio não fazer isso enquanto eles estão ativamente atendendo solicitações. Geralmente, você deseja atualizar apenas uma parte dos sistemas do Publish, enquanto os outros ainda atendem ativamente ao tráfego e, depois de testar, mudam para a outra parte. Se você tiver sorte e puder acessar o balanceador de carga em seu processo de implantação, poderá desativar o roteamento para os servidores em manutenção aqui. Se você estiver em um balanceador de carga compartilhado sem acesso direto, é melhor desligar os dispatchers do Publish que deseja atualizar. Quanto mais existirem, mais você terá que desligar. Se houver um grande número e você estiver planejando atualizações frequentes, recomenda-se alguma automação. Se você não tiver ferramentas de automação, dimensionar é uma má ideia, de qualquer forma.

Em um projeto anterior, usamos um truque diferente para remover um sistema Publish do balanceamento de carga sem ter acesso direto ao próprio balanceador de carga.

O balanceador de carga geralmente "faz o ping", uma página específica para ver se o servidor está ativo e em execução. Uma escolha trivial geralmente é fazer ping na página inicial. Mas se você quiser usar o ping para sinalizar o balanceador de carga para não balancear o tráfego, escolha outra coisa. Você cria um modelo ou servlet dedicado que pode ser configurado para responder com "up" ou "down" (no corpo ou como código de resposta http). A resposta dessa página, é claro, não deve ser armazenada em cache no Dispatcher; portanto, ela sempre é buscada recentemente no sistema do Publish. Agora, se você configurar o balanceador de carga para verificar esse template ou servlet, poderá facilmente deixar o Publish "fingir" que está inativo. Ela não faria parte do balanceamento de carga e pode ser atualizada.

Distribuição mundial

"Distribuição mundial" é uma configuração de "Expansão" em que você tem vários Dispatchers na frente de cada sistema Publish - agora distribuídos em todo o mundo para estarem mais próximos do cliente e fornecerem um melhor desempenho. É claro que nesse cenário você não tem um balanceador de carga central, mas um esquema de balanceamento de carga baseado em DNS e geo-IP.

Escala horizontal

Mesmo em um data center local, uma topologia de "expansão" com vários Dispatchers na frente de cada sistema Publish tem algumas vantagens. Se você observar gargalos de desempenho nos servidores Apache devido ao alto tráfego (e uma boa taxa de acerto de cache) e não puder mais aumentar o hardware (adicionando CPUs, RAM e discos mais rápidos), poderá aumentar o desempenho adicionando Dispatchers. Isso é chamado de "dimensionamento horizontal". No entanto, há limites, especialmente quando o tráfego é invalidado com frequência. Vamos descrever o efeito na próxima seção.

Limites da topologia de expansão

A adição de servidores proxy normalmente deve aumentar o desempenho. Entretanto, há cenários em que a adição de servidores pode realmente diminuir o desempenho. Como? Considere ter um portal de notícias, em que você introduz novos artigos e páginas a cada minuto. Uma Dispatcher invalida por "invalidação automática": sempre que uma página é publicada, todas as páginas no cache do mesmo site são invalidadas. Este é um recurso útil - abordamos isso no Capítulo 1 desta série - mas também significa que, quando você tem alterações frequentes em seu site, você está invalidando o cache com frequência. Se você tiver apenas uma Dispatcher por instância do Publish, o primeiro visitante que solicitar uma página acionará um novo armazenamento em cache dessa página. O segundo visitante já obtém a versão em cache.

Se você tiver dois Dispatchers, o segundo visitante terá 50% de chance de a página não ser armazenada em cache e ele experimentará uma latência maior quando essa página for renderizada novamente. Ter ainda mais Dispatchers por Publish torna as coisas ainda piores. O que acontece é que o servidor do Publish recebe mais carga porque precisa renderizar novamente a página de cada Dispatcher separadamente.

Desempenho reduzido em um cenário de expansão com liberações frequentes de cache.

Reduzindo problemas de expansão

Você pode considerar usar um armazenamento compartilhado central para todos os Dispatchers ou sincronizar os sistemas de arquivos dos servidores Apache para atenuar os problemas. Podemos fornecer apenas uma experiência em primeira mão limitada, mas estar preparados para que isso aumente a complexidade do sistema e possa introduzir uma classe totalmente nova de erros.

Tivemos alguns experimentos com NFS, mas o NFS apresenta enormes problemas de desempenho devido ao bloqueio de conteúdo. Isso na verdade diminuiu o desempenho geral.

Conclusão - O compartilhamento de um sistema de arquivos comum entre vários dispatchers NÃO é uma abordagem recomendada.

Se você estiver enfrentando problemas de desempenho, dimensione o Publish e os Dispatchers igualmente para evitar o pico de carga nas instâncias do Publisher. Não há uma regra de ouro sobre a proporção Publish/Dispatcher: ela depende muito da distribuição das solicitações e da frequência das publicações e invalidações de cache.

Se você também estiver preocupado com a latência que um visitante enfrenta, considere usar uma rede de entrega de conteúdo, uma nova busca de cache, o aquecimento preventivo do cache, a definição de um tempo de carência conforme descrito no Capítulo 1 desta série ou consulte algumas ideias avançadas da Parte 3.

A configuração "Cross Connected"

Outra configuração que vimos de vez em quando é a configuração "interconectada": as instâncias do Publish não têm Dispatchers dedicados, mas todos os Dispatchers estão conectados a todos os sistemas Publish.

Topologia entre conexões: maior redundância e complexidade.

À primeira vista, isso fornece mais redundância para um orçamento relativamente pequeno. Quando um dos servidores Apache está inativo, ainda é possível ter dois sistemas Publish fazendo o trabalho de renderização. Além disso, se um dos sistemas Publish travar, ainda haverá dois Dispatchers atendendo à carga em cache.

Isso, no entanto, vem com um preço.

Primeiro, tirar uma perna para manutenção é bastante complicado. Na verdade, foi para isso que esse esquema foi projetado; para ser mais resiliente e permanecer em funcionamento por todos os meios possíveis. Temos visto planos de manutenção complicados sobre como lidar com isso. Reconfigure o Dispatcher 2 primeiro, removendo a conexão cruzada. Reiniciando o Dispatcher 2. Desligando o Dispatcher 1, atualizando o Publish 1, … e assim por diante. Você deve considerar cuidadosamente se isso aumenta para mais de duas pernas. Vocês chegarão à conclusão de que isso realmente aumenta a complexidade, os custos e é uma fonte formidável de erro humano. Seria melhor automatizar isso. Portanto, é melhor verificar se você realmente tem os recursos humanos para incluir essa tarefa de automação no cronograma do seu projeto. Embora você possa economizar alguns custos de hardware com isso, você pode gastar o dobro em equipe de TI.

Em segundo lugar, você pode ter algum aplicativo de usuário em execução no AEM que requer um logon. Use sessões aderentes para garantir que um usuário sempre seja distribuído da mesma instância do AEM, para que você possa manter o estado da sessão nessa instância. Com essa configuração com conexão cruzada, é necessário garantir que as sessões adesivas estejam funcionando corretamente no balanceador de carga e nos Dispatchers. Não é impossível, mas você precisa estar ciente disso e adicionar algumas horas extras de configuração e teste, o que - novamente - pode nivelar a economia planejada com a economia de hardware.

Conclusão

Não recomendamos que você use esse esquema de conexão cruzada como uma opção padrão. No entanto, se decidir usá-lo, avalie cuidadosamente os riscos e os custos ocultos e planeje incluir a automação da configuração como parte do projeto.

Próxima etapa