Planear 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 orientações sobre como planear volumes de cluster para satisfazer as necessidades de desempenho e capacidade das suas cargas de trabalho, incluindo escolher o respetivo sistema de ficheiros, tipo de resiliência e tamanho.

Nota

Espaços de Armazenamento Direto não suporta um servidor de ficheiros para utilização geral. Se precisar de executar o servidor de ficheiros ou outros serviços genéricos no Espaço de Armazenamento Direto, configure-o nas máquinas virtuais.

Rever: O que são volumes

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

Nota

Utilizamos o termo "volume" para referenciar em conjunto o volume e o disco virtual abaixo do mesmo, incluindo a funcionalidade fornecida por outras funcionalidades incorporadas do Windows, como Volumes Partilhados de Cluster (CSV) e ReFS. A compreensão destas distinções ao nível da implementação não é necessária para planear e implementar Espaços de Armazenamento Direto com êxito.

Todos os volumes são acessíveis por todos os servidores no cluster ao mesmo tempo. Depois de criadas, são apresentadas em C:\ClusterStorage\ em todos os servidores.

Escolher quantos volumes criar

Recomendamos que faça do número de volumes um múltiplo do número de servidores no cluster. Por exemplo, se tiver 4 servidores, terá um desempenho mais consistente com 4 volumes totais do que com 3 ou 5. Isto permite que o cluster distribua o volume "ownership" (um servidor processa a orquestração de metadados para cada volume) uniformemente entre os servidores.

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

Escolher o sistema de ficheiros

Recomendamos que utilize o novo Sistema de Ficheiros Resiliente (ReFS) para Espaços de Armazenamento Direto. O ReFS é o principal sistema de ficheiros concebido para fins de virtualização e oferece muitas vantagens, incluindo acelerações de desempenho dramáticas e proteção incorporada contra danos em dados. Suporta quase todas as principais funcionalidades do NTFS, incluindo a Eliminação de Dados Duplicados na versão 1709 e posterior do Windows Server. Veja a tabela de comparação de funcionalidades do ReFS para obter detalhes.

Se a carga de trabalho necessitar de uma funcionalidade que o ReFS ainda não suporta, pode utilizar o NTFS.

Dica

Os volumes com sistemas de ficheiros diferentes podem coexistir no mesmo cluster.

Escolher o tipo de resiliência

Os volumes no Espaços de Armazenamento Direto fornecem resiliência para proteger contra problemas de hardware, como falhas de unidades ou servidores, e para permitir a disponibilidade contínua em toda a manutenção do servidor, como atualizações de software.

Nota

Os tipos de resiliência que pode escolher são independentes dos tipos de unidades que tem.

Com dois servidores

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

O espelhamento bidirecional mantém duas cópias de todos os dados, uma cópia nas unidades em cada servidor. A sua eficiência de armazenamento é de 50 por cento; para escrever 1 TB de dados, precisa de, pelo menos, 2 TB de capacidade de armazenamento físico no agrupamento de armazenamento. O espelhamento bidirecional pode 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 espelhos. O aninhamento fornece resiliência de dados mesmo quando um servidor está a reiniciar ou indisponível. A sua eficiência de armazenamento é de 25 por cento com espelhamento bidirecional aninhado e cerca de 35-40 por cento para paridade aninhada acelerada pelo espelho. A resiliência aninhada pode tolerar com segurança duas falhas de hardware de cada vez (duas unidades ou um servidor e uma unidade no servidor restante). Devido a esta resiliência de dados adicionada, recomendamos que utilize resiliência aninhada em implementaçõ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, deve utilizar o espelhamento tridirecional para melhorar a tolerância a falhas e o desempenho. O espelhamento tridirecional mantém três cópias de todos os dados, uma cópia nas unidades em cada servidor. A eficiência de armazenamento é de 33,3 por cento– para escrever 1 TB de dados, precisa de, pelo menos, 3 TB de capacidade de armazenamento físico no agrupamento de armazenamento. O espelhamento tridirecional pode tolerar com segurança, pelo menos, dois problemas de hardware (unidade ou servidor) de cada vez. Se dois nós ficarem indisponíveis, o agrupamento de armazenamento perderá quórum, uma vez que 2/3 dos discos não estão disponíveis e os discos virtuais ficarão inacessíveis. No entanto, um nó pode estar inativo e um ou mais discos noutro nó podem falhar e os discos virtuais permanecerão online. Por exemplo, se estiver a reiniciar 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, pode escolher para cada volume se pretende utilizar espelhamento tridirecional, paridade dupla (muitas vezes denominada "codificação de eliminação" ou misturar os dois com paridade acelerada por espelhos.

A paridade dupla proporciona a mesma tolerância a falhas que o espelhamento tridirecional, mas com uma melhor eficiência de armazenamento. Com quatro servidores, a eficiência de armazenamento é de 50,0 por cento; para armazenar 2 TB de dados, precisa de 4 TB de capacidade de armazenamento físico no agrupamento de armazenamento. Isto aumenta para 66,7 por cento de eficiência de armazenamento com sete servidores e continua até 80,0 por cento de eficiência de armazenamento. A desvantagem é que a codificação de paridade é mais intensiva em termos de computação, o que pode limitar o seu desempenho.

O tipo de resiliência a utilizar depende das necessidades da carga de trabalho. Segue-se uma tabela que resume quais as cargas de trabalho que 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 da capacidade	Velocidade	Cargas de Trabalho
Espelho	Espelho tridirecional: 33% Espelho bidirecional: 50%	Desempenho mais elevado	Cargas de trabalho virtualizadas Bases de Dados Outras cargas de trabalho de elevado desempenho
Paridade acelerada por espelhos	Depende da proporção de espelho e paridade	Muito mais lento que o espelho, mas até duas vezes mais rápido que a paridade dupla Melhor para grandes leituras e escritas sequenciais	Arquivo e cópia de segurança Infraestrutura de ambiente de trabalho virtualizada
Paridade dupla	4 servidores: 50% 16 servidores: até 80%	Latência de E/S mais elevada & utilização da CPU em escritas Melhor para grandes leituras e escritas sequenciais	Arquivo e cópia de segurança Infraestrutura de ambiente de trabalho virtualizada

Quando o desempenho é mais importante

As cargas de trabalho que tenham requisitos de latência rigorosos ou que necessitem de muitos IOPS aleatórios mistos, como bases de dados SQL Server ou máquinas virtuais hyper-V sensíveis ao desempenho, devem ser executadas em volumes que utilizem espelhamento para maximizar o desempenho.

Dica

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

Quando a capacidade é mais importante

As cargas de trabalho que escrevem com pouca frequência, como armazéns de dados ou armazenamento "frio", devem ser executadas em volumes que utilizem paridade dupla para maximizar a eficiência de armazenamento. Determinadas outras cargas de trabalho, como Scale-Out Servidor de Ficheiros (SoFS), infraestrutura de ambiente de trabalho virtual (VDI) ou outras que não criam muito tráfego de E/S aleatório de desfasamento rápido e/ou não requerem o melhor desempenho também podem utilizar paridade dupla, a seu critério. A paridade aumenta inevitavelmente a utilização da CPU e a latência de E/S, particularmente nas escritas, em comparação com o espelhamento.

Quando os dados são escritos em massa

As cargas de trabalho que escrevem em passes grandes e sequenciais, como destinos de arquivo ou de cópia de segurança, têm outra opção: um volume pode misturar espelhamento e paridade dupla. Escreve primeiro na parte espelhada e é gradualmente movida para a parte da paridade mais tarde. Isto acelera a ingestão e reduz a utilização de recursos quando chegam grandes escritas ao permitir que a codificação de paridade intensiva em computação ocorra durante mais tempo. Ao dimensionar as partes, considere que a quantidade de escritas que ocorre ao mesmo tempo (como uma cópia de segurança diária) deve caber confortavelmente na parte espelhada. Por exemplo, se ingerir 100 GB uma vez por dia, considere utilizar o espelhamento de 150 GB a 200 GB e paridade dupla para o resto.

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

Dica

Se observar uma diminuição abrupta do desempenho de escrita a meio da ingestão de dados, tal poderá indicar que a parte espelhada não é suficientemente grande ou que a paridade acelerada pelo espelho não é adequada para o seu caso de utilização. Por exemplo, se o desempenho da escrita diminuir de 400 MB/s para 40 MB/s, considere expandir a parte espelhada ou mudar para o espelho tridirecional.

Acerca das implementações com NVMe, SSD e HDD

Em implementações com dois tipos de unidades, as unidades mais rápidas fornecem colocação em cache enquanto as unidades mais lentas fornecem capacidade. Isto acontece automaticamente – para obter mais informações, consulte Compreender a cache no Espaços de Armazenamento Direto. Nestas implementações, todos os volumes residem, em última análise, no mesmo tipo de unidades – as unidades de capacidade.

Em implementações com os três tipos de unidades, apenas as unidades mais rápidas (NVMe) fornecem colocação em cache, deixando dois tipos de unidades (SSD e HDD) para fornecer capacidade. Para cada volume, pode escolher se reside inteiramente na camada SSD, inteiramente na camada HDD ou se abrange os dois.

Importante

Recomendamos que utilize o escalão SSD para colocar as cargas de trabalho mais sensíveis ao desempenho em tudo flash.

Escolher o tamanho dos volumes

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

Dica

Se utilizar uma solução de cópia de segurança que depende do serviço de Cópia Sombra de Volumes (VSS) e do fornecedor de software Volsnap , como é comum nas cargas de trabalho do servidor de ficheiros, limitar o tamanho do volume a 10 TB melhorará o desempenho e a fiabilidade. As soluções de cópia de segurança que utilizam a API RCT do Hyper-V mais recente e/ou a clonagem de blocos do ReFS e/ou as APIs de cópia de segurança sqL nativas têm um bom desempenho até 32 TB e mais além.

Requisitos de espaço

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

O tamanho é distinto da quantidade de espaço do volume, da capacidade total de armazenamento físico que ocupa no agrupamento de armazenamento. A pegada depende do tipo de resiliência. Por exemplo, os volumes que utilizam espelhamento tridirecional têm uma pegada três vezes superior ao seu tamanho.

Os requisitos de espaço dos volumes têm de caber no agrupamento de armazenamento.

Capacidade de reserva

Deixar alguma capacidade no agrupamento de armazenamento não alocado dá espaço aos volumes para reparar "no local" após a falha das unidades, melhorando a segurança e o desempenho dos dados. Se existir capacidade suficiente, uma reparação paralela imediata no local pode restaurar os volumes para resiliência total mesmo antes de as unidades com falha serem substituídas. Isto acontece automaticamente.

Recomendamos reservar o equivalente a uma unidade de capacidade por servidor, até 4 unidades. Pode reservar mais a seu critério, mas esta recomendação mínima garante que uma reparação paralela imediata, no local, pode ser bem-sucedida após a falha de qualquer unidade.

Por exemplo, se tiver 2 servidores e estiver a utilizar 1 unidade de capacidade TB, reserve 2 x 1 = 2 TB do conjunto como reserva. Se tiver 3 servidores e unidades de capacidade de 1 TB, reserve 3 x 1 = 3 TB como reserva. Se 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: Planeamento de capacidade

Considere um cluster de quatro servidores. Cada servidor tem algumas unidades de cache mais dezasseis unidades de 2 TB para capacidade.

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

A partir destes 128 TB no agrupamento de armazenamento, reservamos quatro unidades, ou 8 TB, para que as reparações no local possam acontecer sem qualquer pressa para substituir as unidades depois de falharem. Isto deixa 120 TB de capacidade de armazenamento físico no conjunto com o qual podemos criar volumes.

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

Suponha que precisamos da nossa implementação para alojar algumas máquinas virtuais hyper-V altamente ativas, mas também temos muito armazenamento a frio – ficheiros antigos e cópias de segurança que precisamos de reter. Uma vez que temos quatro servidores, vamos criar quatro volumes.

Vamos colocar as máquinas virtuais nos dois primeiros volumes: Volume1 e Volume2. Escolhemos ReFS como sistema de ficheiros (para a criação e pontos de verificação mais rápidos) e espelhamento tridirecional para resiliência para maximizar o desempenho. Vamos colocar o armazenamento a frio nos outros dois volumes: Volume 3 e Volume 4. Escolhemos NTFS como sistema de ficheiros (para Eliminação de Dados Duplicados) e paridade dupla para resiliência para maximizar a capacidade.

Não temos de tornar todos os volumes do mesmo tamanho, mas, para simplificar, vamos, por exemplo, torná-los todos com 12 TB.

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

O Volume3 e o 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 cabem exatamente na capacidade de armazenamento físico disponível no nosso conjunto. Perfeito!

Dica

Não precisa de criar todos os volumes imediatamente. Pode sempre expandir volumes ou criar novos volumes mais tarde.

Para simplificar, este exemplo utiliza unidades decimais (base-10) em todo, ou seja, 1 TB = 1 000 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 agrupamento de armazenamento de 128 TB apareceria como 116,41 TiB. Isto era esperado.

Utilização

Veja Criar volumes no Azure Stack HCI.

Passos seguintes

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

• Escolher unidades para Espaços de Armazenamento Direto
• Tolerância a falhas e eficiência de armazenamento