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 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 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:
Con Azure Storage para almacenar datos de base de datos y rehacer el archivo de registro, LRS es el único nivel de resistencia admitido en este momento dado.
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 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 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 | Recomendado2 | 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 | Recomendado2 | 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 | Recomendado2 | 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 | Recomendado2 | No compatible |
| Volumen de recursos compartidos de HANA | No compatible | No compatible | Recomendado | Recomendado | Recomendado | Recomendado | Recomendado3 |
| 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.
2 El uso de ANF requiere que /hana/data y /hana/log estén en ANF
3 Hasta ahora solo se ha probado en SLES
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í | No | No | 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 | No | 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 | No | 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 Los costos dependen del IOPS aprovisionado y el rendimiento.
3 La creación de diferentes grupos de capacidad de ANF no garantiza la implementación de grupos de capacidad en diferentes unidades de almacenamiento.
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, usted puede decidir 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 | No | - |
| Instantáneas de máquina virtual de Azure Backup posibles | No | - |
| Costos | Media | - |
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 | No | - |
| Instantáneas de disco posibles | No | - |
| Instantáneas de máquina virtual de Azure Backup posibles | No | - |
| Costos | Mayor que Premium Storage | - |
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). Los discos Ultra no admiten instantáneas de almacenamiento. 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 (ANF)
Azure NetApp Files es el resultado de la cooperación entre Microsoft y NetApp establecida con el objetivo de proporcionar recursos compartidos de SMB y NFS nativos de Azure de alto rendimiento. El énfasis se pone en proporcionar un alto ancho de banda y un almacenamiento de baja latencia que permita escenarios de implementación de DBMS y, a lo largo del tiempo, habilite la funcionalidad típica operativa del almacenamiento de NetApp a través también de Azure. Los recursos compartidos de NFS/SMB se ofrecen en tres niveles de servicio diferentes en términos de rendimiento del almacenamiento y precio. Los niveles de servicio se documentan en el artículo Niveles de servicio para Azure NetApp Files. En el caso de los diferentes tipos de carga de trabajo de SAP, se recomiendan los siguientes niveles de servicio:
- Carga de trabajo de DBMS de SAP: rendimiento, idealmente Ultra
- Recurso compartido SAPMNT: rendimiento, idealmente Ultra
- Directorio de transporte global: rendimiento, idealmente Ultra
Nota
El tamaño mínimo de aprovisionamiento es una unidad de 4 TiB denominada grupo de capacidad. A continuación, crea volúmenes fuera de este grupo de capacidad. El volumen más pequeño que se puede compilar es 100 GiB. Puede expandir un grupo de capacidad en pasos de TiB. Para información sobre precios, consulte el artículo Precios de Azure NetApp Files
El almacenamiento de ANF se admite actualmente en varios escenarios de carga de trabajo de SAP:
- 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
- Las implementaciones de SAP HANA que usan recursos compartidos de NFS v.4.1 para volúmenes /hana/data y /hana/log o volúmenes de NFS v4.1 o NFS v3 para volúmenes de /hana/shared, como se documenta en el artículo Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA.
- IBM Db2 en un sistema operativo invitado Suse o Red Hat Linux
- Las implementaciones de 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 ASE en un sistema operativo invitado Suse o Red Hat Linux
Nota
De momento no se admiten cargas de trabajo DBMS en SMB basado en Azure NetApp Files.
Como ya se ha hecho con Azure Premium Storage, un tamaño de rendimiento fijo o lineal por GB puede suponer un problema cuando tiene que cumplir algunos números mínimos para el rendimiento. Este es el caso de SAP HANA. Con ANF, este problema puede ser más pronunciado que con el disco Premium de Azure. Con un disco prémium de Azure, puede tomar varios discos más pequeños con un rendimiento relativamente alto por GiB y seccionarlos para que sean rentables y tengan un rendimiento mayor a menor capacidad. Este tipo de seccionamiento no funciona para los recursos compartidos de NFS o SMB hospedados en ANF. Esta restricción dio lugar a la implementación de un exceso de capacidad como el siguiente:
- Para lograr, por ejemplo, un rendimiento de 250 MiB/s en un volumen de NFS hospedado en ANF, debe implementar la capacidad de 1,95 TiB del nivel de servicio Ultra.
- Para lograr 400 MiB/s, tendría que implementar la capacidad de 3,125 TiB. Pero es posible que necesite un aprovisionamiento en exceso de la capacidad para lograr el rendimiento que requiere del volumen. Este aprovisionamiento en exceso de la capacidad afecta a los precios de las instancias de HANA más pequeñas.
- Al usar NFS sobre ANF para el directorio /sapmnt de SAP, generalmente se supera la capacidad mínima de 100 GiB a 150 GiB que aplica Azure NetApp Files. Sin embargo, la experiencia de los clientes ha demostrado que el rendimiento relacionado de 12,8 MiB/s (con el nivel de servicio Ultra) puede no ser suficiente y puede incidir negativamente en la estabilidad del sistema SAP. En estos casos, los clientes podrían evitar problemas aumentando el volumen de /sapmnt, por lo que se proporciona más rendimiento a ese volumen.
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 | SAP HANA, Oracle en Oracle Linux, Db2 y SAP ASE en SLES/RHEL |
| 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 v3 y NFS v4.1 |
| Resistencia | LRS y GRS | GRS disponible |
| Latencia | Muy baja | - |
| SLA DE IOPS | Sí | - |
| IOPS lineal a capacidad | estrictamente lineal | Dependiente del nivel de servicio |
| SLA de rendimiento | Sí | - |
| Rendimiento lineal de la capacidad | linear | Dependiente del nivel de servicio |
| Certificación de HANA | Sí | - |
| Instantáneas de disco posibles | Sí | - |
| Instantáneas de máquina virtual de Azure Backup posibles | No | - |
| Costos | Mayor que Premium Storage | - |
Otra funcionalidad integrada de almacenamiento de ANF:
- Capacidad para realizar instantáneas de volumen
- Clonación de volúmenes de ANF desde instantáneas
- Restauración de volúmenes a partir de instantáneas (reversión de instantáneas)
- Copia de seguridad de instantáneas coherente con la aplicación para SAP HANA y Oracle
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 de menos de 1 milisegundos para las escrituras de registro de puesta al día de HANA de tamaños más pequeños. Para llegar a estas latencias, consulte las posibilidades siguientes.
Importante
Incluso para el uso que no sea de DBMS, debe usar la funcionalidad de versión preliminar que le permite crear el recurso compartido NFS en la misma zona de disponibilidad de Azure que ha colocado las máquinas virtuales en las que debe montar los recursos compartidos NFS. Esta funcionalidad se documenta en el artículo Administración de la ubicación de volumen de zona de disponibilidad para Azure NetApp Files. 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 aún en otra avZone en la que no se ejecutan las máquinas virtuales.
- Vaya a la proximidad más cercana entre la máquina virtual y el recurso compartido NFS que se puede organizar mediante grupos de volúmenes de aplicaciones. La ventaja de los grupos de volúmenes de aplicaciones, además de asignar la mejor proximidad y con esa creación de una latencia más baja, es que los distintos recursos compartidos NFS para las implementaciones de SAP HANA se distribuyen entre diferentes controladores en los clústeres de back-end de Azure NetApp Files. La desventaja de este método es que debe volver a pasar por un proceso de anclaje. Es un proceso que terminará restringiendo la implementación de la máquina virtual a un único centro de datos. En lugar de un Availability Zones como primer método introducido. Esto implica menos flexibilidad en el cambio de tamaños de máquina virtual y familias de máquinas virtuales de las máquinas virtuales que tienen montados los volúmenes NFS.
- Proceso actual de no usar grupos de selección de ubicación de disponibilidad. Lo que hasta ahora solo está disponible para SAP HANA. Este proceso también usa el mismo proceso de anclaje manual que los grupos de volúmenes de disponibilidad. Este método es el método utilizado durante los últimos tres años. Tiene las mismas restricciones de flexibilidad que tiene el proceso con los grupos de volúmenes de disponibilidad.
Como preferencias para asignar volúmenes NFS basados en ANF para el uso específico de la base de datos, debe intentar asignar primero el volumen NFS en la misma zona que la máquina virtual. Especialmente para bases de datos que no son de HANA. Solo si la latencia resulta insuficiente, debe pasar por un proceso de anclaje manual. Para cargas de trabajo de HANA más pequeñas o cargas de trabajo de HANA que no sean de producción, también debe seguir un método de asignación zonal. Solo en los casos en los que el rendimiento y la latencia no sean suficientes, debe usar grupos de volúmenes de aplicaciones.
Resumen: Azure NetApp Files es un almacenamiento de baja latencia certificado de HANA que permite implementar volúmenes o recursos compartidos de NFS y SMB. El almacenamiento incluye tres niveles de servicio diferentes que proporcionan rendimiento e IOPS diferentes de forma lineal por la capacidad de GiB del volumen. El almacenamiento de ANF está habilitado para implementar escenarios de escalado horizontal de SAP HANA con un nodo en espera. El almacenamiento es adecuado para proporcionar recursos compartidos de archivos según sea necesario para /sapmnt o el directorio de transporte global de SAP. El almacenamiento de ANF incluye la disponibilidad de funcionalidad que está disponible como funcionalidad nativa de NetApp.
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
- 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.
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 | No | - |
| 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 exigencias 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 | LOW | - |
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 ANF. 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 ANF 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 ningún almacenamiento configurado en la máquina virtual, ya que Azure Storage mantiene los datos redundantes.
- 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: