Como executar AEM com o TarMK Cold Standby how-to-run-aem-with-tarmk-cold-standby

Introdução introduction

A capacidade de Espera Fria do Tar Micro Kernel permite que uma ou mais instâncias de AEM standby se conectem a uma instância primária. O processo de sincronização é uma maneira única de significar que é feito somente das instâncias primárias às de standby.

A finalidade das instâncias em standby é garantir uma cópia dos dados em tempo real do repositório principal e garantir um switch rápido sem perda de dados caso o principal não esteja disponível por qualquer motivo.

O conteúdo é sincronizado linearmente entre as instâncias primárias e de standby, sem qualquer verificação de integridade de corrupção de arquivo ou repositório. Devido a esse design, as instâncias em standby são cópias exatas da instância principal e não podem ajudar a atenuar inconsistências em instâncias primárias.

Como funciona how-it-works

Na instância principal do AEM, uma porta TCP é aberta e está ouvindo mensagens recebidas. Atualmente, há dois tipos de mensagens que os escravos enviarão ao principal:

O standby solicita periodicamente a ID do segmento do cabeçalho atual do primário. Se o segmento for localmente desconhecido, ele será recuperado. Se já estiver presente, os segmentos são comparados e os segmentos referenciados também serão solicitados, se necessário.

Uma implantação típica do TarMK Cold Standby:

Outras características other-characteristics

Robustez robustness

O fluxo de dados foi projetado para detectar e lidar automaticamente com problemas relacionados à conexão e à rede. Todos os pacotes são empacotados com somas de verificação e assim que ocorrem problemas com a conexão ou pacotes danificados, os mecanismos de repetição são acionados.

Desempenho performance

Ativar o TarMK Cold Standby na instância primária quase não tem impacto mensurável no desempenho. O consumo adicional da CPU é muito baixo e o disco rígido extra e a E/S de rede não devem gerar problemas de desempenho.

No modo de espera, você pode esperar alto consumo de CPU durante o processo de sincronização. Devido ao fato de o procedimento não ser multisegmentado, ele não pode ser acelerado usando vários núcleos. Se nenhum dado for alterado ou transferido, não haverá atividade mensurável. A velocidade da conexão varia dependendo do hardware e do ambiente de rede, mas não depende do tamanho do repositório ou do uso do SSL. Lembre-se disso ao estimar o tempo necessário para uma sincronização inicial ou quando muitos dados foram alterados enquanto isso no nó principal.

Segurança security

Supondo que todas as instâncias são executadas na mesma zona de segurança da intranet, o risco de violação de segurança é muito reduzido. No entanto, é possível adicionar uma camada de segurança adicional, permitindo conexões SSL entre os escravos e o principal. Isso reduz a possibilidade de os dados serem comprometidos por um homem no meio.

Além disso, você pode especificar as instâncias de standby que podem se conectar, restringindo o endereço IP das solicitações recebidas. Isso deve ajudar a garantir que ninguém na intranet possa copiar o repositório.

Criação de uma configuração AEM TarMK Cold Standby creating-an-aem-tarmk-cold-standby-setup

Para criar uma configuração TarMK de standby frio, primeiro é necessário criar as instâncias de standby executando uma cópia do sistema de arquivos de toda a pasta de instalação do principal em um novo local. Você pode iniciar cada instância com um modo de execução que especificará sua função ( primary ou standby).

Abaixo está o procedimento que precisa ser seguido para criar uma configuração com uma instância principal e uma standby:

O serviço também pode ser configurado por meio do Console da Web:

Primeira sincronização first-time-synchronization

Depois que a preparação estiver concluída e o standby for iniciado pela primeira vez, haverá tráfego intenso de rede entre as instâncias, já que o standby chega ao primário. Você pode consultar os logs para observar o status da sincronização.

Em espera tarmk-coldstandby.log, você verá entradas como estas:

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore trying to read segment ec1f739c-0e3c-41b8-be2e-5417efc05266

    *DEBUG* [nioEventLoopGroup-3-1] org.apache.jackrabbit.oak.segment.standby.codec.SegmentDecoder received type 1 with id ec1f739c-0e3c-41b8-be2e-5417efc05266 and size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore got segment ec1f739c-0e3c-41b8-be2e-5417efc05266 with size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment ec1f739c-0e3c-41b8-be2e-5417efc05266 to /mnt/crx/author/crx-quickstart/repository/segmentstore/data00016a.tar

No error.log, você deve ver uma entrada como esta:

*INFO* [FelixStartLevel] org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService started standby sync with 10.20.30.40:8023 at 5 sec.

No trecho de log acima, 10.20.30.40 é o endereço IP do principal.

No principal tarmk-coldstandby.log, você verá entradas como estas:

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver got message ‘s.d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd’ from client c7a7ce9b-1e16-488a-976e-627100ddd8cd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler request segment id d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler sending segment d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd to /10.20.30.40:34998

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver did send segment with 262144 bytes to client c7a7ce9b-1e16-488a-976e-627100ddd8cd

Nesse caso, o "cliente" mencionado no log é o secundário instância.

Quando essas entradas deixarem de aparecer no log, você pode assumir com segurança que o processo de sincronização está concluído.

Embora as entradas acima mostrem que o mecanismo de sondagem está funcionando corretamente, muitas vezes é útil entender se há dados sendo sincronizados enquanto a pesquisa está ocorrendo. Para fazer isso, procure entradas como as seguintes:

*DEBUG* [defaultEventExecutorGroup-156-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment 3a03fafc-d1f9-4a8f-a67a-d0849d5a36d5 to /<<CQROOTDIRECTORY>>/crx-quickstart/repository/segmentstore/data00014a.tar

Além disso, ao executar com um FileDataStore, mensagens como as seguintes confirmarão que os arquivos binários estão sendo transmitidos corretamente:

*DEBUG* [nioEventLoopGroup-228-1] org.apache.jackrabbit.oak.segment.standby.codec.ReplyDecoder received blob with id eb26faeaca7f6f5b636f0ececc592f1fd97ea1a9#169102 and size 169102

Configuração configuration

As seguintes configurações OSGi estão disponíveis para o serviço Cold Standby:

Procedimentos de failover failover-procedures

Caso a instância primária falhe por qualquer motivo, você pode definir uma das instâncias de standby para assumir a função do primário alterando o modo de execução de início conforme detalhado abaixo:

Aplicação de hotfixes a uma configuração do Cold Standby applying-hotfixes-to-a-cold-standby-setup

A maneira recomendada de aplicar hotfixes a uma configuração de stanby frio é instalá-los na instância primária e cloná-los em uma nova instância de standby frio com os hotfixes instalados.

Você pode fazer isso seguindo as etapas descritas abaixo:

Monitoramento monitoring

O recurso expõe informações usando JMX ou MBeans. Fazendo isso, você pode inspecionar o estado atual do standby e o principal usando o Console JMX. As informações podem ser encontradas em um MBean de type org.apache.jackrabbit.oak:type="Standby"nomeado Status.

Espera

Observando uma instância de standby, você exporá um nó. Normalmente, a ID é um UUID genérico.

Este nó tem cinco atributos somente leitura:

Há também três métodos faturáveis:

Principal

A observação do primário expõe algumas informações gerais por meio de um MBean cujo valor de ID é o número da porta que o serviço de standby TarMK está usando (8023 por padrão). A maioria dos métodos e atributos é igual ao modo de espera, mas alguns diferem:

Além disso, podem ser recuperadas informações para até 10 clientes (instâncias em standby) conectados ao principal. A ID do MBean é o UUID da instância. Não há métodos faturáveis para esses MBeans, mas alguns atributos muito úteis somente leitura:

Manutenção do Repositório Cold Standby cold-standby-repository-maintenance

Limpeza de revisão revision-clean

O Adobe recomenda executar a manutenção regularmente para evitar o crescimento excessivo do repositório ao longo do tempo. Para executar manualmente a manutenção do repositório de standby frio, siga as etapas abaixo:

Pode demorar mais do que o normal para a instância standby concluir a sincronização com a compactação primária como offline efetivamente reescreve o histórico do repositório, fazendo com que o cálculo das alterações nos repositórios leve mais tempo. Além disso, é de notar que, uma vez concluído esse processo, o tamanho do repositório no standby será basicamente o mesmo tamanho do repositório no principal.

Como alternativa, o repositório principal pode ser copiado para o standby manualmente após executar a compactação no principal, essencialmente reconstruindo o standby sempre que a compactação for executada.

Coleta de lixo do armazenamento de dados data-store-garbage-collection

É importante executar a coleta de lixo nas instâncias do armazenamento de dados de arquivos de vez em quando, caso contrário, os binários excluídos permanecerão no sistema de arquivos, acabando por preencher a unidade. Para executar a coleta de lixo, siga o procedimento abaixo: