Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA
Azure proporciona distintos tipos de almacenamiento adecuados para máquinas virtuales de Azure que ejecutan SAP HANA. Los tipos de almacenamiento de Azure con certificación de SAP HANA que pueden considerarse para las implementaciones de SAP HANA, como:
- SSD Premium de Azure o Premium Storage v1/v2
- Disco Ultra
- Azure NetApp Files
Para obtener información sobre estos tipos de disco, consulte el artículo Tipos de Azure Storage para la carga de trabajo de SAP y Seleccionar un tipo de disco.
Azure ofrece dos métodos de implementación para discos duros virtuales en Azure Standard y Premium Storage v1/v2. Esperamos que aproveche el disco administrado de Azure para implementaciones de almacenamiento en bloque de Azure.
Para obtener una lista de tipos de almacenamiento y sus Acuerdos de Nivel de Servicio sobre IOPS y rendimiento del almacenamiento, revise la documentación de Azure para Managed Disks.
Importante
Independientemente del tipo de almacenamiento de Azure elegido, el sistema de archivos que se usa en ese almacenamiento debe ser compatible con SAP para el sistema operativo y el DBMS específicos. La nota de compatibilidad 2972496 de SAP enumera los sistemas de archivos admitidos para los diferentes sistemas operativos y bases de datos, incluido SAP HANA. Esto se aplica a todos los volúmenes SAP HANA con acceso de lectura y escritura para cualquier tarea. Especialmente si usa NFS en Azure para SAP HANA, se aplican restricciones adicionales de versiones de NFS como se indica más adelante en este artículo.
Las condiciones de certificación mínimas de SAP HANA para los diferentes tipos de almacenamiento son:
- Azure Premium Storage v1: se requiere /hana/log para ser compatible con Azure Acelerador de escritura. El volumen /hana/data podría colocarse en Premium Storage v1 sin el Acelerador de escritura de Azure o en el disco Ultra. Azure Premium Storage v2 o SSD prémium de Azure v2 no admite el uso del Acelerador de escritura de Azure
- Disco Ultra de Azure al menos para el volumen /hana/log. El volumen de /hana/data se puede colocar en Premium Storage v1/v2 sin el Acelerador de escritura de Azure o para obtener tiempos de reinicio más rápidos del disco Ultra
- Volúmenes de NFS v4.1 sobre Azure NetApp Files para /hana/log y /hana/data. El volumen de /hana/shared puede usar el protocolo NFS v3 o NFS v 4.1.
En función de la experiencia adquirida con los clientes, hemos cambiado la compatibilidad para combinar diferentes tipos de almacenamiento entre /hana/data y /hana/log. Se admite para combinar el uso de los diferentes almacenamientos en bloques de Azure certificados para recursos compartidos DE HANA AND NFS basados en Azure NetApp Files. Por ejemplo, es posible colocar /hana/data en Premium Storage v1 o v2 y /hana/log se pueden colocar en el almacenamiento en disco Ultra para obtener la baja latencia necesaria. Si usa un volumen basado en ANF para /hana/data, el volumen /hana/log también se puede colocar en uno de los tipos de almacenamiento en bloques de Azure certificados de HANA. El uso de NFS sobre ANF para uno de los volúmenes (como /hana/data) y Azure Premium Storage v1/v2 o disco Ultra para el otro volumen (como /hana/log) es compatible con.
En el mundo local, casi nunca ha tenido que preocuparse sobre los subsistemas de E/S y sus funcionalidades. El motivo era que el proveedor de las aplicaciones tenía que asegurarse de que se cumplieran los requisitos de almacenamiento mínimo para SAP HANA. Mientras crea la infraestructura de Azure, debe tener en cuenta algunos de estos requisitos que emite SAP. Algunas de las características de rendimiento mínimas que recomienda SAP son:
- Lectura o escritura en /hana/log de 250 MB/s con tamaños de E/S de 1 MB
- Actividad de lectura de al menos 400 MB/s para /hana/data con tamaños de E/S de 16 MB y 64 MB
- Actividad de escritura de al menos 250 MB/s para /hana/data con tamaños de E/S de 16 MB y 64 MB
Debido a que la baja latencia de almacenamiento es fundamental para los sistemas DBMS, incluso estos DBMS, como SAP HANA, mantienen los datos en memoria. La ruta crítica en el almacenamiento normalmente está relacionada con las escrituras del registro de transacciones de los sistemas DBMS. Sin embargo, también las operaciones como la escritura de puntos de retorno o la carga de datos en memoria después de la recuperación tras un bloqueo pueden ser críticas. Por lo tanto, es obligatorio usar Azure Premium Storage v1/v2, disco Ultra o ANF para /hana/data y volúmenes /hana/log.
Estos son algunos principios de la selección de la configuración de almacenamiento para HANA:
- Decida el tipo de almacenamiento según Tipos de Azure Storage para la carga de trabajo de SAP y Seleccionar un tipo de disco.
- El rendimiento global de E/S de la VM y los límites de IOPS al elegir una VM o determinar su tamaño. El rendimiento general del almacenamiento de VM está documentado en el artículo Tamaños de máquina virtual optimizada para memoria.
- A la hora de decidirse por la configuración del almacenamiento, intente permanecer por debajo del rendimiento general de la VM con la configuración del volumen /hana/data. SAP HANA escribe puntos de retorno, HANA puede presentar cierta agresividad al emitir E/S. Es posible aumentar con facilidad los límites de rendimiento del volumen /hana/data al escribir un punto de retorno. Si los discos que compilan el volumen /hana/data tienen un rendimiento superior al que permite la VM, puede que se produzcan situaciones en que el rendimiento usado por la escritura del punto de retorno interfiera con las demandas de rendimiento de las escrituras de registros de fase de puesta al día. Esta situación puede afectar al rendimiento de la aplicación.
- Si está pensando en usar la replicación del sistema de HANA, el almacenamiento usado para /hana/data en cada réplica debe ser el mismo y el tipo de almacenamiento usado para /hana/log en cada réplica debe ser el mismo. Por ejemplo, no se admite el uso de Azure Premium Storage v1 para /hana/data con una máquina virtual y un disco Ultra de Azure para /hana/data en otra máquina virtual que ejecuta una réplica de la misma configuración de replicación del sistema HANA
Importante
Las sugerencias para las configuraciones de almacenamiento de este documento o de los siguientes se han diseñado como instrucciones con las que empezar. Al ejecutar la carga de trabajo y analizar los patrones de uso del almacenamiento, es posible que se dé cuenta de que no está usando todo el ancho de banda de almacenamiento o IOPS proporcionado. En ese caso, puede considerar la posibilidad de reducir el tamaño del almacenamiento. También puede que, por el contrario, la carga de trabajo necesite más rendimiento de almacenamiento del sugerido con estas configuraciones. Como resultado, es posible que tenga que implementar más capacidad, IOPS o rendimiento. En el campo de la tensión entre la capacidad de almacenamiento necesaria, la latencia de almacenamiento necesaria, el rendimiento de almacenamiento y las IOPS necesarias y la configuración menos costosa, Azure ofrece suficientes tipos de almacenamiento diferentes con distintas funcionalidades y precios de venta para determinar el compromiso adecuado para usted y su carga de trabajo de HANA y adaptarse a este.
Conjuntos de franjas frente a creación de particiones de volumen de datos de SAP HANA
Con Azure Premium Storage v1, puede alcanzar la mejor relación de precio/rendimiento al seccionar el /hana/data o /hana/log volumen en varios discos de Azure. en lugar de implementar volúmenes de disco mayores que proporcionan más información sobre IOPS o el rendimiento necesario. La creación de un único volumen en varios discos de Azure se puede realizar con los administradores de volúmenes LVM y MDADM, que forman parte de Linux. El método de seccionamiento de discos tiene décadas de antigüedad y es perfectamente conocido. Por muy beneficiosos que sean esos volúmenes seccionados para conseguir las IOPS o las capacidades de rendimiento que pueda necesitar, este método agrega complejidades en torno a la administración de dichos volúmenes, especialmente en los casos en los que es necesario ampliar la capacidad de los volúmenes. Al menos para /hana/data, SAP presentó un método alternativo que logra el mismo objetivo que el seccionamiento en varios discos de Azure. A partir de SAP HANA 2.0 SPS03, el servidor de indexación de HANA puede seccionar su actividad de E/S en varios archivos de datos de HANA que se encuentran en diferentes discos de Azure. La ventaja es que no tiene que encargarse de crear y administrar un volumen seccionado en varios discos de Azure. La funcionalidad SAP HANA de la creación de particiones de volúmenes de datos se describe en detalle en:
- Guía para administradores de HANA
- Blog sobre SAP HANA: creación de particiones de volúmenes de datos
- Nota de SAP n.º 2400005
- Nota de SAP #2700123
Al leer los detalles, es evidente que la aplicación de esta funcionalidad elimina las complejidades de los conjuntos de franjas basados en el administrador de volúmenes. También se da cuenta de que la creación de particiones de volúmenes de datos de HANA no solo funciona para el almacenamiento en bloques de Azure, como Azure Premium Storage v1/v2. También puede usar esta funcionalidad para seccionar en los recursos compartidos de NFS en caso de que estos recursos compartidos tengan limitaciones de IOPS o rendimiento.
Modo de programador de E/S de Linux
Linux tiene varios modos diferentes de programación de E/S. Una recomendación común de los proveedores de Linux y SAP consiste en reconfigurar el modo de programador de E/S para los volúmenes de disco del modo mq-deadline o kyber en el modo noop (no multicola) o none (multicola) si todavía no lo han hecho los perfiles saptune de SLES. Los detalles se incluyen en:
- Nota de SAP n.º 1984787
- Nota de SAP n.º 2578899
- Problema con la configuración de noop en SLES 12 SP4
En Red Hat, deje la configuración establecida por los perfiles de ajuste específicos para las diferentes aplicaciones SAP.
Tamaños de franja al usar administradores de volúmenes lógicos
Si usa LVM o mdadm para crear conjuntos de franjas en varios discos Premium de Azure, debe definir tamaños de franjas. Estos tamaños difieren entre /hana/data y /hana/log. Recomendación: En cuanto a tamaños de franja, la recomendación es usar:
- 256 KB para /hana/data
- 64 KB para /hana/log
Nota
El tamaño de franja de /hana/data ha cambiado con respecto a las recomendaciones anteriores que precisan de 64 KB o 128 KB a 256 KB según las experiencias del cliente con versiones más recientes de Linux. El tamaño de 256 KB proporciona un rendimiento ligeramente superior. También hemos cambiado la recomendación para los tamaños de franja de /hana/log de 32 KB a 64 KB para obtener un rendimiento suficiente con tamaños de E/S superiores.
Nota
No es necesario configurar ningún nivel de redundancia con volúmenes RAID, ya que el almacenamiento en bloque de Azure conserva tres imágenes de un VHD. El uso de un conjunto de franjas con discos Premium de Azure es, simplemente, configurar volúmenes que proporcionen suficientes IOPS o rendimiento de E/S.
La acumulación de varios discos de Azure por debajo de un conjunto de franjas es acumulativo desde el punto de vista del rendimiento de almacenamiento y las IOPS. Por lo tanto, si coloca un conjunto de franjas en más de 3 x discos de Azure Premium Storage v1, debe proporcionar tres veces las IOPS y tres veces el rendimiento de almacenamiento de un único disco de Azure Premium Storage v1 P30.
Importante
En el supuesto de que use LVM o mdadm como administrador de volúmenes para crear conjuntos de franjas en varios discos Premium de Azure, los tres sistemas de archivos de SAP HANA /data, /log y /shared no se deben colocar en un grupo de volúmenes raíz o predeterminado. Se recomienda encarecidamente seguir la guía de los proveedores de Linux, que normalmente indica crear grupos de volúmenes individuales para /data, /log y /shared.
Consideraciones para el sistema de archivos compartido de HANA
Al dimensionar los sistemas de archivos HANA, la mayor parte de la atención se presta a los sistemas HANA de archivos de datos y de registro. Sin embargo, /hana/shared también desempeña un rol importante en el funcionamiento de un sistema HANA estable, ya que hospeda componentes esenciales como los archivos binarios de HANA.
Si se ha infradimensionado, /hana/shared podría saturarse de E/S debido a operaciones de lectura y escritura excesivas, por ejemplo, al escribir un volcado de memoria grande o durante un seguimiento intensivo, o si la copia de seguridad se escribe en el sistema de archivos /hana/shared. La latencia también podría aumentar.
Si el sistema HANA está en una configuración de alta disponibilidad, las respuestas lentas del sistema de archivos compartidos, es decir /hana/shared podrían provocar tiempos de espera de recursos de clúster. Estos tiempos de espera pueden provocar conmutaciones por error innecesarias, ya que los agentes de recursos de HANA podrían suponer incorrectamente que la base de datos no está disponible.
Las instrucciones de SAP para los tamaños recomendados /hana/shared tienen el siguiente aspecto:
Volumen | Tamaño recomendado: |
---|---|
/hana/shared scale-up | Mín. (1 TB, 1 x RAM) |
/hana/shared scale-out | 1 x RAM del nodo de trabajo por cuatro nodos de trabajo |
Consulte las siguientes notas de SAP para obtener más detalles:
3288971- Preguntas más frecuentes: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager en entornos de replicación del sistema de SAP HANA
1999930 - Preguntas más frecuentes:de análisis de E/S de SAP HANA
Como procedimiento recomendado, ajuste el tamaño /hana/shared para evitar cuellos de botella de rendimiento. Recuerde que un sistema de archivos /hana/shared de tamaño correcto contribuye a la estabilidad y confiabilidad del sistema SAP HANA, especialmente en escenarios de alta disponibilidad.
Configuraciones de Azure Premium Storage v1 para HANA
Para obtener recomendaciones detalladas de configuración de almacenamiento de HANA con Azure Premium Storage v1, lea el documento configuraciones de almacenamiento SSD Premium de máquina virtual de Azure de SAP HANA.
Configuraciones de SSD prémium de Azure v2 para HANA
Para obtener recomendaciones detalladas sobre la configuración de almacenamiento de HANA mediante el almacenamiento SSD Premium v2 de Azure, lea el documento Configuraciones de almacenamiento de SSD Prémium de AZURE de SAP HANA v2.
Configuración de almacenamiento en el disco Ultra de Azure para SAP HANA
Para obtener recomendaciones detalladas sobre la configuración del almacenamiento de HANA mediante el disco Ultra de Azure, lea el documento Configuraciones de almacenamiento en disco Ultra de la máquina virtual de Azure de SAP HANA.
Volúmenes de NFS v4.1 en Azure NetApp Files
Para obtener información detallada sobre Azure NetApp Files para HANA, lea el documento Volúmenes NFS v4.1 en Azure NetApp Files para SAP HANA.
Pasos siguientes
Para más información, consulte:
- Configuraciones de almacenamiento SSD prémium de máquinas virtuales de Azure en SAP HANA.
- Configuraciones de almacenamiento en Disco Ultra de máquinas virtuales de Azure en SAP HANA.
- Volúmenes NFS v4.1 en Azure NetApp Files para SAP HANA.
- Guía sobre la alta disponibilidad de SAP HANA para máquinas virtuales de Azure.