Show Menu
TÓPICOS×

Como executar o AEM com TarMK Cold Standby

Introdução

A capacidade de Espera Fria do Tar Micro Kernel permite que uma ou mais instâncias AEM em espera se conectem a uma instância primária. O processo de sincronização é uma forma somente de fazer isso apenas das instâncias primárias às de espera.
A finalidade das instâncias stand-by é garantir uma cópia de dados em tempo real do repositório mestre e garantir um switch rápido sem perda de dados, caso o mestre esteja indisponível por qualquer motivo.
O conteúdo é sincronizado linearmente entre a instância principal e as instâncias stand-by, sem qualquer verificação de integridade para detecção de danos no arquivo ou repositório. Devido a esse design, as instâncias stand-by são cópias exatas da instância principal e não podem ajudar a atenuar inconsistências em instâncias primárias.
O recurso Modo de espera frio é projetado para proteger cenários nos quais é necessária alta disponibilidade em instâncias do autor . Para situações em que a alta disponibilidade é necessária em instâncias de publicação usando o Tar Micro Kernel, a Adobe recomenda usar um farm de publicação.
Para obter informações sobre implantações mais disponíveis, consulte a página Implantações Implantações recomendadas recomendadas.

Como funciona

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 mestre:
  • uma mensagem solicitando a ID do segmento do cabeçalho atual
  • uma mensagem solicitando dados de segmento com uma ID especificada
O modo de espera 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 serão comparados e os segmentos referenciados também serão solicitados, se necessário.
As instâncias em espera não recebem nenhum tipo de solicitação, pois estão sendo executadas no modo somente sincronização. A única seção disponível em uma instância stand-by é o Console da Web, para facilitar a configuração de pacotes e serviços.
Uma implantação típica do TarMK Cold Standby:

Outras características

Robustez

O fluxo de dados é projetado para detectar e lidar automaticamente com problemas relacionados à conexão e à rede. Todos os pacotes são agrupados 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.

Show

A ativação do 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ó primário.

Segurança

Supondo que todas as instâncias ocorrem 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 mestre. Isso reduz a possibilidade de os dados serem comprometidos por um homem no meio.
Além disso, você pode especificar as instâncias stand-by 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.
É recomendável adicionar um balanceador de carga entre o Dispatcher e os servidores que fazem parte da configuração do Coldy Standby. O balanceador de carga deve ser configurado para direcionar o tráfego do usuário somente para a instância principal , a fim de garantir a consistência e impedir que o conteúdo seja copiado na instância stand-by por outros meios que não o mecanismo de modo de espera frio.

Criação de uma configuração de AEM TarMK Cold Standby

O PID para o armazenamento de nó do segmento e o serviço de armazenamento Stand-by foram alterados no AEM 6.3 em comparação com as versões anteriores da seguinte forma:
  • de org.apache.Jackrabbit.oak. plugins .segment.standby.store.StandbyStoreService para org.apache.Jackrabbit.oak.segment.standby.store.StandbyStoreService
  • de org.apache.Jackrabbit.oak. plugins .segment.SegmentNodeStoreService para org.apache.Jackrabbit.oak.segment.SegmentNodeStoreService
Certifique-se de fazer os ajustes de configuração necessários para refletir essa alteração.
Para criar uma configuração TarMK Easy standby, primeiro é necessário criar as instâncias stand-by, executando uma cópia do sistema de arquivos de toda a pasta de instalação do principal em um novo local. Em seguida, você pode iniciar cada instância com um modo de execução que especifique sua função ( primary ou standby ).
Abaixo está o procedimento que precisa ser seguido para criar uma configuração com uma instância mestre e uma instância stand-by:
  1. Instale o AEM.
  2. Encerre a instância e copie a pasta de instalação para o local de onde a instância de espera fria será executada. Mesmo se executado de máquinas diferentes, certifique-se de atribuir um nome descritivo a cada pasta (como aem-Primary ou aem-standby ) para diferenciar entre as instâncias.
  3. Vá para a pasta de instalação da instância principal e:
    1. Verifique e exclua quaisquer configurações OSGi anteriores nas quais você possa ter aem-primary/crx-quickstart/install
    2. Criar uma pasta chamada install.primary em aem-primary/crx-quickstart/install
    3. Crie as configurações necessárias para o armazenamento de nó preferencial e o armazenamento de dados em aem-primary/crx-quickstart/install/install.primary
    4. Crie um arquivo chamado org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config no mesmo local e configure-o de acordo. Para obter mais informações sobre as opções de configuração, consulte Configuração .
    5. Se você estiver usando uma instância do AEM TarMK com um armazenamento de dados externo, crie uma pasta com o nome crx3 em aem-primary/crx-quickstart/install``crx3
    6. Coloque o arquivo de configuração do armazenamento de dados na crx3 pasta. Se, por exemplo, você estiver executando uma instância do AEM TarMK com um File Data Store externo, precisará dos seguintes arquivos de configuração:
    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    • aem-primary/crx-quickstart/install/crx3/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config Abaixo, você encontrará configurações de amostra para a instância principal:
    Amostra de org.apache.Jackrabbit.oak.segment.SegmentNodeStoreService.config
    org.apache.sling.installer.configuration.persist=B"false"
    customBlobStore=B"true"
    standby=B"false"
    
    
    Exemplo de org.apache.Jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    org.apache.sling.installer.configuration.persist=B"false"
    mode="primary"
    port=I"8023"
    
    
    Exemplo de org.apache.Jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
    
  4. Inicie o primário certificando-se de especificar o modo de execução principal:
    java -jar quickstart.jar -r primary,crx3,crx3tar
    
    
  5. Crie um novo Apache Sling Logging Logger para o pacote org.apache.Jackrabbit.oak.segment . Defina o nível de log como "Depurar" e aponte a saída de log para um arquivo de log separado, como /logs/tarmk-coldstandby.log . For more information, see Logging .
  6. Vá para o local da instância standby e inicie-a executando o jar.
  7. Crie a mesma configuração de registro que para o principal. Então, pare a instância.
  8. Em seguida, prepare a instância de espera. É possível fazer isso executando as mesmas etapas da instância primária:
    1. Exclua os arquivos que possam estar em aem-standby/crx-quickstart/install .
    2. Criar uma nova pasta chamada install.standby em aem-standby/crx-quickstart/install
    3. Crie dois arquivos de configuração chamados:
      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    4. Criar uma nova pasta chamada crx3 em aem-standby/crx-quickstart/install
    5. Crie a configuração do armazenamento de dados e coloque-a em aem-standby/crx-quickstart/install/crx3 . Neste exemplo, o arquivo que você precisa criar é:
      • org.apache.Jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
    6. Edite os arquivos e crie as configurações necessárias. Abaixo estão exemplos de arquivos de configuração para uma instância stand-by típica:
    Exemplo de org.apache.Jackrabbit.oak.segment.SegmentNodeStoreService.config
    org.apache.sling.installer.configuration.persist=B"false"
    name="Oak-Tar"
    service.ranking=I"100"
    standby=B"true"
    customBlobStore=B"true"
    
    
    Exemplo de org.apache.Jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    org.apache.sling.installer.configuration.persist=B"false"
    mode="standby"
    primary.host="127.0.0.1"
    port=I"8023"
    secure=B"false"
    interval=I"5"
    standby.autoclean=B"true"
    
    
    Exemplo de org.apache.Jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
    
  9. Inicie a instância standby usando o modo de execução standby:
    java -jar quickstart.jar -r standby,crx3,crx3tar
    
    
O serviço também pode ser configurado por meio do Console da Web:
  1. Ir para o Web Console em: https://serveraddress:serverport/system/console/configMgr
  2. Procurando um serviço chamado Apache Jackrabbit Oak Segment Tar Cold Standby Service e clique duas vezes nele para editar as configurações.
  3. Salvar as configurações e reiniciar as instâncias para que as novas configurações tenham efeito.
Você pode verificar a função de uma instância a qualquer momento verificando a presença dos modos de execução principal ou stand-by no console da Web Sling Settings.
Isso pode ser feito indo até https://localhost:4502/system/console/status-slingsettings e verificando a linha "Modos de execução" .

Primeira sincronização

Depois que a preparação estiver concluída e o modo de espera for iniciado pela primeira vez, haverá um tráfego intenso na rede entre as instâncias, uma vez que o modo de espera atingirá o nível principal. Você pode consultar os registros para observar o status da sincronização.
No standby 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 do standby, 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 primário.
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 registro é a instância standby .
Depois que essas entradas pararem 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 pesquisa está funcionando corretamente, geralmente é ú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 arquivo não compartilhado 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

As seguintes configurações OSGi estão disponíveis para o serviço de Modo de Espera Frio:
  • Configuração persistente: se ativada, a configuração será armazenada no repositório em vez dos arquivos de configuração OSGi tradicionais. É recomendável manter essa configuração desativada nos sistemas de produção para que a configuração primária não seja puxada pelo modo de espera.
  • mode Modo ( ): isso escolherá o modo de execução da instância.
  • Porta (porta): a porta a ser usada para comunicação. O padrão é 8023 .
  • primary.host Host primário ( ): - o host da instância principal. Esta definição só é aplicável ao modo de espera.
  • interval Intervalo de sincronização ( ): - essa configuração determina o intervalo entre a solicitação de sincronização e é aplicável somente para a instância stand-by.
  • primary.allowed-client-ip-ranges Intervalos de IP permitidos ( ): - os intervalos IP dos quais o principal permitirá conexões.
  • secure Seguro ( ): Ative a criptografia SSL. Para usar essa configuração, ela deve estar ativada em todas as instâncias.
  • standby.readtimeout Tempo limite de leitura em espera ( ): Tempo limite para solicitações emitidas da instância stand-by em milissegundos. A configuração de tempo limite recomendada é 43200000. É recomendável definir o tempo limite para um valor de pelo menos 12 horas.
  • standby.autoclean Limpeza automática em espera ( ): Chame o método de limpeza se o tamanho da loja aumentar em um ciclo de sincronização.
É altamente recomendável que o principal e o standby tenham IDs de repositório diferentes para torná-los separadamente identificáveis para serviços como Descarregamento. A melhor maneira de garantir que isso seja abordado é excluindo o arquivo sling.id no modo de espera e reiniciando a instância.

Procedimentos de failover

Se a instância primária falhar por qualquer motivo, você pode definir uma das instâncias stand-by para assumir a função do primário alterando o modo de execução de início, conforme detalhado abaixo:
Os arquivos de configuração também precisam ser modificados para que correspondam às configurações usadas para a instância primária.
  1. Vá para o local onde a instância standby está instalada e pare-a.
  2. Caso tenha um balanceador de carga configurado com a configuração, você pode remover o principal da configuração do balanceador de carga neste ponto.
  3. Faça backup da crx-quickstart pasta da pasta de instalação stand-by. Pode ser usado como ponto de partida ao configurar um novo modo de espera.
  4. Reinicie a instância usando o primary modo de execução:
    java -jar quickstart.jar -r primary,crx3,crx3tar
    
    
  5. Adicione o novo primário ao balanceador de carga.
  6. Crie e inicie uma nova instância stand-by. Para obter mais informações, consulte o procedimento acima em Criar uma configuração AEM TarMK Cold Standby.

Aplicação de hotfixes a uma configuração de espera fria

A maneira recomendada de aplicar hotfixes a uma configuração de espera fria é instalá-los na instância principal e cloná-los em uma nova instância de espera fria com os hotfixes instalados.
Você pode fazer isso seguindo as etapas descritas abaixo:
  1. Pare o processo de sincronização na instância de standby frio indo para o console JMX e usando o **org.apache.Jackrabbit.oak: Status ("Standby")**bean. Para obter mais informações sobre como fazer isso, consulte a seção sobre Monitoramento .
  2. Pare a instância de espera fria.
  3. Instale o hotfix na instância principal. Para obter mais detalhes sobre como instalar uma correção, consulte Como trabalhar com pacotes .
  4. Teste a instância para problemas após a instalação.
  5. Remova a instância de espera fria excluindo sua pasta de instalação.
  6. Pare a instância principal e clone-a executando uma cópia do sistema de arquivos de toda a pasta de instalação para o local do modo de espera frio.
  7. Reconfigure o clone recém-criado para agir como uma instância de espera fria. Para obter detalhes adicionais, consulte Criação de um AEM TarMK Cold Standby.
  8. Inicie as instâncias principal e de espera fria.

Monitoramento

O recurso expõe informações usando JMX ou MBeans. Fazendo isso, você pode inspecionar o estado atual do modo de espera e do master usando o console Monitorando Recursos do Servidor Usando o Console JMX JMX. As informações podem ser encontradas em um MBean type org.apache.jackrabbit.oak:type="Standby" nomeado Status .
Espera
Observando uma instância stand-by, você exporá um nó. Normalmente, a ID é um UUID genérico.
Este nó tem cinco atributos somente leitura:
  • Running: valor booliano que indica se o processo de sincronização está em execução ou não.
  • Mode: Cliente: seguido pela UUID usada para identificar a instância. Observe que essa UUID será alterada sempre que a configuração for atualizada.
  • Status: uma representação textual do estado atual (como running ou stopped ).
  • FailedRequests: o número de erros consecutivos.
  • SecondsSinceLastSuccess: o número de segundos desde a última comunicação bem-sucedida com o servidor. Ele será exibido -1 se nenhuma comunicação for bem-sucedida.
Há também três métodos chamáveis:
  • start(): inicia o processo de sincronização.
  • stop(): interrompe o processo de sincronização.
  • cleanup(): executa a operação de limpeza no modo de espera.
Primário
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 espera TarMK está usando (8023 por padrão). A maioria dos métodos e atributos são os mesmos do modo de espera, mas alguns diferem:
  • Mode: sempre mostrará o valor primary .
Além disso, podem ser obtidas informações para até 10 clientes (instâncias em espera) ligados ao mestre. A ID MBean é o UUID da instância. Não há métodos chamáveis para esses MBeans, mas alguns atributos somente leitura muito úteis:
  • Name: a ID do cliente.
  • LastSeenTimestamp: o carimbo de data e hora da última solicitação em uma representação textual.
  • LastRequest: a última solicitação do cliente.
  • RemoteAddress: o endereço IP do cliente.
  • RemotePort: a porta que o cliente usou para a última solicitação.
  • TransferredSegments: o número total de segmentos transferidos para este cliente.
  • TransferredSegmentBytes: o número total de bytes transferidos para este cliente.

Manutenção do Repositório Standby Frio

Limpeza de revisão

Se você executar a Limpeza de revisão online na instância principal, o procedimento manual apresentado abaixo não é necessário. Além disso, se você estiver usando a Limpeza de revisão on-line, a operação na instância cleanup () em espera será executada automaticamente.
Não execute limpeza de revisão offline no modo de espera. Não é necessário e não reduzirá o tamanho do armazenamento de segmentos.
A 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 em modo de espera frio, siga as etapas abaixo:
  1. Pare o processo de espera na instância stand-by indo para o Console JMX e usando o org.apache.Jackrabbit.oak: Bean de status ("Standby") . Para obter mais informações sobre como fazer isso, consulte a seção acima sobre Monitoramento .
  2. Pare a instância principal do AEM.
  3. Execute a ferramenta de compactação de carvalho na instância principal. Para obter mais detalhes, consulte Manutenção do repositório .
  4. Inicie a instância principal.
  5. Inicie o processo de espera na instância stand-by usando o mesmo bean JMX como descrito na primeira etapa.
  6. Assista aos registros e aguarde a conclusão da sincronização. É possível que, neste momento, se verifique um crescimento substancial no repositório de espera.
  7. Execute a cleanup() operação na instância stand-by, usando o mesmo bean JMX como descrito na primeira etapa.
Pode demorar mais do que o normal para que a instância stand-by conclua a sincronização com a compactação primária como off-line, reescrevendo efetivamente o histórico do repositório, fazendo com que o cálculo das alterações nos repositórios leve mais tempo. É também de notar que, quando esse processo for concluído, o tamanho do repositório no modo de espera será aproximadamente o mesmo tamanho do repositório no principal.
Como alternativa, o repositório principal pode ser copiado manualmente para o modo de espera após executar a compactação no principal, essencialmente reconstruindo o modo de espera sempre que a compactação for executada.

Coleta de lixo do armazenamento de dados

É importante executar a coleta de lixo em instâncias de armazenamento de dados de arquivos de vez em quando, caso contrário, os binários excluídos permanecerão no sistema de arquivos, eventualmente preenchendo a unidade. Para executar a coleta de lixo, siga o procedimento abaixo:
  1. Execute a manutenção do repositório em modo de espera a frio, conforme descrito na seção acima .
  2. Após a conclusão do processo de manutenção e a reinicialização das instâncias:
    • No principal, execute a coleta de lixo do armazenamento de dados por meio do bean JMX relevante, conforme descrito neste artigo .
    • No modo de espera, a coleta de lixo do armazenamento de dados está disponível somente por meio do MBean BlobGarbageCollection - startBlobGC() . O **RepositoryManagement **MBean não está disponível no modo de espera.
    Se você não estiver usando um armazenamento de dados compartilhado, a coleta de lixo terá que ser executada primeiro no primário e depois no modo de espera.