Arquitectura y Despliegue de un Clúster Ceph para Almacenamiento Hiperconvergente

La evolución hacia infraestructuras hiperconvergentes (HCI) exige soluciones de almacenamiento distribuido que eliminen puntos únicos de fallo y escalen horizontalmente sin fricción. En este contexto, Ceph se consolida como el estándar de facto para almacenamiento unificado (bloque, objeto y archivo) en arquitecturas cloud-native y despliegues de OpenStack o Kubernetes.

En este artículo, desde el Equipo de Ingeniería de ForgeNEX, abordaremos el despliegue técnico de un clúster Ceph utilizando cephadm, enfocándonos en las mejores prácticas de red y optimización del motor BlueStore.

Topología de Red y Requisitos de Hardware#

Para garantizar operaciones de baja latencia y alta disponibilidad, Ceph requiere una segregación estricta a nivel de red. Nunca se debe mezclar el tráfico de replicación interna con el tráfico de los clientes.

Segmentación de Tráfico

Una arquitectura enterprise mínima requiere dos interfaces de red bondings (LACP) por nodo:

1. Public Network: Maneja las peticiones de los clientes (RBD, CephFS, RGW) y la comunicación entre los Monitores (MON).
2. Cluster Network (Replication): Red de backend dedicada exclusivamente al tráfico de replicación, rebalanceo y heartbeats entre los Object Storage Daemons (OSD).

Nota Importante: Recomendamos encarecidamente utilizar switches de 25GbE o 100GbE Non-Blocking para la Cluster Network, configurando Jumbo Frames (MTU 9000) para minimizar el overhead de la CPU durante las operaciones de replicación.

Despliegue Automatizado con Cephadm#

A partir de la versión Octopus, cephadm es el orquestador oficial, integrando contenedores (Podman/Docker) y systemd para aislar los daemons sin depender de herramientas externas como Ansible, aunque puede integrarse con ellas.

Bootstrapping del Monitor Inicial

El primer paso es inicializar el clúster en el primer nodo (que actuará como MON y MGR). Necesitaremos definir explícitamente el rango de red público y de clúster.

# Instalación de dependencias y binario base
apt-get install -y cephadm
cephadm add-repo --release reef
cephadm install

# Bootstrapping del clúster definiendo la red de frontend y backend
cephadm bootstrap --mon-ip 10.10.10.11 \
                  --initial-dashboard-password 'ForgeNEX2026!secure' \
                  --cluster-network 10.10.20.0/24 \
                  --allow-fqdn-hostname

Este comando genera automáticamente las claves SSH, los keyrings de administración (/etc/ceph/ceph.client.admin.keyring) e instancia los contenedores base.

Adición de Nodos y Provisión de OSDs

Una vez bootstrapeado, copiamos la clave SSH pública del clúster a los nuevos nodos (HCI-02, HCI-03) y los integramos usando la CLI de ceph:

# Copiar clave SSH (ejecutar desde el nodo inicial)
ssh-copy-id -f -i /etc/ceph/ceph.pub root@hci-02
ssh-copy-id -f -i /etc/ceph/ceph.pub root@hci-03

# Añadir nodos al orquestador con sus respectivos labels
ceph orch host add hci-02 10.10.10.12 --labels _admin,_mon
ceph orch host add hci-03 10.10.10.13 --labels _mon

Para aprovisionar los OSDs (discos físicos), podemos aplicar una especificación declarativa en YAML que busque dispositivos NVMe libres, ignorando automáticamente los discos de sistema.

# osd_spec.yml
service_type: osd
service_id: nvme_pool
placement:
  host_pattern: '*'
spec:
  data_devices:
    rotational: 0
    size: '>=1TB'
  encrypted: true

Aplicamos la configuración declarativa:

ceph orch apply -i osd_spec.yml

Optimización de Rendimiento (BlueStore y WAL/DB)#

El backend de almacenamiento BlueStore gestiona los discos en crudo (raw block devices) evadiendo el sistema de archivos tradicional (como XFS o ext4), lo que reduce drásticamente la penalización de escritura (write amplification).

Si nuestra infraestructura HCI combina discos mecánicos (HDD) para capacidad y NVMe para caching (tiering híbrido), es crítico separar la partición Block.DB (metadatos de RocksDB) y el WAL (Write-Ahead Log) hacia los discos de estado sólido (NVMe o SSD).

# osd_hybrid_spec.yml
service_type: osd
service_id: hybrid_tier
placement:
  host_pattern: '*'
spec:
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0
  wal_devices:
    rotational: 0

Nota Importante: El tamaño de la partición de db_devices no debería ser inferior al 4% del tamaño total de los data_devices. Si la base de datos de metadatos desborda el NVMe (spillover), el rendimiento caerá de forma pronunciada al escribirse en los HDDs lentos.

Conclusión#

Desplegar Ceph mediante cephadm en un modelo de nube privada o hiperconvergente aporta una robustez y resiliencia sin precedentes. Mediante una topología de red aislada, políticas declarativas de placement de orquestación, y aprovechando la potencia pura del hardware NVMe para los metadatos BlueStore (WAL/DB), podemos garantizar operaciones IOPS masivas para bases de datos críticas, mientras mantenemos un almacenamiento por bloques o de objetos altamente escalable para el entorno corporativo.