beatzaplenty
a854412117
Covers node 1 hardware/network layout, LVM-thin -> ZFS migration path, Ceph as the future HA storage upgrade, and baseline SSH/firewall hardening.
1.9 KiB
Storage: LVM-thin → ZFS, and the path to Ceph
Why move off LVM-thin
Neither ZFS nor LVM-thin is shared storage — both are node-local. HA needs a VM's disk reachable from more than one node so it can restart elsewhere on host failure. LVM-thin has no answer for that. ZFS does, via replication; Ceph does natively.
Two paths to HA-capable storage
| ZFS + replication | Ceph | |
|---|---|---|
| Nodes required | 1+ (replication needs 2+ targets) | 3+ |
| Consistency | Async — snapshot-based, as often as every minute | Sync — real shared storage |
| Data loss on failover | Whatever changed since last replication cycle | ~None |
| Network needs | Normal cluster link | Fast dedicated network (see 03-networking.md) |
| Overhead | Low | Higher RAM/CPU/disk |
Starting point: ZFS + replication. Revisit Ceph once 3 nodes exist or zero-RPO failover is worth the overhead.
Migration plan (old hardware → new hardware)
Don't convert the old LVM-thin box in place. Rebuild fresh on new hardware with ZFS from the installer (mirror if 2+ disks), then move VMs:
- On the old host:
vzdumpeach VM to a backup file (external drive, NFS share, or PBS if available). - Copy backups to the new host.
qmrestoreonto the new ZFS storage — disks land as ZVOLs.
Alternative if both hosts can see each other on the network: temporarily cluster them and use the GUI "Migrate" with a storage move (offline only — live migration doesn't cross storage types).
Later: handing Ceph-earmarked disks over
Once nodes 2 and 3 are up and the Ceph-earmarked disks (see
01-hardware-node1.md) can be pooled 3-node minimum:
- Wipe any temporary ZFS pool on those disks.
- Initialize Ceph across the 3 nodes.
- Create OSDs directly on the raw disks (no ZFS/RAID underneath).
- Migrate VMs that need zero-RPO failover from the ZFS-replicated tier onto Ceph-backed storage.