AMD EPYC Turin: Sådan vælger du den rigtige server-CPU til hostingudbydere

At sætte AMD EPYC Turin i den rette sammenhæng

AMD EPYC Turin betegner EPYC 9005-generationen af serverprocessorer. AMD præsenterede dem i oktober 2024 som den femte generation af EPYC; serien omfatter modeller med Zen-5- og Zen-5c-kerner.

For hostingudbydere er Turin ikke blot en enkelt CPU med ensartede ydeevneegenskaber. Modellerne spænder fra otte til 192 kerner pr. processor. Hvilken model der passer bedst, afhænger af, om der kører mange uafhængige kundeforespørgsler sideløbende, om enkelte applikationer kræver korte responstider, eller om virtuelle maskiner først og fremmest kræver meget arbejdshukommelse.

Valget omfatter også spørgsmålet om Sokkelnummer: En server med én processor tilbyder en anden kombination af regnekapacitet, hukommelsesforbindelse og udvidelsesmuligheder end en platform med to sokler. Ikke alle modeller er beregnet til begge varianter; processorer med suffikset »P« er ifølge databladet designet til systemer med én sokkel.

En forudgående udvælgelse tager derfor udgangspunkt i den konkrete kundesammensætning og kravene til RAM, NVMe-drev og netværk. En tætpakket VPS-host har for eksempel brug for reserver til samtidigt aktive virtuelle maskiner, mens en databaseserver desuden kan reagere på lagerbehov og I/O. Også softwarelicenser og serverproducentens godkendelser indgår i planlægningen.

Flere kerner alene siger ikke noget om, hvor mange eksisterende værter der kan erstattes. Til det har udbyderen brug for sammenlignelige belastningsprofiler og måleværdier for den eksisterende hosting-hardware samt en fastlagt reservekapacitet i tilfælde af nedbrud. Uden dette grundlag er det muligt at vælge en model, men det er ikke muligt at fastlægge en pålidelig konsolideringsgrad.

At forstå kerner, chiplets og klokfrekvens

Torino bruger en Chiplet-design: Regneenhederne og en separat I/O-die er forbundet via AMD Infinity Fabric. I/O-dien sørger blandt andet for forbindelserne til arbejdshukommelsen samt til ind- og udlæsning. I praksis betyder det for serverplanlægningen, at det ikke kun er kernerne, men også tilslutningen til de fælles ressourcer, der tæller.

Zen 5 og Zen 5c adskiller sig i deres udformning og kerneopbygning. Zen 5c giver den højeste kernetæthed inden for denne generation; dette betyder dog ikke, at der er en generel rangorden med hensyn til ydeevne. En stærkt paralleliseret VM-sammensætning og en applikation med få latenstidsfølsomme opgaver kan gøre forskellige modeller mere velegnede.

EPYC 9965 har 192 Zen-5c-kerner og 384 tråde, mens EPYC 9755 har 128 Zen-5-kerner og 256 tråde. AMD angiver en maksimal boost på op til 3,7 GHz for 9965 og op til 4,1 GHz for 9755. Tallene viser forskellige fokusområder, men erstatter ikke en sammenligning baseret på ens egen belastningsprofil.

Den angivne maksimal boost Der er især ingen garanti for en konstant taktshastighed for alle kerner. Den frekvens, der opnås under belastning, afhænger blandt andet af belastningen og driftsbetingelserne. Når man skal træffe en beslutning om hosting, er gennemstrømning og responstider ved en defineret applikationssammensætning derfor mere sigende end den isolerede spidsværdi.

Det dobbelte antal tråde skyldes SMT: En fysisk kerne stiller to logiske tråde til rådighed. Disse deler dog kernens ressourcer; 384 tråde er hverken 384 fysiske kerner eller en automatisk fordobling af regnekraften. Om SMT og en overbelægning af CPU-ressourcer hjælper, skal vurderes ud fra den samtidige aktive kundebelastning.

Hukommelse og I/O begrænser kapaciteten

Mange CPU-kerner kræver en passende hukommelseskonfiguration. Ifølge AMD understøtter EPYC 9005 op til tolv DDR5-hukommelseskanaler pr. CPU. For en VM-host er det ikke kun den samlede RAM-kapacitet, der tæller: Også fordelingen af modulerne og den tilgængelige hukommelsesbåndbredde har indflydelse på, hvor godt samtidigt aktive gæster kan forsynes.

I databladet angives der for de nævnte modeller op til DDR5-6400 ved ét DIMM pr. kanal. Den faktisk anvendelige hastighed afhænger af konfigurationen og platformens godkendelse. Også de op til 6 TB DDR5, der er angivet i databladet, henviser til de der angivne konfigurationer med to DIMM’er pr. kanal og er ikke en garanti for alle servere.

Flere RAM-moduler kan være en god idé for at opnå den nødvendige kapacitet, men ændrer den konfiguration, der skal testes. Derfor bør udbydere sammenholde den ønskede modulstørrelse og konfiguration med serverproducentens godkendelsesliste i stedet for at lægge kapacitets- og hastighedsmaksima fra databladet sammen uafhængigt af hinanden.

For NVMe-drev og netværkskort gælder desuden, at PCIe-tilslutning afgørende. AMD angiver op til 128 PCIe 5.0-baner for systemer med én processor og op til 160 for servere med to processorer. Hvor mange porte et konkret kort rent faktisk stiller til rådighed, afhænger af platformens design og brugen af forbindelserne; 2P-maksimumet gælder ikke automatisk for en 1P-host.

Ved konfigurationen er det derfor en god idé at tage højde for samspillet: Flere NVMe-drev kan kræve ekstra porte, mens hurtige netværkskort også skal tilsluttes. CXL 2.0 er en del af platformens funktioner, men er ikke en funktion, der automatisk kan benyttes på alle servere. Det er nødvendigt at kontrollere, om det valgte system understøtter den pågældende hardware, firmware og det pågældende operativsystem.

Sammenlign Torino-modeller til hosting

EPYC-9005-serien har forskellige fokusområder: 9965 satser på maksimal kerntæthed, mens 9575F sigter mod en højere frekvens. Ved valg af processor er det ikke kun CPU'en, der tæller, men kombinationen af den konkrete model, sokkelnummer og anvendelsesbelastning. Den følgende tabel sammenligner fire modeller på baggrund af AMD-data.

9965 stiller et særligt stort antal fysiske kerner til rådighed til uafhængige opgaver. Dette kan være interessant ved en stærkt paralleliseret VM-sammensætning, forudsat at hukommelsen og I/O-kapaciteten kan følge med. 9755 har færre kerner, men en højere maksimal boost og mere samlet L3-cache. Ud fra disse data alene kan der ikke udledes en fast rangorden for hosting-applikationer.

9575F er en mulig alternativ løsning, hvis enkelte arbejdstrin kræver korte responstider. Dens maksimal boost er dog ikke en garanteret taktrate for alle kerner på lang sigt. Om den er mere økonomisk end en model med flere kerner, afhænger blandt andet af samtidige anmodninger og licensmodellen.

For 9655P begrænser det P-endelsen sokkelens egnethed til systemer med én sokkel. Denne model er derfor ikke en mulighed for en server med to sokler. En bredere sammenligning af platforme bør omfatte konkrete konfigurationer og målinger; artiklen om Valg af platform mellem AMD EPYC og Intel Xeon yderligere vejledning.

Kortlægning af hosting-arbejdsbelastninger og flaskehalse

En server-CPU skal passe til de tjenester, der kører samtidigt. Ved shared hosting opstår der mange uafhængige forespørgsler, mens hele operativsystemer konkurrerer om ressourcerne på virtuelle maskiner, og databaser reagerer, afhængigt af arbejdsbelastningen, følsomt på hukommelsesadgang eller lagringsforsinkelse. Den følgende oversigt omsætter disse forskelle til kontrolspørgsmål til dimensioneringen.

Ved shared hosting er antallet af samtidigt aktive workere lige så relevant som varigheden af de enkelte forespørgsler. En høj CPU-udnyttelse kan være acceptabel, hvis gennemstrømningen er god; men i sig selv siger den ikke noget om, hvorvidt kunderne skal vente længe. Derfor indgår fordelingen af svartider og fejlprocenten ved definerede belastningsniveauer i sammenligningen.

Når det gælder databaser, er L3-cache kun en del af billedet. 9755 har i alt 512 MB, mens 9965 har i alt 384 MB. Disse modelværdier beviser ikke nogen databasefordel: Datasættets størrelse, adgangs mønstre, fordelingen af arbejdet og RAM-konfigurationen påvirker, hvor ofte der er behov for data fra andre lagringsniveauer.

En administreret Redis-tjeneste supplerer eksempelvis applikationsmixet som cache. Til dette formål skal udbydere ud over CPU-ressourcer især tage højde for den tilgængelige RAM og kravene til den konkrete tjeneste. Artiklen om Redis 8 og beslutninger om opgradering for hostingudbydere omhandler blandt andet lagringsbegrænsninger og driften af sådanne tjenester.

For at sikre en retfærdig sammenligning af modellerne skal VM-sammensætning, RAM-kapacitet, lagerplads og belastningsniveauer være så sammenlignelige som muligt. Ellers kan forskelle i responstider eller gennemstrømning ikke på en meningsfuld måde tilskrives valget af CPU. En hurtigere enkeltforespørgsel og en højere samlet gennemstrømning er desuden separate mål, som kan vægtes forskelligt i forbindelse med prisplanlægningen.

Eksempel på planlægning af VM-kapacitet

Et regneeksempel illustrerer størrelsesordenerne: En host med en EPYC 9965 har 192 fysiske kerner og 384 tråde. Hvis der oprettes 48 virtuelle maskiner (VM'er) med hver fire vCPU'er, giver det 48 × 4 = 192 tildelte vCPU'er. Dette er en tildelingsberegning og ikke en måling af den opnåelige VM-ydeevne.

En vCPU er ikke nødvendigvis en fysisk kerne, der er eksklusivt reserveret. Hypervisoren planlægger virtuelle processorer på de tilgængelige logiske processorer; den faktiske udførelse afhænger af, hvilke VM'er der kører samtidigt, og hvilke ressourcer der tildeles dem. Processors 384 tråde svarer heller ikke til 384 uafhængige fysiske kerner.

For Overbooking Du bør først fastlægge, hvilken samtidig belastning du forventer, og hvilken ydeevne en prisplan lover. Et højere antal tildelte vCPU’er kan fungere, når belastningsspidser sjældent falder sammen, men øger risikoen for ventetider, når mange gæster regner på samme tid. Tjek denne antagelse ud ved at se på den faktiske kundesammensætning i stedet for blot at se på antallet af tråde.

Derefter beregner du hukommelsesbehovet separat: Læg den planlagte RAM for de virtuelle maskiner sammen, og tag desuden højde for hypervisorens behov samt driftsreserver. CPU-beregningen siger ikke noget om, hvorvidt værten stiller tilstrækkelig RAM til rådighed, eller om den nødvendige hukommelsesbåndbredde er tilstrækkelig, når flere gæster er aktive samtidigt.

Det samme gælder for lagring og netværk. Mange virtuelle maskiner kan samtidig få adgang til NVMe-drev eller overføre data; her er ikke kun den samlede gennemstrømning, men også I/O-forsinkelser og belastningsspidser relevante. Du bør derfor medtage tilslutningen og ydeevnen for de drev og netværkskort, der rent faktisk anvendes, i din planlægning.

Endelig skal du have en reserve til vedligeholdelse og nedbrud. Hvis en tilbageværende host skal overtage yderligere VM’er efter, at en anden er gået ned, må den normale udnyttelse ikke allerede optage alle de ressourcer, der er nødvendige til dette. Eksemplet med 48 virtuelle maskiner fastlægger hverken en sikker belægningsgrænse eller en konsolideringsgrad; begge dele skal vurderes ud fra det konkrete miljø.

Forberedelse af platform og virtualisering

Start planlægningen af platformen med den konkrete CPU-model og spørgsmålet om, hvorvidt der er brug for én eller to sokler. Behovet for kerner, RAM og I/O skal samlet set passe til det ønskede værtsystem. En P-model som EPYC 9655P er designet til én sokkel og kan derfor ikke anvendes i en konfiguration med to sokler.

Kontroller derefter Producentgodkendelse for CPU, bundkort og BIOS. Turin bruger ganske vist SP5-soklen, men en eksisterende SP5-server understøtter ikke af den grund alene alle 9005-modeller. Også strømforsyningen og kølesystemet skal være godkendt til den valgte CPU og det påtænkte kabinet.

Planlæg RAM-modulerne ud fra kapacitet, kanalopbygning og serverproducentens specifikationer. Derudover skal der tages højde for de nødvendige NVMe-drev og netværkskort: Det afgørende er ikke kun antallet, men også hvilke stik eller drevpladser der er tilgængelige i det konkrete system. På den måde kan man inden bestillingen se, om den ønskede kombination overhovedet er mulig på platformen.

For fortrolige kundevirtuelle maskiner kan SEV-SNP udvide beskyttelsen af VM-hukommelsen med integritetsmekanismer. Trusted I/O via TDISP er en yderligere mulig komponent til enhedsadgang. Om dette resulterer i et brugbart tilbud, afhænger dog af kombinationen af firmware, hypervisor, gæstoperativsystem og eventuelt enheder.

Inden du giver tilsagn om et produkt, bør du desuden afklare, hvordan gæster konfigureres, godkendes og administreres, samt hvilke begrænsninger der gælder for de tilbudte VM-funktioner. En CPU-funktion alene garanterer hverken kompatibiliteten af hele stakken eller beskytter mod alle angreb. Dokumenter derfor den faktisk understøttede konfiguration, og hold den opdateret ved opdateringer.

Måle driften og finde flaskehalse

For at kunne sammenligne med eksisterende hosting-hardware skal du have en overskuelig lastprofil: omtrent samme kombination af virtuelle maskiner, sammenlignelige datamængder og definerede forespørgselstyper. Notér RAM-kapacitet, lagerplads, netværk og softwarekonfiguration. Kun på den måde kan man senere skelne, om en afvigelse snarere hænger sammen med CPU’en eller med en anden ændring i systemet.

Undersøg flere belastningsniveauer i stedet for blot én spidsværdi. Registrer samtidig gennemstrømning, fordeling af svartider og fejlprocenter: En højere gennemstrømning har ringe værdi for et hostingtilbud, hvis mange forespørgsler samtidig bliver langsomme eller mislykkes. Fastlæg på forhånd, hvilke svartider og fejlprocenter der er acceptable for den pågældende tjeneste.

Overvåg samtidig RAM-udnyttelsen og hukommelsesadfærden samt latenstiden og udnyttelsen af lagerplads og netværk. Hvis svartiderne stiger, selvom CPU’en stadig har ledig kapacitet, kan det for eksempel skyldes, at en anden del af platformen udgør en flaskehals. Omvendt er en høj CPU-udnyttelse i sig selv ikke bevis på, at kunderne har en dårlig brugeroplevelse.

Hvis der er unormale svarstider fra VM’erne, skal du kontrollere den antagede samtidighed og CPU-overbooking. Sammenlign derefter den faktiske RAM-konfiguration samt firmware- og hypervisor-indstillingerne med den planlagte konfiguration. Ændr om muligt enkelte faktorer målrettet, og gentag det samme belastningsniveau, så årsagen ikke forveksles med en samtidig ændring i arbejdsbelastningen.

Den løbende drift omfatter desuden sikkerhedsmeddelelser, firmwareopdateringer, adgangskontrol og verificerbare sikkerhedskopier. AMD offentliggør også oplysninger om sikkerhedshuller og afhjælpende foranstaltninger for EPYC-processorer; operatører skal planlægge de relevante opdateringer fra serverproducenten. Kontroller efter vedligeholdelsesarbejder igen, om beskyttelsesfunktioner og de tilbudte gæstekonfigurationer er tilgængelige som forventet.

Indkøb og rentabilitet er afgørende

En beslutning om anskaffelse tager udgangspunkt i spørgsmålet om, hvorvidt den eksisterende platform fortsat opfylder kravene. Hvis kapaciteten og reserverne er tilstrækkelige, kan det være fornuftigt at fortsætte driften. For en opgradering til Turin skal den konkrete CPU-model, firmwaren og de øvrige komponenter derimod være godkendt af serverproducenten; den fælles SP5-sokkel er ikke tilstrækkeligt bevis.

Sammenlign en 1P-vært med en 2P-konfiguration baseret på det samlede behov for kerner, RAM og porte. To sokler er ikke kun nødvendige på grund af et højt mål for antallet af VM'er. Omvendt kan en platform med én sokkel udelukkes, hvis den nødvendige kombination af hukommelse og I/O ikke kan rummes i den valgte server.

Når der er mange uafhængige opgaver, der kører samtidigt, kan kerne tæthed være et vigtigt udvælgelseskriterium. Til latenstidsfølsomme applikationer kan det derimod betale sig at undersøge modeller med højere klokfrekvens i ens egen applikationssammensætning. Beregn desuden den konkrete licensmodel: Omkostninger pr. kerne, sokkel eller VM kan ændre den økonomiske rangorden blandt platformene.

Die TDP er ikke en måling af strømforbruget for en komplet server. AMD angiver en TDP på 500 watt for både EPYC 9755 og 9965; dette siger dog intet om strømforbruget under din belastning eller de årlige energiomkostninger. RAM, drev, netværk og køling skal medtages i systemvurderingen.

For at kunne foretage en energi- og omkostningssammenligning skal du beregne det samlede system ved repræsentative belastningsniveauer og medtage de nødvendige reserver. Du bør sammenligne anskaffelsesomkostninger, softwarelicenser og driftsomkostninger over den planlagte levetid. Uden sammenlignelige eksisterende data kan der hverken loves en bestemt besparelse eller en pålidelig konsolideringsgrad.