Redémarrage automatique des nœuds gérés de gWLM dans des domaines SRD (Disponibilité élevée)

Chaque fois qu'un nœud géré est amorcé, son agent gWLM tente de rejoindre automatiquement le nœud dans son domaine SRD, afin de fournir une disponibilité élevée. Les seules étapes de configuration à effectuer pour que ce comportement se produise sont les suivantes :

Assurez-vous que le fichier /etc/rc.config.d/gwlmCtl sur chaque nœud géré a un paramètre GWLM_AGENT_START défini à 1. Vous pouvez exécuter la commande suivante sur chaque système sur lequel gwlmagent est en cours d'exécution pour qu'il apporte la modification pour vous :
# /opt/gwlm/bin/gwlmagent --enable_start_on_boot
Dans le même fichier, il vous faut également GWLM_CMS_START=1 sur le système sur lequel gwlmcmsd est en cours d'exécution. Toutefois, lorsque vous avez exécuté /opt/vse/bin/vseinitconfig durant l'installation, cette modification a été apportée automatiquement.
(Facultatif) Modifiez la propriété
com.hp.gwlm.node.HA.minimumTimeout
dans le fichier /etc/opt/gwlm/conf/gwlmagent.properties afin de définir le nombre minimum de secondes qui doivent s'écouler avant qu'un nœud géré se considère comme séparé de son domaine SRD. Définissez cette propriété afin de vous assurer que des problèmes réseau mineurs ne font pas en sorte qu'un nœud géré ne se considère pas prématurément comme séparé.
gWLM utilise cette valeur uniquement si elle est supérieure à 10 multiplié par l'intervalle d'allocation de gWLM. Par exemple, avec un intervalle d'allocation de 15 secondes, un nœud peut passer 2,5 minutes sans communiquer avec son domaine SRD avant que son agent gWLM ne tente de rétablir une connexion avec le domaine SRD.

Cette fonctionnalité est plus performante lorsqu'un nœud géré est perdu à la fois ou lorsque tous les nœuds gérés sont perdus.




	REMARQUE : Si une vpar emprunte des processeurs à d'autres vpars lorsqu'elle perd contact avec son domaine SRD, ces processeurs empruntés peuvent être séparés du domaine SRD. Si la vpar peut être désactivée pendant une durée prolongée, vérifiez que le domaine SRD s'est reformé sans cette vpar et qu'il dispose de suffisamment de processeurs pour remplir ses engagements. Si ce n'est pas le cas, essayez d'utiliser `vparmodify` pour récupérer une partie des processeurs. (Avec la vpar désactivée, vous ne pourrez pas la modifier localement, et seules certaines versions de HP-UV Virtual Partitions vous permettent de modifier une vpar distante.) De même, si une npar a plusieurs processeurs actifs (à cause d'Instant Capacity) lorsqu'elle perd contact avec son domaine SRD, vous devrez peut-être dimensionner manuellement la npar de façon à récupérer ces processeurs pour les npars qui se trouvent encore dans le domaine SRD. Pour plus d'informations sur ces aspects, reportez-vous à la documentation d'Instant Capacity.

Fonctionnement du redémarrage automatique

Lorsqu'un nœud géré est amorcé, l'agent gWLM (gwlmagent) démarre automatiquement si GWLM_AGENT_START a la valeur 1 dans le fichier /etc/rc.config.d/gwlmCtl. L'agent vérifie alors le fichier /etc/opt/gwlm/deployed.config pour déterminer son CMS. Ensuite, il tente de contacter le CMS pour faire en sorte qu'il redéploie sa vue du domaine SRD. Si le CMS ne peut être contacté, le domaine SRD dans le fichier deployed.config est déployé, à condition que tous les nœuds soient d'accord.

En général, lorsqu'un domaine SRD est perturbé par la panne d'un nœud ou par des problèmes de communication réseau, gWLM tente de reformer le domaine SRD. gWLM maintient le concept d'un cluster pour les nœuds d'un domaine SRD. Dans un cluster, un nœud est un maître et les autres nœuds sont des non-maîtres. Si le nœud maître perd contact avec le reste du domaine SRD, le reste du domaine SRD peut continuer sans lui, en tant que cluster partiel, en nommant de manière unanime un nouveau maître. Si un non-maître perd la communication avec le reste du domaine SRD, le cluster partiel résultant continue de fonctionner sans le nœud perdu. Le maître omet simplement le nœud manquant jusqu'à ce qu'il soit de nouveau disponible.




	REMARQUE : Les tentatives de reformer des domaines SRD peuvent dépasser le délai d'attente, entraînant ainsi l'absence de domaine SRD déployé et par conséquent l'absence de gestion des allocations de ressources. Si cela se produit, arrêtez et démarrez les agents, comme décrit dans la section « Événement "Node Failed to Rejoin SRD on Start-up" » ci-dessous.

Événements connexes

Vous pouvez configurer les événements SIM suivants concernant cette fonctionnalité de redémarrage automatique :

Node Failed to Rejoin SRD on Start-up
SRD Reformed with Partial Set of Nodes
SRD Communication Issue

Pour plus d'informations sur l'activation et l'affichage de ces événements, reportez-vous au menu "Configure Events" de gWLM.

Vous pouvez afficher ces événements à l'aide de l'élément Event Lists situé dans le volet gauche de SIM.

Les sections suivantes expliquent comment gérer certains des événements.

Événement "Node Failed to Rejoin SRD on Start-up"

Si vous constatez la présence de cet événement :

Arrêtez le gwlmagent sur chaque nœud géré dans le domaine SRD affecté :
# /opt/gwlm/bin/gwlmagent --stop
Redémarrez l'agent sur chacun de ces nœuds gérés :
# /opt/gwlm/bin/gwlmagent
Vérifiez que l'agent a rejoint le domaine SRD en contrôlant la vue Shared Resource Domain dans SIM ou en exécutant la commande gwlm monitor.
Si le problème persiste, vérifiez si les fichiers /var/opt/gwlm/gwlmagent.log.0 et /var/opt/gwlm/gwlm/gwlmcmsd.log.0 contiennent des messages de diagnostic supplémentaires.

Événements "SRD Communication Issue" / "SRD Reformed with Partial Set of Nodes"




	REMARQUE : La reformation avec un ensemble de nœuds partiel requiert un minimum de trois nœuds gérés dans le domaine SRD.Les événements "SRD Communication Issue" ne sont pas activés par défaut. Pour afficher ces événements, configurez vos événements dans SIM par le biais de la barre de menus VSE Management à l'aide de Tools -> Global Workload Manager -> Events.

Si vous avez un domaine SRD contenant n nœuds et que vous recevez des événements

n - 1 événements "SRD Communication Issue"

mais aucun

événement "SRD Reformed with Partial Set of Nodes" dans les 5 minutes qui suivent (en supposant que l'intervalle d'allocation soit de 15 secondes) le premier événement "SRD Communication Issue"

vous devrez peut-être :

Arrêter le gwlmagent sur chaque nœud géré dans le domaine SRD affecté :
# /opt/gwlm/bin/gwlmagent --stop
Redémarrer l'agent sur chacun de ces nœuds gérés :
# /opt/gwlm/bin/gwlmagent

Effacement manuel d'un domaine SRD

Si gWLM est incapable de reformer un domaine SRD, vous pouvez effacer manuellement le domaine SRD comme décrit ci-dessous.

Effacement d'un domaine SRD d'un agent A.02.50.00.x (ou version ultérieure)

La commande discutée ci-dessous est une commande avancée pour l'effacement d'un domaine SRD. La méthode recommandée pour supprimer un hôte du système de gestion consiste à utiliser la commande gwlm undeploy.

À compter des agents A.02.50.00.x, vous pouvez effacer manuellement un domaine SRD à l'aide de la commande suivante :

# gwlm reset --host=hôte

où hôte spécifie l'hôte contenant le domaine SRD à effacer.

Si la commande ci-dessus ne fonctionne pas, appliquez la procédure décrite dans la section suivante.

Effacement d'un agent SRD d'une version quelconque

La procédure suivante permet d'effacer un domaine SRD quelle que soit la version des agents dans le domaine SRD :

Supprimez le fichier deployed.config sur chaque nœud géré :
# rm -f /etc/opt/gwlm/deployed.config
Forcez un dédéploiement du domaine SRD (nommé SRD ci-dessous) afin de vous assurer que le CMS et les nœuds gérés s'accordent sur l'état du domaine SRD. Exécutez la commande suivante sur le CMS :
# /opt/gwlm/bin/gwlm undeploy --srd=SRD --force
Arrêtez le démon gwlmagent sur chaque nœud géré :
# /opt/gwlm/bin/gwlmagent --stop
Démarrez le démon gwlmagent sur chaque nœud géré :
# /opt/gwlm/bin/gwlmagent




	REMARQUE : Si le CMS gWLM et l'agent ne sont pas d'accord sur le fait qu'un domaine SRD soit déployé ou dédéployé, vous pouvez utiliser l'option `--force` avec la commande `gwlm deploy` ou `gwlm undeploy`.