Tipos de Azure Storage para una carga de trabajo de SAP
Azure tiene numerosos tipos de almacenamiento que difieren en gran medida en términos de funcionalidad, rendimiento, latencia y precio. Algunos de los tipos de almacenamiento no son para escenarios de SAP, o bien su uso está limitado en ellos. Sin embargo, hay varios tipos de almacenamiento de Azure que están bien adaptados u optimizados para escenarios específicos de carga de trabajo de SAP. Especialmente en el caso de SAP HANA, algunos tipos de almacenamiento de Azure han recibido certificación para su uso con SAP HANA. En este documento, vamos a repasar los diferentes tipos de almacenamiento y a describir su capacidad y uso con las cargas de trabajo de SAP y los componentes de SAP.
Comentario sobre las unidades que se usan en este artículo. Los proveedores de nube pública se han migrado para usar GiB (gibibyte) o TiB (tebibyte como unidades de tamaño, en lugar del gigabyte o terabyte. Por lo tanto, toda la documentación y los precios de Azure utilizan esas unidades. A lo largo de todo el documento, nos referiremos exclusivamente a estas unidades de tamaño MiB, GiB y TiB. Es posible que sus planes se basen en MB, GB y TB. Por lo tanto, tenga en cuenta algunas pequeñas diferencias en los cálculos si necesita dimensionar un rendimiento de 400 MiB/seg, en lugar de un rendimiento de 250 MiB/seg.
Resistencia de Microsoft Azure Storage
El almacenamiento en Microsoft Azure HDD estándar, SSD estándar, Azure Premium Storage, SSD prémium v2 y en disco Ultra mantiene el VHD base (con SO) y los discos de datos conectados a la máquina virtual o los VHD (discos duros virtuales) en tres copias en tres nodos de almacenamiento diferentes. La conmutación por error a otra réplica y la inicialización de una nueva réplica si hay un error de nodo de almacenamiento es transparente. Como resultado de esta redundancia, NO es necesario usar ningún tipo de capa de redundancia de almacenamiento entre varios discos de Azure. Este hecho se denomina Almacenamiento con redundancia local (LRS). LRS es la opción predeterminada para todos estos tipos de almacenamiento en Azure. Azure NetApp Files proporciona redundancia suficiente para lograr los mismos SLA (Acuerdos de nivel de servicio) que otro almacenamiento nativo de Azure.
Existen más métodos de redundancia, que se describen en el artículo Replicación de Azure Storage y se aplican a algunos de los diferentes tipos de almacenamiento que ofrece Azure.
Nota:
Al utilizar el almacenamiento de Azure para almacenar los datos de la base de datos y el archivo de registro de rehacer, LRS es el único nivel de resistencia admitido en este momento
Tenga en cuenta también que los distintos tipos de almacenamiento de Azure afectan a los SLA de disponibilidad de una sola máquina virtual, tal como se publica en SLA para Virtual Machines.
Azure Managed Disks
Los discos Managed Disks son un tipo de recurso de Azure Resource Manager que puede usarse en lugar de discos duros virtuales almacenados en cuentas de Azure Storage. Los elementos Managed Disks se alinearán automáticamente con el [conjunto de disponibilidad][virtual-machines-manage-availability] de la máquina virtual a la que están asociados. Con esta alineación, se experimenta una mejora de la disponibilidad de la máquina virtual y de los servicios que se ejecutan en esta. Para más información, lea este artículo de información general.
Nota
Es necesario que las nuevas implementaciones de máquinas virtuales que usan almacenamiento en bloque de Azure para sus discos (todo Azure Storage excepto Azure NetApp Files) utilicen discos administrados de Azure para los discos VHD/SO de base y discos de datos que almacenan archivos de base de datos de SAP. Independientemente de si implementa las máquinas virtuales a través del conjunto de disponibilidad, en Availability Zones o aparte de conjuntos y zonas. No es necesario que los discos que se usan con el propósito de almacenar copias de seguridad sean discos administrados.
Escenarios de almacenamiento con cargas de trabajo de SAP
Se necesita almacenamiento persistente en la carga de trabajo de SAP en varios componentes de la pila que implementa en Azure. Estos escenarios son al menos como estos:
- Mantienen el VHD de base de su VM que contiene el sistema operativo y otro software que instale en ese disco. Este disco o VHD es la raíz de la máquina virtual. Los cambios que se realicen en él deben mantenerse. Por lo tanto, la próxima vez que detenga y reinicie la máquina virtual, todos los cambios realizados antes siguen existiendo. Especialmente en los casos en los que Azure implementa la máquina virtual en un host diferente de donde se estaba ejecutando originalmente.
- Discos de datos persistentes. Estos discos son los VHD que se adjuntan para almacenar los datos de la aplicación. Estos datos de aplicación podrían ser archivos de datos y registro/rehacer de una base de datos, archivos de copia de seguridad o instalaciones de software. Es decir, cualquier disco más allá del VHD de base que contiene el sistema operativo.
- Recursos compartidos de archivos o discos compartidos que contienen el directorio de transporte global para NetWeaver o S/4HANA. El contenido de esos recursos compartidos lo consume el software que se ejecuta en varias máquinas virtuales o se usa para crear escenarios de clúster de conmutación por error de alta disponibilidad.
- El directorio /sapmnt o los recursos compartidos de archivos comunes para procesos EDI (intercambio electrónico de datos) o similares. El contenido de esos recursos compartidos lo consume el software que se ejecuta en varias máquinas virtuales o se usa para crear escenarios de clúster de conmutación por error de alta disponibilidad.
En las siguientes secciones, se explican los diferentes tipos de almacenamiento de Azure y su uso para los cuatro escenarios de cargas de trabajo de SAP. En el artículo ¿Qué tipos de disco están disponibles en Azure? se documenta una categorización general de cómo se deben usar los distintos tipos de almacenamiento de Azure. Las recomendaciones para usar los diferentes tipos de almacenamiento de Azure para una carga de trabajo de SAP no van a ser muy diferentes.
Para conocer las restricciones de compatibilidad con los tipos de almacenamiento de Azure para SAP NetWeaver/nivel de aplicación de S/4HANA, lea la nota de soporte técnico de SAP 2015553. Para los tipos de almacenamiento de Azure certificados y compatibles con SAP HANA, lea el artículo Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA.
En las secciones que describen los diferentes tipos de almacenamiento de Azure se proporcionará más información sobre las restricciones y las posibilidades que ofrece el almacenamiento compatible con SAP.
Opciones de almacenamiento al usar la replicación de DBMS
Nuestras arquitecturas de referencia prevén el uso de funcionalidades de DBMS (sistema de administración de bases de datos) como SQL Server Always On, la replicación del sistema de HANA, DB2 HADR u Oracle Data Guard. En caso de que use estas tecnologías entre dos o varias máquinas virtuales de Azure, los tipos de almacenamiento elegidos para cada una de las VM deben ser los mismos. Significa que la configuración de almacenamiento entre el nodo activo y el nodo de réplica en la configuración de alta disponibilidad de DBMS debe ser la misma.
Recomendaciones de almacenamiento para escenarios de almacenamiento de SAP
Antes de entrar en detalles, presentamos el resumen y las recomendaciones al principio del documento. Por su parte, los detalles de los tipos concretos de Azure Storage se presentan en esta sección del documento. El resumen de las recomendaciones de almacenamiento para los escenarios de almacenamiento de SAP en una tabla tiene el siguiente aspecto:
| Escenario de uso | HDD estándar | SSD estándar | Premium Storage | SSD prémium v2 | Disco Ultra | Azure NetApp Files | Azure Premium Files |
|---|---|---|---|---|---|---|---|
| Disco del sistema operativo | No adecuado | Adecuación restringida (no en prod.) | Recomendado | No es posible | No es posible | No es posible | No es posible |
| Directorio de transporte global | No compatible | No compatible | Recomendado | Recomendado | Recomendado | Recomendado | Muy recomendado |
| /sapmnt | No adecuado | Adecuación restringida (no en prod.) | Recomendado | Recomendado | Recomendado | Recomendado | Muy recomendado |
| Familias de máquinas virtuales M/MV2 de SAP HANA en volumen de datos de DBMS | No compatible | No compatible | Recomendado | Recomendado | Recomendado | Recomendado | No compatible |
| Familias de máquinas virtuales M/MV2 de SAP HANA en volumen de registro de DBMS | No compatible | No compatible | Recomendado1 | Recomendado | Recomendado | Recomendado | No compatible |
| Familias de máquinas virtuales Esv3/Edsv4 de SAP HANA en volumen de datos de DBMS | No compatible | No compatible | Recomendado | Recomendado | Recomendado | Recomendado | No compatible |
| Familias de máquinas virtuales Esv3/Edsv4 de SAP HANA en volumen de registro de DBMS | No compatible | No compatible | No compatible | Recomendado | Recomendado | Recomendado | No compatible |
| Volumen de recursos compartidos de HANA | No compatible | No compatible | Recomendado | Recomendado | Recomendado | Recomendado | Recomendado |
| Volumen de datos DBMS no HANA | No compatible | Adecuación restringida (no en prod.) | Recomendado | Recomendado | Recomendado | Solo para versiones específicas de Oracle en Oracle Linux, Db2 y SAP ASE en SLES/RHEL Linux | No compatible |
| Familias de máquinas virtuales M/MV2 no de HANA en volumen de registro de DBMS | No compatible | Adecuación restringida (no en prod.) | Recomendado1 | Recomendado | Recomendado | Solo para versiones específicas de Oracle en Oracle Linux, Db2 y SAP ASE en SLES/RHEL Linux | No compatible |
| Familias de máquinas virtuales no M/MV2 no de HANA en volumen de registro de DBMS | No compatible | adecuación restringida (no en prod.) | Adecuado para cargas de trabajo hasta de tamaño medio | Recomendado | Recomendado | Solo para versiones específicas de Oracle en Oracle Linux, Db2 y SAP ASE en SLES/RHEL Linux | No compatible |
1 Con el uso del Acelerador de escritura de Azure para las familias de máquinas virtuales M/MV2 para los volúmenes de registro/rehacer.
Características que puede esperar de la lista de tipos de almacenamiento diferentes, como:
| Escenario de uso | HDD estándar | SSD estándar | Premium Storage | SSD prémium v2 | Disco Ultra | Azure NetApp Files | Azure Premium Files |
|---|---|---|---|---|---|---|---|
| Acuerdo de Nivel de Servicio rendimiento/IOPS | No | No | Sí | Sí | Sí | Sí | Sí |
| Lecturas de latencia | Alto | Medio a alto | Bajo | submilisegundo | submilisegundo | submilisegundo | low |
| Escrituras de latencia | Alto | Medio a alto | Baja (submilisegundo1) | submilisegundo | submilisegundo | submilisegundo | low |
| HANA compatible | No | No | sí1 | Sí | Sí | Sí | No |
| Instantáneas de disco posibles | Sí | Sí | Sí | Sí3 | No2 | Sí | No |
| Asignación de discos en diferentes clústeres de almacenamiento cuando se usan conjuntos de disponibilidad | Mediante discos administrados | Mediante discos administrados | Mediante discos administrados | Tipo de disco no compatible con máquinas virtuales implementadas mediante conjuntos de disponibilidad | Tipo de disco no compatible con máquinas virtuales implementadas mediante conjuntos de disponibilidad | No3 | No |
| Alineación con Availability Zones | Sí | Sí | Sí | Sí | Sí | En versión preliminar pública | No |
| Redundancia zonal sincrónica | No para discos administrados | No para discos administrados | No se admite para DBMS | No | N.º | No | Sí |
| Redundancia zonal asincrónica | No para discos administrados | No para discos administrados | No se admite para DBMS | No | No | En versión preliminar | No |
| Redundancia geográfica | No para discos administrados | No para discos administrados | No | N.º | No | Posibilidad | No |
1 Con el uso del Acelerador de escritura de Azure para las familias de máquinas virtuales M/MV2 para los volúmenes de registro/rehacer.
2 La creación de distintos grupos de capacidad de Azure NetApp Files no garantiza la implementación de grupos de capacidad en distintas unidades de almacenamiento
3 Las instantáneas (incrementales) de un disco Ultra o SSD prémium v2 no se pueden usar inmediatamente después de su creación. La copia en segundo plano debe completarse para poder crear un disco a partir de la instantánea
Importante
Consulte la sección Azure NetApp Files de este documento para encontrar detalles sobre la ubicación por proximidad de volúmenes y máquinas virtuales NFS cuando se requieren latencias de menos de 1 milisegundo.
Azure Premium Storage
El almacenamiento SSD Premium de Azure se introdujo con el objetivo de proporcionar lo siguiente:
- Baja latencia de E/S
- Acuerdo de Nivel de Servicio para IOPS y rendimiento
- Menor variabilidad de la latencia de E/S
Este tipo de almacenamiento está destinado a cargas de trabajo de DBMS, tráfico de almacenamiento que requiere una latencia baja de milisegundos de un solo dígito y Acuerdos de Nivel de Servicio para IOPS y rendimiento. La base del coste para Azure Premium Storage no es el volumen real de los datos almacenados en estos discos, sino la categoría de tamaño de tal disco, independientemente de la cantidad de datos almacenados en él. También puede crear discos en Premium Storage sin correspondencia directa con las categorías de tamaño que se muestran en el artículo SSD prémium. Las conclusiones de este artículo son las siguientes:
- El almacenamiento se organiza en intervalos. Por ejemplo, un disco en el intervalo de capacidad de 513 GiB a 1024 GiB comparte las mismas funcionalidades y los mismos costos mensuales
- La IOPS por GiB no realiza un seguimiento lineal de las categorías de tamaño. Los discos más pequeños por debajo de 32 GiB tienen tasas de IOPS mayores por GiB. En el caso de los discos de más de 32 GiB a 1024 GiB, la tasa de IOPS por GiB se encuentra entre 4-5 IOPS por GiB. En el caso de discos más grandes, de hasta 32 767 GiB, la tasa de IOPS por GiB está por debajo de 1.
- El rendimiento de E/S de este almacenamiento no es lineal con el tamaño de la categoría de disco. En el caso de los discos más pequeños, como la categoría con capacidad entre 65 GiB y 128 GiB, el rendimiento se encuentra en torno a 780 KB por GiB. Mientras que para los discos de gran tamaño, como un disco de 32 767 GiB, el rendimiento está alrededor de 28 KB por GiB.
- Los Acuerdos de Nivel de Servicio de IOPS y rendimiento no se pueden modificar sin cambiar la capacidad del disco.
La matriz de funcionalidad para la carga de trabajo de SAP tiene el siguiente aspecto:
| Capacidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | Adecuado | Todos los sistemas |
| Disco de datos | Adecuado | Todos los sistemas: especialmente para SAP HANA |
| Directorio de transporte global de SAP | Sí | Compatible |
| SAP sapmnt | Adecuado | Todos los sistemas |
| Almacenamiento de copia de seguridad | Adecuado | Para el almacenamiento a corto plazo de copias de seguridad |
| Recursos compartidos/disco compartido | No disponible | Necesita Azure Premium Files o de terceros |
| Resistencia | LRS | No hay almacenamiento con redundancia geográfica o almacenamiento con redundancia de zona disponible para los discos |
| Latencia | Baja a media | - |
| SLA DE IOPS | Sí | - |
| IOPS lineal a capacidad | semilineal entre corchetes | Precios de Managed Disk |
| Número máximo de IOPS por disco | 20 000 en función del tamaño del disco | Tenga también en cuenta los límites de la máquina virtual. |
| SLA de rendimiento | Sí | - |
| Rendimiento lineal de la capacidad | Semilineal entre corchetes | Precios de Managed Disk |
| Certificación de HANA | Sí | especialmente para SAP HANA |
| Compatibilidad con el Acelerador de escritura de Azure | No | - |
| Seguridad de disco | Sí | - |
| Instantáneas de disco posibles | Sí | - |
| Instantáneas de máquina virtual de Azure Backup posibles | Sí | - |
| Costos | Media | - |
Azure Premium Storage no cumple los indicadores clave de rendimiento de latencia de almacenamiento de SAP HANA con los tipos comunes de almacenamiento en caché que se ofrecen con Azure Premium Storage. Para cumplir los KPI de latencia de almacenamiento para escrituras de registro de SAP HANA, debe usar el almacenamiento en caché del Acelerador de escritura de Azure como se describe en el artículo Habilitar el acelerador de escritura. El Acelerador de escritura de Azure beneficia a todos los demás sistemas DBMS para sus escrituras de registro de transacciones y de rehacer. Por lo tanto, se recomienda utilizarlo en todas las implementaciones de DBMS de SAP. Para SAP HANA, es obligatorio el uso del Acelerador de escritura de Azure para /hana/log junto con Azure Premium Storage.
Resumen: Azure Premium Storage es uno de los tipos de almacenamiento de Azure recomendados para la carga de trabajo de SAP. Esta recomendación se aplica a los sistemas de producción y de no producción. Azure Premium Storage es adecuado para controlar las cargas de trabajo de base de datos. El uso del Acelerador de escritura de Azure va a mejorar considerablemente la latencia de escritura en discos Premium de Azure. Sin embargo, para los sistemas DBMS con tasas de rendimiento y de IOPS altas, debe sobreaprovisionar la capacidad de almacenamiento. La otra opción es usar una funcionalidad como los Espacios de almacenamiento de Windows o administradores de volúmenes lógicos en Linux para crear conjuntos seccionados que le proporcionen la capacidad deseada por un lado, pero también las operaciones IOPS o el rendimiento que necesite con la mejor rentabilidad.
Funcionalidad de ráfaga de Azure para Premium Storage
En el caso de los discos de Azure Premium Storage con una capacidad de 512 GiB o inferior, se ofrece funcionalidad de ráfaga. La forma exacta en que funciona la ráfaga de disco se describe en el artículo Seguridad de disco. Al leer el artículo, comprenderá el concepto de acumulación de IOPS y rendimiento en los casos en que la carga de trabajo de E/S esté por debajo del valor de IOPS y de rendimiento de los discos nominal (para obtener más información sobre el rendimiento nominal, consulte Precios del disco administrado). Acumulará la diferencia de IOPS y rendimiento entre el uso actual y los valores nominales del disco. Las ráfagas están limitadas a un máximo de 30 minutos.
Los casos ideales en los que se puede planear esta funcionalidad de ráfaga serán, probablemente, los volúmenes o discos que contengan archivos de datos para distintos DBMS. Se espera que la carga de trabajo de E/S para esos volúmenes, especialmente con sistemas de gama pequeña o mediana, tenga el aspecto siguiente:
- Carga de trabajo de lectura de baja a moderada, puesto que los datos se almacenan en caché en la memoria. Al igual que con SAP HANA también pueden guardarse completamente en la memoria.
- Ráfagas de escritura desencadenadas por puntos de control o puntos de retorno de la base de datos que se emiten de forma regular
- Carga de trabajo de copia de seguridad que se lee en un flujo continuo en los casos en que las copias de seguridad no se ejecutan mediante instantáneas de almacenamiento
- En el caso de SAP HANA, carga de los datos en memoria después de reiniciar una instancia
Especialmente en sistemas DBMS más pequeños en los que la carga de trabajo controla solo unos cientos de transacciones por segundo, esta funcionalidad de ráfaga puede tener sentido para los discos o volúmenes que almacenan la transacción o el registro de fase de puesta al día. La carga de trabajo esperada en este disco o volúmenes tiene el siguiente aspecto:
- Las escrituras regulares en el disco que dependen de la carga de trabajo y la naturaleza de la carga de trabajo, ya que es probable que todas las confirmaciones emitidas por la aplicación desencadenen una operación de E/S
- Mayor carga de trabajo en el rendimiento para los casos de tareas operativas, como crear o recompilar índices
- Ráfagas de lectura al realizar copias de seguridad de registros de transacciones o fase de puesta al día
SSD prémium v2 de Azure
El almacenamiento SSD prémium v2 de Azure es una nueva versión de almacenamiento prémium que se ha introducido con el objetivo de proporcionar lo siguiente:
- Latencia de E/S de submilisegundos para tamaños de E/S de lectura y escritura más pequeños
- Acuerdo de Nivel de Servicio para IOPS y rendimiento
- Capacidad de pago por los GB aprovisionados
- Conjunto predeterminado de rendimiento de almacenamiento e IOPS por disco
- Posibilidad de agregar más IOPS y rendimiento a cada disco y pagar aparte estos recursos adicionales aprovisionados
- Obtención de la certificación de SAP HANA sin ayuda de otras funcionalidades, como el Acelerador de escritura de Azure u otras cachés
Este tipo de almacenamiento está destinado a cargas de trabajo de DBMS, tráfico de almacenamiento que requiere una latencia de submilisegundos y Acuerdos de Nivel de Servicio para IOPS y rendimiento. Los discos SSD prémium v2 se entregan con un conjunto predeterminado de 3000 IOPS y un rendimiento de 125 MBps. Además, ofrecen la posibilidad de agregar más IOPS y rendimiento a los discos individuales. Los precios del almacenamiento se estructuran de forma que agregar más rendimiento o IOPS no influya en el precio de forma significativa. Sin embargo, le dejamos decidir cómo tendrá el aspecto de la configuración de almacenamiento para SSD prémium v2. Para un comienzo básico, lea Configuraciones de almacenamiento SSD prémium v2 de máquinas virtuales de Azure en SAP HANA.
Para ver las regiones en las que está disponible este nuevo tipo de almacenamiento en bloque y las restricciones aplicables, lea el documento SSD prémium v2.
La matriz de funcionalidad para la carga de trabajo de SAP tiene el siguiente aspecto:
| Capacidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | No compatible | Ningún sistema |
| Disco de datos | Adecuado | Todos los sistemas |
| Directorio de transporte global de SAP | Sí | Todos los sistemas |
| SAP sapmnt | Adecuado | Todos los sistemas |
| Almacenamiento de copia de seguridad | Adecuado | Para el almacenamiento a corto plazo de copias de seguridad |
| Recursos compartidos/disco compartido | No disponible | Necesita Azure Files Premium o Azure NetApp Files |
| Resistencia | LRS | No hay almacenamiento con redundancia geográfica o almacenamiento con redundancia de zona disponible para los discos |
| Latencia | submilisegundo | - |
| SLA DE IOPS | Sí | - |
| IOPS lineal a capacidad | semilineal | Precios de Managed Disk |
| Número máximo de IOPS por disco | 80 000 en función del tamaño del disco | Tenga también en cuenta los límites de la máquina virtual. |
| SLA de rendimiento | Sí | - |
| Rendimiento lineal de la capacidad | Semilineal | Precios de Managed Disk |
| Certificación de HANA | Sí | - |
| Compatibilidad con el Acelerador de escritura de Azure | No | - |
| Seguridad de disco | No | - |
| Instantáneas de disco posibles | Sí1 | - |
| Instantáneas de máquina virtual de Azure Backup posibles | Sí | - |
| Costos | Media | - |
1 Las instantáneas (incrementales) de un disco Ultra o SSD prémium v2 no se pueden usar inmediatamente después de su creación. La copia en segundo plano debe completarse para poder crear un disco a partir de la instantánea
Al contrario que Azure Premium Storage, SSD prémium v2 de Azure cumple los indicadores clave de rendimiento de latencia de almacenamiento de SAP HANA. Como resultado, NO es necesario usar el almacenamiento en caché del Acelerador de escritura de Azure, tal y como se describe en el artículo Habilitar el acelerador de escritura.
Resumen: SSD prémium v2 de Azure es el almacenamiento en bloque que se ajusta a la mejor relación precio/rendimiento para las cargas de trabajo de SAP. SSD prémium v2 de Azure es adecuado para controlar las cargas de trabajo de base de datos. La latencia de submilisegundos es el almacenamiento ideal para las cargas de trabajo de DBMS más exigentes. Aunque es un tipo de almacenamiento más reciente que se publicó en noviembre de 2022. Por lo tanto, puede que algunas de sus limitaciones se vayan eliminando en los próximos meses.
Disco Ultra de Azure
Los discos Ultra de Azure ofrecen un alto rendimiento, un número elevado de IOPS y un almacenamiento en disco coherente y de baja latencia para máquinas virtuales IaaS de Azure. Entre algunas de las ventajas de los discos Ultra se incluyen la capacidad de cambiar dinámicamente el valor de IOPS y el rendimiento del disco, junto con sus cargas de trabajo, sin necesidad de reiniciar las máquinas virtuales (VM). Los discos Ultra son adecuados para cargas de trabajo con un uso intensivo de datos, como la carga de trabajo DBMS de SAP. Los discos Ultra solo se pueden usar como discos de datos, y no se pueden usar como disco VHD de base que almacena el sistema operativo. Se recomienda el uso de Azure Premium Storage como disco VHD de base.
Al crear un disco Ultra, puede definir tres dimensiones:
- La capacidad del disco. Los intervalos van de 4 GiB a 65 536 GiB.
- IOPS aprovisionada para el disco. Se aplican valores máximos diferentes a la capacidad del disco. Lea el artículo Disco Ultra para obtener más detalles
- Ancho de banda de almacenamiento aprovisionado. Se aplica un ancho de banda máximo diferente en función de la capacidad del disco. Lea el artículo Disco Ultra para obtener más detalles
El costo de un solo disco lo determinan las tres dimensiones que se pueden definir para los discos concretos por separado.
La matriz de funcionalidad para la carga de trabajo de SAP tiene el siguiente aspecto:
| Capacidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | No funciona | - |
| Disco de datos | Adecuado | Todos los sistemas |
| Directorio de transporte global de SAP | Sí | Compatible |
| SAP sapmnt | Adecuado | Todos los sistemas |
| Almacenamiento de copia de seguridad | Adecuado | Para el almacenamiento a corto plazo de copias de seguridad |
| Recursos compartidos/disco compartido | No disponible | Necesita terceros |
| Resistencia | LRS | No hay almacenamiento con redundancia geográfica o almacenamiento con redundancia de zona disponible para los discos |
| Latencia | Muy baja | - |
| SLA DE IOPS | Sí | - |
| IOPS lineal a capacidad | Semilineal entre corchetes | Precios de Managed Disk |
| Número máximo de IOPS por disco | 1200 a 160 000 | depende de la capacidad del disco |
| SLA de rendimiento | Sí | - |
| Rendimiento lineal de la capacidad | Semilineal entre corchetes | Precios de Managed Disk |
| Certificación de HANA | Sí | - |
| Compatibilidad con el Acelerador de escritura de Azure | No | - |
| Seguridad de disco | Sí | - |
| Instantáneas de disco posibles | Sí1 | - |
| Instantáneas de máquina virtual de Azure Backup posibles | Sí | - |
| Costes | Mayor que Premium Storage | - |
1 Las instantáneas (incrementales) de un disco Ultra o SSD prémium v2 no se pueden usar inmediatamente después de su creación. La copia en segundo plano debe completarse para poder crear un disco a partir de la instantánea
Resumen: Los discos Ultra de Azure son un almacenamiento adecuado con una latencia de submilisegundos baja para todos los tipos de carga de trabajo de SAP. Hasta ahora, los discos Ultra solo se pueden usar en combinaciones con máquinas virtuales que se han implementado a través de Availability Zones (implementación de zonas). En contraposición al resto del almacenamiento, no se puede usar un disco Ultra para el disco VHD de base. El disco Ultra es idóneo para los casos en los que la carga de trabajo de E/S fluctúa mucho y desea adaptar el rendimiento de almacenamiento implementado o IOPS a patrones de carga de trabajo de almacenamiento en lugar de cambiar el tamaño para el uso máximo de ancho de banda e IOPS.
Azure NetApp Files
Azure NetApp Files es un servicio de almacenamiento de archivos nativo de Azure, de clase empresarial y alto rendimiento, certificado para su uso con SAP HANA. Proporciona Volúmenes como servicio para los que crear grupos de capacidad, volúmenes y cuentas de NetApp. Azure NetApp Files le permite seleccionar los niveles de servicio y rendimiento y administrar la protección de datos para crear y administrar recursos compartidos de archivos escalables, de alto rendimiento y de alta disponibilidad mediante los mismos protocolos y herramientas que ya conoce y que usa en el entorno local.
Los siguientes tipos de carga de trabajo de SAP se admiten en volúmenes de Azure NetApp Files:
- Carga de trabajo de DBMS de SAP
- Recurso compartido de SAPMNT
- Directorio de transporte global
Azure NetApp Files está disponible en tres niveles de servicio, cada uno con sus propias especificaciones de rendimiento y precios. Cuál es el adecuado para la implementación depende del tamaño de la implementación. Las recomendaciones de ajuste de tamaño personalizadas están disponibles en el Estimador de costo total de propiedad de SAP on Azure NetApp Files.
Para obtener información sobre los niveles de servicio, consulte Niveles de servicio para Azure NetApp Files.
Implementación de volúmenes
Para obtener resultados óptimos, implemente los volúmenes con el grupo de volúmenes de aplicaciones para SAP HANA. El grupo de volúmenes de aplicación coloca los volúmenes en ubicaciones óptimas de la infraestructura de Azure mediante reglas de afinidad y antiafinidad para reducir la contención y lograr el mejor rendimiento y la latencia más baja.
Nota:
Los grupos de capacidad son una unidad de aprovisionamiento básica para Azure NetApp Files. Los grupos de capacidad se ofrecen a partir de 1 TiB en tamaño; puede expandir un grupo de capacidad en incrementos de 1 TiB. Los grupos de capacidad son la unidad primaria de los volúmenes. Para obtener información sobre el ajuste de tamaño, consulte Límites de recursos de Azure NetApp Files. Para conocer los precios, consulte Precios Azure NetApp Files.
Azure NetApp Files es compatible con varios escenarios de cargas de trabajo SAP:
- Implementaciones de SAP HANA que usan recursos compartidos NFS para volúmenes /hana/data y /hana/log para volúmenes /hana/shared como se documenta en las configuraciones de almacenamiento de máquinas virtuales de Azure de SAP HANA
- Provisión de recursos compartidos de SMB o NFS para el directorio de transporte global de SAP
- El recurso compartido sapmnt en escenarios de alta disponibilidad, como se documenta en:
- Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en Windows con Azure NetApp Files (SMB) para aplicaciones SAP
- Alta disponibilidad de SAP NetWeaver en VM de Azure en SUSE Linux Enterprise Server con Azure NetApp Files para las aplicaciones de SAP
- Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver en Red Hat Enterprise Linux con Azure NetApp Files para aplicaciones SAP
- IBM Db2 en una máquina virtual de Azure basada en Suse o Red Hat Linux
- Las implementaciones de SAP en Oracle en un sistema operativo invitado Oracle Linux mediante dNFS para volúmenes registros de fase de puesta al día y datos de Oracle. Puede encontrar más detalles en el artículo Implementación de DBMS de Oracle de Azure Virtual Machines para la carga de trabajo de SAP
- SAP en ASE en un sistema operativo invitado Suse o Red Hat Linux
- SAP en MAXDB en un sistema operativo invitado Suse o Red Hat Linux
- SAP en Microsoft SQL Server con volúmenes SMB
Nota:
En el caso de las cargas de trabajo de DBMS en Linux, use volúmenes basados en NFS en Azure NetApp Files.
Desacoplar el rendimiento del tamaño del volumen
El almacenamiento para aplicaciones de bases de datos suele tener unos requisitos de rendimiento que no escalan linealmente con el tamaño de los volúmenes, es decir, los volúmenes de registro tienen un tamaño relativamente pequeño pero requieren altos niveles de rendimiento.
Azure NetApp Files le permite asignar el caudal del volumen de rendimiento independientemente del tamaño del volumen cuando se utiliza un grupo de capacidad de tipo QoS manual.
Este es un ejemplo:
- Un volumen para archivos de bases de datos requiere un rendimiento de 500 MiB/s y una capacidad de 39 TiB
- Un volumen para archivos de registro requiere un rendimiento de 2000 MiB/s y una capacidad de 1 TiB
Puede crear un grupo de capacidad QoS manual para este escenario y asignar el rendimiento independientemente de los tamaños de volumen. La capacidad total requerida es de 40 TiB, y el presupuesto de rendimiento total es de 2500 MiB/s. Un grupo de capacidad en el nivel de servicio Premium (64 MiB/s por TiB asignado) satisface tanto los requisitos de rendimiento como de capacidad (40 MiB x 64 MiB/s/TiB = 2560 TiB).
Un escalado lineal del rendimiento requeriría un sobre aprovisionamiento considerable del volumen de registro para alcanzar el requisito de rendimiento. Para lograr el rendimiento de 2000 MiB/s para el volumen de registro, tendría que implementar un grupo de capacidad en el nivel Ultra (128 MiB/s por TiB asignado) de 16 TiB, lo que da lugar a un sobreaprovisionamiento y, por tanto, un desperdicio de capacidad de 15 TiB.
Utilice la calculadora de rendimiento de Azure NetApp Files para obtener una estimación de su situación.
La matriz de funcionalidades de la carga de trabajo de SAP en Azure NetApp Files tiene el siguiente aspecto:
| Funcionalidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | Uso del disco administrado | - |
| Disco de datos | Adecuado | SAP HANA, Oracle en Oracle Linux, Db2 y SAP ASE en SLES/RHEL, MAXDB, SQL Server |
| Directorio de transporte global de SAP | Sí | SMB (solo Windows) y NFS (solo Linux) |
| SAP sapmnt | Adecuado | SMB (solo Windows) o NFS (solo Linux) |
| Almacenamiento de copia de seguridad | Adecuado | Uso de instantáneas o copia de seguridad de Azure NetApp Files. La copia de seguridad de registros para HANA también se puede usar como destino de copia de seguridad basada en archivos. |
| Recursos compartidos/disco compartido | Sí | SMB, NFS |
| Resistencia | LRS y GRS | GRS con replicación entre regiones; ZRS con replicación entre zonas |
| Latencia | Muy baja | Normalmente menos de 1 ms |
| SLA DE IOPS | Sí | - |
| IOPS lineal a capacidad | Lineal con QoS automático; configurable independientemente con QoS manual | Tres niveles de servicio disponibles |
| SLA de rendimiento | Sí | Las recomendaciones de dimensionamiento están disponibles en SAP en el estimador de costo total de propiedad de Azure NetApp Files |
| Rendimiento lineal de la capacidad | Lineal con QoS automático; configurable independientemente con QoS manual | Tres niveles de servicio disponibles |
| Certificación de HANA | Sí | - |
| Instantáneas de disco posibles | Sí | Consulte Funcionamiento de las instantáneas de Azure NetApp Files |
| Instantánea coherente con la aplicación y orquestación de copia de seguridad | No | Utilice AzAcSnap o SnapCenter |
| Costos | Uso de herramientas de estimación de costo total de propiedad | Use el SAP en el estimador de costo total de propiedad de Azure NetApp Files y escriba el tamaño del entorno. |
Otras funciones integradas del almacenamiento de Azure NetApp Files:
- Funcionalidad para realizar instantáneas coherentes con la aplicación de volumen mediante AzAcSnap
- Clonación de volúmenes de Azure NetApp Files a partir de instantáneas para pruebas y desarrollo
- Restauración de volúmenes a partir de instantáneas (reversión instantánea) para restauraciones rápidas de daños y errores
Importante
Específicamente para las implementaciones de bases de datos, quiere lograr latencias bajas para al menos los registros de puesta al día. Especialmente para SAP HANA, SAP requiere una latencia inferior a 1 milisegundo para las escrituras de redo log de HANA de menor tamaño. Para llegar a estas latencias, consulte las posibilidades siguientes.
Importante
Al implementar volúmenes de Azure NetApp Files, tome nota de la zona en las máquinas virtuales se han implementado o se van a implementar. Asegúrese de seleccionar la misma zona. Esta funcionalidad se documenta en el artículo Administración de la ubicación de volumen de zona de disponibilidad para Azure NetApp Files. El grupo de volúmenes de aplicaciones para SAP HANA usa la misma funcionalidad para implementar los volúmenes en la proximidad más cercana posible a las máquinas virtuales de la aplicación.
La motivación para tener este tipo de alineación de zona de disponibilidad es la reducción de la superficie de riesgo al tener los recursos compartidos NFS en la misma zona de disponibilidad que las máquinas virtuales de la aplicación.
- Implemente volúmenes de Azure NetApp Files para la implementación de SAP HANA mediante un grupo de volúmenes de aplicaciones para SAP HANA. La ventaja del grupo de volúmenes de aplicaciones es que los volúmenes de datos se implementan en varios puntos de conexión de almacenamiento, lo que reduce la contención de red y mejora el rendimiento.
Resumen: Azure NetApp Files es una solución de almacenamiento de baja latencia certificada para SAP HANA. El servicio proporciona volúmenes extraídos de uno o varios grupos de capacidad. Los grupos de capacidad están disponibles en tres niveles de servicio que definen la capacidad total y el rendimiento asignados. Los volúmenes se pueden cambiar de tamaño y el rendimiento asignado se puede ajustar sin interrupción del servicio para satisfacer los requisitos cambiantes y controlar el costo. El servicio proporciona funcionalidad para replicar volúmenes en otras regiones o zonas con fines de recuperación ante desastres y continuidad empresarial.
Azure Premium Files
Azure Premium Files es un almacenamiento compartido que ofrece SMB y NFS por un precio moderado y una latencia suficiente para controlar los recursos compartidos del nivel de aplicación de SAP. Además, Azure Premium Files ofrece replicación sincrónica por zonas de los recursos compartidos que está automatizada de forma que, en caso de que se produzca un error en una réplica, puede asumir el control otra réplica de una zona distinta. Al contrario que en Azure NetApp Files, no hay niveles de rendimiento. Tampoco es necesario contar con un grupo de capacidad. El pago se basa en la capacidad real aprovisionada de los distintos recursos compartidos. Azure Premium Files no se ha probado como almacenamiento de DBMS para cargas de trabajo de SAP. En su lugar, el escenario de uso de la carga de trabajo de SAP se ha centrado en todos los tipos de recursos compartidos SMB y NFS, ya que se utilizan en el nivel de aplicación de SAP. Azure Premium Files también es adecuado para el uso en /hana/shared.
Nota:
Hasta el momento, no se admite ninguna carga de trabajo DBMS de SAP en los volúmenes compartidos basados en Azure Premium Files.
Lista de escenarios de SAP admitidos en Azure Premium Files, como:
- Provisión de recursos compartidos de SMB o NFS para el directorio de transporte global de SAP
- Uso como recurso compartido para interfaces para sistemas SAP y procesos EDI
- El recurso compartido sapmnt en escenarios de alta disponibilidad, como se documenta en:
- Alta disponibilidad de SAP NetWeaver en máquinas virtuales Azure que se ejecutan en SUSE Linux Enterprise Server utilizando NFS en Azure Files
- Alta disponibilidad de SAP NetWeaver en máquinas virtuales Azure que se ejecutan en Red Hat Enterprise Linux utilizando NFS en Azure Files
- Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en Windows con Azure Files Premium SMB para aplicaciones SAP
- Alta disponibilidad para el sistema de escalabilidad horizontal de SAP HANA con HSR en SUSE Linux Enterprise Server
Azure Premium Files comienza por usar una mayor cantidad de IOPS con el tamaño mínimo de recurso compartido de 100 GB en comparación con Azure NetApp Files. Este listón superior de IOPS puede evitar el sobreaprovisionamiento de capacidad para lograr determinados valores de IOPS y rendimiento. En relación con el rendimiento de almacenamiento e IOPS, lea la sección Objetivos de escalabilidad de Azure Files en Objetivos de escalabilidad y rendimiento de Azure Files.
Nota:
Debido a la arquitectura en capas de Azure Premium Files, la latencia de acceso a los metadatos de los archivos almacenados en recursos compartidos es significativamente mayor que con Azure NetApp Files. Esta mayor latencia puede afectar a la creación y eliminación masiva de archivos de instancia. Pero también puede tener un impacto notable en el tiempo que se tarda en enumerar el contenido de directorios grandes, que contiene cientos de miles de archivos. El caso de uso principal que vemos que afecta a esta mayor latencia de metadatos es el uso como recurso compartido de interfaz donde los clientes pueden encontrar cientos de miles o incluso millones de creaciones de archivos y eliminaciones masivas todos los días. Por lo tanto, debe probar diligentemente los escenarios de uso compartido de interfaz. Para determinar si la carga de trabajo tiene muchos metadatos, marque Carga de trabajo de metadatos o espacio de nombres intensivo
La matriz de funcionalidad para la carga de trabajo de SAP tiene el siguiente aspecto:
| Capacidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | No funciona | - |
| Disco de datos | No se admite para cargas de trabajo de SAP | - |
| Directorio de transporte global de SAP | Sí | SMB y NFS |
| SAP sapmnt | Adecuado | Todos los sistemas SMB (solo Windows) o NFS (solo Linux) |
| Almacenamiento de copia de seguridad | Adecuado | - |
| Recursos compartidos/disco compartido | Sí | SMB 3.0, NFS v4.1 |
| Resistencia | LRS y ZRS | GRS no disponible para Azure Premium Files |
| Latencia | low | - |
| SLA DE IOPS | Sí | - |
| IOPS lineal a capacidad | estrictamente lineal | - |
| SLA de rendimiento | Sí | - |
| Rendimiento lineal de la capacidad | estrictamente lineal | - |
| Certificación de HANA | No | - |
| Instantáneas de disco posibles | Sí | - |
| Instantáneas de máquina virtual de Azure Backup posibles | No | - |
| Costos | low | - |
Resumen: Azure Premium Files es un almacenamiento de baja latencia que permite implementar volúmenes o recursos compartidos de NFS y SMB. Azure Premium Files ofrece una excelente relación precio/rendimiento para los recursos compartidos del nivel de aplicación de SAP. También proporciona replicación sincrónica por zonas para estos recursos compartidos. Hasta el momento, no se admite este tipo de almacenamiento para cargas de trabajo DBMS de SAP. Sin embargo, se puede usar para volúmenes /hana/shared.
Almacenamiento SSD estándar de Azure
En comparación con el almacenamiento HDD estándar de Azure, el almacenamiento SSD estándar de Azure ofrece una mejor disponibilidad, coherencia, confiabilidad y latencia. Está optimizado para cargas de trabajo que necesitan un rendimiento coherente a niveles inferiores de IOPS. Esta opción es el almacenamiento mínimo que se usa para sistemas SAP que no son de producción y que tienen bajas demandas de IOPS y rendimiento. La matriz de funcionalidad para la carga de trabajo de SAP tiene el siguiente aspecto:
| Capacidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | Adecuación restringida | Sistemas que no son de producción |
| Disco de datos | Adecuación restringida | Algunos sistemas que no son de producción con bajas solicitudes de IOPS y latencia |
| Directorio de transporte global de SAP | No | No compatible |
| SAP sapmnt | Adecuación restringida | Sistemas que no son de producción |
| Almacenamiento de copia de seguridad | Adecuado | - |
| Recursos compartidos/disco compartido | No disponible | Necesita terceros |
| Resistencia | LRS y GRS | No hay almacenamiento con redundancia de zona disponible para los discos |
| Latencia | high | Demasiado alta para el directorio de transporte global de SAP o sistemas de producción |
| SLA DE IOPS | No | - |
| Número máximo de IOPS por disco | 500 | Independiente del tamaño del disco |
| SLA de rendimiento | No | - |
| Certificación de HANA | No | - |
| Instantáneas de disco posibles | Sí | - |
| Instantáneas de máquina virtual de Azure Backup posibles | Sí | - |
| Costes | Bajo | - |
Resumen: El almacenamiento de SSD estándar de Azure es la recomendación mínima para las máquinas virtuales que no son de producción para VHD de base, implementaciones de DBMS eventuales con insensibilidad relativa a la latencia o bajas tasas de IOPS y de rendimiento. Este tipo de almacenamiento de Azure ya no se admite para hospedar el directorio de transporte global de SAP.
Almacenamiento HDD estándar de Azure
El almacenamiento HDD estándar de Azure era el único tipo de almacenamiento cuando la infraestructura de Azure se certificó para la carga de trabajo de SAP NetWeaver en el año 2014. En el año 2014, las máquinas virtuales de Azure eran pequeñas y bajas en términos de rendimiento del almacenamiento. Por lo tanto, este tipo de almacenamiento era capaz de satisfacer las demandas. El almacenamiento es ideal para cargas de trabajo independientes de la latencia, lo que apenas se produce en el espacio de SAP. Con el creciente rendimiento de las máquinas virtuales de Azure y la mayor carga de trabajo que estas generan, este tipo de almacenamiento ya no se tiene en cuenta para el uso con escenarios de SAP. La matriz de funcionalidad para la carga de trabajo de SAP tiene el siguiente aspecto:
| Capacidad | Comentario | Notas y vínculos |
|---|---|---|
| VHD de base de SO | No adecuado | - |
| Disco de datos | No adecuado | - |
| Directorio de transporte global de SAP | No | No compatible |
| SAP sapmnt | No | No compatible |
| Almacenamiento de copia de seguridad | Adecuado | - |
| Recursos compartidos/disco compartido | No disponible | Necesita Azure Files o de terceros |
| Resistencia | LRS y GRS | No hay almacenamiento con redundancia de zona disponible para los discos |
| Latencia | high | Demasiado alta para el uso de DBMS, el directorio de transporte global de SAP o sapmnt/saploc |
| SLA DE IOPS | No | - |
| Número máximo de IOPS por disco | 500 | Independiente del tamaño del disco |
| SLA de rendimiento | No | - |
| Certificación de HANA | No | - |
| Instantáneas de disco posibles | Sí | - |
| Instantáneas de máquina virtual de Azure Backup posibles | Sí | - |
| Costes | Bajo | - |
Resumen: HDD estándar es un tipo de almacenamiento de Azure que solo se debe usar para almacenar copias de seguridad de SAP. Solo se debe usar como VHD de base para sistemas más bien inactivos, como sistemas retirados que se utilizan para buscar datos aquí y allá. Sin embargo, las máquinas virtuales de producción, de control de calidad o de desarrollo activo no se deben basar en ese almacenamiento. Tampoco deben hospedarse archivos de base de datos en ese almacenamiento.
Límites de máquinas virtuales de Azure en el tráfico de almacenamiento
Al contrario que los escenarios locales, el tipo de máquina virtual individual que está seleccionando desempeña un papel fundamental en el ancho de banda de almacenamiento que puede lograr. En el caso de los diferentes tipos de almacenamiento, debe tener en cuenta lo siguiente:
| Tipo de almacenamiento | Linux | Windows | Comentarios |
|---|---|---|---|
| HDD estándar | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | Probablemente difícil alcanzar los límites de almacenamiento de máquinas virtuales medianas o grandes |
| SSD estándar | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | Probablemente difícil alcanzar los límites de almacenamiento de máquinas virtuales medianas o grandes |
| Premium Storage | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | Fácil de alcanzar los límites de las máquinas virtuales de rendimiento de almacenamiento o IOPS con la configuración de almacenamiento |
| SSD prémium v2 | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | Fácil de alcanzar los límites de las máquinas virtuales de rendimiento de almacenamiento o IOPS con la configuración de almacenamiento |
| Almacenamiento en disco Ultra | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | Fácil de alcanzar los límites de las máquinas virtuales de rendimiento de almacenamiento o IOPS con la configuración de almacenamiento |
| Azure NetApp Files | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | El tráfico de almacenamiento usa ancho de banda de rendimiento de red y no ancho de banda de almacenamiento. |
| Azure Premium Files | Tamaños de las máquinas virtuales Linux en Azure | Tamaños de las máquinas virtuales Windows en Azure | El tráfico de almacenamiento usa ancho de banda de rendimiento de red y no ancho de banda de almacenamiento. |
Como limitación, debe tener en cuenta lo siguiente:
- Cuanto menor es la máquina virtual, menos discos puede adjuntar. Esta restricción no se aplica a Azure NetApp Files. Dado que monta recursos compartidos de NFS o SMB, no encuentra un límite en el número de volúmenes compartidos que se van a adjuntar.
- Las máquinas virtuales tienen límites de rendimiento de E/S e IOPS que se podrían superar fácilmente con discos de Premium Storage y discos Ultra.
- Con Azure NetApp Files y Azure Premium Files, el tráfico a los volúmenes compartidos consume el ancho de banda de red de la máquina virtual y no el ancho de banda de almacenamiento
- Con grandes volúmenes de NFS en el espacio de capacidad de TiB de dos dígitos, el rendimiento que accede a dicho volumen desde una sola VM se estabilizará en función de los límites de Linux para una sola sesión que interactúa con el volumen compartido.
A medida que incrementa el tamaño de las máquinas virtuales de Azure en el ciclo de vida de un sistema SAP, debe evaluar los límites de IOPS y rendimiento de almacenamiento del tipo de máquina virtual nuevo y mayor. En algunos casos, también podría convenir ajustar la configuración del almacenamiento a las nuevas funcionalidades de la máquina virtual de Azure.
Posibilidad de seccionar o no
La creación de un conjunto seccionado de varios discos de Azure en un volumen más grande permite acumular la IOPS y el rendimiento de los discos individuales en un solo volumen. Se usa solo para almacenamiento estándar y prémium de Azure. Para el disco Ultra de Azure, donde puede configurar el rendimiento e IOPS independientemente de la capacidad de un disco, no es necesario usar conjuntos de franjas. Los volúmenes compartidos basados en NFS o SMB no se pueden seccionar. Debido a la naturaleza no lineal del rendimiento e IOPS de Azure Premium Storage, puede aprovisionar una capacidad menor con los mismos valores de IOPS y rendimiento que los discos individuales de Azure Premium Storage grandes. Este es el método para lograr un mayor rendimiento o IOPS a un costo más bajo con Azure Premium Storage. Por ejemplo, con el seccionamiento en dos discos de almacenamiento premium P15 se consigue un rendimiento de:
- 250 MiB/s. Dicho volumen va a tener una capacidad de 512 GiB. Si desea tener un único disco que proporcione un rendimiento de 250 MiB por segundo, deberá elegir un disco P40 con 2 TiB de capacidad.
- 400 MiB/s mediante el seccionamiento de cuatro discos de almacenamiento premium P10 con una capacidad total de 512 GiB por medio del seccionamiento. Si desea tener un solo disco con un rendimiento mínimo de 500 MiB por segundo, debe elegir un disco de Premium Storage de P60 con 8 TiB. Dado que el costo del almacenamiento premium es casi lineal con la capacidad, puede detectar el ahorro en los costos mediante el uso del seccionamiento.
Algunas reglas deben seguirse en el seccionamiento:
- No se debe usar redundancia de almacenamiento configurada en la máquina virtual, ya que Azure Storage mantiene la redundancia del disco de datos ya en el back-end de Azure Storage
- Los discos a los que se aplica el conjunto de bandas deben tener el mismo tamaño.
- Con SSD prémium v2 y Disco Ultra, la capacidad, así como las IOPS y el rendimiento aprovisionados, deben ser iguales.
La división en varios discos más pequeños es la mejor manera de lograr una buena relación precio/rendimiento con Azure Premium Storage. Se entiende que el seccionamiento puede tener cierta sobrecarga adicional de implementación y administración.
En el caso de recomendaciones específicas de tamaño de seccionamiento, lea la documentación de los distintos DBMS, como Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA.
Pasos siguientes
Lea los artículos: