Tres servidores rack HPE como clúster Proxmox: planificar la reserva

Tres servidores rack HPE no forman por sí solos un clúster Proxmox resistente. El objetivo se puede comprobar cuando, tras fallar un nodo, quedan cálculo, memoria, datos VM accesibles, red y vías de alimentación suficientes. Este ejemplo muestra las decisiones necesarias para un clúster Proxmox VE con tres HPE ProLiant DL360 Gen11.

El artículo describe un perfil de dimensionamiento hipotético, no una referencia de pedido HPE ya definida. Por nodo se suponen una CPU de 24 núcleos, 256 GiB de RAM ECC, medios de arranque en espejo, cuatro SSD SAS empresariales de 3,84 TB cada uno para datos VM, dos fuentes redundantes y conexiones de red adecuadas de 25 Gbit. HPE ofrece el DL360 Gen11 con opciones de CPU, DIMM, unidades, red y alimentación. La aprobación de esta combinación precisa de CPU, backplane, modo HBA/JBOD, tipo de SSD, ventiladores, NIC, cables y firmware requiere una lista de materiales y revisión de compatibilidad confirmadas por el socio HPE. Los discos OSD de Ceph no deben quedar ocultos tras un RAID hardware inadecuado.

¿Basta la reserva tras fallar un host?

Tres nodos ofrecen 72 núcleos físicos y 768 GiB de RAM bruta. Si uno falla quedan 48 núcleos y 512 GiB. En el ejemplo reservamos en cada host restante cuatro núcleos y 32 GiB para Proxmox, Ceph y picos operativos. Para las VM quedan, según el cálculo, 40 equivalentes de núcleo y 448 GiB de RAM. Un pico medido de 28 equivalentes de núcleo y 300 GiB de RAM VM dejaría en este modelo un margen de 12 equivalentes y 148 GiB. El número de vCPU por sí solo no es una medición: CPU steal, NUMA, I/O, ocupación RAM y distribución de VM grandes deben medirse en el piloto. El tiempo de reinicio necesario y la prioridad de aplicaciones también forman parte de la aceptación.

Para un quórum fiable en alta disponibilidad, Proxmox requiere al menos tres votos. Con tres nodos de igual peso, al perder uno quedan dos votos y, por tanto, mayoría. Eso todavía no garantiza reiniciar una VM: los datos deben estar accesibles, el host de destino necesita recursos y las reglas HA deben encajar. Corosync requiere latencia baja y estable y una segunda vía independiente. Un switch compartido averiado o una PDU común anula la redundancia de hosts prevista.

SSD locales: ¿qué datos siguen disponibles tras un fallo?

En este ejemplo, los doce SSD locales forman un pool Ceph con tres copias y el host como dominio de fallo. La capacidad bruta es 3 × 4 × 3,84 = 46,08 TB . Tres copias reducen la capacidad útil teórica, antes de metadatos y reservas, a 15,36 TB. Con un límite fijado solo para la planificación del 70 %, resulta un valor de trabajo de unos 10,75 TB. No es capacidad Ceph garantizada: llenado OSD, distribución, recuperación, snapshots y patrones reales de datos deben medirse.

Si falla uno de los tres hosts, las dos copias restantes pueden seguir atendiendo I/O con una regla min_size configurada adecuadamente; el pool queda degradado. Solo puede restaurarse una tercera copia en un tercer dominio de fallo host cuando vuelve el nodo o se sustituye. Es un límite de un diseño de exactamente tres nodos. La réplica Ceph tampoco sustituye una copia de seguridad independiente. Proxmox Backup Server debe quedar fuera de estos tres hosts, en su propio dominio de fallo, con restauración probada y una copia externa adicional. El artículo DAXS Proxmox Backup Server: verificación, retención y restauración profundiza en la prueba de recuperación.

Red y alimentación forman parte de la arquitectura

Para Ceph importan ancho de banda y baja latencia; para un clúster nuevo planteamos vías separadas de 25 Gbit, conectadas de forma redundante, como hipótesis inicial verificable. La velocidad necesaria depende de carga de escritura, tráfico de réplica y tiempo objetivo de recuperación, no del número de puertos de la ficha técnica. Corosync debe ir por caminos físicos independientes; gestión y tráfico VM se separan o limitan adecuadamente. La asignación exacta de VLAN, switches y NIC se documenta en un plan de puertos.

Dos fuentes de servidor ayudan solo si usan vías eléctricas separadas. DAXS haría conectar en cada host la fuente A a PDU/SAI A y la B a PDU/SAI B, comprobar consumo bajo carga y probar la pérdida de una vía. Gestión iLO, SSD de repuesto, mantenimiento de firmware y ventanas de intervención son otros costes operativos. Tres servidores en el mismo rack no protegen del fallo de toda la sala.

Cálculo abierto a tres y cinco años

Sea una oferta HPE actualmente confirmada para el nodo completo de h euros, la red redundante con ópticas de n, y un servidor independiente de copias con medios de k. Servicio HPE y repuestos cuestan en el modelo s euros anuales, electricidad y housing e euros anuales. Estos importes de oferta no se inventan. Los precios de lista publicados de Proxmox son 550 € anuales por socket VE ocupado y 2.240 € por servidor PBS Standard: aquí 3 × 550 + 2.240 = 3.890 € al año. Se suponen una vez 80 horas a 90 € (7.200 €) para montaje, pruebas y entrega; cada año, 50 horas a 90 € (4.500 €) para operación.

La sensibilidad se ve directamente: 1.000 € más por nodo elevan ambos horizontes en 3.000 €; 1.000 € más de servicio HPE anual suman 3.000 o 5.000 €. Si cada host necesita una segunda CPU ocupada, al mismo nivel Proxmox Standard solo las suscripciones añaden 1.650 € al año, más hardware, RAM y energía. El cálculo excluye migración desde VMware, segunda ubicación de copias y subidas de precios; deben añadirse para la decisión concreta.

DAXS comprueba primero picos de carga y objetivos ante fallos, después lista HPE aprobada, plan de puertos y alimentación, restauración Ceph y de copias y ofertas completas. Para planificar un clúster así en su entorno, utilice Contacto para iniciar la conversación.

Fuentes: HPE ProLiant DL360 Gen11 QuickSpecs · Proxmox VE Administration Guide: clúster, HA y Ceph · Ceph: número de copias y min_size · Proxmox VE: precios de suscripción · Proxmox Backup Server: precios.