Administrar nodos del clúster de Omnissa Access Control Plane

En este tema se describe cómo sustituir una implementación existente del plano de control agregando nodos de infraestructura/plataforma de Omnissa y nodos de Access, y se explica qué ocurre cuando un nodo deja de estar operativo y se elimina del clúster.

Agregar un nodo de Omnissa Access al clúster

Puede reemplazar un nodo del plano de control existente agregando un nodo Linux de Omnissa Access al clúster. Los nuevos nodos se incorporan mediante el comando wso cp deploy desde el nodo de arranque.

Requisitos

La dirección IP del nuevo nodo se ha agregado al archivo cp-cluster.ini en el grupo de hosts correspondiente antes de ejecutar el comando deploy.
Se puede acceder al nuevo nodo a través de SSH desde el nodo de arranque.

Procedimiento:

Abra el archivo /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini y agregue la dirección IP del nuevo nodo en el grupo de hosts correspondiente. Por ejemplo:

Opción 1 - Nodo de Omnissa Access: Si va a agregar un nuevo nodo de Omnissa Access, hágalo en estas secciones:
```
[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
```
Opción 2 - Nodo de infraestructura/plataforma: Si va a agregar un nuevo nodo de infraestructura/plataforma, hágalo en todas las secciones excepto en las siguientes:
```
[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.
```
Importante: No agregue la dirección IP del nodo de arranque al inventario. La validación fallará si se detecta la IP del nodo de arranque.
Desde el nodo de arranque, ejecute wso cp deploy para incorporar el nodo.
- Para incorporar uno o varios nodos específicos, utilice el indicador -t (--target-hosts):
```
# navigate to your cluster working directory
cd /opt/wss/<cluster_name>
wso cp deploy -t "10.0.0.x"
```
  Para varios nodos:
```
cd /opt/wss/<cluster_name>
wso cp deploy -t "10.0.0.x,10.0.0.x"
```
Ejecute el siguiente comando para comprobar si el estado del clúster es correcto.
```
wso healthcheck
```
Mueva las cargas de trabajo (servicios) al nuevo nodo. De forma predeterminada, no se ejecutarán cargas de trabajo en el nodo recién agregado. Debe iniciar sesión en la interfaz de usuario de Nomad utilizando el token de Nomad y seguir los pasos que se indican a continuación:
1. Inicie sesión en la interfaz de usuario de Nomad en https://10.0.0.x:4646/ui/jobs.
2. Haga clic en Clients.
3. Haga clic en el ID del nodo desde el que desea trasladar las cargas de trabajo.
4. Haga clic en Drain para trasladar las cargas de trabajo a la nueva máquina virtual.
Nota: Una vez completada la operación de traslado, todas las cargas de trabajo se habrán trasladado a la nueva máquina virtual. No es posible mover servicios seleccionados al nuevo nodo.

Elimine el nodo existente del clúster ejecutando el siguiente comando.

# 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"

Compruebe el estado del clúster y los servicios.

wso healthcheck
wso access check-service-readiness

Solucionar problemas

Problema	Causa	Resolución
IP de arranque en el inventario	La dirección IP del nodo de arranque se agregó a `cp-cluster.ini`.	Elimine la IP de arranque del archivo de inventario.
Implementación omitida	El nodo ya estaba incorporado (coincidencia de hash).	Utilice `-f` (`--force`) para volver a ejecutar.
Conexión SSH rechazada	No se puede acceder al nodo, o SSH no está configurado.	Compruebe la conectividad y las claves SSH.
Error en el paso de Consul o Vault	El estado del clúster de Consul o Vault es incorrecto.	Compruebe el estado del clúster antes de agregar un nodo.

Eliminar un nodo de Omnissa Access del clúster

No hay ningún comando de la CLI dedicado para eliminar un nodo del clúster del plano de control. Cuando un nodo deja de estar disponible o tiene un estado incorrecto, el clúster controla la eliminación automáticamente:

El nodo deja de recibir nuevas asignaciones de cargas de trabajo tras aproximadamente dos latidos perdidos.
Las cargas de trabajo existentes en el nodo se reasignan a nodos en estado correcto.
No es necesario ejecutar ningún comando de eliminación manual.

Elimine la dirección IP del nodo antiguo del archivo cp-cluster.ini en todas las secciones pertinentes.
Apague el nodo eliminado.

Nota: La limpieza de la pertenencia al clúster se lleva a cabo en un plazo diferente al de la detección de fallos:

Consul elimina automáticamente los nodos inactivos de su lista de miembros en un plazo de entre 24 y 72 horas.
Nomad elimina los nodos obsoletos durante su siguiente ciclo de recopilación de elementos no utilizados.
Por este motivo, un nodo eliminado puede permanecer visible en la interfaz de usuario de Nomad o Consul durante algún tiempo después de dejar de recibir tráfico, aunque ya no se utilice para la programación.

Administración de contraseñas para nodos del clúster del plano de control

La caducidad predeterminada de las contraseñas de las cuentas configuser y root es de 60 días. Debe cambiar la contraseña en todos los nodos del clúster del plano de control antes de que caduque.

La contraseña raíz y la contraseña de configuser no tienen que coincidir, pero cada una debe ser idéntica en todos los nodos del clúster. Por ejemplo, la contraseña raíz debe ser la misma en todos los nodos y la contraseña de configuser debe ser la misma en todos los nodos.

Restablecer la contraseña de configuser o root

En un solo nodo, con sesión iniciada como root o mediante sudo:

passwd configuser
passwd root

En todos los nodos a la vez, desde el nodo de arranque:

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}"

Sustituya NEW_PASSWORD por la contraseña real antes de ejecutar el comando y ${TARGETS} por el grupo de inventario de Ansible o el patrón de hosts correspondiente a los nodos que se van a actualizar. No deje el marcador de posición literal en un script guardado ni en el historial del shell.

Importante: Después de cambiar la contraseña de configuser, actualice la misma contraseña en cp-cluster.ini en el nodo de arranque; de lo contrario, las operaciones de la CLI de wso con el clúster empezarán a producir errores de autenticación. No es necesario invalidar las sesiones activas de configuser después de restablecer la contraseña.

Cambiar el período de caducidad de la contraseña

La caducidad de 60 días se controla mediante los campos de antigüedad de contraseña de cada cuenta.

Nota: Si está ejecutando los comandos como configuser, anteponga sudo a los comandos.

Compruebe la configuración actual con:

chage -l configuser
chage -l root

Cambie la configuración por cuenta (en un solo nodo):

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

-M establece el número máximo de días durante los que una contraseña seguirá siendo válida; -1 deshabilita la caducidad (por lo general, no se recomienda para root ni para cuentas de servicio).

Recuperar una contraseña raíz completamente olvidada

Para ello se necesita acceso a la consola (hipervisor) de la máquina virtual afectada. No se puede realizar mediante SSH y solo permite recuperar la contraseña de un nodo cada vez.

Reinicie la máquina virtual e interrumpa el proceso en el menú de GRUB.
Resalte la entrada de arranque y pulse e para editarla.
Busque la línea que comienza por linux (o linux16), vaya hasta el final y agregue:
```
rd.break enforcing=0
```
Pulse Ctrl+X (o F10) para arrancar con los parámetros modificados. Esto le llevará al shell de emergencia de Dracut.
Vuelva a montar el sistema de archivos raíz con permisos de lectura y escritura y ejecute chroot en él:
```
mount -o remount,rw /sysroot
chroot /sysroot
```
Establezca la nueva contraseña:
```
passwd root
```
Marque el sistema de archivos para que se vuelva a etiquetar con SELinux durante el siguiente arranque, ya que SELinux se encontraba en modo permisivo durante esta sesión:
```
touch /.autorelabel
```
Salga de chroot y reinicie:
```
exit
reboot
```
El primer arranque después de este proceso tardará más de lo habitual debido al nuevo etiquetado de SELinux.

¿Le resultó útil esta página?