Adobe Experience Manager com MongoDB
Este artigo tem como objetivo melhorar o conhecimento sobre as tarefas e as considerações necessárias para a implantação bem-sucedida do AEM (Adobe Experience Manager) com o MongoDB.
Para obter mais informações sobre implantação, consulte a seção Implantação e manutenção da documentação.
Quando usar MongoDB com AEM
O MongoDB é normalmente usado para oferecer suporte a implantações de autores de AEM, onde um dos seguintes critérios é atendido:
- Mais de 1000 utilizadores únicos por dia;
- Mais de 100 usuários simultâneos;
- Grandes volumes de edições de página;
- Implantações ou ativações grandes.
Os critérios acima são somente para as instâncias do autor e não para nenhuma instância de publicação que deve ser baseada em TarMK. O número de usuários se refere a usuários autenticados, pois as instâncias de autor não permitem acesso não autenticado.
Se os critérios não forem atendidos, uma implantação ativo/standby de TarMK será recomendada para tratar da disponibilidade. Geralmente, o MongoDB deve ser considerado em situações em que os requisitos de dimensionamento são maiores do que o que pode ser obtido com um único item de hardware.
NOTEImplantação mínima do MongoDB para AEM
Abaixo está uma implantação mínima para o AEM no MongoDB. Para simplificar, a terminação SSL e os componentes do Proxy HTTP foram generalizados. Consiste em um único conjunto de réplicas MongoDB, com um primário e dois secundários.
Uma implantação mínima requer três instâncias mongod configuradas como um conjunto de réplicas. Uma instância é eleita primária com as outras instâncias sendo secundárias, com a eleição gerenciada por mongod. Anexado a cada instância está um disco local. Portanto, o cluster pode suportar a carga. Recomenda-se um throughput mínimo de 12 MB por segundo com mais de 3.000 operações de E/S por segundo (IOPS).
Os autores do AEM estão conectados às mongod instâncias, com cada autor do AEM se conectando a todas as três mongod instâncias. As gravações são enviadas para o principal e as leituras podem ser lidas de qualquer uma das instâncias. O tráfego é distribuído com base na carga por um Dispatcher para qualquer uma das instâncias de autor ativas do AEM. O armazenamento de dados do Oak é um FileDataStore, e o monitoramento do MongoDB é fornecido pelo MMS ou pelo MongoDB Ops Manager, dependendo da localização da implantação. O nível do sistema operacional e o monitoramento de registros são fornecidos por soluções de terceiros, como Splunk ou Ganglia.
Nesta implantação, todos os componentes são necessários para uma implementação bem-sucedida. Qualquer componente ausente deixa a implementação não funcional.
Sistemas operacionais
Para obter uma lista dos sistemas operacionais compatíveis com o AEM 6, consulte a página Requisitos técnicos.
Ambientes
Os ambientes virtualizados são suportados desde que haja uma boa comunicação entre as diferentes equipes técnicas que executam o projeto. Esse suporte inclui a equipe que está executando o AEM, a equipe que possui o sistema operacional e a equipe que gerencia a infraestrutura virtualizada.
Há requisitos específicos que abrangem a capacidade de E/S das instâncias do MongoDB que devem ser gerenciadas pela equipe que gerencia o ambiente virtualizado. Se o projeto usar uma implantação em nuvem, como o Amazon Web Services, as instâncias deverão ser provisionadas com capacidade e consistência de E/S suficientes para dar suporte às instâncias do MongoDB. Caso contrário, os processos do MongoDB e o repositório do Oak serão executados de forma não confiável e irregular.
Em ambientes virtualizados, o MongoDB requer configurações específicas de E/S e VM para garantir que o mecanismo de armazenamento do MongoDB não seja paralisado pelas políticas de alocação de recursos da VMWare. Uma implementação bem-sucedida garante que não haja barreiras entre as várias equipes, e todas estão inscritas para fornecer o desempenho necessário.
Considerações sobre hardware
Armazenamento
Para alcançar a taxa de transferência de leitura e gravação para melhor desempenho sem a necessidade de dimensionamento horizontal prematuro, o MongoDB geralmente requer armazenamento de dados SSD ou armazenamento de dados com desempenho equivalente ao SSD.
RAM
As versões 2.6 e 3.0 do MongoDB que usam o mecanismo de armazenamento MMAP exigem que o conjunto de trabalho do banco de dados e seus índices se encaixem na RAM.
A RAM insuficiente resulta em uma redução significativa do desempenho. O tamanho do conjunto de trabalho e do banco de dados é altamente dependente do aplicativo. Embora algumas estimativas possam ser feitas, a maneira mais confiável de determinar a quantidade de RAM necessária é criar o aplicativo AEM e testá-lo.
Para auxiliar no processo de teste de carga, a seguinte proporção de conjunto de trabalho para o tamanho total do banco de dados pode ser presumida:
- 1:10 para armazenamento de dados SSD
- 1:3 para armazenamento em disco rígido
Essas taxas significam que para implantações de SSD são necessários 200 GB de RAM para um banco de dados de 2 TB.
Embora as mesmas limitações se apliquem ao mecanismo de armazenamento WiredTiger no MongoDB 3.0, a correlação entre o conjunto de trabalho, a RAM e as falhas de página não é tão forte. O WiredTiger não usa o mapeamento de memória da mesma forma que o mecanismo de armazenamento MMAP.
NOTEArmazenamento de dados
Devido às limitações do conjunto de trabalho do MongoDB, é recomendável que o armazenamento de dados seja mantido independente do MongoDB. Na maioria dos ambientes, um FileDataStore usando um NAS disponível para todas as instâncias AEM deve ser usado. Para situações em que o Amazon Web Services é usado, também há um S3 DataStore. Se, por qualquer motivo, o armazenamento de dados for mantido no MongoDB, o tamanho do armazenamento de dados deverá ser adicionado ao tamanho total do banco de dados e os cálculos do conjunto de trabalho deverão ser ajustados adequadamente. Esse dimensionamento pode significar o provisionamento de mais RAM para manter o desempenho sem falhas de página.
Monitoramento
O acompanhamento é vital para uma implementação bem-sucedida do projeto. Com conhecimento suficiente, é possível executar o AEM no MongoDB sem monitoramento. No entanto, esse conhecimento normalmente é encontrado em engenheiros especializados para cada seção da implantação.
Esse conhecimento especializado geralmente envolve um engenheiro de P&D que trabalha no Apache Oak Core e um especialista em MongoDB.
Sem monitoramento em todos os níveis, é necessário um conhecimento detalhado da base de código para diagnosticar problemas. Com o acompanhamento em vigor e orientações adequadas sobre as principais estatísticas, as equipes de execução podem reagir adequadamente às anomalias.
Embora seja possível usar ferramentas de linha de comando para obter um instantâneo rápido da operação de um cluster, fazer isso em tempo real em muitos hosts é quase impossível. As ferramentas de linha de comando raramente fornecem informações históricas além de alguns minutos e nunca permitem a correlação cruzada entre diferentes tipos de métricas. Um breve período de sincronização lenta em segundo plano do mongod requer um esforço manual significativo para correlacionar com os níveis de espera de E/S ou de gravação excessiva para um recurso de armazenamento compartilhado de uma máquina virtual aparentemente desconectada.
MongoDB Cloud Manager
O MongoDB Cloud Manager é um serviço gratuito oferecido pelo MongoDB que permite o monitoramento e o gerenciamento de instâncias do MongoDB. Ele fornece uma visualização do desempenho e da integridade do cluster MongoDB em tempo real. Ele gerencia instâncias na nuvem e hospedadas de forma privada, desde que a instância possa acessar o Cloud Manager Monitoring Server.
Ele requer um agente instalado na instância do MongoDB que se conecta ao servidor de monitoramento. Há três níveis do agente:
- Um agente de automação que pode automatizar completamente tudo no servidor MongoDB,
- Um agente de monitoramento que pode monitorar a instância
mongod, - Um agente de backup que pode executar backups programados dos dados.
Embora o uso do Cloud Manager para automação de manutenção de um cluster MongoDB torne muitas das tarefas de rotina mais fáceis, ele não é necessário e nem o está usando para backup. No entanto, ao escolher um Cloud Manager para monitorar, é necessário monitorar.
Para obter mais informações sobre o MongoDB Cloud Manager, consulte a documentação do MongoDB.
Gerenciador de Operações do MongoDB
MongoDB Ops Manager é o mesmo software que o MongoDB Cloud Manager. Depois de registrado, o Ops Manager pode ser baixado e instalado localmente em um data center privado ou em qualquer outro laptop ou computador desktop. Ele usa um banco de dados MongoDB local para armazenar dados e se comunicar da mesma forma que o Cloud Manager com os servidores gerenciados. Se você tiver políticas de segurança que proíbam um agente de monitoramento, o MongoDB Ops Manager deverá ser usado.
Monitoramento do sistema operacional
É necessário o monitoramento em nível de sistema operacional para executar um cluster AEM MongoDB.
O Ganglia é um bom exemplo de um sistema desse tipo e fornece uma imagem da variedade e dos detalhes das informações necessárias, que vão além das métricas básicas de integridade, como CPU, média de carga e espaço livre em disco. Para diagnosticar problemas, são necessárias informações de nível inferior, como níveis de pool de entropia, Espera de E/S da CPU e soquetes no estado FIN_WAIT2.
Agregação de Log
Com um cluster de vários servidores, a agregação central de registros é um requisito para um sistema de produção. Softwares como o Splunk oferecem suporte à agregação de logs e permitem que as equipes analisem os padrões de comportamento do aplicativo sem precisar coletar manualmente os logs.
Listas de verificação
Esta seção trata de várias etapas necessárias para garantir que suas implantações de AEM e MongoDB sejam configuradas corretamente antes de implementar seu projeto.
Rede
- Primeiro, verifique se todos os hosts têm uma entrada de DNS
- Todos os hosts devem ser resolvidos por sua entrada de DNS de todos os outros hosts roteáveis
- Todos os hosts MongoDB podem ser roteados de todos os outros hosts MongoDB no mesmo cluster
- Os hosts MongoDB podem rotear pacotes para o MongoDB Cloud Manager e outros servidores de monitoramento
- Servidores AEM podem rotear pacotes para todos os servidores MongoDB
- A latência de pacote entre qualquer servidor AEM e qualquer servidor MongoDB é menor que dois milissegundos, sem perda de pacote e com uma distribuição padrão de um milissegundo ou menos.
- Verifique se não há mais de dois saltos entre um AEM e um servidor MongoDB
- Não há mais do que dois saltos entre dois servidores MongoDB
- Não há roteadores mais altos que o nível 3 de OSI entre quaisquer servidores núcleo (MongoDB ou AEM ou qualquer combinação).
- Se o entroncamento VLAN ou qualquer forma de tunelamento de rede for usado, ele deverá estar em conformidade com as verificações de latência de pacote.