Corosync es uno de los componentes que permiten que varios servidores Proxmox VE funcionen como un cluster coordinado. Su trabajo no consiste en ejecutar máquinas virtuales ni almacenar sus discos, sino en mantener la comunicación entre los nodos, gestionar la membresía y proporcionar la información necesaria para determinar si existe quorum. Es una pieza poco visible durante el funcionamiento normal, pero decisiva cuando un servidor o una conexión de red falla.
Las claves de Corosync en Proxmox en 20 segundos
- Corosync mantiene coordinados los nodos que forman un cluster Proxmox.
- La membresía determina qué servidores siguen formando parte del cluster y el quorum establece si existe mayoría suficiente.
- Proxmox utiliza Corosync junto con
pmxcfs, Kronosnet y su sistema de alta disponibilidad. - Sus temporizadores ayudan a detectar fallos y reorganizar la membresía.
- Una red estable, redundante y de baja latencia es más importante que disponer de mucho ancho de banda.
Cuando se crea un cluster con pvecm, Proxmox configura esta infraestructura de comunicación prácticamente sin que el administrador tenga que enfrentarse directamente a todos sus componentes. Eso explica que sea posible administrar Proxmox durante años sin profundizar demasiado en Corosync.
Entenderlo resulta útil porque conceptos como cluster, quorum, Corosync, fencing, watchdog, QDevice, HA o Ceph están relacionados, pero solucionan problemas diferentes. Confundirlos puede llevar a considerar altamente disponible una infraestructura que únicamente tiene varios servidores agrupados.
Qué es Corosync y qué hace dentro de Proxmox
Corosync es un motor de comunicación para clusters utilizado por diferentes proyectos de alta disponibilidad en Linux. Proxmox VE lo emplea como pieza de su arquitectura de clustering para que los servidores puedan mantener una visión coherente de quién pertenece al cluster.
Una instalación puede estar formada, por ejemplo, por:
- PVE01
- PVE02
- PVE03
Los tres servidores necesitan saber que pertenecen al mismo cluster y mantener información actualizada sobre la presencia de los demás.
Si PVE03 deja de responder, no basta con marcarlo como desconectado. PVE01 y PVE02 necesitan acordar una nueva membresía en la que PVE03 ya no participe.
Ahí aparece una de las principales funciones de Corosync.
Membresía
La membresía describe qué nodos forman parte en ese momento del cluster.
Puede cambiar porque un servidor se apaga, se reinicia, pierde conectividad o vuelve a incorporarse.
Este concepto es importante porque un servidor aparentemente desaparecido podría continuar funcionando pero haber quedado aislado debido a un problema de red.
Quorum
El segundo concepto es el quorum.
Proxmox utiliza un modelo basado en votos para determinar si una parte del cluster dispone de suficiente autoridad para continuar operando.
En un ejemplo básico de tres nodos:
| Nodo | Votos |
|---|---|
| PVE01 | 1 |
| PVE02 | 1 |
| PVE03 | 1 |
| Total | 3 |
Si desaparece PVE03, quedan dos votos de tres. Existe mayoría y, por tanto, quorum.
Si PVE01 queda completamente aislado de los otros dos, únicamente dispone de un voto. No puede saber si PVE02 y PVE03 están realmente apagados o simplemente continúan funcionando al otro lado de una interrupción de red.
El quorum ayuda a impedir que ambas partes actúen simultáneamente sobre los mismos recursos.
Esta es una de las protecciones frente al split brain, una situación especialmente peligrosa en sistemas distribuidos porque diferentes grupos de servidores pueden considerar que son la parte válida del cluster.
Por eso se habla tanto de tres nodos en Proxmox. No es que tres servidores virtualicen mejor que dos. Tres votos permiten conservar una mayoría de dos después de perder un miembro.
Corosync, Kronosnet, pmxcfs y QDevice: cómo encajan las piezas
Corosync no trabaja aislado. Alrededor de él aparecen varios componentes que conviene distinguir.
| Componente | Función principal |
|---|---|
| Corosync | Comunicación, membresía y servicios de quorum del cluster |
| Kronosnet (knet) | Transporte de comunicaciones entre los nodos |
| pmxcfs | Sistema de archivos distribuido de configuración de Proxmox |
| pvecm | Herramienta de Proxmox para gestionar el cluster |
| QDevice | Voto externo para determinados diseños de quorum |
| Watchdog | Ayuda a aislar mediante reinicio un nodo problemático en HA |
| HA Manager | Gestiona los recursos protegidos por alta disponibilidad |
Separar estas funciones ayuda a comprender qué ocurre cuando algo falla.
Kronosnet: el transporte
Las versiones actuales de Corosync utilizan Kronosnet, habitualmente denominado knet, como capa de transporte.
Es la parte encargada de transportar las comunicaciones entre los miembros y permite utilizar múltiples enlaces entre nodos.
Esto tiene una consecuencia práctica: un cluster puede disponer de redundancia para la comunicación de Corosync.
Pero la redundancia debe existir realmente en la infraestructura.
Dos enlaces configurados sobre VLAN diferentes pero que atraviesan la misma tarjeta, switch o camino físico pueden seguir compartiendo un único punto de fallo.
pmxcfs: la configuración distribuida de Proxmox
Proxmox añade otro componente importante: Proxmox Cluster File System (pmxcfs).
Es el sistema de archivos que aparece montado en /etc/pve y permite distribuir la configuración del cluster entre sus nodos.
Allí se encuentran configuraciones de máquinas virtuales, almacenamiento, usuarios y otros elementos de Proxmox.
pmxcfs utiliza la información proporcionada por Corosync para mantener la consistencia del cluster. Cuando un nodo pierde quorum, el comportamiento de este sistema cambia precisamente para evitar modificaciones potencialmente conflictivas.
Por eso un administrador puede encontrarse con /etc/pve en modo de solo lectura después de perder quorum. No es simplemente un problema de permisos del sistema de archivos.
pvecm: la herramienta que ve el administrador
Proxmox proporciona pvecm como interfaz de administración del cluster.
Uno de los comandos básicos es:
pvecm statusPermite consultar información como el número de nodos, votos, quorum y estado general.
También resulta útil:
pvecm nodesLa configuración de Corosync utilizada por Proxmox puede consultarse en:
/etc/pve/corosync.confEste fichero forma parte de la configuración crítica del cluster y no debería modificarse sin conocer las consecuencias.
QDevice y por qué aparece en clusters de dos nodos
Un cluster de dos nodos plantea un problema evidente.
Si cada servidor dispone de un voto y se pierde la comunicación entre ambos, ninguno puede saber con certeza si el otro está apagado o simplemente aislado.
Una solución contemplada por Proxmox para determinados clusters pequeños consiste en incorporar un QDevice, normalmente apoyado en un QNetd externo.
Su función puede entenderse como la incorporación de un voto externo al proceso de quorum.
No es necesario que ese tercer elemento sea otro servidor Proxmox capaz de ejecutar máquinas virtuales.
Esto permite construir arquitecturas del tipo:
| Elemento | Función |
|---|---|
| PVE01 | Cómputo + voto |
| PVE02 | Cómputo + voto |
| QDevice | Arbitraje de quorum |
El matiz es importante: QDevice ayuda con el quorum, pero no aporta capacidad de recuperación.
Si PVE01 falla, PVE02 puede conservar la situación necesaria para operar con ayuda del mecanismo de quorum, pero todas las máquinas que deban recuperarse tendrán que caber en PVE02.
Un tercer voto no proporciona RAM, CPU ni almacenamiento.
Token y consensus: cómo sabe Corosync que algo ha cambiado
Para mantener coordinado el cluster Corosync utiliza diferentes temporizadores. Dos de los más conocidos son token y consensus.
token forma parte del mecanismo utilizado para detectar problemas en la circulación del token entre los miembros.
consensus interviene durante el establecimiento de una nueva membresía.
Estos parámetros explican por qué la desaparición de un servidor no provoca una reacción instantánea. En un sistema distribuido reaccionar demasiado rápido también puede ser peligroso.
Un paquete perdido o unos milisegundos de congestión no deberían hacer que un servidor perfectamente operativo sea declarado muerto.
Por eso existen temporizadores.
También explica por qué bajar indiscriminadamente los valores de Corosync para intentar conseguir un failover más rápido puede producir el efecto contrario: una red inestable puede generar falsas detecciones y cambios innecesarios de membresía.
El tamaño del cluster también influye. Corosync dispone de token_coefficient, que permite aumentar el tiempo efectivo conforme crece el número de nodos.
Este parámetro ha recibido especial atención recientemente porque Proxmox VE 9.2 utiliza un coeficiente explícito de 125 ms al crear nuevos clusters, frente al comportamiento histórico asociado a 650 ms cuando no se establece expresamente.
El cambio resulta especialmente apreciable en clusters grandes, aunque una instalación actualizada desde versiones anteriores puede conservar su configuración existente. Por eso resulta más fiable consultar los valores efectivos que deducirlos a partir de la versión instalada.
Puede hacerse con:
corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'Estos temporizadores merecen revisión en infraestructuras grandes, pero Corosync es mucho más que token y consensus. Centrarse únicamente en esos números puede hacer perder de vista su función principal: mantener una visión coherente del cluster.
Qué relación tiene Corosync con Proxmox HA
Corosync tampoco es el sistema de alta disponibilidad de Proxmox.
Proporciona una parte de la información que necesita HA para funcionar.
Cuando una máquina virtual se configura como recurso HA, Proxmox HA Manager supervisa dónde debería ejecutarse y puede reaccionar ante determinados fallos.
Si un host desaparece abruptamente, el proceso conceptual incluye varias etapas:
- Se produce la pérdida del nodo o de su conectividad.
- Corosync detecta el cambio.
- Los miembros supervivientes establecen una nueva membresía.
- Se determina si existe quorum.
- Los mecanismos de fencing aseguran que el nodo problemático no pueda provocar conflictos.
- HA Manager puede recuperar los recursos protegidos en otros servidores.
Esto explica por qué HA no es lo mismo que Live Migration.
En una migración en vivo el servidor origen continúa funcionando y participa activamente en el movimiento de la máquina virtual.
Durante una avería abrupta el host original puede haber desaparecido completamente. La VM tendrá que recuperarse en otro nodo y volver a arrancar.
Watchdog y fencing
Proxmox utiliza un watchdog dentro de su arquitectura HA.
Si un nodo pierde quorum y deja de poder mantener correctamente el watchdog, este puede terminar provocando su reinicio. Proxmox documenta aproximadamente 60 segundos para este mecanismo de self-fencing.
La lógica es conservadora.
Antes de permitir que otro servidor recupere determinados recursos interesa asegurarse de que el nodo aislado no continúa utilizándolos.
El fencing busca precisamente evitar que dos hosts actúen simultáneamente como propietarios del mismo recurso.
Esto también explica la relación entre los temporizadores de Corosync y el watchdog. Proxmox recomienda mantener suficiente margen para que pueda establecerse una nueva membresía antes de alcanzar el límite de fencing.
La red de Corosync merece un diseño propio
Una de las particularidades de Corosync es que no necesita necesariamente mucho ancho de banda, pero sí necesita una red estable y con baja latencia.
Esta diferencia resulta importante.
Una interfaz de 1 Gbit/s estable puede resultar perfectamente adecuada para determinadas instalaciones, mientras que una conexión de 25 Gbit/s saturada simultáneamente por Ceph, migraciones y backups puede ofrecer peores condiciones para el tráfico del cluster.
La documentación de Proxmox recomienda prestar especial atención a esta red y permite configurar múltiples enlaces mediante Kronosnet.
En una instalación empresarial conviene revisar:
- latencia entre nodos;
- pérdida de paquetes;
- jitter;
- redundancia de interfaces;
- redundancia de switching;
- MTU consistente;
- congestión;
- separación respecto a tráfico intensivo;
- caminos físicos realmente independientes.
Esto cobra todavía más importancia cuando Proxmox comparte infraestructura con Ceph.
Ceph puede generar grandes cantidades de tráfico durante recuperación, rebalanceo o reconstrucción. Una incidencia puede ser precisamente el momento en el que más necesita comunicarse Corosync y, simultáneamente, más tráfico genera el almacenamiento.
Diseñar ambas redes sin considerar ese escenario degradado es una fuente potencial de problemas.
Corosync no es Ceph
La presencia de ambos componentes en muchas instalaciones Proxmox puede provocar otra confusión.
Corosync mantiene la coordinación del cluster Proxmox.
Ceph proporciona almacenamiento distribuido.
Una instalación puede utilizar Corosync sin Ceph. Por ejemplo, un cluster Proxmox puede disponer de almacenamiento compartido mediante NFS, iSCSI, Fibre Channel u otras arquitecturas.
También puede utilizar Ceph, pero entonces aparecen dos sistemas distribuidos diferentes, cada uno con sus propios mecanismos, redes y temporizadores.
Que Corosync tenga quorum no significa automáticamente que Ceph esté sano. Y que Ceph mantenga suficientes réplicas tampoco significa que Proxmox conserve quorum.
Qué debería conocer un administrador de Proxmox sobre Corosync
No es necesario memorizar cada parámetro de corosync.conf para operar correctamente una infraestructura Proxmox.
Sí conviene tener claras algunas preguntas.
| Pregunta | Qué permite saber |
|---|---|
| ¿Cuántos votos existen? | Cómo se obtiene quorum |
| ¿Qué ocurre al perder un nodo? | Tolerancia real del cluster |
| ¿Existe QDevice? | Cómo se resuelve el quorum en diseños pequeños |
| ¿Qué enlaces usa Corosync? | Redundancia de comunicaciones |
| ¿Comparten red Corosync y Ceph? | Riesgo de congestión |
¿Cuáles son token y consensus? | Temporizadores efectivos |
| ¿Existe HA? | Qué cargas pueden recuperarse automáticamente |
| ¿Qué watchdog se utiliza? | Mecanismo de fencing |
| ¿Existe capacidad N+1? | Si las VMs realmente podrán recuperarse |
La última cuestión queda fuera de Corosync, pero es probablemente una de las más importantes.
Un cluster puede tener quorum perfecto, Corosync perfectamente configurado y una red completamente redundante, pero seguir sin ofrecer una HA útil si los nodos supervivientes no disponen de CPU y RAM para recuperar las máquinas del servidor perdido.
Tampoco el backup forma parte de Corosync.
La alta disponibilidad busca reducir la interrupción causada por determinados fallos de infraestructura. Las copias de seguridad permiten recuperar información después de corrupción, ransomware, borrados accidentales y otros escenarios diferentes.
Comprender estas fronteras ayuda a situar Corosync donde corresponde. Es la capa que permite a los miembros de Proxmox mantener una visión común de quién sigue dentro del cluster y quién puede tomar decisiones.
Normalmente permanece silenciosa. Precisamente por eso conviene conocerla antes de que llegue el día en el que uno de los servidores deje de responder.
Preguntas frecuentes
¿Qué es Corosync en Proxmox?
Corosync es el sistema utilizado por Proxmox VE para proporcionar comunicación, membresía y servicios relacionados con quorum entre los nodos de un cluster. Permite mantener una visión coherente de qué servidores siguen formando parte de la infraestructura.
¿Proxmox puede funcionar sin Corosync?
Un servidor Proxmox VE independiente no necesita formar un cluster. Cuando varios nodos se integran mediante las funciones de clustering de Proxmox, Corosync forma parte de esa arquitectura.
¿Corosync proporciona alta disponibilidad?
No por sí solo. Corosync proporciona comunicación, membresía y quorum. Proxmox HA Manager, el watchdog, el almacenamiento y la capacidad disponible en los nodos forman parte del diseño necesario para recuperar cargas automáticamente.
¿Corosync necesita una red dedicada?
Proxmox recomienda prestar especial atención a su red y evitar que tráfico sensible de Corosync compita con cargas intensivas. Más que un enorme ancho de banda, necesita baja latencia, estabilidad y una redundancia correctamente diseñada.
