Patcher les Clusters Windows

Le patching des serveurs Windows est un sujet ultra classique dans les entreprises. Microsoft répond à cette problématique via WSUS et SCCM. D'ailleurs depuis SCCM 2007, ce produit s'appuie sur le moteur de WSUS pour détecter les patchs nécessaires sur les postes, mais utilise ensuite ses propres mécanismes pour la distribution afin d'apporter d'avantage de fonctionnalités telles que les fenêtres de maintenance ou la possibilité d'interdire le redémarrage du serveur.

Le sujet devient autrement plus compliqué dès qu'il faut patcher des clusters...
Pour automatiser le déploiement de patchs sur les clusters, certaines entreprises tâchent de mettre les différents noeuds dans des fenêtres ou des groupes de patching différents. Les noeuds rebootent ainsi à des moments différents.
Ce fonctionnement trouve vite ses limites, quand les ressources n'ont pas basculé correctement ou lorsqu'un noeud n'a pas correctement redémarré.

Et qu'est ce que dit le Support Microsoft ?
Aussi étrange que cela puisse paraître, pour le patching d'un cluster, le support Microsoft n'a guère que la KB174799 : Patching Windows Server Failover Clusters à proposer, c'est à dire, une procédure manuelle. Rien d'automatique !
Dans une réponse récente, le support précise aussi que la fonctionnalité de bascule des ressources cluster est une fonctionnalité de protection qui ne doit pas être mis en oeuvre en fonctionnement nominal. Il est donc hors de question de laisser un serveur redémarrer (donc d'appliquer un patch nécessitant un redémarrage) alors qu'une ressource est en cours d'exécution. Pour Microsoft, il est en effet préférable que la bascule des ressources soit supervisée par un opérateur .

A noter que les cluster Hyper-V échappent à cette règle. En effet, grâce à SCVMM, il est possible de passer un noeud en mode maintenance entraînant le déplacement automatisé et sécurisé de toutes les ressources sur les autres nœuds actifs.


Que peut-on faire à court terme ?
Reste à trouver une solution pour patcher les clusters, certes sans revenir à un processus entièrement manuel, mais surtout sans risquer des casser les ressources hébergées (et en général critiques).
Il est, je pense, évident pour tout le monde que la production est prioritaire, mais qu'il faut tout de même appliquer ces patchs quand cela est possible. A court terme, la meilleure solution trouvée a donc été de préserver l'intégrité d'une ressource en interdisant de patcher le nœud sur lequel elle s'exécute plutôt que de patcher ce nœud au risque de corrompre cette ressource.

La solution retenue a donc été de rester sous WSUS en mettant les nœuds des clusters dans des groupes différents. A la charge pour les opérateurs de déplacer les ressources sur les bons nœuds avant chaque fenêtre de patching. Jusque là, rien de très nouveau même si le dernier point implique un travail manuel important pour les opérateurs.

Pour éviter les oublis et les catastrophes, un script est chargé de vérifier périodiquement sur chaque nœud si une ressource s'exécute et interdit dans ce cas l'installation automatique des patchs.
Les tentatives pour déplacer automatiquement les ressources par script se sont soldées par de gros échecs, principalement en raison de la complexité du processus.

Schématiquement, voila ce que çà donne :

Vous pouvez télécharger le script AutomaticPatchInstallation. Vous trouverez avec ce script la procédure d'installation/désinstallation ainsi que la procédure de patching d'un cluster avec cet outil.


Sympa le Bricolage ! Maintenant que la production est sécurisée, qu'elle solution plus pérenne peut être mise en place ?
Je l'avoue, c'est un peu du bricolage ;o) mais ce bricolage permet d'offrir rapidement une solution pour que les applications critiques conservent leur base SQL en état de marche (pas mal, non ?)


Reste bien évidement encore à trouver une solution nécessitant moins d'intervention manuelle tout en garantissant la sécurité du processus.
Notre cahier des charges est alors le suivant :
 - Un Cluster n'est patché que si tous ses noeuds sont en bonne santé
 - Les ressources doivent être déplacées d'un noeud à un autre automatiquement mais de manière sécurisé
 - L'ensemble du processus doit être supervisé et facilement adaptable aux spécificités des applications.

La Suite System Center 2012 est bien évidemment tout indiquée :
 - SCCM 2012 se charge de patcher les noeuds
 - SCOM 2012 se charge de superviser l'état du cluster et de ses noeuds
 - SC Orchestrator 2012 se charge quant à lui d'orchestrer les opérations

Le processus de déploiement sécurisé des patchs sur les nœuds d'un cluster est alors le suivant :

Le codage de workflow dans SC Orchestrator 2012 peut être plus ou moins long selon le niveau de service attendu mais nous voyons déjà toute l'intérêt de SC Orchestrator 2012 pour effectuer des tâches courantes d'administration.


@bientôt
Julien