Più imprese e organizzazioni implementano workload nel cloud pubblico, più i loro data center locali richiedono minori risorse per gestire i carichi di lavoro rimasti on-premise, e diventa un passo naturale, per IT manager e responsabili del business, cercare di estrarre maggior valore e prestazioni dalla capacità rimasta disponibile nel parco server esistente. Ma la convinzione che un server possa davvero andare bene per qualunque applicazione, e che si possa popolare il data center con tanti sistemi ‘white box’, cioè cloni privi di marchio, virtualizzati, ‘clusterizzati’ e capaci di gestire tutti i workload, comincia a essere scalfita da una nuova onda di specializzazione che riguarda le caratteristiche dei server, e che oggi consente di selezionare, o anche confezionare su misura, il cluster di macchine hardware più adatte per soddisfare modelli d’uso specifici.
Consolidamento di VM, le caratteristiche hardware richieste
Il funzionamento delle VM dipende primariamente dalla memoria RAM e dai core del processore, e il numero di quelle che possono risiedere su un dato server varia a seconda di quanta memoria e risorse di elaborazione si allocano per ciascuna VM. In linea di principio, più memoria e core di processore ha il server, più VM può ospitare. In aggiunta, i server destinati a operazioni di elevato consolidamento delle VM dovrebbero anche includere funzionalità di resilienza: ad esempio, alimentatori ridondanti sostituibili a caldo (hot swappable), e memorie resilienti, come DIMM ‘hot swap’ e meccanismi di mirroring delle DIMM.
Un secondo aspetto a cui prestare attenzione quando si sceglie un server su cui eseguire un elevato consolidamento sono le operazioni di I/O (input/output) in rete, perché i workload aziendali scambiano dati, accedono a risorse di storage centralizzate, s’interfacciano con utenti sulla LAN, WAN e quant’altro. Qui i colli di bottiglia possono verificarsi quando diverse macchine virtuali cercano di condividere la stessa porta di rete di fascia bassa: in tal caso, i server con VM consolidate possono trarre vantaggio dall’integrazione di un’interfaccia di rete veloce, come una porta 10 Gigabit Ethernet (GbE), sebbene risulti spesso più economico e flessibile selezionare un server dotato di diverse porte 1 GbE, che sono poi aggregabili per ottenere più velocità e resilienza.
Requisiti per il consolidamento di container
I container virtualizzati inglobano il codice con tutte le dipendenze e, a differenza delle VM, condividono lo stesso kernel del sistema operativo sottostante: i contenitori, quindi, permettono di creare e dispiegare le applicazioni cloud-based in maniera semplice e altamente scalabile. Anche quando sul server si consolidano i container, sono sempre le risorse hardware di elaborazione a determinare quanti di essi la macchina fisica è potenzialmente in grado di ospitare: dunque, anche i server destinati a gestire i contenitori dovrebbero essere dotati di un’abbondante quantità di RAM e di core di elaborazione.
Il fatto che vi possano essere dozzine di container, che tentano di comunicare con lo stesso kernel del sistema operativo, può generare livelli di latenza in grado di degradare le prestazioni dei contenitori.
Tra l’altro, i container sono spesso dispiegati come componenti di un’applicazione, non come applicazioni complete, e come tali devono comunicare l’un l’altro e scalare secondo le necessità, per innalzare le prestazioni dell’intero workload: ciò però può produrre un enorme, e talvolta impredicibile, traffico API tra i container. Le limitazioni di banda di I/O all’interno dello stesso server, e l’efficienza architetturale dell’applicazione, condizionano quindi il numero di container che un server è realmente in grado di ospitare.
In maniera analoga, anche le operazioni I/O in rete possono creare potenziali colli di bottiglia, quando molti workload containerizzati devono comunicare al di fuori del server, sulla LAN o la WAN. I colli di bottiglia sulla rete possono rallentare l’accesso allo storage condiviso, ritardare le risposte del sistema agli utenti, e anche causare errori nei workload. Occorre quindi considerare le esigenze di networking dei container e dei workload, e configurare il server dotandolo di un’adeguata capacità di rete: quindi, come per le VM, si può pensare di integrare una porta veloce 10 GbE, oppure molteplici porte 1 GbE, che si possono combinare per incrementare velocità e resilienza.
Visualizzazione ed elaborazione scientifica influenzano la scelta del server
Un altro trend che non si può ignorare è la crescente presenza e integrazione di GPU (graphics processing unit) a livello di server, per assistere operazioni di calcolo impegnative, come l’elaborazione di big data, di dati scientifici, o attività di modellazione e visualizzazione che richiedono capacità grafiche.
Inoltre, usare le GPU significa anche poter conservare ed elaborare i data set di informazioni sensibili e di valore in un data center privato e ben protetto, invece di farli fluire verso l’esterno, dove possono più facilmente essere copiati o rubati. Tuttavia, in genere, il supporto per le GPU non consiste nella semplice aggiunta al server di una scheda GPU adatta, perché comunque esiste anche un impatto sugli altri componenti hardware della macchina (processore, memoria, I/O, storage, networking). Inoltre, gli adattatori GPU integrati nei server di classe enteprise sono spesso molto più sofisticati di quelli disponibili per i sistemi desktop o le workstation.
