Riggen_HomeLab_Storage_4 - itnett/FTD02H-N GitHub Wiki

La oss oppsummere og sette opp en komplett og optimal lagringskonfigurasjon for Proxmox-laben din, inkludert en detaljert partisjonering av M.2 NVMe-disken (1 TiB) og andre disker i riggen. Vi skal ta høyde for alle kravene dine, inkludert redundans, ytelse, og effektiv bruk av tilgjengelige ressurser.

1. M.2 NVMe SSD (1 TiB): Brukes til Proxmox systemdisk, caching (L2ARC), SLOG (ZFS ZIL), swap, og fremtidige behov.
2. 2 x 1.6 TB SSD (zpool_vm): ZFS pool for VM-lagring.
3. 2 x 1.2 TB SSD (zpool_cont): ZFS pool for container-lagring.
4. 2 x 4 TB SATA HDD (zpool_cloudTier): ZFS pool for "cold storage" (backup, arkiver).
5. 1 x 500 GB SSD (zpool_image): Lagring for ISO-er, templates, og golden images.

Vi har en 1 TiB (1024 GiB) M.2 NVMe SSD tilgjengelig. På grunn av overhead fra partisjonering og filsystemer, antar vi at vi får rundt 931 GiB faktisk brukbar plass.

• Systemdisk (ZFS root):

  • 100 GiB partisjon for Proxmox OS (/dev/nvme0n1p1).
  • Brukes til å boote Proxmox og inneholder OS-filer.

• L2ARC og SLOG-konfigurasjon:

  • Partisjoner dedikert til L2ARC (Lesecache) og SLOG (Write log) for hver ZFS-pool:
    • L2ARC for zpool_vm: 100-150 GiB for raskere lesing av VM-data.
    • SLOG for zpool_vm: 20 GiB for raskere synkrone skriver til VM-poolen.
    • L2ARC for zpool_cont: 75-100 GiB for containere.
    • SLOG for zpool_cont: 20 GiB for raskere synkrone skriver til container-poolen.
    • L2ARC for zpool_cloudTier: 75-100 GiB for kald lagring.
    • SLOG for zpool_cloudTier: 10 GiB for kald lagring.
    • L2ARC for zpool_image: 25-50 GiB for ISO- og image-data.
    • SLOG for zpool_image: 10 GiB for image-data.

• Swap for Overprovisionering:

  • 32 GiB partisjon som swap for å gi ekstra minnekapasitet utover fysisk RAM, spesielt nyttig når du har begrenset RAM (32-64 GiB).

• ZFS Pool for VM-er (zpool_vm):

  • 2 x 1.6 TB SSD-er speilet i RAID1.
  • Dette gir robusthet og ytelse for VM-lagring.

• ZFS Pool for Containere (zpool_cont):

  • 2 x 1.2 TB SSD-er speilet i RAID1.
  • Dette gir rask tilgang og god beskyttelse for container-data.

• ZFS Pool for Cold Storage (zpool_cloudTier):

  • 2 x 4 TB HDD-er i ZFS RAIDZ1 eller RAIDZ2.
  • Sikker lagring for arkiver, backuper, eller annen kald data.

• ZFS Pool for Images (zpool_image):

  • 1 x 500 GB SSD.
  • Lagring av ISO-er, blueprints, og golden images.

• Totalt Utnyttet: ~ 467-531 GiB for alle nødvendige funksjoner, med rikelig plass (~339-464 GiB) igjen for fremtidig bruk eller justeringer.
• Plass til Overs for Utvidelse: Med god margin tilgjengelig for justeringer, fremtidig caching, swap-justering, eller andre behov.

Denne konfigurasjonen optimaliserer bruken av din 1 TiB M.2 NVMe SSD for å gi best mulig ytelse, robusthet, og fleksibilitet for Proxmox og alle dets VM-er og containere. Ved å strategisk allokere plass til system, cache, logg, og swap, balanserer vi ytelse og kapasitet, samtidig som vi tar høyde for fremtidig vekst og endringer.

Hvis M.2-disken skulle feile, har du også sikret at dataene dine på VM- og containerpoolene er beskyttet via ZFS RAID-konfigurasjoner, og du kan raskt gjenopprette systemet fra backup-lagring eller alternative disker.

La oss gå gjennom spørsmålene dine og lage en optimal konfigurasjon som dekker alle kravene dine:

Ja, du kan slette, øke eller redusere størrelsen på L2ARC (Level 2 Adaptive Replacement Cache) og SLOG (Separate Log Device) i fremtiden uten å tape data, men det krever litt planlegging:

• L2ARC er en lesecache for ZFS som lagrer data som nylig er blitt lest fra disken. Data i L2ARC er kopier av data fra ZFS-poolen, så det er ikke kritisk for dataintegritet hvis L2ARC-enheten fjernes eller endres.
• For å endre størrelsen på L2ARC:
  1. Fjern eksisterende L2ARC: Du kan fjerne L2ARC ved å bruke zpool remove-kommandoen:

     zpool remove <zpool_name> <l2arc_device>

  2. Opprett ny partisjon med ønsket størrelse på M.2-disken.
  3. Legg til den nye L2ARC-enheten: Bruk zpool add til å legge til en ny L2ARC:

     zpool add <zpool_name> cache /dev/nvme0n1pX

• SLOG brukes til å akselerere synkrone skriveoperasjoner. Data i SLOG er en logg av de siste synkrone skriverne, og ZFS vil automatisk skrive disse dataene til den primære lagringen.
• For å endre størrelsen på SLOG:
  1. Fjern eksisterende SLOG: Fjern den ved å bruke zpool remove:

     zpool remove <zpool_name> <slog_device>

     ZFS vil sørge for at ingen data går tapt, siden alle synkrone skriver vil bli fullført før fjerningen.
  2. Opprett en ny SLOG-partisjon med ønsket størrelse.
  3. Legg til den nye SLOG-enheten:

     zpool add <zpool_name> log /dev/nvme0n1pY

Merk: Både L2ARC og SLOG kan fjernes og endres dynamisk uten datatap, men det er lurt å utføre disse operasjonene når systemet har lav belastning for å unngå ytelsestap.

La oss sette opp LVM (Logical Volume Management) for å sikre at Proxmox bruker riggens kapasitet optimalt og for å kjøre VM-er og containere effektivt.

Oversikt over Partisjonering: Vi skal bruke M.2 NVMe SSD som hovedsystemdisk for Proxmox, og deretter speile Proxmox OS til en av SSD-ene for å kunne gjenopprette ved feil.

1. Installer Proxmox på M.2 NVMe med ZFS root:

   • Velg ZFS RAID 0 under installasjon for systemdisk (/dev/nvme0n1p1).
   • Opprett en LVM-thin volumgruppe (VG) på /dev/nvme0n1p2 for VM-er og containere.

2. Sett opp swap og andre partisjoner:

   • Opprett swap-partisjonen (/dev/nvme0n1p3) på 32 GiB.

3. Konfigurer LVM-thin for VM-er og containere:

   • Opprett en LVM-thin-pool for VM-er og containere:

     lvcreate -L 200G -T pve/data-thin pve
     lvcreate -n vm-storage -V 200G --thinpool pve/data-thin
     lvcreate -n container-storage -V 200G --thinpool pve/data-thin

   • Dette gir fleksibilitet for lagring, og gir optimal ytelse og IOPS for VM-er og containere.

For å sikre at du kan starte opp samme Proxmox-miljø fra en av de andre diskene om M.2 ryker, vil vi opprette en backup-installasjon av Proxmox på en av SSD-ene i zpool_vm eller zpool_cont.

1. Opprett en Kopi av Proxmox OS på en av SSD-ene:

• Installer en kopi av Proxmox VE på en av de eldre SSD-ene (for eksempel en partisjon på en av diskene i zpool_vm).
• Bruk en partisjon som er stor nok (f.eks., 100 GiB).
• Speil systeminstallasjonen fra M.2 til denne SSD-en regelmessig ved hjelp av rsync eller en annen synkroniseringsmetode.

2. Sette opp grub-bootloader for å støtte alternativ oppstart:

• Rediger /etc/default/grub på hovedinstallasjonen til å inkludere en fallback-entry for den sekundære installasjonen:

  GRUB_DEFAULT="saved"
  GRUB_TIMEOUT=5
  GRUB_CMDLINE_LINUX_DEFAULT="quiet"

• Oppdater GRUB og la det inkludere en oppføring for fallback til SSD:

  update-grub

3. Automatiser Backups av Konfigurasjon og Data:

• Bruk Proxmox-backup-verktøy for å ta regelmessige sikkerhetskopier av konfigurasjonen og VM-data til en ekstern lagringsenhet eller zpool_cloudTier.
• Sørg for at alle konfigurasjonsfiler og VM-disker er inkludert i backupene.

1. Fleksibilitet i L2ARC og SLOG: Du kan dynamisk endre størrelsen på L2ARC og SLOG på M.2 uten datatap.
2. Optimal LVM-oppsett: Bruk LVM-thin for å allokere lagring til VM-er og containere, og bruk dedikerte swap-områder.
3. Sikre Alternativ Oppstart: Installer en sikkerhetskopi av Proxmox på en av SSD-ene og konfigurer GRUB til å støtte alternativ oppstart.

Denne konfigurasjonen sikrer optimal ytelse, redundans, og maksimal utnyttelse av riggens kapasitet, samtidig som den beskytter mot feil på M.2 NVMe-disken.

La oss se på alternativene for å plassere en oppstartbar backup av Proxmox og evaluere hva som vil gi deg best balanse mellom ytelse, redundans, og bruk av tilgjengelig lagringsplass.

• Er backupen av Proxmox sikret av to disker?
• Vil denne backupen redusere ytelsen på SATA-poolene?
• Er det mer fornuftig å bruke en annen disk, som ISO-SSD-disken eller 2x4TB SATA-poolen, til denne oppstartbare backupen?

1. Fordeler:

   • Dataredundans gjennom ZFS Mirror: Hvis du oppretter en backup av Proxmox på en partisjon av en av diskene i zpool_vm, vil dataene bli speilet (RAID1), og du får beskyttelse mot diskkrasj.
   • Relativt høy ytelse: SSD-ene har høyere ytelse enn HDD-ene, noe som gir raskere oppstart og gjenoppretting sammenlignet med bruk av HDD-poolen.

2. Begrensninger:

   • Redusert ytelse for VM-er: Selv om du bruker en liten partisjon til Proxmox-backup på disse diskene, kan dette potensielt påvirke ytelsen til VM-poolen (zpool_vm), spesielt hvis det skjer samtidig med tunge lese-/skriveoperasjoner.
   • Rotering av ytelsen på SATA SSD-poolene: Selv om dette ikke drastisk vil forringe ytelsen, vil det være mer effektivt å holde disse diskene dedikert til lagring av VM-er og containere.

1. Fordeler:

   • Ingen påvirkning på hovedlagringspoolene: Denne disken brukes til ISO-er, templates, og images, som ikke krever konstant høy I/O-ytelse. Å legge til en Proxmox-backup her vil ikke påvirke ytelsen til VM-er og containere.
   • Raskere ytelse enn HDD-poolen: SSD-en vil være raskere enn HDD-poolen for oppstart og systemgjenoppretting.

2. Begrensninger:

   • Ingen dataredundans: ISO-SSD-en er en enkelt disk, så det er ingen speiling eller RAID-beskyttelse. Hvis denne disken svikter, vil Proxmox-backupen også gå tapt.
   • Mindre kapasitet: 500 GB gir mindre plass til sikkerhetskopiering og fremtidig utvidelse sammenlignet med større disker.

1. Fordeler:

   • God redundans: Ved å bruke RAIDZ1 eller RAIDZ2, kan du sikre dataene mot en eller to diskkrasj, noe som gir god databeskyttelse.
   • Stor kapasitet: Du har rikelig plass til sikkerhetskopiering, systemimages og fremtidig utvidelse.
   • Ingen påvirkning på primære VM/Container-pooler: Backup vil være på separate HDD-er som ikke påvirker I/O-intensive operasjoner for VM-er og containere på SSD-poolene.

2. Begrensninger:

   • Lavere ytelse: SATA HDD-er vil ha mye lavere lese-/skriveytelse enn SSD-er. Dette betyr langsommere oppstart og gjenoppretting av Proxmox.
   • Mulig rotasjon av data på kald lagring: Hvis disse HDD-ene også brukes til andre sikkerhetskopier og arkiver, kan det redusere leseytelsen ytterligere.

• Opprett en egen partisjon på ISO SSD-disken for å lagre en kopi av Proxmox.
  • Opprett en partisjon på rundt 100 GiB for Proxmox-backup og installer en kopi av Proxmox på denne partisjonen.
  • Denne metoden påvirker ikke ytelsen til VM- og container-poolene, og SSD-en vil gi raskere oppstart enn HDD-poolen.

• Opprett en egen ZFS pool for Proxmox-backup på HDD-ene:
  • Installer Proxmox på en liten partisjon (f.eks., 100 GiB) på RAIDZ1 eller RAIDZ2 konfigurasjonen for å dra nytte av redundans.
  • Dette gir deg god databeskyttelse, men lavere oppstartshastighet.

1. For optimal ytelse og ingen påvirkning på primærlagringspoolene, anbefales det å bruke ISO SSD-disken (500GB) for en oppstartbar backup av Proxmox. Dette gir rask oppstart og systemgjenoppretting uten å påvirke ytelsen til VM-er og containere.

2. For best mulig redundans, men med lavere ytelse, kan du bruke en av HDD-ene (zpool_cloudTier) i RAIDZ-konfigurasjon for sikkerhetskopi av Proxmox. Dette gir databeskyttelse mot flere diskkrasj.

Ved å implementere disse to alternativene, får du både rask ytelse og databeskyttelse for Proxmox-laben din.

La oss gå gjennom detaljene for å skreddersy konfigurasjonen din basert på dine behov og begrensninger. Du ønsker et miljø der du kan eksperimentere med CI/CD, lære ZFS-administrasjon, og utforske forskjellige teknologier uten risiko for kritisk datatap. Samtidig ønsker du å begrense slitasje på SSD-ene og sikre at systemet fungerer effektivt med 32 GiB RAM.

• L2ARC (Read Cache):

  • Fylles opp med data som ofte leses fra ZFS poolen, men det avhenger av den tilgjengelige mengden fysisk minne (RAM) som ZFS kan bruke som ARC (Adaptive Replacement Cache).
  • L2ARC-størrelsen påvirkes av hvor mye fysisk minne som er tilgjengelig; ZFS bruker først ARC (RAM) før den begynner å bruke L2ARC.
  • L2ARC-cache vil ikke overskride mengden data som passer i ARC (RAM) pluss den tilgjengelige plass på L2ARC-enheten (M.2), men det blir mest effektivt når det er tilstrekkelig RAM til å holde metadataene for cachen.

• SLOG (Separate Intent Log):

  • Brukes kun for synkrone skriveoperasjoner på ZFS-pooler. Data skrives først til SLOG før de blir skrevet til den permanente ZFS-lagringen.
  • SLOG-enheten påvirkes ikke av størrelsen på det fysiske minnet eller swap. Den trenger bare nok plass til å håndtere de synkrone skriveoperasjonene som skjer i løpet av en gitt tid (vanligvis sekunder).
  • Optimal størrelse på SLOG avhenger av arbeidsmengden og mengden synkrone skriver, men vanligvis er 10-20 GiB tilstrekkelig for de fleste bruksområder i din lab.

Ja, du har full fleksibilitet i ZFS til å bruke så mye eller så lite av SSD-ene som du vil. Du trenger ikke å dedikere hele disken til én ZFS-pool – du kan lage flere pooler eller reservere plass til andre formål.

Du kan partisjonere SSD-ene for å bruke bare en del av plassen til ZFS pooler, og beholde resten for fremtidige behov. Dette gir deg fleksibilitet til å tilpasse systemet etter hvert som dine behov endrer seg.

Eksempel på konfigurasjon:

• Fleksibilitet: Du kan alltid utvide eller opprette nye ZFS pooler etter behov uten å være låst til én stor pool.
• Reduksjon av slitasje: Ved å reservere plass, reduserer du slitasjen på SSD-ene, siden de ikke alltid brukes maksimalt.
• Mulighet for andre filsystemer: Du kan bruke resten av plass til andre filsystemer eller formål senere.

Du kan bruke LVM (Logical Volume Management) for å gi Proxmox mest mulig fleksibilitet og utnytte riggens kapasitet:

1. Installer Proxmox på M.2 NVMe:

   • Opprett en partisjon på M.2 NVMe SSD (f.eks., /dev/nvme0n1p1) på 100 GiB for Proxmox OS med LVM.
   • Bruk resten av plassen på M.2 til L2ARC, SLOG, og swap-partisjoner som tidligere beskrevet.

2. LVM-thin Pool for VM-er og Containere:

   • Opprett en LVM-thin pool på /dev/nvme0n1p2 (200 GiB) for VM-er og containere som trenger høy IOPS.
   • Bruk dedikert plass til swap (/dev/nvme0n1p3, 32 GiB).

• LVM-volumgruppe (VG):
  • Opprett en volumgruppe (VG) kalt pve på M.2 NVMe.
  • Legg til et logisk volum (LV) for swap (pve/swap), og et volum for root (pve/root).

vgcreate pve /dev/nvme0n1p1
lvcreate -L 100G -n root pve
lvcreate -L 32G -n swap pve
lvcreate -L 200G -n thin-pool pve

• LVM-thin Pool:
  • Opprett en thin pool for VM-er og containere for effektiv bruk av diskplass.

lvcreate --thinpool thin-pool pve

For å sikre at du kan starte opp Proxmox fra en av de andre diskene om M.2 NVMe feiler:

1. Installer en Backup av Proxmox på 2x4TB SATA HDD (zpool_cloudTier):

• Opprett en liten partisjon (100 GiB) på en av HDD-ene (zpool_cloudTier) for å installere en sikkerhetskopi av Proxmox.
• Bruk RAIDZ1 eller RAIDZ2 for å beskytte mot datatap.

2. Automatisert Backup av Systemdisk:

• Bruk rsync eller dd for å synkronisere systemdisken fra M.2 NVMe til backup-disken periodisk.

3. Oppdater grub for Fallback Boot:

• Konfigurer grub for å ha en oppføring til backup-installasjonen på SATA-disken.

update-grub

1. Du kan justere størrelsen på L2ARC og SLOG når som helst uten å tape data, og konfigurere dem for å oppnå optimal ytelse basert på faktiske arbeidsbelastninger.

2. Optimal bruk av ZFS og LVM: Del diskene opp for å gi fleksibilitet og redusere slitasje, samtidig som du bruker LVM for å gi Proxmox den ytelsen den trenger.

3. Sikre backup og oppstart fra SATA-poolen: Bruk HDD-ene til å installere en backup av Proxmox som kan brukes i tilfelle feil på M.2 NVMe. Dette sikrer at du raskt kan gjenopprette og starte opp igjen labben. Du har helt rett – for din brukssituasjon, der du ikke forventer tung belastning med tusenvis av sesjoner, kan det være mer fornuftig å starte med mindre SLOG og L2ARC-størrelser. Siden du hovedsakelig vil eksperimentere, teste, og kanskje kjøre periodiske lasttester, vil du sannsynligvis ikke utnytte store SLOG- og L2ARC-størrelser til det fulle fra starten av.

Vi kan begynne med å tildele mindre plass til både SLOG og L2ARC, og la et større uparisjonert område være tilgjengelig for fremtidig utvidelse. Dette vil gi deg fleksibilitet til å justere disse størrelsene etter behov.

1. SLOG (Write Cache):

   • Start med en liten partisjon på 10-20 GiB for SLOG på M.2-disken. Dette bør være mer enn tilstrekkelig for dine nåværende behov, spesielt med sporadiske eller planlagte skriveintensive operasjoner.

2. L2ARC (Read Cache):

   • Tildel en partisjon på 20-40 GiB for L2ARC som et utgangspunkt. Dette gir ZFS lesecache nok plass til å forbedre leseoperasjoner uten å kaste bort for mye plass.

3. Resten av M.2 som uparisjonert plass:

   • La resten av M.2-disken (~900 GiB) være uparisjonert for fremtidig bruk. På denne måten kan du når som helst opprette nye partisjoner for å utvide SLOG, L2ARC, eller andre bruksområder etter behov.

Når du ser behovet for større SLOG eller L2ARC, kan du enkelt utvide fra det uparisjonerte området på M.2-disken:

1. Lage en ny partisjon på det uparisjonerte området:

   • Bruk parted eller et annet partisjoneringsverktøy til å lage en ny partisjon på M.2-disken med ønsket størrelse.

   parted /dev/nvme0n1

2. Legge til den nye partisjonen som SLOG eller L2ARC:

   • For L2ARC:

     zpool add <zpool_name> cache /dev/nvme0n1pX

   • For SLOG:

     zpool add <zpool_name> log /dev/nvme0n1pY

• Begynn med små SLOG (10-20 GiB) og L2ARC (20-40 GiB) størrelser for å redusere unødvendig ressursbruk.
• Behold et stort uparisjonert område på M.2-disken for fleksibilitet og fremtidig vekst.
• Utvid ved behov for å tilpasse seg arbeidsbelastninger eller spesifikke scenarier som krever mer cache.

Dette gir deg maksimal fleksibilitet, beskytter mot unødvendig slitasje på disken, og gjør det mulig å tilpasse lagringsoppsettet dynamisk basert på faktisk bruk.