Planejar volumes em clusters do Azure Stack HCI e do Windows Server

Aplica-se a: Azure Stack HCI, versões 21H2 e 20H2; Windows Server 2022, Windows Server 2019

Este artigo fornece diretrizes sobre como planejar volumes de cluster para atender às necessidades de desempenho e capacidade de suas cargas de trabalho, incluindo escolher seu sistema de arquivos, tipo de resiliência e tamanho.

Observação

Espaços de Armazenamento Diretos não dá suporte a um servidor de arquivos para uso geral. Se você precisar executar o servidor de arquivos ou outros serviços genéricos no Espaço de Armazenamento Direto, configure-o nas máquinas virtuais.

Revisão: O que são volumes

Os volumes são onde você coloca os arquivos de que suas cargas de trabalho precisam, como arquivos VHD ou VHDX para máquinas virtuais Hyper-V. Os volumes combinam as unidades no pool de armazenamento para introduzir os benefícios de tolerância a falhas, escalabilidade e desempenho de Espaços de Armazenamento Diretos, a tecnologia de armazenamento definida pelo software por trás do Azure Stack HCI e do Windows Server.

Observação

Usamos o termo "volume" para fazer referência conjunta ao volume e ao disco virtual sob ele, incluindo a funcionalidade fornecida por outros recursos internos do Windows, como CSV (Volumes Compartilhados de Cluster) e ReFS. Não é necessário entender essas distinções no nível de implementação para planejar e implantar com êxito Espaços de Armazenamento Diretos.

O diagrama mostra três pastas rotuladas como volumes associados a um disco virtual rotulado como volumes, todas associadas a um pool de armazenamento comum de discos.

Todos os volumes são acessíveis por todos os servidores do cluster ao mesmo tempo. Depois de criados, eles aparecem em C:\ClusterStorage\ em todos os servidores.

A captura de tela mostra uma janela do explorador de arquivos intitulada ClusterStorage que contém volumes chamados Volume1, Volume2 e Volume3.

Escolhendo quantos volumes criar

Recomendamos criar um número de volumes múltiplo do número de servidores no cluster. Por exemplo, se você tiver 4 servidores, terá um desempenho mais consistente com quatro volumes totais do que com 3 ou 5. Isso permite que o cluster distribua a "propriedade" do volume (um servidor manipula coordenação de metadados para cada volume) uniformemente entre servidores.

Recomendamos limitar o número total de volumes a 64 volumes por cluster.

Escolhendo o sistema de arquivos

Recomendamos usar o novo Sistema de Arquivos Resiliente (ReFS) para Espaços de Armazenamento Diretos. ReFS é o sistema de arquivos premier voltado para virtualização e oferece muitas vantagens, incluindo acelerações de desempenho espetaculares e proteção interna contra corrupção de dados. Ele dá suporte a quase todos os principais recursos do NTFS, incluindo Eliminação de Duplicação de Dados no Windows Server versão 1709 e posterior. Consulte a tabela de comparação de recursos reFS para obter detalhes.

Se sua carga de trabalho requerer um recurso a que o ReFS ainda não dá suporte, você pode usar o NTFS.

Dica

Volumes com sistemas de arquivos diferentes podem coexistir no mesmo cluster.

Escolhendo o tipo de resiliência

Os volumes em Espaços de Armazenamento Diretos fornecem resiliência para se proteger contra os problemas de hardware, como falhas na unidade ou no servidor, e para possibilitar a disponibilidade contínua durante a manutenção do servidor, como atualizações de software.

Observação

Os tipos de resiliência entre os quais você pode escolher independem dos tipos de unidades que você tem.

Com dois servidores

Com dois servidores no cluster, você pode usar espelhamento bidirecional ou usar resiliência aninhada.

O espelhamento bidirecional mantém duas cópias de todos os dados, uma cópia nas unidades em cada servidor. Sua eficiência de armazenamento é de 50%. para gravar 1 TB de dados, você precisa de pelo menos 2 TB de capacidade de armazenamento físico no pool de armazenamento. O espelhamento bidirecional pode tolerar com segurança uma falha de hardware por vez (um servidor ou unidade).

O diagrama mostra volumes rotulados de dados e cópia conectados por setas circulares e ambos os volumes estão associados a um banco de discos em servidores.

A resiliência aninhada fornece resiliência de dados entre servidores com espelhamento bidirecional e adiciona resiliência em um servidor com espelhamento bidirecional ou paridade acelerada por espelho. O aninhamento fornece resiliência de dados mesmo quando um servidor está reiniciando ou indisponível. Sua eficiência de armazenamento é de 25% com espelhamento bidirecional aninhado e cerca de 35 a 40% para paridade aninhada acelerada por espelho. A resiliência aninhada pode tolerar com segurança duas falhas de hardware por vez (duas unidades ou um servidor e uma unidade no servidor restante). Devido a essa resiliência de dados adicionada, recomendamos usar resiliência aninhada em implantações de produção de clusters de dois servidores. Para obter mais informações, consulte Resiliência Aninhada.

O diagrama mostra a paridade acelerada do espelho aninhado com o espelho bidirecional entre servidores associados a um espelho bidirecional em cada servidor correspondente a uma camada de paridade em cada servidor.

Com três servidores

Com três servidores, você deve usar o espelhamento de três voas para melhor tolerância de falhas e melhor desempenho. O espelhamento de três vias mantém três cópias de todos os dados, uma cópia nas unidades em cada servidor. Sua eficiência de armazenamento é de 33,3% – para gravar 1 TB de dados, você precisa de pelo menos 3 TB de capacidade de armazenamento físico no pool de armazenamento. O espelhamento de três vias pode tolerar com segurança pelo menos dois problemas de hardware (unidade ou servidor) por vez. Se dois nós ficarem indisponíveis, o pool de armazenamento perderá quorum, já que 2/3 dos discos não estão disponíveis e os discos virtuais não poderão ser acessados. No entanto, um nó pode estar inativo e um ou mais discos em outro nó podem falhar e os discos virtuais permanecerão online. Por exemplo, se você estiver reiniciando um servidor quando, de repente, outra unidade ou servidor falhar, todos os dados permanecem seguros e continuamente acessíveis.

O diagrama mostra um volume de dados rotulados e duas cópias rotuladas conectadas por setas circulares com cada volume associado a um servidor que contém discos físicos.

Com quatro ou mais servidores

Com quatro ou mais servidores, você pode escolher para cada volume se deseja usar espelhamento bidirecional, paridade dupla (geralmente chamada de "codificação de eliminação" ou misturar os dois com paridade acelerada por espelho.

A paridade dupla fornece a mesma tolerância a falhas que o espelhamento de três vias, mas com melhor eficiência de armazenamento. Com quatro servidores, sua eficiência de armazenamento é de 50,0%. para armazenar 2 TB de dados, você precisa de 4 TB de capacidade de armazenamento físico no pool de armazenamento. Isso aumenta para 66,7% a eficiência de armazenamento com sete servidores e continua até 80,0% de eficiência de armazenamento. A desvantagem é que codificação de paridade tem um processamento mais intensivo, o que pode limitar seu desempenho.

O diagrama mostra dois volumes rotulados de dados e duas paridades rotuladas conectadas por setas circulares com cada volume associado a um servidor que contém discos físicos.

O tipo de resiliência a ser usado depende das necessidades de sua carga de trabalho. Aqui está uma tabela que resume quais cargas de trabalho são adequadas para cada tipo de resiliência, bem como a eficiência de desempenho e armazenamento de cada tipo de resiliência.

Tipo de resiliência Eficiência de capacidade Velocidade Cargas de trabalho
Espelho Eficiência de armazenamento mostrando 33%
Espelho de três vias: 33%
Espelho bidirecional: 50%
Desempenho mostrando 100%
Desempenho mais alto
Cargas de trabalho virtualizadas
Bancos de dados
Outras cargas de trabalho de alto desempenho
Paridade acelerada por espelho Eficiência de armazenamento mostrando cerca de 50%
Depende da proporção de espelho e paridade
Desempenho mostrando cerca de 20%
Muito mais lento do que o espelho, mas até duas vezes mais rápido que a paridade dupla
Melhor para gravações e leituras sequenciais grandes
Arquivamento e backup
Infraestrutura de área de trabalho virtualizada
Paridade dupla Eficiência de armazenamento mostrando cerca de 80%
4 servidores: 50%
16 servidores: até 80%
Desempenho mostrando cerca de 10%
Maior uso de CPU de latência & de E/S em gravações
Melhor para gravações e leituras sequenciais grandes
Arquivamento e backup
Infraestrutura de área de trabalho virtualizada

Quando desempenho é o mais importante

As cargas de trabalho que tenham requisitos estritos de latência ou que precisem de muitos IOPS mistos aleatórios, como bancos de dados do SQL Server ou máquinas virtuais Hyper-V dependentes de desempenho, devem ser executadas em volumes que usem espelhamento para maximizar o desempenho.

Dica

O espelhamento é mais rápido do que qualquer outro tipo de resiliência. Usamos o espelhamento para quase todos os exemplos de desempenho.

Quando a capacidade é o mais importante

Cargas de trabalho que gravam com pouca frequência, como data warehouses ou armazenamento "frio", devem ser executadas em volumes que usem a paridade dupla para aumentar a eficiência de armazenamento. Determinadas outras cargas de trabalho, como Scale-Out Servidor de Arquivos (SoFS), VDI (infraestrutura de área de trabalho virtual) ou outras que não criam muito tráfego de E/S aleatório rápido e/ou não exigem o melhor desempenho, também podem usar paridade dupla, a seu critério. A paridade inevitavelmente aumenta utilização da CPU e a latência de E/S, principalmente nas gravações, em comparação ao espelhamento.

Quando os dados são gravados em massa

Cargas de trabalho que gravam em passagens grandes e sequenciais, como destinos de arquivamento ou backup, têm outra opção: um volume pode misturar espelhamento e paridade dupla. As gravações são feitas primeiro na parte espelhada e, depois, são gradualmente movidas para a parte de paridade. Isso acelera a recepção e reduz a utilização de recursos quando chegam grandes gravações, permitindo que a codificação de paridade de processamento intensivo aconteça durante um período mais longo. Ao dimensionar as partes, considere que a quantidade de gravações que ocorrem ao mesmo tempo (por exemplo, um backup diário) deve caber confortavelmente na parte de espelho. Por exemplo, se receber 100 GB uma vez por dia, considere usar o espelhamento para 150 GB a 200 GB e a paridade dupla para o restante.

A eficiência de armazenamento resultante depende das proporções que você escolher. Consulte esta demonstração para obter alguns exemplos.

Dica

Se você observar uma redução abrupta no desempenho de gravação em parte por meio da ingestão de dados, isso pode indicar que a parte espelho não é grande o suficiente ou que a paridade acelerada por espelho não é adequada para o caso de uso. Por exemplo, se o desempenho da gravação diminuir de 400 MB/s para 40 MB/s, considere expandir a parte do espelho ou alternar para espelho de três vias.

Sobre as implantações com o NVMe, SSD e HDD

Em implantações com dois tipos de unidades, as unidades mais rápidas fornecem cache enquanto as unidades mais lentas fornecem a capacidade. Isso acontece automaticamente – para obter mais informações, consulte Noções básicas sobre o cache em Espaços de Armazenamento Diretos. Em tais implantações, todos os volumes, em última análise, residem no mesmo tipo de unidades – as unidades de capacidade.

Em implantações com todos os três tipos de unidades, somente as unidades mais rápidas (NVMe) fornecem cache, deixando dois tipos de unidades (SSD e HDD) para fornecer capacidade. Para cada volume, você pode escolher se ele reside inteiramente na camada SSD, inteiramente na camada HDD, ou se abrange as duas.

Importante

Recomendamos usar a camada SSD para colocar as cargas de trabalho mais dependentes de desempenho em all-flash.

Escolhendo o tamanho dos volumes

Recomendamos limitar o tamanho de cada volume a 64 TB no Azure Stack HCI.

Dica

Se você usar uma solução de backup que depende do VSS (serviço de Cópia de Sombra de Volume) e do provedor de software Volsnap, como é comum com cargas de trabalho do servidor de arquivos, limitar o tamanho do volume a 10 TB melhorará o desempenho e a confiabilidade. As soluções de backup que usam a mais recente API RCT Hyper-V e/ou a clonagem de blocos ReFS e/ou as APIs de backup SQL nativas executam bem até 32 TB ou mais.

Superfície

O tamanho de um volume se refere à sua capacidade utilizável, a quantidade de dados que ele pode armazenar. Isso é fornecido pelo parâmetro -Tamanho do cmdlet Novo Volume e, em seguida, aparece na propriedade Tamanho quando você executa o cmdlet Get-Volume.

Tamanho é diferente da superfície do volume, a capacidade total de armazenamento físico que ocupa no pool de armazenamento. A superfície depende do tipo de resiliência. Por exemplo, os volumes que usam o espelhamento de três vias têm uma superfície de três vezes o seu tamanho.

As superfícies de seus volumes precisam caber no pool de armazenamento.

O diagrama mostra um volume de 2 TB em comparação com um volume de 6 TB no pool de armazenamento com um multiplicador de três especificados.

Capacidade de reserva

Deixar alguma capacidade não alocada no pool de armazenamento oferece espaço aos volumes para reparar "in-loco" após falhas de unidade, melhorando o desempenho e a segurança dos dados. Se houver capacidade suficiente, um reparo imediato, in-loco e paralelo pode restaurar os volumes a uma resiliência completa antes mesmo de as unidades com falha serem substituídas. Isso acontece automaticamente.

É recomendável reservar o equivalente a uma unidade de capacidade por servidor, até 4 unidades. Você pode reservar mais a seu critério, mas essa recomendação mínima garante que um reparo imediato, in-loco e paralelo pode ter sucesso após a falha de qualquer unidade.

O diagrama mostra um volume associado a vários discos em um pool de armazenamento e discos não associados marcados como reserva.

Por exemplo, se você tiver 2 servidores e estiver usando unidades de 1 TB de capacidade, separe 2 x 1 = 2 TB do pool como reserva. Se você tiver 3 servidores e unidades de 1 TB de capacidade, separe 3 x 1 = 3 TB como reserva. Se você tiver 4 ou mais servidores e unidades de 1 TB de capacidade, separe 4 x 1 = 4 TB como reserva.

Observação

Nos clusters com unidades de todos os três tipos (NVMe + SSD + HDD), é recomendável reservar o equivalente a uma SSD mais uma HDD por servidor, até 4 unidades de cada.

Exemplo: planejamento da capacidade

Considere um cluster de quatro servidores. Cada servidor tem algumas unidades de cache além de dezesseis unidades de 2 TB de capacidade.

4 servers x 16 drives each x 2 TB each = 128 TB

Desses 128 TB no pool de armazenamento, separamos quatro unidades, ou 8 TB, para que os reparos in-loco possam acontecer sem qualquer pressa para substituir as unidades depois de falharem. Isso deixa 120 TB de capacidade de armazenamento físico no pool com o qual podemos criar volumes.

128 TB – (4 x 2 TB) = 120 TB

Suponha que precisamos que nossa implantação hospede algumas máquinas virtuais Hyper-V extremamente ativas, mas também há muito espaço de armazenamento frio – arquivos antigos e backups que precisamos manter. Como temos quatro servidores, vamos criar quatro volumes.

Vamos colocar as máquinas virtuais nos dois primeiros volumes: Volume1 e Volume2. Escolhemos ReFS como o sistema de arquivos (para uma criação mais rápida e pontos de verificação) e o espelhamento de três vias para resiliência a fim de maximizar o desempenho. Vamos colocar o armazenamento frio em outros dois volumes: Volume 3 e Volume 4. Escolhemos NTFS como o sistema de arquivos (para Eliminação de Duplicação de Dados) e a paridade dupla para resiliência a fim de maximizar a capacidade.

Não precisamos criar todos os volumes do mesmo tamanho, mas para simplificar, vamos fazer isso. Por exemplo, podemos criar todos com 12 TB.

Volume1 e Volume2 ocuparão 12 TB x 33,3% de eficiência = 36 TB de capacidade de armazenamento físico.

Volume3 e Volume4 ocuparão 12 TB x 50,0% de eficiência = 24 TB de capacidade de armazenamento físico.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

Os quatro volumes se encaixam exatamente na capacidade de armazenamento físico disponível no nosso pool. Perfeito!

O diagrama mostra dois volumes de espelho de três vias de 12 TB associados a 36 TB de armazenamento e dois volumes de paridade dupla de 12 TB associados a 24 TB, todos ocupando 120 TB em um pool de armazenamento.

Dica

Você não precisa criar todos os volumes imediatamente. Sempre é possível estender volumes ou criar novos volumes mais tarde.

Para simplificar, este exemplo usa unidades decimais (base 10), ou seja, 1 TB = 1.000.000.000.000 bytes. No entanto, as quantidades de armazenamento no Windows aparecem em unidades binários (base 2). Por exemplo, cada unidade de 2 TB apareceria como 1,82 TiB no Windows. Da mesma forma, o pool de armazenamento de 128 TB apareceria como 116,41 TiB. Isso é esperado.

Uso

Consulte Criando volumes no Azure Stack HCI.

Próximas etapas

Para obter mais informações, consulte também: