AMD EPYC Turin: scegliere la CPU per server più adatta per i fornitori di servizi di hosting

Comprendere appieno l’AMD EPYC Turin

AMD EPYC Turin indica il Generazione EPYC 9005 dei processori per server. AMD li ha presentati nell'ottobre 2024 come quinta generazione EPYC; la famiglia comprende modelli con core Zen-5 e Zen-5c.

Per i fornitori di servizi di hosting, Turin non è una singola CPU con caratteristiche prestazionali uniformi. La gamma di modelli spazia da otto a 192 core per processore. La scelta del modello più adatto dipende dal fatto che vi siano molte richieste indipendenti dei clienti in esecuzione in parallelo, che singole applicazioni richiedano tempi di risposta brevi o che le macchine virtuali necessitino soprattutto di molta memoria.

Tra le opzioni figura anche la domanda relativa alla Numero di zoccoli: Un server dotato di un solo processore offre una combinazione diversa di potenza di calcolo, connettività di memoria e possibilità di espansione rispetto a una piattaforma a due socket. Non tutti i modelli sono destinati a entrambe le varianti; secondo la scheda tecnica, i processori con suffisso "P" sono progettati per sistemi a socket singolo.

La preselezione parte quindi dalla composizione concreta della clientela e dai requisiti relativi a RAM, unità NVMe e rete. Un host VPS ad alta densità, ad esempio, necessita di riserve per le macchine virtuali attive contemporaneamente, mentre un server di database può inoltre rispondere alle esigenze di memoria e di I/O. Anche le licenze software e le autorizzazioni del produttore del server rientrano nella pianificazione.

Il semplice aumento del numero di core non indica di per sé quanti host esistenti possano essere sostituiti. A tal fine, il fornitore necessita di profili di carico e valori di misurazione comparabili relativi all’hardware di hosting esistente, nonché di una riserva di disponibilità prestabilita. Senza queste basi, è possibile selezionare un modello, ma non è possibile stabilire un tasso di consolidamento attendibile.

Comprendere i core, i chiplet e la frequenza di clock

Torino utilizza un Progettazione di chiplet: Le unità di calcolo e un die I/O separato sono collegati tramite AMD Infinity Fabric. Il die I/O fornisce, tra l’altro, i collegamenti alla memoria di lavoro e alle interfacce di ingresso e uscita. Ai fini della progettazione pratica dei server, ciò significa che non contano solo i core, ma anche il collegamento alle risorse condivise.

Zen 5 e Zen 5c si differenziano per la loro architettura e l'organizzazione dei core. Zen 5c offre la massima densità di core all'interno della stessa generazione; ciò non implica tuttavia una classifica generale in termini di prestazioni. Un mix di VM fortemente parallelizzato e un'applicazione con poche attività sensibili alla latenza possono favorire modelli diversi.

L'EPYC 9965 dispone di 192 core Zen-5c e 384 thread, mentre l'EPYC 9755 ne ha 128 core Zen-5 e 256 thread. AMD indica una frequenza massima di boost fino a 3,7 GHz per il modello 9965 e fino a 4,1 GHz per il modello 9755. Questi valori evidenziano punti di forza diversi, ma non sostituiscono un confronto basato sul proprio profilo di carico.

Il valore indicato boost massimo In particolare, non è garantita una frequenza costante per tutti i core. La frequenza raggiunta sotto carico dipende, tra l’altro, dal carico di lavoro e dalle condizioni operative. Per una decisione in materia di hosting, quindi, la larghezza di banda e i tempi di risposta con un mix di applicazioni definito sono indicatori più significativi rispetto al valore di picco considerato isolatamente.

Il numero di thread, in ogni caso doppio, è dovuto alla tecnologia SMT: un core fisico mette a disposizione due thread logici. Questi, tuttavia, condividono le risorse del core; 384 thread non corrispondono né a 384 core fisici né a un raddoppio automatico della potenza di calcolo. Per stabilire se la tecnologia SMT e l’overbooking delle risorse della CPU siano d’aiuto, occorre valutare il carico dei clienti attivi contemporaneamente.

La memoria e l'I/O limitano la capacità

Molti core della CPU richiedono una configurazione di memoria adeguata. Secondo AMD, EPYC 9005 supporta fino a dodici canali di memoria DDR5 per CPU. Per un host di macchine virtuali non conta solo la capacità totale della RAM: anche la distribuzione dei moduli e la larghezza di banda di memoria disponibile influenzano la capacità di gestire efficacemente gli ospiti attivi contemporaneamente.

La scheda tecnica indica, per i modelli elencati, una velocità massima di DDR5-6400 a un DIMM per canale. La velocità effettivamente utilizzabile dipende dalla configurazione hardware e dall'approvazione della piattaforma. Anche i 6 TB di DDR5 indicati nella scheda tecnica si riferiscono alle configurazioni ivi specificate con due DIMM per canale e non costituiscono una garanzia per ogni server.

L'aggiunta di ulteriori moduli RAM può essere utile per ottenere la capacità richiesta, ma modifica la configurazione da verificare. Pertanto, i fornitori dovrebbero confrontare le dimensioni e la configurazione dei moduli desiderati con l’elenco di approvazione del produttore del server, anziché sommare indipendentemente l’uno dall’altro i valori massimi di capacità e velocità riportati nella scheda tecnica.

Per le unità NVMe e le schede di rete è inoltre disponibile la Interfaccia PCIe determinante. AMD indica fino a 128 linee PCIe 5.0 per i sistemi a socket singolo e fino a 160 per i server a doppio socket. Il numero effettivo di porte disponibili su una scheda specifica dipende dal design della piattaforma e dall’utilizzo delle connessioni; il limite massimo previsto per i sistemi a 2 socket non si applica automaticamente a un host a 1 socket.

Durante la configurazione vale quindi la pena prestare attenzione all’interazione tra i componenti: un numero maggiore di unità NVMe può richiedere connessioni aggiuntive, mentre anche le schede di rete veloci devono essere collegate. CXL 2.0 rientra tra le funzionalità della piattaforma, ma non è una caratteristica automaticamente disponibile su ogni server. È necessario verificare il supporto per dispositivi, firmware e sistema operativo per il sistema scelto.

Confronta i modelli di Torino per l'hosting

La famiglia EPYC 9005 offre diverse opzioni: il modello 9965 punta sulla massima densità di core, mentre il 9575F punta a una frequenza più elevata. Per la scelta non conta solo la CPU, ma la combinazione tra modello specifico, tipo di socket e carico di lavoro. La tabella seguente mette a confronto quattro modelli sulla base dei dati forniti da AMD.

Il modello 9965 mette a disposizione un numero particolarmente elevato di core fisici per attività indipendenti. Ciò può risultare interessante in presenza di un mix di macchine virtuali fortemente parallelizzate, a condizione che la memoria e l’I/O siano in grado di tenere il passo. Il modello 9755 offre un numero inferiore di core, ma un boost massimo più elevato e una cache L3 complessiva maggiore. Da questi dati, di per sé, non è possibile stabilire una classifica definitiva per le applicazioni di hosting.

Il modello 9575F rappresenta una possibile opzione di confronto quando le singole fasi di lavoro richiedono tempi di risposta brevi. Il suo boost massimo Tuttavia, non si tratta di una frequenza garantita in modo permanente per tutti i core. Il fatto che sia più conveniente rispetto a un modello con un numero maggiore di core dipende, tra l’altro, dalle richieste simultanee e dal modello di licenza.

Nel modello 9655P, ciò limita il Suffisso P l'idoneità del socket per i sistemi a socket singolo. Per un server a due socket, questo modello non rappresenta quindi un'opzione. Un confronto più ampio tra piattaforme dovrebbe includere configurazioni e misurazioni concrete; a tal proposito, l'articolo su Scelta della piattaforma tra AMD EPYC e Intel Xeon ulteriori indicazioni.

Assegnazione dei carichi di lavoro di hosting e dei colli di bottiglia

La CPU di un server deve essere adeguata ai servizi in esecuzione simultanea. Nell’hosting condiviso si generano numerose richieste indipendenti, nelle macchine virtuali interi sistemi operativi competono per le risorse e i database, a seconda del carico di lavoro, reagiscono in modo sensibile agli accessi alla memoria o alla latenza dello storage. La seguente panoramica traduce queste differenze in criteri di valutazione per la progettazione.

Per l'hosting condiviso, il numero di worker attivi contemporaneamente è rilevante tanto quanto la durata delle singole richieste. Un elevato carico della CPU può essere accettabile se la velocità di elaborazione è buona; tuttavia, di per sé non indica se i clienti debbano attendere a lungo. Per questo motivo, nella valutazione comparativa vanno prese in considerazione anche le distribuzioni dei tempi di risposta e i tassi di errore a livelli di carico definiti.

Nel caso dei database, il Cache L3 solo una parte del quadro. Il modello 9755 dispone complessivamente di 512 MB, mentre il 9965 ne ha 384 MB. Questi valori relativi ai modelli non dimostrano alcun vantaggio in termini di database: la dimensione dei record, i modelli di accesso, la distribuzione del carico di lavoro e la configurazione della RAM influenzano la frequenza con cui sono necessari dati provenienti da altri livelli di memoria.

Un servizio Redis gestito integra il mix di applicazioni, ad esempio come cache. A tal fine, i fornitori devono tenere conto, oltre che delle risorse CPU, soprattutto della memoria disponibile e dei requisiti del servizio specifico. L'articolo su Redis 8 e le decisioni relative all'aggiornamento per i fornitori di servizi di hosting tratta, tra l'altro, i limiti di archiviazione e il funzionamento di tali servizi.

Per un confronto equo tra i modelli, il mix di VM, la dotazione di RAM, lo storage e i livelli di carico devono essere il più possibile comparabili. In caso contrario, non è possibile attribuire in modo significativo le differenze nei tempi di risposta o nella velocità di elaborazione alla scelta della CPU. Anche una maggiore velocità di elaborazione delle singole richieste e una maggiore velocità di elaborazione complessiva sono obiettivi distinti, che possono essere ponderati in modo diverso nella pianificazione tariffaria.

Pianificazione esemplificativa della capacità VM

Un esempio di calcolo mette in evidenza gli ordini di grandezza: un host dotato di un EPYC 9965 dispone di 192 core fisici e 384 thread. Se su di esso vengono configurate 48 macchine virtuali con quattro vCPU ciascuna, si ottengono 48 × 4 = 192 vCPU assegnate. Si tratta di un calcolo di assegnazione e non di una misurazione delle prestazioni raggiungibili dalle macchine virtuali.

A vCPU non si tratta necessariamente di un core fisico riservato in modo esclusivo. L’hypervisor pianifica i processori virtuali sui processori logici disponibili; l’effettiva esecuzione dipende da quali macchine virtuali sono in esecuzione contemporaneamente e dalle risorse loro assegnate. Anche i 384 thread del processore non corrispondono a 384 core fisici indipendenti.

Per il Overbooking Dovresti innanzitutto stabilire quale carico di lavoro simultaneo ti aspetti e quale prestazione garantisce una determinata tariffa. Un numero maggiore di vCPU assegnate può funzionare in caso di picchi di carico che si verificano raramente, ma aumenta il rischio di tempi di attesa quando molti utenti effettuano calcoli contemporaneamente. Verifica questa ipotesi in base all’effettivo mix di clienti, anziché basarti esclusivamente sul numero di thread.

Successivamente, calcola separatamente il fabbisogno di memoria: somma la RAM prevista per le VM e tieni conto anche del fabbisogno dell’hypervisor e delle riserve operative. Il calcolo relativo alla CPU non indica se l’host metta a disposizione RAM sufficiente né se la larghezza di banda di memoria richiesta sia adeguata quando più guest sono attivi contemporaneamente.

Lo stesso vale per lo storage e la rete. Molte macchine virtuali possono accedere contemporaneamente alle unità NVMe o trasferire dati; in questo contesto, oltre alla larghezza di banda complessiva, sono rilevanti anche le latenze I/O e i picchi di carico. È quindi necessario tenere in considerazione la connettività e le prestazioni delle unità e delle schede di rete effettivamente utilizzate.

Infine, è necessario disporre di risorse di riserva per la manutenzione e i guasti. Se, in seguito al guasto di un host, quello rimanente deve ospitare ulteriori macchine virtuali, l’occupazione regolare non deve già occupare tutte le risorse necessarie a tale scopo. L’esempio con 48 VM non stabilisce né un limite di occupazione sicuro né un tasso di consolidamento; entrambi devono essere valutati in base all’ambiente specifico.

Preparazione della piattaforma e della virtualizzazione

Inizia la progettazione della piattaforma partendo dal modello specifico di CPU e valutando se sono necessari uno o due socket. Il fabbisogno di core, RAM e I/O deve essere complessivamente compatibile con il sistema host desiderato. Un modello P come l’EPYC 9655P è progettato per un solo socket e pertanto non è adatto a una configurazione a due socket.

Controlla quindi il Approvazione del produttore per CPU, scheda madre e BIOS. Turin utilizza sì il socket SP5, ma un server SP5 già esistente non supporta per questo motivo ogni modello 9005. Anche l'alimentatore e il sistema di raffreddamento devono essere compatibili con la CPU selezionata e il case previsto.

Scegli i moduli RAM in base alla capacità, alla configurazione dei canali e alle specifiche del produttore del server. A questi si aggiungono le unità NVMe e le schede di rete necessarie: non è determinante solo il loro numero, ma anche quali slot o alloggiamenti per unità sono collegati nel sistema specifico. In questo modo è possibile verificare, prima di effettuare l’ordine, se la combinazione desiderata sia effettivamente realizzabile sulla piattaforma.

Per le macchine virtuali riservate dei clienti è possibile SEV-SNP integrare la protezione della memoria VM con meccanismi di integrità. Il Trusted I/O tramite TDISP rappresenta un ulteriore elemento possibile per l’accesso alle periferiche. Tuttavia, la possibilità di ottenere un’offerta utilizzabile dipende dalla combinazione di firmware, hypervisor, sistema operativo ospite ed eventualmente periferiche.

Prima di confermare l’acquisto di un prodotto, dovresti inoltre chiarire in che modo vengono configurati, certificati e gestiti gli ospiti e quali limitazioni si applicano alle funzionalità delle macchine virtuali offerte. Una singola funzionalità della CPU non garantisce né la compatibilità dell’intero stack né la protezione da tutti gli attacchi. Documenta quindi la configurazione effettivamente supportata e mantienila aggiornata in occasione degli aggiornamenti.

Misurare il funzionamento e individuare i colli di bottiglia

Per un confronto con l'hardware di hosting esistente, ti serve un documento comprensibile profilo di carico: più o meno lo stesso mix di macchine virtuali, volumi di dati simili e tipi di richieste definiti. Prendi nota della dotazione di RAM, dello spazio di archiviazione, della rete e della configurazione software. Solo così sarà possibile distinguere in seguito se una discrepanza è dovuta piuttosto alla CPU o a un’altra modifica apportata al sistema.

Analizza diversi livelli di carico anziché limitarti a un unico valore di picco. Rileva la velocità di trasmissione, la distribuzione dei tempi di risposta e i tassi di errore: una velocità di trasmissione più elevata ha scarso valore per un'offerta di hosting se, allo stesso tempo, molte richieste diventano lente o falliscono. Stabilisci in anticipo quali tempi di risposta e quali tassi di errore sono accettabili per il rispettivo servizio.

Monitorare contemporaneamente l'utilizzo della RAM e il comportamento della memoria, nonché la latenza e il carico dello storage e della rete. Se i tempi di risposta aumentano nonostante la CPU mostri ancora riserve, è possibile che, ad esempio, un'altra parte della piattaforma costituisca un collo di bottiglia. Al contrario, un elevato carico della CPU di per sé non dimostra ancora che i clienti stiano vivendo un'esperienza utente negativa.

In caso di tempi di risposta delle VM anomali, verificare la simultaneità ipotizzata e la Overbooking della CPU. Confronta quindi la dotazione effettiva di RAM, le impostazioni del firmware e dell'hypervisor con la configurazione prevista. Modifica i singoli fattori nel modo più mirato possibile e ripeti lo stesso livello di carico, in modo da non confondere la causa con un carico di lavoro modificato contemporaneamente.

La gestione operativa comprende inoltre bollettini di sicurezza, aggiornamenti del firmware, controlli degli accessi e backup verificabili. AMD pubblica anche avvisi relativi a vulnerabilità di sicurezza e misure correttive per i processori EPYC; gli operatori devono pianificare gli aggiornamenti appropriati forniti dal produttore del server. Dopo gli interventi di manutenzione, verificare nuovamente che le funzioni di protezione e le configurazioni guest offerte siano disponibili come previsto.

L'approvvigionamento e la redditività sono determinanti

Una decisione in materia di approvvigionamento parte dalla domanda se la piattaforma esistente soddisfi ancora i requisiti. Se la capacità e le riserve sono sufficienti, può essere opportuno continuare a utilizzarla. Per un aggiornamento a Turin, invece, il modello specifico della CPU, il firmware e gli altri componenti devono essere approvati dal produttore del server; il socket comune SP5 non è sufficiente come prova.

Confronta un Host 1P con una configurazione a 2P in base al fabbisogno complessivo di core, RAM e porte. Due socket non sono necessari solo a causa di un numero elevato di VM previsto. Al contrario, una piattaforma a socket singolo può essere scartata se la combinazione richiesta di memoria e I/O non può essere ospitata nel server scelto.

Quando si hanno molte attività indipendenti attive contemporaneamente, la densità per core può rappresentare un importante criterio di selezione. Per le applicazioni sensibili alla latenza, invece, vale la pena valutare anche modelli con frequenze di clock più elevate nel proprio mix di applicazioni. Calcola inoltre il modello di licenza specifico: i costi per core, socket o VM possono modificare l’ordine di priorità economico delle piattaforme.

Il sito TDP Non si tratta di una misurazione del consumo energetico di un server completo. AMD indica un TDP di 500 watt sia per l’EPYC 9755 che per il 9965; da questo dato non è possibile dedurre né il consumo energetico sotto il tuo carico né i costi energetici annuali. RAM, unità disco, rete e raffreddamento fanno parte della valutazione complessiva del sistema.

Per un confronto in termini di energia e costi, valuta l’intero sistema in base a livelli di carico rappresentativi e tieni conto delle riserve necessarie. Dovresti mettere a confronto i costi di acquisto, le licenze software e i costi di esercizio per l’intero periodo di utilizzo previsto. Senza dati comparabili relativi alla situazione attuale, non è possibile garantire né un risparmio specifico né un tasso di consolidamento attendibile.