Déployer un jeu de clusters

Article
10/06/2023

S’applique à : Windows Server 2019

Cet article explique comment déployer un jeu de clusters pour des clusters de basculement Windows Server en utilisant PowerShell. Un ensemble de clusters est un groupe de plusieurs clusters de basculement qui sont regroupés en cluster. À l’aide d’un ensemble de clusters, vous pouvez augmenter le nombre de nœuds de serveur dans un cloud de centre de données défini par logiciel (SDDC) par ordre de grandeur.

Les ensembles de clusters ont été testés et pris en charge avec un maximum de 64 nœuds de cluster. Toutefois, les jeux de clusters peuvent être mis à l’échelle avec des limites plus grandes personnalisables.

Avantages

Les ensembles de clusters offrent les avantages suivants :

Augmente considérablement la mise à l’échelle du cloud SDDC pour exécuter des machines virtuelles à haut niveau de disponibilité en combinant plusieurs clusters plus petits dans une vaste structure unique, tout en conservant la limite d’erreurs logicielles à un cluster unique. Vous pouvez aisément migrer des machines virtuelles dans l’ensemble de clusters.
Résilience accrue. Le fait de disposer de quatre clusters à 4 nœuds dans un ensemble de clusters vous offre une meilleure résilience qu’un cluster à 16 nœuds, dans la mesure où plusieurs nœuds de calcul peuvent tomber en panne et la production reste intacte.
Gestion du cycle de vie du cluster de basculement, y compris les clusters d’intégration et de mise hors service, sans impact sur la disponibilité des machines virtuelles du locataire.
Flexibilité des machines virtuelles sur des clusters individuels et un espace de noms de stockage unifié.
Modifiez aisément le ratio de charge de travail de calcul à stockage dans votre environnement hyper-convergé.
Tirez parti des domaines d’erreur et des groupes à haute disponibilité Azure sur des clusters individuels dans le positionnement initial des machines virtuelles et la migration suivante.
Peut être utilisé même si le matériel de calcul et de stockage entre les nœuds de cluster n’est pas identique.
Migration dynamique des machines virtuelles entre les clusters.
Groupes à haute disponibilité de type Azure et domaines d’erreur sur plusieurs clusters.
Déplacement des machines virtuelles SQL Server entre les clusters.

Conditions requises et limitations :

Certaines exigences et limitations s’appliquent à l’utilisation des ensembles de clusters :

Tous les clusters membres d’un ensemble de clusters doivent résider dans la même forêt Active Directory (AD).
Les serveurs membres de l’ensemble doivent exécuter la même version du système d’exploitation. Les machines virtuelles ne peuvent pas être migrées dynamiquement entre différents systèmes d’exploitation. Vous pouvez avoir un ensemble de clusters qui se compose de l’une des options suivantes, mais pas de plusieurs :
- Windows Server 2019 avec clusters de basculement et Windows Server 2019 avec clusters de basculement
- Windows Server 2019 avec clusters de basculement et Windows Server 2019 avec espaces de stockage direct
- Windows Server 2019 avec espaces de stockage direct et Windows Server 2019 avec espaces de stockage direct
Tous les serveurs membres doivent disposer d’un matériel de processeur identique pour pouvoir effectuer une migration dynamique entre les clusters membres ; sinon, vous devez sélectionner Compatibilité du processeur dans les paramètres des machines virtuelles.
Les machines virtuelles du jeu de clusters doivent être migrées manuellement en direct sur les clusters ; elles ne peuvent pas basculer automatiquement.
Le réplica de stockage doit être utilisé entre les clusters membres pour assurer la résilience du stockage aux défaillances du cluster. Lorsque vous utilisez Storage Replica (réplique de stockage), gardez à l’esprit que les chemins d’accès UNC de stockage d’espace de noms ne changent pas automatiquement sur le basculement Storage Replica vers le cluster cible de réplication.
Les espaces de stockage direct ne fonctionnent pas sur les clusters membres d’un jeu de clusters. Au lieu de cela, Espaces de stockage direct s’applique à un seul cluster, chaque cluster ayant son propre pool de stockage.

Architecture

Le schéma suivant représente un ensemble de clusters à un niveau élevé :

Vous trouverez ci-dessous un résumé de chacun des éléments affichés :

Cluster de gestion

Le cluster de gestion héberge le plan de gestion hautement disponible et le Serveur de fichiers avec montée en puissance parallèle (SOFS) de référence de l’espace de noms pour le jeu de clusters. Un cluster de gestion est logiquement découplé des clusters membres individuels qui exécutent des charges de travail de machine virtuelle. Le plan de gestion de l’ensemble de clusters est ainsi résilient aux défaillances localisées à l’ensemble du cluster, telles que la perte de puissance d’un cluster membre.

Serveur de fichiers avec montée en puissance parallèle (SOFS) de référence de l’espace de noms de l’ensemble de clusters

Un espace de noms pour l’ensemble de clusters est fourni avec un rôle serveur SOFS en cours d’exécution sur le cluster de gestion. Cela est similaire à un espace de noms de système de fichiers distribué (DFSN). Contrairement à un DFSN, toutefois, les métadonnées de référence de l’espace de noms du jeu de clusters sont automatiquement remplies sur tous les nœuds de cluster sans aucune intervention. Il n’y a donc presque aucune surcharge de performance dans le chemin d’accès de stockage. Ce mécanisme de référence léger ne fait pas partie du chemin d’accès entrée/sortie.

Chaque partage de référence SMB (Server Message Block) sur le serveur SOFS de l’espace de noms de l’ensemble de clusters est de type SimpleReferral. Cette référence permet aux clients SMB d’accéder au partage SMB cible hébergé sur le serveur SOFS du cluster membre. Les références sont mises en cache de façon perpétuelle sur chacun des nœuds du client, et l’espace de noms de l’ensemble de clusters met dynamiquement à jour les références en fonction des besoins. Les informations de référence sont mises en cache de manière permanente dans chaque nœud de l’ensemble de clusters, même lors des redémarrages.

Maître d’ensemble de clusters

La communication entre les clusters membres est faiblement couplée et coordonnée par la ressource Cluster Set Master (CS-Master). À l’instar des autres ressources de l’ensemble de clusters, CS-Master est hautement disponible et résiste aux défaillances de cluster individuelles ou aux défaillances de nœud de cluster de gestion. À l’aide d’un fournisseur WMI d’ensemble de clusters, CS-Master fournit le point de terminaison de gestion pour toutes les actions de gestion d’ensemble de clusters.

Cluster membre

Un cluster membre exécute des charges de travail de machine virtuelle et d’espaces de stockage direct. Plusieurs clusters membres participent à un déploiement d’ensemble de clusters, formant ainsi la plus grande structure de cloud SDDC. Les clusters membres diffèrent du cluster de gestion sur deux points essentiels : les clusters membres participent aux constructions de groupe de disponibilité et de domaine d’erreur, et les clusters membres sont dimensionnés pour héberger des charges de travail de machine virtuelle et de espaces de stockage direct. Pour cette raison, les machines virtuelles qui se déplacent entre les clusters membres ne sont pas hébergées sur le cluster de gestion.

Worker d’ensemble de clusters

Le CS-Master interagit avec une ressource de cluster sur les clusters membres appelée Cluster Set Worker (CS-Worker). CS-Worker répond aux requêtes du SC-Master, concernant notamment le placement de la machine virtuelle et l’inventaire des ressources. Il existe une instance CS-Worker par cluster membre.

Domaine d'erreur

Un domaine d’erreur est un groupe de matériels et de logiciels qui peuvent échouer ensemble. Bien que vous puissiez désigner un ou plusieurs clusters ensemble comme domaine d’erreur, chaque nœud peut participer à un domaine d’erreur dans un groupe à haute disponibilité. Les limites de domaine d’erreur sont basées sur la topologie du centre de données, l’architecture de mise en réseau et d’autres considérations.

Groupe à haute disponibilité

Un groupe à haute disponibilité permet de configurer la redondance souhaitée des charges de travail en cluster entre les domaines d’erreur en regroupant et en déployant des charges de travail. Pour une application à deux niveaux, vous devez configurer au moins deux machines virtuelles dans un groupe à haute disponibilité pour chaque niveau, ce qui garantit qu’en cas de défaillance d’un domaine d’erreur dans un groupe à haute disponibilité, votre application aura au moins une machine virtuelle dans chaque niveau hébergé sur un domaine d’erreur différent.

Créer un ensemble de clusters

Utilisez PowerShell dans l’exemple de flux de travail suivant pour créer un ensemble de clusters à l’aide de deux clusters. Le nom de l’ensemble de clusters est CSMASTER.

Nom du cluster	Nom SOFS de l’infrastructure
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Utilisez un ordinateur client de gestion exécutant Windows Server 2022 ou Windows Server 2019.
Installez les outils de cluster de basculement sur le serveur du cluster de gestion.
Créez deux membres de cluster, avec au moins deux volumes partagés de cluster (CSV) dans chaque cluster.
Créez un cluster de gestion (physique ou invité) à cheval sur les clusters membres. Cela permet de s’assurer que le plan de gestion de l’ensemble de clusters continue d’être disponible malgré les défaillances possibles du cluster.
Pour créer l’ensemble de clusters :
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Notes

Si vous utilisez une adresse IP statique, vous devez inclure -StaticAddress x.x.x. x sur la commande New-ClusterSet.

Pour ajouter des membres de cluster à l’ensemble de clusters :

Add-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER1
Add-ClusterSetMember -ClusterName CLUSTER2 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER2

Pour énumérer tous les clusters membres de l’ensemble de clusters :
```
Get-ClusterSetMember -CimSession CSMASTER
```
Pour énumérer tous les clusters membres de l’ensemble de clusters, y compris les nœuds de cluster de gestion :
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
Pour répertorier tous les nœuds de serveur de tous les clusters membres :
```
Get-ClusterSetNode -CimSession CSMASTER
```
Pour répertorier tous les groupes de ressources dans l’ensemble de clusters :
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup
```
Pour vérifier que l’ensemble de clusters contient un partage SMB (ScopeName étant le nom du serveur Infrastructure File Server) sur le SOFS d’infrastructure pour chaque volume CSV du membre du cluster :
```
Get-SmbShare -CimSession CSMASTER
```
Examinez les fichiers journaux de débogage de l’ensemble de clusters pour l’ensemble de clusters, le cluster de gestion et chaque membre du cluster :
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
Configurez Kerberos avec délégation contrainte entre tous les membres du groupe de clusters.
Configurez le type d’authentification de migration dynamique de machine virtuelle entre clusters sur Kerberos sur chaque nœud de l’ensemble de clusters :
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```
Ajoutez le cluster de gestion au groupe Administrateurs local sur chaque nœud de serveur membre du cluster dans l’ensemble de clusters :
```
foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }
```

Créer des machines virtuelles d’ensemble de cluster

Après avoir créé l’ensemble de clusters, l’étape suivante consiste à créer des machines virtuelles. Vous devez effectuer préalablement les contrôles suivants :

Vérifier la mémoire disponible sur chaque nœud du serveur de cluster
Vérifier l’espace disque disponible sur chaque nœud du serveur de cluster
Vérifier la vitesse et les performances de toutes les exigences spécifiques en matière de stockage de machines virtuelles

La commande Get-ClusterSetOptimalNodeForVM identifie le cluster et le nœud optimaux dans l’ensemble de clusters, puis déploie la machine virtuelle dessus. Dans l’exemple suivant, une machine virtuelle est créée avec les ressources suivantes :

4 Go disponibles
Un processeur virtuel
Processeur avec 10 % minimum disponible

# Identify the optimal node to create a new virtual machine
$memoryinMB=4096
$vpcount = 1
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

# Deploy the virtual machine on the optimal node
Invoke-Command -ComputerName $targetnode.name -scriptblock { param([String]$storagepath); New-VM CSVM1 -MemoryStartupBytes 3072MB -path $storagepath -NewVHDPath CSVM.vhdx -NewVHDSizeBytes 4194304 } -ArgumentList @("\\SOFS-CLUSTER1\VOLUME1") -Credential $cred | Out-Null

Start-VM CSVM1 -ComputerName $targetnode.name | Out-Null
Get-VM CSVM1 -ComputerName $targetnode.name | fl State, ComputerName

Une fois le processus terminé, vous voyez le nœud de cluster sur lequel la machine virtuelle a été déployée. Pour l’exemple ci-dessus, il s’affiche comme suit :

State         : Running
ComputerName  : 1-S2D2

S’il n’y a pas assez de mémoire, de capacité processeur ou d’espace disque disponible pour ajouter la machine virtuelle, l’erreur suivante s’affiche :

Get-ClusterSetOptimalNodeForVM : A cluster node isn't available for this operation.

Une fois la machine virtuelle créée, elle s’affiche dans le gestionnaire Hyper-V sur le nœud spécifique indiqué. Pour l’ajouter en tant que machine virtuelle de groupe de clusters et l’ajouter au cluster, utilisez la commande suivante :

Register-ClusterSetVM -CimSession CSMASTER -MemberName $targetnode.Member -VMName CSVM1

Une fois terminée, la sortie s’affiche :

Id  VMName  State  MemberName  PSComputerName
--  ------  -----  ----------  --------------
 1  CSVM1     On   CLUSTER1    CSMASTER

Si vous avez créé un cluster à l’aide de machines virtuelles existantes, celles-ci doivent être inscrites auprès du jeu de clusters. Pour inscrire toutes les machines virtuelles en même temps, utilisez :

Get-ClusterSetMember -Name CLUSTER3 -CimSession CSMASTER | Register-ClusterSetVM -RegisterAll -CimSession CSMASTER

Ajoutez ensuite le chemin d’accès de la machine virtuelle à l’espace de noms de l’ensemble de clusters.

Par exemple, supposons qu’un cluster existant soit ajouté à l’ensemble de clusters avec des machines virtuelles préconfigurées qui résident sur le volume partagé de cluster local (CSV). Le chemin d’accès du VHDX ressemblerait à ceci : C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1.

Une migration de stockage est nécessaire, car les chemins d’accès CSV sont en mode de conception locale sur un cluster à membre unique et ne sont donc pas accessibles par la machine virtuelle une fois qu’ils sont migrés en direct entre les clusters membres.

Dans cet exemple, CLUSTER3 est ajouté à l’ensemble de clusters à l’aide de Add-ClusterSetMember avec le serveur de fichiers avec montée en puissance parallèle SOFS-CLUSTER3. Pour déplacer la configuration et le stockage de la machine virtuelle, la commande est la suivante :

Move-VMStorage -DestinationStoragePath \\SOFS-CLUSTER3\Volume1 -Name MyVM

Une fois l’opération terminée, vous pouvez recevoir un message d’avertissement :

WARNING: There were issues updating the virtual machine configuration that may prevent the virtual machine from running. For more information view the report file below.
WARNING: Report file location: C:\Windows\Cluster\Reports\Update-ClusterVirtualMachineConfiguration '' on date at time.htm.

Cet avertissement peut être ignoré, car il n’y avait pas de modifications physiques dans la configuration du stockage du rôle de machine virtuelle. L’emplacement physique réel ne change pas, à la différence des chemins d’accès uniquement.

Pour plus d’informations sur Move-VMStorage, voir Move-VMStorage.

La migration dynamique d’une machine virtuelle au sein d’un ensemble de clusters implique les opérations suivantes :

Set-VMHost -UseAnyNetworkForMigration $true

Ensuite, pour déplacer une machine virtuelle de l’ensemble de clusters CLUSTER1 vers NODE2-CL3 sur CLUSTER3, par exemple, la commande serait la suivante :

Move-ClusterSetVM -CimSession CSMASTER -VMName CSVM1 -Node NODE2-CL3

Cette commande ne déplace pas les fichiers de stockage ou de configuration de machine virtuelle et n’est pas nécessaire, car le chemin de la machine virtuelle reste \\SOFS-CLUSTER1\VOLUME1. Une fois qu’une machine virtuelle a été inscrite auprès du chemin d’accès du partage de serveur de fichiers de l’infrastructure, les lecteurs et les machines virtuelles ne doivent pas nécessairement résider sur le même nœud que la machine virtuelle.

Créez le serveur de fichiers scale-out d’infrastructure

Il existe un rôle de cluster SOFS d’infrastructure sur un cluster. Le rôle SOFS d’infrastructure est créé en spécifiant le paramètre de commutateur -Infrastructure à l’applet de commande Add-ClusterScaleOutFileServerRole. Par exemple :

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Chaque volume CSV créé déclenche automatiquement la création d’un partage SMB avec un nom généré automatiquement en fonction du nom du volume CSV. Vous ne pouvez pas créer ou modifier directement des partages SMB sous un rôle SOFS, à l’exception des opérations de création et de modification de volume CSV.

Dans les configurations hyperconvergées, une infrastructure SOFS permet à un client SMB (hôte Hyper-V) de communiquer avec le serveur SMB SOFS d’infrastructure SOFS en bénéficiant de la disponibilité continue (CA). Cette disponibilité continue de bouclage SMB hyper-convergée est obtenue par des machines virtuelles qui accèdent à leurs fichiers de disque virtuel (VHDX) où l’identité de la machine virtuelle propriétaire est transférée entre le client et le serveur. Ce transfert d’identité permet d’utiliser des listes de contrôle d’accès (ACL) pour les fichiers VHDX comme dans les configurations de clusters hyperconvergées standards classiques.

Une fois qu’un ensemble de clusters est créé, l’espace de noms de l’ensemble de clusters s’appuie sur un SOFS d’infrastructure sur chacun des clusters membres, ainsi que sur un SOFS d’infrastructure dans le cluster de gestion.

Au moment où un cluster membre est ajouté à un ensemble de clusters, vous pouvez spécifier le nom d’un SOFS d’infrastructure sur ce cluster s’il en existe déjà un. Si le SOFS d’infrastructure n’existe pas, un nouveau rôle SOFS d’infrastructure est créé sur le nouveau cluster membre. Si un rôle de SOFS d’infrastructure existe déjà sur le cluster membre, l’opération d’ajout le renomme implicitement en fonction du nom spécifié, si nécessaire. Les serveurs SMB existants ou les rôles SOFS autres que les rôles SOFS d’infrastructure sur les clusters membres ne sont pas utilisés par le jeu de clusters.

Lorsque l’ensemble de clusters est créé, vous avez la possibilité d’utiliser un objet d’ordinateur AD existant comme racine de l’espace de noms sur le cluster de gestion. La création de l’ensemble de clusters crée le rôle de cluster SOFS d’infrastructure sur le cluster de gestion ou renomme le rôle SOFS d’infrastructure existant. Le SOFS d’infrastructure sur le cluster de gestion est utilisée en tant que SOFS de référence de l’espace de noms de l’ensemble de clusters.

Créer des domaines d'erreur et des groupes à haute disponibilité

Les domaines d’erreur de type Azure et les groupes à haute disponibilité peuvent être configurés dans un ensemble de clusters. Cela est appréciable pour les remplacements de machines virtuelles initiaux et les migrations entre les clusters.

L’exemple ci-dessous possède quatre clusters dans un ensemble de clusters. Dans l’ensemble, un domaine d’erreur est créé avec deux des clusters, et un deuxième domaine d’erreur est créé avec les deux autres clusters. Ces deux domaines d’erreur comprennent le groupe à haute disponibilité.

Dans l’exemple ci-dessous, CLUSTER1 et CLUSTER2 se trouvent dans le domaine d’erreur FD1, tandis que CLUSTER3 et CLUSTER4 se trouvent dans le domaine d’erreur FD2. Le groupe à haute disponibilité est CSMASTER-AS.

Pour créer les domaines d’erreur, les commandes sont les suivantes :

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER1,CLUSTER2 -Description "First fault domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER3,CLUSTER4 -Description "Second fault domain"

Pour vous assurer qu’elles ont été créées avec succès, Get-ClusterSetFaultDomain peut être exécuté avec sa sortie affichée pour FD1 :

PS C:\> Get-ClusterSetFaultDomain -CimSession CSMASTER -FdName FD1 | fl *

PSShowComputerName    : True
FaultDomainType       : Logical
ClusterName           : {CLUSTER1, CLUSTER2}
Description           : First fault domain
FDName                : FD1
Id                    : 1
PSComputerName        : CSMASTER

Maintenant que les domaines d’erreur ont été créés, le groupe à haute disponibilité l’est également :

New-ClusterSetAvailabilitySet -Name CSMASTER-AS -FdType Logical -CimSession CSMASTER -ParticipantName FD1,FD2

Pour valider qu’il a bien été créé, utilisez :

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

Lorsque vous créez des machines virtuelles, utilisez le paramètre -AvailabilitySet pour déterminer le nœud optimal dans le cadre de la sélection élective. Voici un exemple :

# Identify the optimal node to create a new VM
$memoryinMB=4096
$vpcount = 1
$av = Get-ClusterSetAvailabilitySet -Name CSMASTER-AS -CimSession CSMASTER
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10 -AvailabilitySet $av
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

Supprimer un cluster d’un ensemble

Il peut arriver qu’un cluster doive être supprimé d’un ensemble de clusters. En guise de meilleure pratique, toutes les machines virtuelles de l’ensemble de cluster doivent être déplacées hors du cluster préalablement. Cela peut être fait à l’aide des commandes Move-ClusterSetVM et Move-VMStorage.

Si les machines virtuelles ne sont pas déplacées hors du cluster, toutes les machines virtuelles d’ensemble de cluster restantes hébergées sur le cluster en cours de suppression deviennent des machines virtuelles à haut niveau de disponibilité qui sont liées à ce cluster, en supposant qu’elles aient accès à leur espace de stockage. Les ensembles de clusters mettent également à jour automatiquement leur inventaire en n’effectuant plus le suivi de l’intégrité d’un cluster supprimé et des machines virtuelles en cours d’exécution, et en supprimant l’espace de noms et toutes les références aux partages hébergés sur le cluster supprimé.

Par exemple, la commande permettant de supprimer le cluster CLUSTER1 d’un ensemble de clusters est la suivante :

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Sauvegarde de l'état du système

La sauvegarde de l’état du système sauvegarde l’état et les métadonnées du cluster. À l’aide de Sauvegarde Windows Server, vous pouvez restaurer uniquement la base de données de cluster d’un nœud, si nécessaire, ou effectuer une restauration faisant autorité pour restaurer l’intégralité de la base de données de cluster sur tous les nœuds. Pour les ensembles de clusters, nous vous recommandons d’abord d’utiliser une restauration faisant autorité pour les clusters membres, puis pour le cluster de gestion. Pour plus d’informations sur la sauvegarde de l’état du système, consultez Sauvegarder l’état du système et le matériel nu.

Étapes suivantes

En savoir plus sur le réplica de stockage.