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.
58 lines
2.5 KiB
Markdown
58 lines
2.5 KiB
Markdown
# Overview & Roadmap
|
|
|
|
## Background
|
|
|
|
Current hardware requires disabling KVM hardware virtualization for VMs to
|
|
start at all (falls back to software emulation — slow). This is a
|
|
host/BIOS-level issue, not a Proxmox limitation, and shouldn't be needed on
|
|
new hardware. Before reusing that workaround on the new box:
|
|
|
|
- Confirm VT-x (Intel) / AMD-V (AMD) is enabled in BIOS/UEFI.
|
|
- Confirm IOMMU is enabled if passthrough is planned.
|
|
- Update BIOS/microcode first.
|
|
- Rule out running Proxmox nested inside another hypervisor.
|
|
|
|
## End goal
|
|
|
|
3-node Proxmox VE cluster with HA-managed VMs. Two ways to get VM disks
|
|
available on more than one node (see `02-storage-zfs-ceph.md`):
|
|
|
|
1. **Ceph** — true distributed shared storage, sync replication, needs 3+
|
|
nodes and a fast dedicated network. Zero/near-zero RPO on failover.
|
|
2. **ZFS + storage replication** — local ZFS pool per node, Proxmox
|
|
replicates VM disks between nodes on a schedule (as often as every
|
|
minute). Lighter weight, async — failover loses whatever changed since
|
|
last replication.
|
|
|
|
Starting point: ZFS + replication (lighter, works from node 1 onward).
|
|
Ceph is the upgrade path once 3 nodes exist and/or zero-RPO failover
|
|
matters enough to justify the overhead.
|
|
|
|
## Cluster fundamentals (apply from node 1 onward)
|
|
|
|
- 3 nodes minimum for real quorum. If starting with 2, add a QDevice
|
|
(small VM or Raspberry Pi) as tie-breaker.
|
|
- Dedicated network for corosync (cluster/quorum traffic) — never shared
|
|
with VM or storage traffic. Needs low, consistent latency (well under
|
|
5ms); jitter matters more than bandwidth.
|
|
- All nodes on the same PVE version, NTP-synced, SSH reachable between
|
|
nodes.
|
|
- Set VM CPU type to a portable type (e.g. `x86-64-v2-AES` or `kvm64`)
|
|
rather than `host` if nodes will ever have different CPUs — needed for
|
|
clean live migration.
|
|
|
|
## Rollout sequence
|
|
|
|
1. Build node 1 per `01-hardware-node1.md` — fresh PVE install on ZFS boot
|
|
mirror, local ZFS "tier 2" pool for VM disks, Ceph-earmarked disks left
|
|
idle or as a temporary ZFS pool.
|
|
2. Migrate VMs off old hardware via `vzdump` → copy backups → `qmrestore`
|
|
onto the new ZFS storage (converts disks to ZVOLs).
|
|
3. Apply hardening (`04-security-hardening.md`) and networking
|
|
(`03-networking.md`) before exposing the node beyond the LAN.
|
|
4. Add nodes 2 and 3 identically (same disk/network layout).
|
|
5. Join cluster, stand up dedicated corosync network, configure
|
|
replication and HA groups.
|
|
6. Optionally migrate the Ceph-earmarked disks from temporary ZFS to real
|
|
Ceph OSDs once 3 nodes are up.
|