Hardware-guide til virtualisering: Optimering af servere

Hvilken processor (CPU) er bedst til virtualisering?

En processor til virtualisering skal prioritere høj kerne-tæthed og understøttelse af hardware-assisteret virtualisering frem for rå clock-frekvens. Dette skyldes, at en hypervisor som VMware ESXi eller Microsoft Hyper-V fungerer som et abstraktionslag, der fordeler CPU-ressourcer til flere virtuelle maskiner (VMs). Jo flere fysiske kerner og tråde processoren har, desto flere arbejdsbelastninger kan køre parallelt uden at skabe kø i processor-køen. For virksomheder er AMD EPYC og Intel Xeon de primære valg på grund af deres massive mængder af kerner og understøttelse af store mængder RAM.

Kerne-tæthed vs. Clock-frekvens

I et virtualiseret miljø er det mere fordelagtigt at have 64 kerner ved 2,5 GHz end 16 kerner ved 5,0 GHz. Dette skyldes vCPU (virtual CPU) allokering, hvor man ofte over-allokerer ressourcer. En høj kerne-tæthed reducerer risikoen for 'CPU Ready' ventetid, hvilket opstår, når en VM venter på adgang til en fysisk kerne.

Hardware-assisteret virtualisering og BIOS

For at kunne køre virtuelle maskiner skal specifikke instruktionssæt være aktiveret i bundkortets BIOS. Uden disse kan hypervisoren ikke effektivt styre hardwaren, hvilket resulterer i enten manglende boot eller ekstremt lav ydeevne.

• Intel VT-x / AMD-V: Grundlæggende hardware-acceleration der tillader CPU'en at køre flere operativsystemer samtidigt.
• Intel VT-d / AMD-Vi (IOMMU): Gør det muligt for en VM at få direkte adgang til fysisk hardware, såsom et specifikt netværkskort eller GPU.
• SLAT (Second Level Address Translation): Også kendt som EPT (Extended Page Tables) hos Intel og NPT (Nested Page Tables) hos AMD. Hyper-V kræver en 64-bit processor med SLAT aktiveret i BIOS for at fungere korrekt.

For yderligere indsigt i moderne CPU-arkitekturer kan du læse vores AMD EPYC guide til datacentre, AI og cloud-infrastruktur.

Hvordan dimensionerer man RAM korrekt til virtualisering?

RAM er typisk den første ressource, der bliver en flaskehals i et virtuelt miljø, da hukommelse ikke kan over-allokeres på samme måde som CPU-cyklusser uden markante ydelsestab. For at sikre stabilitet skal man dimensionere RAM med en betydelig margin og udelukkende anvende ECC RAM (Error-Correcting Code). ECC RAM detekterer og retter enkelt-bit fejl i realtid, hvilket er essentielt, da en enkelt hukommelsesfejl ellers kan crashe hele den fysiske host og dermed alle 20 eller flere virtuelle maskiner, der kører på den.

Kapacitet og ECC RAM

I modsætning til almindelig desktop-RAM, hvor en fejl blot fører til et systemnedbrud for én bruger, er konsekvensen i et datacenter katastrofal. Det anbefales stærkt at bruge ECC RAM til produktionsvirtualisering for at undgå bit-flips, der kan korrumpere data på tværs af flere VM'er.

Vigtigheden af Multi-channel arkitektur

For at undgå båndbredde-flaskehalse skal RAM-kanalerne udfyldes korrekt i overensstemmelse med processorens specifikationer. Hvis en CPU understøtter 8 kanaler, men man kun installerer 2 moduler, reduceres den samlede hukommelsesbåndbredde drastisk. Dette påvirker især VM'er med høj I/O-belastning eller databaser.

1. Identificér antallet af hukommelseskanaler på CPU'en (f.eks. 8 eller 12).
2. Installer RAM-moduler i sæt, der matcher kanal-antallet for at maksimere båndbredden.
3. Sørg for at bruge identiske moduler (samme hastighed og kapacitet) for at undgå nedgradering til den langsomste modul.

Hvis du overvejer at opgradere eksisterende hardware, kan vores guide til opgradering af CPU, bundkort og RAM give nyttig viden om kompatibilitet.

Hvilken storage-arkitektur er nødvendig for høj ydeevne?

Storage-ydeevnen i virtualisering måles ikke på kapacitet (GB/TB), men på IOPS (Input/Output Operations Per Second). Når mange virtuelle maskiner skriver til disk samtidigt, opstår der et fænomen kaldet 'I/O blender', hvor sekventielle skrivninger bliver til tilfældige skrivninger. Traditionelle mekaniske harddiske (HDD) kan ikke håndtere dette og vil skabe massive ventetider. Løsningen er NVMe- eller enterprise SAS-SSD'er, der leverer tusindvis af gange flere IOPS end HDD'er.

IOPS og SSD-valg

Til virtualisering kræves drives med høj udholdenhed (DWPD - Drive Writes Per Day). For eksempel kræver hukommelseslagring (memory tiering) med NVMe drives mindst 100.000 skrivninger per sekund og DWPD >=3 for at sikre, at diskene ikke slides op på kort tid under intensive skriveoperationer.

RAID-konfigurationer og redundans

For at kombinere fart med datasikkerhed anvendes RAID. I virtualiseringsmiljøer er RAID 10 det foretrukne valg, da det giver både spejling (redundans) og striping (ydeevne). RAID 6 kan overvejes til større datamængder, hvor kapacitet prioriteres over skrivestyrke.

• RAID 10: Bedste ydeevne og hurtig recovery. Kræver mange diske, men eliminerer paritets-overhead.
• RAID 6: Tåler fejl på to samtidige diske, men har langsommere skrivning pga. paritetsberegning.

SAN vs. Lokal Storage (vSAN)

Valget mellem lokal lagring og et SAN (Storage Area Network) afhænger af ønsket om High Availability. Lokalt lager (Direct Attached Storage) er hurtigere og billigere, men binder VM'en til den fysiske server. Et centraliseret SAN gør det muligt at flytte kørende virtuelle maskiner mellem servere uden nedetid via funktioner som VMware vMotion.

For en dybere forståelse af lagringsløsninger kan du se vores NAS server guide: Specifikationer, RAID og brug.

Hvordan skal netværket konfigureres for at undgå flaskehalse?

En virtualiseringsserver kræver betydeligt mere båndbredde end en standard server, da ét fysisk netværksstik skal bære trafikken for potentielt hundreder af virtuelle netværkskort. For at sikre stabil drift bør serveren udstyres med flere 10 GbE (eller hurtigere) porte. Disse porte bør dedikeres til specifikke trafiktyper for at undgå, at en stor backup-job blokerer for brugernes adgang til deres virtuelle maskiner.

Trafiksegmentering og port-dedikation

Det er best practice at opdele netværkstrafikken i logiske eller fysiske segmenter. Dette sikrer, at administrationstrafik altid har prioritet over datatrafik, hvilket forhindrer 'network starvation' under høj belastning.

NIC Teaming og Redundans

For at eliminere 'Single Point of Failure' anvendes NIC Teaming (også kaldet bonding). Her parres to eller flere fysiske netværkskort, så de fungerer som én logisk forbindelse. Hvis et kabel knækker, eller en switch-port dør, overtager det andet kort trafikken øjeblikkeligt uden afbrydelse for de virtuelle maskiner.

• Load Balancing: Fordeler trafikken over alle aktive kort for at øge den samlede båndbredde og reducere latency.
• Failover: Ét kort er aktivt, mens det andet står i standby og kun aktiveres ved fejl på primærforbindelsen.

For virksomheder der bygger større infrastrukturer, kan vores købsguide til servere hjælpe med at vælge den rette chassis-konfiguration.

Hvordan sikrer man High Availability (HA) i hardwaren?

High Availability (HA) handler om at sikre, at virksomhedens systemer forbliver online, selvom en fysisk komponent svigter. Da virtualisering konsoliderer mange tjenester på få maskiner, øges risikoen ved et enkelt nedbrud markant. Derfor skal hardwaren bygges med fuld redundans i alle kritiske led, herunder strømforsyning og køling, så ingen enkelt fejl kan tage hele infrastrukturen med i faldet.

Dual Power Supplies (PSU)

En server til virtualisering skal altid have mindst to uafhængige strømforsyninger. For at opnå reel redundans bør disse PSU'er tilsluttes hver sin strømkreds og ideelt set hver sin UPS (Uninterruptible Power Supply). Hvis den ene strømforsyning brænder sammen, eller en sikring går i det ene el-panel, fortsætter serveren med at køre uden afbrydelse.

Hardware-kompatibilitet og VCG

En af de mest oversete faktorer i virtualiseringshardware er officiel support. Det er ikke nok, at en komponent virker; den skal være certificeret til den specifikke version af hypervisoren. VMware tilbyder f.eks. deres VMware Compatibility Guide (VCG/HCL), hvor man kan tjekke om et specifikt netværkskort eller en RAID-controller er understøttet.

Hvis man installerer ikke-certificeret hardware, risikerer man:

• Manglende drivere i hypervisoren (f.eks. ESXi), hvilket gør hardwaren ubrugelig.
• Uforklarlige 'Purple Screen of Death' (PSOD) nedbrud pga. driver-konflikter mellem firmware og kernel.
• Afvisning af support fra softwareleverandøren ved kritiske fejl, da systemet ikke er valideret.

For dem der bygger high-end systemer til AI og virtualisering, kan vores AI-server guide give indsigt i hvordan GPU'er integreres i disse miljøer.

Hvilke budgetklasser og konfigurationer findes til virtualisering?

Valget af hardware-budget afhænger primært af den ønskede VM-densitet (antal virtuelle maskiner per host) og kravene til oppetid. Mens mindre virksomheder kan nøjes med en enkelt kraftig server i budgetklassen, kræver enterprise-miljøer klynger af servere for at opnå fuld High Availability. Prisdifferencen ligger ofte ikke kun i rå ydeevne, men i redundans og supportaftaler.

Budget vs. Enterprise konfigurationer

En budgetløsning fokuserer på at maksimere antallet af kerner og RAM per krone, mens en enterprise-løsning prioriterer fejltolerance og skalering. I budgetklassen ser man ofte brug af enkelte store servere med lokal storage, hvorimod enterprise-segmentet anvender SAN og redundante switches.

Detaljerede konfigurationsscenarier

For at vælge den rette klasse bør man analysere de specifikke arbejdsbelastninger. En lille virksomhed, der kun kører en Active Directory-server og en filserver, kan klare sig med budgetklassen. En mellemstor virksomhed med VDI (Virtual Desktop Infrastructure) til 50 brugere vil kræve mellemklassen for at undgå storage-flaskehalse.

• Budgetscenarie: Ideelt til testmiljøer eller små kontorer. Fokus er på en enkelt kraftig maskine med lokal NVMe lagring i RAID 1 for basal redundans.
• Mellemklassescenarie: Velegnet til produktionsmiljøer uden krav om 99,99% oppetid. Her implementeres Dual PSU og NIC Teaming for at sikre mod hardwarefejl.
• Enterprisescenarie: Designet til mission-critical systemer. Her anvendes SAN (Storage Area Network) og klynger af servere, så en hel fysisk host kan brænde sammen uden at tjenesterne går ned.

Når man planlægger budgettet, bør man overveje 'vertical scaling' (opgradering af eksisterende server) kontra 'horizontal scaling' (tilføjelse af flere servere). Horizontal scaling er generelt sikrere i virtualiserede miljøer, da det reducerer skadesomfanget ved et hardwarenedbrud. Hvis én server i en klynge på fire dør, mister man kun 25 % af kapaciteten.

For dem der har brug for ekstrem ydeevne til specifikke opgaver, kan en professionel workstation være et alternativ til mindre virtualiseringsbehov.

Hvilket tilbehør og kabling er kritisk for serverstabilitet?

Stabiliteten af en virtualiseringsserver afhænger ikke kun af interne komponenter, men også af den fysiske infrastruktur omkring den. Forkert kabling eller mangelfuld strømstyring kan føre til uforklarlige genstarter eller netværksudfald, som er ekstremt kritiske i et miljø med høj VM-densitet. Investering i kvalitetstilbehør reducerer risikoen for fysiske fejl markant.

Strømstyring og UPS

Da virtualiseringsservere ofte kører med Dual PSU, er det vigtigt at bruge to separate strømkilder. En UPS (Uninterruptible Power Supply) bør være dimensioneret til at holde alle servere kørende længe nok til en kontrolleret shutdown af alle virtuelle maskiner via hypervisorens API.

Netværksinfrastruktur og Switches

For at udnytte 10 GbE NICs skal switchen understøtte samme hastighed og have tilstrækkelig bufferkapacitet. I virtualiseringsmiljøer anbefales det at bruge switches, der understøtter LACP (Link Aggregation Control Protocol) for at muliggøre effektiv NIC Teaming på tværs af fysiske porte.

Hvis du bygger mindre løsninger til kontorbrug, kan en Mini PC være relevant, men husk at disse sjældent understøtter de nødvendige enterprise-funktioner som ECC RAM eller Dual PSU.

Typiske fejl ved hardware til virtualisering

1. Overprioritering af clock-frekvens: Mange køber CPU'er med høj GHz, men for få kerner. Dette fører til CPU Ready-problemer, hvor VM'erne venter på processortid. For en database-server betyder det markant øget svartid (latency), selvom den samlede CPU-udnyttelse ser lav ud.
2. Brug af Non-ECC RAM: At spare på hukommelsen ved at bruge standard RAM i en server med 10+ VM'er er en stor risiko. En enkelt bit-flip kan crashe alle tjenester samtidigt, hvilket fører til totalt driftstab for hele virksomheden og potentielt datatab i ikke-synkroniserede databaser.
3. Underestimering af IOPS: Installation af virtuelle maskiner på traditionelle HDD'er eller billige consumer SSD'er uden DWPD-garanti fører til ekstremt langsomme boot-tider. I VDI-miljøer vil dette resultere i 'boot storms', hvor systemet fryser, når alle brugere logger på samtidigt kl. 08:00.
4. Manglende BIOS-konfiguration: At glemme at aktivere Intel VT-x/AMD-V eller SLAT i BIOS resulterer i, at hypervisoren enten slet ikke kan starte eller er ude af stand til at køre 64-bit VM'er, hvilket tvinger administratoren til at genstarte og rekonfigurere hele systemet.
5. Ignorering af kompatibilitetslister: Køb af hardware baseret på generelle specifikationer frem for officielle lister som VMware Compatibility Guide fører ofte til driver-konflikter. Dette kan manifestere sig som uforklarlige 'Purple Screen of Death' (PSOD) nedbrud, der er ekstremt svære at fejlfinde uden officiel support.