Partager via


Scale-out d’un serveur unique pour votre instance Azure Stack HCI

S’applique à : Azure Stack HCI, version 22H2

Important

Azure Stack HCI fait désormais partie d’Azure Local. Le changement de nom de la documentation produit est en cours. Toutefois, les versions antérieures d’Azure Stack HCI, par exemple 22H2, continueront de référencer Azure Stack HCI et ne reflèteront pas la modification du nom. Plus d’informations

Avertissement

Les instructions de déploiement fournies dans cet article s’appliquent à une version antérieure, Azure Stack HCI, version 22H2. Pour les nouveaux déploiements, nous vous recommandons d’utiliser la dernière version en disponibilité générale, Azure Stack HCI, version 23H2. Pour obtenir des instructions de déploiement, consultez À propos du déploiement d’Azure Stack HCI, version 23H2.

Azure Stack HCI version 22H2 prend en charge le domaine d’erreur inline et les modifications de résilience pour le scale-out d’un cluster à serveur unique. Cet article explique comment effectuer un scale-out de votre cluster Azure Stack HCI.

À propos du scale-out d’un cluster à serveur unique

Azure Stack HCI version 22H2 offre des options de mise à l’échelle simples pour passer d’un cluster à serveur unique à un cluster à deux nœuds et d’un cluster à deux nœuds à un cluster à trois nœuds. Le diagramme suivant montre comment un serveur unique peut être mis à l’échelle vers un cluster à plusieurs nœuds sur votre instance Azure Stack HCI.

Diagramme montrant un cluster à serveur unique vers un scale-out de cluster à plusieurs nœuds.

Modifications apportées au domaine d’erreur inline

Lorsque vous effectuez un scale-up d’un cluster à serveur unique vers un cluster à deux nœuds, le domaine d’erreur de stockage doit d’abord être modifié de type PhysicalDisk à StorageScaleUnit. La modification doit être appliquée à tous les disques virtuels et niveaux de stockage. Des nœuds supplémentaires peuvent être créés et les données sont équilibrées uniformément entre tous les nœuds du cluster.

Effectuez les étapes suivantes pour définir correctement les domaines d’erreur après l’ajout d’un nœud :

  1. Exécutez PowerShell en tant qu’administrateur.

  2. Modifiez le type de domaine d’erreur du pool de stockage :

    Get-StoragePool -FriendlyName <s2d*> | Set-StoragePool -FaultDomainAwarenessDefault StorageScaleUnit
    
  3. Supprimez le volume d’historique des performances du cluster :

    Remove-VirtualDisk -FriendlyName ClusterPerformanceHistory
    
  4. Générez de nouveaux niveaux de stockage et recréez le volume d’historique des performances du cluster en exécutant la commande suivante :

    Enable-ClusterStorageSpacesDirect -Verbose
    
  5. Supprimez les niveaux de stockage qui ne sont plus applicables en exécutant la commande suivante. Pour plus d’informations, consultez le tableau récapitulative du niveau de stockage.

    Remove-StorageTier -FriendlyName <tier_name>
    
  6. Modifiez le type de domaine d’erreur des volumes existants :

    Pour un volume non hiérarchisé, exécutez la commande suivante :

    Set-VirtualDisk –FriendlyName <name> -FaultDomainAwareness StorageScaleUnit
    

    Pour vérifier la progression de cette modification, exécutez les commandes suivantes :

    Get-VirtualDisk -FriendlyName <volume_name> | FL FaultDomainAwareness
    Get-StorageJob
    

    Voici un exemple de sortie des commandes précédentes :

    PS C:\> Get-VirtualDisk -FriendlyName DemoVol | FL FaultDomainAwareness
    
    FaultDomainAwareness : StorageScaleUnit
    
    PS C:\> Get-StorageJob
    
    Name              IsBackgroundTask ElapsedTime JobState  PercentComplete BytesProcessed BytesTotal
    ----              ---------------- ----------- --------  --------------- -------------- ----------
    S2DPool-Rebalance True             00:00:10    Running   0                          0 B     512 MB
    

    Pour un volume hiérarchisé, exécutez la commande suivante :

    Get-StorageTier -FriendlyName <volume_name*> | Set-StorageTier -FaultDomainAwareness StorageScaleUnit
    

    Pour vérifier la prise en charge du domaine d’erreur des niveaux de stockage, exécutez la commande suivante :

    Get-StorageTier -FriendlyName <volume_name*> | FL FriendlyName, FaultDomainAwareness
    

    Remarque

    Les commandes précédentes ne fonctionnent pas pour passer d’à StorageScaleUnit , ou PhysicalDiskde vers ou Chassis de StorageScaleUnit Node types.

Modifications de résilience inline

Une fois les modifications apportées au domaine d’erreur inline, la résilience du volume peut être augmentée pour gérer le scale-out des nœuds dans les scénarios suivants.

Exécutez la commande suivante pour vérifier la progression des modifications de résilience. L’opération de réparation doit être observée pour tous les volumes du cluster.

Get-StorageJob

Cette commande affiche uniquement les travaux en cours.

Cluster à serveur unique à deux nœuds

Pour rester en miroir bidirectionnel, aucune action n’est requise. Pour convertir un miroir bidirectionnel en miroir bidirectionnel imbriqué, procédez comme suit :

Pour un volume non hiérarchisé, exécutez les commandes suivantes pour commencer par définir le disque virtuel :

Set-VirtualDisk -FriendlyName <name> -NumberOfDataCopies 4

Pour un volume hiérarchisé, exécutez la commande suivante :

Get-StorageTier -FriendlyName <volume_name*> | Set-StorageTier -NumberOfDataCopies 4

Ensuite, déplacez le volume vers un autre nœud pour remonter le volume. Un remontage est nécessaire, car ReFS reconnaît uniquement le type d’approvisionnement au moment du montage.

Move-ClusterSharedVolume -Name <name> -Node <node>

Cluster à deux nœuds à trois nœuds+

Pour rester en miroir bidirectionnel, aucune action n’est requise. Pour convertir un miroir bidirectionnel en miroir bidirectionnel ou plus grand, la procédure suivante est recommandée.

Les volumes miroir bidirectionnel existants peuvent également tirer parti de cela à l’aide des commandes PowerShell suivantes. Par exemple, pour un cluster à serveur unique ou un cluster à trois nœuds ou plus, vous convertissez votre volume miroir bidirectionnel en volume miroir bidirectionnel.

Les scénarios suivants ne sont pas pris en charge :

  • Effectuer un scale-down, comme d’un miroir tridirectionnel vers un miroir bidirectionnel.
  • Mise à l’échelle vers ou depuis des volumes de parité accélérés en miroir.
  • Mise à l’échelle à partir d’un miroir bidirectionnel imbriqué ou d’un volume de parité accéléré par miroir imbriqué.

Pour un volume non hiérarchisé, exécutez la commande suivante :

Set-VirtualDisk -FriendlyName <name> -NumberOfDataCopies 3

Pour un volume hiérarchisé, exécutez la commande suivante :

Get-StorageTier -FriendlyName <volume_name*> | Set-StorageTier -NumberOfDataCopies 3

Ensuite, déplacez le volume vers un autre nœud pour remonter le volume. Un remontage est nécessaire, car ReFS reconnaît uniquement le type d’approvisionnement au moment du montage.

Move-ClusterSharedVolume -Name <name> -Node <node>

Remarque

Les volumes créés dans Windows Admin Center sont configurés en tant que volumes hiérarchisé. Pour modifier la résilience du volume, utilisez les applets de commande StorageTier, telles que Get-StorageTier et Set-StorageTier.

Étapes suivantes

Pour plus d’informations, consultez ReFS .