In una distribuzione dell'appliance di VMware Cloud Director con configurazione HA del database, l'utente postgres non può connettersi ai nodi del database peer tramite SSH.

Problema

Quando tra i nodi del database si verifica un problema di SSH, in VMware Cloud Director, localClusterHealth viene indicato come SSH_PROBLEM. È necessario risolvere questo problema critico appena possibile.

È possibile visualizzare localClusterHealth utilizzando l'interfaccia utente di gestione dell'appliance di VMware Cloud Director o eseguire l'API dell'appliance di VMware Cloud Director /nodes. Vedere la documentazione dell'API dell'appliance VMware Cloud Director.

Quando si esegue l'API di /nodes in un nodo peer di quello in cui si è verificato il problema relativo a SSH, l'API /nodes restituisce l'informazione che localClusterHealth è SSH_PROBLEM e localClusterFailover è INDETERMINATE. La modalità di failover è INDETERMINATE perché il nodo in cui viene eseguita l'API /nodes non può connettersi a uno dei suoi nodi peer tramite SSH. In "details" nella parte dell'output "failover" del corpo della risposta per il nodo con il problema relativo a SSH viene visualizzato il messaggio: ssh failed. command: ssh unreachable_standby_host_IP /usr/bin/grep failover=manual /opt/vmware/vpostgres/10/etc/repmgr.conf.

Ad esempio, se in un nodo di standby si verifica un problema relativo a SSH e si esegue GET https://primary_host_IP:5480/api/1.0.0/nodes, l'API /nodes potrebbe restituire le informazioni seguenti.
{
    "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": []
}

Se si esegue GET https://unreachable_standby_host_IP:5480/api/1.0.0/nodes, poiché il nodo non è attendibile, le informazioni localClusterFailover e localClusterState potrebbero non essere corrette. L'API /nodes restituisce messaggi di avviso in cui specifica che unreachable_standby_host_name non è in grado di connettersi ai nodi peer.

Ad esempio, l'API /nodes potrebbe restituire le informazioni seguenti.
{
    "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)"
    ]
}

Causa

VMware Cloud Director archivia i certificati SSH dell'utente postgres nello storage del server di trasferimento condiviso NFS. Tutti i nodi del database devono poter accedere allo storage del server di trasferimento condiviso. Se un nodo del database diventa non attendibile, ovvero i certificati SSH dell'utente postgres non sono più validi o non sono accessibili, il nodo non è in grado di eseguire comandi nei suoi nodi peer utilizzando un client SSH. L'appliance di VMware Cloud Director deve avere questa funzionalità per poter funzionare correttamente in modalità HA.

Soluzione

  1. Verificare se esiste un problema di connettività tra i nodi e correggere il problema. Vedere Verifica dello stato di connettività di un cluster a disponibilità elevata del database.
  2. Verificare che il servizio appliance-sync.timer sia in esecuzione nei nodi in cui si è verificato il problema relativo a SSH eseguendo il comando seguente.
    systemctl status appliance-sync.timer
    Ad esempio, il comando potrebbe restituire:
    * 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. Se lo stato del servizio appliance-sync.timer non è Attivo, riavviare il servizio eseguendo il comando seguente.
    systemctl start appliance-sync.timer
  4. Attendere circa 90 secondi e verificare che l'integrità del cluster sia HEALTHY utilizzando l'interfaccia utente di gestione di VMware Cloud Director o richiamare l'API /nodes.