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 a escolha de 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
Nos volumes, você coloca os arquivos necessários para as cargas de trabalho, como arquivos VHD ou VHDX para máquinas virtuais do Hyper-V. Os volumes combinam as unidades no pool de armazenamento para introduzir a tolerância a falhas, a escalabilidade e os benefícios de desempenho dos Espaços de Armazenamento Diretos, a tecnologia de armazenamento definida por software por trás do Azure Stack HCI e do Windows Server.
Observação
Usamos o termo "volume" para nos referirmos conjuntamente ao volume e ao disco virtual sob ele, incluindo a funcionalidade fornecida por outros recursos internos do Windows, como CSV (Volumes Compartilhados em 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.
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.
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 4 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 a Eliminação de Duplicação de Dados no Windows Server versão 1709 e posterior. Consulte a tabela de comparação de recursos de 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 o espelhamento bidirecional ou a 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 uma unidade).
A resiliência aninhada fornece resiliência de dados entre servidores com espelhamento bidirecional e, em seguida, 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 espelho 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 o uso de resiliência aninhada em implantações de produção de clusters de dois servidores. Para obter mais informações, consulte Resiliência aninhada.
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 2 nós ficarem indisponíveis, o pool de armazenamento perderá quorum, pois 2/3 dos discos não estão disponíveis e os discos virtuais estão inacessíveis. 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 reiniciando um servidor quando, de repente, outra unidade ou servidor falhar, todos os dados permanecem seguros e continuamente acessíveis.
Com quatro ou mais servidores
Com quatro ou mais servidores, você pode escolher, para cada volume, se deseja usar o espelhamento de três vias, a paridade dupla (geralmente, chamada de "codificação de eliminação") ou uma mistura dos 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 codificação de paridade tem um processamento mais intensivo, o que pode limitar seu desempenho.
O tipo de resiliência a ser usado depende dos requisitos de desempenho e capacidade do 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 |  Espelho de três vias: 33% Espelho bidirecional: 50% |
 Desempenho mais alto |
| Paridade acelerada por espelho |  Depende da proporção de espelho e paridade |
 Muito mais lento do que o espelhamento, mas até duas vezes mais rápido que a paridade dupla Melhor para leituras e gravações sequenciais grandes |
| Paridade dupla |  4 servidores: 50% 16 servidores: até 80% |
 Maior latência de E/S e uso de CPU em gravações Melhor para leituras e gravações sequenciais grandes |
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. Algumas outras cargas de trabalho, como SoFS (Servidor de Arquivos de Escalabilidade Horizontal), VDI (infraestrutura de área de trabalho virtual) ou outras que não criam muito tráfego de E/S aleatório de desvio 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
As cargas de trabalho que gravam em passagens grandes e sequenciais, como destinos de arquivamento ou backup, têm outra opção: um volume pode combinar 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.
Dica
Se você observar uma diminuição abrupta no desempenho de gravação por meio da ingestão de dados, isso poderá indicar que a parte 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 da gravação diminuir de 400 MB/s para 40 MB/s, considere expandir a parte do espelho ou alternar para o 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
É recomendável 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 serviço de Cópia de Sombra de Volume (VSS) e do fornecedor de software Volsnap – como é comum com cargas de trabalho de servidor de arquivos – limitar o tamanho do volume a 10 TB vai melhorar o desempenho e 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.
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 paralelo imediato no local poderá restaurar os volumes para resiliência total antes mesmo que as unidades com falha sejam 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.
Por exemplo, se você tiver 2 servidores e estiver usando unidades com capacidade de 1 TB, reserve 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.
O Volume1 e o Volume2 ocupam 12 TB x 33,3% de eficiência = 36 TB de capacidade de armazenamento físico.
O Volume3 e o Volume4 ocupam 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!
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: