AMD EPYC Turin: Att välja rätt serverprocessor för webbhotellleverantörer

Att sätta AMD EPYC Turin i sitt rätta sammanhang

AMD EPYC Turin avser EPYC 9005-generationen av serverprocessorer. AMD presenterade dem i oktober 2024 som den femte generationen av EPYC; i serien ingår modeller med Zen-5- och Zen-5c-kärnor.

För webbhotellleverantörer är Turin inte en enskild CPU med enhetliga prestandakarakteristika. Modellutbudet sträcker sig från åtta till 192 kärnor per processor. Vilken modell som passar beror på om många oberoende kundförfrågningar körs parallellt, om enskilda applikationer kräver korta svarstider eller om virtuella maskiner framför allt kräver mycket arbetsminne.

I urvalet ingår även frågan om Antal socklar: En server med en processor erbjuder en annan kombination av beräkningskapacitet, minnesanslutning och utbyggnadsmöjligheter än en plattform med två socklar. Inte alla modeller är avsedda för båda varianterna; processorer med suffixet ”P” är enligt databladet utformade för system med en sockel.

Ett första urval utgår därför från den konkreta kundsammansättningen och kraven på RAM, NVMe-enheter och nätverk. En högt belastad VPS-värd behöver till exempel reserver för virtuella maskiner som är aktiva samtidigt, medan en databasserver dessutom kan anpassas efter lagringsbehov och I/O-krav. Även programvarulicenser och servertillverkarens villkor ingår i planeringen.

Antalet kärnor i sig säger inte hur många befintliga värdar som kan ersättas. För detta behöver leverantören jämförbara belastningsprofiler och mätvärden för den befintliga hostinghårdvaran samt en fastställd reservkapacitet för driftavbrott. Utan denna grund är det möjligt att välja en modell, men inte att fastställa en tillförlitlig konsolideringsgrad.

Att förstå kärnor, chiplets och klockfrekvens

Turin använder en Chiplet-design: Beräkningsenheterna och en separat I/O-chip är anslutna via AMD Infinity Fabric. I/O-chipet sköter bland annat anslutningarna till arbetsminnet samt till in- och utdata. För den praktiska serverplaneringen innebär detta att det inte bara är kärnorna som spelar roll, utan även anslutningen till de gemensamt använda resurserna.

Zen 5 och Zen 5c skiljer sig åt vad gäller utformning och kärnorganisation. Zen 5c möjliggör den högsta kärntätheten inom generationen; detta innebär dock inte någon allmän prestandarankning. En starkt parallelliserad VM-mix och en applikation med få latenskritiska uppgifter kan gynna olika modeller.

EPYC 9965 har 192 Zen-5c-kärnor och 384 trådar, medan EPYC 9755 har 128 Zen-5-kärnor och 256 trådar. AMD anger en maximal boost på upp till 3,7 GHz för 9965 och upp till 4,1 GHz för 9755. Värdena visar olika inriktningar, men ersätter inte en jämförelse utifrån den egna belastningsprofilen.

Den angivna maximal boost Det finns framför allt ingen garanterad konstant klockfrekvens för alla kärnor. Vilken frekvens som uppnås under belastning beror bland annat på belastningen och driftsförhållandena. Vid val av webbhotell är därför genomströmning och svarstider vid en definierad applikationsmix mer meningsfulla än det isolerade toppvärdet.

Det dubbla antalet trådar beror på SMT: en fysisk kärna tillhandahåller två logiska trådar. Dessa delar dock på kärnresurserna; 384 trådar innebär varken 384 fysiska kärnor eller en automatisk fördubbling av beräkningskraften. Huruvida SMT och en överbokning av CPU-resurser hjälper måste utvärderas utifrån den samtidigt aktiva kundbelastningen.

Lagring och I/O begränsar kapaciteten

Många CPU-kärnor kräver en lämplig minneskonfiguration. Enligt AMD stöder EPYC 9005 upp till tolv DDR5-minneskanaler per CPU. För en VM-värd är det inte bara den totala RAM-kapaciteten som spelar roll: även modulernas fördelning och den tillgängliga minnesbandbredden påverkar hur väl samtidigt aktiva gäster kan försörjas.

I databladet anges för de listade modellerna upp till DDR5-6400 vid ett DIMM-modul per kanal. Den faktiska användbara hastigheten beror på utrustningen och plattformens godkännande. Även uppgiften i databladet om upp till 6 TB DDR5 avser de konfigurationer som anges där, med två DIMM-moduler per kanal, och utgör ingen garanti för alla servrar.

Fler RAM-moduler kan vara lämpliga för att uppnå den kapacitet som krävs, men de förändrar den konfiguration som ska testas. Därför bör leverantörer jämföra önskad modulstorlek och konfiguration med servertillverkarens godkännandelista, istället för att oberoende av varandra lägga ihop kapacitets- och hastighetsmaxvärdena från databladet.

För NVMe-enheter och nätverkskort gäller dessutom att PCIe-anslutning avgörande. AMD anger upp till 128 PCIe 5.0-banor för system med en processor och upp till 160 för servrar med två processorer. Hur många anslutningar ett specifikt moderkort faktiskt tillhandahåller beror på plattformens utformning och hur anslutningarna används; 2P-maximivärdet gäller inte automatiskt för en 1P-värd.

Vid konfigurationen är det därför värt att beakta samspelet: Fler NVMe-enheter kan ta upp ytterligare anslutningar, samtidigt som snabba nätverkskort också måste anslutas. CXL 2.0 ingår i plattformens funktioner, men är inte en funktion som automatiskt kan användas på alla servrar. Stöd för hårdvara, firmware och operativsystem måste kontrolleras för det valda systemet.

Jämför Turin-modeller för webbhotell

EPYC-9005-serien har olika inriktningar: 9965 satsar på maximal kärntäthet, medan 9575F strävar efter högre klockfrekvens. Vid valet är det inte bara processorn som spelar roll, utan kombinationen av konkret modell, antal socklar och arbetsbelastning. I följande tabell jämförs fyra modeller utifrån AMD:s data.

9965 erbjuder särskilt många fysiska kärnor för oberoende uppgifter. Detta kan vara intressant vid en starkt parallelliserad VM-mix, förutsatt att minne och I/O hänger med. 9755 har färre kärnor, men en högre maximal boost och mer L3-cache totalt. Enbart utifrån dessa uppgifter går det inte att fastställa någon bestämd rangordning för hostingapplikationer.

9575F är ett möjligt alternativ att jämföra med när enskilda arbetssteg kräver korta svarstider. Dess maximal boost Det innebär dock inte att alla kärnor garanteras en konstant klockfrekvens. Huruvida detta är mer kostnadseffektivt jämfört med en modell med fler kärnor beror bland annat på samtidiga förfrågningar och licensmodellen.

För 9655P begränsar detta P-suffix att sockeln är avsedd för system med en enda sockel. För en server med två socklar är denna modell därför inte ett alternativ. En mer omfattande plattformsjämförelse bör inkludera konkreta konfigurationer och mätningar; detta behandlas i artikeln om Val av plattform mellan AMD EPYC och Intel Xeon ytterligare vägledning.

Koppla samman hosting-arbetsbelastningar och flaskhalsar

En server-CPU måste vara anpassad till de tjänster som körs samtidigt. Vid delad hosting uppstår många oberoende förfrågningar, vid virtuella maskiner konkurrerar hela operativsystem om resurser, och databaser reagerar, beroende på arbetsbelastningen, känsligt på minnesåtkomst eller lagringslatens. Följande översikt översätter dessa skillnader till kontrollfrågor för dimensioneringen.

När det gäller delad hosting är antalet samtidigt aktiva arbetare lika viktigt som varaktigheten för enskilda förfrågningar. En hög CPU-belastning kan vara acceptabel om genomströmningen är god, men den säger i sig inte om kunderna får vänta länge. Därför ingår svarstidsfördelningar och felfrekvenser vid definierade belastningsnivåer i jämförelsen.

När det gäller databaser är L3-cache bara en del av helheten. Modellen 9755 har totalt 512 MB, medan modellen 9965 har totalt 384 MB. Dessa modellvärden bevisar inte någon databasfördel: datamängdens storlek, åtkomstmönster, arbetsfördelning och RAM-konfiguration påverkar hur ofta data från andra lagringsnivåer behövs.

En hanterad Redis-tjänst kompletterar till exempel applikationsmixen som cache. För detta måste leverantörerna, förutom CPU-resurser, framför allt beakta det tillgängliga minnet och kraven för den specifika tjänsten. Artikeln om Redis 8 och uppgraderingsbeslut för webbhotellleverantörer behandlar bland annat lagringsbegränsningar och driften av sådana tjänster.

För en rättvis jämförelse mellan olika modeller bör VM-mix, RAM-kapacitet, lagringsutrymme och belastningsnivåer vara så jämförbara som möjligt. Annars går det inte att på ett meningsfullt sätt koppla skillnader i svarstider eller genomströmning till valet av CPU. Även en snabbare enskild förfrågan och en högre total genomströmning är separata mål som kan viktas olika vid prissättningen.

Exempel på hur man planerar VM-kapacitet

Ett beräknings exempel tydliggör storleksordningarna: En värd med en EPYC 9965 har 192 fysiska kärnor och 384 trådar. Om man därpå konfigurerar 48 virtuella maskiner med vardera fyra vCPU:er blir det 48 × 4 = 192 tilldelade vCPU:er. Detta är en tilldelningsberäkning och inte en mätning av den uppnåeliga prestandan för de virtuella maskinerna.

En vCPU är inte nödvändigtvis en exklusivt reserverad fysisk kärna. Hypervisorn schemalägger virtuella processorer på tillgängliga logiska processorer; den faktiska körningen beror på vilka virtuella maskiner som körs samtidigt och vilka resurser som tilldelas dem. Processorns 384 trådar motsvarar inte heller 384 oberoende fysiska kärnor.

För Överbokning Du bör först fastställa vilken samtidig belastning du förväntar dig och vilken prestanda ett prisalternativ lovar. Ett högre antal tilldelade vCPU:er kan fungera när belastningstoppar sällan sammanfaller, men ökar risken för väntetider när många gäster utför beräkningar samtidigt. Kontrollera detta antagande utifrån den faktiska kundmixen istället för enbart antalet trådar.

Därefter beräknar du minnesbehovet separat: Lägg ihop det planerade RAM-minnet för de virtuella maskinerna och ta dessutom hänsyn till hypervisorens behov samt driftsreserver. CPU-beräkningen visar inte om värddatorn tillhandahåller tillräckligt med RAM-minne eller om den nödvändiga minnesbandbredden är tillräcklig när flera gäster är aktiva samtidigt.

Detsamma gäller för lagring och nätverk. Många virtuella maskiner kan samtidigt komma åt NVMe-enheter eller överföra data; förutom den totala genomströmningen är även I/O-fördröjningar och belastningstoppar av betydelse. Ta därför hänsyn till anslutningen och prestandan hos de enheter och nätverkskort som faktiskt används.

Slutligen behöver du reservkapacitet för underhåll och driftstopp. Om en kvarvarande värd ska ta emot ytterligare virtuella maskiner efter att en annan har gått ur drift, får den normala beläggningen inte redan ta upp alla resurser som krävs för detta. Exemplet med 48 virtuella maskiner anger varken en säker beläggningsgräns eller en konsolideringsgrad; båda dessa måste utvärderas utifrån den konkreta miljön.

Förbereda plattformen och virtualiseringen

Börja plattformsplaneringen med den specifika CPU-modellen och frågan om det behövs ett eller två socklar. Behovet av kärnor, RAM och I/O måste tillsammans passa det önskade värdsystemet. En P-modell som EPYC 9655P är utformad för ett sockel och kommer därför inte i fråga för en konfiguration med två socklar.

Kontrollera sedan Tillverkarens godkännande för processor, moderkort och BIOS. Turin använder visserligen SP5-sockeln, men en befintlig SP5-server stöder inte alla 9005-modeller enbart av den anledningen. Även strömförsörjningen och kylsystemet måste vara godkända för den valda processorn och det avsedda chassit.

Planera RAM-modulerna utifrån kapacitet, antal kanaler och servertillverkarens specifikationer. Till detta kommer de nödvändiga NVMe-enheterna och nätverkskorten: Det avgörande är inte bara antalet, utan också vilka kortplatser eller enhetsfack som är anslutna i det specifika systemet. På så sätt kan man redan före beställningen avgöra om den önskade kombinationen överhuvudtaget är möjlig på plattformen.

För konfidentiella kund-VM:er kan SEV-SNP komplettera skyddet av VM-minnet med integritetsmekanismer. Trusted I/O via TDISP är ytterligare en möjlig komponent för enhetsåtkomst. Om detta leder till en användbar lösning beror dock på kombinationen av firmware, hypervisor, gästoperativsystem och eventuellt enheter.

Innan du bekräftar ett produktval bör du dessutom klargöra hur gäster konfigureras, certifieras och hanteras, samt vilka begränsningar som gäller för de VM-funktioner som erbjuds. En enskild CPU-funktion garanterar varken kompatibiliteten för hela stacken eller skyddar mot alla typer av attacker. Dokumentera därför den konfiguration som faktiskt stöds och uppdatera dokumentationen vid uppdateringar.

Mäta driften och identifiera flaskhalsar

För att kunna jämföra med befintlig webbhotellshårdvara behöver du en överskådlig lastprofil: ungefär samma kombination av virtuella maskiner, jämförbara datamängder och definierade typer av förfrågningar. Dokumentera RAM-kapacitet, lagringsutrymme, nätverk och programvarukonfiguration. Endast på så sätt går det senare att avgöra om en avvikelse snarare beror på processorn eller på någon annan förändring i systemet.

Undersök flera belastningsnivåer istället för bara ett toppvärde. Registrera samtidigt genomströmning, svarstidsfördelning och felfrekvens: En högre genomströmning är av ringa värde för en webbhotellstjänst om många förfrågningar samtidigt blir långsamma eller misslyckas. Fastställ i förväg vilka svarstider och felfrekvenser som är acceptabla för respektive tjänst.

Övervaka samtidigt RAM-utnyttjandet och minnesbeteendet samt latens och belastning på lagringsutrymmet och nätverket. Om svarstiderna ökar trots att CPU:n fortfarande har kapacitet kvar kan det till exempel bero på att en annan del av plattformen utgör en flaskhals. Omvänt innebär en hög CPU-belastning i sig inte nödvändigtvis att kunderna upplever en dålig användarupplevelse.

Om svarstiderna för virtuella maskiner avviker från det normala, kontrollera den antagna samtidigheten och Överbeläggning av CPU. Jämför därefter den faktiska RAM-konfigurationen, firmware- och hypervisorinställningarna med den planerade konfigurationen. Ändra enskilda faktorer så målinriktat som möjligt och upprepa samma belastningsnivå, så att orsaken inte förväxlas med en samtidigt förändrad arbetsbelastning.

Den löpande driften omfattar dessutom säkerhetsmeddelanden, uppdatering av firmware, åtkomstkontroller och verifierbara säkerhetskopior. AMD publicerar även information om säkerhetsbrister och åtgärder för EPYC-processorer; operatörerna måste planera in lämpliga uppdateringar från servertillverkaren. Kontrollera efter underhållsarbeten på nytt om skyddsfunktioner och tillgängliga gästkonfigurationer fungerar som avsett.

Upphandling och lönsamhet är avgörande

Ett inköpsbeslut börjar med frågan om den befintliga plattformen fortfarande uppfyller kraven. Om kapaciteten och reserverna är tillräckliga kan det vara lämpligt att fortsätta driva den. För en uppgradering till Turin måste däremot den specifika CPU-modellen, firmware och övriga komponenter ha godkänts av servertillverkaren; det gemensamma SP5-socklet räcker inte som bevis.

Jämför en 1P-värd med en 2P-konfiguration utifrån det totala behovet av kärnor, RAM och anslutningar. Två socklar krävs inte enbart på grund av ett högt önskat antal virtuella maskiner. Omvänt kan en plattform med en sockel uteslutas om den nödvändiga kombinationen av minne och I/O inte ryms i den valda servern.

När det finns många oberoende uppgifter som körs samtidigt kan kärntäthet vara ett viktigt urvalskriterium. För latenskänsliga tillämpningar lönar det sig däremot att även undersöka modeller med högre klockfrekvens i den egna tillämpningsmixen. Beräkna dessutom den konkreta licensmodellen: kostnader per kärna, sockel eller virtuell maskin kan påverka den ekonomiska rangordningen av plattformarna.

Die TDP är inte en mätning av strömförbrukningen för en komplett server. AMD anger en TDP på 500 watt för både EPYC 9755 och 9965; detta säger varken något om strömförbrukningen under din belastning eller om de årliga energikostnaderna. RAM, hårddiskar, nätverk och kylning ingår i systemanalysen.

För att kunna jämföra energi- och kostnader bör du beräkna hela systemet vid representativa belastningsnivåer och ta hänsyn till de nödvändiga reserverna. Du bör jämföra anskaffningskostnader, programvarulicenser och driftskostnader över den planerade användningstiden. Utan jämförbara befintliga data går det varken att lova en specifik besparing eller en tillförlitlig konsolideringsgrad.