Resiliência aninhada para espaços de armazenamento diretos
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022 e Windows Server 2019
Importante
O Azure Stack HCI agora faz parte do Azure Local. A renomeação da documentação do produto está em andamento. No entanto, as versões mais antigas do Azure Stack HCI, por exemplo 22H2, continuarão a fazer referência ao Azure Stack HCI e não refletirão a alteração de nome. Mais informações.
A resiliência aninhada é um recurso do Storage Spaces Direct no Azure Stack HCI 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 aninhada, fornece instruções passo a passo para começar e responde às perguntas mais frequentes.
Antes de começar
Considere a resiliência aninhada se:
- Seu cluster executa um destes sistemas operacionais: Azure Stack HCI, versão 21H2, Azure Stack HCI, versão 20H2, Windows Server 2022 ou Windows Server 2019; 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 a seguir Eficiência de capacidade.
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 estabelecida de resiliência de armazenamento distribuído que fornece informações úteis para entender a resiliência aninhada. 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 Stack HCI 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 aninhado proporciona um desempenho intransigente: 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. Novas gravações no volume vão para a parte espelhada com duas cópias 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 espelho bidirecional ou em uma única estrutura de paridade. 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 em Espaços de Armazenamento Diretos.
A paridade aninhada acelerada por espelho alcança maior eficiência de capacidade, em torno de 35% a 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 pesquisa para configurações comuns:
Drives de capacidade por servidor 10% espelho 20% espelho 30% espelho 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. Espelhado para ambos os servidores, sua 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% de eficiência de capacidade global.
Observe que a eficiência de capacidade do espelhamento bidirecional clássico (cerca de 50%) e da paridade aninhada acelerada por espelho (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.
Nota
Se você estiver executando o Windows Server 2022, Azure Stack HCI 21H2 ou Azure Stack HCI 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 unidades de capacidade forem unidades de estado sólido (SSD), defina o -MediaType para SSD em vez disso e altere o -FriendlyName para *OnSSD. Não modifique outros parâmetros.
Gorjeta
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 as suas unidades de capacidade forem unidades de estado sólido (SSD), mude
-StorageTierFriendlyNamespara*OnSSD.Paridade aninhada acelerada por espelho
Para usar a paridade aninhada acelerada por espelho, faça referência aos modelos e
NestedParitycamadaNestedMirrore especifique dois tamanhos, um para cada parte do volume (espelho primeiro, paridade segundo). Por exemplo, para criar um volume de 500 GB com 20% de espelho bidirecional aninhado e 80% de paridade aninhada, execute:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GBSe as suas unidades de capacidade 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: Estender para unidades de cache
Com suas configurações padrão, a resiliência aninhada protege contra a perda de várias unidades de capacidade ao mesmo tempo ou um servidor e uma unidade de capacidade ao mesmo tempo. 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. Depois que o cache de gravação é desativado, o conteúdo do cache de gravação é gravado em dispositivos de capacidade. 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.
Nota
Para um sistema físico de todo o cache (tipo de mídia única), você não precisa considerar a desativação automática do cache de gravação quando um servidor em um cluster de dois servidores estiver inativo. Você precisa considerar isso apenas com o cache de camada de barramento de armazenamento (SBL), que é necessário apenas se você estiver usando HDDs.
(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 é:
| Situação | Comportamento do cache | Pode tolerar a perda da unidade de cache? |
|---|---|---|
| Ambos os servidores para cima | Leituras e gravações em cache, desempenho total | Sim |
| 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 que o cache é gravado em unidades de capacidade) |
Perguntas mais 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 Stack HCI, Windows Server 2022 ou Windows Server 2019, decida com antecedência qual tipo de resiliência melhor atende às suas necessidades. Se estiver atualizando do Windows Server 2016, você poderá criar novos volumes com resiliência aninhada, migrar seus dados e excluir os volumes mais antigos.
Posso usar resiliência aninhada com vários tipos de drives de capacidade?
Sim, basta especificar o de cada camada de acordo durante a -MediaType 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 aninhada com três ou mais servidores?
Não, use a resiliência aninhada apenas se o cluster tiver exatamente dois servidores.
De quantas unidades preciso 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 aninhada, e a recomendação de capacidade de reserva também permanece inalterada.
A resiliência aninhada altera a forma como funciona a substituição da unidade?
N.º
A resiliência aninhada altera a forma como funciona a substituição do nó do servidor?
N.º Para substituir um nó de servidor e suas unidades, 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 obter detalhes, consulte o artigo Remover servidores .