Se presentó al agregar a ARES al cluster, se cayó el cluster y pasó a modo solo de lectura, se solucionó deteniendo el servicio de cluster en todos los nodos, editando los archivos de configuración de COROSYNC de manera manual y aumentando el número de versión para que se actualice, posteriormente se reiniciaron todos los servicios y los nodos, a continuación se detalla el proceso realizado.
1) Nos logeamos en todos los servidores, en el caso de que el cluster siga activo y tenga Quorum, y solo el último servidor agregado presente problemas, se debe realizar el proceso solo en el servidor con problemas, en caso contrario se debe hacer con todos los nodos que conforman el cluster
ssh -l root 10.20.200.202) Detenemos los servicios relacionados al cluster
/etc/init.d/pve-cluster stop
service corosync stop3) Cambiarse a modo solo local
pmxcfs -lAquí hay 2 opciones, la primera que nos indica que se pasará a modo local aún cuando ya existe el archivo corosync.conf
"even though corosync.conf is already present"en este caso todo marcha bien, la segunda opción es que nos indique que no es posible obtener «the lock»
"unable to get the lock"en este caso debemops borrar el archivo «.pmxcfs.lockfile» y volver a ejecutar «pmxcfs -l»
rm /var/lib/pve-cluster/.pmxcfs.lockfile
pmxcfs -lahora debería de mostrarnos la primera opción.
Una vez que estamos en el modo local los archivos de la ruta /etc/pve/ desaparecen, por ello vamos a crear el archivo /etc/pve/corosync.conf manualmente en base a el archivo /etc/corosync/corosync.conf,
respaldamos /etc/corosync/corosync.conf
cp /etc/corosync/corosync.conf /etc/corosync/corosync.conf.bakeditamos /etc/corosync/corosync.conf
nano /etc/corosync/corosync.confPara este punto debemos tener claro como debería lucir el archivo corosync.conf dado que nos daremos a la tarea de editarlo y debemos saber entre otras cosas el número de nodos esperados y las IP de la red COROSYNC de cada nodo, el archivo para la configuración de los servidores UGIT es
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: ares
nodeid: 4
quorum_votes: 1
ring0_addr: 10.20.252.20
}
node {
name: hestia
nodeid: 2
quorum_votes: 1
ring0_addr: 10.20.252.30
}
node {
name: poseidon
nodeid: 1
quorum_votes: 1
ring0_addr: 10.20.252.14
}
node {
name: zeus
nodeid: 3
quorum_votes: 1
ring0_addr: 10.20.252.10
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: cluster-ugit-1
config_version: 10
interface {
bindnetaddr: 10.20.252.1
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
}Y así es como debe editar el archivo /etc/corosync/corosync.conf, en nuestro caso debimos cambiar el
«ring0_addr: ares» por «ring0_addr: 10.20.252.20»
Si hace falta algún nodo se agrega a la configuración o se elimina de la misma según sea la necesidad, se debe subir la config_version para que sea actualizada y no sustituida al reiniciar el servicio, por ultimo se copia el archivo de configuración de corosync
cp /etc/corosync/corosync.conf /etc/pve/corosync.confy se reinician los servicios
/etc/init.d/pve-cluster start
service corosync start
service pve-cluster start
service pvedaemon restart
service pveproxy restartAl reiniciar pve-cluster nos daba un error que indica que no puede encontrar el archivo lock o que el mismo no es accesible, para ello debemos eliminarlo
rm /var/lib/pve-cluster/.pmxcfs.lockfiley volvemos a reiniciar el cluster
service pve-cluster restartSeguía dando un error, pero ahora indicaba que la ruta /etc/pve/ no se encontraba disponible, o seguía desmontada para ello se reinician los nodos con este problema para que la ruta /etc/pve/ sea montada de nuevo, si los servidores están en producción se puede intentar montar la ruta de manera manual, este ultimó caso no se realizó.
Al reiniciar los nodos, el cluster estaba activo y sin ningún error en los logs.
En nuestro caso inicialmente se saco a ARES del cluster, se arregló el cluster entre POSEIDON-HESTIA-ZEUS, y luego se reincorporó a ARES al cluster, lo mejor era arreglar el cluster desde la primera vez con los cuatro nodos ya que se debió repetir este proceso en ARES cuando se reincorporó al cluster, en este caso cuando se editó el /etc/pve/corosync.conf de ARES en modo local, se puso la misma «config_version» que se encontraba en el archivo /etc/pve/corosync.conf de POSEIDON, una vez ARES estaba activo e incorporado al cluster se cambió nuevamente la config_version de POSEIDON para revisar que efectivamente se actualizaba en todos los nodos del cluster.
Con el cluster entre ARES-POSEIDON-HESTIA-ZEUS funcionando, se probó la migración de HESTIA-ARES indicando el error «No se puede accesar a la dirección de destino con la public_key», para resolver esto debemos garantizar que la clave ssh_host_rsa_key.pub de cada servidor es conocida por cada uno de los nodos, para esto debemos garantizar que todos los nodos tenga el mismo contenido en el archivo
/etc/ssh/ssh_known_hosts, en donde deberían estar las llaves contenidas en /etc/ssh/ssh_host_rsa_key.pub tanto para el nombre del servidor como para la IP, el formato del archivo /etc/ssh/ssh_known_hosts debe ser
poseidon ssh-rsa "public_key"
10.20.200.12 ssh-rsa "public_key"Estas dos lineas debe aparecer por cada uno de los nodos miembros del cluster, cuando el cluster esta funcionando bien, el nodo master actualiza a los esclavos con su contenido de /etc/ssh/ssh_known_hosts, en nuestro caso ARES no tenia este archivo y debimos crearlo, ademas de agregar la public_key de ARES contenida en etc/ssh/ssh_host_rsa_key.pub, al archivo /etc/ssh/ssh_known_hosts de POSEIDON y luego copiar el archivo /etc/ssh/ssh_known_hosts de POSEIDON en /etc/ssh/ssh_known_hosts de ARES, HESTIA y ZEUS fueron actualizados por POSEIDON, al final los 4 nodos tienen la siguiente configuración de /etc/ssh/ssh_known_hosts
poseidon ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDR8qUapn/DVaNqv3z1yAdTxby4qUAp4Br3GXh8eTuMAmrz8t+q2dXtNzq31dRkHAxx+OS1ADR3jqm63SJ9OUEDJZmMrtxLkXNDoAlkaRg2L6HYLhNBeDawa1XmBL7DDYETPZoorQ9S0g06qqbTIfwr/CzleI+TLptc65R1iFlxa49pKOBJVbqwnv3Yc7t46WuMGZDbFdqPqpjOwZpHGXLeOGXz6N4ip3SFjQxXlKNhtgTMtaO7BVkJiupDN9ybfccLh6aHvB3TWFUk5aBLQtIodqaxAl5SSKfNL81FpfbtjNd0GlUA9QX5+AjtXprFCjgeXnQ5l0Dxq7UotAd44XYH
10.20.200.14 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDR8qUapn/DVaNqv3z1yAdTxby4qUAp4Br3GXh8eTuMAmrz8t+q2dXtNzq31dRkHAxx+OS1ADR3jqm63SJ9OUEDJZmMrtxLkXNDoAlkaRg2L6HYLhNBeDawa1XmBL7DDYETPZoorQ9S0g06qqbTIfwr/CzleI+TLptc65R1iFlxa49pKOBJVbqwnv3Yc7t46WuMGZDbFdqPqpjOwZpHGXLeOGXz6N4ip3SFjQxXlKNhtgTMtaO7BVkJiupDN9ybfccLh6aHvB3TWFUk5aBLQtIodqaxAl5SSKfNL81FpfbtjNd0GlUA9QX5+AjtXprFCjgeXnQ5l0Dxq7UotAd44XYH
hestia ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCobTYp1I5b488UQ1JaiL6m+maHUBss5iy55XH4gFo6TLDFI+VACtG6HuLbIQlYlqnwfJmsZz8WXzTcKAxq1ijh2SwZMDhFaBwl8uUt9W3JSJ0fex1DGXvfic/uaGsU60FAO5/mWxQEK9aF4H9w5GC0jiUpNGE5NG1C31oqHoYfjH6MGOnle0een/pl26YNzIvXRDkvXPr7iq2EquBescD8ScFIfaR8kkVlT0znht2o56byyyYvGZFDnO8v9hL8CJAcxxcdem4KJl7AKo9w4nE5/Cq5jcMvK4kdECa0q3fg5yAV6EeexYU6K58o9g2EHqjG04gXiZV4b+uK5Ue5TETD
10.20.200.30 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCobTYp1I5b488UQ1JaiL6m+maHUBss5iy55XH4gFo6TLDFI+VACtG6HuLbIQlYlqnwfJmsZz8WXzTcKAxq1ijh2SwZMDhFaBwl8uUt9W3JSJ0fex1DGXvfic/uaGsU60FAO5/mWxQEK9aF4H9w5GC0jiUpNGE5NG1C31oqHoYfjH6MGOnle0een/pl26YNzIvXRDkvXPr7iq2EquBescD8ScFIfaR8kkVlT0znht2o56byyyYvGZFDnO8v9hL8CJAcxxcdem4KJl7AKo9w4nE5/Cq5jcMvK4kdECa0q3fg5yAV6EeexYU6K58o9g2EHqjG04gXiZV4b+uK5Ue5TETD
zeus ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXFNe9MZHlZmYhNkar4nUbeveO2RpMIUGXmV/dALz8TNobjeJQJN0+nfqI4xrIkYhdoCVXxEc6b0S9M+VQXZXPMesrHSkYIY6peQPHN5ca8/51b//xtnf++TBlHq8BFH344eAMytZpH0syVZikUU9/Dxx4yPfBma8C16UJp74/dFEZ3ayD4Ww702uZTBIra/c2iecMN/JUB8BjXNa8PKLAlXekD9vO8RIMfaDqkXu4UbOwgzh/qnymRLgtjh6K0qyFxKNIz+3U5pPb/27mUA6kbgdOKlJOCU6/dllBdbpbXVYvLY4ybjfvQDxlQ0YnjolGauarzDLTuGe41eKraPNt
10.20.200.10 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXFNe9MZHlZmYhNkar4nUbeveO2RpMIUGXmV/dALz8TNobjeJQJN0+nfqI4xrIkYhdoCVXxEc6b0S9M+VQXZXPMesrHSkYIY6peQPHN5ca8/51b//xtnf++TBlHq8BFH344eAMytZpH0syVZikUU9/Dxx4yPfBma8C16UJp74/dFEZ3ayD4Ww702uZTBIra/c2iecMN/JUB8BjXNa8PKLAlXekD9vO8RIMfaDqkXu4UbOwgzh/qnymRLgtjh6K0qyFxKNIz+3U5pPb/27mUA6kbgdOKlJOCU6/dllBdbpbXVYvLY4ybjfvQDxlQ0YnjolGauarzDLTuGe41eKraPNt
ares ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFyYTUR/cNtMAbXj0aSp4+5AiSk+UP9B0jJICULWEXcm60eVSBfV5gvbi8aipIE+OtJkGm++MhgJo0J8tv+AH6lwIXeFfFeN/Y1SiNgWRd/b5H0rcAs1gjAMvz8I3iS2ax9TMZNi/8E+dF1aLvEZLcpXUyA6f1gSbTIiQ0guv93at3EyJRzoGZgcDad6zt87exn0C9vkAWXj5JpJFtTM2Fql4HJ1zo930em2lt9k0B+PyPLE5hHYvxDzkBYsw5v9OAfGC/ZcVbeMMeFCoFXIDedz6aXjNQ2VrTqhvhVVognEhbtX5v+otRsJjWzwSVPn5KMjMdk7+qRNORI+H9YTQV
10.20.200.20 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFyYTUR/cNtMAbXj0aSp4+5AiSk+UP9B0jJICULWEXcm60eVSBfV5gvbi8aipIE+OtJkGm++MhgJo0J8tv+AH6lwIXeFfFeN/Y1SiNgWRd/b5H0rcAs1gjAMvz8I3iS2ax9TMZNi/8E+dF1aLvEZLcpXUyA6f1gSbTIiQ0guv93at3EyJRzoGZgcDad6zt87exn0C9vkAWXj5JpJFtTM2Fql4HJ1zo930em2lt9k0B+PyPLE5hHYvxDzkBYsw5v9OAfGC/ZcVbeMMeFCoFXIDedz6aXjNQ2VrTqhvhVVognEhbtX5v+otRsJjWzwSVPn5KMjMdk7+qRNORI+H9YTQVFinalmente se probó la migración de una maquina virtual de HESTIA hacia ARES y viceversa con resultados satisfactorios.