Show Menu
TEMAS×

Tareas de mantenimiento previas a la actualización

Antes de comenzar la actualización, es importante seguir estas tareas de mantenimiento para asegurarse de que el sistema está listo y se puede revertir en caso de que se produzcan problemas:

Asegurar suficiente espacio en disco

Al ejecutar la actualización, además de las actividades de actualización de contenido y código, será necesario realizar una migración de repositorio. La migración creará una copia del repositorio en el nuevo formato de la barra de segmentos. Como resultado, necesitará suficiente espacio en disco para conservar una segunda versión, potencialmente más grande, del repositorio.

Realizar una copia de seguridad completa de AEM

Debe realizarse una copia de seguridad completa de AEM antes de iniciar la actualización. Asegúrese de realizar una copia de seguridad del repositorio, la instalación de la aplicación, el almacén de datos y las instancias de Mongo, si corresponde. Para obtener más información sobre la copia de seguridad y restauración de una instancia de AEM, consulte Copia de seguridad y restauración .

Realizar copia de seguridad de cambios en /etc

El proceso de actualización permite mantener y combinar el contenido y las configuraciones existentes desde debajo de las rutas /apps y /libs del repositorio. Para los cambios realizados en la ruta, incluidas las configuraciones de Context Hub, a menudo es necesario volver a aplicar estos cambios después de la actualización. /etc Aunque la actualización hará una copia de seguridad de los cambios en los que no se puede combinar /var , recomendamos realizar una copia de seguridad de estos cambios manualmente antes de comenzar la actualización.

Generar el archivo quickstart.properties

Al iniciar AEM desde el archivo jar, se generará un quickstart.properties archivo en crx-quickstart/conf . Si AEM solo se ha iniciado con la secuencia de comandos de inicio en el pasado, este archivo no estará presente y la actualización fallará. Asegúrese de comprobar la existencia de este archivo y reinicie AEM desde el archivo jar si no está presente.

Configurar la depuración del flujo de trabajo y del registro de auditoría

Las tareas WorkflowPurgeTask y com.day.cq.audit.impl.AuditLogMaintenanceTask requieren configuraciones OSGi independientes y no funcionarán sin ellas. Si fallan durante la ejecución de tareas previas a la actualización, la razón más probable es que falten configuraciones. Por lo tanto, asegúrese de agregar configuraciones OSGi para estas tareas o de eliminarlas por completo de la lista de tareas de optimización previas a la actualización si no desea ejecutarlas. La documentación para configurar las tareas de depuración de flujo de trabajo se encuentra en Administración de instancias de flujo de trabajo y la configuración de tareas de mantenimiento de registro de auditoría se encuentra en Mantenimiento de registro de auditoría en AEM 6 .
Para depurar el flujo de trabajo y el registro de auditoría en CQ 5.6, así como el registro de auditoría en AEM 6.0, consulte Depuración del flujo de trabajo y los nodos de auditoría.

Instalar, configurar y ejecutar las tareas previas a la actualización

Debido al nivel de personalización que AEM permite, los entornos no suelen seguir una forma uniforme de realizar actualizaciones. Esto dificulta la creación de un procedimiento estandarizado para las actualizaciones.
En versiones anteriores, también resultaba difícil realizar actualizaciones de AEM que se detuvieran o que no se reanudaran de forma segura. Esto daba lugar a situaciones en las que era necesario reiniciar el procedimiento completo de actualización o en las que se realizaban actualizaciones defectuosas sin activar ninguna advertencia.
Para solucionar estos problemas, Adobe ha añadido varias mejoras al proceso de actualización, lo que lo hace más flexible y fácil de usar. Las tareas de mantenimiento previas a la actualización que antes debían realizarse manualmente se están optimizando y automatizando. Además, se han agregado informes posteriores a la actualización para que el proceso pueda analizarse a fondo con la esperanza de encontrar cualquier problema más fácilmente.
Las tareas de mantenimiento previas a la actualización se distribuyen actualmente en varias interfaces que se realizan de forma manual o parcial. La optimización de mantenimiento previa a la actualización introducida en AEM 6.3 permite activar estas tareas de forma unificada y poder inspeccionar sus resultados según sea necesario.
Todas las tareas incluidas en el paso de optimización previo a la actualización son compatibles con todas las versiones de AEM 6.0 y posteriores.

Cómo configurarlo

En AEM 6.3 y versiones posteriores, las tareas de optimización de mantenimiento previas a la actualización se incluyen en el tarro de inicio rápido. Si va a realizar la actualización desde una versión anterior de AEM 6, estará disponible mediante paquetes independientes que puede descargar desde el Administrador de paquetes.
Puede encontrar los paquetes en estas ubicaciones:

How to Use It

El componente PreUpgradeTasksMBean OSGI viene preconfigurado con una lista de tareas de mantenimiento previas a la actualización que se pueden ejecutar de una vez. Puede configurar las tareas siguiendo el procedimiento siguiente:
  1. Vaya a la consola web navegando a https://serveraddress:serverport/system/console/configMgr
  2. Busque " preupgradeTasks " y, a continuación, haga clic en el primer componente coincidente. El nombre completo del componente es com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
  3. Modifique la lista de tareas de mantenimiento que deben ejecutarse como se muestra a continuación:
La lista de tareas varía según el modo de ejecución que se esté utilizando para iniciar la instancia. A continuación se muestra una descripción del modo de ejecución para el que está diseñada cada tarea de mantenimiento.
Tarea Modo de ejecución Notas
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 Se ejecutará mark y sweep. Para los almacenes de datos compartidos, elimine este paso y ejecute manualmente o correctamente las instancias antes de ejecutarlas.
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 Debe configurar el OSGi de configuración de purga de flujo de trabajo de Adobe Granite antes de ejecutarse.
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 Para las instancias de TarMK en AEM 6.0 a 6.2, ejecute manualmente la limpieza de revisión sin conexión en su lugar.
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 Debe configurar OSGi del programador de depuración de registros de auditoría antes de ejecutar.
DataStoreGarbageCollectionTask llama a una operación de recolección de elementos no utilizados del almacén de datos con la fase de marca y barrido si se utiliza. Para implementaciones que utilizan un almacén de datos compartido, asegúrese de volver a configurarlo o bien de preparar la instancia para evitar la eliminación de elementos a los que hace referencia otra instancia. Esto puede requerir ejecutar la fase de marca manualmente en todas las instancias antes de activar esta tarea previa a la actualización.

Configuración predeterminada de las comprobaciones de estado previas a la actualización

El componente PreUpgradeTasksMBeanImpl OSGI viene preconfigurado con una lista de etiquetas de comprobación de estado previas a la actualización para ejecutarse cuando se llame al runAllPreUpgradeHealthChecks método:
  • sistema : la etiqueta utilizada por las comprobaciones de mantenimiento de granito
  • actualización previa: es una etiqueta personalizada que se puede agregar a todas las comprobaciones de estado que se pueden configurar para que se ejecuten antes de una actualización
La lista es editable. Puede utilizar los botones más (+) y menos (-) además de las etiquetas para agregar más etiquetas personalizadas o quitar las predeterminadas.
Métodos MBean
Se puede acceder a la funcionalidad de granos administrados mediante la consola JMX .
Puede acceder a los MBeans mediante:
  1. Ir a la consola de JMX en https://serveraddress:serverport/system/console/jmx
  2. Busque PreUpgradeTasks y haga clic en el resultado
  3. Seleccione cualquier método en la sección Operaciones y seleccione Invocar en la siguiente ventana.
A continuación se muestra una lista de todos los métodos disponibles que PreUpgradeTasksMBeanImpl expone:
Nombre del método Tipo Descripción
getAvailablePreUpgradeTasksNames() INFORMACIÓN Muestra la lista de nombres de tareas de mantenimiento previas a la actualización disponibles.
getAvailablePreUpgradeHealthChecksTagNames() INFORMACIÓN Muestra la lista de nombres de etiquetas de comprobación de mantenimiento previa a la actualización.
runAllPreUpgradeTasks() ACCIÓN Ejecuta todas las tareas de mantenimiento previas a la actualización en la lista.
runPreUpgradeTask(preUpgradeTaskName) ACCIÓN Ejecuta la tarea de mantenimiento previa a la actualización con el nombre proporcionado como parámetro.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Comprueba si la runAllPreUpgradeTasksmaintenance tarea se está ejecutando.
getAnyPreUpgradeTaskRunning() ACTION_INFO Comprueba si se está ejecutando una tarea de mantenimiento previa a la actualización y devuelve una matriz que contiene los nombres de las tareas que se están ejecutando.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) ACCIÓN Muestra el tiempo de ejecución exacto de la tarea de mantenimiento previa a la actualización con el nombre dado como parámetro.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) ACCIÓN Muestra el último estado de ejecución de la tarea de mantenimiento previa a la actualización con el nombre dado como parámetro.
runAllPreUpgradeHealthChecks(shutDownOnSuccess) ACCIÓN
Ejecuta todas las comprobaciones de estado previas a la actualización y guarda su estado en un archivo denominado preUpgradeHCStatus.properties que se encuentra en la ruta de inicio de sling. Si el shutDownOnSuccess parámetro está establecido en true , la instancia de AEM se cerrará, pero solo si todas las comprobaciones de estado previas a la actualización tienen el estado OK.
El archivo de propiedades se utilizará como condición previa para cualquier actualización futura y el proceso de actualización se detendrá si falla la ejecución de la comprobación de estado previa a la actualización. Si desea ignorar el resultado de las comprobaciones de estado previas a la actualización e iniciar la actualización de todos modos, puede eliminar el archivo.
detectUsageOfUnavailableAPI(aemVersion) ACCIÓN Enumera todos los paquetes importados que ya no se satisfarán al actualizar a la versión de AEM especificada. La versión de AEM de destino debe proporcionarse como parámetro.
Los métodos MBean se pueden invocar mediante:
  • La consola JMX
  • Cualquier aplicación externa que se conecte a JMX
  • cURL

Deshabilitar los módulos de inicio de sesión personalizados

Este paso solo es necesario si va a realizar la actualización desde una versión de AEM 5. Se puede omitir completamente para las actualizaciones de versiones anteriores de AEM 6.
La forma en que LoginModules se configuran los valores personalizados para la autenticación a nivel de repositorio ha cambiado fundamentalmente en Apache Oak.
En las versiones de AEM que utilizaban la configuración de CRX2 se colocaba en el repository.xml archivo, mientras que a partir de AEM 6 se realiza en el servicio de fábrica de configuración de Apache Felix JAAS a través de la consola web.
Por lo tanto, cualquier configuración existente tendrá que deshabilitarse y volverse a crear para Apache Oak después de la actualización.
Para deshabilitar los módulos personalizados definidos en la configuración de JAAS de repository.xml , debe modificar la configuración para utilizar el valor predeterminado LoginModule , como en este ejemplo:
<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>

Para obtener más información, consulte Autenticación con el módulo de inicio de sesión externo.
Para ver un ejemplo de LoginModule configuración en AEM 6, consulte Configuración de LDAP con AEM 6 .

Quitar Actualizaciones Del Directorio /install

Sólo elimine paquetes del directorio crx-quickstart/install DESPUÉS de cerrar la instancia de AEM. Este será uno de los últimos pasos antes de iniciar el procedimiento de actualización in situ.
Elimine todos los paquetes de servicios, paquetes de funciones o revisiones que se hayan implementado a través del crx-quickstart/install directorio en el sistema de archivos local. Esto evitará la instalación involuntaria de revisiones y Service Packs antiguos además de la nueva versión de AEM una vez completada la actualización.

Detener Cualquier Instancia En Espera En Frío

Si utiliza TarMK en espera fría, detenga las instancias en espera en frío. Esto garantizará una manera eficiente de volver a conectarse en caso de problemas en la actualización. Una vez que la actualización se haya completado correctamente, las instancias en espera en frío deberán reconstruirse a partir de las instancias primarias actualizadas.

Deshabilitar trabajos programados personalizados

Deshabilite los trabajos programados de OSGi que estén incluidos en el código de la aplicación.

Ejecutar limpieza de revisión sin conexión

Este paso solo es necesario para las instalaciones TarMK
Si utiliza TarMK, debe ejecutar la limpieza de revisión sin conexión antes de la actualización. Esto hará que el paso de migración del repositorio y las tareas de actualización subsiguientes se ejecuten mucho más rápido y ayudará a garantizar que la limpieza de revisión en línea se pueda ejecutar correctamente una vez completada la actualización. Para obtener más información sobre cómo ejecutar la limpieza de revisiones sin conexión, consulte Realización de la limpieza de revisiones sin conexión.

Ejecutar recopilación de elementos no utilizados del almacén de datos

Este paso solo es necesario para instancias que ejecutan crx3
Después de ejecutar la limpieza de revisión en instancias de CRX3, debe ejecutar la recopilación de elementos no utilizados del almacén de datos para eliminar los blobs no referenciados del almacén de datos. Para obtener instrucciones, consulte la documentación sobre la recopilación de elementos no utilizados del almacén de datos.

Actualizar el esquema de base de datos si es necesario

Normalmente, la pila Apache Oak subyacente que AEM utiliza para mantener se encargará de actualizar el esquema de la base de datos si es necesario.
Sin embargo, pueden surgir casos cuando el esquema no se puede actualizar automáticamente. Son entornos de alta seguridad donde la base de datos se ejecuta bajo un usuario con privilegios muy limitados. Si esto sucede, AEM seguirá utilizando el esquema antiguo.
Para evitar que esto ocurra, debe actualizar el esquema siguiendo el procedimiento siguiente:
  1. Cierre la instancia de AEM que debe actualizarse.
  2. Actualice el esquema de base de datos. Consulte la documentación de su tipo de base de datos para ver cuál es la herramienta que necesita utilizar para conseguirlo.
    Para obtener más información sobre cómo Oak gestiona las actualizaciones de esquema, consulte esta página en el sitio web de Apache.
  3. Continúe con la actualización de AEM.

Eliminar usuarios que podrían obstaculizar la actualización

Esta tarea de mantenimiento previa a la actualización solo es necesaria si:
  • Está actualizando desde versiones de AEM anteriores a AEM 6.3
  • Durante la actualización se produce cualquiera de los errores mencionados a continuación.
Hay casos excepcionales en los que los usuarios de servicios pueden terminar etiquetándose incorrectamente como usuarios habituales en versiones anteriores de AEM.
Si esto sucede, la actualización fallará con un mensaje como este:
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 solucionar este problema, asegúrese de hacer lo siguiente:
  1. Desasociar la instancia del tráfico de producción
  2. Cree una copia de seguridad de los usuarios que ocasionan el problema. Puede hacerlo a través del Administrador de paquetes. Para obtener más información, consulte Cómo trabajar con paquetes.
  3. Elimine los usuarios que ocasionan el problema. A continuación se muestra una lista de los usuarios que podrían incluirse en esta categoría:
    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

Rotar archivos de registro

Se recomienda archivar los archivos de registro actuales antes de comenzar la actualización. Esto facilitará la supervisión y exploración de los archivos de registro durante y después de la actualización para identificar y resolver cualquier problema que pueda producirse.