Arquitectura
Sugerir cambios
PDF
Los hosts SAP HANA están conectados a controladoras de almacenamiento mediante una infraestructura FCP redundante y un software multivía. Se necesita una infraestructura de switch FCP redundante para proporcionar conectividad de host a almacenamiento de SAP HANA con tolerancia a fallos en caso de fallo del switch o del adaptador de bus de host (HBA). Debe configurarse la división en zonas adecuada en el switch para permitir que todos los hosts HANA lleguen a las LUN requeridas en las controladoras de almacenamiento.
Los diferentes modelos de la familia de productos AFF pueden combinarse y emparejarse en la capa de almacenamiento para permitir el crecimiento y las distintas necesidades de rendimiento y capacidad. El número máximo de hosts SAP HANA que se pueden conectar al sistema de almacenamiento se define según los requisitos de rendimiento de SAP HANA y el modelo de controladora de NetApp utilizado. El número de bandejas de discos necesarias solo está determinado por los requisitos de capacidad y rendimiento de los sistemas SAP HANA.
En la siguiente figura, se muestra un ejemplo de configuración con ocho hosts SAP HANA conectados a un par de alta disponibilidad de almacenamiento.
Esta arquitectura se puede escalar en dos dimensiones:
-
Conectando los hosts SAP HANA adicionales y la capacidad de almacenamiento al almacenamiento existente si las controladoras de almacenamiento proporcionan el rendimiento suficiente para cumplir los KPI actuales de SAP HANA
-
Agregando más sistemas de almacenamiento con capacidad de almacenamiento adicional para los hosts SAP HANA adicionales
La siguiente figura muestra un ejemplo de configuración en el que hay más hosts SAP HANA conectados a las controladoras de almacenamiento. En este ejemplo, se necesitan más bandejas de discos para cumplir los requisitos de capacidad y rendimiento de los 16 hosts SAP HANA. Según los requisitos de rendimiento totales, debe añadir conexiones FC adicionales a las controladoras de almacenamiento.
Independientemente del sistema AFF puesto en marcha, el entorno SAP HANA también puede escalarse añadiendo controladoras de almacenamiento certificadas para cumplir con la densidad de nodos deseada, como se muestra en la siguiente figura.
Backup de SAP HANA
El software ONTAP presente en todas las controladoras de almacenamiento de NetApp proporciona un mecanismo integrado para realizar backups de bases de datos SAP HANA mientras se ejecuta sin que el rendimiento se ve afectado. Los backups Snapshot de NetApp basados en el almacenamiento son una solución de backup totalmente compatible e integrada disponible para contenedores únicos de SAP HANA y para sistemas MDC de SAP HANA con un único inquilino o varios inquilinos.
Los backups de Snapshot basados en almacenamiento se implementan usando el complemento SnapCenter de NetApp para SAP HANA. De este modo, los usuarios pueden crear backups Snapshot coherentes basados en el almacenamiento mediante las interfaces que proporcionan de forma nativa las bases de datos SAP HANA. SnapCenter registra cada uno de los backups de Snapshot en el catálogo de backup de SAP HANA. Por lo tanto, los backups realizados por SnapCenter son visibles en SAP HANA Studio o Cockpit, donde pueden seleccionarse directamente para operaciones de restauración y recuperación.
La tecnología SnapMirror de NetApp permite replicar copias snapshot creadas en un sistema de almacenamiento a un sistema de almacenamiento de backup secundario controlado por SnapCenter. A continuación se pueden definir diferentes normativas de retención de backups para cada conjunto de backup en el almacenamiento primario y también para los conjuntos de backup en los sistemas de almacenamiento secundario. El plugin de SnapCenter para SAP HANA gestiona automáticamente la retención de los backups de registros y los backups de datos basados en copias de Snapshot, incluido el mantenimiento del catálogo de backup. El plugin de SnapCenter para SAP HANA también permite ejecutar una comprobación de integridad de bloque de la base de datos de SAP HANA mediante la ejecución de un backup basado en archivos.
Puede realizarse un backup de los registros de la base de datos directamente en el almacenamiento secundario mediante un montaje NFS, como se muestra en la siguiente figura.
Los backups basados en almacenamiento Snapshot proporcionan importantes ventajas en comparación con los backups basados en archivos convencionales. Estas ventajas incluyen, entre otras:
-
Backups más rápidos (unos minutos)
-
Objetivo de tiempo de recuperación reducido debido a un tiempo de restauración mucho más rápido en la capa de almacenamiento (unos pocos minutos) y a backups más frecuentes
-
Sin degradación del rendimiento del host, la red o el almacenamiento de bases de datos SAP HANA durante las operaciones de backup y recuperación
-
Replicación con gestión eficiente del espacio y del ancho de banda en el almacenamiento secundario en función de los cambios de bloque
Para obtener información detallada acerca de la solución de backup y recuperación de SAP HANA, consulte "TR-4614: Backup y recuperación de datos de SAP HANA con SnapCenter".
Recuperación ante desastres de SAP HANA
La recuperación ante desastres de SAP HANA se puede llevar a cabo a nivel de base de datos mediante la replicación del sistema SAP HANA o en la capa de almacenamiento mediante tecnologías de replicación de almacenamiento. La siguiente sección ofrece información general sobre las soluciones de recuperación ante desastres basadas en la replicación de almacenamiento.
Para obtener información detallada acerca de las soluciones de recuperación ante desastres de SAP HANA, consulte "TR-4646: Recuperación ante desastres de SAP HANA con replicación de almacenamiento".
Replicación de almacenamiento basada en SnapMirror
La siguiente figura muestra una solución de recuperación ante desastres en tres sitios mediante la replicación SnapMirror síncrona en el centro de datos de recuperación ante desastres local y SnapMirror asíncrono para replicar los datos en el centro de datos de recuperación ante desastres remoto.
La replicación de datos mediante SnapMirror síncrono proporciona un objetivo de punto de recuperación de cero. La distancia entre el centro de datos primario y el local de recuperación ante desastres se limita a unos 100 km.
La protección contra fallos del sitio de recuperación ante desastres local y primario se realiza replicando los datos en un tercer centro de datos de recuperación ante desastres remoto mediante SnapMirror asíncrono. El RPO depende de la frecuencia de las actualizaciones de replicación y de la rapidez con la que se pueden transferir. En teoría, la distancia es ilimitada, pero el límite depende de la cantidad de datos que se debe transferir y de la conexión disponible entre los centros de datos. Los valores típicos del RPO están dentro del intervalo de 30 minutos a varias horas.
El objetivo de tiempo de recuperación para ambos métodos de replicación depende principalmente del tiempo necesario para iniciar la base de datos HANA en el sitio de recuperación ante desastres y cargar los datos en la memoria. Suponiendo que se leen los datos con un rendimiento de 1000 Mbps, la carga de 1 TB de datos requeriría aproximadamente 18 minutos.
Los servidores en los sitios de DR pueden usarse como sistemas de desarrollo y pruebas durante el funcionamiento normal. En caso de desastre, los sistemas de desarrollo y pruebas deberían cerrarse y iniciarse como servidores de producción de recuperación ante desastres.
Ambos métodos de replicación permiten ejecutar pruebas del flujo de trabajo de recuperación ante desastres sin que ello afecte al objetivo de punto de recuperación ni al objetivo de tiempo de recuperación. Los volúmenes FlexClone se crean en el almacenamiento y se conectan a los servidores de pruebas de recuperación ante desastres.
La replicación síncrona ofrece el modo StrictSync. Si la escritura en almacenamiento secundario no se completa por ningún motivo, las operaciones de I/o de la aplicación fallan, lo cual garantiza que los sistemas de almacenamiento primario y secundario sean idénticos. Las operaciones de I/o de la aplicación en el principal se reanudan solo después de que la relación de SnapMirror vuelva al estado InSync. Si falla el almacenamiento primario, se pueden reanudar las operaciones de I/o de la aplicación en el almacenamiento secundario después de una conmutación por error sin pérdida de datos. En el modo StrictSync, el objetivo de punto de recuperación siempre es cero.
Replicación de almacenamiento basada en MetroCluster de NetApp
En la siguiente figura, se muestra una descripción general de alto nivel de la solución. El cluster de almacenamiento de cada sitio proporciona alta disponibilidad local y se utiliza para la carga de trabajo de producción. Los datos de cada sitio se replican de forma síncrona en la otra ubicación y están disponibles en caso de recuperación tras fallos.
