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. Es necesaria una infraestructura de conmutación redundante para proporcionar conectividad entre el host de SAP HANA y el almacenamiento tolerante 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 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 (ha) de almacenamiento.
La figura siguiente muestra un ejemplo del uso de VMware vSphere como capa de virtualización.
La 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 indicadores clave de rendimiento (KPI) de SAP HANA 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 los 16 hosts SAP HANA. En función de los requisitos de rendimiento totales, debe añadir conexiones 10 GbE o más rápidas a las controladoras de almacenamiento.
Independientemente del sistema AFF puesto en marcha, el entorno SAP HANA también puede escalarse al añadir cualquiera de las 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 individuales de SAP HANA y para sistemas SAP HANA Multitenant Database Containers (MDC) 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 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 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 (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 sobre 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 (DR) de SAP HANA se puede llevar a cabo en la capa de la base de datos mediante la replicación del sistema SAP HANA o en la capa de almacenamiento mediante las 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
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.
