152 lines
9.0 KiB
Markdown
152 lines
9.0 KiB
Markdown
# State
|
||
|
||
## Kontext a zkušenosti
|
||
|
||
- Proxmox provozuje dlouhodobě — jeden z domácích serverů, provozuje ho i v práci.
|
||
- Druhý domácí server je taky Proxmox.
|
||
- Zkušený Linux admin — preferuje CLI, líbí se mu, že všechno jde udělat z CLI.
|
||
- Odattendoval dvě vícedenní školení Proxmoxu: základy + pokročilý.
|
||
|
||
## Hardware / současný stav
|
||
|
||
- **proxmox.hell** (hlavní server): Dell OptiPlex 9020 Mini Tower, Intel Core i7-4790 @ 3.60GHz, 32GB RAM, GeForce RTX 4060 Ti 16GB, KINGSTON SKC3000D2048G 2TB NVMe, KINGSTON SUV5004 56RI 480GB SSD.
|
||
- RTX 4060 Ti / 16 GB passthrough do jedné VM.
|
||
|
||
## Cíle / probíhající práce
|
||
|
||
- **ZFS do hloubky** — základy zná, chce hlubší porozumění. Materiály:
|
||
viz sekce Studijní materiály níže.
|
||
- **Proxmox Backup Server** — vyzkoušel, líbí se. Plánovaný layout: SSD na
|
||
rootfs, spiny disky na data, **special vdev také na SSD**.
|
||
- **Migrace Hyper-V → Proxmox pro kamaráda**: vyražený Dell Edge server,
|
||
2× 2 TB SSD (rootfs + VM disky). Přenos image z Hyper-V už úspěšně
|
||
natrénoval. Potřeba: celý proces **lépe popsat a naskriptovat**.
|
||
|
||
## Dlouhodobé cíle
|
||
|
||
- **Atom server — znovupoužití 2TB šifrovaného disku z předchozího Debianu**:
|
||
používat ho dál ve stejném duchu — více partition, nad nimi LUKS
|
||
a LVM (nad/pod LUKS). Napojit jako storage do Proxmoxu.
|
||
- **rdiff-backup z jiného serveru** — v LXC kontejneru na atom serveru
|
||
zálohovat jiný server.
|
||
- **Záloha Incus kontejneru** — běží v něm hromada dockerů s různými
|
||
službami včetně Gitey; **data Gitey jsou kritická**. Potřeba vymyslet
|
||
spolehlivý zálohovací postup.
|
||
- **Gitea: migrace z Incusu do Proxmoxu?** — zvažuje přesun na PVE
|
||
(VM/kontejner), čímž se záloha výrazně zjednoduší — standardní PBS
|
||
záloha VM/kontejneru místo ad-hoc zálohování Incusu.
|
||
- **Gitea Actions** — chce GitHub Actions-compatible CI pro Giteu;
|
||
runner jako další VM/kontejner na Proxmoxu (Gitea Actions, `act_runner`).
|
||
- **PBS na atom serveru?** — zvažuje, zda na atom serveru spustit Proxmox
|
||
Backup Server jako zálohovací cíl pro hlavní Proxmox.
|
||
|
||
## Hostname / přejmenování nodu
|
||
|
||
- **Název nodu = kernel hostname (`uname -n`)**, ne DNS. Změna DNS záznamu
|
||
Proxmoxu vůbec nevadí (ověřeno); změna `/etc/hostname` na nodu s VM
|
||
rozběhne systém — VM se nenašly, vše se chovalo divně. Pomohl revert.
|
||
- Root cause: pmxcfs drží konfigurace VM/kontejnerů, certifikáty a metadata
|
||
v `/etc/pve/nodes/<hostname>/`. Po změně hostname hledá pvedaemon konfigurace
|
||
pod novým názvem, který v pmxcfs neexistuje → VM "zmizí".
|
||
- **Správný postup** (oficiální wiki Renaming a PVE node):
|
||
1. Doporučeno jen na **prázdném nodu** — pmxcfs neumí přejmenovat
|
||
neprázdné adresáře.
|
||
2. Editovat `/etc/hostname` **a** `/etc/hosts` (všechny výskyty, hostname
|
||
na hlavní IP). Volitelně `/etc/mailname`, `/etc/postfix/main.cf`.
|
||
3. V clusteru: upravit `n_0` v `/etc/pve/corosync.conf` přes
|
||
`pvecm edit corosync.conf` — ale v clusteru se přejmenování
|
||
**nedoporučuje**.
|
||
4. Reboot.
|
||
5. Ručně přenést `/etc/pve/nodes/<starý>/` → `<nový>/` (strukturu
|
||
rekonstruovat, kopírovat po úrovních).
|
||
6. Přenést RRD data: `/var/lib/rrdcached/db/pve2-{node,storage}/<starý>`
|
||
→ `<nový>`, starý smazat.
|
||
- **Moudro:** u nodu s běžícími VM stojí přejmenování tolik ruční práce,
|
||
že je čistší postavit node pod novým názvem a VM migrnout. Revert
|
||
hostname vše opraví — pmxcfs data nemaže, jen je "nezobrazí".
|
||
|
||
## Studijní materiály — ZFS (uložené v bookmark skillu, db/bookmark.sqlite)
|
||
|
||
- [ZFS 101 (Jim Salter, Ars Technica)](https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/) — zpools, vdevy, RAIDZ vs mirror, ashift, CoW, ZIL/SLOG, komprese, ARC. Plný text archivován.
|
||
- [ZFS vs RAID benchmark (Ars Technica)](https://arstechnica.com/gadgets/2020/05/zfs-versus-raid-eight-ironwolf-disks-two-filesystems-one-winner/) — 8× Ironwolf, mirrors vs RAID10, RAIDZ2 vs RAID6, vliv recordsize; výkon roste s počtem vdevů, ne disků. Plný text archivován.
|
||
|
||
## Atompivo — hardware kontext
|
||
|
||
- Server **atompivo**: Proxmox, stavěný dřív, než bylo jasné finální využití.
|
||
- **1 TB SSD** — celý disk na root fs nad ZFS (žádná volná partition).
|
||
- **2 TB spin disk** — 5400 rpm, starší, aktuálně šifrovaná data (LUKS z předchozího
|
||
Debianu); plánovaná přestavba na datastore. Další 2 TB spin disk k dispozici.
|
||
|
||
## PBS datastore na atompivo — layout a tuning
|
||
|
||
- **PBS poběží jako VM** na atompivu (oficiálně podporované, běžné). Požadavky:
|
||
celý disk passthrough pro spiny i pro special vdev (virtio-scsi), rezervovat
|
||
dost RAM pro ARC (řádově 4-8 GB), atom = ingest spíš CPU-bound (SHA256/zstd).
|
||
- **Chicken-egg**: PBS VM zálohuje node, na kterém sama běží — umět PBS postavit
|
||
znovu z ničeho; konfiguraci datastore + vzdump PBS VM držet mimo datastore
|
||
(např. `zfs send` z root poolu na jiný stroj).
|
||
- **Datastore pool** na 2TB spiny (5400 rpm), tuning hned od založení:
|
||
- `recordsize=1M` + `logbias=throughput` (doloženo na Proxmox foru: ingest
|
||
200 → 900 MB/s jen touto změnou)
|
||
- **special vdev na SSD** — na 5400 rpm **nutnost, ne nice-to-have**:
|
||
GC je metadata workload (readdir+stat nad miliony chunků); bez special vdevu
|
||
~20+ h denně, s ním minuty až desítky minut. GC defaultně běží denně.
|
||
- `special_small_blocks=64K` — obsah malých chunků také na SSD; hlídat
|
||
zaplnění special vdevu (`zpool list -v`), řádově desítky GB.
|
||
- **`proxmox-backup-debug chunk-order`** — povinný na 5400 rpm: bez něj
|
||
random read ~1-2 MB/s efektivně → verify týdny; s ním sekvenční read
|
||
~100-130 MB/s → ~5-6 h na 2 TB. Pustit po naplnění datastore a po
|
||
velkých změnách znovu.
|
||
- **Special vdev = zvol nad SSD root poolem** (žádná volná partition):
|
||
- Overhead nested CoW (write amplification ~2-3× na malých writzech,
|
||
dvojité journaling vrstvy) — pro metadata na SSD irelevantní.
|
||
- **SPOF**: ztráta SSD = ztráta celého poolu i se zdravými spiny.
|
||
Akceptováno (GC bolí denně, ztráta SSD je hypotetický jednorázový event).
|
||
- **Nelze později odebrat**, pokud top-level vdevy jsou raidz nebo ashifty
|
||
neschodují (`zpool remove` restrikce) — topologii naplánovat předem;
|
||
mirror spinů = odstranitelné, raidz = ne.
|
||
- Special vdev lze naopak přidat kdykoliv (`zpool add -o ... -special`)
|
||
— alternativní postup: založit bez něj, změřit, přidat.
|
||
|
||
## Gitea → PVE migrace a zálohy
|
||
|
||
- Rozhodnuto: **Gitea migruje z Incusu na Proxmox** — standardní PBS záloha
|
||
VM/kontejneru místo ad-hoc zálohování Incusu.
|
||
- Zálohovací cíl: **PBS na atompivu** (datastore viz výše).
|
||
|
||
## Šifrování — co Proxmox umí a co ne
|
||
|
||
- **PVE installer neumí šifrovaný root FS** — žádná LUKS volba. LUKS root =
|
||
ruční instalace Debianu + PVE na něj (komunitní návody: mr-manuel
|
||
luks-encryption-manual-tpm-ssh-unlock, cmspam/proxmox-uki-installer).
|
||
Feature request v Bugzille otevřený.
|
||
- **Hardware TPM pro host unlock: PVE neumí, ale jde DIY** — TPM2 sealing přes
|
||
`systemd-cryptenroll --tpm2` (nebo clevis) na Debian vrstvě; pro smysluplné
|
||
PCR7 sealing vhodné/žádoucí Secure Boot. PVE samo TPM spravuje jen pro
|
||
**guesty** (vTPM, Windows 11) — to je jiná věc než host unlock.
|
||
- **ZFS native encryption = experimentální v PVE docs** — známé limity:
|
||
replikace encrypted datasets (Bugzilla 2350), checksum errory u snapshotů
|
||
a ZVOLů (openzfs#11688). **Žádná TPM integrace** — jen passphrase/keyfile,
|
||
`zfs load-key` ručně nebo systemd unit.
|
||
- **Čistá cesta pro data disky: ZFS nad LUKS** (`/dev/mapper/...` jako vdev
|
||
zařízení) — osvědčený NAS pattern, TPM2 auto-unlock možný přes LUKS.
|
||
Pozor: `cryptsetup --sector-size 4096` pro ashift alignment.
|
||
- **Atom caveat**: zkontrolovat AES-NI (`lscpu | grep aes`) a přítomnost
|
||
TPM čipu — bez AES-NI LUKS throughput na atomu výrazně padá.
|
||
|
||
## Atompivo — reinstalace vs. stávající layout
|
||
|
||
- Problém: celý SSD patří rpoolu → žádná volná partition pro special vdev
|
||
(jen zvol nad rpoolem) ani pro budoucí potřeby.
|
||
- **Reinstalace overkill?** Pro samotný special vdev ano (zvol stačí), ale
|
||
node se právě přestavuje (data na spinu k přestavbě, Gitea se stěhuje
|
||
dovnitř) — reinstalace nikdy nebude levnější než teď.
|
||
- Installer umí advanced options (menší HDSize → volné místo na SSD).
|
||
- Bonusy reinstalace: swap na partition místo rpool/swap ZVOLu (PVE wiki
|
||
explicitně varuje před swap na zvolu), čistá partition pro special vdev
|
||
(jedna vrstva ZFS, žádný nested CoW, nezávislost na rpoolu), LVM rezerva.
|
||
- **Otevřená otázka: PBS VM vs. PBS v LXC** — LXC by posunul ZFS pool
|
||
datastore na host (žádný disk passthrough, special vdev = host partition/
|
||
zvol, LUKS pod ZFS řešený na hostu vč. TPM). Váže se na rozhodnutí o
|
||
šifrování a layoutu.
|