S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Azure Local, versions 23H2 et 22H2
Cluster-Aware Mise à jour de (CAU) est une fonctionnalité qui coordonne les mises à jour logicielles sur tous les serveurs d’un cluster de basculement d’une manière qui n’affecte pas la disponibilité du service plus qu’un basculement planifié d’un nœud de cluster. Pour certaines applications avec des fonctionnalités de disponibilité continue (telles que Hyper-V avec la migration dynamique ou un serveur de fichiers SMB 3.x avec basculement transparent SMB), la mise à jour automatisée du cluster peut être coordonnée sans impact sur la disponibilité du service.
La mise à jour des espaces de stockage direct prend-elle en charge la mise à jour des clusters CAU ?
Oui. La mise à jour des clusters espaces de stockage direct, quel que soit le type de déploiement : hyperconvergé ou convergé. Plus précisément, l’orchestration des clusters garantit que l’interruption de chaque nœud de cluster attend que l’espace de stockage en cluster sous-jacent soit sain.
La mise à jour des clusters fonctionne-t-elle avec Windows Server 2008 R2 ou Windows 7 ?
Non. La mise à jour du cluster coordonne l’opération de mise à jour du cluster uniquement à partir d’ordinateurs exécutant Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1 ou Windows 8. Le cluster de basculement mis à jour doit exécuter Windows Server 2016, Windows Server 2012 R2 ou Windows Server 2012.
La mise à jour de la mise à jour cloud est-elle limitée à des applications en cluster spécifiques ?
Non. La mise à jour cloud est indépendante du type de l’application en cluster. La mise à jour de cluster externe est une solution de mise à jour de cluster externe superposée aux API de clustering et aux applets de commande PowerShell. Par conséquent, la mise à jour de la mise à jour de la mise à jour pour n’importe quelle application en cluster configurée dans un cluster de basculement Windows Server.
Note
Actuellement, les charges de travail en cluster suivantes sont testées et certifiées pour la mise à jour CAU : SMB, Hyper-V, réplication DFS, espaces de noms DFS, iSCSI et NFS.
La mise à jour des clusters prend-elle en charge les mises à jour de Microsoft Update et de Windows Update ?
Oui. Par défaut, la mise à jour CAU est configurée avec un plug-in qui utilise les API utilitaires de l’agent Windows Update (WUA) sur les nœuds du cluster. L’infrastructure WUA peut être configurée pour pointer vers Microsoft Update et Windows Update ou vers Windows Server Update Services (WSUS) comme source de mises à jour.
La mise à jour des clusters prend-elle en charge les mises à jour WSUS ?
Oui. Par défaut, la mise à jour CAU est configurée avec un plug-in qui utilise les API utilitaires de l’agent Windows Update (WUA) sur les nœuds du cluster. L’infrastructure WUA peut être configurée pour pointer vers Microsoft Update et Windows Update ou vers un serveur Windows Server Update Services (WSUS) local comme source de mises à jour.
La mise à jour de la mise en production de la mise en production de la mise à jour de la distribution limitée peut-elle être appliquée à
Oui. Les mises à jour de version de distribution limitée (LDR), également appelées correctifs logiciels, ne sont pas publiées via Microsoft Update ou Windows Update. Elles ne peuvent donc pas être téléchargées par le plug-in WuA (Windows Update Agent) que la mise à jour CAU utilise par défaut.
Toutefois, la mise à jour de la mise à jour des correctifs logiciels inclut un deuxième plug-in que vous pouvez sélectionner pour appliquer des mises à jour de correctif logiciel. Ce plug-in de correctif logiciel peut également être personnalisé pour appliquer des mises à jour non-Microsoft, microprogramme et BIOS.
Puis-je utiliser la mise à jour cumulative pour appliquer des mises à jour cumulatives ?
Oui. Si les mises à jour cumulatives sont des mises à jour de version de distribution générale ou des mises à jour LDR, la mise à jour de la mise à jour CAU peut les appliquer.
Puis-je planifier des mises à jour ?
Oui. La mise à jour adaptée aux clusters prend en charge les modes de mise à jour suivants, qui autorisent la planification des mises à jour :
mise à jour automatique permet au cluster de se mettre à jour en fonction d’un profil défini et d’une planification régulière, par exemple pendant une fenêtre de maintenance mensuelle. Vous pouvez également démarrer une Self-Updating Exécuter à la demande à tout moment. Pour activer le mode de mise à jour automatique, vous devez ajouter le rôle cluster de la mise à jour CAU au cluster. La fonctionnalité de mise à jour automatique de la mise à jour des clusters s’effectue comme toute autre charge de travail en cluster et peut fonctionner en toute transparence avec les basculements planifiés et non planifiés d’un ordinateur coordinateur de mise à jour.
mise à jour à distance vous permet de démarrer une exécution de mise à jour à tout moment à partir d’un ordinateur exécutant Windows ou Windows Server. Vous pouvez démarrer une exécution de mise à jour via la fenêtre mise à jour Cluster-Aware ou à l’aide de l’applet de commande Invoke-CauRun PowerShell. La mise à jour à distance est le mode de mise à jour par défaut pour la mise à jour cloud. Vous pouvez utiliser le planificateur de tâches pour exécuter l’applet de commande Invoke-CauRun à partir d’un ordinateur distant qui n’est pas l’un des nœuds de cluster.
Puis-je planifier des mises à jour à appliquer pendant une sauvegarde ?
Oui. La mise à jour des clusters n’impose aucune contrainte à cet égard. Toutefois, l’exécution de mises à jour logicielles sur un serveur (avec les redémarrages potentiels associés) alors qu’une sauvegarde de serveur est en cours n’est pas une bonne pratique informatique. N’oubliez pas que les clusters s’appuient uniquement sur les API de clustering pour déterminer les basculements de ressources et les restaurations automatiques ; Ainsi, la mise à jour de la mise à jour cloud ignore l’état de la sauvegarde du serveur.
La mise à jour de la mise à jour cloud peut-elle fonctionner avec Configuration Manager ?
La mise à jour CAU est un outil qui coordonne les mises à jour logicielles sur un nœud de cluster, et Configuration Manager effectue également des mises à jour logicielles serveur. Il est important de configurer ces outils afin qu’ils n’aient pas de couverture qui se chevauche sur les mêmes serveurs dans un déploiement de centre de données, notamment à l’aide de différents serveurs Windows Server Update Services. Cela garantit que l’objectif derrière l’utilisation de la mise à jour de la mise à jour basée sur Configuration Manager n’intègre pas la prise en charge du cluster.
Ai-je besoin d’informations d’identification d’administration pour exécuter la mise à jour de la mise à jour cloud ?
Oui. Pour exécuter les outils de la mise à jour de la mise à jour, la mise à jour des clusters a besoin d’informations d’identification administratives sur le serveur local, ou elle a besoin de l'emprunter l’identité d’un client après l’authentification'utilisateur directement sur le serveur local ou l’ordinateur client sur lequel il s’exécute. Toutefois, pour coordonner les mises à jour logicielles sur les nœuds du cluster, la mise à jour des clusters nécessite des informations d’identification d’administration de cluster sur chaque nœud. Bien que l’interface utilisateur de la mise à jour de la mise à jour puisse être effectuée sans les informations d’identification de la mise à jour du cluster, l’interface utilisateur de la mise à jour du cluster peut démarrer sans les informations d’identification.
Puis-je scripter la mise à jour des clusters ?
Oui. La mise à jour cloud est fournie avec les applets de commande PowerShell qui offrent un ensemble complet d’options de script. Il s’agit des mêmes applets de commande que celles que l’interface utilisateur de la mise à jour de la mise à jour cloud appelle pour effectuer des actions de mise à jour de la mise à jour.
Que se passe-t-il pour les rôles en cluster actifs ?
Les rôles en cluster (anciennement appelés applications et services) actifs sur un nœud, basculent vers d’autres nœuds avant que la mise à jour logicielle puisse commencer. La mise à jour cloud orchestre ces basculements à l’aide du mode de maintenance, qui interrompt et draine le nœud de tous les rôles en cluster actifs. Une fois les mises à jour logicielles terminées, la mise à jour du cluster reprend le nœud et les rôles en cluster basculent vers le nœud mis à jour. Cela garantit que la distribution des rôles en cluster par rapport aux nœuds reste la même dans les exécutions de mise à jour de la mise à jour de cluster.
Comment la mise à jour CAU sélectionne-t-elle les nœuds cibles pour les rôles en cluster ?
La mise à jour des clusters s’appuie sur les API de clustering pour coordonner les basculements. L’implémentation de l’API de clustering sélectionne les nœuds cibles en s’appuyant sur des métriques internes et des heuristiques de placement intelligentes (comme les niveaux de charge de travail) sur les nœuds cibles.
La charge de la mise à jour des clusters équilibre-t-elle la charge des clusters ?
La mise à jour cloud n’équilibre pas la charge des nœuds en cluster, mais tente de conserver la distribution des rôles en cluster. Lorsque la mise à jour de la mise à jour d’un nœud de cluster est terminée, elle tente de restaurer automatiquement les rôles en cluster précédemment hébergés sur ce nœud. La mise à jour des clusters s’appuie sur les API de clustering pour restaurer les ressources au début du processus de pause. Ainsi, en l’absence de basculements non planifiés et de paramètres de propriétaire préférés, la distribution des rôles en cluster doit rester inchangée.
Comment la mise à jour des clusters permet-elle de sélectionner l’ordre des nœuds ?
Par défaut, la mise à jour des clusters sélectionne l’ordre des nœuds à mettre à jour en fonction du niveau d’activité. Les nœuds qui hébergent les rôles en cluster les plus rares sont mis à jour en premier. Toutefois, un administrateur peut spécifier un ordre particulier de mise à jour des nœuds en spécifiant un paramètre pour l’exécution de mise à jour dans l’interface utilisateur de la mise à jour ou à l’aide des applets de commande PowerShell.
Que se passe-t-il si un nœud de cluster est hors connexion ?
L’administrateur qui lance une exécution de mise à jour peut spécifier le seuil acceptable pour le nombre de nœuds pouvant être hors connexion. Par conséquent, une exécution de mise à jour peut se poursuivre sur un cluster même si tous les nœuds de cluster ne sont pas en ligne.
Puis-je utiliser la mise à jour de la mise à jour d’un seul nœud ?
Non. La mise à jour de la mise à jour de cluster est un outil de mise à jour délimitée par un cluster. Il vous permet donc uniquement de sélectionner des clusters à mettre à jour. Si vous souhaitez mettre à jour un nœud unique, vous pouvez utiliser des outils de mise à jour de serveur existants indépendamment de la mise à jour de la mise à jour de la mise à jour des clusters.
La mise à jour du rapport de la mise à jour de la mise à jour des clusters peut-elle être lancée à partir de l’extérieur de la mise à jour de la mise à jour de la
Non. La mise à jour des clusters ne peut signaler que les exécutions de mise à jour lancées à partir de la mise à jour de la mise à jour à partir de la mise à jour de la mise à jour. Toutefois, lorsqu’une exécution ultérieure de mise à jour de la mise à jour est lancée, les mises à jour qui ont été installées via des méthodes non-CAU sont considérées de manière appropriée pour déterminer les mises à jour supplémentaires qui peuvent être applicables à chaque nœud de cluster.
La mise à jour des clusters peut-elle prendre en charge mes besoins uniques en matière de processus informatique ?
Oui. La mise à jour cloud offre les dimensions suivantes de la flexibilité pour répondre aux besoins uniques des clients d’entreprise en matière de processus informatique :
Scripts Une exécution de mise à jour peut spécifier un script PowerShell avant la mise à jour et un script PowerShell après la mise à jour. Le script de pré-mise à jour s’exécute sur chaque nœud de cluster avant que le nœud ne soit suspendu. Le script post-mise à jour s’exécute sur chaque nœud de cluster après l’installation des mises à jour du nœud.
Note
.NET Framework 4.6 ou 4.5 et PowerShell doivent être installés sur chaque nœud de cluster sur lequel vous souhaitez exécuter les scripts de pré-mise à jour et de post-mise à jour. Vous devez également activer la communication à distance PowerShell sur les nœuds du cluster. Pour plus d’informations sur la configuration requise, consultez Configuration requise et meilleures pratiques pour Cluster-Aware mise à jour.
options d’exécution de mise à jour avancées L’administrateur peut également spécifier à partir d’un grand ensemble d’options d’exécution de mise à jour avancées, telles que le nombre maximal de fois où le processus de mise à jour est retenté sur chaque nœud. Ces options peuvent être spécifiées à l’aide de l’interface utilisateur de la mise à jour des clusters ou des applets de commande PowerShell de la mise à jour des clusters. Ces paramètres personnalisés peuvent être enregistrés dans un profil d’exécution de mise à jour et réutilisés pour les exécutions de mise à jour ultérieures.
architecture de plug-in public la mise à jour des clusters inclut des fonctionnalités permettant d’inscrire, d’annuler l’inscription et de sélectionner des plug-ins. La mise à jour cloud est fournie avec deux plug-ins par défaut : une coordonne les API de l’agent Windows Update (WUA) sur chaque nœud de cluster ; la deuxième applique les correctifs logiciels qui sont copiés manuellement dans un partage de fichiers accessible aux nœuds du cluster. Si une entreprise a des besoins uniques qui ne peuvent pas être satisfaits avec ces deux plug-ins, l’entreprise peut créer un nouveau plug-in de la mise à jour de la mise à jour cloud en fonction de la spécification de l’API publique. Pour plus d’informations, consultez Cluster-Aware informations de référence sur la mise à jour du plug-in.
Pour plus d’informations sur la configuration et la personnalisation des plug-ins de la mise à jour pour prendre en charge différents scénarios de mise à jour, consultez How Plug-ins Work.
Comment puis-je exporter la préversion et mettre à jour les résultats de la mise à jour de la mise à jour des clusters ?
La mise à jour cloud offre des options d’exportation via l’interface de ligne de commande et via l’interface utilisateur.
options d’interface de ligne de commande :
Afficher un aperçu des résultats à l’aide de l’applet de commande PowerShell Invoke-CauScan | ConvertTo-Xml. Sortie : XML
Signaler les résultats à l’aide de l’applet de commande PowerShell Invoke-CauRun | ConvertTo-Xml. Sortie : XML
Signaler les résultats à l’aide de l’applet de commande PowerShell Get-CauReport | Export-CauReport. Sortie : HTML, CSV
options d’interface utilisateur :
Copiez les résultats du rapport à partir de l’écran aperçu des mises à jour. Sortie : CSV
Copiez les résultats du rapport à partir de l’écran Générer un rapport. Sortie : CSV
Exportez les résultats du rapport à partir de l’écran Générer un rapport. Sortie : HTML
Comment installer la mise à jour des clusters ?
Une installation de la mise à jour des clusters est intégrée en toute transparence à la fonctionnalité clustering de basculement. La mise à jour de la mise à jour cloud est installée comme suit :
Lorsque le clustering de basculement est installé sur un nœud de cluster, le fournisseur WMI (CAU Windows Management Instrumentation) est automatiquement installé.
Lorsque la fonctionnalité Outils de clustering de basculement est installée sur un serveur ou un ordinateur client, les applets de commande Cluster-Aware Mise à jour de l’interface utilisateur et de PowerShell sont automatiquement installées.
La mise à jour des clusters nécessite-t-elle des composants s’exécutant sur les nœuds de cluster en cours de mise à jour ?
La mise à jour cloud n’a pas besoin d’un service s’exécutant sur les nœuds de cluster. Toutefois, la mise à jour CAU a besoin d’un composant logiciel (fournisseur WMI) installé sur les nœuds du cluster. Ce composant est installé avec la fonctionnalité clustering de basculement.
Pour activer le mode de mise à jour automatique, le rôle cluster de la mise à jour des clusters doit également être ajouté au cluster.
Quelle est la différence entre l’utilisation de la mise à jour CAU et de VMM ?
System Center Virtual Machine Manager (VMM) se concentre sur la mise à jour uniquement Hyper-V clusters, tandis que la mise à jour de n’importe quel type de cluster de basculement pris en charge, y compris les clusters Hyper-V.
VMM nécessite des licences supplémentaires, tandis que la mise à jour de la mise à jour cloud est concédée sous licence pour tous les serveurs Windows Server. Les fonctionnalités, outils et interface utilisateur de la mise à jour des clusters sont installées avec les composants de clustering de basculement.
Si vous possédez déjà une licence System Center, vous pouvez continuer à utiliser VMM pour mettre à jour Hyper-V clusters, car il offre une expérience de gestion intégrée et de mise à jour logicielle.
La mise à jour CAU est prise en charge uniquement sur les clusters exécutant Windows Server 2016, Windows Server 2012 R2 et Windows Server 2012. VMM prend également en charge les clusters Hyper-V sur les ordinateurs exécutant Windows Server 2008 R2 et Windows Server 2008.
Puis-je utiliser la mise à jour à distance sur un cluster configuré pour la mise à jour automatique ?
Oui. Un cluster de basculement dans une configuration de mise à jour automatique peut être mis à jour via la mise à jour à distance à la demande, tout comme vous pouvez forcer une analyse Windows Update à tout moment sur votre ordinateur, même si Windows Update est configuré pour installer automatiquement les mises à jour. Toutefois, vous devez vous assurer qu’une exécution de mise à jour n’est pas déjà en cours.
Puis-je réutiliser mes paramètres de mise à jour de cluster entre les clusters ?
Oui. La mise à jour des clusters prend en charge un certain nombre d’options d’exécution de mise à jour qui déterminent le comportement de l’exécution de mise à jour lorsqu’elle met à jour le cluster. Ces options peuvent être enregistrées en tant que profil d’exécution de mise à jour, et elles peuvent être réutilisées sur n’importe quel cluster. Nous vous recommandons d’enregistrer et de réutiliser vos paramètres dans les clusters de basculement qui ont des besoins de mise à jour similaires. Par exemple, vous pouvez créer un « profil d’exécution de mise à jour de cluster SQL ServerBusiness-Critical » pour tous les clusters Microsoft SQL Server qui prennent en charge les services critiques pour l’entreprise.