Implantações recomendadas recommended-deployments
MicroKernels agem como gerenciadores de persistência a partir do AEM 6.2. Escolher um para atender às suas necessidades depende da finalidade da instância e do tipo de implantação que você está considerando.
Os exemplos abaixo são uma indicação de quais são os usos recomendados nas configurações mais comuns do AEM.
Cenários de implantação deployment-scenarios
Instância única do TarMK single-tarmk-instance
Nesse cenário, uma única instância TarMK é executada em um único servidor.
Esta é a implantação padrão para instâncias de autor.
Vantagens:
- Simples
- Fácil manutenção
- Bom desempenho
As desvantagens:
- Não dimensionável além dos limites da capacidade do servidor
- Sem capacidade de failover
Modo de espera a frio TarMK tarmk-cold-standby
Uma instância TarMK atua como a instância primária. O repositório do principal é replicado em um sistema de failover de standby.
O mecanismo de standby inativo também pode ser usado como backup porque o repositório completo é replicado constantemente no servidor de failover. O servidor de failover está sendo executado no modo de espera inativo, o que significa que somente o HttpReceiver da instância está sendo executado.
Vantagens:
- Simplicidade
- Capacidade de manutenção
- Desempenho
- Failover
As desvantagens:
- Não dimensionável além dos limites da capacidade do servidor
- Um servidor fica ocioso a maior parte do tempo
- O failover não é automático. Ele deve ser detectado externamente antes que o sistema de failover possa iniciar a veiculação de solicitações.
Farm TarMK tarmk-farm
Várias instâncias do Oak são executadas com uma instância TarMK. Os repositórios TarMK são independentes e precisam ser mantidos em sincronia.
Manter os repositórios em sincronia é fornecido com o fato de que o servidor do autor está publicando o mesmo conteúdo para cada membro do farm. Para obter mais informações, consulte Replicação.
Para o AEM Communities, o conteúdo gerado pelo usuário (UGC) nunca é replicado. Para obter suporte a UGC em um Farm TarMK, consulte considerações para AEM Communities.
Esta é a implantação padrão para ambientes de publicação.
Vantagens:
- Desempenho
- Escalabilidade para acesso de leitura
- Failover
Cluster Oak com failover MongoMK para alta disponibilidade em um único data center oak-cluster-with-mongomk-failover-for-high-availability-in-a-single-datacenter
Essa abordagem implica que várias instâncias do Oak acessem um conjunto de réplicas do MongoDB em um único data center, criando, na verdade, um cluster ativo-ativo para o ambiente de criação do AEM. Os conjuntos de réplicas no MongoDB são usados para fornecer alta disponibilidade e redundância em caso de falha de hardware ou rede.
Vantagens:
- Capacidade de dimensionar horizontalmente com novas instâncias de autor de AEM
- Alta disponibilidade, redundância e failover automatizado da camada de dados
As desvantagens:
- O desempenho pode ser menor do que com TarMK para alguns cenários
Cluster Oak com failover MongoMK em vários data centers oak-cluster-with-mongomk-failover-across-multiple-datacenters
Essa abordagem implica que várias instâncias do Oak acessem um conjunto de réplicas do MongoDB em vários data centers, criando, na verdade, um cluster ativo-ativo para o ambiente de criação do AEM. Com vários data centers, a replicação MongoDB fornece a mesma alta disponibilidade e redundância, mas agora inclui a capacidade de lidar com uma interrupção no data center.
Vantagens:
- Capacidade de dimensionar horizontalmente com novas instâncias de autor de AEM
- Alta disponibilidade, redundância e failover automatizado da camada de dados (incluindo paralisações do data center)
Microkernels: qual usar microkernels-which-one-to-use
A regra básica que precisa ser levada em conta ao escolher entre os dois micronúcleos disponíveis é que o TarMK é projetado para desempenho, enquanto o MongoMK é usado para escalabilidade.
Você pode usar essas matrizes de decisão para estabelecer qual é o melhor tipo de implantação adequado aos seus requisitos.
A Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, para as instâncias do AEM Author e do Publish, exceto nos casos de uso descritos abaixo.
Exceções para escolher AEM MongoMK em vez de TarMK em instâncias de autor exceptions-for-choosing-aem-mongomk-over-tarmk-on-author-instances
O principal motivo para escolher o back-end de persistência MongoMK em vez do TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução o tempo todo e usar o MongoDB como o sistema de armazenamento de persistência. A necessidade de executar mais de uma instância de autor geralmente resulta do fato de que a capacidade da CPU e da memória de um único servidor, que suporta todas as atividades de criação simultâneas, não é mais sustentável.
É quase impossível prever qual será o modelo de simultaneidade exato depois que um novo site entrar em funcionamento. Portanto, o Adobe recomenda que você considere os seguintes critérios ao avaliar se deve usar MongoMK e dois ou mais nós ativos do Author:
- Número de usuários nomeados conectados em um dia: milhares ou mais.
- Número de usuários simultâneos: em centenas ou mais.
- Volume de assimilações de ativos por dia: em centenas de milhares ou mais.
- Volume de edições de página por dia: em centenas de milhares ou mais (incluindo atualizações automatizadas via Gerenciador de vários sites ou assimilações de feed de notícias, por exemplo).
- Volume de pesquisas por dia: em dezenas de milhares ou mais.
Uma implantação mínima com MongoDB normalmente envolve a seguinte topologia:
- Um conjunto de réplicas MongoDB que consiste em um nó primário, dois nós secundários com cada uma das instâncias MongoDB em execução em uma zona de disponibilidade com uma latência abaixo de 15 milissegundos em cada nó;
- Um cluster de instâncias do autor com um nó líder, um nó não líder e ambos ativos o tempo todo, com cada uma das instâncias do autor em execução em cada um dos data centers, onde as instâncias primária e secundária do MongoDB estão em execução.
Além disso, é altamente recomendável configurar o armazenamento de dados em um sistema de arquivos compartilhado ou no Amazon S3, de modo que os ativos ou binários não sejam armazenados no MongoDB. Isso garantirá o desempenho ideal na implantação.
Um dos benefícios adicionais de implantar um conjunto de réplicas do MongoDB com um cluster de duas ou mais instâncias de autor é ter um cenário de recuperação automatizada com tempo de inatividade mínimo se houver instâncias de autor, réplica do MongoDB ou uma falha completa do data center. No entanto, a escolha de MongoMK em vez de TarMK não deve ser orientada exclusivamente pelo requisito de recuperação, já que o TarMK também pode fornecer uma solução de tempo de inatividade mínimo com um mecanismo de failover controlado.
Se os critérios acima não forem esperados durante os primeiros 18 meses da implantação, é recomendável primeiro implantar o AEM usando TarMK, reavaliar sua configuração posteriormente quando os critérios acima se aplicarem e, finalmente, determinar se deve permanecer no TarMK ou migrar para MongoMK.
Exceções para escolher AEM MongoMK em vez de TarMK em instâncias do Publish exceptions-for-choosing-aem-mongomk-over-tarmk-on-publish-instances
Não é recomendável implantar o MongoMK para instâncias de publicação. O nível de publicação da implantação é quase sempre implantado como um farm de instâncias de publicação totalmente independentes que executam o TarMK, que são mantidas em sincronia ao replicar o conteúdo das instâncias de autor. Essa arquitetura de "nada compartilhado", adequada às instâncias de publicação, permite que a implantação do nível de publicação seja dimensionada horizontalmente de forma linear. A topologia do farm também oferece o benefício de aplicar qualquer atualização ou atualização a instâncias de publicação continuamente, de modo que qualquer alteração no nível de publicação não exigirá tempo de inatividade.
Isso não se aplica ao AEM Communities que usa clusters MongoMK no nível de publicação sempre que houver mais de um editor. Se você escolher o JSRP (consulte Armazenamento de conteúdo da comunidade), um cluster MongoMK será apropriado, assim como qualquer cluster do lado da publicação, independentemente do MK escolhido, como MongoDB ou RDB.
Pré-requisitos e Recommendations ao implantar AEM com MongoMK prerequisites-and-recommendations-when-deploying-aem-with-mongomk
Um conjunto de pré-requisitos e recomendações está disponível se você estiver considerando uma implantação do MongoMK para AEM:
Pré-requisitos obrigatórios para implantações do MongoDB:
- A arquitetura e o dimensionamento da implantação do MongoDB devem fazer parte da implementação do projeto com a ajuda de arquitetos da Adobe Consulting ou do MongoDB familiarizados com o AEM;
- A experiência do MongoDB deve estar presente no parceiro ou na equipe do cliente para ter confiança na capacidade de sustentar e manter um ambiente MongoDB existente ou novo;
- Você pode optar por implantar a versão comercial ou de código aberto do MongoDB (AEM suporta ambos), mas deve comprar um contrato de Manutenção e Suporte do MongoDB diretamente da MongoDB Inc;
- Em geral, as arquiteturas e infraestruturas do AEM e do MongoDB devem ser bem definidas e validadas por um Arquiteto do Adobe AEM;
- Revise o modelo de suporte para implantações de AEM que incluem MongoDB.
Recomendações fortes para implantações do MongoDB:
- Consulte a Análise da Implantação do MongoDB para o Adobe Experience Manager;
- Revise a Lista de Verificação de Operações do MongoDB;
- Participe de uma aula de certificação no MongoDB - disponível online.
Considerações para o AEM Communities considerations-for-aem-communities
Para sites que planejam implantar o AEM Communities, é recomendável escolher uma implantação otimizada para lidar com o UGC postado por membros da comunidade do ambiente de publicação.
Ao usar um armazenamento comum, o UGC não precisa ser replicado entre o autor e outras instâncias de publicação para obter uma exibição consistente do UGC.
Abaixo estão um conjunto de matrizes de decisão que podem ajudá-lo a escolher o melhor tipo de persistência para sua implantação:
Escolha do tipo de implantação para instâncias de autor choosing-the-deployment-type-for-author-instances
Escolha do tipo de implantação para instâncias de publicação choosing-the-deployment-type-for-publish-instances
