Segurança do disco gerido

  • Artigo

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

O Azure oferece a capacidade de aumentar o IOPS de armazenamento de discos e o desempenho de MB/s, isto é referido como expansão para máquinas virtuais (VM) e discos. Pode utilizar eficazmente a VM e o expansão do disco para obter um melhor desempenho de expansão nas VMs e no disco.

O pico de VMs do Azure e os recursos de disco não dependem uns dos outros. Não precisa de ter uma VM compatível com expansão para que um disco compatível com expansão ligado seja rebentado. Da mesma forma, não precisa de ter um disco compatível com rajada ligado à VM com capacidade de rajada para a VM rebentar.

Cenários comuns

Os seguintes cenários podem beneficiar bastante do modo de expansão:

  • Melhorar os tempos de arranque – com o pico, a instância será iniciada a um ritmo mais rápido. Por exemplo, o disco de SO predefinido para VMs com capacidade premium é o disco P4, que é um desempenho aprovisionado de até 120 IOPS e 25 MB/s. Com o pico, o P4 pode ir até 3500 IOPS e 170 MB/s, permitindo que o arranque acelere até 6X.
  • Processar tarefas em lote – algumas cargas de trabalho de aplicação são de natureza cíclica. Precisam de um desempenho de linha de base na maior parte do tempo e de um desempenho superior durante curtos períodos de tempo. Um exemplo disto é um programa de contabilidade que processa transações diárias que requerem uma pequena quantidade de tráfego de disco. No final do mês, este programa concluiria a reconciliação de relatórios que precisam de uma quantidade muito maior de tráfego de disco.
  • Picos de tráfego – os servidores Web e as respetivas aplicações podem registar picos de tráfego em qualquer altura. Se o servidor Web tiver o suporte de VMs ou discos que utilizam expansão, os servidores estarão melhor equipados para lidar com picos de tráfego.

Expansão ao nível do disco

Atualmente, existem dois tipos de disco geridos que podem rebentar, discos geridos SSD Premium e SSDs standard. Outros tipos de disco não podem, atualmente, rebentar. Existem dois modelos de expansão para discos:

  • Um modelo de expansão a pedido, em que o disco rebenta sempre que as suas necessidades excedem a capacidade atual. Este modelo incorre em custos adicionais sempre que o disco rebentar. A expansão a pedido só está disponível para discos SSD Premium superiores a 512 GiB.
  • Um modelo baseado em crédito, onde o disco só irá rebentar se tiver créditos de rajada acumulados no registo de crédito. Este modelo não incorre em custos adicionais quando o disco é rebentado. A expansão baseada no crédito só está disponível para discos geridos SSD Premium 512 GiB e menores e SSDs standard 1024 GiB e menores.

Os discos geridos do SSD Premium do Azure podem utilizar qualquer um dos modelos em expansão, mas os SSDs padrão oferecem atualmente apenas expansão baseada em crédito.

Além disso, o escalão de desempenho dos discos geridos pode ser alterado, o que pode ser ideal se a carga de trabalho estiver em execução em rajada.

Expansão baseada no crédito Expansão a pedido Alterar o escalão de desempenho
Cenários Ideal para dimensionamento de curto prazo (30 minutos ou menos). Ideal para dimensionamento de curto prazo (Não limitado no tempo). Ideal se a carga de trabalho estiver continuamente em execução em rajada.
Custo Gratuito O custo é variável. Veja a secção Faturação para obter detalhes. O custo de cada escalão de desempenho é fixo. Veja Managed Disks preços para obter detalhes.
Disponibilidade Disponível apenas para discos geridos SSD premium 512 GiB e menores e SSDs standard 1024 GiB e menor. Disponível apenas para discos geridos SSD premium superiores a 512 GiB. Disponível para todos os tamanhos SSD premium.
Ativação Ativado por predefinição em discos elegíveis. Tem de ser ativado pelo utilizador. O utilizador tem de alterar manualmente o escalão.

Expansão a pedido

Os discos geridos SSD Premium com o modelo de expansão a pedido de expansão do disco podem ir além dos destinos aprovisionados originais, sempre que necessário pela carga de trabalho, até ao destino de rajada máximo. Por exemplo, num disco P30 de 1 TiB, o IOPS aprovisionado é 5000 IOPS. Quando a expansão do disco está ativada neste disco, as cargas de trabalho podem emitir E/S para este disco até ao desempenho máximo de rajada de 30 000 IOPS e 1000 MBps. Para obter os destinos de rajada máximos em cada disco suportado, veja Metas de escalabilidade e desempenho para discos de VM.

Se espera que as cargas de trabalho sejam frequentemente executadas para além do destino de desempenho aprovisionado, a expansão do disco não será rentável. Neste caso, recomendamos que altere o escalão de desempenho do disco para um escalão superior , para um melhor desempenho de linha de base. Reveja os detalhes de faturação e avalie-os em relação ao padrão de tráfego das suas cargas de trabalho.

Antes de ativar o pico a pedido, compreenda o seguinte:

  • Não é possível ativar a expansão a pedido num SSD premium que tenha menos ou igual a 512 GiB. Os SSDs Premium inferiores ou iguais a 512 GiB utilizarão sempre rajadas baseadas em crédito.
  • A expansão a pedido só é suportada em SSDs premium. Se um SSD premium com expansão a pedido ativado for mudado para outro tipo de disco, a expansão do disco será desativada.
  • A expansão a pedido não se desativa automaticamente quando o escalão de desempenho é alterado. Se quiser alterar o escalão de desempenho, mas não quiser manter o disco em expansão, tem de o desativar.
  • A expansão a pedido só pode ser ativada quando o disco é desanexado de uma VM ou quando a VM é parada. O pico a pedido pode ser desativado 12 horas depois de ter sido ativado.

Disponibilidade regional

Atualmente, o modelo a pedido para expansão de discos está disponível em todas as regiões públicas do Azure.

Faturação

Os discos geridos SSD Premium que utilizam o modelo de expansão a pedido são cobrados uma taxa fixa de ativação por rajada de hora e os custos de transação aplicam-se a quaisquer transações de rajada para além do destino aprovisionado. Os custos de transação são cobrados com o modelo pay as you go, com base em E/S de disco não colocados em cache, incluindo leituras e escritas que excedem os destinos aprovisionados. Segue-se um exemplo de padrões de tráfego de disco durante uma hora de faturação:

Configuração do disco: SSD Premium – 1 TiB (P30), Expansão do disco ativada.

  • 00:00:00 – 00:10:00 IOPS de Disco abaixo do objetivo aprovisionado de 5000 IOPS
  • 00:10:01 – 00:10:10 A aplicação emitiu um trabalho de lote que fez com que o IOPS do disco rebentasse a 6000 IOPS durante 10 segundos
  • 00:10:11 – 00:59:00 IOPS de Disco abaixo do objetivo aprovisionado de 5000 IOPS
  • 00:59:01 – 01:00:00 A aplicação emitiu outro trabalho de lote, fazendo com que o IOPS do disco rebentasse a 7000 IOPS durante 60 segundos

Nesta hora de faturação, o custo de expansão consiste em dois custos:

A primeira cobrança é a taxa fixa de ativação de rajada de $X (determinada pela sua região). Esta taxa fixa é sempre cobrada no disco, ignorando o estado de anexação até que seja desativada.

Em segundo lugar, o custo da transação de rajada. O pico do disco ocorreu em dois intervalos de tempo. Das 00:10:01 às 00:10:10, a transação de rajada acumulada é (6000 – 5000) X 10 = 10 000. Das 00:59:01 às 01:00:00, a transação de rajada acumulada é (7000 – 5000) X 60 = 120 000. O total de transações de rajada é de 10 000 + 120 000 = 130 000. O custo da transação de rajada será cobrado em $Y com base em 13 unidades de 10 000 transações (com base nos preços regionais).

Com isso, o custo total no pico de disco desta hora de faturação é igual a $X + $Y. Aplicar-se-ia o mesmo cálculo para a expansão do destino aprovisionado de MBps. Convertemos a utilização excedida de MB em transações com um tamanho de E/S de 256 KB. Se o tráfego do disco exceder o IOPS aprovisionado e o destino de MBps, pode consultar o exemplo abaixo para calcular as transações de rajada.

Configuração do disco: SSD Premium – 1 TB (P30), Expansão do disco ativada.

  • 00:00:01 – 00:00:05 A aplicação emitiu um trabalho de lote que fez com que o IOPS do disco rebentasse a 10 000 IOPS e 300 MBps durante cinco segundos.
  • 00:00:06 – 00:00:10 A aplicação emitiu uma tarefa de recuperação que fez com que o IOPS do disco rebentasse a 6000 IOPS e 600 MBps durante cinco segundos.

A transação de rajada é contabilizada como o número máximo de transações de IOPS ou MBps a rebentar. Das 00:00:01 às 00:00:05, a transação de rajada acumulada é Max((10.000 – 5.000), (300 - 200) * 1024/256)) * 5 = 25.000 transações. Das 00:00:06 às 00:00:10, a transação de rajada acumulada é Max((6.000 – 5.000), (600 - 200) * 1024 /256)) * 5 = 8.000 transações. Além disso, inclui a taxa fixa de ativação de expansão para obter o custo total para permitir a expansão do disco a pedido.

Pode consultar a página de preços do Managed Disks para obter detalhes sobre os preços e utilizar a Calculadora de Preços do Azure para fazer a avaliação da sua carga de trabalho.

Para ativar a expansão a pedido, veja Ativar o pico a pedido.

Expansão baseada no crédito

Para discos geridos SSD Premium, a expansão baseada em crédito está disponível para tamanhos de disco P20 e menores. Para SSDs padrão, a expansão baseada em crédito está disponível para tamanhos de disco E30 e menores. Para discos geridos standard e Premium SSD, o pico baseado no crédito está disponível em todas as regiões nas Clouds Públicas, Governamentais e China do Azure. Por predefinição, a expansão do disco está ativada em todas as implementações novas e existentes de tamanhos de disco suportados. A expansão ao nível da VM utiliza apenas expansão baseada em crédito.

Expansão ao nível da máquina virtual

A expansão ao nível da VM utiliza apenas o modelo baseado em crédito para expansão, esta está ativada por predefinição para a maioria Armazenamento Premium VMs suportadas.

Fluxo de rajada

O sistema de crédito em expansão aplica-se da mesma forma ao nível da VM e ao nível do disco. O recurso, quer seja uma VM ou um disco, começará com créditos totalmente abastecidos no seu próprio registo de rajada. Estes créditos permitem-lhe rebentar até 30 minutos com a taxa de expansão máxima. Acumula créditos sempre que os IOPS ou MB/s do recurso estiverem a ser utilizados abaixo do objetivo de desempenho do recurso. Se o recurso tiver acumulado créditos de expansão e a carga de trabalho precisar de um desempenho adicional, o recurso pode utilizar esses créditos para ultrapassar os limites de desempenho e aumentar o desempenho para satisfazer as exigências da carga de trabalho.

Diagrama de registo a rebentar.

A forma como gasta os créditos disponíveis depende de si. Pode utilizar os seus 30 minutos de créditos de rajada consecutivos ou esporadicamente ao longo do dia. Quando os recursos são implementados, têm uma alocação completa de créditos. Quando se esgotam, demora menos de um dia a reabastecer. Os créditos podem ser gastos a seu critério, o registo de rajada não precisa de estar cheio para que os recursos sejam rebentados. A acumulação de rajadas varia consoante cada recurso, uma vez que se baseia em IOPS não utilizados e MB/s abaixo dos respetivos objetivos de desempenho. Os recursos de desempenho de linha de base mais elevados podem acumular os créditos de expansão mais rapidamente do que os recursos de desempenho da linha de base inferior. Por exemplo, um IDling de disco P1 acumulará 120 IOPS por segundo, enquanto um disco P20 com idling acumularia 2300 IOPS por segundo.

Estados de rajada

Existem três estados em que o recurso pode estar com o modo de expansão ativado:

  • Acumulação – o tráfego de E/S do recurso está a utilizar menos do que o destino de desempenho. A acumulação de créditos de expansão para IOPS e MB/s é feita separadamente umas das outras. O recurso pode estar a acumular créditos IOPS e a gastar créditos de MB/s ou vice-versa.
  • Expansão – o tráfego do recurso está a utilizar mais do que o destino de desempenho. O tráfego de rajada consumirá créditos, de forma independente, da largura de banda ou do IOPS.
  • Constante – o tráfego do recurso está exatamente no destino de desempenho.

Exemplos de expansão

Os exemplos seguintes mostram como o modo de expansão funciona com várias combinações de VMs e discos. Para tornar os exemplos fáceis de seguir, vamos focar-nos em MB/s, mas a mesma lógica é aplicada de forma independente ao IOPS.

Máquina virtual expansível com discos não expansíveis

Combinação de VMs e discos:

  • Standard_L8s_v2
    • MB/s não instalados: 160
    • Máximo de MB/s de rajada: 1.280
  • Disco do SO P50
    • MB/s aprovisionados: 250
    • Expansão a Pedido: não ativado
  • 2 Discos de Dados P50
    • MB/s aprovisionados: 250
    • Expansão a Pedido: não ativado

Após o arranque inicial, uma aplicação é executada na VM e tem uma carga de trabalho não crítica. Esta carga de trabalho requer 30 MB/s que são distribuídos uniformemente por todos os discos. A aplicação envia um pedido de 30 MB/s de débito para a VM, a VM recebe o pedido e envia a cada um dos respetivos discos um pedido de 10 MB/s, cada disco devolve 10 MB/s, a VM devolve 30 MB/s para a aplicação.

Em seguida, a aplicação tem de processar uma tarefa em lote que requer 600 MB/s. O Standard_L8s_v2 rebenta para satisfazer esta procura e, em seguida, os pedidos para os discos são distribuídos uniformemente para discos P50.

A aplicação envia um pedido de 600 MB/s de débito para a VM, a VM utiliza rajadas para efetuar o pedido e envia a cada um dos respetivos discos um pedido de 200 MB/s, cada disco devolve 200 MB/s, as VMs explodem para devolver 600 MB/s à aplicação.

Máquina virtual expansível com discos expansíveis

Combinação de VMs e discos:

  • Standard_L8s_v2
    • MB/s não instalados: 160
    • Máximo de MB/s de rajada: 1.280
  • Disco do SO P4
    • MB/s aprovisionados: 25
    • Máximo de MB/s de rajada: 170
  • 2 Discos de Dados P4
    • MB/s aprovisionados: 25
    • Máximo de MB/s de rajada: 170

Quando a VM é iniciada, irá rebentar para pedir o limite de rajada de 1280 MB/s do disco do SO e o disco do SO responderá com o desempenho de rajada de 170 MB/s.

No arranque, a VM é rebentada para enviar um pedido de 1280 MB/s para o disco do SO, o disco do SO é rebentado para devolver os 1280 MB/s.

Após o arranque, inicia uma aplicação que tem uma carga de trabalho não crítica. Esta aplicação requer 15 MB/s que são distribuídos uniformemente por todos os discos.

A aplicação envia um pedido de 15 MB/s de débito para a VM, a VM recebe o pedido e envia a cada um dos respetivos discos um pedido de 5 MB/s, cada disco devolve 5 MB/s de respostas, a VM devolve 15 MB/s para a aplicação.

Em seguida, a aplicação tem de processar uma tarefa em lote que requer 360 MB/s. A Standard_L8s_v2 rebenta para satisfazer esta procura e, em seguida, os pedidos. Apenas 20 MB/s são necessários para o disco do SO. Os restantes 340 MB/s são processados pelos discos de dados P4 em expansão.

A aplicação envia um pedido de 360 MB/s de débito para a VM, a VM faz rajadas para aceitar o pedido e envia a cada um dos respetivos discos de dados um pedido de 170 MB/s e 20 MB/s do disco do SO, cada disco devolve os MB/s pedidos, as VMs explodem para devolver 360 MB/s à aplicação.

Passos seguintes