Riggen_HomeLab_Storage_3 - itnett/FTD02H-N GitHub Wiki
Basert på maskinvareoppsettet ditt og den foreslåtte konfigurasjonen, kan vi evaluere fordeler og begrensninger med å bruke en M.2 NVMe SSD sammen med andre SSD-er og HDD-er på MSI X99S MPOWER hovedkortet.
-
Fordeler:
- Rask ytelse: PCIe 4.0 NVMe SSD-en gir høy lese- og skriveytelse (opptil 3.500 MB/s og 2.100 MB/s), noe som er ideelt for Proxmox-installasjon, caching (L2ARC), og som SLOG (write cache) for ZFS-pooler.
- Optimal bruk som systemdisk: Rask tilgang til OS-data, kortere oppstartstid og bedre respons for Proxmox-administrasjonsgrensesnittet.
- Mulighet for L2ARC og SLOG: Denne disken kan også brukes til L2ARC og SLOG, som kan akselerere ytelsen til ZFS-pooler ytterligere.
-
Begrensninger:
- Enkelt M.2-slot: Hovedkortet har bare ett M.2-port som støtter PCIe Gen3 x4, så det er ingen mulighet for RAID-konfigurasjon på M.2.
- Kompatibilitetsbegrensninger: M.2-porten støtter ikke RAID-moduser (RAID 0, 1, 5, 10) på PCIe M.2 SSD-er, og NVMe SSD-er er kun kompatible med UEFI, ikke legacy ROM.
- M.2 Port påvirker SATA-porter: Installasjon av en M.2 SATA SSD vil deaktivere SATA5 og SATA6 porter, men dette gjelder ikke for PCIe-baserte M.2-moduler som NVMe.
-
Fordeler:
- Mulighet for ZFS-pooler med RAID: Kan konfigureres i forskjellige ZFS RAID-moduser (f.eks., RAID1 eller RAIDZ) for å balansere ytelse, kapasitet, og databeskyttelse.
- Optimal lagring for VM-er og containere: Bruk disse SSD-ene for rask, stabil lagring av VM-er og containere.
- Redundans og feilbeskyttelse: Med RAID-konfigurasjon kan du beskytte dataene mot diskfeil.
-
Begrensninger:
- Begrensning på antall SATA-porter: Det er 10 SATA-porter totalt, men bruk av M.2 kan deaktivere to SATA-porter (SATA5 og SATA6), så vær oppmerksom på disktilkoblingene.
- Ytelsesgrense på SATA 6Gb/s: Selv om disse SSD-ene gir god ytelse, vil de fortsatt være begrenset til 6Gb/s per port, noe som er lavere enn M.2 NVMe-ytelsen.
-
Fordeler:
- Stor lagringskapasitet: Ideelt for "cold storage" eller mindre hastighetskrevende data, som backup, loggfiler, og arkiver.
- Bruk i ZFS pool med speiling eller RAIDZ: Kan brukes til ZFS RAIDZ for å sikre redundans og pålitelighet.
-
Begrensninger:
- Lavere ytelse enn SSD-er: SATA HDD-er vil være mye tregere enn både NVMe og SATA SSD-er, noe som gjør dem mindre egnet for I/O-intensive oppgaver.
- Kan bli flaskehalser: Ved bruk av disse i ZFS-pooler som krever høy IOPS, kan de påvirke totalytelsen negativt.
-
Fordeler:
- Allsidig bruk: Kan brukes som en backup-lagringsenhet, for lagring av ISO-er, mindre kritiske data, eller som cache for andre ZFS-pooler.
- Tilgjengelighet: Gir fleksibilitet for mindre viktige data uten å kaste bort høy ytelse på NVMe eller større SSD-er.
-
Begrensninger:
- Begrenset kapasitet: 500 GB kan være lite for store lagringsbehov eller intensive arbeidsbelastninger.
- Lavere ytelse enn NVMe: Raskere enn HDD-er, men tregere enn NVMe SSD.
-
M.2 NVMe SSD:
- Bruk som systemdisk for Proxmox, og tildele partisjoner til L2ARC og SLOG for ZFS-pooler. Dette gir rask tilgang til operativsystemet og akselererer lese-/skriveoperasjoner.
-
2 x 1.6 TB SSD-er:
- Konfigurer som en ZFS mirror (RAID1) eller RAIDZ1 for VM-lagring, som gir både ytelse og databeskyttelse.
-
2 x 1.2 TB SSD-er:
- Konfigurer som en annen ZFS-pool, dedikert til containere, eller som en utvidelse til den primære VM-poolen, avhengig av behov.
-
2 x 4 TB SATA HDD-er:
- Bruk som en ZFS RAIDZ2 pool for "cold storage," backups, eller arkiver. Dette gir redundans og utnytter den store kapasiteten til HDD-ene.
-
1 x 500 GB SSD (Samsung 850 EVO):
- Bruk som dedikert lagringsdisk for ISO-er, blåkopier, og annen mindre viktig data.
Dette oppsettet gir en god balanse mellom ytelse, kapasitet, og databeskyttelse. Ved å bruke M.2 NVMe SSD-en som systemdisk og cache, kombinert med ZFS RAID-konfigurasjoner på de andre SSD-ene og HDD-ene, maksimerer du ytelsen til kritiske oppgaver samtidig som du sikrer databeskyttelse og fleksibilitet for fremtidig vekst.
Begrensninger:
- Hovedkortets M.2 begrensning: Støtter ikke RAID-konfigurasjoner for NVMe og kan deaktivere SATA-porter.
- Ytelse på HDD-er: HDD-er vil være betydelig tregere enn SSD-er og bør kun brukes til lagringsoppgaver som ikke krever høy ytelse.
Ved å implementere både ZFS RAID1 (Mirror) for systemdisk og ZFS pool for andre disker, sammen med automatiserte backup-løsninger, får du et robust, fleksibelt og fremtidssikkert systemoppsett.
For å maksimere ytelsen, kapasiteten, og påliteligheten til Proxmox-laben din, samtidig som vi sørger for at systemet kan startes opp selv om M.2 NVMe SSD-en feiler, kan vi kombinere flere strategier. Her er en optimal lagringsplan som dekker alle de spesifikke kravene dine:
- Redundans: Sikre at labben kan boote opp og fungere hvis M.2 NVMe SSD feiler.
- Ytelsesoptimalisering: Utnytt M.2 NVMe SSD-en for å akselerere ZFS-pooler gjennom caching (L2ARC) og write log (SLOG).
- Effektiv bruk av RAM: Optimalisere for 32 GiB RAM nå, med mulighet for å oppgradere til 64 GiB RAM senere.
- Maksimal utnyttelse av tilgjengelig lagringskapasitet.
Enhet | Formål | Type RAID / Konfigurasjon | Størrelse | Beskrivelse |
---|---|---|---|---|
M.2 NVMe SSD (1 TB) | Systemdisk + Caching (L2ARC, SLOG) | ZFS RAID1 (Mirror) for systemdisk med SSDs | 100 GiB System, resten til Cache | Brukes til Proxmox OS, og som caching disk (L2ARC og SLOG) for å akselerere ZFS-pooler. |
2 x 1.6 TB SSD (zpool_vm) | VM Storage Pool | ZFS Mirror (RAID1) | 2 x 1.6 TB | Lagring for VM-er, speilet for databeskyttelse, og delt opp med en liten partisjon for redundant boot. |
2 x 1.2 TB SSD (zpool_cont) | Container Storage Pool | ZFS Mirror (RAID1) | 2 x 1.2 TB | Lagring for containere, speilet for databeskyttelse, med en liten partisjon for redundant boot. |
2 x 4 TB SATA HDD (zpool_cloudTier) | Cold Storage | ZFS RAIDZ1 eller RAIDZ2 | 2 x 4 TB | Kald lagring for sikkerhetskopier, arkiver, eller mindre I/O-krevende data. |
1 x 500 GB SSD (zpool_image) | ISO-er, Blueprints, Golden Images | ZFS Pool | 500 GB | Dedikert lagring for ISO-er, templates, og golden images. |
Vi skal dele opp M.2 NVMe SSD-en i partisjoner for å optimalisere både system- og cache-funksjonalitet.
Partisjon | Formål | Størrelse (32 GiB RAM) | Størrelse (64 GiB RAM) | Beskrivelse |
---|---|---|---|---|
/dev/nvme0n1p1 |
Proxmox System (ZFS root) | 100 GiB | 100 GiB | Dedikert til Proxmox VE-system og booting. |
/dev/nvme0n1p2 |
L2ARC for zpool_vm | 100 GiB | 150 GiB | Cache for VM-pool for raskere lesetilgang. |
/dev/nvme0n1p3 |
SLOG for zpool_vm | 20 GiB | 20 GiB | Write log for VM-pool for raskere synkron skriveytelser. |
/dev/nvme0n1p4 |
L2ARC for zpool_cont | 75 GiB | 100 GiB | Cache for container-pool for å øke lesehastigheten. |
/dev/nvme0n1p5 |
SLOG for zpool_cont | 20 GiB | 20 GiB | Write log for container-pool. |
/dev/nvme0n1p6 |
L2ARC for zpool_cloudTier | 75 GiB | 100 GiB | Cache for kald lagring for raskere lesehastighet. |
/dev/nvme0n1p7 |
SLOG for zpool_cloudTier | 10 GiB | 10 GiB | Write log for kald lagring om nødvendig. |
/dev/nvme0n1p8 |
L2ARC for zpool_image | 25 GiB | 50 GiB | Cache for ISO og image-pool. |
/dev/nvme0n1p9 |
SLOG for zpool_image | 10 GiB | 10 GiB | Write log for image-pool. |
Reservert plass | Fremtidig bruk / buffer | ~565 GiB | ~440 GiB | Resterende plass til fremtidige behov eller justeringer. |
-
RAID1 Speil av Proxmox Systemdisk på SSD-er:
- Bruk en partisjon på hver av "cluster"-diskene for å lage et speil for systemet.
- For eksempel:
-
På hver av 1.6TB SSD-ene (zpool_vm): Opprett en 100 GiB partisjon for ZFS system-mirror (
/dev/sda1
og/dev/sdb1
). -
På hver av 1.2TB SSD-ene (zpool_cont): Opprett en 100 GiB partisjon for ZFS system-mirror (
/dev/sdc1
og/dev/sdd1
).
-
På hver av 1.6TB SSD-ene (zpool_vm): Opprett en 100 GiB partisjon for ZFS system-mirror (
-
Installer Proxmox med ZFS Mirror for System:
- Under installasjonen, velg "ZFS RAID1 (Mirror)" og inkluder både M.2 NVMe SSD (
/dev/nvme0n1p1
) og de små partisjonene på "cluster"-diskene (/dev/sda1
,/dev/sdb1
,/dev/sdc1
,/dev/sdd1
).
- Under installasjonen, velg "ZFS RAID1 (Mirror)" og inkluder både M.2 NVMe SSD (
-
Installer GRUB Bootloader på Alle Disker:
- Etter installasjonen, installer GRUB bootloader på alle diskene som deltar i RAID1 speilet:
grub-install /dev/nvme0n1 grub-install /dev/sda grub-install /dev/sdb grub-install /dev/sdc grub-install /dev/sdd
- Etter installasjonen, installer GRUB bootloader på alle diskene som deltar i RAID1 speilet:
-
Konfigurer ZFS Pools og Cache:
- Konfigurer cache og logg ved å legge til partisjoner fra M.2 NVMe SSD:
zpool add zpool_vm cache /dev/nvme0n1p2 zpool add zpool_vm log /dev/nvme0n1p3 zpool add zpool_cont cache /dev/nvme0n1p4 zpool add zpool_cont log /dev/nvme0n1p5 # Og så videre for alle pools
- Redundant Systemdisk: Hvis M.2 NVMe SSD feiler, kan systemet fortsatt boote fra de alternative SSD-ene.
- Optimal Ytelse med Cache: NVMe SSD-en fungerer som cache og log for alle ZFS-pooler, noe som forbedrer lese- og skriveytelsen betraktelig.
- Effektiv Utnyttelse av Kapasitet: Maksimerer lagringskapasiteten samtidig som dataintegriteten og gjenopprettingsmulighetene opprettholdes.
- Fleksibel RAM-bruk: Tilpasset for 32 GiB RAM, men klar til å skalere til 64 GiB RAM senere uten behov for omkonfigurering.
Dette oppsettet gir en robust, høyytelsesløsning for Proxmox-laben din med redundans, ytelsesoptimalisering, og fremtidig vekst i tankene.
Ja, det kan absolutt være en god idé å utnytte den uparisjonerte delen av M.2 NVMe-disken ved å opprette små partisjoner (for eksempel på 5 GiB hver) som kan brukes som en dedikert disk for Windows pagefile. Dette kan gi betydelig bedre ytelse for Windows-servere eller -klienter, spesielt for applikasjoner som er I/O-intensive eller som krever mye virtuelt minne.
-
Raskere Lesing og Skriving:
- Siden NVMe-disken har mye høyere lese- og skrivehastigheter enn de fleste andre disker i systemet, kan det å ha pagefile på NVMe-disken forbedre ytelsen betydelig, spesielt for applikasjoner som bruker mye swapminne.
-
Reduserte Ventetider:
- Med en dedikert 5 GiB partisjon for pagefile på M.2 NVMe vil du redusere I/O-køer og latens som normalt oppstår når flere applikasjoner konkurrerer om tilgang til samme disk. Dette kan gi en merkbar forbedring i systemresponsen.
-
Bedre Bruk av Cache og SLOG:
- Hvis pagefile er på M.2, vil de andre ZFS-poolene få bedre ytelse for sine normale lese- og skriveoperasjoner, siden NVMe-disken tar seg av det mest I/O-intensive arbeidet (swap-operasjoner).
-
Mindre Slitasje på Andre Diskenheter:
- Ved å bruke M.2 NVMe-disken for pagefile reduseres den konstante skrivingen og lesingen på de andre SSD-ene i systemet, noe som kan forlenge levetiden deres.
Med over 400 GiB uparisjonert plass på M.2 NVMe-disken, kan vi opprette flere små partisjoner på 5 GiB hver som kan brukes til Windows pagefile.
For eksempel, for å opprette de første to 5 GiB partisjonene:
parted /dev/nvme0n1 mkpart primary 530GiB 535GiB # 1. 5 GiB Partisjon
parted /dev/nvme0n1 mkpart primary 535GiB 540GiB # 2. 5 GiB Partisjon
Gjenta for så mange 5 GiB partisjoner som du tror kan være nyttige.
Når du oppretter eller redigerer en Windows VM i Proxmox, gjør følgende:
-
Legg til en ny Virtuell Disk:
- Gå til VM-konfigurasjonen i Proxmox.
- Klikk på "Add" -> "Hard Disk".
- Velg
nvme0n1pX
(en av 5 GiB partisjonene) som lagringssted. - Angi disktypen som "VirtIO Block" eller "SCSI" for bedre ytelse.
-
Konfigurer Windows for å bruke den nye disken som Pagefile:
- Start VM-en og logg inn på Windows.
- Gå til "System Properties" -> "Advanced" -> "Performance Options".
- Under "Virtual Memory", velg "Change", og tilordne den nye P:-disken til å bruke en fast pagefile-størrelse (for eksempel 4096–5120 MB).
-
Fordeler:
- Optimal ytelse: Windows vil bruke NVMe-disken for å håndtere pagefile-operasjoner ekstremt raskt, noe som gir bedre total systemytelse.
- Isolert I/O: Pagefile-aktivitet vil ikke påvirke ytelsen til resten av systemet, siden den er isolert på en egen rask disk.
- Fleksibilitet: Du kan bruke flere slike partisjoner for ulike VM-er avhengig av behovet.
-
Begrensninger:
- Begrenset plass på M.2 NVMe: Mens 400 GiB uparisjonert plass gir rikelig med rom for å lage flere 5 GiB partisjoner, må du sørge for at du ikke bruker opp all plassen, spesielt hvis det er andre planlagte behov.
- Partisjonsadministrasjon: Å administrere mange små partisjoner kan bli komplekst, og du bør ha en klar plan for hvordan disse partisjonene brukes og administreres.
Ja, ved å dedikere små partisjoner (5 GiB) på M.2 NVMe SSD-en som pagefile disker for Windows VM-er, kan du gi betydelige ytelsesforbedringer, spesielt på systemer med begrenset RAM. Dette kan redusere I/O-flaskehalser, optimalisere bruk av tilgjengelig RAM, og forlenge levetiden til de andre SSD-ene ved å redusere deres skrivebelastning.
Denne strategien gir deg både fleksibilitet og ytelsesfordeler i labmiljøet ditt.
Ja, hvis du planlegger å kjøre mer krevende Linux-baserte løsninger som Kubernetes eller Red Hat OpenShift, kan det også være gunstig å bruke dedikerte partisjoner på M.2 NVMe-disken for spesifikke områder som swap og andre I/O-intensive områder. Dette vil gi bedre ytelse og redusere ventetid for disse applikasjonene, spesielt under høy belastning.
-
Raskere Swap-ytelse:
- Ved å bruke en dedikert partisjon for swap på NVMe-disken, kan du drastisk forbedre ytelsen for VM-er som opplever hyppig bruk av swap. Dette gjelder spesielt for Kubernetes-mastere og noder, samt OpenShift-kontrollplaner som kan ha behov for ekstra minne under belastning.
-
Forbedret I/O-ytelse for Spesifikke Kataloger:
- Linux-klynger som Kubernetes og OpenShift bruker flere kataloger som er kritiske for ytelse, som kan dra nytte av raskere lagring. Eksempler på slike kataloger inkluderer:
-
/var/lib/docker
eller/var/lib/containers
: Lagrer container-images og metadata for Docker eller CRI-O (Container Runtime Interface). -
/var/log
: Lagrer loggfiler, som kan vokse raskt og kreve rask skriving og lesing for å unngå at systemytelsen svekkes. -
/etc/kubernetes
: Lagrer konfigurasjonsfiler for Kubernetes, som bør ha rask tilgang for optimal kontrollflyt.
-
- Ved å bruke dedikerte partisjoner på NVMe-disken for disse katalogene, kan du optimalisere ytelsen til container-tjenester og kontrollplaner.
- Linux-klynger som Kubernetes og OpenShift bruker flere kataloger som er kritiske for ytelse, som kan dra nytte av raskere lagring. Eksempler på slike kataloger inkluderer:
-
Redusert Belastning på Primære SSD-er:
- Ved å flytte I/O-intensive operasjoner til NVMe-disken, reduserer du belastningen på de primære SSD-ene (som er i bruk for VM-lagring eller container-pooler). Dette kan forlenge levetiden til de eldre SSD-ene.
For å maksimere ytelsen til Kubernetes, OpenShift, og andre Linux-baserte VM-er, kan du sette opp dedikerte partisjoner for følgende formål:
Partisjon | Formål | Størrelse | Beskrivelse |
---|---|---|---|
/dev/nvme0n1pX (swap) |
Dedikert Swap-partisjon for Linux VM-er | 8 GiB | Rask swap for Linux VM-er, spesielt nyttig for Kubernetes-mastere og noder, eller OpenShift-kontrollplaner under høy belastning. |
/dev/nvme0n1pY (/var/lib/docker) |
Dedikert partisjon for Docker eller CRI-O storage | 20-50 GiB | Rask lagring for Docker eller CRI-O containers, som kan forbedre ytelsen for container images, lagring, og metadata. |
/dev/nvme0n1pZ (/var/log) |
Dedikert partisjon for Logs | 5-10 GiB | Rask logglagring for applikasjoner som skriver hyppig til disk, for å sikre at logging ikke forsinker andre operasjoner. |
/dev/nvme0n1pW (/etc/kubernetes) |
Dedikert partisjon for Kubernetes Config | 2 GiB | Rask lagring for Kubernetes-konfigurasjonsfiler, som gir raskere tilgang til essensiell konfigurering av kontrollplanen og administrasjon. |
-
Opprett Partisjonene på M.2 NVMe Disk:
- Bruk
parted
ellerfdisk
til å opprette de nødvendige partisjonene for hvert av formålene:parted /dev/nvme0n1 mkpart primary linux-swap 565GiB 573GiB # 8 GiB for Swap parted /dev/nvme0n1 mkpart primary ext4 573GiB 623GiB # 50 GiB for /var/lib/docker parted /dev/nvme0n1 mkpart primary ext4 623GiB 633GiB # 10 GiB for /var/log parted /dev/nvme0n1 mkpart primary ext4 633GiB 635GiB # 2 GiB for /etc/kubernetes
- Bruk
-
Monter Partisjonene i Linux VM-en:
- Når VM-en er oppe, bruk
fstab
for å montere partisjonene til de nødvendige katalogene. - Legg til disse linjene i
/etc/fstab
:/dev/nvme0n1pX swap swap defaults 0 0 /dev/nvme0n1pY /var/lib/docker ext4 defaults 0 2 /dev/nvme0n1pZ /var/log ext4 defaults 0 2 /dev/nvme0n1pW /etc/kubernetes ext4 defaults 0 2
- Når VM-en er oppe, bruk
-
Formater og Aktiver Partisjonene:
- Kjør formatering og aktivering av partisjonene:
mkswap /dev/nvme0n1pX swapon /dev/nvme0n1pX mkfs.ext4 /dev/nvme0n1pY mkfs.ext4 /dev/nvme0n1pZ mkfs.ext4 /dev/nvme0n1pW
- Kjør formatering og aktivering av partisjonene:
-
Bruk i Kubernetes eller OpenShift:
- Nå kan du bruke disse partisjonene til spesifikke oppgaver i Kubernetes eller OpenShift for å maksimere ytelsen, redusere forsinkelser, og sikre optimal drift.
- Optimalisert Swap-bruk: Swap-partisjonen på NVMe vil gi rask tilgang til virtuelt minne, noe som gir bedre respons for Linux VM-er under høy belastning.
- Forbedret Container-ytelse: Dedikerte partisjoner for container-lagring, logger, og konfigurasjonsfiler sikrer raskere I/O og mer pålitelig drift for container-plattformer.
- Redusert Belastning på Andre Diskenheter: Mindre I/O-operasjoner på de eldre SSD-ene, noe som kan forlenge levetiden deres.
Å bruke M.2 NVMe-disken til dedikerte partisjoner for swap, container-lagring, logger, og andre spesifikke områder gir betydelige fordeler når du kjører tunge arbeidsbelastninger som Kubernetes eller OpenShift. Dette gir ikke bare bedre ytelse, men også bedre ressursutnyttelse og lengre levetid for resten av lagringssystemet ditt.
Ja, det er mulig for Proxmox VE å utnytte en del av M.2 NVMe-disken til å kompensere for manglende fysisk RAM ved å bruke swap-områder eller ved å overprovisionere minne til VM-er og containere. Dette kan gi deg muligheten til å kjøre flere arbeidsbelastninger enn det den fysiske RAM-en alene ville tillate, ved å bruke M.2 som en rask sekundær lagringsenhet for swapminne.
-
Bruke Swap på M.2 NVMe:
- Proxmox VE (som en Debian-basert distribusjon) støtter bruk av swap-partisjoner eller swap-filer for å gi ekstra "virtuelt minne". Dette kan hjelpe når du har begrenset fysisk RAM, slik at systemet kan lagre deler av minneinnholdet på disk.
-
Overprovisionering med Virtuell RAM til VM-er og Containere:
- I Proxmox kan du overprovisionere RAM for VM-er og containere ved å tildele mer minne enn det som faktisk er fysisk tilgjengelig, basert på antagelsen om at ikke alle VM-er eller containere vil bruke sitt maksimale minne samtidig. Swap på NVMe kan brukes til å håndtere "spikes" i minneforbruket.
Du kan opprette en dedikert swap-partisjon på M.2 NVMe-disken. Dette kan gjøres ved å bruke parted
eller fdisk
for å opprette en ny partisjon på den ubrukte delen av NVMe-disken.
Eksempel for å opprette en swap-partisjon på 32 GiB:
parted /dev/nvme0n1 mkpart primary linux-swap 635GiB 667GiB # 32 GiB Swap Partisjon
Formater og aktiver swap-partisjonen:
mkswap /dev/nvme0n1pX # Hvor 'X' er partisjonsnummeret for swap
swapon /dev/nvme0n1pX
Rediger /etc/fstab
for å legge til swap-partisjonen slik at den automatisk monteres ved oppstart:
/dev/nvme0n1pX none swap sw 0 0
-
For VM-er:
- I Proxmox GUI, kan du konfigurere Ballooning for VM-er:
- Naviger til VM > Hardware > Memory og aktiver Ballooning Device.
- Dette tillater Proxmox å justere den faktiske RAM-bruken til VM-en dynamisk, basert på tilgjengelig fysisk RAM og swap.
- I Proxmox GUI, kan du konfigurere Ballooning for VM-er:
-
For Containere (LXC):
- Du kan spesifisere minnebegrensninger i konfigurasjonen for hver container.
- Legg til swap-støtte for containere ved å sette
swap
-parametere i containerens konfigurasjonsfil (/etc/pve/lxc/<CTID>.conf
):
memory: 2048 # 2 GiB RAM swap: 4096 # 4 GiB swap
Dette tildeler en container 2 GiB fysisk RAM, med mulighet for å bruke opptil 4 GiB swap hvis nødvendig.
-
Høy Ytelse for Swap:
Swap-områder på NVMe-disker vil være mye raskere enn på SATA SSD-er eller HDD-er, noe som betyr at systemet kan håndtere minnebelastning bedre når det er behov for å bruke swap. -
Reduserer Belastningen på Andre Disker: Swap-operasjoner kan flyttes bort fra SSD-pooler (zpool_vm og zpool_cont), som ellers brukes til VM- og containerlagring. Dette optimaliserer I/O-ytelsen for begge.
-
Større Minnekapasitet Utover Fysisk RAM: Med en dedikert swap på NVMe kan systemet håndtere mer arbeid enn det den fysiske RAM-en alene ville tillatt. Dette er nyttig for scenarier hvor flere arbeidsbelastninger kjører samtidig, og det er behov for "overprovisionering".
-
Ytelsesforskjell Mellom RAM og NVMe:
Selv om NVMe er raskt, vil det fortsatt være mye tregere enn ekte RAM. Swap på disk kan redusere ytelsen for applikasjoner som er veldig minneintensive eller avhengige av lav latens. -
Slitasje på NVMe-disken:
Selv om NVMe-disken er rask, vil hyppig bruk av swap føre til økt slitasje på disken over tid, da NAND-flashminne har en begrenset mengde skriv/lese-sykluser. -
Økt Responsforsinkelse:
Bruk av swap kan øke responstiden for applikasjoner når systemet begynner å bruke swap i stor skala. Dette kan påvirke brukeropplevelsen, spesielt i interaktive applikasjoner.
Ja, du kan bruke deler av M.2 NVMe-disken som swap for å overprovisionere systemets fysiske RAM. Dette vil tillate deg å kjøre flere eller tyngre VM-er og containere på begrenset fysisk minne. For maksimal ytelse, bruk swap på NVMe kun som en midlertidig løsning for å håndtere spikende arbeidsbelastninger, og sørg for at swap brukes strategisk for spesifikke VM-er eller containere som kan dra nytte av det.
Ja, når jeg nevnte "midlertidig" i sammenheng med bruk av M.2 NVMe som swap, mente jeg det som en løsning som kan brukes når systemet har behov for mer minne enn det som er fysisk tilgjengelig, uten å bytte ut CPU eller oppgradere til mer RAM.
Men du kan absolutt konfigurere Proxmox til å bruke swap på M.2 NVMe kun når det er nødvendig – det vil si når den fysiske RAM-en (opptil 64 GiB) er i ferd med å bli oppbrukt. Dette kan bidra til å forbedre ytelsen og forhindre at systemet blir tregt eller ustabilt under høy belastning.
Linux (og dermed Proxmox VE) bruker swap når fysisk RAM er fullt. Swap er mye tregere enn RAM, men med NVMe-disk vil denne ytelsen være langt bedre enn med tradisjonelle SSD-er eller HDD-er. Proxmox vil alltid prioritere fysisk RAM først, men vil bruke swap som "nødutgang" når RAM er oppbrukt.
Hvis du allerede har en swap-partisjon på M.2 NVMe (som beskrevet tidligere), kan du justere bruken av denne swapen ved hjelp av swappiness
.
-
Kontroller Swap-konfigurasjonen: Sjekk om swap-partisjonen er aktiv og dens nåværende størrelse.
swapon --show free -h
-
Juster
swappiness
-parameteren for å Kontrollere Swap-bruk:
swappiness
er en parameter i Linux-kjernen som bestemmer hvor aggressivt systemet bruker swap i stedet for fysisk RAM. Verdien varierer fra 0 til 100:
- 0: Swap brukes kun når RAM er helt oppbrukt.
- 60 (standard): Moderat bruk av swap for å forhindre full RAM-bruk.
- 100: Swap brukes så mye som mulig, sammen med RAM.
Justere swappiness
:
Reduser swappiness
for å sikre at swap kun brukes som en siste utvei når RAM er nesten oppbrukt:
Åpne filen /etc/sysctl.conf
med en teksteditor:
nano /etc/sysctl.conf
Legg til eller endre følgende linje for å sette swappiness
til 10 (som betyr at swap brukes svært lite):
vm.swappiness=10
Lagre filen og bruk den nye innstillingen:
sysctl -p
Dette vil redusere bruken av swap til et minimum og tvinge Proxmox til å bruke fysisk RAM først.
Bruk verktøy som htop
, vmstat
, eller free
til å overvåke RAM- og swap-bruken over tid. Dette vil hjelpe deg med å se når swap blir brukt og om swappiness
-innstillingene trenger å justeres ytterligere.
Med den nye konfigurasjonen vil swap på M.2 NVMe-disken:
- Kun bli brukt når RAM er nesten full, noe som gir bedre kontroll over systemytelsen.
- Gi muligheten til å kjøre flere VM-er og containere enn det fysiske RAM alene ville tillatt, uten at systemet blir tregt.
- Sørge for at swap brukes strategisk for å håndtere korte perioder med høy minnebruk.
-
Aktiver Overcommit Memory: Linux har en funksjon kalt overcommit som gjør at systemet kan tildele mer minne enn det faktisk har, basert på statistiske sannsynligheter for at ikke alle prosesser vil bruke sitt tildelte minne samtidig. Dette kan justeres i
/etc/sysctl.conf
:vm.overcommit_memory=1
-
Unngå Unødvendig Swap-bruk: For applikasjoner eller VM-er som krever høy ytelse og ikke tåler forsinkelser, kan du manuelt justere innstillingene for minnebruk og swap-begrensninger.
Ved å sette swappiness
til en lav verdi (som 10), kan du konfigurere Proxmox til å bruke swap på M.2 NVMe kun når det er absolutt nødvendig. Dette gir deg en løsning som lar deg kjøre flere VM-er og arbeidsbelastninger enn den tilgjengelige RAM-en skulle tilsi, samtidig som systemytelsen holdes optimal.