Tarefas de Manutenção de Pré-Atualização pre-upgrade-maintenance-tasks

Antes de iniciar a atualização, é importante seguir estas tarefas de manutenção para garantir que o sistema esteja pronto e possa ser revertido caso ocorram problemas:

Garantir espaço suficiente em disco ensure-sufficient-disk-space

Ao executar a atualização, além das atividades de atualização de conteúdo e código, uma migração de repositório deve ser executada. A migração cria uma cópia do repositório no novo formato TAR de segmento. Como resultado, é necessário espaço em disco suficiente para manter uma segunda versão do repositório, possivelmente maior.

Fazer backup completo do AEM fully-back-up-aem

O AEM deve ter backup completo antes de iniciar a atualização. Faça backup do repositório, da instalação do aplicativo, do armazenamento de dados e das instâncias Mongo, se aplicável. Para obter mais informações sobre como fazer backup e restaurar uma instância do AEM, consulte Backup e restauração.

Fazer backup de alterações em /etc backup-changes-etc

O processo de atualização faz um bom trabalho ao manter e mesclar o conteúdo e as configurações existentes no /apps e /libs caminhos no repositório. Para alterações feitas no /etc incluindo as configurações do Context Hub, geralmente é necessário reaplicar essas alterações após a atualização. Embora a atualização faça uma cópia de backup de qualquer alteração que não possa ser mesclada no /var, o Adobe recomenda que você faça o backup dessas alterações manualmente antes de iniciar a atualização.

Gerar o arquivo quickstart.properties generate-quickstart-properties

Ao iniciar o AEM a partir do arquivo jar, uma variável quickstart.properties o arquivo é gerado em crx-quickstart/conf. Se o AEM tiver sido iniciado apenas com o script de inicialização no passado, esse arquivo não estará presente e a atualização falhará. Verifique a existência desse arquivo e reinicie o AEM a partir do arquivo jar, se ele não estiver presente.

Configurar a limpeza do fluxo de trabalho e do log de auditoria configure-wf-audit-purging

A variável WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask As tarefas do exigem configurações OSGi separadas e não podem funcionar sem elas. Se eles falharem durante a execução da tarefa de pré-atualização, a falta de configurações será o motivo mais provável. Portanto, adicione configurações OSGi para essas tarefas ou remova-as completamente da lista de tarefas de otimização de pré-atualização se não quiser executá-las. A documentação para configurar as tarefas de limpeza de fluxo de trabalho pode ser encontrada em Administração de instâncias de fluxo de trabalho e a configuração da tarefa de manutenção de log de auditoria podem ser encontradas em Manutenção do registro de auditoria no AEM 6.

Para limpeza de fluxo de trabalho e log de auditoria no CQ 5.6 e limpeza de log de auditoria no AEM 6.0, consulte Limpar fluxo de trabalho e nós de auditoria.

Instalar, Configurar e Executar as Tarefas de Pré-Atualização install-configure-run-pre-upgrade-tasks

Devido ao nível de personalização permitido pelo AEM, os ambientes geralmente não seguem uma maneira uniforme de executar atualizações. Assim, a criação de um procedimento padronizado para atualizações é um processo difícil.

Em versões anteriores, também era difícil para atualizações de AEM que eram interrompidas ou que não eram retomadas com segurança. Esse problema levou a situações em que era necessário reiniciar o procedimento de atualização completo ou em que atualizações com defeito eram realizadas sem disparar avisos.

Para resolver esses problemas, o Adobe adicionou vários aprimoramentos ao processo de atualização, tornando-o mais resiliente e fácil de usar. As tarefas de manutenção pré-atualização que antes tinham de ser realizadas manualmente estão sendo otimizadas e automatizadas. Além disso, foram adicionados relatórios pós-atualização para que o processo possa ser totalmente analisado, na esperança de que quaisquer problemas sejam encontrados mais facilmente.

Atualmente, as tarefas de manutenção pré-atualização estão distribuídas por várias interfaces que são parcial ou totalmente executadas manualmente. A otimização de manutenção de pré-atualização introduzida no AEM 6.3 permite uma maneira unificada de acionar essas tarefas e inspecionar seus resultados sob demanda.

Todas as tarefas incluídas na etapa de otimização de pré-atualização são compatíveis com todas as versões do AEM 6.0 em diante.

Como configurar how-to-set-it-up

No AEM 6.3 e versões posteriores, as tarefas de otimização de manutenção de pré-atualização são incluídas no jar de início rápido.

Como usá-lo how-to-use-it

A variável PreUpgradeTasksMBean O componente OSGI vem pré-configurado com uma lista de tarefas de manutenção de pré-atualização que podem ser executadas todas de uma vez. Você pode configurar as tarefas seguindo o procedimento abaixo:

  1. Acesse o Console da Web navegando até https://serveraddress:serverport/system/console/configMgr

  2. Pesquisar por "tarefas de pré-atualização", em seguida, clique no primeiro componente correspondente. O nome completo do componente é com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. Modifique a lista de tarefas de manutenção que devem ser executadas conforme mostrado abaixo:

    1487758925984

A lista de tarefas difere dependendo do modo de execução que está sendo usado para iniciar a instância. Abaixo está uma descrição do modo de execução para o qual cada tarefa de manutenção foi projetada.

Tarefa
Modo de execução
Notas
TarIndexMergeTask
crx2
DataStoreGarbageCollectionTask
crx2
Executa a marcação e a varredura. Para armazenamentos de dados compartilhados, remova esta etapa e execute
preparar instâncias manualmente ou corretamente antes da execução.
ConsistencyCheckTask
crx2
WorkflowPurgeTask
crx2/crx3
É necessário configurar o OSGi de configuração de limpeza de fluxo de trabalho do Adobe Granite antes de executar.
GenerateBundlesListFileTask
crx2/crx3
RevisionCleanupTask
crx3
Para instâncias TarMK no AEM 6.0 para 6.2, execute manualmente a Limpeza de revisão offline.
com.day.cq.audit.impl.AuditLogMaintenanceTask
crx3
É necessário definir a configuração OSGi do Agendador de limpeza de log de auditoria antes de executar.
CAUTION
A variável DataStoreGarbageCollectionTask chama uma operação de Coleta de Lixo do Datastore com a fase de marcação e varredura, se usada. Para implantações que usam um armazenamento de dados compartilhado, reconfigure-o corretamente ou prepare a instância para evitar a exclusão de itens referenciados por outra instância. Esse processo pode exigir a execução da fase de marcação manualmente em todas as instâncias antes de acionar essa tarefa de pré-atualização.

Configuração padrão das verificações de integridade de pré-atualização default-configuration-of-the-pre-upgrade-health-checks

A variável PreUpgradeTasksMBeanImpl O componente OSGI vem pré-configurado com uma lista de tags de verificação de integridade de pré-atualização para serem executadas quando o runAllPreUpgradeHealthChecks o método é chamado:

  • sistema - a tag usada pelas verificações de integridade de manutenção do granite

  • pré-atualização - uma tag personalizada que pode ser adicionada a todas as verificações de integridade que você pode definir para executar antes de uma atualização

A lista é editável. Você pode usar o sinal de mais (+) e menos (-) além das tags, para adicionar mais tags personalizadas ou remover as padrão.

Métodos MBean

A funcionalidade do bean gerenciado pode ser acessada usando o Console JMX.

Você pode acessar os MBeans ao:

  1. Indo para o console JMX em https://serveraddress:serverport/system/console/jmx

  2. Pesquisar por TarefasDePré-Atualização e clique no resultado

  3. Selecione qualquer método no Operações e selecione Chamar na janela a seguir.

Abaixo está uma lista de todos os métodos disponíveis que o PreUpgradeTasksMBeanImpl expõe:

Nome do método
Tipo
Descrição
getAvailablePreUpgradeTasksNames()
INFO
Exibe a lista de nomes de tarefas de manutenção de pré-atualização disponíveis.
getAvailablePreUpgradeHealthChecksTagNames()
INFO
Exibe a lista dos nomes das tags de verificação de integridade pré-atualização.
runAllPreUpgradeTasks()
AÇÃO
Executa todas as tarefas de manutenção de pré-atualização da lista.
runPreUpgradeTask(preUpgradeTaskName)
AÇÃO
Executa a tarefa de manutenção de pré-atualização com o nome fornecido como o parâmetro.
isRunAllPreUpgradeTaskRunning()
ACTION_INFO
Verifica se runAllPreUpgradeTasksmaintenance tarefa em execução.
getAnyPreUpgradeTaskRunning()
ACTION_INFO
Verifica se alguma tarefa de manutenção de pré-atualização está em execução e
retorna uma matriz contendo os nomes das tarefas em execução no momento.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName)
AÇÃO
Exibe o tempo de execução exato da tarefa de manutenção de pré-atualização com o nome fornecido como parâmetro.
getPreUpgradeTaskLastRunState(preUpgradeTaskName)
AÇÃO
Exibe o último estado de execução da tarefa de manutenção de pré-atualização com o nome fornecido como o parâmetro.
runAllPreUpgradeHealthChecks(shutDownOnSuccess)
AÇÃO

Executa todas as verificações de integridade anteriores à atualização e salva seu status em um arquivo chamado preUpgradeHCStatus.properties que está no caminho do sling home. Se a variável shutDownOnSuccess está definido como true, a instância do AEM será desligada, mas somente se todas as verificações de integridade anteriores à atualização tiverem um status OK.

O arquivo de propriedades é usado como uma pré-condição para qualquer atualização futura
e o processo de atualização será interrompido se a verificação de integridade pré-atualização
falha na execução. Se quiser ignorar o resultado da pré-atualização
e iniciar a atualização de qualquer maneira, você poderá excluir o arquivo.

detectUsageOfUnavailableAPI(aemVersion)
AÇÃO
Lista todos os pacotes importados que não são mais satisfeitos quando
atualização para a versão do AEM especificada. A versão do AEM de destino deve ser
fornecido como parâmetro.
NOTE
Os métodos MBean podem ser chamados por meio de:
  • A console JMX
  • Qualquer aplicativo externo que se conecta ao JMX
  • cURL

Desativar módulos de logon personalizados disable-custom-login-modules

NOTE
Esta etapa só é necessária se você estiver atualizando de uma versão AEM 5. Ele pode ser ignorado totalmente para atualizações de versões mais antigas do AEM 6.

A forma como o LoginModules estão configurados para autenticação no nível do repositório e foram alterados basicamente no Apache Oak.

Em versões do AEM que usavam a configuração CRX2, ela era colocada no estado repository.xml arquivo, enquanto a partir do AEM 6 ele é feito no serviço Apache Felix JAAS Configuration Fatory através do console da Web.

Portanto, todas as configurações existentes precisarão ser desativadas e recriadas para o Apache Oak após a atualização.

Para desativar os módulos personalizados definidos na configuração JAAS de repository.xml, você deverá editar a configuração para usar o padrão LoginModule, como no exemplo a seguir:

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>
NOTE
Para obter mais informações, consulte Autenticação com o módulo de logon externo.
Para obter um exemplo de LoginModule no AEM 6, consulte Configuração do LDAP com AEM 6.

Remover Atualizações Do Diretório /install remove-updates-install-directory

NOTE
Remova os pacotes somente do diretório crx-quickstart/install DEPOIS de desligar a instância AEM. Esta etapa é uma das últimas antes de iniciar o procedimento de atualização no local.

Remova service packs, pacotes de recursos ou hotfixes que foram implantados por meio do crx-quickstart/install no sistema de arquivos local. Isso impede a instalação inadvertida de hotfixes e service packs antigos sobre a nova versão do AEM após a conclusão da atualização.

Interromper Quaisquer Instâncias De Modo De Espera Por Frio stop-tarmk-coldstandby-instance

Se estiver usando a espera a frio do TarMK, interrompa todas as instâncias a frio da espera. Isso garante uma maneira eficiente de voltar a ficar online em caso de problemas na atualização. Depois que o upgrade for concluído com sucesso, as instâncias off-line deverão ser recriadas a partir das instâncias principais atualizadas.

Desabilitar Trabalhos Agendados Personalizados disable-custom-scheduled-jobs

Desative todos os trabalhos agendados OSGi incluídos no código do aplicativo.

Executar limpeza de revisão offline execute-offline-revision-cleanup

NOTE
Esta etapa só é necessária para instalações TarMK

Se estiver usando TarMK, você deve executar a Limpeza de revisão offline antes da atualização. Isso torna a etapa de migração do repositório e as tarefas de atualização subsequentes muito mais rápidas e ajuda a garantir que a Limpeza de revisão online possa ser executada com êxito após a conclusão da atualização. Para obter informações sobre como executar a Limpeza de revisão offline, consulte Execução de limpeza de revisão offline.

Executar coleta de lixo do armazenamento de dados execute-datastore-garbage-collection

NOTE
Esta etapa só é necessária para instâncias que executam o crx3

Depois de executar a limpeza de revisão nas instâncias do CRX3, você deve executar a Coleta de lixo do armazenamento de dados para remover todos os blobs não referenciados no armazenamento de dados. Para obter instruções, consulte a documentação em Coleta de lixo do armazenamento de dados.

Fazer Upgrade do Esquema de Banco de Dados, Se Necessário upgrade-the-database-schema-if-needed

Normalmente, a pilha subjacente do Apache Oak que o AEM usa para persistência cuida da atualização do esquema do banco de dados, se necessário.

No entanto, podem surgir casos em que o esquema não pode ser atualizado automaticamente. Esses casos são, em sua maioria, ambientes de alta segurança nos quais o banco de dados é executado sob um usuário com privilégios limitados. Se tal situação ocorrer, o AEM continuará a usar o esquema antigo.

Para evitar que esse cenário aconteça, atualize o esquema fazendo o seguinte:

  1. Desligue a instância do AEM que deve ser atualizada.

  2. Atualize o esquema do banco de dados. Consulte a documentação do tipo de banco de dados para ver quais ferramentas são necessárias para obter o resultado.

    Para obter mais informações sobre como o Oak lida com atualizações de esquema, consulte esta página no site do Apache.

  3. Continue atualizando o AEM.

Excluir usuários que podem dificultar a atualização delete-users-that-might-hinder-the-upgrade

NOTE
Essa tarefa de manutenção pré-atualização só será necessária se:
  • Você está atualizando de versões do AEM anteriores ao AEM 6.3
  • Você encontra qualquer um dos erros mencionados abaixo durante a atualização.

Há casos excepcionais em que os usuários de serviço podem acabar sendo marcados incorretamente como usuários regulares em uma versão mais antiga do AEM.

Se tal situação ocorrer, a atualização falhará com uma mensagem como a seguinte:

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

Para contornar esse problema, faça o seguinte:

  1. Desanexar a instância do tráfego de produção

  2. Crie um backup de um ou mais usuários que causam o problema. Você pode fazer essa tarefa por meio do Gerenciador de pacotes. Para obter mais informações, consulte Como trabalhar com pacotes.

  3. Exclua um ou mais usuários que estão causando o problema. Veja abaixo uma lista de usuários que podem se enquadrar nesta categoria:

    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

Girar arquivos de registro rotate-log-files

O Adobe recomenda arquivar seus arquivos de log atuais antes de iniciar a atualização. Isso facilita a monitoração e a varredura dos arquivos de registro durante e após a atualização para identificar e resolver quaisquer problemas que possam ocorrer.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2