Le blog technique

Contexte

Migration de l’emplacement d’un FileShare Witness utilisé par un cluster.

Dans le cadre d’une configuration cluster Microsoft Cluster avec un nombre pair de noeuds, l’un des modèles utilisé afin d’assurer une majorité dans le quorum est le “Node and File Share Majority”. Cette méthode – peu couteuse en espace – permet d’utiliser un partage de fichier comme témoin.

Le partage stocke uniquement les information

Cet article présente comment migrer l’emplacement d’un partage  témoin utilisé par un cluster, il s’applique également à tout produit utilisant la technologie Microsoft Cluster.

Modification de la configuration du cluster

1. Afin de récupérer la configuration existante du cluster, il faut exécuter la commande PowerShell suivante :

Get-ClusterQuorum NOMDUCLUSTER

Actuellement, le type de quorum qui devrait s’afficher est “NodeAndFileShareMajority”.

2. Nous allons modifier la configuration du cluster de manière à le passer en “NodeMajority” à l’aide de la commande suivante :

Set-ClusterQuorum –cluster NOMDUCLUSTER –NodeMajority

La commande ci-dessus passe la configuration du cluster à “NodeMajority”, cette configuration est déconseillée lorsqu’un un nombre pair de noeuds est présent dans le cluster.

Valider depuis la console “Failover Cluster Manager Administrative Tool” que la nouvelle configuration a bien été prise en compte puis continuer.

3. La dernière étape va permettre de configurer le cluster en mode “NodeAndFileShareMajority” en indiquant le nouveau partage de fichier à utiliser :

Set-ClusterQuorum –cluster NOMDUCLUSTER –NodeAndFileShareMajority \\NOUVEAU PARTAGEDEFICHIER

Vérification

Valider depuis la console “Failover Cluster Manager Administrative Tool” que la nouvelle configuration a bien été prise en compte, il faut également valider au niveau du partage de fichier qu’une permission “NOMDUCLUSTER$” a bien été créé automatiquement :

Des alertes « Operations Manager Failed to Access the Windows Event Log” concernant des journaux d’événements Veeam Vmware (nWorks) et provenant de serveurs de management (MS) apparaissent :

Elles sont complétées par des événements 26604 récurrents (toutes les 12 minutes) dans les Event Log de ces serveurs :

The Windows Event Log Provider is still unable to open the Veeam VMware event log on computer ‘SRV0’. The Provider has been unable to open the Veeam VMware event log for 1440 seconds.

Most recent error details: The specified channel could not be found. Check channel configuration.

One or more workflows were affected by this.

Workflow name: Veeam.Virt.Extensions.VMware.VMGUEST.CollectEvents

Veeam a publié une KB concernant ce problème : http://www.veeam.com/kb1496#/kb1496

Les causes indiquées dans cette dernière ne semblent pas correspondre au contexte rencontré dans mon cas (les alertes apparaissaient sur deux nouveau MS physiques fraichement ajoutés), mais la solution proposée fonctionne malgré tout :

Dans la console Veeam, exécuter une reconstruction de la topologie Rebuild Full Topology :

Rien n’indiquera que la reconstruction est terminée, mais cela peut prendre plusieurs dizaines de minutes voire plusieurs heures selon la taille de votre infrastructure, mais lorsque cela sera bon les événements 26004 ne doivent plus revenir dans l’Event Log.

Il restera enfin à réinitialiser manuellement les moniteurs en erreur :

D’origine, il est possible via les common Published Data de récupérer dans n’importe quel runbook Orchestrator l’ID d’une activité ou d’un process :

On peut même récupérer l’ID de l’instance en cours d’exécution (Job ID) d’un runbook enfant lorsqu’il est appelé via l’activité Invoke Runbook :

Par contre, il n’y a rien de prévu pour récupérer l’ID de l’instance en cours d’exécution du runbook courant.

Ce Job ID du runbook courant peut cependant avoir son utilité, par exemple à des fins de logging et debug. Dans mon cas, il s’agissait de récupérer le nom de la personne ayant démarré le runbook via le portail self-service EUPSCO.

Il est donc malgré tout possible de récupérer cet ID, en intégrant la requête SQL suivante dans une activité Query Database :

SELECT POLICYINSTANCES.JobID
FROM  POLICYINSTANCES INNER JOIN
ACTIONSERVERS ON POLICYINSTANCES.ActionServer = ACTIONSERVERS.UniqueID
WHERE     (POLICYINSTANCES.ProcessID = <Activity process ID from "Initialize Data">) AND (ACTIONSERVERS.Computer = ‘<Runbook Server name from "Initialize Data">’) AND (POLICYINSTANCES.Status IS NULL)

Explication : cette requête interroge la base de données en lui fournissant l’Activity Process ID (qui est disponible nativement via les Common Published Data) afin de retrouver quel JobID contient cet Activity PRocess ID.

Il peut toutefois arriver que le Process ID soit présent plusieurs fois à l’identique dans la base, c’est pourquoi on filtre un peu plus en indiquant le nom du serveur qui exécute le runbook (Runbook Server Name dans les Common Published Data) et surtout en spécifiant le status « NULL », c’est-à-dire que l’on ne recherche que parmi les runbooks qui sont en cours d’exécution et qui n’ont donc pas encore un statut “success”, “warning” ou “failed”

Si tout s’est bien passé, le champ Full line as a string with fields separated by ‘ ;’ présent en sortie de l’activité Query Database devrait contenir le JobID de votre instance de runbook en cours d’exécution, à vous de le réutiliser à votre guise plus loin dans votre runbook !