La siguiente figura muestra la vista lógica de la comunicación entre el servidor SnapCenter , la base de datos SAP HANA y el sistema de almacenamiento. El servidor SnapCenter aprovecha los complementos de HANA y Linux para comunicarse con la base de datos de HANA y los sistemas operativos Linux.

La opción de implementación recomendada y predeterminada para los complementos de SnapCenter es la instalación en el host de base de datos HANA. Con esta opción de implementación, todas las configuraciones y características descritas en el capítulo Configuración compatible con SnapCenter son válidas. Hay algunas excepciones en las que los complementos de SnapCenter no se pueden instalar en el host de base de datos HANA, sino que deben configurarse en un host de complementos central, que podría ser el propio servidor SnapCenter . Se requiere un host de complemento central para sistemas host múltiples HANA o sistemas HANA que se ejecutan en la plataforma IBM Power. Ambas opciones de implementación también se pueden combinar, por ejemplo, utilizando el servidor SnapCenter como un host de complemento central para un sistema de host múltiple e implementando los complementos en los hosts de base de datos HANA para todos los demás sistemas HANA de host único.

En SnapCenter, un recurso HANA se puede descubrir automáticamente o configurar manualmente. Un sistema HANA se descubre automáticamente de forma predeterminada tan pronto como se implementan los complementos de HANA y Linux en el host de la base de datos. El descubrimiento automático de SnapCenter no admite múltiples instalaciones de HANA en el mismo host. Los sistemas HANA administrados mediante un host de complemento central deben configurarse manualmente en SnapCenter. Además, los volúmenes que no son de datos son recursos configurados manualmente de forma predeterminada.

Si bien SnapCenter admite una implementación de complemento central para sistemas HANA, existen limitaciones en la plataforma y la compatibilidad de funciones. Las siguientes configuraciones y operaciones de infraestructura no son compatibles con los sistemas HANA configurados con un host de complemento central:

SAP recomienda incluir comprobaciones periódicas de la consistencia de los bloques de HANA en la estrategia de copia de seguridad general. Con las copias de seguridad tradicionales basadas en archivos, esta comprobación se realiza con cada operación de copia de seguridad. Con las copias de seguridad instantáneas, la verificación de consistencia debe ejecutarse además de las operaciones de copia de seguridad instantánea, por ejemplo, una vez por semana.

Técnicamente hay dos opciones para ejecutar la verificación de consistencia del bloque.

La herramienta HANA hdbpersdiag es parte de la instalación de HANA y permite ejecutar operaciones de verificación de consistencia de bloques en una base de datos HANA sin conexión. Por lo tanto, es perfecto para utilizarlo en combinación con copias de seguridad instantáneas, donde las copias de seguridad instantáneas existentes se pueden presentar a hdbpersdiag.

Al comparar los dos enfoques, hdbpersdiag tiene ventajas significativas en comparación con la copia de seguridad basada en archivos para las comprobaciones de consistencia de bloques de HANA. Una dimensión es la capacidad de almacenamiento requerida. Con copias de seguridad basadas en archivos, al menos el tamaño de una copia de seguridad debe estar disponible para cada sistema HANA. Si tiene, por ejemplo, 15 sistemas HANA con un tamaño de persistencia de 3 TB, necesitará 45 TB adicionales solo para las comprobaciones de consistencia. Con hdbpersdiag no se requiere capacidad de almacenamiento adicional ya que la operación se ejecuta contra una copia de seguridad Snapshot existente o un FlexClone de una copia de seguridad Snapshot existente. La segunda dimensión es la carga de la CPU en el host HANA durante la operación de verificación de consistencia. Una copia de seguridad basada en archivos requerirá ciclos de CPU en el host de base de datos HANA, mientras que el procesamiento de hdbpersdiag se puede descargar completamente del host HANA cuando se usa en combinación con un host de verificación central. La siguiente tabla resume las características clave.

NetApp recomienda utilizar hdbpersdiag para ejecutar comprobaciones de consistencia de bloques de HANA. Más detalles sobre la implementación están disponibles en el capítulo "Comprobaciones de consistencia de bloques con SnapCenter".

Antes de configurar SnapCenter y el complemento SAP HANA, la estrategia de protección de datos se debe definir de acuerdo con los requisitos de objetivo de tiempo de recuperación y objetivo de punto de recuperación de los distintos sistemas SAP.

Un enfoque común es definir tipos de sistemas como sistemas de producción, desarrollo, pruebas o entornos de pruebas. Normalmente, todos los sistemas SAP del mismo tipo tienen los mismos parámetros de protección de datos.

Los parámetros que deben definirse son:

La siguiente tabla muestra un ejemplo de parámetros de protección de datos para los tipos de sistemas de producción, desarrollo y prueba. Para el sistema de producción, se ha definido una alta frecuencia de copias de seguridad, y las copias de seguridad se replican en un sitio de copia de seguridad secundario una vez al día. Los sistemas de prueba tienen requisitos menores y no hay replicación de las copias de seguridad.

La siguiente tabla muestra las políticas y los programas que deben configurarse para los parámetros de protección de datos anteriores.

La siguiente figura resume los cronogramas y las retenciones de copias de seguridad. Si se utiliza SnapCenter para administrar la retención de copias de seguridad de registros, se eliminarán todas las copias de seguridad de registros que sean más antiguas que la copia de seguridad de instantánea más antigua. En otras palabras, las copias de seguridad de los registros se conservan durante el tiempo que sea necesario para permitir la recuperación a tiempo de cada copia de seguridad disponible.

Cuando se utiliza el cifrado de persistencia de HANA, es fundamental crear copias de seguridad de las claves raíz además de las copias de seguridad de datos estándar. Se requieren copias de seguridad de la clave raíz para recuperar la base de datos de HANA en caso de que se pierdan el volumen de datos y el sistema de archivos de instalación de HANA. Para más información véase "Guía de administración de SAP HANA".

SnapCenter admite operaciones de respaldo de instantáneas de sistemas HANA MDC con uno o varios inquilinos. SnapCenter también admite dos operaciones de restauración diferentes de un sistema HANA MDC. Puede restaurar el sistema completo, la base de datos del sistema y todos los inquilinos, o puede restaurar solo un inquilino. Hay algunos requisitos previos para permitir que SnapCenter ejecute estas operaciones.

En un sistema MDC, la configuración del inquilino no es necesariamente estática. Se pueden agregar o eliminar inquilinos. SnapCenter no puede confiar en la configuración que se descubre cuando se agrega la base de datos HANA a SnapCenter. Para habilitar una operación de restauración de un solo inquilino, SnapCenter debe saber qué inquilinos están incluidos en cada copia de seguridad de instantánea. Además, debe saber qué archivos y directorios pertenecen a cada inquilino incluido en la copia de seguridad instantánea.

Por lo tanto, con cada operación de respaldo, SnapCenter identifica la información del inquilino. Esto incluye los nombres de los inquilinos y la información de archivos y directorios correspondiente. Estos datos deben almacenarse en los metadatos de respaldo de instantáneas para poder admitir una operación de restauración de un solo inquilino.

Otro paso del descubrimiento automático de aplicaciones es la detección del nodo primario o secundario de HANA System Replication (HSR). Si un sistema HANA está configurado con HSR, SnapCenter debe identificar el nodo principal con cada operación de respaldo para que los comandos SQL de respaldo se ejecuten en el nodo principal HSR. Véase también "Replicación de sistemas SAP HANA: Backup y recuperación de datos con SnapCenter".

SnapCenter también detecta la configuración del volumen de datos de HANA y la asigna al sistema de archivos y a los recursos de almacenamiento. Con este enfoque, SnapCenter puede gestionar cambios de configuración de volumen de HANA, por ejemplo, particiones múltiples o cambios de configuración de almacenamiento como migraciones de volúmenes.

El siguiente paso es la operación de copia de seguridad instantánea en sí. Este paso incluye el comando SQL para activar la instantánea de la base de datos de HANA, la copia de seguridad de la instantánea de almacenamiento y el comando SQL para cerrar la operación de la instantánea de HANA. Al utilizar el comando de cierre, la base de datos de HANA actualiza el catálogo de respaldo de la base de datos del sistema y de cada inquilino.

Para la gestión de retención de los backups de datos y la gestión del catálogo de backup de HANA, SnapCenter debe ejecutar las operaciones de eliminación de catálogo para la base de datos del sistema y todas las bases de datos de tenant que se identificaron en el primer paso. Del mismo modo para los backups de registros, el flujo de trabajo SnapCenter debe funcionar en cada inquilino que forme parte de la operación de backup.

En la siguiente figura, se muestra información general sobre el flujo de trabajo de backup.

La gestión de la retención de backup de datos y el mantenimiento de los backups de registros se pueden dividir en cinco áreas principales, incluida la gestión de retención de:

En la siguiente figura, se proporciona información general sobre los diferentes flujos de trabajo y las dependencias de cada operación. En las siguientes secciones se describen detalladamente las diferentes operaciones.