Adobe Experience Manager com MongoDB

Implantaçã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 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.

Desabilitação da Dica de Consulta

É recomendável desabilitar a dica de consulta enviada com todas as consultas, adicionando a propriedade -Doak.mongo.disableIndexHint=true quando você inicia o AEM. Isso garante que o MongoDB calcule no índice mais apropriado para usar com base em estatísticas internas.

Se a dica de consulta não estiver desativada, qualquer ajuste de desempenho dos índices não afetará o desempenho do AEM.

Ativar cache persistente para MongoMK

Recomenda-se que uma configuração de cache persistente seja ativada para implantações do MongoDB, a fim de maximizar a velocidade para ambientes com alto desempenho de leitura de E/S. Para obter mais detalhes, consulte a documentação do Jackrabbit Oak.

Otimizações do sistema operacional MongoDB

Suporte a sistema operacional

O MongoDB 2.6 usa um mecanismo de armazenamento de memória mapeada que é sensível a alguns aspectos do gerenciamento de nível do sistema operacional entre a RAM e o Disco. O desempenho de consulta e leitura da instância do MongoDB depende de evitar ou eliminar operações lentas de E/S, geralmente chamadas de falhas de página. Esses problemas são falhas de página que se aplicam especificamente ao processo mongod. Não confunda isso com falhas de página no nível do sistema operacional.

Para uma operação rápida, o banco de dados MongoDB deve acessar apenas os dados que já estão na RAM. Os dados que ele deve acessar são compostos de índices e dados. Essa coleção de índices e dados é chamada de conjunto de trabalho. Quando o conjunto de trabalho é maior que a RAM disponível, o MongoDB tem que paginar esses dados no disco, incorrendo em um custo de E/S, removendo outros dados já na memória. Se a remoção fizer com que os dados sejam recarregados do disco, as falhas de página dominarão e o desempenho será prejudicado. Quando o conjunto de trabalho é dinâmico e variável, ocorrem mais falhas de página para dar suporte às operações.

O MongoDB é executado em vários sistemas operacionais, incluindo uma grande variedade de opções de Linux®, Windows e macOS. Consulte https://docs.mongodb.com/manual/installation/#supported-platforms para obter mais detalhes. Dependendo da sua escolha de sistema operacional, o MongoDB tem diferentes recomendações de nível de sistema operacional. Estão documentados em https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration e resumidos aqui para conveniência.

Instantâneos e pontos de verificação

WiredTiger usa Controle de Simultaneidade MultiVersion (MVCC). No início de uma operação, o WiredTiger fornece um instantâneo point-in-time dos dados para a transação. Um instantâneo apresenta uma exibição consistente dos dados na memória.

Ao gravar em disco, o WiredTiger grava todos os dados em um instantâneo no disco de maneira consistente em todos os arquivos de dados. Os dados agora- duráveis atuam como um ponto de verificação nos arquivos de dados. O ponto de verificação garante a consistência dos arquivos de dados até o último ponto de verificação, inclusive. Ou seja, os pontos de verificação podem agir como pontos de recuperação.

O MongoDB configura o WiredTiger para criar pontos de verificação (ou seja, gravar os dados do instantâneo no disco) em intervalos de 60 segundos ou 2 GB de dados de diário.

Durante a gravação de um novo ponto de verificação, o ponto de verificação anterior ainda é válido. Dessa forma, mesmo que o MongoDB termine ou encontre um erro ao gravar um novo ponto de verificação, após a reinicialização, o MongoDB pode se recuperar do último ponto de verificação válido.

O novo checkpoint se torna acessível e permanente quando a tabela de metadados do WiredTiger é atualizada com precisão para fazer referência ao novo checkpoint. Quando o novo ponto de verificação estiver acessível, o WiredTiger liberará páginas dos pontos de verificação antigos.

Usando o WiredTiger, mesmo sem o registro em diário, o MongoDB pode se recuperar do último ponto de verificação; no entanto, para recuperar as alterações feitas após o último ponto de verificação, execute com o registro em diário.

Configuração do Dispatcher

Uma configuração típica do Dispatcher apresenta de dez a 20 vezes mais throughput de solicitação de uma única instância do AEM.

Como o Dispatcher não tem estado, ele pode ser dimensionado horizontalmente com facilidade. Em algumas implantações, os autores devem ser impedidos de acessar determinados recursos. É recomendável usar uma Dispatcher com as instâncias do autor.

A execução do AEM sem uma Dispatcher exige que a terminação SSL e o balanceamento de carga sejam executados por outro aplicativo. Isso é necessário porque as sessões devem ter afinidade com a instância do AEM em que são criadas, um conceito conhecido como conexões aderentes. O motivo é garantir que as atualizações do conteúdo exibam latência mínima.

Consulte a documentação do Dispatcher para obter mais informações sobre como configurá-la.

Configuração adicional

Conexões adesivas

As conexões adesivas garantem que páginas personalizadas e dados de sessão de um usuário sejam todos compostos na mesma instância do AEM. Esses dados são armazenados na instância, de modo que as solicitações subsequentes do mesmo usuário retornam à mesma instância.

Recomenda-se que as conexões aderentes sejam ativadas para todas as camadas internas que roteam solicitações para as instâncias de AEM, incentivando as solicitações subsequentes a alcançar a mesma instância de AEM. Isso ajuda a minimizar a latência que seria percebida quando o conteúdo é atualizado entre as instâncias.