Archived
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.
70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
# Node 1 Hardware Layout
|
|
|
|
Build node 1 so nodes 2/3 are drop-in identical later — don't re-architect
|
|
disks or network when the cluster grows.
|
|
|
|
## Disks — three separate roles, physically separate devices
|
|
|
|
1. **Boot/OS pool (`rpool`)** — 2x small SSDs (240-480GB plenty), ZFS
|
|
mirror. Proxmox itself only. Never share with Ceph OSDs or bulk ZFS
|
|
data pools.
|
|
2. **Future Ceph OSD disks** — must end up as raw, unformatted devices —
|
|
no ZFS/RAID/LVM underneath (Ceph does its own replication; anything
|
|
underneath just doubles copy-on-write/checksumming and hurts
|
|
performance). Use enterprise SATA/NVMe SSDs with power-loss protection
|
|
(PLP) — matters far more for Ceph write latency than for general ZFS
|
|
use. Ceph needs 3 nodes minimum to go live, so on node 1 these disks
|
|
either sit idle or run as a temporary local ZFS pool to be wiped and
|
|
handed to Ceph once nodes 2/3 exist.
|
|
3. **Local ZFS "replicated tier" disks** — separate set of disks
|
|
(mirror or small raidz) for VMs kept on local storage + PVE
|
|
replication rather than Ceph (latency-sensitive or non-critical
|
|
workloads). This pool is permanent, not a placeholder.
|
|
|
|
If budget only allows one extra disk set right now: prioritize the
|
|
future-Ceph disks, run everything on ZFS locally until nodes 2/3 arrive,
|
|
then split workloads out. Avoid consumer QLC SSDs for either role — Ceph
|
|
punishes it on latency, ZFS on sync writes/scrub.
|
|
|
|
## Networking — cable and provision for the final topology now
|
|
|
|
Logically separate networks (ideally separate NICs/VLANs):
|
|
|
|
- **Management** — web UI / SSH
|
|
- **Corosync** — cluster quorum traffic, low-latency, unshared
|
|
- **Ceph public** — VM-to-OSD traffic
|
|
- **Ceph cluster/backend** — OSD-to-OSD replication (heaviest load)
|
|
|
|
Practical layout: 2x 10/25GbE bonded or split — one pair for Ceph, one
|
|
for mgmt + corosync + VM traffic, with corosync on its own VLAN even if
|
|
sharing a physical NIC. Get switch/cabling right on node 1 so nodes 2/3
|
|
are identical drops.
|
|
|
|
## CPU / RAM sizing
|
|
|
|
Size for the end state, not day one — RAM is the hardest thing to
|
|
retrofit. Budget covers:
|
|
|
|
- OS + ZFS ARC (ZFS wants RAM, not just disk)
|
|
- Ceph OSD daemons — realistically 3-5GB per OSD once running
|
|
- Actual VM workloads
|
|
|
|
Roughly a core per OSD on top of what VMs need. If OSDs won't be active
|
|
for a while, that's headway, but buy for 3 nodes' worth of eventual OSD
|
|
load.
|
|
|
|
## Backup target (PBS)
|
|
|
|
Keep it off the Ceph/compute nodes if possible — its failure domain
|
|
should be independent of the cluster. Modest separate machine or NAS:
|
|
ZFS mirror or raidz2, ECC RAM if possible, capacity for retention policy.
|
|
If it has to run as a VM inside the cluster short-term, that's a known
|
|
compromise, not the end state.
|
|
|
|
## Node 1 install sequence
|
|
|
|
1. Install Proxmox VE fresh onto the ZFS boot mirror.
|
|
2. Create the local ZFS "tier 2" pool for VM disks.
|
|
3. Leave Ceph-earmarked disks idle, or provision as a temporary ZFS pool
|
|
(to be wiped once Ceph goes live at 3 nodes).
|