Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A resiliência aninhada é um recurso dos Espaços de Armazenamento Diretos no Azure Local e no Windows Server. Ele permite que um cluster de dois servidores resista a várias falhas de hardware ao mesmo tempo sem perda de disponibilidade de armazenamento, para que usuários, aplicativos e máquinas virtuais continuem a ser executados sem interrupções. Este artigo explica como funciona a resiliência hierárquica, fornece instruções detalhadas para iniciar e responde às perguntas mais frequentes.
Antes de começar
Considere uma resiliência aninhada se:
- Seu cluster executa um destes sistemas operacionais: Azure Local, versão 22H2 ou posterior, Windows Server 2019 ou posterior; e ainda
- Seu cluster tem exatamente dois nós de servidor.
Não é possível usar a resiliência aninhada se:
- Seu cluster executa o Windows Server 2016; quer
- Seu cluster tem apenas um único nó de servidor ou tem três ou mais nós de servidor.
Porquê a resiliência aninhada
Os volumes que usam resiliência aninhada podem permanecer on-line e acessíveis mesmo se várias falhas de hardware acontecerem ao mesmo tempo, ao contrário da resiliência de espelhamento bidirecional clássica. Por exemplo, se duas unidades falharem ao mesmo tempo ou se um servidor ficar inativo e uma unidade falhar, os volumes que usam resiliência aninhada permanecerão online e acessíveis. Para infraestrutura hiperconvergente, isso aumenta o tempo de atividade para aplicativos e máquinas virtuais; Para cargas de trabalho do servidor de arquivos, isso significa que os usuários têm acesso ininterrupto aos seus arquivos.
A contrapartida é que a resiliência aninhada tem menor eficiência de capacidade do que o espelhamento bidirecional clássico, o que significa que você obtém um pouco menos de espaço utilizável. Para obter detalhes, consulte a seção Eficiência de capacidade a seguir.
Como funciona
Esta seção fornece informações básicas sobre resiliência aninhada para Espaços de Armazenamento Diretos e descreve as duas novas opções de resiliência e sua eficiência de capacidade.
Inspiração: RAID 5+1
O RAID 5+1 é uma forma bem estabelecida de resiliência de armazenamento distribuído que fornece informações úteis para entender a resiliência hierárquica. No RAID 5+1, dentro de cada servidor, a resiliência local é fornecida pelo RAID-5, ou paridade única, para proteger contra a perda de qualquer unidade. Em seguida, mais resiliência é fornecida pelo RAID-1, ou espelhamento bidirecional, entre os dois servidores para proteger contra a perda de qualquer um dos servidores.
Opções de resiliência
O Storage Spaces Direct no Azure Local e no Windows Server oferece duas opções de resiliência implementadas em software, sem a necessidade de hardware RAID especializado:
Espelho bidirecional aninhado. Dentro de cada servidor, a resiliência local é fornecida pelo espelhamento bidirecional e, em seguida, a resiliência adicional é fornecida pelo espelhamento bidirecional entre os dois servidores. É essencialmente um espelho de quatro vias, com duas cópias em cada servidor que estão localizadas em discos físicos diferentes. O espelhamento bidirecional em camadas proporciona um desempenho irrepreensível: as gravações vão para todas as cópias e as leituras vêm de qualquer cópia.
Paridade aninhada acelerada por espelho. Combine espelhamento bidirecional aninhado, da imagem anterior, com paridade aninhada. Dentro de cada servidor, a resiliência local para a maioria dos dados é fornecida pela aritmética de paridade bit a bit única, exceto novas gravações recentes que usam espelhamento bidirecional. Em seguida, a resiliência adicional para todos os dados é fornecida pelo espelhamento bidirecional entre os servidores. Novos registos no volume são direcionados para a secção espelhada, criando duas réplicas em discos físicos separados em cada servidor. À medida que a parte espelhada do volume é preenchida em cada servidor, os dados mais antigos são convertidos e salvos na parte de paridade em segundo plano. Como resultado, cada servidor tem os dados para o volume em espelhamento bidirecional ou em estrutura de paridade única. Isso é semelhante ao funcionamento da paridade acelerada por espelho — com a diferença de que a paridade acelerada por espelho requer quatro servidores no cluster e no pool de armazenamento e usa um algoritmo de paridade diferente.
Eficiência da capacidade
A eficiência da capacidade é a relação entre espaço utilizável e volume ocupado. Ele descreve a sobrecarga de capacidade atribuível à resiliência e depende da opção de resiliência escolhida. Como um exemplo simples, o armazenamento de dados sem resiliência é 100% eficiente em termos de capacidade (1 TB de dados ocupa 1 TB de capacidade de armazenamento físico), enquanto o espelhamento bidirecional é 50% eficiente (1 TB de dados ocupa 2 TB de capacidade de armazenamento físico).
O espelho bidirecional aninhado grava quatro cópias de tudo. Isso significa que, para armazenar 1 TB de dados, você precisa de 4 TB de capacidade de armazenamento físico. Embora sua simplicidade seja atraente, a eficiência de capacidade do espelho bidirecional aninhado de 25% é a mais baixa de qualquer opção de resiliência no Storage Spaces Direct.
A paridade aninhada acelerada por espelho alcança maior eficiência de capacidade, em torno de 35%-40%, que depende de dois fatores: o número de drives de capacidade em cada servidor e a combinação de espelho e paridade especificada para o volume. Esta tabela fornece uma referência para configurações comuns.
Drives de capacidade por servidor Espelho de 10% Espelho de 20% Espelho de 30% 4 35.7% 34.1% 32.6% 5 37.7% 35.7% 33.9% 6 39.1% 36.8% 34.7% 7+ 40.0% 37.5% 35.3% Segue-se um exemplo da matemática completa. Suponhamos que temos seis unidades de capacidade em cada um dos dois servidores e queremos criar um volume de 100 GB composto por 10 GB de espelho e 90 GB de paridade. O espelho bidirecional local do servidor é 50,0% eficiente, o que significa que os 10 GB de dados espelhados levam 20 GB para serem armazenados em cada servidor. Espelhada em ambos os servidores, a pegada total é de 40 GB. A paridade única servidor-local, neste caso, é 5/6 = 83,3% eficiente, o que significa que os 90 GB de dados de paridade levam 108 GB para serem armazenados em cada servidor. Espelhado para ambos os servidores, sua pegada total é de 216 GB. A pegada total é, portanto, [(10 GB / 50,0%) + (90 GB / 83,3%)] × 2 = 256 GB, para 39,1% eficiência global da capacidade.
Observe que a eficiência de capacidade do espelhamento bidirecional clássico (cerca de 50%) e da paridade acelerada por espelho aninhada (até 40%) não são muito diferentes. Dependendo de suas necessidades, a eficiência de capacidade um pouco menor pode valer a pena o aumento significativo na disponibilidade de armazenamento. Você escolhe resiliência por volume, para que possa misturar volumes de resiliência aninhados e volumes espelhados bidirecionais clássicos dentro do mesmo cluster.
Criar volumes de resiliência aninhados
Você pode usar cmdlets de armazenamento familiares no PowerShell para criar volumes com resiliência aninhada, conforme descrito na seção a seguir.
Etapa 1: Criar modelos de camada de armazenamento (somente Windows Server 2019)
O Windows Server 2019 exige que você crie novos modelos de camada de armazenamento usando o cmdlet antes de New-StorageTier criar volumes. Você só precisa fazer isso uma vez e, em seguida, cada novo volume criado pode fazer referência a esses modelos.
Note
Se você estiver executando o Windows Server 2022, Azure Stack HCI, versão 21H2, ou Azure Stack HCI, versão 20H2, poderá ignorar esta etapa.
Especifique as -MediaType unidades de capacidade e, opcionalmente, as -FriendlyName de sua escolha. Não modifique outros parâmetros.
Por exemplo, se suas unidades de capacidade forem unidades de disco rígido (HDD), inicie o PowerShell como Administrador e execute os cmdlets a seguir.
Para criar uma camada NestedMirror:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4
Para criar uma camada NestedParity:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk
Se as suas unidades de capacidade forem unidades de estado sólido (SSD), defina o -MediaType para SSD ao invés e altere o -FriendlyName para *OnSSD. Não modifique outros parâmetros.
Tip
Verifique se Get-StorageTier as camadas foram criadas com êxito.
Etapa 2: Criar volumes aninhados
Crie novos volumes usando o New-Volume cmdlet.
Espelho bidirecional aninhado
Para usar o espelho bidirecional aninhado, faça referência ao
NestedMirrormodelo de camada e especifique o tamanho. Por exemplo:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GBSe os seus discos forem unidades de estado sólido (SSD), mude
-StorageTierFriendlyNamespara*OnSSD.Paridade aninhada acelerada por espelho
Para usar a paridade aninhada acelerada por espelhos, faça referência aos modelos das camadas
NestedMirroreNestedParitye especifique dois tamanhos, um para cada parte do volume (espelho primeiro, paridade segundo). Por exemplo, para criar um volume de 500 GB que seja 20% espelho bidirecional aninhado e 80% paridade aninhada, execute:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GBSe os seus discos forem unidades de estado sólido (SSD), mude
-StorageTierFriendlyNamespara*OnSSD.
Etapa 3: Continuar no Windows Admin Center
Os volumes que usam resiliência aninhada aparecem no Windows Admin Center com rotulagem clara, como na captura de tela a seguir. Depois de criados, você pode gerenciá-los e monitorá-los usando o Windows Admin Center como qualquer outro volume no Storage Spaces Direct.
Opcional: Expandir para unidades de cache
Com as suas configurações padrão, a resiliência encadeada protege contra a perda de vários discos de capacidade ao mesmo tempo ou de um servidor e um disco de capacidade simultaneamente. Para estender essa proteção às unidades de cache, há outra consideração: como as unidades de cache geralmente fornecem cache de leitura e gravação para várias unidades de capacidade, a única maneira de garantir que você possa tolerar a perda de uma unidade de cache quando o outro servidor estiver inativo é não armazenar gravações em cache, mas isso afeta o desempenho.
Para resolver esse cenário, o Storage Spaces Direct oferece a opção de desabilitar automaticamente o cache de gravação quando um servidor em um cluster de dois servidores estiver inativo e, em seguida, reativar o cache de gravação assim que o servidor fizer backup. Para permitir reinicializações de rotina sem impacto no desempenho, o cache de gravação não é desativado até que o servidor fique inativo por 30 minutos. Assim que o cache de gravação é desativado, o conteúdo do cache de gravação é gravado nos dispositivos de armazenamento. Depois disso, o servidor pode tolerar um dispositivo de cache com falha no servidor online, embora as leituras do cache possam ser atrasadas ou falhar se um dispositivo de cache falhar.
Note
Para um sistema físico inteiramente em cache (um único tipo de mídia), não é necessário considerar desativar automaticamente o cache de gravação quando um dos servidores em um cluster de dois servidores estiver inativo. Deve considerar isto apenas em relação ao cache da camada de barramento de armazenamento (SBL), que é necessário apenas se estiver a utilizar discos rígidos.
(Opcional) Para desabilitar automaticamente o cache de gravação quando um servidor em um cluster de dois servidores estiver inativo, inicie o PowerShell como Administrador e execute:
Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"
Uma vez definido como True, o comportamento do cache é:
| Situation | Comportamento do cache | É capaz de tolerar a perda do disco de cache? |
|---|---|---|
| Ambos os servidores estão operacionais | Leituras e gravações em cache, desempenho total | Yes |
| Servidor inativo, primeiros 30 minutos | Leituras e gravações em cache, desempenho total | Não (temporariamente) |
| Após os primeiros 30 minutos | Somente leitura de cache, desempenho afetado | Sim (depois de o cache ser gravado em discos de capacidade) |
Perguntas frequentes
Encontre respostas para perguntas frequentes sobre resiliência aninhada.
Posso converter um volume existente entre espelho bidirecional e resiliência aninhada?
Não, os volumes não podem ser convertidos entre tipos de resiliência. Para novas implantações no Azure Local, Windows Server 2022 ou Windows Server 2019, decida com antecedência qual tipo de resiliência melhor atende às suas necessidades. Se estiver a atualizar do Windows Server 2016, pode criar novos volumes com resiliência aninhada, migrar os seus dados e, em seguida, eliminar os volumes mais antigos.
Posso usar resiliência aninhada com vários tipos de unidades de armazenamento?
Sim, basta especificar -MediaType de cada camada de acordo durante etapa 1 acima. Por exemplo, com NVMe, SSD e HDD no mesmo cluster, o NVMe fornece cache, enquanto os dois últimos fornecem capacidade: defina a NestedMirror camada como -MediaType SSD e a NestedParity camada como -MediaType HDD. Neste caso, a eficiência da capacidade de paridade depende apenas do número de unidades HDD e necessita de pelo menos 4 delas por servidor.
Posso usar resiliência hierárquica com três ou mais servidores?
Não, use a resiliência aninhada apenas se o cluster tiver exatamente dois servidores.
Quantas unidades são necessárias para usar a resiliência aninhada?
O número mínimo de unidades necessárias para o Storage Spaces Direct é de quatro unidades de capacidade por nó de servidor, mais duas unidades de cache por nó de servidor (se houver). Isso não foi alterado em relação ao Windows Server 2016. Não há outro requisito para resiliência em camadas, e a recomendação de capacidade de reserva também permanece inalterada.
A resiliência aninhada altera a forma como funciona a substituição de discos?
No.
A resiliência aninhada altera a forma como funciona a substituição do nó do servidor?
No. Para substituir um nó de servidor e os seus discos rígidos, siga esta ordem:
- Desative as unidades no servidor de saída
- Adicionar o novo servidor, com suas unidades, ao cluster
- O pool de armazenamento será reequilibrado
- Remova o servidor de saída e suas unidades
Para mais detalhes, consulte o artigo Remover servidores.