Partilhar um disco gerido do Azure

  • Artigo

Aplica-se a: ✔️ VMs do Windows VMs ✔️ do Linux Conjuntos ✔️ de dimensionamento ✔️ flexíveis Conjuntos de dimensionamento uniformes

Os discos partilhados do Azure são uma funcionalidade para discos geridos do Azure que lhe permitem anexar um disco gerido a várias máquinas virtuais (VMs) em simultâneo. Anexar um disco gerido a várias VMs permite-lhe implementar aplicações em cluster novas ou migrar aplicações em cluster existentes para o Azure.

Como funciona

As VMs no cluster podem ler ou escrever no respetivo disco anexado com base na reserva escolhida pela aplicação em cluster através de Reservas Persistentes scSI (SCSI PR). O SCSI PR é um padrão do setor utilizado pelas aplicações em execução na Rede de Área de Armazenamento (SAN) no local. Ativar o PR SCSI num disco gerido permite-lhe migrar estas aplicações para o Azure tal como está.

Os discos geridos partilhados oferecem armazenamento de blocos partilhado que pode ser acedido a partir de várias VMs, estes são expostos como números de unidade lógica (LUNs). Os LUNs são então apresentados a um iniciador (VM) a partir de um destino (disco). Estes LUNs parecem-se com o armazenamento ligado diretamente (DAS) ou uma unidade local para a VM.

Os discos geridos partilhados não oferecem nativamente um sistema de ficheiros totalmente gerido que possa ser acedido com SMB/NFS. Tem de utilizar um gestor de clusters, como o Cluster de Ativação Pós-falha do Windows Server (WSFC) ou o Pacemaker, que processa a comunicação do nó de cluster e o bloqueio de escrita.

Limitações

Limitações gerais

Os discos partilhados têm limitações gerais que se aplicam a todos os discos partilhados, independentemente do tipo de disco. Além de limitações adicionais que se aplicam apenas a tipos específicos de discos partilhados. A lista seguinte é a lista de limitações gerais:

  • Atualmente, apenas discos Ultra, SSD Premium v2, SSD Premium e SSDs Standard podem ser utilizados como um disco partilhado
  • Os discos partilhados podem ser anexados a Conjuntos de Dimensionamento de Máquinas Virtuais individuais, mas não podem ser definidos nos modelos do Conjunto de Dimensionamento de Máquinas Virtuais ou implementados automaticamente
  • Não é possível expandir um disco partilhado sem desalocar todas as VMs às quais o disco está ligado ou desanexar o disco de todas estas VMs
  • O acelerador de escrita não é suportado para discos partilhados
  • A colocação em cache de anfitriões não é suportada para discos partilhados

Cada disco gerido com discos partilhados ativados também está sujeito às seguintes limitações, organizadas por tipo de disco:

Discos Ultra

Os discos Ultra têm a sua própria lista separada de limitações, não relacionadas com discos partilhados. Para obter limitações de discos ultra, veja Utilizar discos ultra do Azure.

Ao partilhar discos ultra, têm as seguintes limitações adicionais:

SSD Premium v2

Os discos geridos premium SSD v2 têm a sua própria lista separada de limitações, não relacionadas com discos partilhados. Para estas limitações, veja Limitações premium do SSD v2.

Ao partilhar discos SSD v2 Premium, estes têm a seguinte limitação adicional:

SSD Premium

Discos SSD Standard

Requisitos do sistema operativo

Os discos partilhados suportam vários sistemas operativos. Veja as secções Windows ou Linux para obter os sistemas operativos suportados.

Implicações de faturação

Quando partilha um disco, a faturação pode ser afetada de duas formas diferentes, consoante o tipo de disco.

Para discos SSD premium partilhados, além do custo do escalão do disco, existe um custo adicional que aumenta com cada VM à qual o SSD está montado. Veja os preços dos discos geridos para obter detalhes.

Os discos ultra não têm um custo adicional para cada VM à qual estão montados. São faturados no total de IOPS e MB/s para os quais o disco está configurado. Normalmente, um disco ultra tem duas limitações de desempenho que determinam o total de IOPS/MB/s. No entanto, quando configurado como um disco ultra partilhado, são expostas mais duas limitações de desempenho, num total de quatro. Estas duas limitações adicionais permitem um aumento do desempenho a uma despesa adicional e cada medidor tem um valor predefinido, o que aumenta o desempenho e o custo do disco.

As quatro limitações de desempenho que um disco ultra partilhado tem são diskMB/sReadWrite, diskIOPSReadOnly e diskMB/sReadOnly. Cada limitação de desempenho pode ser configurada para alterar o desempenho do disco. O desempenho do disco ultra partilhado é calculado das seguintes formas: IOPS total aprovisionado (diskIOPSReadWrite + diskIOPSReadOnly) e para MB/s de débito total aprovisionado (diskMB/sReadWrite + diskMB/sReadOnly).

Depois de determinar o total de IOPS aprovisionado e o débito total aprovisionado, pode utilizá-los na calculadora de preços para determinar o custo de um disco ultra partilhado.

Tamanhos de disco

Por enquanto, apenas discos ultra, SSD premium v2, SSD premium e SSDs padrão podem ativar discos partilhados. Diferentes tamanhos de disco podem ter um limite diferente maxShares , que não pode exceder ao definir o maxShares valor.

Para cada disco, pode definir um maxShares valor que representa o número máximo de nós que podem partilhar simultaneamente o disco. Por exemplo, se planear configurar um cluster de ativação pós-falha de dois nós, definiria maxShares=2. O valor máximo é um limite superior. Os nós podem aderir ou sair do cluster (montar ou desmontar o disco) desde que o número de nós seja inferior ao valor especificado maxShares .

Nota

O maxShares valor só pode ser definido ou editado quando o disco é desanexado de todos os nós.

Intervalos SSD Premium

A tabela seguinte ilustra os valores máximos permitidos para maxShares por tamanhos SSD premium:

Tamanhos de disco limite maxShares
P1,P2,P3,P4,P6,P10,P15,P20 3
P30, P40, P50 5
P60, P70, P80 10

Os limites de IOPS e largura de banda de um disco não são afetados pelo maxShares valor. Por exemplo, o IOPS máximo de um disco P15 é 1100, quer maxShares = 1 ou maxShares > 1.

Intervalos SSD Standard

A tabela seguinte ilustra os valores máximos permitidos para maxShares por tamanhos SSD padrão:

Tamanhos de disco limite maxShares
E1,E2,E3,E4,E6,E10,E15,E20 3
E30, E40, E50 5
E60, E70, E80 10

Os limites de IOPS e largura de banda de um disco não são afetados pelo maxShares valor. Por exemplo, o IOPS máximo de um disco E15 é 500, quer maxShares = 1 ou maxShares > 1.

Intervalos de discos ultra

O valor mínimo maxShares é 1, enquanto o valor máximo maxShares é 15. Não existem restrições de tamanho em discos ultra, qualquer tamanho de disco ultra pode utilizar qualquer valor para maxShares, até e incluindo o valor máximo.

Intervalos SSD v2 Premium

O valor mínimo maxShares é 1, enquanto o valor máximo maxShares é 15. Não existem restrições de tamanho no SSD Premium v2, qualquer tamanho do disco SSD v2 Premium pode utilizar qualquer valor para maxShares, até e incluindo o valor máximo.

Cargas de trabalho de exemplo

Windows

Os discos partilhados do Azure são suportados no Windows Server 2008 e mais recentes. A maioria dos clusterings baseados no Windows baseia-se no WSFC, que processa toda a infraestrutura principal para a comunicação de nós de cluster, permitindo que as suas aplicações tirem partido de padrões de acesso paralelos. O WSFC permite opções baseadas em CSV e não CSV consoante a versão do Windows Server. Para mais detalhes, veja Criar um cluster de ativação pós-falha.

Algumas aplicações populares em execução no WSFC incluem:

Linux

Os discos partilhados do Azure são suportados em:

Os clusters do Linux podem utilizar gestores de clusters, como o Pacemaker. O Pacemaker baseia-se no Corosync, permitindo comunicações de cluster para aplicações implementadas em ambientes de elevada disponibilidade. Alguns sistemas de ficheiros agrupados comuns incluem ocfs2 e gfs2. Pode utilizar modelos de clustering baseados em Dispositivos de Bloqueio SCSI (SCSI PR) e/ou STONITH Block Device (SBD) para arbitrar o acesso ao disco. Ao utilizar o PR SCSI, pode manipular reservas e registos com utilitários como fence_scsi e sg_persist.

Fluxo de reserva persistente

O diagrama seguinte ilustra uma aplicação de base de dados em cluster de dois nós de exemplo que utiliza o PR SCSI para ativar a ativação pós-falha de um nó para o outro.

Dois clusters de nós que consistem na VM1 do Azure, na VM2 e num disco partilhado entre eles. Uma aplicação em execução no cluster processa o acesso ao disco.

O fluxo é o seguinte:

  1. A aplicação em cluster em execução na VM1 do Azure e na VM2 regista a sua intenção de ler ou escrever no disco.
  2. Em seguida, a instância da aplicação na VM1 utiliza reserva exclusiva para escrever no disco.
  3. Esta reserva é imposta no disco do Azure e a base de dados pode agora escrever exclusivamente no disco. As escritas da instância da aplicação na VM2 não serão bem-sucedidas.
  4. Se a instância da aplicação na VM1 ficar inativa, a instância na VM2 pode agora iniciar uma ativação pós-falha da base de dados e a substituição do disco.
  5. Esta reserva é agora imposta no disco do Azure e o disco deixará de aceitar escritas da VM1. Só aceitará escritas da VM2.
  6. A aplicação em cluster pode concluir a ativação pós-falha da base de dados e servir pedidos da VM2.

O diagrama seguinte ilustra outra carga de trabalho em cluster comum que consiste em vários nós que leem dados do disco para executar processos paralelos, como a preparação de modelos de machine learning.

Quatro clusters de VMs de nós, cada nó regista a intenção de escrita, a aplicação utiliza reserva exclusiva para processar corretamente os resultados de escrita

O fluxo é o seguinte:

  1. A aplicação em cluster em execução em todas as VMs regista a intenção de ler ou escrever no disco.
  2. A instância da aplicação na VM1 utiliza uma reserva exclusiva para escrever no disco enquanto abre leituras para o disco a partir de outras VMs.
  3. Esta reserva é imposta no disco do Azure.
  4. Todos os nós no cluster podem agora ler a partir do disco. Apenas um nó devolve resultados ao disco, em nome de todos os nós no cluster.

Fluxo de reserva SSD v2 do Ultra Disk e Premium

Tanto os discos Ultra como os discos geridos premium SSD v2 oferecem duas limitações adicionais, dando a cada um deles um total de quatro limitações. Devido a isto, o fluxo de reserva pode funcionar conforme descrito na secção anterior ou pode limitar e distribuir o desempenho de forma mais granular.

Uma imagem de uma tabela que ilustra o acesso

Limitações de desempenho

Limitações de desempenho do SSD Premium

Com o SSD premium, o IOPS do disco e o débito são fixos, por exemplo, o IOPS de um P30 é 5000. Este valor permanece se o disco é partilhado em 2 VMs ou 5 VMs. Os limites de disco podem ser atingidos a partir de uma única VM ou divididos em duas ou mais VMs.

Limitações de desempenho do Disco Ultra e do SSD Premium v2

Tanto os Discos Ultra como os discos geridos premium SSD v2 têm a capacidade exclusiva de lhe permitir definir o seu desempenho expondo atributos modificáveis e permitindo-lhe modificá-los. Por predefinição, existem apenas dois atributos modificáveis, mas os Discos Ultra partilhados e os discos geridos premium SSD v2 partilhados têm mais dois atributos. Os Discos Ultra e o SSD V2 Premium dividem estes atributos em cada VM anexada. Para obter alguns exemplos sobre como funciona esta distribuição de capacidade, IOPS e débito, veja a secção Exemplos .

Atributo Descrição
DiskIOPSReadWrite (IOPS de disco de leitura/escrita) O número total de IOPS permitido em todas as VMs que montam o disco partilhado com acesso de escrita.
DiskMB/sReadWrite (Débito do disco de leitura/escrita) O débito total (MB/s) permitido em todas as VMs que montam o disco partilhado com acesso de escrita.
DiskIOPSReadOnly* (IOPS de disco só de leitura) O número total de IOPS permitido em todas as VMs que montam o disco partilhado como ReadOnly.
DiskMB/sReadOnly* (Débito de disco só de leitura) O débito total (MB/s) permitido em todas as VMs que montam o disco partilhado como ReadOnly.

* Aplica-se apenas a Discos Ultra partilhados e discos geridos premium SSD v2 partilhados

As fórmulas seguintes explicam como os atributos de desempenho podem ser definidos, uma vez que são modificáveis pelo utilizador:

  • DiskIOPSReadWrite (IOPS do disco de leitura/escrita):
    • Tem um IOPS mínimo de linha de base de 100, para discos 100 GiB e menor.
      • Para discos com mais de 100 GiB, o IOPS mínimo da linha de base pode definir aumentos em 1 por GiB. Assim, o menor que pode definir DiskIOPSReadWrite para um disco GiB 101 é 101 IOPS.
    • O máximo que pode definir este atributo é determinado pelo tamanho do disco, a fórmula é 300 * GiB, até um máximo de 160 000.
  • DiskMB/sReadWrite (Débito do disco de leitura/escrita)
    • O débito mínimo (MB/s) deste atributo é determinado pelo IOPS, a fórmula é 4 KiB por segundo por IOPS. Por isso, se tiver 101 IOPS, o mínimo de MB/s que pode definir é 1.
    • O máximo que pode definir este atributo é determinado pela quantidade de IOPS que definiu, a fórmula é 256 KiB por segundo por IOPS, até um máximo de 4000 MB/s.
  • DiskIOPSReadOnly (IOPS de disco só de leitura)
    • O IOPS de linha de base mínimo para este atributo é 100. Para DiskIOPSReadOnly, a linha de base não aumenta com o tamanho do disco.
    • O máximo que pode definir este atributo é determinado pelo tamanho do disco, a fórmula é 300 * GiB, até um máximo de 160 000.
  • DiskMB/sReadOnly (Débito de disco só de leitura)
    • O débito mínimo (MB/s) para este atributo é 1. Para DiskMB/sReadOnly, a linha de base não aumenta com o IOPS.
    • O máximo que pode definir este atributo é determinado pela quantidade de IOPS que definiu, a fórmula é 256 KiB por segundo por IOPS, até um máximo de 4000 MB/s.

Exemplos

Os exemplos seguintes mostram alguns cenários que mostram como a limitação pode funcionar com discos ultra partilhados, especificamente.

Dois nós de cluster com volumes partilhados de cluster

Segue-se um exemplo de um WSFC de dois nós com volumes partilhados em cluster. Com esta configuração, ambas as VMs têm acesso de escrita simultâneo ao disco, o que resulta na divisão da ReadWrite limitação entre as duas VMs e na limitação que não está a ReadOnly ser utilizada.

CSV dois nós ultra exemplo

Dois clusters de nós sem volumes de partilha de clusters

Segue-se um exemplo de um WSFC de dois nós que não está a utilizar volumes partilhados em cluster. Com esta configuração, apenas uma VM tem acesso de escrita ao disco. Isto faz com que a limitação ReadWrite seja utilizada exclusivamente para a VM primária e a ReadOnly limitação seja utilizada apenas pela secundária.

CSV dois nós sem csv ultra disk example

Cluster linux de quatro nós

Segue-se um exemplo de um cluster linux de 4 nós com um único escritor e três leitores de escalamento horizontal. Com esta configuração, apenas uma VM tem acesso de escrita ao disco. Isto faz com que a limitação ReadWrite seja utilizada exclusivamente para a VM primária e a ReadOnly limitação seja dividida pelas VMs secundárias.

Exemplo de limitação ultra de quatro nós

Preços do Disco Ultra Partilhado e do SSD Premium v2

Tanto os Discos Ultra partilhados como os discos geridos premium SSD v2 partilhados têm um preço baseado na capacidade aprovisionada, no total de IOPS aprovisionados (diskIOPSReadWrite + diskIOPSReadOnly) e no total de MB/s de Débito aprovisionado (diskMB/sReadWrite + diskMB/sReadOnly). Não existem custos adicionais para cada montagem de VM adicional. Por exemplo, um Disco Ultra partilhado com a seguinte configuração (diskSizeGB: 1024, DiskIOPSReadWrite: 10000, DiskMB/sReadWrite: 600, DiskIOPSReadOnly: 100, DiskMB/sReadOnly: 1) é cobrado com 1024 GiB, 10100 IOPS e 601 MB/s, independentemente de estar montado em duas VMs ou cinco VMs.

Passos seguintes

Se estiver interessado em ativar e utilizar discos partilhados para os discos geridos, avance para o nosso artigo Ativar disco partilhado

Se tiver perguntas adicionais, veja a secção discos partilhados das FAQ.