← Tornar al blog

Proxmox + Ceph + PBS: Guia Completa per a un Homelab Production-Ready

Per què Proxmox + Ceph per a un homelab

Proxmox VE és l’alternativa open source seriosa a VMware/ESXi. Hypervisor enterprise-grade, sense cost de llicència, amb una interfície web que no fa vergonya. Però on realment brilla és quan hi sumes Ceph.

Ceph integrat a Proxmox et dona storage distribuït sense necessitat d’un NAS o SAN extern. Els teus discos locals es converteixen en un pool d’emmagatzematge unificat que les VMs consumeixen com si fos un SAN enterprise. I el millor: pots separar discos ràpids (SSD) de discos de capacitat (HDD) en pools diferents, cadascun amb les seves pròpies regles de replicació.

Afegeix Proxmox Backup Server i tens el triangle complet: virtualització, storage tiered, i backups amb deduplicació — tot en una plataforma, tot open source.

Aquest setup funciona igual amb 1 node que amb 3+. L’arquitectura escala sense redissenyar res. Les mateixes CRUSH rules, els mateixos pools, els mateixos jobs de backup. Quan afegeixes nodes, Ceph distribueix les dades automàticament.

Hardware i planificació

El que necessites:

  • CPU amb VT-x/VT-d — qualsevol processador modern de servidor o desktop el té. VT-d és important si planifiques fer PCI passthrough (GPUs, controladors de xarxa, etc.)
  • RAM: 32GB mínim, 64GB recomanat — Proxmox consumeix poc, però les VMs i els OSDs de Ceph sumen. Cada OSD reserva ~1GB de RAM per defecte. Amb 4 OSDs ja són 4GB només per a Ceph.
  • Discos dedicats per a Ceph — aquesta és la decisió més important

La planificació de discos:

DiscÚsExemple
SSD/NVMe petit (128-256GB)Sistema operatiu ProxmoxDisc de boot
SSD/NVMe dedicatsOSDs per al pool ràpidVMs, bases de dades
HDDs dedicatsOSDs per al pool bulkBackups, ISOs, templates

Per a la xarxa: en single-node, la xarxa estàndard de 1GbE és suficient perquè el tràfic de Ceph és local. En multi-node, una xarxa dedicada per a Ceph és pràcticament obligatòria — idealment 10GbE, o com a mínim una VLAN separada.

Disc de sistema ≠ OSD

No facis servir el disc de sistema com a OSD de Ceph. Sembla temptador per aprofitar espai, però quan Ceph s’omple (i s’omplirà), el sistema operatiu es queda sense espai i perds accés al node. El disc de sistema és sagrat — només per a Proxmox OS i configuració.

Instal·lació de Proxmox VE

Descarrega la ISO de Proxmox VE des del web oficial i instal·la al SSD/NVMe de sistema. La instal·lació és un wizard estàndard — selecciona disc, configura xarxa, contrasenya de root, i llest.

Post-instal·lació

Primer pas: ajustar els repositoris. Si no tens subscripció (i per a un homelab no la necessites), canvia al repo no-subscription:

# Eliminar repo enterprise (requiere suscripción)
rm /etc/apt/sources.list.d/pve-enterprise.list

# Añadir repo no-subscription
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > \
  /etc/apt/sources.list.d/pve-no-subscription.list

# Añadir repo de Ceph no-subscription
echo "deb http://download.proxmox.com/debian/ceph-squid bookworm no-subscription" > \
  /etc/apt/sources.list.d/ceph.list

# Actualizar
apt update && apt full-upgrade -y
Subscripció de Proxmox

Proxmox funciona perfectament sense subscripció. El repositori no-subscription és estable i rep actualitzacions regulars. La subscripció et dona accés al repo enterprise (mateixes versions però amb testing addicional abans de publicar) i suport tècnic. Per a un homelab, el repo no-subscription és més que suficient.

Verifica que el bridge de xarxa vmbr0 estigui configurat correctament. Proxmox el crea durant la instal·lació, però confirma que té la IP estàtica i el gateway correcte:

cat /etc/network/interfaces

Hauries de veure una cosa així:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Instal·lació i configuració de Ceph

Instal·lar Ceph

Des de la CLI del node Proxmox:

pveceph install

Això instal·la la versió de Ceph que Proxmox suporta nativament (Squid a PVE 8.x). La integració és completa — Proxmox gestiona la configuració, els serveis, i el monitoring de Ceph.

Inicialitzar el cluster de Ceph

# Inicializar Ceph con la red del cluster
pveceph init --network 192.168.1.0/24

# Crear el monitor (necesario para que Ceph funcione)
pveceph mon create

# Crear el manager (necesario para el dashboard y métricas)
pveceph mgr create

En multi-node crearies monitors i managers en múltiples nodes per alta disponibilitat. En single-node, un de cada és suficient.

Configuració per a single-node

Ceph per defecte espera 3 rèpliques de cada objecte, la qual cosa requereix 3 nodes. En single-node necessites ajustar això:

# Configurar Ceph para single-node
ceph config set global osd_pool_default_size 1
ceph config set global osd_pool_default_min_size 1
Sense redundància en single-node

Amb size 1, NO hi ha redundància de dades. Si un disc mor, perds el que hi havia en aquell OSD. Per això PBS és crític en aquest setup — els teus backups són la teva redundància. En multi-node amb size 2 o 3, Ceph replica les dades entre nodes automàticament i pots sobreviure a la pèrdua d’un disc o un node sencer.

Creant els OSDs — SSD i HDD per separat

Un OSD (Object Storage Daemon) és un procés de Ceph que gestiona un disc físic. Cada disc dedicat a Ceph es converteix en un OSD.

Ceph detecta automàticament el tipus de disc i li assigna una device class: ssd, hdd, o nvme. Aquesta classificació és la base per separar l’emmagatzematge en pools per rendiment.

Crear els OSDs

Des de la CLI:

# Crear OSD para cada disco dedicado
pveceph osd create /dev/sdb    # SSD
pveceph osd create /dev/sdc    # SSD
pveceph osd create /dev/sdd    # HDD
pveceph osd create /dev/sde    # HDD

O des de la GUI: Ceph → OSD → Create OSD, selecciona el disc i Proxmox fa la resta.

Verificar les device classes

ceph osd tree
bash

$ ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 3.63689 root default -3 3.63689 host pve-node 0 ssd 0.46500 osd.0 up 1.00000 1.00000 1 ssd 0.46500 osd.1 up 1.00000 1.00000 2 hdd 1.81940 osd.2 up 1.00000 1.00000 3 hdd 0.88249 osd.3 up 1.00000 1.00000

Cada OSD ha de mostrar la seva classe correcta. Si Ceph no detecta bé la classe (rar, però passa amb alguns controladors RAID o discos darrere d’un HBA), pots forçar-la manualment:

# Forzar device class (primero hay que quitar la actual)
ceph osd crush rm-device-class osd.0
ceph osd crush set-device-class ssd osd.0

ceph osd crush rm-device-class osd.2
ceph osd crush set-device-class hdd osd.2

CRUSH Rules — Separar pools per tipus de disc

Aquesta és la part més important del setup i on molta gent es perd.

CRUSH (Controlled Replication Under Scalable Hashing) és l’algoritme que Ceph fa servir per decidir on emmagatzemar cada objecte. Les CRUSH rules li diuen a Ceph quins discos pot fer servir per a cada pool.

Per defecte, Ceph té una sola CRUSH rule (replicated_rule) que distribueix dades per tots els OSDs sense distingir tipus. Això significa que les teves dades de VM de producció podrien acabar en un HDD lent, i els teus backups en un SSD car. No volem això.

Crear CRUSH rules per device class

# Rule per a SSDs — només usa OSDs amb class 'ssd'
ceph osd crush rule create-replicated ssd-rule default host ssd

# Rule per a HDDs — només usa OSDs amb class 'hdd'
ceph osd crush rule create-replicated hdd-rule default host hdd

La sintaxi és: ceph osd crush rule create-replicated <nom> <root> <failure-domain> <device-class>

  • root: default — el node arrel del CRUSH map
  • failure-domain: host — Ceph distribueix rèpliques entre diferents hosts
  • device-class: ssd o hdd — només fa servir discos d’aquest tipus
Failure domain 'host' en single-node

El paràmetre host com a failure domain significa que Ceph intenta posar cada rèplica en un host diferent. En single-node això no aplica (només hi ha un host), però la rule funciona igual perquè tenim size 1. Quan afegeixis nodes al cluster i pugis el size a 2 o 3, la replicació entre hosts s’activa automàticament sense canviar res — la rule ja està preparada.

Verifica les rules creades:

ceph osd crush rule ls
bash

$ ceph osd crush rule ls replicated_rule ssd-rule hdd-rule

Creant els pools — SSD pool i HDD pool

Amb les CRUSH rules al seu lloc, ara creem els pools que realment fan servir aquestes rules.

Pool SSD — emmagatzematge ràpid

Per a discos de VMs, bases de dades, i qualsevol workload d’I/O intensiu:

# Crear pool SSD amb la CRUSH rule de SSDs
ceph osd pool create ssd-pool 64 replicated ssd-rule

# En single-node: sense rèplica
ceph osd pool set ssd-pool size 1
ceph osd pool set ssd-pool min_size 1

# Habilitar com a RBD (necessari perquè Proxmox el faci servir per a discos de VM)
ceph osd pool application enable ssd-pool rbd

Pool HDD — emmagatzematge bulk

Per a backups (disc de la VM de PBS), ISOs, templates, i emmagatzematge general:

# Crear pool HDD amb la CRUSH rule de HDDs
ceph osd pool create hdd-pool 64 replicated hdd-rule

# En single-node: sense rèplica
ceph osd pool set hdd-pool size 1
ceph osd pool set hdd-pool min_size 1

# Habilitar com a RBD
ceph osd pool application enable hdd-pool rbd

Calcular el nombre de PGs

El nombre de Placement Groups (PGs) afecta el rendiment i la distribució de dades. La fórmula general és:

PGs = (OSDs × 100) / mida de rèplica

Per a un setup petit (2-4 OSDs per pool, size 1): 64 PGs per pool és suficient. Per a setups més grans, 128 o 256. Proxmox té un autoscaler de PGs que ajusta això automàticament, però un valor inicial raonable evita warnings.

Afegir els pools com a storage a Proxmox

Des de la GUI: Datacenter → Storage → Add → RBD

Per al pool SSD:

  • ID: ceph-ssd
  • Pool: ssd-pool
  • Content: VM Disks, Containers

Per al pool HDD:

  • ID: ceph-hdd
  • Pool: hdd-pool
  • Content: VM Disks, Containers, ISO Images, Container Templates

O per CLI editant /etc/pve/storage.cfg:

rbd: ceph-ssd
    pool ssd-pool
    content images,rootdir
    krbd 0

rbd: ceph-hdd
    pool hdd-pool
    content images,rootdir,iso,vztmpl
    krbd 0

Proxmox Backup Server en VM

PBS com a VM dins del propi Proxmox és un compromís pragmàtic. No és ideal — el backup està al mateix maquinari que les dades — però és infinitament millor que no tenir backups. I per a un homelab, funciona.

Crear la VM de PBS

Descarrega la ISO de PBS des del web de Proxmox i crea una VM amb aquests specs:

  • CPU: 2 vCPUs
  • RAM: 2-4 GB (PBS és molt eficient)
  • Disc: 50-100GB al pool HDD (ceph-hdd) — els backups no necessiten emmagatzematge ràpid
  • Xarxa: bridge vmbr0, IP estàtica

Instal·la PBS normalment. És un wizard similar al de Proxmox — disc, xarxa, contrasenya, i llest.

Post-instal·lació de PBS

Accedeix a la interfície web de PBS (port 8007) i configura:

  1. Datastore: el disc virtual de la VM ja està muntat. Crea un datastore apuntant-hi.
  2. Verificació: habilita la verificació automàtica de backups — PBS pot verificar la integritat de cada backup després de crear-lo.

Integrar PBS amb Proxmox

Al node Proxmox, afegeix PBS com a storage:

Des de la GUI: Datacenter → Storage → Add → Proxmox Backup Server

  • ID: pbs
  • Server: IP de la VM de PBS
  • Username: root@pam
  • Password: la que vas configurar a PBS
  • Datastore: el nom del datastore que vas crear
  • Fingerprint: PBS el mostra a Dashboard → Show Fingerprint

O genera un API token a PBS per a autenticació sense password, que és el recomanat per a automatització.

Configurar jobs de backup

A Proxmox: Datacenter → Backup → Add

  • Storage: pbs
  • Schedule: daily per a VMs crítiques, weekly per a la resta
  • Selection: selecciona les VMs/CTs a incloure
  • Mode: Snapshot (no requereix apagar la VM)
  • Retention (pruning): configura quants backups mantenir

Un esquema de retenció raonable:

keep-daily: 7
keep-weekly: 4
keep-monthly: 3

Això manté els últims 7 backups diaris, 4 setmanals, i 3 mensuals. PBS aplica pruning automàticament després de cada backup.

Deduplicació de PBS

PBS fa servir deduplicació a nivell de bloc — els backups incrementals són extremadament eficients. Després del primer backup complet, els següents només transfereixen els blocs que van canviar. Una VM de 100GB que canvia 2GB al dia ocupa ~2GB per backup incremental, no 100GB. L’estalvi d’espai és brutal.

Verificació i monitorització

Amb tot muntat, verifica que el cluster està healthy.

Estat de Ceph

ceph status
bash

$ ceph status cluster: id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 health: HEALTH_OK

services: mon: 1 daemons, quorum pve-node (age 4d) mgr: pve-node(active, since 4d) osd: 4 osds: 4 up (since 4d), 4 in (since 2w)

data: pools: 2 pools, 128 pgs objects: 1.24k objects, 48 GiB usage: 52 GiB used, 3.58 TiB / 3.64 TiB avail pgs: 128 active+clean

L’important: HEALTH_OK, tots els OSDs up i in, i tots els PGs active+clean.

Verificar que els pools usin els discos correctes

ceph osd pool ls detail

Cada pool ha de mostrar la CRUSH rule corresponent. Busca crush_rule a la sortida — ha de coincidir amb ssd-rule o hdd-rule.

Ús d’espai per pool

ceph df
bash

$ ceph df --- RAW STORAGE --- CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 2.70 TiB 2.58 TiB 123 GiB 126 GiB 4.56 ssd 930 GiB 882 GiB 47 GiB 49 GiB 5.24 TOTAL 3.64 TiB 3.46 TiB 170 GiB 175 GiB 4.72

--- POOLS --- POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL ssd-pool 1 64 45 GiB 612 45 GiB 4.88 864 GiB hdd-pool 2 64 123 GiB 634 123 GiB 4.58 2.44 TiB

Aquí veus clarament que ssd-pool fa servir només els discos SSD i hdd-pool només els HDD. Si veus que un pool fa servir discos del tipus incorrecte, la CRUSH rule no està ben configurada.

Monitorització contínua

Proxmox integra el monitoring de Ceph a la seva GUI: Ceph → Status mostra IOPS, throughput, i latència per OSD en temps real.

Configura notificacions: Datacenter → Notifications — afegeix un endpoint (email, Gotify, webhook) i activa alertes per a:

  • Ceph health warnings
  • OSD down
  • Pool usage > 80%
  • Backup job failures

Multi-node: escalant el setup

El mateix disseny escala sense canvis. Això és el que guanyes:

Afegir un node al cluster

Des de la GUI del nou node: Datacenter → Cluster → Join Cluster. Proxmox gestiona la configuració de corosync, els certificats, i la replicació de la configuració.

Afegir discos del nou node

Crea OSDs als discos del nou node igual que abans. Ceph els detecta, els assigna la device class, i els integra al CRUSH map automàticament.

Habilitar replicació real

Ara que tens més d’un node, puja el size dels pools:

# Replicación entre 2 nodos
ceph osd pool set ssd-pool size 2
ceph osd pool set ssd-pool min_size 1

ceph osd pool set hdd-pool size 2
ceph osd pool set hdd-pool min_size 1

Ceph comença a rebalancejar dades automàticament — cada objecte es replica en un OSD d’un altre node. Les CRUSH rules que vam crear amb host com a failure domain asseguren que les rèpliques estiguin en nodes diferents.

Moure PBS a un altre node

En multi-node, pots migrar la VM de PBS a un node diferent del que allotja les VMs de producció. Així, una fallada de hardware al node de producció no afecta els backups.

Tips i gotchas

No omplis Ceph per sobre del 80%. El rendiment es degrada dràsticament quan l’espai s’esgota. Al 85%, Ceph comença a emetre warnings. Al 95%, bloqueja escriptures (nearfull/full flags) i recuperar-se d’aquest estat és dolorós. Monitoritza l’ús i afegeix capacitat abans d’arribar-hi.

Scrubs i rendiment. Ceph fa scrubs periòdics — verificacions d’integritat de les dades. En single-node amb HDDs, un deep scrub pot causar latència notable a les VMs. Programa els scrubs en horaris de baixa activitat:

# Scrubs solo entre las 2:00 y las 6:00
ceph config set osd osd_scrub_begin_hour 2
ceph config set osd osd_scrub_end_hour 6

Recovery després de fallada d’OSD. Si un HDD mor, el pool HDD queda degradat però el pool SSD segueix intacte — gràcies a les CRUSH rules separades. Cada pool és independent. Reemplaça el disc, crea un nou OSD, i Ceph reconstrueix les dades automàticament (si tens replicació > 1).

Snapshots abans d’operacions arriscades. Ceph RBD suporta snapshots natius que són instantanis i no ocupen espai fins que les dades originals canvien. Fes-los servir abans d’actualitzar una VM o canviar configuracions crítiques:

# Snapshot de un disco de VM
rbd snap create ssd-pool/vm-100-disk-0@pre-upgrade

No barregis workloads. VMs de producció al pool SSD, tot la resta al pool HDD. La temptació de “només posar aquesta VM petita al SSD” acaba amb el pool ple i totes les teves VMs de producció afectades. Sigues disciplinat amb la separació.

Conclusió

Amb Proxmox + Ceph + PBS tens una plataforma de virtualització completa: compute, storage tiered per rendiment, i backups amb deduplicació. Tot open source. El cost és només el hardware.

El setup escala d’1 node a un cluster sense redissenyar res. Les CRUSH rules, els pools, els jobs de backup — tot segueix funcionant quan afegeixes nodes. Només canvies el size dels pools per activar la replicació real.

PBS en VM és un compromís pragmàtic. Per a un homelab és perfecte. Per a producció seriosa, PBS hauria d’estar en hardware separat, o com a mínim els backups replicats a un segon destí — un altre PBS remot, un bucket S3, o un disc USB extern rotat (sí, de debò — una còpia offline val més que mil rèpliques online si t’entra un ransomware).

Si vols muntar Kubernetes sobre d’aquest Proxmox, fes un cop d’ull al primer post del blog — cobreix l’stack complet de K8s en un sol servidor, que és exactament el que pots fer amb una VM en aquest setup.