En una implementación de dispositivo de VMware Cloud Director con configuración de HA de base de datos, el usuario postgres no puede conectarse a los nodos de base de datos del mismo nivel a través de SSH.

Problema

Cuando se produce un problema de SSH entre los nodos de la base de datos, VMware Cloud Director muestra localClusterHealth como SSH_PROBLEM. Debe solucionar este problema crítico lo antes posible.

Puede ver localClusterHealth mediante la interfaz de usuario de administración del dispositivo de VMware Cloud Director o ejecutar la API del dispositivo de /nodes VMware Cloud Director. Consulte la documentación de API del dispositivo de VMware Cloud Director.

Cuando se ejecuta la API /nodes en un nodo del mismo nivel que el que tiene el problema de SSH, la API /nodes devuelve información que indica que localClusterHealth es SSH_PROBLEM y localClusterFailover es INDETERMINATE. El modo de conmutación por error es INDETERMINATE porque el nodo en el que se ejecuta la API /nodes no se puede conectar a uno de sus nodos del mismo nivel a través de SSH. Los "details" de la parte del resultado de "failover" del cuerpo de la respuesta para el nodo con un problema de SSH muestran: ssh failed. comando: ssh unreachable_standby_host_IP /usr/bin/grep failover=manual /opt/vmware/vpostgres/10/etc/repmgr.conf.

Por ejemplo, si un nodo en espera tiene un problema de SSH y usted ejecuta GET https://primary_host_IP:5480/api/1.0.0/nodes, la API /nodes podría devolver la siguiente información.
{
    "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 ejecuta GET https://unreachable_standby_host_IP:5480/api/1.0.0/nodes, debido a que el nodo no es de confianza, es posible que la información de localClusterFailover y localClusterState no sea correcta. La API /nodes devuelve mensajes de advertencia que indican que unreachable_standby_host_name no puede conectarse a sus nodos del mismo nivel.

Por ejemplo, es posible que la API /nodes devuelva la siguiente información.
{
    "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 almacena los certificados SSH del usuario postgres en el almacenamiento del servidor de transferencia compartido de NFS. Todos los nodos de base de datos deben tener acceso al almacenamiento del servidor de transferencia compartido. Si un nodo de base de datos deja de ser de confianza, es decir, los certificados SSH del usuario postgres ya no son válidos o accesibles, ese nodo no puede ejecutar comandos en sus nodos del mismo nivel mediante un cliente SSH. El dispositivo de VMware Cloud Director debe tener esta capacidad para funcionar correctamente cuando está en modo HA.

Solución

  1. Determine si hay un problema de conectividad entre los nodos y corrija el problema. Consulte la Comprobar el estado de conectividad de un clúster de alta disponibilidad de la base de datos.
  2. Compruebe que appliance-sync.timer se esté ejecutando en los nodos que tienen el problema de SSH mediante el siguiente comando.
    systemctl status appliance-sync.timer
    Por ejemplo, el comando podría devolver:
    * 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 el estado del servicio appliance-sync.timer no es Active, ejecute el siguiente comando para reiniciar el servicio.
    systemctl start appliance-sync.timer
  4. Espere aproximadamente 90 segundos y compruebe si el estado del clúster es HEALTHY mediante la interfaz de usuario de administración de VMware Cloud Director o llame a la API /nodes.