Con SnapCenter, la detección automática, y la restauración y recuperación automatizadas son compatibles con la mayoría de las configuraciones de HANA, con la excepción de que varios sistemas de host de HANA requieren una configuración manual.

La siguiente tabla muestra las configuraciones de HANA compatibles para la detección automática.

Es posible configurar manualmente los recursos HANA para todas las arquitecturas HANA; sin embargo, requiere un host de complemento HANA central. El host del plugin central puede ser el propio servidor SnapCenter o un host Linux o Windows independiente.

La siguiente tabla muestra las configuraciones de HANA compatibles para la configuración manual de recursos de HANA.

SnapCenter se puede establecer en una configuración de alta disponibilidad de dos nodos. En dicha configuración, se utiliza un equilibrador de carga (por ejemplo, F5) en un modo activo/pasivo utilizando una dirección IP virtual dirigida al host de SnapCenter activo. El repositorio de SnapCenter (la base de datos de MySQL) es replicado por SnapCenter entre los dos hosts para que los datos de SnapCenter estén siempre sincronizados.

La alta disponibilidad del servidor SnapCenter no es compatible si el plugin HANA está instalado en el servidor SnapCenter. Si planea configurar SnapCenter en una configuración de alta disponibilidad, no instale el plugin HANA en el servidor SnapCenter. Puede encontrar más información sobre la alta disponibilidad de SnapCenter en este "Página de la base de conocimientos de NetApp".

La siguiente figura muestra una configuración en la que SnapCenter Server se utiliza como host de plugin central. El complemento SAP HANA y el software de cliente SAP hdbsql se instalan en el servidor SnapCenter.

Dado que el complemento HANA se puede comunicar con las bases de datos HANA gestionadas usando el hdbclient a través de la red, no es necesario instalar ningún componente de SnapCenter en los hosts individuales de la base de datos HANA. SnapCenter puede proteger las bases de datos de HANA mediante un host del complemento de HANA central en el que todas las claves de userstore están configuradas para las bases de datos gestionadas.

Por otro lado, la automatización mejorada del flujo de trabajo para la detección automática, la automatización de la restauración y la recuperación, así como las operaciones de actualización del sistema SAP requieren la instalación de los componentes de SnapCenter en el host de la base de datos. Cuando se utiliza un host de un plugin de HANA central, estas funciones no están disponibles.

Además, la alta disponibilidad del servidor SnapCenter con la función de alta disponibilidad integrada no se puede usar cuando el complemento HANA está instalado en el servidor SnapCenter. La alta disponibilidad se puede obtener usando VMware ha si el servidor SnapCenter se está ejecutando en un equipo virtual dentro de un clúster de VMware.

En la siguiente figura, se muestra una configuración en la que un host Linux separado se usa como host de plugin central. En este caso, el complemento SAP HANA y el software de cliente SAP hdbsql se instalan en el host Linux.

La misma restricción en cuanto a la disponibilidad de funciones descrita en la sección anterior también se aplica a un host de plugin central independiente.

Sin embargo, con esta opción de puesta en marcha, el servidor SnapCenter se puede configurar con la funcionalidad de alta disponibilidad incorporada. El host del plugin central también debe ser ha, por ejemplo, mediante una solución de clúster Linux.

La siguiente figura muestra una configuración en la cual el plugin de SAP HANA está instalado en cada host de base de datos SAP HANA.

Cuando el complemento HANA se instala en cada host de base de datos HANA individual, todas las funciones, como la detección automática y la restauración y recuperación automatizadas, están disponibles. Además, el servidor SnapCenter puede configurarse en una configuración de alta disponibilidad.

Como se explicó al principio de esta sección, algunas configuraciones del sistema HANA, como varios sistemas de host, requieren un host de plugin centralizado. Por lo tanto, la mayoría de las configuraciones de SnapCenter requieren una puesta en marcha mixta del complemento HANA.

NetApp recomienda implementar el plugin de HANA en el host de base de datos de HANA para todas las configuraciones del sistema HANA que se admiten para la detección automática. Otros sistemas HANA, como las configuraciones de varios hosts, deben gestionarse con el host de plugin de HANA central.

Las dos figuras siguientes muestran implementaciones de plugins combinadas con el servidor SnapCenter o con un host Linux independiente como host de plugins centrales. La única diferencia entre estas dos puestas en marcha es la configuración de alta disponibilidad opcional.

En general, NetApp recomienda poner en marcha el complemento HANA en cada host SAP HANA para habilitar todas las funciones disponibles de SnapCenter HANA y mejorar la automatización del flujo de trabajo.

Para las configuraciones de HANA en las que no se admite la detección automática, como las configuraciones de varios hosts de HANA, se debe configurar un host del plugin de HANA central adicional. El host del complemento central puede ser el servidor de SnapCenter si se puede utilizar ha de VMware para alta disponibilidad de SnapCenter. Si piensa utilizar la funcionalidad de alta disponibilidad incorporada de SnapCenter, utilice un host de plugin de Linux independiente.

En la tabla siguiente se resumen las distintas opciones de implementación.

SnapCenter realiza un backup de la base de datos SAP HANA en el siguiente orden:

SnapCenter ejecuta la comprobación de integridad de bloques en la siguiente secuencia:

SnapCenter realiza tareas de mantenimiento de backups de bases de datos SAP HANA y backups de volúmenes sin datos eliminando copias Snapshot en el almacenamiento principal y en el repositorio de SnapCenter según una retención definida en la política de backup de SnapCenter.

La lógica de gestión de retención se ejecuta con cada flujo de trabajo de backup en SnapCenter.

Los backups locales del almacenamiento primario también se pueden eliminar manualmente en SnapCenter.

SnapCenter realiza tareas de mantenimiento de los backups basados en archivos mediante la eliminación de los backups en el sistema de archivos según una retención definida en la política de backup de SnapCenter.

La lógica de gestión de retención se ejecuta con cada flujo de trabajo de backup en SnapCenter.

La gestión de retención de backups en el almacenamiento secundario es gestionada por ONTAP de acuerdo con la retención definida en la relación de protección de ONTAP.

Para sincronizar estos cambios en el almacenamiento secundario del repositorio de SnapCenter, SnapCenter utiliza un trabajo de limpieza programado. Esta tarea de limpieza sincroniza todos los backups de almacenamiento secundario con el repositorio de SnapCenter para todos los plugins de SnapCenter y todos los recursos.

De forma predeterminada, el trabajo de limpieza se programa una vez a la semana. Esta programación semanal genera un retraso con la eliminación de backups en SnapCenter y SAP HANA Studio en comparación con los backups que ya se han eliminado en el almacenamiento secundario. Para evitar esta incoherencia, los clientes pueden cambiar la programación por una mayor frecuencia, por ejemplo, una vez al día.

Para obtener información detallada acerca de cómo adaptar la programación del trabajo de limpieza o cómo activar una actualización manual, consulte la sección "“Cambie la frecuencia de programación de la sincronización de copias de seguridad con el almacenamiento de copias de seguridad fuera de las instalaciones”."

Cuando SnapCenter ha eliminado cualquier backup, snapshot local o basado en archivos, o si ha identificado la eliminación del backup en el almacenamiento secundario, este backup de datos también se elimina en el catálogo de backup de SAP HANA.

Antes de eliminar la entrada del catálogo SAP HANA para un backup de Snapshot local en el almacenamiento principal, SnapCenter comprueba si el backup sigue existiendo en el almacenamiento secundario.

La base de datos SAP HANA crea automáticamente backups de registro. Este backup de registro ejecuta crean archivos de backup para cada servicio SAP HANA individual en un directorio de backup configurado en SAP HANA.

Los backups de registros más antiguos del último backup de datos ya no son necesarios para la recuperación futura y, por lo tanto, se pueden eliminar.

SnapCenter realiza tareas de mantenimiento de los backups de archivos de registro en el nivel del sistema de archivos y del catálogo de backup SAP HANA mediante la ejecución de los pasos siguientes:

La gestión de retención del backup de registros está habilitada de forma predeterminada. Si es necesario, se puede desactivar tal como se describe en la sección "“Deshabilitar la detección automática en el host del plugin de HANA.”"

Desde la perspectiva de la base de datos de HANA, SnapCenter admite dos operaciones de restauración diferentes.

Desde la perspectiva del almacenamiento, las operaciones de restauración anteriores deben ejecutarse de una forma diferente en función del protocolo de almacenamiento utilizado (NFS o SAN Fibre Channel), la protección de datos configurada (almacenamiento principal con o sin almacenamiento de backup externo), y el backup seleccionado que se utilizará para la operación de restauración (restauración desde el almacenamiento de backup principal o externo).

Cuando se restaura el recurso completo desde el almacenamiento primario, SnapCenter admite dos funciones de ONTAP diferentes para ejecutar la operación de restauración. Puede elegir entre las siguientes dos funciones:

En la siguiente tabla, se proporcionan comparación entre los diferentes métodos de restauración.

Una restauración desde el almacenamiento de backup externo siempre se ejecuta mediante una operación de restauración de SnapVault, donde todos los archivos o todos los LUN del volumen de almacenamiento se sobrescriben con el contenido del backup de Snapshot.

La restauración de un solo inquilino requiere una operación de restauración basada en archivos. Según el protocolo de almacenamiento utilizado, SnapCenter ejecuta diferentes flujos de trabajo de restauración.

Los sistemas de un solo inquilino de HANA y MDC de HANA que se detectaron automáticamente están habilitados para restaurar y recuperar de forma automatizada con SnapCenter. Para estos sistemas HANA, SnapCenter admite tres flujos de trabajo diferentes de restauración y recuperación, como se muestra en la siguiente figura:

Aunque los sistemas MDC de HANA con múltiples inquilinos se pueden detectar automáticamente, la restauración y la recuperación automatizadas no son compatibles con la versión actual de SnapCenter. Para los sistemas MDC con múltiples inquilinos, SnapCenter admite dos flujos de trabajo diferentes de restauración y recuperación, como se muestra en la siguiente figura:

Los flujos de trabajo son los mismos que se describen en la sección anterior.

Los recursos HANA configurados manualmente no están habilitados para la restauración y la recuperación automatizadas. Asimismo, en el caso de sistemas MDC con uno o varios inquilinos, no se admite una operación de restauración de un solo inquilino.

Para los recursos HANA configurados manualmente, SnapCenter solo admite la recuperación manual, como se muestra en la siguiente figura. El flujo de trabajo para la recuperación manual es el mismo que el descrito en las secciones anteriores.

La tabla siguiente resume las operaciones de restauración y recuperación en función de la configuración de recursos de HANA en SnapCenter.