Dans un déploiement de dispositif VMware Cloud Director avec une configuration de base de données HA, l'utilisateur postgres ne peut pas se connecter à ses nœuds de base de données homologues sur SSH.

Problème

En présence d'un problème SSH entre les nœuds de bases de données, VMware Cloud Director affiche le localClusterHealth comme SSH_PROBLEM. Vous devez résoudre ce problème critique le plus tôt possible.

Vous pouvez afficher le localClusterHealth à l'aide de l'interface utilisateur de gestion de dispositifs de VMware Cloud Director ou exécuter l'API /nodes du dispositif VMware Cloud Director. Reportez-vous à la documentation de VMware Cloud Director Appliance API.

Lorsque vous exécutez l'API /nodes sur un nœud homologue de celui présentant le problème SSH, l'API /nodes renvoie des informations indiquant que localClusterHealth est SSH_PROBLEM, localClusterFailover est INDÉTERMINÉ. Le mode de basculement est INDÉTERMINÉ, car le nœud sur lequel vous exécutez l'API /nodes ne peut pas se connecter à l'un de ses nœuds homologues sur SSH. La section "details" de la sortie "failover" du corps de la réponse pour le nœud présentant un problème SSH indique : ssh failed. commande : ssh unreachable_standby_host_IP /usr/bin/grep failover=manual /opt/vmware/vpostgres/10/etc/repmgr.conf.

Par exemple, si un nœud en veille présente un problème SSH et que vous exécutez GET https://primary_host_IP:5480/api/1.0.0/nodes, l'API /nodes peut renvoyer les informations suivantes.
{
    "localClusterFailover": "INDETERMINATE",
    "localClusterHealth": "SSH_PROBLEM",
    "localClusterState": [
        {
            "connectionString": "host=primary_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover = manual",
                "mode": "MANUAL",
                "repmgrd": {
                    "details": "On node primary_node_ID (primary_host_name): repmgrd = not applicable",
                    "status": "NOT APPLICABLE"
                }
            },
            "id": primary_node_ID,
            "location": "default",
            "name": "primary_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "PRIMARY",
            "role": "primary",
            "status": "* running",
            "upstream": ""
        },
        {
            "connectionString": "host=running_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover = manual",
                "mode": "MANUAL",
                "repmgrd": {
                    "details": "On node running_standby_node_ID (running_standby_host_name): repmgrd = not applicable",
                    "status": "NOT APPLICABLE"
                }
            },
            "id": running_standby_node_ID,
            "location": "default",
            "name": "running_standby_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "running",
            "upstream": "primary_host_name"
        },
        {
            "connectionString": "host=unreachable_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "ssh failed. command: ssh unreachable_standby_host_IP /usr/bin/grep failover=manual /opt/vmware/vpostgres/10/etc/repmgr.conf",
                "mode": "UNKNOWN",
                "repmgrd": {
                    "details": "On node unreachable_standby_node_ID (unreachable_standby_host_name): repmgrd = not running",
                    "status": "NOT RUNNING"
                }
            },
            "id": unreachable_standby_node_ID,
            "location": "default",
            "name": "unreachable_standby_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "running",
            "upstream": "primary_host_name"
        }
    ],
    "warnings": []
}

Si vous exécutez GET https://unreachable_standby_host_IP:5480/api/1.0.0/nodes, car le nœud n'est pas approuvé, les informations de localClusterFailover et localClusterState peuvent ne pas être correctes. L'API /nodes renvoie des messages d'avertissement indiquant que unreachable_standby_host_name ne parvient pas à se connecter à ses nœuds homologues.

Par exemple, l'API /nodes peut renvoyer les informations suivantes.
{
    "localClusterFailover": "MANUAL",
    "localClusterHealth": "SSH_PROBLEM",
    "localClusterState": [
        {
            "connectionString": "host=primary_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "ssh failed. command: ssh primary_host_IP /usr/bin/grep failover=manual /opt/vmware/vpostgres/10/etc/repmgr.conf",
                "mode": "UNKNOWN",
                "repmgrd": {
                    "details": "On node primary_node_ID (primary_host_name): repmgrd = n/a",
                    "status": "UNKNOWN"
                }
            },
            "id": primary_node_ID,
            "location": "default",
            "name": "primary_host_name",
            "nodeHealth": "UNHEALTHY",
            "nodeRole": "PRIMARY",
            "role": "primary",
            "status": "? running",
            "upstream": ""
        },
        {
            "connectionString": "host=running_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "ssh failed. command: ssh running_standby_host_IP /usr/bin/grep failover=manual /opt/vmware/vpostgres/10/etc/repmgr.conf",
                "mode": "UNKNOWN",
                "repmgrd": {
                    "details": "On node running_standby_node_ID (running_standby_host_name): repmgrd = n/a",
                    "status": "UNKNOWN"
                }
            },
            "id": running_standby_node_ID,
            "location": "default",
            "name": "running_standby_host_name",
            "nodeHealth": "UNHEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "? running",
            "upstream": "primary_host_name"
        },
        {
            "connectionString": "host=unreachable_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover = manual",
                "mode": "MANUAL",
                "repmgrd": {
                    "details": "On node unreachable_standby_node_ID (unreachable_standby_host_name): repmgrd = not applicable",
                    "status": "NOT APPLICABLE"
                }
            },
            "id": unreachable_standby_node_ID,
            "location": "default",
            "name": "unreachable_standby_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "running",
            "upstream": "? primary_host_name"
        }
    ],
    "warnings": [
        "unable to connect to node \"primary_host_name\" (ID: primary_node_ID)",
        "unable to connect to node \"running_standby_host_name\" (ID: running_standby_node_ID)",
        "unable to connect to node \"unreachable_standby_host_name\" (ID: unreachable_standby_node_ID)'s upstream node \"primary_host_name\" (ID: primary_node_ID)",
        "unable to determine if node \"unreachable_standby_host_name\" (ID: unreachable_standby_node_ID) is attached to its upstream node \"primary_host_name\" (ID: primary_node_ID)"
    ]
}

Cause

VMware Cloud Director stocke les certificats SSH de l'utilisateurs postgres sur le stockage du serveur de transfert partagé NFS. Tous les nœuds de base de données doivent avoir accès au stockage partagé du serveur de transfert. Si un nœud de base de données n'est plus approuvé, c'est-à-dire que les certificats SSH de l'utilisateur postgres ne sont plus valides ou accessibles, ce nœud ne peut pas exécuter de commandes sur ses nœuds homologues à l'aide d'un client SSH. Le dispositif VMware Cloud Director doit avoir cette capacité pour fonctionner correctement en mode HA.

Solution

  1. Déterminez l'éventuelle présence d'un problème de connectivité entre les nœuds et corrigez-le le cas échéant. Reportez-vous à Vérifier l'état de connectivité d'un cluster haute disponibilité de base de données.
  2. Vérifiez que le service appliance-sync.timer est en cours d'exécution sur les nœuds qui présentent le problème SSH en exécutant la commande suivante.
    systemctl status appliance-sync.timer
    Par exemple, la commande peut renvoyer :
    * appliance-sync.timer - Periodic check and sync of needed files for Cloud Appliance functionality
       Loaded: loaded (/lib/systemd/system/appliance-sync.timer; enabled; vendor preset: enabled)
       Active: active (waiting) since Sat 2020-09-05 23:22:49 UTC; 1 months 9 days ago
     
    Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
  3. Si l'état du service appliance-sync.timer n'est pas Actif, redémarrez le service en exécutant la commande suivante.
    systemctl start appliance-sync.timer
  4. Attendez environ 90 secondes et vérifiez que la santé du cluster est SAIN à l'aide de l'interface utilisateur de gestion de VMware Cloud Director ou appelez l'API /nodes.