Saiba mais sobre: 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
A resiliência aninhada é uma funcionalidade de Espaços de Armazenamento Diretos 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 sendo 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:
- O 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
- Seu cluster tem exatamente dois nós de servidor.
Você não poderá usar resiliência aninhada se:
- Seu cluster executa o Windows Server 2016; ou
- O cluster tem apenas um único nó de servidor ou tem três ou mais nós de servidor.
Por que a resiliência aninhada
Os volumes que usam resiliência aninhada podem permanecer online e acessíveis mesmo que várias falhas de hardware ocorram ao mesmo tempo, ao contrário da resiliência clássica do espelhamento bidirecional . Por exemplo, se duas unidades falharem ao mesmo tempo ou se um servidor falhar 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 arquivos.
A compensação é 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 espaço utilizável. Para obter detalhes, consulte a seção Eficiência de capacidade a seguir.
Como ele funciona
Esta seção fornece a tela de fundo 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
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, em cada servidor, a resiliência local é fornecida pelo RAID-5, ou paridade única, para proteger contra a perda de qualquer unidade única. Em seguida, mais resiliência é fornecida pelo RAID-1, ou espelhamento bidirecional, entre os dois servidores para proteger contra a perda de qualquer servidor.
Opções de resiliência
Espaços de Armazenamento Diretos no Azure Stack HCI e no Windows Server oferece duas opções de resiliência implementadas no software, sem a necessidade de hardware RAID especializado:
Espelho bidirecional aninhado. Em 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 uma espelho de quatro vias, com duas cópias em cada servidor que estão localizadas em discos físicos diferentes. O espelhamento bidirecional aninhado fornece um desempenho intransigente: as gravações vão para todas as cópias e as leituras vêm de qualquer cópia.
Paridade acelerada por espelho aninhado. Combine o espelhamento bidirecional aninhado, da imagem anterior, com paridade aninhada. Em cada servidor, a resiliência local para a maioria dos dados é fornecida pela aritmética de paridade bit a bit única, exceto por novas gravações recentes que usam espelhamento bidirecional. Em seguida, uma resiliência adicional para todos os dados é fornecida pelo espelhamento bidirecional entre os servidores. Novas gravações no volume vão para a parte espelho com duas cópias em discos físicos separados em cada servidor. À medida que a parte espelho 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 do volume em espelho bidirecional ou em uma única estrutura de paridade. Isso é semelhante a como a paridade acelerada por espelho funciona, com a diferença sendo 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 de capacidade
A eficiência da capacidade é a proporção de espaço utilizável para volume. Ele descreve a sobrecarga de capacidade atribuível à resiliência e depende da opção de resiliência escolhida. Como um exemplo simples, armazenar 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).
Aninhado bidirecional espelho 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 aninhada do espelho bidirecional de 25% é a mais baixa de qualquer opção de resiliência em Espaços de Armazenamento Diretos.
A paridade acelerada por espelho aninhada atinge maior eficiência de capacidade, em torno de 35%-40%, que depende de dois fatores: o número de unidades 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:
Unidades 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% Veja a seguir um exemplo da matemática completa. Suponha que tenhamos 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 espelho levam 20 GB para serem armazenados em cada servidor. Espelhado para ambos os servidores, seu volume total é de 40 GB. A paridade única local do servidor, 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, seu volume total é de 216 GB. Portanto, o volume total é [(10 GB / 50,0%) + (90 GB / 83,3%)] × 2 = 256 GB, para eficiência de capacidade geral de 39,1%.
Observe que a eficiência de capacidade do espelhamento bidirecional clássico (cerca de 50%) e a paridade aninhada acelerada por espelho (até 40%) não são muito diferentes. Dependendo dos requisitos, a eficiência de capacidade ligeiramente menor pode valer a pena o aumento significativo na disponibilidade de armazenamento. Você escolhe resiliência por volume para poder misturar volumes de resiliência aninhados e volumes de espelho bidirecionais clássicos dentro do mesmo cluster.
Criar volumes de resiliência aninhados
Você pode usar cmdlets de armazenamento conhecidos 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 New-StorageTier antes de criar volumes. Você só precisa fazer isso uma vez e, em seguida, cada novo volume criado pode referenciar esses modelos.
Observação
Se você estiver executando o Windows Server 2022, o Azure Stack HCI 21H2 ou o Azure Stack HCI 20H2, ignore esta etapa.
Especifique o -MediaType das unidades de capacidade e, opcionalmente, o -FriendlyName de sua escolha. Não modifique outros parâmetros.
Por exemplo, se as unidades de capacidade forem HDD (unidades de disco rígido), 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 SSD (unidades de estado sólido), defina como -MediaType a SSD e altere -FriendlyName para *OnSSD. Não modifique outros parâmetros.
Dica
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 modelo de camada
NestedMirrore especifique o tamanho. Por exemplo:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GBSe as unidades de capacidade forem SSD (unidades de estado sólido), altere
-StorageTierFriendlyNamespara*OnSSD.Paridade acelerada por espelho aninhado
Para usar a paridade acelerada por espelho aninhada, faça referência aos modelos de camada
NestedMirroreNestedParity, em seguida, especifique dois tamanhos, um para cada parte do volume (espelho primeiro, paridade segundo). Por exemplo, para criar um volume de 500 GB aninhado de 20% espelho bidirecional e paridade aninhada de 80%, execute:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GBSe as unidades de capacidade forem SSD (unidades de estado sólido), altere
-StorageTierFriendlyNamespara*OnSSD.
Etapa 3: Continuar no Windows Admin Center
Os volumes que usam resiliência aninhada aparecem em Windows Admin Center com rotulagem clara, como na captura de tela a seguir. Depois que eles forem criados, você poderá gerenciá-los e monitorá-los usando Windows Admin Center como qualquer outro volume em Espaços de Armazenamento Diretos.
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 para 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 está inativo é não gravar em cache, mas isso afeta o desempenho.
Para resolver esse cenário, Espaços de Armazenamento Diretos 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, reabilitar o cache de gravação depois que o servidor estiver fazendo backup. Para permitir reinicializações de rotina sem impacto no desempenho, o cache de gravação não será desabilitado até que o servidor fique inativo por 30 minutos. Depois que o cache de gravação estiver desabilitado, o conteúdo do cache de gravação será 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 estar atrasadas ou falhar se um dispositivo de cache falhar.
Observação
Para um sistema físico de cache (tipo de mídia única), você não precisa considerar a desabilitação automática do cache de gravação quando um servidor em um cluster de dois servidores está inativo. Você precisa considerar isso apenas com o cache SBL (camada de barramento de armazenamento), que é necessário somente 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"
Depois de definido como True, o comportamento do cache é:
| Situação | Comportamento do cache | Pode tolerar a perda de unidade de cache? |
|---|---|---|
| Ambos os servidores ativos | Leituras e gravações de cache, desempenho completo | Sim |
| Servidor inativo, primeiros 30 minutos | Leituras e gravações de cache, desempenho completo | Não (temporariamente) |
| Após os primeiros 30 minutos | Somente leituras de cache, desempenho afetado | Sim (depois que o cache é gravado em unidades de capacidade) |
Perguntas frequentes
Encontre respostas para perguntas frequentes sobre resiliência aninhada.
Posso converter um volume existente entre o espelho bidirecional e a 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 antecipadamente qual tipo de resiliência melhor atende às suas necessidades. Se você estiver atualizando de Windows Server 2016, 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 unidades de capacidade?
Sim, basta especificar o -MediaType de cada camada adequadamente durante a 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 camada NestedMirror como -MediaType SSD e a camada NestedParity como -MediaType HDD. Nesse caso, a eficiência da capacidade de paridade depende apenas do número de unidades HDD e você precisa de pelo menos 4 delas por servidor.
Posso usar resiliência aninhada com três ou mais servidores?
Não, use apenas resiliência aninhada se o cluster tiver exatamente dois servidores.
Quantas unidades preciso usar resiliência aninhada?
O número mínimo de unidades necessárias para Espaços de Armazenamento Diretos é de quatro unidades de capacidade por nó de servidor, além de duas unidades de cache por nó de servidor (se houver). Isso não é alterado de Windows Server 2016. Não há nenhum outro requisito de resiliência aninhada e a recomendação para a capacidade de reserva também é inalterada.
A resiliência aninhada muda o funcionamento da substituição de unidade?
Não.
A resiliência aninhada muda o funcionamento da substituição do nó do servidor?
Não. Para substituir um nó de servidor e suas unidades, siga esta ordem:
- Desativar as unidades no servidor de saída
- Adicione o novo servidor, com suas unidades, ao cluster
- O pool de armazenamento reequilibrará
- Remova o servidor de saída e suas unidades
Para obter detalhes, consulte o artigo Remover servidores .
Próximas etapas
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de