Skip to main content

17 septembre 2026

Gérer les nœuds de cluster Omnissa Access Control Plane

Cette rubrique décrit comment remplacer un déploiement de plan de contrôle existant en ajoutant des nœuds d'infrastructure/de plate-forme Omnissa et des nœuds d'accès, et explique ce à quoi s'attendre lorsqu'un nœud perd sa santé et est supprimé du cluster.

Ajouter un nœud Omnissa Access au cluster

Vous pouvez remplacer un nœud de plan de contrôle existant en ajoutant un nœud Linux Omnissa Access au cluster. Les nouveaux nœuds sont intégrés à l'aide de la commande wso cp deploy du nœud de démarrage.

Conditions préalables

  • L'adresse IP du nouveau nœud a été ajoutée à cp-cluster.ini sous le groupe d'hôtes approprié avant d'exécuter la commande déployer.
  • Le nouveau nœud est accessible via le protocole SSH à partir du nœud de démarrage.

Procédure :

  1. Ouvrez le fichier /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini et ajoutez l'adresse IP du nouveau nœud sous le groupe d'hôtes approprié. Par exemple :

    Option 1 - Nœud Omnissa Access : si vous ajoutez un nouveau nœud Omnissa Access, ajoutez-le sous ces sections :

    [general_compute_access_linux]
    10.0.0.x
    10.0.0.x  # New node
    [vault_server_linux]
    10.0.0.x  # New node
    [consul_server_linux]
    10.0.0.x  # New node
    [nomad_server_linux]
    10.0.0.x  # New node
    [general_compute_nginx_http]
    10.0.0.x  # New node
    

    Option 2 - Nœud d'infrastructure/de plate-forme : si vous ajoutez un nouveau nœud pour le nœud d'infrastructure/de plate-forme, ajoutez-le sous toutes les sections, à l'exception des sections suivantes :

    [general_compute_access_linux]
    [general_compute_nginx_http]
    [asset_server_linux]
    
    # If the new node is a candidate for asset-server-linux that will replace existing asset-server, you must add a node IP in asset_server_linux, too.
    

    Important : n'ajoutez pas l'adresse IP du nœud de démarrage à l'inventaire. La validation échoue si l'adresse IP de démarrage est détectée.

  2. À partir du nœud de démarrage, exécutez wso cp deploy pour intégrer le nœud.

    • Pour intégrer un ou plusieurs nœuds spécifiques, utilisez l'indicateur -t (--target-hosts) :

      # navigate to your cluster working directory
      cd /opt/wss/<cluster_name>
      wso cp deploy -t "10.0.0.x"
      

      Pour plusieurs nœuds :

      cd /opt/wss/<cluster_name>
      wso cp deploy -t "10.0.0.x,10.0.0.x"
      
  3. Exécutez les commandes suivantes pour vérifier si le cluster est sain :

    wso healthcheck
    
  4. Déplacez les charges de travail (services) vers le nouveau nœud. Par défaut, aucune charge de travail ne sera en cours d'exécution sur le nœud récemment ajouté. Vous devez vous connecter à l'UI Nomad à l'aide du jeton Nomad et effectuer les étapes ci-dessous

    1. Connectez-vous à l'UI Nomad à l'adresse https://10.0.0.x:4646/ui/jobs
    2. Cliquez sur Clients.
    3. Cliquez sur l'ID de nœud à partir duquel vous souhaitez déplacer les charges de travail.
    4. Cliquez sur Purger pour déplacer les charges de travail vers la nouvelle VM.

    Remarque : une fois l'opération de purge terminée, toutes les charges de travail seront déplacées vers la nouvelle VM. Vous ne pouvez pas déplacer les services sélectionnés vers le nouveau nœud.

  5. Supprimez le nœud existant du cluster en exécutant la commande suivante.

    # From the bootstrap VM
    source /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
    server_id = <node_ip> # IP of the node being removed
    
    # API to remove peer
    curl -sk \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -H "Content-Type: application/json" \
    -X POST \
    -d '{"server_id":"$server_id"}' \
    "$VAULT_ADDRESS/v1/sys/storage/raft/remove-peer"
    
  6. Vérifiez la santé du cluster et des services.

    wso healthcheck
    wso access check-service-readiness
    

Résolution des problèmes

ProblèmeCauseRésolution
Adresse IP de démarrage dans l'inventaireL'adresse IP du nœud de démarrage a été ajoutée à cp-cluster.ini.Supprimez l'adresse IP de démarrage du fichier d'inventaire.
Déploiement ignoréLe nœud a déjà été intégré (correspondance par hachage).Utilisez -f (--force) pour recommencer l'exécution.
Connexion via SSH refuséeLe nœud est inaccessible, ou le protocole SSH n'est pas configuré.Vérifiez la connectivité et les clés SSH.
Échec à l'étape Consul ou VaultLe cluster Consul ou Vault n'est pas sain.Vérifiez la santé du cluster avant d'ajouter un nœud.

Supprimez un nœud Omnissa Access du cluster

Il n'existe aucune commande de CLI dédiée pour supprimer un nœud du cluster de plan de contrôle. Lorsqu'un nœud devient indisponible ou pas sain, le cluster gère automatiquement la suppression :

  • Le nœud cesse de recevoir de nouvelles allocations de charge de travail après environ deux pulsations manquées.
  • Les charges de travail existantes sur le nœud sont replanifiées en nœuds sains.
  • Aucune commande de suppression manuelle n'est requise.
  1. Supprimez l'ancienne adresse IP de nœud du fichier cp-cluster.ini de toutes les sections pertinentes.
  2. Mettez hors tension le nœud supprimé.

Remarque : le nettoyage de l'appartenance au cluster se produit sur une chronologie différente de celle de la détection de panne :

  • Consul purge automatiquement les nœuds inactifs de sa liste de membres entre 24 et 72 heures.
  • Nomad supprime les nœuds périmés lors de son prochain cycle de nettoyage de la mémoire.
  • Pour cette raison, un nœud supprimé peut rester visible dans l'UI Nomad ou Consul pendant un certain temps après qu'il cesse de recevoir du trafic, même s'il n'est plus utilisé pour la planification.

Gestion des mots de passe pour les nœuds de cluster de plan de contrôle

Le délai d'expiration par défaut du mot de passe pour configuser et root est de 60 jours. Vous devez modifier le mot de passe sur tous les nœuds de cluster du plan de contrôle avant qu'il n'expire.

Il n'est pas nécessaire que le mot de passe racine et celui de configuser correspondent, mais ils doivent être identiques sur tous les nœuds du cluster. Par exemple, le mot de passe racine doit être le même sur chaque nœud et le mot de passe de configuser doit être le même sur chaque nœud.

Réinitialiser le mot de passe de configuser ou racine

Nœud unique, connecté en tant qu'utilisateur racine ou via sudo :

passwd configuser
passwd root

Sur tous les nœuds à la fois, à partir du nœud de démarrage :

export TARGETS='general_compute_linux:general_compute_access_linux'
wso control-plane ansible -- -b -m shell -a "echo 'configuser:NEW_PASSWORD' | chpasswd" "${TARGETS}"
wso control-plane ansible -- -b -m shell -a "echo 'root:NEW_PASSWORD' | chpasswd" "${TARGETS}"

Remplacez NEW_PASSWORD par le mot de passe réel avant l'exécution et ${TARGETS} par le groupe d'inventaire Ansible ou le modèle d'hôte pour la mise à jour des nœuds. Ne laissez pas l'espace réservé littéral dans un script enregistré ou dans l'historique de votre shell.

Important : après la modification du mot de passe configuser, mettez à jour le même mot de passe dans cp-cluster.ini sur le nœud de démarrage, sinon l'authentification des opérations de CLI wso par rapport au cluster échouera. Les sessions configuser actives n'ont pas besoin d'être invalidées après une réinitialisation.

Modifier la période d'expiration du mot de passe

L'expiration de 60 jours est contrôlée par les champs d'expiration du mot de passe sur chaque compte.

Remarque : s'il est exécuté en tant que configuser, utilisez sudo devant les commandes.

Vérifiez le paramètre actuel avec :

chage -l configuser
chage -l root

Modifiez-le par compte (nœud unique) :

chage -M <days> configuser
chage -M <days> root

-M définit le nombre maximal de jours pendant lesquels un mot de passe reste valide ; -1 désactive l'expiration (généralement non recommandé pour root ou les comptes de service).

Récupérer un mot de passe racine complètement oublié

Cela nécessite que la console (hyperviseur) puisse accéder à la machine virtuelle affectée, ce qui n'est pas possible via SSH et un seul nœud est récupéré à la fois.

  1. Redémarrez la machine virtuelle et interrompez-la dans le menu GRUB.

  2. Mettez en surbrillance l'entrée de démarrage et appuyez sur e pour la modifier.

  3. Recherchez la ligne commençant par linux (ou linux16), accédez à la fin de celle-ci et ajoutez :

    rd.break enforcing=0
    
  4. Appuyez sur Ctrl+X (ou F10) pour démarrer avec les paramètres modifiés. Cela vous amène au shell d'urgence Dracut.

  5. Remontez le système de fichiers racine en lecture-écriture et le chroot :

    mount -o remount,rw /sysroot
    chroot /sysroot
    
  6. Définissez le nouveau mot de passe :

    passwd root
    
  7. Marquez le système de fichiers pour un nouvel étiquetage SELinux au prochain démarrage, car SELinux était en mode permissif pour cette session :

    touch /.autorelabel
    
  8. Quittez le chroot et redémarrez :

    exit
    reboot
    

    Le premier démarrage après cela prend plus de temps que d'habitude, en raison du nouvel étiquetage SELinux.

Cette page vous a-t-elle été utile ?

Envoyer un commentaire sur cette rubrique

Cette rubrique vous a-t-elle été utile ?

N'indiquez aucune information personnelle ou confidentielle.

Génération du lien…