Categoría: Virtualización
Proxmox VE gestionado: clústeres de virtualización con alta disponibilidad
Vuestras máquinas virtuales y contenedores en un clúster que conmuta solo si cae un nodo, con el almacenamiento bien elegido, actualizaciones nodo a nodo.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source, AGPLv3 (suscripción opcional)
En resumen
Proxmox VE es una plataforma de virtualización de código abierto que reúne máquinas virtuales KVM, contenedores LXC, almacenamiento y alta disponibilidad en una sola interfaz. Montamos y operamos clústeres en vuestros servidores o en dedicados de un proveedor: red, ZFS o Ceph, alta disponibilidad, copias, monitorización y actualizaciones. También migramos máquinas desde VMware.
¿Qué nos encargamos de mantener?
Proxmox VE se instala desde una imagen en poco tiempo y puede funcionar mucho sin que nadie lo toque. Los problemas llegan con el primer nodo caído sin quórum, un pool de ZFS al noventa por ciento o una actualización mayor hecha con prisa. Esto es lo que dejamos bajo control:
Nodos
Instalación, red, firmware y paquetes al día en cada servidor del clúster.
Clúster y HA
Corosync con quórum, grupos de alta disponibilidad y conmutación probada.
Almacenamiento
ZFS con réplica o Ceph, espacio vigilado y discos revisados con SMART.
Copias
Proxmox Backup Server o vzdump a otro sitio, con restauraciones de prueba.
Métricas
Estado del clúster, uso por máquina, ZFS o Ceph y alertas útiles.
Accesos
Interfaz solo por VPN, doble factor, usuarios nominales y permisos por grupo.
¿Qué arquitectura recomendamos?
La alta disponibilidad de Proxmox VE depende del quórum: más de la mitad de los votos del clúster tienen que estar de acuerdo para que un nodo arranque las máquinas de otro. Por eso partimos de tres nodos, o de dos y un dispositivo de quórum externo. El tráfico de Corosync va por una red propia, porque si se satura con copias o con Ceph, los nodos se creen aislados y se reinician.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Un solo servidor | ZFS en espejo y copias a Proxmox Backup Server fuera | Sin alta disponibilidad, pero con recuperación probada |
| Dos o tres nodos con disco local | ZFS en cada nodo con replicación programada y HA | Sencillo; al conmutar se pierden los minutos desde la última réplica |
| Tres nodos o más con red de 10 Gbit/s o superior | Ceph con varios discos por nodo | Almacenamiento compartido, conmutación sin pérdida de datos |
| Cabina de discos ya existente | iSCSI o NFS compartido | Aprovecha lo que tenéis; la cabina pasa a ser el punto único |
Una réplica de ZFS o la redundancia de Ceph no sustituyen a la copia: si alguien borra una máquina o un ransomware cifra sus discos, el daño se replica. Las copias van siempre a otra máquina, y mejor a otro sitio.
¿Qué problemas encontramos más a menudo?
- Dos nodos sin dispositivo de quórum: la alta disponibilidad no actúa, o el nodo superviviente se queda bloqueado.
- Pool de ZFS sin vigilar: se llena y las máquinas dejan de poder escribir.
- Corosync compartiendo red con las copias: reinicios de nodos en mitad de la noche sin causa aparente.
- Copias en el mismo clúster: el almacenamiento de las copias es un disco de uno de los nodos.
- Interfaz web abierta a internet con el usuario root y sin doble factor.
- Actualización mayor sin preparar: se salta el script de comprobación y una máquina no vuelve a arrancar.
¿Cómo hacemos las actualizaciones?
Las actualizaciones menores las aplicamos nodo a nodo: migramos en vivo las máquinas a otro nodo, actualizamos, reiniciamos si hace falta y las devolvemos. El clúster sigue dando servicio durante todo el proceso. Para una versión mayor, leemos las notas, ejecutamos la herramienta de comprobación que publica Proxmox para cada salto de versión, corregimos lo que señala y hacemos una copia reciente de todas las máquinas antes de empezar. Si usáis Ceph, su actualización sigue su propio orden y la hacemos antes o después según indique la guía.
¿Para quién tiene sentido?
- Una empresa con VMware que busca una alternativa tras el cambio de licencias y quiere conservar sus máquinas virtuales.
- Un equipo con servidores propios en la oficina o en un centro de datos que necesita alta disponibilidad sin pagar licencias por procesador.
- Quien quiere máquinas virtuales en servidores dedicados, por coste o por control, con alguien que responda del clúster.
Las copias de este clúster las solemos llevar a un Proxmox Backup Server gestionado, y las métricas a la monitorización con Grafana y Prometheus.
¿Cómo es una migración desde VMware?
Empezamos con un inventario: máquinas, sistemas operativos, discos, redes y dependencias entre ellas. Montamos el clúster de Proxmox VE en paralelo y usamos su asistente de importación, que se conecta al host ESXi y trae cada máquina con su configuración. En las máquinas Windows instalamos antes los controladores VirtIO; en todas revisamos tarjetas de red, arranque UEFI o BIOS y agente invitado. Migramos primero máquinas poco críticas, después las importantes en ventanas pactadas, y el entorno de VMware se queda encendido hasta que todo funciona. Si la migración forma parte de un cambio mayor de proveedor, la planificamos dentro de las migraciones y costes cloud.
- Acceso remotoVPN y doble factor
- Proxmox VETres nodos en clúster
- Alta disponibilidadQuórum con Corosync
- AlmacenamientoZFS con réplica o Ceph
- Proxmox Backup ServerCopias fuera del clúster
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores dedicados con Proxmox VE, red privada entre ellos con vSwitch e IP adicionales o subred para las máquinas virtuales. | En la red pública de un dedicado no vale cualquier configuración de MAC; preparamos el enrutado o el NAT según lo que contratéis. |
| OVH | Servidores dedicados con Proxmox VE, red privada entre nodos y IP adicionales para las máquinas virtuales. | |
| Servidor propio | Proxmox VE en vuestros servidores físicos, en vuestra oficina o en un centro de datos, con gestión por VPN. | Para alta disponibilidad real hace falta un tercer voto: un tercer nodo o un dispositivo de quórum en otra máquina. |
Qué incluye
- Clúster de Proxmox VE con tres nodos o dos más un dispositivo de quórum, en vuestro hardware o en servidores dedicados.
- Red separada para gestión, tráfico del clúster, almacenamiento y máquinas virtuales, con VLAN o puentes según el caso.
- Almacenamiento con ZFS y replicación entre nodos, o Ceph cuando hay tres nodos o más y red rápida.
- Alta disponibilidad configurada para las máquinas críticas, con la conmutación probada apagando un nodo.
- Copias con Proxmox Backup Server o con vzdump a un destino externo, y restauración de prueba periódica.
- Métricas del clúster, de ZFS o Ceph y de los discos, con alertas de quórum, espacio, SMART y copias fallidas.
- Actualizaciones menores y mayores nodo a nodo, migrando antes las máquinas en vivo.
- Interfaz web sin exponer a internet, doble factor, usuarios nominales y migración desde VMware ESXi.
Preguntas frecuentes
¿Podemos migrar nuestras máquinas desde VMware ESXi?
Sí. Proxmox VE incluye un asistente de importación que se conecta a un host ESXi como si fuera un almacenamiento y trae las máquinas con su configuración; Proxmox indica que está probado desde ESXi 6.5 hasta 8.0. Para casos que el asistente no cubre, usamos la importación de OVF. En Windows revisamos los controladores VirtIO y el tipo de disco, y en todas la red y el arranque.
¿Hace falta pagar la suscripción de Proxmox?
No es obligatoria. Proxmox VE es código abierto y se actualiza también desde el repositorio sin suscripción. La suscripción da acceso al repositorio enterprise y al soporte del fabricante. Para producción solemos recomendarla; la decisión es vuestra y os la explicamos antes de empezar.
¿ZFS o Ceph?
ZFS con replicación entre nodos es más sencillo y basta para muchos clústeres pequeños, a cambio de perder los minutos de datos desde la última réplica si un nodo cae. Ceph reparte los discos entre todos los nodos y no pierde datos al conmutar, pero pide al menos tres nodos, varios discos por nodo y una red dedicada rápida.
¿Funciona con dos servidores?
Con dos nodos solos no: si uno cae, el otro pierde el quórum y no arranca nada por su cuenta. Se resuelve con un dispositivo de quórum externo, que puede ser una máquina pequeña o un servidor virtual en otra ubicación, o con un tercer nodo.
¿Cómo lo gestionáis si los servidores están en nuestra oficina?
Por una VPN que solo abre el acceso de gestión. Si el hardware lo permite, configuramos también la consola fuera de banda del servidor para poder entrar aunque el sistema no arranque.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
- Proxmox VE Administration Guide: Cluster Manager
- Proxmox VE Wiki: Migrate to Proxmox VE
- Proxmox VE Administration Guide: Deploy Hyper-Converged Ceph Cluster
- Hetzner Docs: Error FAQ (MAC errors)
Revisado el