Problema

En entornos HA con Proxmox es frecuente que, además de máquinas Linux, haya que alojar servidores Windows que dependen de un disco compartido. Ese disco suele estar expuesto mediante Fibre Channel (FC) y es usado por una aplicación que sincroniza datos entre varios nodos Windows. Cuando el cluster Proxmox solo cuenta con Ceph y sin un fabric FC, el reto es reproducir ese modelo de “shared block” sin romper la lógica de bloqueo de la aplicación y sin perder la alta disponibilidad.

El patrón que se repite es: varias VMs Windows necesitan acceder simultáneamente a un mismo bloque de datos, con coordinación de locks a nivel de archivo. La solución debe:

  1. Proveer un bloque que pueda ser presentado a varios hosts Windows simultáneamente.
  2. Mantener la consistencia de los locks gestionados por la aplicación.
  3. Integrarse con la infraestructura de almacenamiento existente (Ceph) y con el plano de alta disponibilidad de Proxmox.

Causa

Los bloqueos fallan cuando el almacenamiento se presenta como discos independientes (por ejemplo, RBD mapeado individualmente a cada VM). Cada VM ve su propio copy‑on‑write y la aplicación pierde la capacidad de sincronizar. Las causas típicas son:

  • Uso de discos virtuales tradicionales (qcow2, raw) en modo “passthrough”: cada VM tiene su propio contenedor, no hay un medio compartido real.
  • Exposición de Ceph como archivos (NFS/SMB) sin soporte de SCSI‑2 persistent reservations: la capa de archivos no transporta los locks de bloque que la aplicación espera.
  • Falta de un target iSCSI/FC que admita múltiples initiators con PR (Persistent Reservations): sin PR, Windows no puede coordinar el acceso exclusivo a regiones del disco.

En la práctica, la mayoría de los fallos provienen de intentar emular FC con una solución de nivel de archivo o de bloquear un RBD a una sola VM.

Solución

La estrategia más robusta es exponer un RBD de Ceph como LUN iSCSI y permitir que varios hosts Windows lo monten simultáneamente. iSCSI soporta Persistent Reservations, que Windows utiliza para los bloqueos de nivel de bloque. Proxmox incluye targetcli (o tgt) para crear un target iSCSI y mapear el RBD. El flujo general es:

  1. Crear un RBD dedicado con tamaño suficiente y con features=layering desactivado (para evitar copy‑on‑write que rompe los locks).
  2. Configurar un iSCSI target en uno de los nodos Proxmox (o en un nodo dedicado de storage). Asociar el RBD como LUN.
  3. Habilitar CHAP opcional para seguridad.
  4. Conectar los hosts Windows como initiators al target. En Windows, usar el “iSCSI Initiator” y marcar la opción “Enable multi‑path” si se usan varios nodos Proxmox.
  5. Inicializar el disco en Windows (crear volumen, asignar letra). La aplicación seguirá funcionando porque los locks se gestionan a nivel de SCSI.

Alternativas prácticas

  • SMB 3.0 con Continuous Availability: Si la aplicación solo necesita locks de archivo y no de bloque, un share SMB en un nodo Proxmox (usando samba con vfs objects = shadow_copy2) puede ser suficiente. No obstante, la mayoría de las aplicaciones que usan “folder lock” en FC esperan PR, por lo que iSCSI sigue siendo la opción más segura.
  • FC over Ethernet (FCoE) con OpenFabrics: Viable solo si la infraestructura de red ya soporta FCoE y los switches están configurados. Requiere hardware adicional y no es tan sencillo de desplegar en un cluster Proxmox típico.

Cuándo aplicar esta solución

Aplicable cuando:

  • Necesitas que más de una VM Windows acceda al mismo bloque simultáneamente.
  • La aplicación depende de SCSI Persistent Reservations (bloqueos a nivel de disco).
  • Ya dispones de un cluster Ceph y prefieres reutilizarlo en vez de comprar hardware FC.
  • El entorno Proxmox está configurado para HA y quieres que el LUN siga disponible aunque falle un nodo.

No aplicable si:

  • La aplicación solo usa locks de archivo y puede migrarse a un share SMB sin cambios.
  • No puedes abrir puertos iSCSI (3260) en la red o la política de seguridad lo prohíbe.
  • El rendimiento requerido supera lo que ofrece Ceph sobre la red actual (latencia excesiva).

Código

# 1. Crear el RBD (ejemplo: 200 GB, sin layering)
rbd create shared-ws-lun --size 200G --pool rbd --image-format 2 --features ''

# 2. Asignar permisos al usuario ceph para el pool (si aún no existen)
ceph auth get-or-create client.iscsi mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=rbd'

# 3. Instalar targetcli (en nodo que actuará como iSCSI gateway)
apt-get update && apt-get install -y targetcli-fb

# 4. Configurar iSCSI target y mapear el RBD
targetcli /backstores/rbd create shared-ws-lun rbd shared-ws-lun
targetcli /iscsi create iqn.2026-06.com.example:proxmox-iscsi
targetcli /iscsi/iqn.2026-06.com.example:proxmox-iscsi/tpg1/luns create /backstores/rbd/shared-ws-lun
# Opcional: habilitar CHAP
targetcli /iscsi/iqn.2026-06.com.example:proxmox-iscsi/tpg1 set attribute authentication=1
targetcli /iscsi/iqn.2026-06.com.example:proxmox-iscsi/tpg1/acls create iqn.2026-06.com.example:windows-initiator
targetcli saveconfig

Verificación

  1. En cada VM Windows, abre iSCSI Initiator, agrega el portal con la IP del nodo Proxmox y descubre el target iqn.2026-06.com.example:proxmox-iscsi.
  2. Conecta el LUN y verifica que aparece en Disk Management como un disco sin formato.
  3. Crea un volumen simple (NTFS) y asigna la letra D:. Reinicia la VM y confirma que el disco persiste.
  4. Desde la consola de Windows, ejecuta iscsicli PersistentReservationInfo para asegurarte de que el disco tiene una reserva activa.
  5. Simula la caída de un nodo Proxmox (detén el servicio target o desconecta la red) y verifica que los demás nodos siguen accediendo al LUN sin errores.

Notas adicionales

  • Multipath I/O (MPIO): Si el target está disponible en varios nodos Proxmox, habilita MPIO en Windows para balancear la carga y evitar un único punto de fallo.
  • Snapshots: Ceph permite snapshots de RBD, pero no son compatibles con discos iSCSI en uso. Programa snapshots cuando el LUN esté offline o usa freeze a nivel de aplicación.
  • Performance tuning: Ajusta el osd_pool_default_crush_rule y los pg_num del pool RBD para evitar cuellos de botella. En redes de 10 GbE la latencia típica es <1 ms, suficiente para la mayoría de aplicaciones de sincronización de archivos.
  • Backup: Usa vzdump con la opción --mode snapshot para respaldar la VM Windows, pero ten en cuenta que el LUN iSCSI no se incluye en el backup de la VM; deberás respaldar el RBD por separado (rbd export o rbd snap + rbd export-diff).

Con esta configuración, los servidores Windows pueden seguir usando su modelo de carpeta compartida como si fuera un volumen FC, mientras el cluster Proxmox mantiene la alta disponibilidad y la flexibilidad de Ceph.