Mise à niveau propagée du système d’exploitation de cluster

La mise à niveau propagée du système d’exploitation de cluster permet à un administrateur de mettre à niveau le système d’exploitation des nœuds de cluster sans arrêter les charges de travail du serveur de fichiers avec montée en puissance parallèle ou Hyper-V. Avec cette fonctionnalité, les pénalités de temps d’arrêt sur les contrats de niveau de service peuvent être évitées.

La mise à niveau propagée du système d’exploitation de cluster offre les avantages suivants :

• Les clusters de basculement exécutant une machine virtuelle Hyper-V et des charges de travail SOFS (Scale-out File Server) peuvent être mis à niveau à partir d’une version de Windows Server, en commençant par Windows Server 2012 R2, vers une version plus récente de Windows Server. Par exemple, vous pouvez mettre à niveau Windows Server 2016 (s’exécutant sur tous les nœuds de cluster du cluster) vers Windows Server 2019 (s’exécutant sur tous les nœuds du cluster) sans temps d’arrêt.

• Aucun matériel supplémentaire n’est nécessaire. Dans les petits clusters, vous pouvez ajouter temporairement des nœuds de cluster supplémentaires pour améliorer la disponibilité du cluster pendant le processus de mise à niveau propagée du système d’exploitation de cluster.

• Le cluster n’a pas besoin d’être arrêté ou redémarré.

• Un nouveau cluster n’est pas requis. Le cluster existant est mis à niveau. En outre, les objets de cluster existants stockés dans Active Directory sont utilisés.

• Le processus de mise à niveau est réversible jusqu’à l’étape finale, lorsque tous les nœuds de cluster exécutent la version la plus récente de Windows Server et que l’applet de commande PowerShell Update-ClusterFunctionalLevel est exécutée.

• Le cluster peut prendre en charge les opérations de mise à jour corrective et de maintenance lors de l’exécution en mode de système d’exploitation mixte.

• Il prend en charge l’automatisation via PowerShell et WMI.

• La propriété publique de cluster ClusterFunctionalLevel indique l’état du cluster sur Windows Server 2016 et les nœuds de cluster ultérieurs. Cette propriété peut être interrogée à l’aide de l’applet de commande PowerShell à partir d’un nœud de cluster qui appartient à un cluster de basculement :

  Get-Cluster | Select ClusterFunctionalLevel
  

  Le tableau ci-dessous présente les valeurs et chaque niveau fonctionnel correspondant :

  Valeur	Niveau fonctionnel
  8	Windows Server 2012 R2
  9	Windows Server 2016
  10	Windows Server 2019

Ce guide décrit les différentes étapes du processus de mise à niveau propagée du système d’exploitation de cluster, les étapes d’installation, les limitations des fonctionnalités et les questions fréquentes (FAQ). Il s’applique aux scénarios de mise à niveau propagée du système d’exploitation de cluster suivants dans Windows Server :

• Clusters Hyper-V
• Clusters de serveurs de fichiers avec montée en puissance parallèle

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

• Mise à niveau propagée du système d’exploitation de cluster des clusters invités à l’aide d’un disque dur virtuel (fichier .vhdx) en tant que stockage partagé.

La mise à niveau propagée du système d’exploitation de cluster est entièrement prise en charge par System Center Virtual Machine Manager (SCVMM). Si vous utilisez SCVMM, consultez Effectuer une mise à niveau propagée d’un cluster hôte Hyper-V pour Windows Server 2016 dans VMM pour obtenir des conseils sur la mise à niveau des clusters et l’automatisation des étapes décrites dans ce document.

Configuration requise

Vérifiez que vous remplissez les conditions suivantes avant de commencer le processus de mise à niveau propagée du système d’exploitation de cluster :

• Démarrez avec un cluster de basculement exécutant Windows Server 2012 R2 ou version ultérieure. Vous pouvez effectuer une mise à niveau vers la version suivante, par exemple de Windows Server 2016 vers Windows Server 2019.
• Vérifiez que les nœuds Hyper-V utilisent des processeurs qui prennent en charge Second-Level Addressing Table (SLAT) à l’aide de l’une des méthodes suivantes : - Consultez l’article Are you SLAT Compatible? WP8 SDK Tip 01, qui décrit deux méthodes pour vérifier si un processeur prend en charge SLAT - Téléchargez l’outil Coreinfo v3.31 pour déterminer si un processeur prend en charge SLAT.

États de transition du cluster pendant la mise à niveau propagée du système d’exploitation de cluster

Cette section décrit les différents états de transition du cluster Windows Server en cours de mise à niveau vers la prochaine version de Windows Server à l’aide de la mise à niveau propagée du système d’exploitation de cluster.

Pour que les charges de travail du cluster s’exécutent pendant le processus de mise à niveau propagée du système d’exploitation de cluster, le déplacement d’une charge de travail de cluster d’un nœud exécutant une version antérieure de Windows Server vers un nœud exécutant une version plus récente de Windows Server fonctionne à l’aide d’un mode de compatibilité. Ce mode de compatibilité permet aux nœuds exécutant la version la plus récente de Windows Server d’apparaître comme s’ils exécutent la même version antérieure de Windows Server. Par exemple, lors de la mise à niveau d’un cluster Windows Server 2016 vers Windows Server 2019, les nœuds Windows Server 2019 fonctionnent en mode de compatibilité Windows Server 2016 comme mesure temporaire. Un nouveau mode de cluster conceptuel, appelé mode de système d’exploitation mixte, permet aux nœuds de différentes versions d’exister dans le même cluster (voir la figure 1).

Figure 1 : Transitions de l’état du système d’exploitation du cluster

Un cluster Windows Server passe en mode de système d’exploitation mixte lorsqu’un nœud exécutant une version plus récente de Windows Server est ajouté au cluster. Le processus est entièrement réversible à ce stade : les nœuds Windows Server plus récents peuvent être supprimés du cluster, et les nœuds exécutant la version existante de Windows Server peuvent être ajoutés au cluster dans ce mode. Le processus n’est pas réversible une fois que l’applet de commande PowerShell Update-ClusterFunctionalLevel est exécutée sur le cluster. Pour que cette applet de commande réussisse, tous les nœuds doivent exécuter la version la plus récente de Windows Server, et tous les nœuds doivent être en ligne.

États de transition d’un cluster à quatre nœuds lors de la mise à niveau propagée du système d’exploitation

Cette section illustre et décrit les quatre différentes étapes d’un cluster avec un stockage partagé dont les nœuds sont mis à niveau de Windows Server 2012 R2 vers Windows Server 2016. Le processus est le même pour les versions ultérieures de Window Server.

« Étape 1 » est l’état initial : nous commençons par un cluster Windows Server 2012 R2.

Figure 2 : État initial : cluster de basculement Windows Server 2012 R2 (étape 1)

À la « Phase 2 », deux nœuds ont été suspendus, vidés, supprimés, reformatés et installés avec Windows Server 2016.

Figure 3 : État intermédiaire : mode de système d’exploitation mixte : Windows Server 2012 R2 et cluster de basculement Windows Server 2016 (étape 2)

À l’étape 3, tous les nœuds du cluster ont été mis à niveau vers Windows Server 2016, et le cluster est prêt à être mis à niveau avec l’applet de commande PowerShell Update-ClusterFunctionalLevel.

Figure 4 : État intermédiaire : tous les nœuds mis à niveau vers Windows Server 2016, prêts pour Update-ClusterFunctionalLevel (étape 3)

Une fois l’applet de commande Update-ClusterFunctionalLevel exécutée, le cluster passe à l’étape 4, où de nouvelles fonctionnalités de cluster Windows Server 2016 peuvent être utilisées.

Figure 5 : État final : cluster de basculement Windows Server 2016 (étape 4)

Processus de mise à niveau propagée du système d'exploitation de cluster

Cette section décrit le workflow pour effectuer la mise à niveau propagée du système d’exploitation de cluster.

Figure 6 : Workflow du processus de mise à niveau propagée du système d’exploitation du cluster

La mise à niveau propagée du système d’exploitation de cluster inclut les étapes ci-dessous pour la mise à niveau de Windows Server 2012 R2 vers Windows Server 2016, mais le processus est le même pour les versions ultérieures de Window Server.

1. Préparez le cluster pour la mise à niveau du système d’exploitation comme suit :

   1. La mise à niveau propagée du système d’exploitation de cluster nécessite la suppression d’un nœud à la fois du cluster. Vérifiez si vous disposez d’une capacité suffisante sur le cluster pour gérer les contrats SLA de haute disponibilité lorsque l’un des nœuds de cluster est supprimé du cluster pour une mise à niveau du système d’exploitation. En d’autres termes, avez-vous besoin de la possibilité de basculer des charges de travail vers un autre nœud lorsqu’un nœud est supprimé du cluster pendant le processus de mise à niveau propagée du système d’exploitation de cluster ? Le cluster a-t-il la capacité d’exécuter les charges de travail requises lorsqu’un nœud est supprimé du cluster pour la mise à niveau propagée du système d’exploitation de cluster ?

   2. Pour les charges de travail Hyper-V, vérifiez que tous les hôtes Windows Server Hyper-V prennent en charge le processeur pour Second-Level Address Table (SLAT). Seules les machines compatibles SLAT peuvent utiliser le rôle Hyper-V dans Windows Server 2016 et versions ultérieures.

   3. Vérifiez que toutes les sauvegardes de charge de travail sont terminées et sauvegardez le cluster le cas échéant. Arrêtez les opérations de sauvegarde lors de l’ajout de nœuds au cluster.

   4. Vérifiez que tous les nœuds de cluster sont en ligne/en cours d’exécution/à l’aide de l’applet de commande Get-ClusterNode (voir la figure 7).

      Figure 7 : Détermination de l’état du nœud à l’aide de l’applet de commande Get-ClusterNode

   5. Si vous exécutez Cluster Aware Updates (CAU), vérifiez si la mise à jour de cluster est en cours d’exécution à l’aide de l’interface utilisateur Cluster-Aware Updating ou de l’applet de commande Get-CauRun (voir la figure 8). Arrêtez la mise à jour CAU à l’aide de l’applet de commande Disable-CauClusterRole (voir la figure 9) pour empêcher les nœuds d’être suspendus et vidés par la mise à niveau propagée du système d’exploitation de cluster.

      Figure 8 : Utilisation de l’applet de commande Get-CauRun pour déterminer Cluster Aware Updates est en cours d’exécution sur le cluster

      Figure 9 : Désactivation du rôle de Mises à jour de cluster à l’aide de l’applet de commandeDisable-CauClusterRole

2. Pour chaque nœud du cluster, effectuez les opérations suivantes :

   1. À l’aide de l’interface utilisateur du gestionnaire de cluster, sélectionnez un nœud et utilisez l’option de menu Pause | Drainer pour drainer le nœud (voir la figure 10) ou utiliser l’applet de commande Suspend-ClusterNode (voir la figure 11).

      Figure 10 : Drainage des rôles à partir d’un nœud à l’aide du Gestionnaire de cluster de basculement

      Figure 11 : Drainage des rôles à partir d’un nœud à l’aide de l’applet de commande Suspend-ClusterNode

   2. À l’aide de l’interface utilisateur du gestionnaire de cluster, supprimez le nœud suspendu du cluster ou utilisez l’applet de commande Remove-ClusterNode.

      Figure 12 : Supprimer un nœud du cluster à l’aide de l’applet de commande Remove-ClusterNode

   3. Reformatez le lecteur système et effectuez une « nouvelle installation du système d’exploitation » de Windows Server 2016 sur le nœud à l’aide de l’option Personnalisé : installer uniquement Windows (avancé) (voir la figure 13) dans setup.exe. Évitez de sélectionner l’option Mettre à niveau : installer Windows et conserver les fichiers, les paramètres et les applications, car la mise à niveau propagée du système d’exploitation de cluster n’encourage pas la mise à niveau sur place.

      Figure 13 : Options d’installation disponibles pour Windows Server 2016

   4. Ajoutez le nœud au domaine Active Directory approprié.

   5. Ajoutez les utilisateurs appropriés au groupe Administrateurs.

   6. À l’aide de l’interface utilisateur du gestionnaire de serveur ou de l’applet de commande PowerShell Install-WindowsFeature, installez tous les rôles serveur dont vous avez besoin, par exemple Hyper-V.

      Install-WindowsFeature -Name Hyper-V
      

   7. À l’aide de l’interface utilisateur du gestionnaire de serveur ou de l’applet de commande PowerShell Install-WindowsFeature, installez la fonctionnalité Clustering de basculement.

      Install-WindowsFeature -Name Failover-Clustering
      

   8. Installez toutes les fonctionnalités supplémentaires nécessaires à vos charges de travail de cluster.

   9. Vérifiez les paramètres de connectivité réseau et de stockage à l’aide de l’interface utilisateur du gestionnaire du cluster de basculement.

   10. Si le pare-feu Windows est utilisé, vérifiez que les paramètres du pare-feu sont corrects pour le cluster. Par exemple, les clusters prenant en charge Cluster Aware Updating (CAU) peuvent nécessiter la configuration du pare-feu.

   11. Pour les charges de travail Hyper-V, utilisez l’interface utilisateur du gestionnaire Hyper-V pour lancer la boîte de dialogue Gestionnaire de commutateur virtuel (voir la figure 14).

       Vérifiez que le nom des commutateurs virtuels utilisés est identique pour tous les nœuds hôtes Hyper-V du cluster.

       Figure 14 : Gestionnaire de commutateur virtuel

   12. Sur un nœud Windows Server 2016 (n’utilisez pas de nœud Windows Server 2012 R2), utilisez le gestionnaire de cluster de basculement (voir la figure 15) pour vous connecter au cluster.

       Figure 15 : Ajout d’un nœud au cluster à l’aide du Gestionnaire du cluster de basculement

   13. Utilisez l’interface utilisateur du gestionnaire du cluster de basculement ou l’applet de commande Add-ClusterNode (voir la figure 16) pour ajouter le nœud au cluster.

       Figure 16 : Ajouter un nœud au cluster à l’aide de l’applet de commande Add-ClusterNode

       Remarque

       Lorsque le premier nœud Windows Server 2016 joint le cluster, le cluster passe en mode « Système d’exploitation mixte » et les ressources principales du cluster sont déplacées vers le nœud Windows Server 2016. Un cluster en mode « Système d’exploitation mixte » est un cluster entièrement fonctionnel dans lequel les nouveaux nœuds s’exécutent en mode de compatibilité avec les anciens nœuds. Le mode « Système d’exploitation mixte » est un mode transitoire pour le cluster. Il n’est pas destiné à être permanent et les clients sont censés mettre à jour tous les nœuds de leur cluster dans les quatre semaines.

   14. Une fois le nœud Windows Server 2016 correctement ajouté au cluster, vous pouvez (éventuellement) déplacer une partie de la charge de travail de cluster vers le nœud nouvellement ajouté afin de rééquilibrer la charge de travail sur le cluster comme suit :

       Figure 17 : Déplacement d’une charge de travail de cluster (rôle de machine virtuelle de cluster) à l’aide de l’applet de commande Move-ClusterVirtualMachineRole

       1. Utilisez l’option Migration dynamique à partir du gestionnaire du cluster de basculement pour les machines virtuelles ou l’applet de commande Move-ClusterVirtualMachineRole (voir la figure 17) pour effectuer une migration dynamique des machines virtuelles.

          Move-ClusterVirtualMachineRole -Name VM1 -Node robhind-host3
          

       2. Utilisez l’option Déplacer du gestionnaire du cluster de basculement ou l’applet de commande Move-ClusterGroup pour d’autres charges de travail de cluster.

3. Lorsque chaque nœud a été mis à niveau vers Windows Server 2016 et ajouté au cluster, ou lorsque des nœuds Windows Server 2012 R2 restants ont été supprimés, procédez comme suit :

   Important

   • Après avoir mis à jour le niveau fonctionnel du cluster, vous ne pouvez pas revenir au niveau fonctionnel Windows Server 2012 R2 et les nœuds Windows Server 2012 R2 ne peuvent pas être ajoutés au cluster.
   • Tant que l’applet de commande Update-ClusterFunctionalLevel n’est pas exécutée, le processus est totalement réversible, et vous pouvez ajouter des nœuds Windows Server 2012 R2 à ce cluster et supprimer des nœuds Windows Server 2016.
   • Certaines opérations de cluster, telles que le drainage de nœud, peuvent entraîner l’isolement d’un nœud pendant une courte période. Ce comportement peut se produire lorsque l’opération Update-ClusterFunctionalLevel n’a pas été exécutée.
   • Une fois l’applet de commande Update-ClusterFunctionalLevel exécutée, de nouvelles fonctionnalités sont disponibles.

   1. À l’aide de l’interface utilisateur du gestionnaire du cluster de basculement ou de l’applet de commande Get-ClusterGroup, vérifiez que tous les rôles de cluster s’exécutent sur le cluster comme prévu. Dans l’exemple suivant, l’option Stockage disponible n’est pas utilisée ; à la place CSV est utilisé. Par conséquent, Stockage disponible affiche un état Hors connexion (voir la figure 18).

      Figure 18 : Vérification que tous les groupes de cluster (rôles de cluster) s’exécutent à l’aide de l’applet de commande Get-ClusterGroup

   2. Vérifiez que tous les nœuds de cluster sont en ligne et en cours d’exécution à l’aide de l’applet de commande Get-ClusterNode.

   3. Exécutez l’applet de commande Update-ClusterFunctionalLevel : aucune erreur ne doit être retournée (voir la figure 19).

      Figure 19 : Mise à jour du niveau fonctionnel d’un cluster à l’aide de PowerShell

   4. Une fois l’applet de commande Update-ClusterFunctionalLevel exécutée, de nouvelles fonctionnalités sont disponibles.

4. Reprendre les mises à jour et sauvegardes normales du cluster :

   1. Si vous exécutiez précédemment CAU, redémarrez CAU à l’aide de l’interface utilisateur de CAU, ou utilisez l’applet de commande Enable-CauClusterRole (voir la figure 20).

      Figure 20 : Activer l’Mises à jour du cluster à l’aide de l’applet de commandeEnable-CauClusterRole

   2. Reprendre les opérations de sauvegarde.

5. Activez et utilisez les fonctionnalités Windows Server 2016 sur les machines virtuelles Hyper-V.

   1. Une fois le cluster mis à niveau vers le niveau fonctionnel Windows Server 2016, de nombreuses charges de travail telles que les machines virtuelles Hyper-V disposeront de nouvelles fonctionnalités. Pour obtenir la liste des nouvelles fonctionnalités Hyper-V. Voir Migrer et mettre à niveau des machines virtuelles

   2. Sur chaque nœud hôte Hyper-V du cluster, utilisez l’applet de commande Get-VMHostSupportedVersion pour afficher les versions de configuration de machine virtuelle Hyper-V prises en charge par l’hôte.

      Figure 21 : Affichage des versions de configuration de machine virtuelle Hyper-V prises en charge par l’hôte

   3. Sur chaque nœud hôte Hyper-V du cluster, les versions de configuration des machines virtuelles Hyper-V peuvent être mises à niveau en planifiant une brève fenêtre de maintenance avec les utilisateurs, en sauvegardant, en désactivant les machines virtuelles, puis en exécutant l’applet de commande Update-VMVersion (voir la figure 22). Cette procédure met à jour la version de la machine virtuelle et active les nouvelles fonctionnalités Hyper-V, éliminant ainsi la nécessité de futures mises à jour du composant d’intégration Hyper-V (IC). Cette applet de commande peut être exécutée à partir du nœud Hyper-V qui héberge la machine virtuelle, ou le paramètre -ComputerName peut être utilisé pour mettre à jour la version de la machine virtuelle à distance. Dans cet exemple, nous mettons à niveau la version de configuration de VM1 de 5.0 à 7.0 pour tirer parti de nombreuses nouvelles fonctionnalités Hyper-V associées à cette version de configuration de machine virtuelle, notamment les points de contrôle de production (sauvegardes cohérentes des applications) et le fichier de configuration de machine virtuelle binaire.

      Figure 22 : Mise à niveau d’une version de machine virtuelle à l’aide de l’applet de commande PowerShell Update-VMVersion

6. Les pools de stockage peuvent être mis à niveau à l’aide de l’applet de commande PowerShell Update-StoragePool. Il s’agit d’une opération en ligne.

Même si nous ciblons des scénarios de cloud privé, en particulier des clusters Hyper-V et de serveur de fichiers avec montée en puissance parallèle, qui peuvent être mis à niveau sans temps d’arrêt, le processus de mise à niveau propagée du système d’exploitation de cluster peut être utilisé pour n’importe quel rôle de cluster.

Restrictions/limitations

• Cette fonctionnalité fonctionne uniquement pour les versions de Windows Server commençant par Windows Server 2012 R2. Cette fonctionnalité ne peut pas mettre à niveau les versions antérieures de Windows Server telles que Windows Server 2008, Windows Server 2008 R2 ou Windows Server 2012.
• Chaque nœud Windows Server 2016 doit être reformaté ou une nouvelle installation doit être effectuée. Les types d’installation sur place ou de mise à niveau sont déconseillés.
• Un nœud exécutant la version la plus récente de Windows Server doit être utilisé pour ajouter les nouveaux nœuds au cluster.
• Lors de la gestion d’un cluster en mode Système d’exploitation mixte, effectuez toujours les tâches de gestion à partir d’un nœud de niveau supérieur qui exécute Windows Server 2016. Les nœuds Windows Server de niveau inférieur ne peuvent pas utiliser l’interface utilisateur ou des outils de gestion sur des versions plus récentes de Windows Server.
• Nous encourageons les clients à passer rapidement au processus de mise à niveau du cluster, car certaines fonctionnalités de cluster ne sont pas optimisées pour le mode Système d’exploitation mixte.
• Évitez de créer ou de redimensionner le stockage sur des nœuds Windows Server plus récents pendant que le cluster s’exécute en mode Système d’exploitation mixte en raison de possibles incompatibilités sur le basculement d’un nœud Windows Server plus récent vers des nœuds Windows Server de niveau inférieur.

Forum aux questions

Combien de temps le cluster de basculement peut-il s’exécuter en mode Système d’exploitation mixte ? Nous encourageons les clients à effectuer la mise à niveau dans les quatre semaines. Nous avons mis à niveau les clusters Hyper-V et de serveur de fichiers avec montée en puissance en parallèle avec un temps d’arrêt inférieur à quatre heures.

Comptez-vous porter cette fonctionnalité sur Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008 ? Nous n’avons aucun plan de portage de cette fonctionnalité vers de précédentes versions. Nous recommandons la mise à niveau propagée du système d’exploitation de cluster pour mise à niveau des clusters Windows Server.

Les nœuds exécutant la version antérieure de Windows Server doivent-ils avoir toutes les mises à jour logicielles installées avant de démarrer le processus de mise à niveau propagée du système d’exploitation de cluster ? Oui, avant de commencer le processus de mise à niveau propagée du système d’exploitation de cluster, vérifiez que tous les nœuds de cluster sont mis à jour avec les dernières mises à jour logicielles.

Puis-je exécuter l’applet de commande Update-ClusterFunctionalLevel pendant que les nœuds sont désactivés ou suspendus ? Non. Tous les nœuds de cluster doivent être activés et en appartenance active pour que l’applet de commande Update-ClusterFunctionalLevel fonctionne.

La mise à niveau propagée du système d’exploitation de cluster fonctionne-t-elle pour n’importe quelle charge de travail de cluster ? Fonctionne-t-elle pour SQL Server ? Oui, la mise à niveau propagée du système d’exploitation de cluster fonctionne pour toute charge de travail de cluster. Toutefois, il n’y a aucun temps d’arrêt pour les clusters Hyper-V et de serveur de fichiers avec montée en puissance parallèle. La plupart des autres charges de travail entraînent un temps d’arrêt (généralement de quelques minutes) lorsqu’elles basculent, et le basculement est requis au moins une fois pendant le processus de mise à niveau propagée du système d’exploitation de cluster.

Puis-je automatiser ce processus à l’aide de PowerShell ? Oui, la mise à niveau propagée du système d’exploitation de cluster a été conçue pour pouvoir être automatisée à l’aide de PowerShell.

Pour un cluster volumineux disposant d’une capacité de basculement supplémentaire, puis-je mettre à niveau plusieurs nœuds simultanément ? Oui. Lorsqu’un nœud est supprimé du cluster pour mettre à niveau le système d’exploitation, le cluster aura un nœud inférieur pour le basculement, ce qui entraîne une capacité de basculement réduite. Pour les clusters volumineux avec suffisamment de charge de travail et de capacité de basculement, plusieurs nœuds peuvent être mis à niveau simultanément. Vous pouvez ajouter temporairement des nœuds de cluster au cluster pour améliorer la charge de travail et la capacité de basculement pendant le processus de mise à niveau propagée du système d’exploitation de cluster.

Que se passe-t-il si je rencontre un problème sur mon cluster après l’exécution réussie de Update-ClusterFunctionalLevel ? Si vous avez sauvegardé la base de données de cluster avec une sauvegarde de l’état du système avant d’exécuter Update-ClusterFunctionalLevel, vous devriez être en mesure d’effectuer une restauration faisant autorité sur un nœud exécutant la version précédente de Windows Server et de restaurer la base de données ainsi que la configuration du cluster d’origine.

Puis-je effectuer une mise à niveau sur place pour chaque nœud au lieu d’effectuer une nouvelle installation du système d’exploitation en reformatant le lecteur système ? Nous déconseillons l’utilisation de la mise à niveau sur place de Windows Server, mais nous savons que cette procédure fonctionne dans certains cas où les pilotes par défaut sont utilisés. Veuillez lire attentivement tous les messages d’avertissement affichés lors de la mise à niveau sur place d’un nœud de cluster.

Si j’utilise la réplication Hyper-V pour une machine virtuelle Hyper-V sur mon cluster Hyper-V, la réplication reste-t-elle intacte pendant et après le processus de mise à niveau propagée du système d’exploitation de cluster ? Oui, le réplica Hyper-V reste intact pendant et après le processus de mise à niveau propagée du système d’exploitation de cluster.

Puis-je utiliser System Center Virtual Machine Manager (SCVMM) pour automatiser le processus de mise à niveau propagée du système d’exploitation de cluster ? Oui, vous pouvez automatiser le processus de mise à niveau propagée du système d’exploitation de cluster à l’aide de VMM dans System Center.