En esta guía explicamos como crear un cluster entre 3 nodos, se asume que existen tres servidores instalados con proxmox, sino puede seguir la guía «instalación PROXMOX» pero el proceso debe servir para «n» cantidad de servidores.

Escenario:

Es importante entender el escenario que buscamos lograr, tenemos 3 servidores zeus, poseidon y hestia los cuales uniremos en un gran cluster que llamaremos «cluster-ugit-1», por si se llega a implementar otro cluster.
Otro aspecto importante a destacar que que PROXMOX utiliza «corosync» como el medio de sincronización entre los nodos y en su documentación oficial indican que lo mejor es que exista una red privada para este servicio y otra donde se maneja la interfaz web de administración, por esta razón cada servidor va a tener una pata en la red 10.20.200.0/24 para la interfaz web y otra en 10.20.252.0/24
Además dentro del cluster debemos establecer un servidor «master» dentro del cual vamos a crear el cluster y los demás nodos se unirán a este, para nuestro ejemplo usaremos el servidor de nombre «POSEIDON»
En resumen tenemos:

Nombre:	Función:	VLAN 201	VLAN CORO
POSEIDON	MASTER	10.20.200.14	10.20.252.14
ZEUS	Cliente 1	10.20.200.10	10.20.252.10
HESTIA	Cliente 2	10.20.200.30	10.20.252.30

Procedimiento:

Sobre «Master»

Paso 1: ingresamos por SSH al nodo «MASTER» (POSEIDON)

ssh 10.20.200.14 -l root

Paso 2: Ejecutar el siguiente comando para crear el cluster llamado «cluster-ugit-1»

pvecm create cluster-ugit-1

Paso 3: podemos verificar el estado del cluster

pvecm status

RESULTADO:

Quorum information
------------------
Date: Tue Apr 3 14:31:35 2018
Quorum provider: corosync_votequorum
Nodes: 1
Node ID: 0x00000001
Ring ID: 1/4
Quorate: Yes

Votequorum information
----------------------
Expected votes: 1
Highest expected: 1
Total votes: 1
Quorum: 1 
Flags: Quorate 

Membership information
----------------------
 Nodeid Votes Name
0x00000001 1 10.20.200.14 (local)

Como podemos ver el cluster de momento solo cuenta con un único nodo

Cliente 1: hestia

Ingresamos por ssh al servidor

ssh 10.20.200.30 -l root

Corremos el comando que nos permite incluirnos en un cluster

pvecm add 10.20.200.14

Nos pide si queremos conectarnos al servidor y nos solicita la contraseña del usuario «root»

The authenticity of host '10.20.200.14 (10.20.200.14)' can't be established.
ECDSA key fingerprint is SHA256:z+hrRqx/kU1slrr61YbVxE0LIHi5uQt6ejhEGCajFx4.
Are you sure you want to continue connecting (yes/no)? yes
root@10.20.200.14's password:
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'hestia' to cluster.

Cliente 2: Zeus

Ingresamos por ssh al servidor

ssh 10.20.200.10 -l root

Ejecutamos el comando de inclusión a cluster

pvecm add 10.20.200.14

Dentro de master

Podemos ejecutar el siguiente comando para ver los nodos disponibles

pvecm nodes

RESULTADO:

Membership information
----------------------
    Nodeid      Votes Name
         3          1 zeus
         1          1 poseidon (local)
         2          1 hestia

Podemos ver que en el cluster ya tenemos los nodos disponibles, al igual que si entramos vía web podemos observar que ya están los nodos disponibles

Red Corosync

En el proceso anterior creamos un cluster, pero tambien se había planteado la recomendación de PROXMOX de que el corosync tenga una red única, esto es lo que vamos hacer.
Lo primero que vamos hacer es garantizar que todos los nodos poseen una interfaz en la red destinada a corosync para nuestro caso 10.20.252.0/24

En Master-POSEIDON

Vamos asegurar que todas las interfaces de redes inician del forma automática

Vamos a crear un puente para cada interfaz
RESULTADO

Ahora al puente que le hemos asignado la red corosync le asignamos la ip

Reiniciamos el servidor

init 6

Vamos abrir el archivo:

nano /etc/network/interfaces

RESULTADO:

auto lo
iface lo inet loopback

auto enp66s0
iface enp66s0 inet manual
#Poseidon INT 2

auto enp4s0
iface enp4s0 inet manual
#Poseidon EXT

auto enp69s0f0
iface enp69s0f0 inet manual
#Poseidon INT 6

auto enp69s0f1
iface enp69s0f1 inet manual

auto enp70s0f0
iface enp70s0f0 inet manual

auto enp70s0f1
iface enp70s0f1 inet manual

auto vmbr0
iface vmbr0 inet static
address 10.20.200.14
netmask 255.255.255.0
gateway 10.20.200.1
bridge_ports enp66s0
bridge_stp off
bridge_fd 0

auto vmbr1
iface vmbr1 inet static
address 10.20.252.14
netmask 255.255.255.0
bridge_ports enp69s0f0
bridge_stp off
bridge_fd 0
#Poseidon INT 6

auto vmbr2
iface vmbr2 inet manual
bridge_ports enp69s0f1
bridge_stp off
bridge_fd 0

auto vmbr3
iface vmbr3 inet manual
bridge_ports enp70s0f0
bridge_stp off
bridge_fd 0

auto vmbr4
iface vmbr4 inet manual
bridge_ports enp70s0f1
bridge_stp off
bridge_fd 0

Como podemos ver la interfaz «enp66s0» es la utilizada para la interfaz web a través de puente «vmbr0»
La interfaz «enp4s0» la utilizaremos posteriormente para darle acceso a la interfaz web por una IP publica a través de puente «vmbr5»
Y la interfaz «enp69s0f0» la usaremos para el corosync a través del puente «vmbr1»

Cliente 1 – Hestia

Vamos hacer el mismo procedimiento
Creamos los puentes y el asignamos una IP de la red corosync

Cliente 2 – Zeus

Vamos hacer el mismo procedimiento
Creamos los puentes y el asignamos una IP de la red corosync

En master

Ahora podemos probar que ya tenemos una interfaz en la red de corosync y podemos hacer ping a todos los servidores y desde todos los servidores

ping 10.20.252.10
ping 10.20.252.14
ping 10.20.252.30

Podemos probar también con el comando que el multicast funciona se debe ejecutar en todos los servidores

omping -c 10000 -i 0.001 -F -q 10.20.252.14 10.20.252.10 10.20.252.30

Y podemos verificar que el multicast funciona en periodos largos (Dura como 10 minutos)

omping -c 600 -i 1 -q 10.20.252.14 10.20.252.10 10.20.252.30

Dentro de proxmox existen 2 archivos «corosync.conf» uno ubicado en «/etc/pve/corosync.conf» y el otro en «/etc/corosync/corosync.conf» al modificar el primero los cambios se aplican automáticamente en el otro.
El proceso de una modificación es el siguiente y además estos archivos tiene un numero «config_version» que debe ir cambiando para que se ejecute la actualización en el otro archivo.
Paso 1: copiamos al configuración del archivo actual en un nuevo archivo para poder modificar este sin que se caiga el corosync

cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new

Paso 2: Ahora podemos hacer los cambios necesarios en el nuevo archivo

nano /etc/pve/corosync.conf.new

Archivo actual

logging {
debug: off
to_syslog: yes
}

nodelist {
node {
name: hestia
nodeid: 2
quorum_votes: 1
ring0_addr: hestia
}
node {
name: poseidon
nodeid: 1
quorum_votes: 1
ring0_addr: poseidon
}
node {
name: zeus
nodeid: 3
quorum_votes: 1
ring0_addr: zeus
}
}

quorum {
provider: corosync_votequorum
}

totem {
cluster_name: cluster-ugit-1
config_version: 3
interface {
bindnetaddr: 10.20.200.14
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
}

Modificar a: (recuerde cambiar el numero de versión)

logging {
debug: off
to_syslog: yes
}

nodelist {
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: 4
interface {
bindnetaddr: 10.20.252.1
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
}

Paso 3: ahora vamos a respaldar el archivo de configuración actual por cualquier error

cp /etc/pve/corosync.conf /etc/pve/corosync.conf.bak

Paso 4: ahora actualizamos el archivo de configuración

mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf

Ahora podemos verificar con:

systemctl status corosync
o
journalctl -b -u corosync

Los cambios se deben de aplicar automáticamente si no puede reiniciar el servicio

systemctl restart corosync