Résilience imbriquée pour les espaces de stockage direct

S’applique à : Azure Stack HCI, versions 22H2 et ultérieures ; Windows Server 2022 et Windows Server 2019

La résilience imbriquée est une fonctionnalité des Espaces de stockage direct dans Azure Stack HCI et Windows Server. Il permet à un cluster à deux serveurs de résister à plusieurs défaillances matérielles en même temps sans perte de disponibilité du stockage, de sorte que les utilisateurs, les applications et les machines virtuelles continuent à s’exécuter sans interruption. Cet article explique comment fonctionne la résilience imbriquée, fournit des instructions pas à pas pour commencer et répond aux questions les plus fréquemment posées.

Avant de commencer

Envisagez la résilience imbriquée si :

• Votre cluster exécute l’un de ces systèmes d’exploitation : Azure Stack HCI, version 22H2 ou ultérieure, Windows Server 2019 ou version ultérieure ; et
• Votre cluster a exactement deux nœuds serveur.

Vous ne pouvez pas utiliser la résilience imbriquée si :

• Votre cluster exécute Windows Server 2016 ; ou
• Votre cluster n’a qu’un seul nœud de serveur ou a trois ou plusieurs nœuds de serveur.

Pourquoi la résilience imbriquée

Les volumes qui utilisent la résilience imbriquée peuvent rester en ligne et accessibles même si plusieurs défaillances matérielles se produisent en même temps, contrairement à la résilience de mise en miroir bidirectionnel classique. Par exemple, si deux lecteurs échouent en même temps ou si un serveur tombe en panne et qu’un lecteur échoue, les volumes qui utilisent la résilience imbriquée restent en ligne et accessibles. Pour l’infrastructure hyperconvergée, cela augmente la durée de fonctionnement des applications et des machines virtuelles ; pour les charges de travail du serveur de fichiers, cela signifie que les utilisateurs ont un accès ininterrompu à leurs fichiers.

Le compromis est que la résilience imbriquée a une efficacité de capacité inférieure à celle de la mise en miroir bidirectionnelle classique, ce qui signifie que vous obtenez légèrement moins d’espace utilisable. Pour plus d’informations, consultez la section Relative à l’efficacité de la capacité suivante.

Fonctionnement

Cette section fournit l’arrière-plan sur la résilience imbriquée pour les espaces de stockage direct et décrit les deux nouvelles options de résilience et leur efficacité de capacité.

Inspiration : RAID 5+1

RAID 5+1 est une forme établie de résilience de stockage distribué qui fournit un arrière-plan utile pour comprendre la résilience imbriquée. Dans RAID 5+1, au sein de chaque serveur, la résilience locale est fournie par RAID-5 ou par parité unique, pour vous protéger contre la perte d’un seul lecteur. Ensuite, une résilience supplémentaire est fournie par RAID-1, ou mise en miroir bidirectionnelle, entre les deux serveurs pour protéger contre la perte de l'un ou l'autre serveur.

Options de résilience

Les espaces de stockage direct dans Azure Stack HCI et Windows Server offrent deux options de résilience implémentées dans les logiciels, sans avoir besoin de matériel RAID spécialisé :

• Miroir sans tain imbriqué. Au sein de chaque serveur, la résilience locale est fournie par la mise en miroir bidirectionnelle, puis une autre résilience est fournie par la mise en miroir bidirectionnelle entre les deux serveurs. Il s’agit essentiellement d’un miroir à quatre sens, avec deux copies sur chaque serveur qui se trouvent sur des disques physiques différents. La mise en miroir bidirectionnelle imbriquée offre des performances sans compromis : les écritures sont effectuées sur toutes les copies et les lectures proviennent de n'importe quelle copie.

  

• Parité accélérée par miroir imbriqué. Combinez la mise en miroir bidirectionnelle imbriquée, de l'image précédente, avec la parité imbriquée. Au sein de chaque serveur, la résilience locale de la plupart des données est assurée par une arithmétique de parité binaire unique, à l'exception des nouvelles écritures récentes qui utilisent la mise en miroir bidirectionnelle. Ensuite, une résilience supplémentaire pour toutes les données est fournie par la mise en miroir bidirectionnelle entre les serveurs. Les nouvelles écritures sur le volume vont vers la partie miroir avec deux copies sur des disques physiques distincts sur chaque serveur. Comme la partie miroir du volume se remplit sur chaque serveur, les données les plus anciennes sont converties et enregistrées dans la partie parité en arrière-plan. Par conséquent, chaque serveur dispose des données du volume soit dans un miroir bidirectionnel, soit dans une structure de parité unique. Cela est similaire à la façon dont fonctionne la parité accélérée par miroir , avec la différence que la parité accélérée par miroir nécessite quatre serveurs dans le cluster et le pool de stockage, et utilise un algorithme de parité différent.

  

Efficacité de la capacité

L’efficacité de la capacité est le rapport entre l’espace utilisable et l’encombrement du volume. Il décrit la surcharge de capacité attribuable à la résilience et dépend de l’option de résilience que vous choisissez. Par exemple, le stockage de données sans résilience est efficace à 100% en termes de capacité (1 To de données occupe 1 To de capacité de stockage physique), tandis que la mise en miroir bidirectionnel est efficace à 50% (1 To de données occupe 2 To de capacité de stockage physique).

• Le miroir bidirectionnel imbriqué écrit quatre copies de tout. Cela signifie que pour stocker 1 To de données, vous avez besoin de 4 To de capacité de stockage physique. Bien que sa simplicité soit attrayante, l'efficacité de capacité du miroir bidirectionnel imbriqué de 25 % est la plus faible de toutes les options de résilience dans Storage Spaces Direct.

• La parité accélérée par miroir imbriqué atteint une efficacité de capacité supérieure, d'environ 35 à 40 %, qui dépend de deux facteurs : le nombre de disques de capacité dans chaque serveur et le mélange de miroir et de parité que vous spécifiez pour le volume. Ce tableau fournit une recherche pour les configurations courantes :

  Capacité des lecteurs par serveur	Miroir de 10 %	Miroir de 20 %	Miroir de 30 %
  4	35.7 %	34.1 %	32.6 %
  5	37.7 %	35.7 %	33.9 %
  6	39.1 %	36.8 %	34.7 %
  7 ans et plus	40.0 %	37.5 %	35.3 %

  Voici un exemple de calcul complet. Supposons que nous avons six lecteurs de capacité dans chacun des deux serveurs et que nous voulons créer un volume de 100 Go composé de 10 Go de miroir et de 90 Go de parité. Le miroir bidirectionnel local du serveur est efficace à 50,0 %, ce qui signifie que les 10 Go de données miroir nécessitent 20 Go pour être stockées sur chaque serveur. Mis en miroir sur les deux serveurs, son empreinte totale est de 40 Go. Dans ce cas, la parité unique locale du serveur est de 5/6 = 83,3% efficace, ce qui signifie que les données de parité de 90 Go prennent 108 Go pour stocker sur chaque serveur. Mis en miroir sur les deux serveurs, son empreinte totale est de 216 Go. L’empreinte totale est donc [(10 Go / 50,0%) + (90 Go / 83,3%)] × 2 = 256 Go, avec une efficacité de la capacité globale de 39,1%.

  Notez que l'efficacité de la capacité du miroir bidirectionnel classique (environ 50%) et de la parité accélérée par miroir imbriqué (jusqu'à 40%) ne diffèrent pas beaucoup. Selon vos besoins, l’efficacité de la capacité légèrement inférieure peut valoir une augmentation significative de la disponibilité du stockage. Vous choisissez la résilience par volume. Vous pouvez donc combiner des volumes de résilience imbriqués et des volumes miroir bidirectionnel classiques au sein du même cluster.

  

Créer des volumes de résilience imbriqués

Vous pouvez utiliser des applets de commande de stockage familières dans PowerShell pour créer des volumes avec une résilience imbriquée, comme décrit dans la section suivante.

Étape 1 : Créer des modèles de niveau de stockage (Windows Server 2019 uniquement)

Windows Server 2019 nécessite que vous créiez de nouveaux modèles de niveau de stockage à l’aide de l’applet de commande New-StorageTier avant de créer des volumes. Vous devez effectuer cette opération une seule fois, puis chaque nouveau volume que vous créez peut référencer ces modèles.

Remarque

Si vous exécutez Windows Server 2022, Azure Stack HCI, version 21H2 ou Azure Stack HCI, version 20H2, vous pouvez ignorer cette étape.

Spécifiez les -MediaType de vos lecteurs de capacité et, éventuellement, le -FriendlyName de votre choix. Ne modifiez pas d’autres paramètres.

Par exemple, si vos lecteurs de capacité sont des disques durs (HDD), lancez PowerShell en tant qu’administrateur et exécutez les applets de commande suivantes.

Pour créer un niveau NestedMirror :

New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4

Pour créer un niveau NestedParity :

New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk

Si vos disques de stockage sont des SSD, définissez à la place -MediaType comme SSD et modifiez -FriendlyName en *OnSSD. Ne modifiez pas d’autres paramètres.

Conseil / Astuce

Vérifiez que Get-StorageTier a créé les niveaux avec succès.

Étape 2 : Créer des volumes imbriqués

Créez de nouveaux volumes à l'aide du cmdlet New-Volume.

• Miroir sans tain imbriqué

  Pour utiliser un miroir bidirectionnel imbriqué, référencez le modèle de niveau NestedMirror et spécifiez la taille. Par exemple:

  New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GB
  

  Si vos lecteurs de capacité sont des disques SSD (Solid-State Drive), passez -StorageTierFriendlyNames à *OnSSD.

• Parité accélérée par miroir imbriqué

  Pour utiliser la parité imbriquée accélérée par miroir, référez-vous aux modèles de niveau NestedMirror et NestedParity et spécifiez deux tailles, une pour chaque partie du volume (d'abord pour la mise en miroir, ensuite pour la parité). Par exemple, pour créer un volume de 500 Go avec un miroir bidirectionnel imbriqué à 20 % et une parité imbriquée à 80 %, exécutez :

  New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GB
  

  Si vos lecteurs de capacité sont des disques SSD (Solid-State Drive), passez -StorageTierFriendlyNames à *OnSSD.

Étape 3 : Continuer dans Windows Admin Center

Les volumes qui utilisent la résilience imbriquée apparaissent dans Windows Admin Center avec l’étiquetage clair, comme dans la capture d’écran suivante. Une fois qu’ils sont créés, vous pouvez les gérer et les surveiller à l’aide de Windows Admin Center comme n’importe quel autre volume dans les espaces de stockage direct.

Facultatif : étendre aux lecteurs de cache

Avec ses paramètres par défaut, la résilience imbriquée protège contre la perte de plusieurs lecteurs de capacité en même temps, ou un serveur et un lecteur de capacité en même temps. Pour étendre cette protection aux lecteurs de cache, il existe une autre considération : étant donné que les lecteurs de cache fournissent souvent une mise en cache de lecture et d’écriture pour plusieurs lecteurs de capacité, la seule façon de vous assurer que vous pouvez tolérer la perte d’un lecteur de cache lorsque l’autre serveur est en panne est de ne pas mettre en cache les écritures, mais cela a un impact sur les performances.

Pour résoudre ce scénario, les espaces de stockage direct offrent la possibilité de désactiver automatiquement la mise en cache d’écriture lorsqu’un serveur d’un cluster à deux serveurs est arrêté, puis réactive la mise en cache d’écriture une fois le serveur sauvegardé. Pour autoriser les redémarrages de routine sans impact sur les performances, la mise en cache d’écriture n’est pas désactivée tant que le serveur n’a pas été arrêté pendant 30 minutes. Une fois la mise en cache d’écriture désactivée, le contenu du cache d’écriture est écrit sur les dispositifs de stockage. Après cela, le serveur peut tolérer un appareil de cache ayant échoué dans le serveur en ligne, bien que les lectures du cache puissent être retardées ou échouées si un appareil de cache échoue.

Remarque

Pour un système physique à cache total (type de média unique), vous n'avez pas besoin de prendre en compte la désactivation automatique du cache d'écriture lorsqu'un serveur d'un cluster de deux serveurs est hors service. Vous devez prendre en compte cela uniquement avec le cache de la couche de bus de stockage (SBL), qui est requis seulement si vous utilisez des disques durs.

(Facultatif) Pour désactiver automatiquement la mise en cache de l’écriture lorsqu’un serveur d’un cluster à deux serveurs est arrêté, lancez PowerShell en tant qu’administrateur et exécutez :

Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"

Une fois la valeur True définie, le comportement du cache est :

Situation	Comportement du cache	Peut-il tolérer une perte de lecteur de cache ?
Les deux serveurs sont opérationnels	Lectures et écritures du cache, performance maximale	Oui
Serveur arrêté, 30 premières minutes	Lectures et écritures du cache, performance maximale	Non (temporairement)
Après les 30 premières minutes	Le cache est en lecture seule, les performances sont affectées	Oui (une fois le cache écrit sur les disques de capacité)

Questions fréquentes

Trouvez des réponses aux questions fréquemment posées sur la résilience imbriquée.

Puis-je convertir un volume existant entre un miroir bidirectionnel et une résilience imbriquée ?

Non, les volumes ne peuvent pas être convertis entre les types de résilience. Pour les nouveaux déploiements sur Azure Stack HCI, Windows Server 2022 ou Windows Server 2019, décidez à l’avance quel type de résilience convient le mieux à vos besoins. Si vous effectuez une mise à niveau à partir de Windows Server 2016, vous pouvez créer de nouveaux volumes avec une résilience imbriquée, migrer vos données, puis supprimer les anciens volumes.

Puis-je utiliser la résilience imbriquée avec plusieurs types de disques de capacité ?

Oui, indiquez simplement le -MediaType pour chaque niveau en conséquence à l’étape 1 ci-dessus. Par exemple, avec NVMe, SSD et HDD dans le même cluster, NVMe fournit le cache tandis que les deux derniers fournissent une capacité : définir le niveau NestedMirror sur -MediaType SSD et le niveau NestedParity sur -MediaType HDD. Dans ce cas, l’efficacité de la capacité de parité dépend uniquement du nombre de lecteurs HDD, et vous avez besoin d’au moins 4 d’entre eux par serveur.

Puis-je utiliser la résilience imbriquée avec trois serveurs ou plus ?

Non, utilisez uniquement la résilience imbriquée si votre cluster a exactement deux serveurs.

De combien de disques ai-je besoin pour utiliser la résilience imbriquée ?

Le nombre minimal de lecteurs requis pour les espaces de stockage direct est de quatre lecteurs de capacité par nœud de serveur, plus deux lecteurs de cache par nœud de serveur (le cas échéant). Cela n’est pas modifié par rapport à Windows Server 2016. Il n’existe aucune autre exigence pour la résilience imbriquée et la recommandation de capacité de réserve n’est pas modifiée également.

La résilience imbriquée modifie-t-elle le fonctionnement du remplacement des disques ?

Non.

La résilience imbriquée change-t-elle le fonctionnement du remplacement du nœud serveur ?

Non. Pour remplacer un nœud de serveur et ses lecteurs, suivez cet ordre :

1. Retirer les lecteurs du serveur sortant
2. Ajouter le nouveau serveur, avec ses lecteurs, au cluster
3. Le pool de stockage rééquilibrera
4. Supprimer le serveur sortant et ses lecteurs

Pour plus d’informations, consultez l’article Supprimer les serveurs .

Étapes suivantes

• Vue d’ensemble des espaces de stockage direct
• Comprendre la tolérance de panne dans les espaces de stockage direct
• Planifier les volumes dans Storage Spaces Direct
• Créer des volumes dans Storage Spaces Direct