Arquitectura
Sugerir cambios
PDF
Los hosts SAP HANA están conectados a controladoras de almacenamiento mediante una infraestructura de red 10 GbE redundante o más rápida. La comunicación de datos entre los hosts SAP HANA y las controladoras de almacenamiento se basa en el protocolo NFS.
Se recomienda utilizar una infraestructura de conmutación redundante para proporcionar conectividad entre el host SAP HANA con tolerancia a fallos en caso de fallo del switch o de la tarjeta de interfaz de red (NIC). Los switches pueden agregar rendimiento de puerto individual con canales de puerto para que aparezcan como una única entidad lógica en el nivel de host.
Los diferentes modelos de la familia de productos FAS 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 (ha) de almacenamiento.
La figura siguiente muestra un ejemplo de uso de VMware vSphere como capa de virtualización.
La arquitectura se puede escalar en dos dimensiones:
-
Agregando hosts SAP HANA adicionales y/o capacidad de almacenamiento al almacenamiento existente si las controladoras de almacenamiento proporcionan el suficiente rendimiento para cumplir los indicadores clave de rendimiento (KPI) de SAP actuales.
-
Agregando más sistemas de almacenamiento con capacidad de almacenamiento adicional para los hosts SAP HANA adicionales
La siguiente figura muestra una configuración de ejemplo en la 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 16 hosts SAP HANA. En función de los requisitos de rendimiento totales, deben añadirse conexiones 10 GbE (o más rápidas) a las controladoras de almacenamiento.
Además de ser independiente del sistema FAS puesto en marcha, el entorno SAP HANA también puede escalarse añadiendo cualquiera de las controladoras de almacenamiento certificadas para cumplir con la densidad de nodos deseada (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 de Snapshot de NetApp basados en el almacenamiento son una solución de backup totalmente compatible e integrada disponible para contenedores individuales de SAP HANA y para sistemas de contenedores de bases de datos multitenant (MDC) de SAP HANA con un solo 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 y Cockpit, donde pueden seleccionarse directamente para operaciones de restauración y recuperación.
La tecnología SnapMirror de NetApp permite replicar copias de 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 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 Snapshot basados en almacenamiento 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 (RTO) reducido debido a un tiempo de restauración mucho más rápido en la capa de almacenamiento (unos pocos minutos) y a los 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 con SnapCenter, 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 que utiliza la replicación sincrónica de SnapMirror en el centro de datos de recuperación ante desastres local y SnapMirror asíncrono para replicar 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 de recuperación ante desastres principal y local se limita a unos 100 km.
La protección frente a fallos del sitio de recuperación ante desastres primario y local 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 recuperación de desastres pueden usarse como sistemas de prueba/desarrollo durante el funcionamiento normal. En caso de desastre, los sistemas de desarrollo y pruebas debían cerrarse 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 sistema de almacenamiento y se conectan a los servidores de prueba 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 de 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
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 si se produce una conmutación por error ante desastres.
