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 ASA 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 ASA 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.
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 "Protección de datos de SAP HANA y alta disponibilidad con SnapCenter, sincronización activa de SnapMirror y clúster de almacenamiento de VMware Metro".
|
Al momento de la creación de este documento, SnapCenter para ASA solo admite máquinas virtuales basadas en VMware que utilizan VMDK como almacenamiento. |
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 de tres sitios que utiliza la sincronización activa síncrona de SnapMirror con el centro de datos de recuperación ante desastres local y la sincronización asíncrona de SnapMirror para replicar los datos al centro de datos de recuperación ante desastres remoto. La sincronización activa de SnapMirror permite que los servicios empresariales sigan funcionando incluso tras un fallo total del sitio, lo que permite la conmutación por error transparente de las aplicaciones mediante una copia secundaria (RPO=0 y RTO=0). No se requiere intervención manual ni secuencias de comandos personalizadas para activar una conmutación por error con SnapMirror Active Sync. A partir de ONTAP 9.15.1, SnapMirror active sync admite una funcionalidad activo-activo simétrica. Activo-activo simétrico permite operaciones de I/O de lectura y escritura desde ambas copias de una LUN protegida con replicación síncrona bidireccional. De este modo, ambas copias LUN pueden servir operaciones de I/O localmente.
Puede encontrar más detalles en "Información general sobre la sincronización activa de SnapMirror en ONTAP" ..
El RTO para la replicación asincrónica de SnapMirror depende principalmente del tiempo necesario para iniciar la base de datos HANA en el sitio de DR 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.
