Planejar volumes em clusters do Azure Stack HCI e do Windows Server
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; 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.
Nota
Os Espaços de Armazenamento Diretos não dão 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
Volumes são o lugar onde você coloca os arquivos 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 apresentar os benefícios de tolerância a falhas, escalabilidade e desempenho do Storage Spaces Direct, a tecnologia de armazenamento definida por software que sustenta o Azure Stack HCI e o Windows Server.
Nota
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. Entender essas distinções de nível de implementação não são necessárias para planejar e implantar Espaços de Armazenamento Diretos com êxito.
Todos os volumes são acessíveis por todos os servidores no cluster ao mesmo tempo. Depois de criados, eles aparecem em C:\ClusterStorage\ em todos os servidores.
Escolhendo quantos volumes criar
Recomendamos tornar o número de volumes um múltiplo do número de servidores em seu cluster. Por exemplo, se você tiver 4 servidores, terá um desempenho mais consistente com 4 volumes totais do que com 3 ou 5. Isso permite que o cluster distribua a "propriedade" do volume (um servidor manipula a orquestração de metadados para cada volume) uniformemente entre os 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. O ReFS é o principal sistema de arquivos criado para virtualização e oferece muitas vantagens, incluindo acelerações dramáticas de desempenho e proteção interna contra corrupção de dados. Ele dá suporte a quase todos os principais recursos do NTFS, incluindo a 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 a carga de trabalho exigir um recurso que o ReFS ainda não dá suporte, você poderá usar o NTFS.
Dica
Volumes com sistemas de arquivos diferentes podem coexistir no mesmo cluster.
Escolhendo o tipo de resiliência
Volumes em Espaços de Armazenamento Diretos fornecem resiliência para proteger contra problemas de hardware, como falhas de unidade ou servidor, e para assegurar a disponibilidade contínua durante a manutenção do servidor, como atualizações de software.
Nota
Os tipos de resiliência que você pode escolher são independentes 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 nos discos 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).
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 acelerada por espelhamento aninhado. 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 de resiliência aninhada.
Com três servidores
Com três servidores, você deve usar o espelhamento de três vias para melhorar o desempenho e a tolerância a falhas. O espelhamento de três vias mantém três cópias de todos os dados, uma cópia nas unidades de 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 permanecem online. Por exemplo, se você estiver reinicializando um servidor quando, de repente, outra unidade ou servidor falhar, todos os dados permanecerão seguros e continuamente acessíveis.
Com quatro ou mais servidores
Com quatro ou mais servidores, você pode escolher para cada volume se deseja usar espelhamento de três vias, paridade dupla (frequentemente chamada de "erasure coding"), 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% de eficiência de armazenamento com sete servidores e continua até 80,0% de eficiência de armazenamento. A desvantagem é que a codificação de paridade é mais intensiva em computação, o que pode limitar seu desempenho.
Qual tipo de resiliência usar depende dos requisitos de desempenho e capacidade para seu ambiente. Aqui está uma tabela que resume o desempenho e a eficiência de armazenamento de cada tipo de resiliência.
| Tipo de resiliência | Eficiência de capacidade | Velocidade |
|---|---|---|
| espelho | eficiência de armazenamento  Espelho de três vias: 33% Espelho bidirecional: 50% |
Desempenho do  Desempenho mais alto |
| Paridade acelerada por espelho | eficiência de armazenamento  Depende da proporção de espelho e paridade |
Desempenho de  Muito mais lento que o espelho, mas até duas vezes mais rápido que a paridade dupla Melhor para gravações e leituras sequenciais grandes |
| de paridade dupla | A eficiência de armazenamento está em torno de 80% 4 servidores: 50% 16 servidores: até 80% |
desempenho do  Latência de E/S mais alta para uso da CPU & em gravações Ideal para grandes operações sequenciais de escrita e leitura |
Quando o desempenho é mais importante
Cargas de trabalho que têm requisitos de latência rigorosos ou que precisam de muitos IOPS aleatórios mistos, como bancos de dados do SQL Server ou máquinas virtuais Hyper-V sensíveis ao desempenho, devem ser executadas em volumes que usam 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 nossos exemplos de desempenho.
Quando a capacidade é mais importante
Cargas de trabalho que gravam com pouca frequência, como data warehouses ou armazenamento "frio", devem ser executadas em volumes que usam paridade dupla para maximizar a eficiência do armazenamento. Determinadas outras cargas de trabalho, como Scale-Out SoFS (Servidor de Arquivos), VDI (infraestrutura de área de trabalho virtual) ou outras que não criam muito tráfego de E/S aleatório instável e/ou não exigem o melhor desempenho, também podem usar paridade dupla, a seu critério. A paridade inevitavelmente aumenta a utilização da CPU e a latência de E/S, especialmente em gravações, em comparação com o 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. Os registros são feitos primeiro na parte espelhada e depois são gradualmente movidos para a parte de paridade. Isso acelera a ingestão e reduz a utilização de recursos quando grandes gravações chegam, permitindo que a codificação de paridade, que exige uso intensivo de computação, aconteça de forma mais distribuída ao longo do tempo. Ao dimensionar as partes, considere que a quantidade de gravações que ocorrem ao mesmo tempo (como um backup diário) deve caber confortavelmente na parte espelho. Por exemplo, se você ingerir 100 GB uma vez por dia, considere usar espelhamento de 150 GB a 200 GB e paridade dupla para o restante.
A eficiência de armazenamento resultante depende das proporções escolhidas.
Dica
Se você observar uma diminuição abrupta no desempenho de gravação durante a ingestão de dados, isso pode indicar que a porção do espelho não é grande o suficiente ou que a paridade acelerada por espelho não é adequada para seu caso de uso. Por exemplo, se o desempenho de gravação diminuir de 400 MB/s para 40 MB/s, considere expandir a parte espelho ou alternar para o espelho de três vias.
Sobre implantações com 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 capacidade. Isso acontece automaticamente – para obter mais informações, consulte Noções básicas sobre o cache em Espaços de Armazenamento Diretos. Nessas implantações, todos os volumes, em última análise, residem no mesmo tipo de discos – os discos 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 ele abrange os dois.
Importante
Recomendamos usar a camada SSD para colocar suas cargas de trabalho mais sensíveis ao desempenho em armazenamento totalmente em 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 dependa 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. Soluções de backup que usam a API RCT Hyper-V mais recente e/ou a clonagem de blocos do ReFS e/ou as APIs de backup do SQL nativo têm um bom desempenho de até 32 TB e mais.
Pegada
O tamanho de um volume refere-se à sua capacidade utilizável, à quantidade de dados que ele pode armazenar. Isso é fornecido pelo parâmetro -Size do cmdlet New-Volume e aparece na propriedade Size quando você executa o cmdlet Get-Volume.
O tamanho é distinto da pegada do volume, a capacidade total de armazenamento físico que ele ocupa no pool de armazenamento. A pegada depende de seu tipo de resiliência. Por exemplo, os volumes que usam espelhamento de três vias ocupam um espaço três vezes maior que o seu tamanho.
As pegadas dos seus volumes precisam caber no pool de armazenamento.
Capacidade de reserva
Deixar alguma capacidade no pool de armazenamento não alocada dá espaço aos volumes para reparar "no local" depois que as unidades de disco falham, melhorando a segurança e o desempenho dos dados. Se houver capacidade suficiente, um reparo imediato e paralelo, no local, poderá restaurar volumes para resiliência total mesmo antes que as unidades com falha sejam substituídas. Isso acontece automaticamente.
É recomendável reservar o equivalente a um disco de capacidade por servidor, até quatro discos. Você pode reservar mais a seu critério, mas essa recomendação mínima garante que um reparo paralelo imediato, no local, possa ser bem-sucedido após a falha de qualquer disco.
Por exemplo, se você tiver dois servidores e estiver usando unidades de capacidade de 1 TB, reserve 2 x 1 = 2 TB do pool como reserva. Se você tiver 3 servidores e unidades de capacidade de 1 TB, reserve 3 x 1 = 3 TB como reserva. Se você tiver 4 ou mais servidores e unidades de capacidade de 1 TB, reserve 4 x 1 = 4 TB como reserva.
Nota
Em clusters com unidades dos três tipos (NVMe + SSD + HDD), recomendamos reservar o equivalente a um SSD mais um HDD por servidor, até 4 unidades de cada.
Exemplo: Planejamento de capacidade
Considere um cluster de quatro servidores. Cada servidor tem algumas unidades de cache mais dezesseis unidades de 2 TB para capacidade.
4 servers x 16 drives each x 2 TB each = 128 TB
A partir destes 128 TB no pool de armazenamento, reservamos quatro unidades, ou seja, 8 TB, para que os reparos no local possam ocorrer sem pressa de substituir as unidades depois que 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 de Hyper-V altamente ativas, mas também temos muito armazenamento frio – arquivos antigos e backups que precisamos reter. Como temos quatro servidores, vamos criar quatro volumes.
Vamos colocar as máquinas virtuais nos dois primeiros volumes, volume1 e volume2. Escolhemos o ReFS como o sistema de arquivos (para a criação e os pontos de verificação mais rápidos) e o espelhamento de três vias para resiliência para maximizar o desempenho. Vamos colocar o armazenamento a frio nos outros dois volumes, Volume 3 e Volume 4. Escolhemos o NTFS como o sistema de arquivos (para Eliminação de Duplicação de Dados) e a paridade dupla para resiliência para maximizar a capacidade.
Não precisamos tornar todos os volumes do mesmo tamanho, mas, para simplificar, vamos, por exemplo, podemos torná-los todos de 12 TB.
volume1 e Volume2 cada um ocupa 12 TB x 33,3% de eficiência = 36 TB de capacidade de armazenamento físico.
volume3 e Volume4 cada um ocupa 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 em nosso pool. Perfeito!
Dica
Você não precisa criar todos os volumes imediatamente. Você sempre pode estender volumes ou criar novos volumes mais tarde.
Para simplificar, este exemplo usa unidades decimais (base-10) em toda parte, o que significa 1 TB = 1.000.000.000.000 bytes. No entanto, as quantidades de armazenamento no Windows aparecem em unidades binárias (base 2). Por exemplo, cada unidade de 2 TB seria exibida como 1,82 TiB no Windows. Da mesma forma, o pool de armazenamento de 128 TB seria exibido como 116,41 TiB. Isso é esperado.
Uso
Ver Criando volumes.
Próximas etapas
Para obter mais informações, consulte também: