Compartir a través de

Uso compartido de un disco administrado de Azure

  • Artículo

Se aplica a: ✔️ Máquinas virtuales Linux ✔️ Máquinas virtuales Windows ✔️ Conjuntos de escalado flexibles ✔️ Conjuntos de escalado uniformes

Los discos compartidos de Azure son una nueva característica de los discos administrados de Azure que permite conectar un disco administrado a varias máquinas virtuales (VM) al mismo tiempo. Si adjunta un disco administrado en varias VM, podrá implementar nuevas aplicaciones en clúster o migrar las existentes a Azure.

Los discos compartidos requieren usar un administrador de clústeres, como el Clúster de conmutación por error de Windows Server (WSFC) o Pacemaker, que controle la comunicación del nodo de clúster, así como el bloqueo de escritura. Los discos administrados compartidos no ofrecen de forma nativa un sistema de archivos totalmente administrado al que se pueda obtener acceso mediante SMB/NFS.

Funcionamiento

Las VM del clúster pueden leer o escribir en el disco adjunto en función de la reserva elegida por la aplicación en clúster mediante las reservas persistentes de SCSI (SCSI PR). SCSI PR es un estándar del sector que usan las aplicaciones que se ejecutan en el entorno local de la red de área de almacenamiento (SAN). La habilitación de SCSI PR en un disco administrado le permite migrar estas aplicaciones a Azure tal cual.

Los discos administrados compartidos ofrecen almacenamiento en bloque compartido, al que pueden acceder varias VM, y se exponen como números de unidad lógica (LUN). Los LUN se presentan como un iniciador (VM) de un destino (disco). Estos LUN tienen el aspecto de un almacenamiento conectado directamente (DAS) o de una unidad local en la VM.

Limitaciones

Limitaciones generales

Los discos compartidos tienen limitaciones generales que se aplican a todos los discos compartidos, independientemente del tipo de disco. También tienen más limitaciones que solo se aplican a tipos específicos de discos compartidos. La lista siguiente es la lista de limitaciones generales:

  • Actualmente, solo se pueden usar Ultra Disks, SSD prémium v2, SSD prémium y SSD estándar como disco compartido
  • Los discos compartidos se pueden conectar a instancias individuales de Virtual Machine Scale Sets, pero no se pueden definir en los modelos del conjunto de escalado de máquinas virtuales o implementarse automáticamente
  • Un disco compartido no se puede expandir sin desasignar todas las máquinas virtuales a las que está conectado o desasociar el disco de todas estas máquinas virtuales
  • El acelerador de escritura no se admite para discos compartidos
  • No se admite el almacenamiento en caché de host para los discos compartidos

Cada disco administrado con discos compartidos habilitados está sujeto también a las siguientes limitaciones, organizadas según el tipo de disco:

Discos Ultra

Los discos Ultra Disks tienen su propia lista independiente de limitaciones, que no están relacionadas con los discos compartidos. Para conocer las limitaciones de Ultra Disks, vea Uso de Azure Ultra Disks.

Al compartir discos Ultra Disks, estos tienen las siguientes limitaciones adicionales:

SSD prémium v2

Los discos administrados SSD prémium v2 tienen su propia lista de limitaciones, no relacionadas con los discos compartidos. Para ver estas limitaciones, consulte Limitaciones de SSD prémium v2.

Al compartir discos SSD prémium v2, tienen la siguiente limitación adicional:

SSD Premium

Discos SSD estándar

Requisitos de sistema operativo

Los discos compartidos admiten varios sistemas operativos. Consulte las secciones Windows o Linux en los sistemas operativos compatibles.

Implicaciones de facturación

Al compartir un disco, la facturación podría verse afectada de dos maneras diferentes, según el tipo de disco.

En el caso de discos SSD prémium compartidos, además del coste del nivel del disco, hay un cargo adicional que aumenta con cada máquina virtual en la que se monta el SSD. Consulte Precios de discos administrados para obtener más información.

Tanto los discos Ultra compartidos como los discos SSD prémium v2 compartidos no tienen un cargo adicional por cada máquina virtual en la que se montan. Se facturan según el total de IOPS y MBps para los que se ha configurado el disco. Normalmente, los discos Ultra y SSD prémium v2 tiene dos limitaciones de rendimiento que determinan su IOPS/MB/s totales. Pero cuando se configuran como disco compartido, se exponen dos limitaciones de rendimiento más, lo que hace un total de cuatro. Estas dos limitaciones adicionales permiten aumentar el rendimiento a un gasto adicional y cada medidor tiene un valor predeterminado, lo que aumenta el rendimiento y el coste del disco.

Las cuatro limitaciones de rendimiento que tienen los discos Ultra y SSD prémium v2 compartidos son diskIOPSReadWrite, diskMB/sReadWrite, diskIOPSReadOnly y diskMB/sReadOnly. Cada limitación de rendimiento se puede configurar para cambiar el rendimiento del disco. El rendimiento de los discos Ultra y SSD prémium v2 compartidos se calcula de la siguiente manera: total de IOPS aprovisionadas (diskIOPSReadWrite + diskIOPSReadOnly) y MBps de rendimiento total aprovisionado (diskMB/sReadWrite + diskMB/sReadOnly).

Una vez que haya determinado las IOPS aprovisionadas totales y el rendimiento aprovisionado total, puede usar los valores en la calculadora de precios para determinar el coste de un disco Ultra compartido y un disco SSD prémium v2 compartido.

Tamaños de disco

De momento, solo los discos Ultra, los discos SSD prémium v2 y los discos SSD estándar permiten los discos compartidos. Los distintos tamaños de disco pueden tener un límite de maxShares diferente, que no se puede superar al establecer el valor de maxShares.

Para cada disco, puede definir un valor de maxShares que represente el número máximo de nodos que puede compartir el disco simultáneamente. Por ejemplo, si planea configurar un clúster de conmutación por error de dos nodos, debe establecer maxShares=2. El valor máximo es un límite superior. Los nodos pueden unirse al clúster, o salir de él (montaje o desmontaje del disco) siempre que el número de nodos sea inferior al valor de maxShares especificado.

Nota

El valor de maxShares solo se puede establecer o editar cuando el disco se desasocia de todos los nodos.

Rangos de discos SSD Premium

En la tabla siguiente se muestran los valores máximos permitidos para maxShares por tamaños de discos SSD Premium:

Tamaños de disco Límite de maxShares
P1,P2,P3,P4,P6,P10,P15,P20 3
P30, P40, P50 5
P60, P70, P80 10

Los límites de IOPS y ancho de banda de un disco no se ven afectados por el valor de maxShares. Por ejemplo, el número máximo de IOPS de un disco P15 es 1100 si maxShares = 1 o maxShares > 1.

Intervalos de SSD estándar

En la tabla siguiente se muestran los valores máximos permitidos para maxShares por tamaños de discos estándar:

Tamaños de disco Límite de maxShares
E1,E2,E3,E4,E6,E10,E15,E20 3
E30, E40, E50 5
E60, E70, E80 10

Los límites de IOPS y ancho de banda de un disco no se ven afectados por el valor de maxShares. Por ejemplo, el número máximo de IOPS de un disco E15 es 500 si maxShares = 1 o maxShares > 1.

Rangos de discos Ultra Disks

El valor mínimo de maxShares es 1, mientras que el valor máximo de maxShares es 15. No hay restricciones de tamaño en los discos Ultra Disks, cualquier disco de tamaño ultra puede usar cualquier valor para maxShares, hasta el valor máximo incluido.

Intervalos de SSD prémium v2

El valor mínimo de maxShares es 1, mientras que el valor máximo de maxShares es 15. No hay restricciones de tamaño en SSD prémium v2, cualquier tamaño de disco SSD prémium v2 puede usar cualquier valor para maxShares, hasta el valor máximo inclusive.

Ejemplo de cargas de trabajo

Windows

Los discos compartidos de Azure se admiten en Windows Server 2008 y versiones más recientes. La mayoría de los clústeres basados en Windows se compilan en WSFC, que controla toda la infraestructura central de la comunicación del nodo de clúster, lo que permite que las aplicaciones aprovechen los patrones de acceso en paralelo. WSFC habilita tanto las opciones basadas en CSV como las que no están basadas en CSV en función de la versión de Windows Server. Para obtener más información, consulte Creación de un clúster de conmutación por error.

Entre las aplicaciones populares que se ejecutan en WSFC se incluyen:

Linux

Los discos compartidos de Azure se admiten en:

Los clústeres de Linux pueden usar administradores de clústeres, como Pacemaker. Pacemaker se basa en Corosync, lo que permite las comunicaciones de clúster para las aplicaciones implementadas en entornos de alta disponibilidad. Algunos sistemas de archivos en clúster comunes incluyen ocfs2 y gfs2. Puede usar modelos de agrupación en clústeres basados en la reserva persistente SCSI (SCSI PR) o un dispositivo de bloque STONITH (SBD) para arbitrar el acceso al disco. Al usar SCSI PR, puede manipular las reservas y los registros mediante utilidades como fence_scsi y sg_persist.

Flujo de reserva persistente

En el siguiente diagrama se ilustra un ejemplo de aplicación de base de datos en clúster de dos nodos que usa SCSI PR para permitir la conmutación por error de un nodo a otro.

Clúster de dos nodos que consta de Azure VM1, VM2 y un disco compartido entre ellos. Una aplicación que se ejecuta en el clúster maneja el acceso al disco.

El flujo es el siguiente:

  1. La aplicación en clúster que se ejecuta tanto en la VM1 de Azure como en la VM2 registra su intención para leer o escribir en el disco.
  2. La instancia de la aplicación en la VM1 toma una reserva exclusiva para escribir en el disco.
  3. Esta reserva se aplica en el disco de Azure y la base de datos ya puede escribir en el disco de forma exclusiva. Las escrituras de la instancia de la aplicación en la VM2 no se realizarán correctamente.
  4. Si la instancia de la aplicación en la VM1 deja de funcionar, la instancia en la VM2 ya puede iniciar una conmutación por error de la base de datos y hacerse cargo del disco.
  5. Ahora, esta reserva se aplica en el disco de Azure y este ya no aceptará escrituras de la VM1. Solo aceptará escrituras de la VM2.
  6. La aplicación en clúster puede completar la conmutación por error de la base de datos y atender las solicitudes de la VM2.

En el diagrama siguiente se ilustra otra carga de trabajo en clúster común que consta de varios nodos que leen datos del disco para la ejecución de procesos paralelos, como el entrenamiento de modelos de Machine Learning.

Clúster de VM de cuatro nodos; cada nodo registra la intención que hay que escribir y la aplicación toma la reserva exclusiva para controlar correctamente los resultados de escritura.

El flujo es el siguiente:

  1. La aplicación en clúster que se ejecuta en todas las VM registra la intención de leer o escribir en el disco.
  2. La instancia de la aplicación en la VM1 toma una reserva exclusiva para escribir en el disco mientras abre las lecturas en el disco de otras VM.
  3. Esta reserva se aplica en el disco de Azure.
  4. Ya se pueden leer todos los nodos del clúster desde el disco. Solo un nodo reescribe los resultados en el disco en nombre de los demás nodos del clúster.

Flujo de reserva de SSD Ultra y SSD prémium v2

Tanto los discos administrados SSD Ultra como los SSD prémium v2 ofrecen dos aceleradores adicionales, lo que les da a cada uno un total de cuatro aceleradores. Debido a esto, el flujo de reserva puede funcionar como se describe en la sección anterior, o puede acelerar y distribuir el rendimiento de forma más granular.

Imagen de una tabla que muestra el acceso `ReadOnly` (de solo lectura) o `Read/Write` (de lectura y escritura) para el Reservation Holder (titular de reserva), el Registered (registrado) y Others (otros).

Limitaciones de rendimiento

Limitaciones de rendimiento de SSD Premium

Con SSD Premium, la IOPS y el rendimiento del disco son fijos, por ejemplo, la IOPS de un P30 es 5000. Este valor permanece si el disco se comparte entre 2 máquinas virtuales o 5 máquinas virtuales. Los límites de disco se pueden alcanzar desde una sola máquina virtual o dividirse entre dos o más máquinas virtuales.

Aceleradores de rendimiento de SSD Ultra y SSD prémium v2

Tanto los discos administrados Ultra Disks como los SSD prémium v2 tienen la capacidad única de permitirle configurar su rendimiento al exponer atributos modificables y permitirle modificarlos. De forma predeterminada, solo hay dos atributos modificables, pero los discos administrados Ultra Disks compartidos y los SSD prémium v2 compartidos tienen dos atributos más. Los discos Ultra y SSD prémium v2 dividen estos atributos en cada máquina virtual conectada. Para obtener algunos ejemplos sobre cómo funciona esta distribución de capacidad, IOPS y rendimiento, consulte la sección Ejemplos.

Atributo Descripción
DiskIOPSReadWrite (IOPS de disco de lectura y escritura) El número total de IOPS permitidas en todas las máquinas virtuales que montan el disco compartido con acceso de escritura.
DiskMB/sReadWrite (rendimiento de disco de lectura y escritura) El rendimiento total (MB/s) permitido en todas las máquinas virtuales que montan el disco compartido con acceso de escritura.
DiskIOPSReadOnly* (IOPS de disco de solo lectura) El número total de IOPS permitido en todas las máquinas virtuales que montan el disco compartido como ReadOnly.
DiskMB/sReadOnly* (rendimiento de disco de solo lectura) El rendimiento total (MB/s) permitido en todas las máquinas virtuales que montan el disco compartido como ReadOnly.

* Solo se aplica a discos administrados Ultra Disks compartidos y SSD prémium v2 compartidos

Las fórmulas siguientes explican cómo se pueden establecer los atributos de rendimiento, ya que el usuario puede modificarlos:

  • DiskIOPSReadWrite (IOPS de disco de lectura y escritura):
    • Tiene una IOPS mínima de línea base de 100, para los discos de 100 GiB y menores.
      • Para los discos de más de 100 GiB, la IOPS mínima de línea base que puede establecer aumenta en 1 por GiB. Por lo tanto, lo menos que puede establecer DiskIOPSReadWrite para un disco de 101 GiB es son 101 IOPS.
    • El máximo en el que puede establecer este atributo viene determinado por el tamaño del disco, la fórmula es 300 * GiB, hasta un máximo de 400 000.
  • DiskMB/sReadWrite (rendimiento de disco de lectura y escritura)
    • El rendimiento mínimo (MB/s) de este atributo viene determinado por el valor de IOPS; la fórmula es 4 KiB por segundo por IOPS. Por lo tanto, si tenía 101 IOPS, el valor mínimo de MB/s que se puede establecer es 1.
    • El máximo en el que se puede establecer este atributo viene determinado por la cantidad de IOPS determinada, la fórmula es 256 KiB por segundo por IOPS, hasta un máximo de 10000 MB/s.
  • DiskIOPSReadOnly (IOPS de disco de solo lectura)
    • El valor mínimo de IOPS de línea base para este atributo es 100. Para DiskIOPSReadOnly, la línea base no aumenta con el tamaño del disco.
    • El máximo en el que puede establecer este atributo viene determinado por el tamaño del disco, la fórmula es 300 * GiB, hasta un máximo de 400 000.
  • DiskMB/sReadOnly (rendimiento de disco de solo lectura)
    • El rendimiento mínimo (MB/s) de este atributo es 1. Para DiskMB/sReadOnly, la línea base no aumenta con IOPS.
    • El máximo en el que se puede establecer este atributo viene determinado por la cantidad de IOPS determinada, la fórmula es 256 KiB por segundo por IOPS, hasta un máximo de 10000 MB/s.

Ejemplos

En los siguientes ejemplos se muestran algunos escenarios en los que se muestra cómo la limitación puede funcionar, en concreto, con instancias compartidas de Ultra Disks.

Clúster de dos nodos con volúmenes compartidos en clúster

A continuación, se presenta un ejemplo de un WSFC de dos nodos mediante volúmenes compartidos en clúster. Con esta configuración, ambas máquinas virtuales tienen acceso de escritura simultáneo al disco, lo que da lugar a que se divida la limitación ReadWrite entre las dos máquinas virtuales y a que no se use la limitación ReadOnly.

Ejemplo de disco Ultra de dos nodos en CSV

Clúster de dos nodos sin volúmenes compartidos en clúster

A continuación, se presenta un ejemplo de un WSFC de dos nodos que no usa volúmenes compartidos en clúster. Con esta configuración, solo una máquina virtual tiene acceso de escritura al disco. Esto da como resultado que la limitación ReadWrite se use exclusivamente para la máquina virtual principal y que solo la secundaria use la limitación ReadOnly.

Ejemplo de disco Ultra no CSV de dos nodos en CSV

Clúster Linux de cuatro nodos

A continuación, se proporciona un ejemplo de un clúster Linux de cuatro nodos con un solo escritor y tres lectores de escalabilidad horizontal. Con esta configuración, solo una máquina virtual tiene acceso de escritura al disco. Esto da como resultado que la limitación ReadWrite se use exclusivamente para la máquina virtual principal y que la limitación ReadOnly se divida entre las máquinas virtuales secundarias.

Ejemplo de limitación en disco Ultra de cuatro nodos

Precios de discos SSD Ultra y SSD prémium v2 compartidos

Tanto los discos administrados Ultra Disks compartidos como los SSD prémium v2 compartidos tienen un precio basado en la capacidad aprovisionada, el total de IOPS aprovisionadas (diskIOPSReadWrite + diskIOPSReadOnly) y el rendimiento aprovisionado total en Mbps (diskMB/sReadWrite + diskMB/sReadOnly). No hay ningún cargo adicional por cada montaje de máquina virtual adicional. Por ejemplo, un disco Ultra compartido con la siguiente configuración (diskSizeGB: 1024, DiskIOPSReadWrite: 10000, DiskMB/sReadWrite: 600, DiskIOPSReadOnly: 100, DiskMB/sReadOnly: 1) se carga con 1024 GiB, 10100 IOPS y 601 MB/s independientemente de si se monta en dos o cinco máquinas virtuales.

Pasos siguientes

Si está interesado en habilitar y usar discos compartidos para los discos administrados, continúe con nuestro artículo Habilitación de discos compartidos.

Si tiene preguntas adicionales, consulte la sección discos compartidos de las preguntas más frecuentes.