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 si se producen problemas:

Garantizar 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 del repositorio. La migración creará una copia del repositorio en el nuevo formato Segment Tar . Como resultado, necesitará suficiente espacio en disco para conservar una segunda versión, potencialmente más grande, del repositorio.

AEM de copia de seguridad completa

AEM debe realizar una copia de seguridad completa antes de comenzar 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 cómo realizar copias de seguridad y restaurar una instancia de AEM, consulte Copia de seguridad y restauración.

Haga una copia de seguridad de los cambios en /etc

El proceso de actualización realiza un buen trabajo al mantener y combinar el contenido y las configuraciones existentes desde el /apps y /libs rutas en el repositorio. Para los cambios realizados en la variable /etc , incluidas las configuraciones de Context Hub, a menudo es necesario volver a aplicar estos cambios después de la actualización. Mientras la actualización realiza 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, una quickstart.properties se generará en crx-quickstart/conf. Si AEM se ha iniciado con el script 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 el flujo de trabajo y la depuración del registro de auditoría

La variable WorkflowPurgeTask y com.day.cq.audit.impl.AuditLogMaintenanceTask las tareas 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 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 flujos de trabajo se encuentra en Administración de instancias de flujo de trabajo y la configuración de la tarea de mantenimiento del registro de auditoría se encuentra en Mantenimiento del registro de auditoría en AEM 6.

Para ver el flujo de trabajo y el registro de auditoría purgando en CQ 5.6, así como el registro de auditoría purgando en AEM 6.0, consulte Purga del flujo de trabajo y los nodos de auditoría.

Instalación, configuración y ejecución de las tareas previas a la actualización

Debido al nivel de personalización que AEM permite, los entornos no suelen adherirse a 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 AEM que se detuvieron o que no se reanudaron de forma segura. Esto llevaba a situaciones en las que era necesario reiniciar el procedimiento de actualización completo 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 tenían que realizarse manualmente se están optimizando y automatizando. Además, se han añadido informes posteriores a la actualización para que el proceso pueda examinarse en profundidad con la esperanza de que se encuentren más fácilmente todos los problemas.

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 una forma unificada de déclencheur de estas tareas y poder inspeccionar su resultado bajo demanda.

Todas las tareas incluidas en el paso de optimización previo a la actualización son compatibles con todas las versiones a partir de AEM 6.0.

Cómo configurarlo

En AEM 6.3 y posteriores, las tareas de optimización de mantenimiento previas a la actualización se incluyen en el jar de inicio rápido. Si está actualizando desde una versión anterior de AEM 6, están disponibles a través de paquetes separados que puede descargar desde el Administrador de paquetes.

Puede encontrar los paquetes en estas ubicaciones:

Cómo utilizarlo

La variable PreUpgradeTasksMBean El componente OSGI viene preconfigurado con una lista de tareas de mantenimiento previas a la actualización que se pueden ejecutar todas a la vez. Puede configurar las tareas siguiendo el procedimiento siguiente:

  1. Vaya a la consola web navegando hasta https://serveraddress:serverport/system/console/configMgr

  2. Buscar "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:

    1487758925984

La lista de tareas difiere 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 se ha diseñado cada tarea de mantenimiento.

Tarea Modo de ejecución Notas
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 Ejecutará mark y sweep. Para los almacenes de datos compartidos, elimine este paso y ejecute
prepare las instancias de forma manual o correcta antes de ejecutarlas.
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 Debe configurar el OSGi de configuración de purga del flujo de trabajo de Granite de Adobe antes de ejecutarse.
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 En el caso de instancias de TarMK de 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 la configuración OSGi del Programador de purga de registros de auditoría antes de ejecutar.
PRECAUCIÓN

DataStoreGarbageCollectionTask llama a una operación de colección de residuos 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 reconfigurarlo o de preparar correctamente la instancia para evitar la eliminación de elementos a los que hace referencia otra instancia. Esto puede requerir la ejecución manual de la fase de marca en todas las instancias antes de activar esta tarea de preactualización.

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

La variable PreUpgradeTasksMBeanImpl El componente OSGI viene preconfigurado con una lista de etiquetas de comprobación de estado previas a la actualización para ejecutarse cuando el runAllPreUpgradeHealthChecks se llama método:

  • sistema - la etiqueta utilizada por los controles de mantenimiento de granito

  • actualización previa - esta es una etiqueta personalizada que podría agregarse a todas las comprobaciones de estado que puede configurar para ejecutar antes de una actualización

La lista es editable. Puede utilizar el signo 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 bean administrado mediante la variable Consola JMX.

Puede acceder a los MBeans mediante:

  1. Ir a la consola JMX en https://serveraddress:serverport/system/console/jmx

  2. Buscar PreUpgradeTasks y haga clic en el resultado

  3. Seleccione cualquier método de Operaciones y seleccione Invocar en la siguiente ventana.

A continuación se muestra una lista de todos los métodos disponibles que la variable 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 comprobaciones de estado previas 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 dado como parámetro.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Comprueba si la variable runAllPreUpgradeTasksmaintenance está ejecutándose la tarea.
getAnyPreUpgradeTaskRunning() ACTION_INFO Comprueba si hay alguna tarea de mantenimiento previa a la actualización actualmente en ejecución y
devuelve una matriz que contiene los nombres de las tareas que se están ejecutando actualmente.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) ACCIÓN Muestra el tiempo de ejecución exacto de la tarea de mantenimiento anterior a la actualización con el nombre dado como parámetro.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) ACCIÓN Muestra el último estado en ejecución de la tarea de mantenimiento anterior 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 principal de sling. Si la variable shutDownOnSuccess se establece 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 se realiza la comprobación de estado previa a la actualización
error de ejecución. Si desea ignorar el resultado de la actualización previa
comprueba el estado e inicia 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 cuando
actualizando a la versión de AEM especificada. La versión de AEM de destino debe ser
dado como parámetro.
NOTA

Los métodos MBean se pueden invocar mediante:

  • La consola JMX
  • Cualquier aplicación externa que se conecte a JMX
  • cURL

Desactivar módulos de inicio de sesión personalizados

NOTA

Este paso solo es necesario si está actualizando desde una versión AEM 5. Se puede omitir por completo para las actualizaciones de versiones anteriores AEM 6.

El modo personalizado LoginModules están configurados para la autenticación a nivel de repositorio ha cambiado fundamentalmente en Apache Oak.

En AEM versiones que usaban la configuración CRX2 se colocaron en la variable repository.xml , mientras que a partir de AEM 6 se hace en el servicio Apache Felix JAAS Configuration Factory a través de la Consola Web.

Por lo tanto, cualquier configuración existente tendrá que ser deshabilitada y recreada para Apache Oak después de la actualización.

Para desactivar 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>
NOTA

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

NOTA

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 cualquier paquete de servicio, paquete de características o revisión que se haya implementado a través de la crx-quickstart/install en el sistema de archivos local. Esto evitará la instalación involuntaria de revisiones y service packs antiguos sobre la nueva versión de AEM una vez finalizada la actualización.

Detener Cualquier Instancia En Espera Fría

Si utiliza el modo de espera en frío TarMK, detenga las instancias en espera en frío. Esto garantizará una forma eficaz 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 principales actualizadas.

Desactivar trabajos programados personalizados

Deshabilite cualquier trabajo programado de OSGi que esté incluido en el código de la aplicación.

Ejecutar limpieza de revisión sin conexión

NOTA

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 información sobre cómo ejecutar la limpieza de revisión sin conexión, consulte Realización de limpieza de revisión sin conexión.

Ejecutar colección de residuos del almacén de datos

NOTA

Este paso solo es necesario para instancias que ejecutan crx3

Después de ejecutar la limpieza de revisión en instancias CRX3, debe ejecutar la Colección de residuos del almacén de datos para eliminar cualquier blobs no referenciado en el almacén de datos. Para obtener instrucciones, consulte la documentación de Colección de residuos del almacén de datos.

Actualizar el esquema de base de datos si es necesario

Normalmente, la pila subyacente de Apache Oak que utiliza AEM para la persistencia se encargará de actualizar el esquema de la base de datos si es necesario.

Sin embargo, pueden surgir casos en los que el esquema no se pueda actualizar automáticamente. Estos son, en su mayoría, entornos de alta seguridad en los que 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 siguiente procedimiento:

  1. Apague la instancia de AEM que debe actualizarse.

  2. Actualice el esquema de la base de datos. Consulte la documentación del tipo de base de datos para ver qué herramientas 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 AEM de actualización.

Eliminar usuarios que podrían obstaculizar la actualización

NOTA

Esta tarea de mantenimiento previa a la actualización solo es necesaria si:

  • Está actualizando desde AEM versiones anteriores a AEM 6.3
  • Se encuentra con cualquiera de los errores mencionados a continuación durante la actualización.

Hay casos excepcionales en los que los usuarios de servicios podrían terminar en versiones de AEM antiguas etiquetadas incorrectamente como usuarios normales.

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 causen 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 están causando el problema. A continuación se muestra una lista de usuarios que podrían pertenecer a 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 el análisis de los archivos de registro durante y después de la actualización para identificar y resolver cualquier problema que pueda producirse.

En esta página