Planear volumes no Azure Stack HCI e nos clusters do Windows Server
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server 2019
Este artigo fornece orientação 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
O Storage Spaces Direct não suporta 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 Hyper-V máquinas virtuais. Os volumes combinam as unidades no pool de armazenamento para introduzir os benefícios de tolerância a falhas, escalabilidade e desempenho do Storage Spaces Direct, 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 Volumes Compartilhados de Cluster (CSV) e ReFS. Não é necessário compreender essas distinções de nível de implementação para planejar e implantar o Storage Spaces Direct com êxito.
Todos os volumes são acessíveis por todos os servidores no cluster ao mesmo tempo. Uma vez criados, eles aparecem em C:\ClusterStorage\ em todos os servidores.
Escolher quantos volumes criar
Recomendamos tornar o número de volumes um múltiplo do número de servidores no cluster. Por exemplo, se você tiver 4 servidores, experimentará 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 lida com 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 o uso do novo Sistema de Ficheiros Resiliente (ReFS) para Espaços de Armazenamento Direto. O ReFS é o principal sistema de arquivos desenvolvido especificamente para virtualização e oferece muitas vantagens, incluindo acelerações de desempenho dramáticas e proteção integrada contra corrupção de dados. Ele suporta quase todos os principais recursos NTFS, incluindo a Desduplicação de Dados no Windows Server versão 1709 e posterior. Consulte a tabela de comparação de recursos do ReFS para obter detalhes.
Se sua carga de trabalho exigir um recurso que o ReFS ainda não suporta, você poderá usar NTFS.
Dica
Volumes com sistemas de arquivos diferentes podem coexistir no mesmo cluster.
Escolher o tipo de resiliência
Os volumes no Storage Spaces Direct fornecem resiliência para proteger contra problemas de hardware, como falhas de unidade ou servidor, e para permitir a disponibilidade contínua durante a manutenção do servidor, como atualizações de software.
Observação
Os tipos de resiliência que podes escolher são independentes dos tipos de unidades que possuis.
Com dois servidores
Com dois servidores no cluster, 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 de 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 é capaz de tolerar com segurança uma falha de hardware de cada vez (um servidor ou unidade).
A resiliência aninhada fornece resiliência de dados entre servidores com espelhamento bidirecional e, em seguida, adiciona resiliência dentro de um servidor com espelhamento bidirecional ou paridade acelerada por espelho. O aninhamento fornece resiliência de dados mesmo quando um servidor está em reinício ou indisponível. A eficiência de armazenamento é de 25% com espelhamento bidirecional aninhado e cerca de 35-40% para paridade acelerada por espelhamento aninhado. A resiliência aninhada pode tolerar com segurança duas falhas de hardware ao mesmo tempo (duas unidades de disco, ou um servidor e uma unidade de disco 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 vias para melhor tolerância a falhas e desempenho. O espelhamento tridirecional mantém três cópias de todos os dados, com uma cópia em discos 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) de cada vez. Se 2 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 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 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 (geralmente chamada de "codificação de eliminação") ou misturar os dois com paridade acelerada por espelho.
A paridade dupla oferece 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 contrapartida é que a codificação de paridade é mais intensiva em computação, o que pode limitar seu desempenho.
O tipo de resiliência a ser usado depende dos requisitos de desempenho e capacidade do seu ambiente. Esta é uma tabela que resume o desempenho e a eficiência de armazenamento de cada tipo de resiliência.
| Tipo de resiliência | Eficiência da capacidade | Velocidade |
|---|---|---|
| Espelho |
Espelho de três lados: 33% Espelho bidirecional: 50% |
O mais alto desempenho |
| Paridade acelerada por espelho |
Depende da proporção de espelho e paridade |
Muito mais lento do que o espelho, mas até duas vezes mais rápido que a paridade dupla Ideal para grandes gravações e leituras sequenciais |
| Paridade dupla |
4 servidores: 50% 16 servidores: até 80% |
Maior latência de E/S & utilização da CPU em operações de gravação Ideal para grandes gravações e leituras sequenciais |
Quando o desempenho é mais importante
As cargas de trabalho que têm requisitos de latência estritos ou que precisam de muitas IOPS aleatórias mistas, como bancos de dados SQL Server ou máquinas virtuais de 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 espelhamento para quase todos os nossos exemplos de desempenho.
Quando a capacidade é mais importante
As 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. Certas outras cargas de trabalho, como Scale-Out File Server (SoFS), infraestrutura de área de trabalho virtual (VDI) ou outras que não criam muito tráfego de E/S aleatório de deriva rápida 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, particularmente em gravações, em comparação com o espelhamento.
Quando os dados são gravados em massa
Cargas de trabalho que gravam em grandes sequências, como destinos de arquivo ou backup, têm outra opção: um volume pode combinar espelhamento e paridade dupla. Os dados são primeiro gravados na porção espelhada e são gradualmente movidos para a porção de paridade mais tarde. Isto acelera a ingestão e reduz a utilização de recursos quando chegam grandes gravações, permitindo que a codificação de paridade, intensiva em termos de computação, seja distribuída ao longo de um período de tempo mais extenso. Ao dimensionar as partes, considere que a quantidade de gravações que acontecem de uma só vez (como um backup diário) deve caber confortavelmente na parte espelhada. Por exemplo, se você ingerir 100 GB uma vez por dia, considere usar espelhamento para 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 parte do espelho não é grande o suficiente ou que a paridade acelerada pelo 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 do espelho ou mudar para espelho de três vias.
Sobre implantações com NVMe, SSD e HDD
Em implantações com dois tipos de discos, os discos mais rápidos fornecem cache, enquanto os discos mais lentos fornecem capacidade. Isso acontece automaticamente – para obter mais informações, consulte Noções básicas sobre o cache no Storage Spaces Direct. Nessas implantações, todos os volumes residem, em última análise, no mesmo tipo de drives – os drives de capacidade.
Em implantações com os três tipos de unidades, apenas as unidades mais rápidas (NVMe) fornecem cache, deixando dois tipos de unidades (SSD e HDD) para fornecer capacidade. Para cada volume, pode escolher se reside inteiramente no nível SSD, inteiramente no nível HDD ou se abrange os dois.
Importante
Recomendamos usar a camada SSD para colocar suas cargas de trabalho mais sensíveis ao desempenho em all-flash.
Escolher 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ópias de Sombra de Volume) e do provedor de software Volsnap, como é comum em cargas de trabalho de 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 API RCT do Hyper-V mais recente e/ou a clonagem de bloco ReFS e/ou as APIs de backup SQL nativas têm um bom desempenho de até 32 TB ou mais.
Pegada
O tamanho de um volume refere-se à sua capacidade utilizável, à quantidade de dados que pode armazenar. Isso é fornecido pelo parâmetro -Size do cmdlet New-Volume e, em seguida, 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 do seu tipo de resiliência. Por exemplo, os volumes que usam espelhamento triplo têm uma pegada três vezes 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á aos volumes espaço para reparar "in-loco" depois que os drives falham, melhorando a segurança e o desempenho dos dados. Se houver capacidade suficiente, um reparo imediato, paralelo e no local pode restaurar os volumes para a resiliência total, mesmo antes de as unidades com falha serem substituídas. Isso acontece automaticamente.
Recomendamos reservar o equivalente a um disco de capacidade por servidor, até 4 discos. Você pode reservar mais a seu critério, mas esta recomendação mínima garante que um reparo paralelo e no mesmo local possa ter sucesso após a falha de qualquer disco.
Por exemplo, se você tiver 2 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.
Observação
Em clusters com unidades dos três tipos (NVMe + SSD + HDD), recomendamos reservar o equivalente a uma SSD mais uma 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 desses 128 TB no pool de armazenamento, separamos quatro drives, ou 8 TB, para que os reparos no local possam acontecer sem qualquer pressa para substituir os drives depois que eles 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
Suponhamos que precisamos de nossa implantação para hospedar algumas máquinas virtuais 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 rápida e pontos de verificação) e o espelhamento de três vias para aumentar a resiliência e maximizar o desempenho. Vamos colocar o armazenamento a frio para os outros dois volumes, Volume 3 e Volume 4. Escolhemos NTFS como o sistema de arquivos (para eliminação de duplicação de dados) e paridade dupla para resiliência para maximizar a capacidade.
Não somos obrigados a fazer todos os volumes do mesmo tamanho, mas para simplificar, vamos – por exemplo, podemos fazer todos eles 12 TB.
Volume1 e Volume2 ocupam 12 TB x 33,3% de eficiência = 36 TB de capacidade de armazenamento físico.
Volume3 e 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 em nossa piscina. 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) por 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 apareceria como 1,82 TiB no Windows. Da mesma forma, o pool de armazenamento de 128 TB apareceria como 116,41 TiB. Isso é esperado.
Utilização
Consulte Criação de volumes.
Próximos passos
Para obter mais informações, consulte também: