El libro de ruta de comprobación de estado de VMware Integrated OpenStack CLI abarca los casos y procedimientos de viocli check health para solucionar los problemas notificados.

Puede ejecutar cualquiera de las siguientes soluciones para los problemas notificados en viocli check health:

El nodo no está listo

  • Para obtener el estado del nodo, ejecute el comando osctl get node.
    osctl get node
NAME                                       STATUS   ROLES                     AGE   VERSION
controller-dqpzc8r69w                      Ready    openstack-control-plane   17d   v1.17.2+vmware.1
controller-lqb7xjgm9r                      Ready    openstack-control-plane   17d   v1.17.2+vmware.1
controller-mvn5nmdrsp                      Ready    openstack-control-plane   17d   v1.17.2+vmware.1
vxlan-vm-111-161.vio-mgmt.eng.vmware.com   Ready    master                    17d   v1.17.2+vmware.1
  • Reinicie el servicio kubelet en el not ready node con el siguiente comando:
    viosshcmd ${not_ready_node} 'sudo systemctl restart kubelet'
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n kubernetes.

Nodo con dirección IP duplicada

Para obtener más información sobre el nodo con una dirección IP duplicada, consulte Artículo 82608 de la base de conocimientos.

Para volver a comprobar el estado de este problema, ejecute viocli check health -n kubernetes.

Nodo en mal estado

  • Ejecute osctl describe node <node> para obtener el estado del nodo.
    Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message

  ----                 ------  -----------------                 ------------------                ------                       -------

  NetworkUnavailable   False   Sat, 05 Jun 2021 10:47:53 +0000   Sat, 05 Jun 2021 10:47:53 +0000   CalicoIsUp                   Calico is running on this node

  MemoryPressure       False   Mon, 07 Jun 2021 01:21:55 +0000   Mon, 07 Jun 2021 00:57:29 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available

  DiskPressure         False   Mon, 07 Jun 2021 01:21:55 +0000   Mon, 07 Jun 2021 00:57:29 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure

  PIDPressure          False   Mon, 07 Jun 2021 01:21:55 +0000   Mon, 07 Jun 2021 00:57:29 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available

  Ready                True    Mon, 07 Jun 2021 01:21:55 +0000   Mon, 07 Jun 2021 00:57:32 +0000   KubeletReady                 kubelet is posting ready status
  • Si el estado de NetworkUnavailable, MemoryPressure, DiskPressure o PIDPressure es true, el nodo de Kubernetes tiene un estado anómalo. Por lo tanto, debe comprobar el estado del sistema y el uso de recursos del nodo con estado anómalo.
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n kubernetes.

Nodo con uso elevado de disco

  • Inicie sesión en el nodo que notifica un uso elevado de disco.
    #viossh ${node}
  • Compruebe el uso de disco con df -h.
  • Elimine los archivos no utilizados en el nodo.
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n kubernetes.
Nota: Kubelet purga algunas imágenes de Docker del repositorio de imágenes local en VMware Integrated OpenStack Manager cuando el espacio libre en disco pasa a estar por debajo del 15 %. Cuando esto ocurre y algunos pods pasan a tener el estado Evicted, póngase en contacto con el soporte técnico de VMware para recuperarlos.
Nodo con uso elevado de Inode
  • Inicie sesión en el nodo con uso elevado de Inode.
    #viossh ${node}
  • Compruebe el uso del Inode con df -i /.
  • Elimine los archivos no utilizados en el nodo.
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n kubernetes.

Nodo con instantánea

  • Inicie sesión en vCenter y elimine las instantáneas tomadas para los nodos del controlador de VMware Integrated OpenStack.
  • Si notifica un error No se ha podido conectarse a vCenter, debe comprobar la información de conexión de vCenter en VMware Integrated OpenStack.
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n kubernetes.

No se puede resolver el FQDN

  • En el nodo de administración de VMware Integrated OpenStack, compruebe la resolución de DNS con los siguientes comandos:
    #viosshcmd ${node_name}  -c "nslookup ${reported_host}"
#toolbox -c "dig $host +noedns +tcp"
  • Si se produjo un error, compruebe el servidor DNS configurado en VMware Integrated OpenStack /etc/resolve.conf del nodo.
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n connectivity.

NTP no sincronizado en el nodo

Para obtener más información sobre un nodo NTP, consulte Artículo 78565 de la base de conocimientos. Para volver a comprobar el estado de este problema, ejecute viocli check health -n connectivity.

LDAP inaccesible

Compruebe la conexión de los nodos de VMware Integrated OpenStack con el servidor LDAP especificado y asegúrese de que la configuración de LDAP (usuario, credenciales) de VMware Integrated OpenStack sea correcta. Para volver a comprobar el estado de este problema, ejecute viocli check health -n connectivity.

vCenter inaccesible

En el caso de que vCenter esté inaccesible, compruebe la conexión de los nodos de VMware Integrated OpenStack con la instancia de vCenter especificada y asegúrese de que la configuración de vCenter (usuario, credenciales) en VMware Integrated OpenStack sea correcta. Para volver a comprobar el estado de este problema, ejecute viocli check health -n connectivity.

NSX inaccesible

Para NSX inaccesible, compruebe la conexión de los nodos de VMware Integrated OpenStack al servidor de NSX especificado y asegúrese de que la configuración de NSX (usuario, credenciales) sea correcta. Para volver a comprobar el estado de este problema, ejecute viocli check health -n connectivity.

Servidor de registros inaccesible
Servidor de DNS inaccesible
  • Asegúrese de que el servidor DNS se pueda comunicar con la red de acceso a la API de VMware Integrated OpenStack.
  • Debe tener preparados todos los requisitos previos enumerados en el documento Habilitar el componente Designate.
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n connectivity.

Partición de red incorrecta en nodo rabbitmq

  • Para forzar la recreación del nodo rabbitmq, ejecute en el nodo de administración de VMware Integrated OpenStack.
    #osctl delete pod ${reported_rabbitmq_node}
  • Para volver a comprobar el estado de este problema, ejecute viocli heath check -n rabbitmq.

Problema del clúster WSREP

Si el estado de implementación de viocli get deployment es En ejecución, póngase en contacto con el soporte de VIO. De lo contrario, siga las instrucciones que aparecen a continuación.
  • Ejecute el siguiente comando desde el nodo de VMware Integrated OpenStack Manager: 
    #kubectl -n openstack exec -ti mariadb-server-0 -- mysql --defaults-file=/etc/mysql/admin_user.cnf --connect-timeout=5 --host=localhost -B -N -e "show status;"
#kubectl -n openstack exec -ti mariadb-server-1 -- mysql --defaults-file=/etc/mysql/admin_user.cnf --connect-timeout=5 --host=localhost -B -N -e "show status;"
#kubectl -n openstack exec -ti mariadb-server-2 -- mysql --defaults-file=/etc/mysql/admin_user.cnf --connect-timeout=5 --host=localhost -B -N -e "show status;"
  • Si la salida wsrep_cluster_size de mariadb-server-x no es 3, vuelva a crear el nodo mariadb con:
    #kubectl -n openstack delete pod mariadb-server-x
  • Si se observa un gran vacío de wsrep_last_commited entre los tres nodos, reinicie el nodo o nodos mariadb con un número menor con wsrep_last_committed.
    #kubectl -n openstack delete pod mariadb-server-x
  • Para volver a comprobar el estado de este problema, ejecute viocli check health -n mariadb.

Tablas grandes en la base de datos de OpenStack

  • glance.images

    Hay trabajos cron habilitados de forma predeterminada para purgar automáticamente los registros eliminados por software en la base de datos de Glance.

    Compruebe si el trabajo cron de purga de base de datos está habilitado y funciona correctamente.

    viocli update glance
jobs:
  db_purge:
    age_in_days: 60
    max_rows: 1000
  db_purge_images:
    age_in_days: 60
    max_rows: 1000
manifests:
  cron_job_db_purge: true
  cron_job_db_purge_images: true

    cron_job_db_purge se utiliza para habilitar la purga de tablas de Glance de la base de datos, excepto la tabla "image".

    cron_job_db_purge_images se utiliza para habilitar la purga de la tabla "image" de Glance de la base de datos.

    --age_in_days NUM solo purga las filas que se han eliminado durante más de NUM días. El valor predeterminado es de 30 días.

    --max_rows NUM purga un máximo de NUM filas de cada tabla. El valor predeterminado es 100.

  • cinder.volumes y cinder.volume_attachment

    Pasos manuales para purgar la base de datos de Cinder

  1. Copia de seguridad de la base de datos de Cinder. 
    osctl exec -ti mariadb-server-0 -- mysqldump --defaults-file=/etc/mysql/admin_user.cnf -R cinder > /tmp/cinder_backup.sql
  2. Inicie sesión en el pod cinder-api-xxxxx. 
    osctl exec -ti deploy/cinder-api bash
  3. Limpie la base de datos de Cinder. 
    cinder-manage db purge 60
    Nota:

    uso del comando: cinder-manage db purge age_in_days.

    argumentos posicionales: age_in_days purga filas eliminadas anteriores a la antigüedad en días.

    Es posible que deba ajustar age_in_days para limpiar más registros eliminados por software en la base de datos de Cinder.

Hay demasiados recursos de red heredados en el plano de control

Para obtener una solución, consulte Error al habilitar Ceilometer cuando hay 10k redes de tenants de Neutron en las Notas de la versión de VMware Integrated OpenStack 7.1.

OpenStack Keystone no funciona correctamente

  • Debe intentar iniciar sesión para OpenStack desde el cuadro de herramientas como usuario administrador e intentar ejecutar comandos como openstack user list y openstack user show. Si se produce un error en el inicio de sesión, recopile y compruebe los mensajes de error de los registros de Keystone.
  • Obtenga la lista del pod keystone-api:
    #osctl get pod | grep keystone-api
  • Recopile los registros:
    #osctl logs keystone-api-xxxx -c keystone-api >keystone-api-xxxx.log
  • Para comprobar el estado de este problema, ejecute viocli check health -n keystone.

ID de red en blanco en la base de datos de Neutron

Para obtener una solución, consulte Artículo 76455 de la base de conocimientos. Para comprobar el estado de este problema, ejecute viocli check health -n neutron.

Referencia de vCenter incorrecta en Neutron

  • Obtenga el nombre de viocluster. 
    osctl get viocluster
    Si se devuelve viocluster1, continúe con el siguiente paso. De lo contrario, se trata de una falsa alarma. Póngase en contacto con el soporte técnico de VMware para obtener una solución permanente.
  • Obtenga la configuración viocluster de vCenter.
    # osctl get viocluster viocluster1 -oyaml
  • Haga una copia de seguridad de la configuración de Neutron.
    osctl get neutron -oyaml > neutron-<time-now>.yml
  • Edite el CR de Neutron cmd:osctl edit neutron neutron-xxx y después cambie la especificación de CR reemplazando la referencia de vCenter que se encuentra en el paso 1.
    spec:
  conf:
    plugins:
      nsx:
        dvs:
          dvs_name: vio-dvs
          host_ip: .VCenter:vcenter812:spec.hostname <---- change the vcenter instance to viocluster refered
          host_password: .VCenter:vcenter812:spec.password <---- same above
          host_username: .VCenter:vcenter812:spec.username <----
          insecure: .VCenter:vcenter812:spec.insecure <----
  • Para comprobar el estado de este problema, ejecute viocli check health -n neutron.
Servicios de Nova inactivos
  • Obtenga el pod para Nova.
    osctl get pod | grep nova

    Compruebe si el pod de Nova no está en estado En ejecución.

  • Elimine el pod con: osctl delete pod xxx.

    Espere al nuevo pod hasta que su estado sea En ejecución.

  • Para comprobar el estado de este problema, ejecute viocli check health -n nova.

Servicio Nova obsoleto

Para obtener información sobre un servicio Nova obsoleto, consulte Artículo 78736 de la base de conocimientos. Para comprobar el estado de este problema, ejecute viocli check health -n nova.

Nova redundante en la lista de catálogos
  • Inicie sesión en el cuadro de herramientas e intente encontrar y eliminar el servicio redundante de Nova y algún servicio de Nova sin endpoints.
    # openstack catalog list
    # openstack service list
  • Encuentre el servicio nova en uso.
    # openstack endpoint list |grep nova
  • Para comprobar el estado de este problema, ejecute viocli check health -n nova.

Algunos pods de proceso para Nova no dejan de reiniciarse porque se agota el tiempo de espera del inicio

Esta alarma indica que el estado de algunos pods de proceso para Nova puede ser incorrecto. Póngase en contacto con el soporte técnico de VMware para obtener una solución. Para comprobar el estado del problema, ejecute viocli check health -n nova.

Almacén de datos de Glance inaccesible

  • Obtenga la lista de servicios de Glance.
    osctl get glance
  • Obtenga la información del almacén de datos de Glance.
    osctl get glance $glance-xxx -o yaml
  • Busque la información de conexión del almacén de datos.
    spec:
  conf:
    backends:
      vmware_backend:
        vmware_datastores: xxxx
        vmware_server_host: xxxx
        vmware_server_password: xxxx
        vmware_server_username: .xxxx
  • Si la información no es correcta, compruebe la conexión de vCenter y el almacén de datos y actualícela con osctl update glance $glance-xxx según corresponda.
  • Para comprobar el estado de este problema, ejecute viocli check health -n glance.

Imágenes de Glance con un formato de ubicación incorrecto

El mensaje indica que algunas de las imágenes de Glance tienen un formato de ubicación incorrecto. Póngase en contacto con el soporte técnico de VMware para obtener una solución. Para comprobar el estado del problema, ejecute viocli check health -n glance.

Servicios de Cinder inactivos

  • Obtenga el pod de Cinder.
    osctl get pod | grep cinder | grep -v Completed

    Compruebe si el pod de Cinder no está en estado En ejecución.

  • Elimine el pod con: osctl delete pod xxx.

    Espere al nuevo pod hasta que su estado se muestre como En ejecución.

  • Para comprobar el estado de este problema, ejecute viocli check health -n cinder.
Servicio Cinder obsoleto
  • Inicie sesión en el pod cinder-volume.
    #osctl exec -ti cinder-volume-0 bash
  • Compruebe y enumere los servicios de Cinder obsoletos.
    #cinder-manage service list
    Por ejemplo: 
    #cinder-manage service list
  • Elimine los servicios de Cinder obsoletos mediante el comando cinder-manage en el pod cinder-volume.
    # cinder-manage service remove cinder-scheduler cinder-scheduler-7868dc59dc-km9mj
# cinder-manage service remove cinder-volume controller01@e-muc-cb-1b-az3:172.23.48.18
  • Para comprobar el estado de este problema, ejecute viocli check health -n cinder.
No se encontró el comando
  • Para instalar el comando necesario en el nodo de administración de VMware Integrated OpenStack, ejecute tdnf install xxx.
  • Para comprobar el estado de este problema, ejecute viocli check health -n basic.

Lista de nodos de Kubernetes vacía o nodo inaccesible

Ejecute osctl get nodes desde el nodo de administración de VMware Integrated OpenStack y compruebe si puede capturar la salida correcta. Para comprobar el estado de este problema, ejecute viocli check health -n basic.

No hay ningún pod en ejecución

Ejecute osctl get pod |grep xxx desde el nodo de administración de VMware Integrated OpenStack y compruebe si puede capturar algún pod en ejecución desde la salida. Para comprobar el estado de este problema, viocli check health -n basic.

Pod inaccesible

Ejecute el comando bash osctl exec -it $pod_name desde el nodo de administración de VMware Integrated OpenStack y compruebe si puede iniciar sesión en el pod. Para comprobar el estado de este problema, ejecute viocli check health -n basic.

Ejecutar comando en un pod

Compruebe el archivo de registro /var/log/viocli_health_check.log para obtener información detallada e intente volver a ejecutar el comando desde el nodo de administración de VMware Integrated OpenStack. Para comprobar el estado de este problema, ejecute viocli check health -n basic.

OpenStack no está listo
  • Inicie sesión en el cuadro de herramientas y ejecute algunos comandos OpenStack, por ejemplo openstack catalog list, y compruebe si el comando puede capturar el retorno correcto.
  • Para obtener más mensajes, agregue la opción debug. Por ejemplo:
    openstack catalog list --debug
  • Para comprobar el estado de este problema, ejecute viocli check health -n basic.
Contraseña de administrador de OpenStack vacía almacenada en VMware Integrated OpenStack
  • Obtenga la contraseña de administrador de OpenStack y compárela con OS_PASSWORD.
    osctl get secret keystone-keystone-admin -o jsonpath='{.data.OS_PASSWORD}
  • Si no hay ningún valor almacenado en keystone-keystone-admin, actualícelo con osctl edit secret keystone-keystone-admin.
  • Para comprobar el estado de este problema, ejecute viocli check health -n basic.
Nota: Si las contraseñas son diferentes, debe ponerse en contacto con VMware para recuperar la contraseña correcta.

El clúster de vCenter está sobrecargado o los hosts están bajo presión

Compruebe los hosts de vCenter para el plano de control de VIO y agregue más recursos, o bien limpie algunas instancias no utilizadas para aliviar la presión sobre los recursos.

El certificado de VIO caducó o está a punto de caducar
  • Compruebe el registro /var/log/viocli_health_check.log y busque el último mensaje de check_vio_cert_expire para saber hace cuánto tiempo caducó el certificado o cuándo va a caducar.
  • Para actualizar el certificado, siga Actualizar certificado para VMware Integrated OpenStack.
  • Para volver a comprobar el estado del problema, ejecute viocli check health -n connectivity.

El certificado de LDAP caducó o está a punto de caducar

  • Compruebe el registro /var/log/viocli_health_check.log y busque el último mensaje de check_ldap_cert_expire para saber hace cuánto tiempo caducó el certificado o cuándo va a caducar.
  • Para actualizar el certificado, siga Actualizar certificado para servidor LDAP.
    Nota: Si no hay ningún LDAP configurado, aparecerá el mensaje de registro No LDAP Certificate found y se omite la comprobación.
  • Para volver a comprobar el estado del problema, ejecute viocli check health -n connectivity.

El certificado de vCenter caducó o está a punto de caducar

  • Compruebe el registro /var/log/viocli_health_check.log y busque el último mensaje de check_vcenter_cert_expire para saber hace cuánto tiempo caducó el certificado o cuándo va a caducar.
  • Para actualizar el certificado, siga Configurar VMware Integrated OpenStack con certificado de NSX-T o vCenter actualizado.
    Nota: Si la instancia de vCenter está configurada para usar una conexión no segura, aparece el mensaje de registro Use insecure connection y se omite la comprobación.
  • Para volver a comprobar el estado del problema, ejecute viocli check health -n connectivity.

El certificado de NSX caducó o está a punto de caducar

  • Compruebe el registro /var/log/viocli_health_check.log y busque el último mensaje de check_nsx_cert_expire para saber hace cuánto tiempo caducó el certificado o cuándo va a caducar.
  • Para actualizar el certificado, siga Configurar VMware Integrated OpenStack con certificado de NSX-T o vCenter actualizado.
    Nota: Si la instancia de NSX está configurada para usar una conexión no segura, aparece el mensaje de registro Use insecure connection y se omite la comprobación.
  • Para volver a comprobar el estado del problema, ejecute viocli check health -n connectivity.

Servicio xxx detenido

Ejecute viocli start xxx para iniciar el servicio. Para comprobar el estado de este problema, ejecute viocli check health -n lifecycle_manager.

Los hosts de vCenter para el plano de control de VIO están bajo presión
  • Compruebe el registro /var/log/viocli_health_check.log y busque el último mensaje de check_cluster_workload, que proporciona un uso detallado de los recursos.
  • Solucione los problemas de recursos notificados y ejecute viocli check health -n kubernetes para volver a comprobar el estado.