In una delle chat mi è stata posta una domanda:
— C'è qualcosa da leggere su come imballare correttamente i server nei rack?
Ho capito che non conoscevo un testo del genere, quindi ho scritto il mio.
Innanzitutto, questo testo riguarda server fisici in data center fisici (DC). In secondo luogo, consideriamo che ci sono molti server: centinaia o migliaia; per un numero inferiore questo testo non ha senso. In terzo luogo, consideriamo che abbiamo tre limitazioni: spazio fisico nei rack, alimentazione per rack e supponiamo che i rack siano disposti in file, in modo da poter utilizzare uno switch ToR per connettere server nei rack vicini.
La risposta alla domanda dipende molto da quale parametro stiamo ottimizzando e cosa possiamo variare per ottenere il miglior risultato. Ad esempio, dobbiamo solo occupare il minor spazio possibile per lasciare più spazio per la crescita futura. Oppure, potremmo avere libertà nella scelta dell'altezza dei rack, della potenza per rack, delle prese nel PDU, del numero di rack nel gruppo di switch (un switch per 1, 2 o 3 rack), della lunghezza dei cavi e dei lavori di cablaggio (questo è critico alla fine delle file: con 10 rack in un file e 3 rack per switch, si dovrà tirare cavi in un'altra fila o non utilizzare porti nello switch), ecc., ecc. Storie separate: scelta dei server e scelta dei DC, supponiamo siano già stati scelti.
Sarebbe utile comprendere alcune sfumature e dettagli, in particolare il consumo medio/massimo dei server e come ci viene fornita l'elettricità. Quindi, se abbiamo un'alimentazione russa a 230V e una fase per rack, un interruttore da 32A può supportare circa 7kW. Supponiamo che paghiamo nominalmente per 6kW per rack. Se il provider misura il nostro consumo solo per la fila di 10 rack e non per ogni rack, e se l'interruttore è impostato su una soglia di 7kW, tecnicamente possiamo consumare 6.9kW in un rack separato, 5.1kW in un altro e tutto sarà a posto — senza penalità.
Di solito, il nostro obiettivo principale è la minimizzazione dei costi. Il miglior criterio di misurazione è la riduzione del TCO (costo totale di proprietà). Esso è composto dai seguenti elementi:
- CAPEX: acquisto dell'infrastruttura del DC, dei server, delle apparecchiature di rete e cablaggio
- OPEX: affitto del DC, elettricità consumata, manutenzione. L'OPEX dipende dalla vita utile. È ragionevole presumere che equivalga a 3 anni.
A seconda delle dimensioni dei singoli pezzi nel grande dolce, dobbiamo ottimizzare il più costoso, mentre il resto dovrebbe utilizzare tutte le risorse rimanenti nel modo più efficiente possibile.
Supponiamo che abbiamo già un DC esistente, con un'altezza di armadietto H unità (per esempio H=47), elettricità per armadietto Prack (Prack=6 kW), e abbiamo deciso di utilizzare server a 2U. Rimuoviamo 2..4 unità dall'armadietto per switch, pannelli patch e organizer. Cioè, fisicamente, nel nostro armadietto ci stanno Sh=rounddown((H-2..4)/h) server (cioè Sh = rounddown((47-4)/2)=21 server per armadietto). Ricordiamoci di questo Sh.
In un caso semplice, tutti i server nell'armadietto sono uguali. In totale, se riempiamo l'armadietto server, allora possiamo spendere in media potenza Pserv=Prack/Sh (Pserv = 6000 W/21 = 287 W) per ogni server. Per semplicità, qui ignoriamo il consumo dello switch.
Facciamo un passo indietro e definiamo che cos'è il consumo massimo del server Pmax. Se molto semplicemente, molto inefficacemente e completamente in sicurezza, leggiamo quello che è scritto sull'alimentatore del server — questo è.
Se vogliamo essere più precisi ed efficaci, prendiamo il TDP (thermal design package) di tutti i componenti e facciamo la somma (non è proprio corretto, ma si può fare anche così).
Di solito non conosciamo il TDP dei componenti (eccetto la CPU), quindi adotteremo l'approccio più corretto, ma anche il più complesso (serve un laboratorio) — prendiamo un server sperimentale della configurazione richiesta e lo carichiamo, ad esempio, con Linpack (CPU e memoria) e fio (dischi), misuriamo il consumo. Se vogliamo essere seri, dobbiamo anche creare l'ambiente più caldo nel corridoio freddo durante i test, perché questo influisce sul consumo delle ventole e sulla potenza della CPU. Otteniamo il consumo massimo di un server specifico con una configurazione specifica in queste condizioni particolari sotto questo specifico carico. Teniamo presente che un nuovo firmware, una versione software diversa, e altre condizioni possono influenzare il risultato.
In sintesi, ritorniamo a Pserv e come confrontarlo con Pmax. Questa è una questione di comprensione del funzionamento dei servizi e di quanto siano forti nervi del vostro tecnico.
Se non vogliamo correre alcun rischio, consideriamo che tutti i server possano iniziare a consumare il proprio massimo contemporaneamente. In quel momento, potrebbe esserci un singolo ingresso nel DC. L'infrastruttura, in queste condizioni, deve fornire servizio, quindi Pserv ≡ Pmax. Questo è un approccio in cui l'affidabilità è assolutamente fondamentale.
Se il direttore tecnico non pensa solo alla sicurezza ideale, ma anche al denaro dell'azienda ed è abbastanza audace, si può decidere che
- iniziamo a gestire i nostri fornitori, in particolare, vietiamo di eseguire manutenzioni pianificate nei momenti di carico di picco previsto per minimizzare il crollo di un carico;
- e/o la nostra architettura consente di perdere un rack/riga/DC, mentre i servizi continuano a funzionare;
- e/o distribuiamo bene il carico orizzontalmente sui rack, quindi i nostri servizi non raggiungeranno mai il consumo massimo in un unico rack tutto insieme.
È molto utile non solo ipotizzare, ma monitorare il consumo e sapere come realmente i server consumano elettricità in condizioni normali e di picco. Quindi, dopo un'analisi, il direttore tecnico comprime tutto ciò che ha e dice: «decidiamo con una risoluzione che la media massima raggiungibile dei picchi di consumo dei server per rack è **tanto** sotto il massimo consumo», in termini condizionali Pserv=0,8*Pmax.
E allora in un rack da 6kW non entrano più 16 server con Pmax = 375W, ma 20 server con Pserv = 375W * 0,8 = 300W. Vale a dire, il 25% in più di server. Questo è un grandissimo risparmio — del resto, anche i rack di cui abbiamo bisogno saranno immediatamente il 25% in meno (e risparmieremo anche su PDU, switch e cavi). Un grave svantaggio di questa soluzione è che è necessario monitorare costantemente che le nostre supposizioni siano ancora valide. Che la nuova versione del firmware non modifica sostanzialmente il funzionamento delle ventole e il consumo, che lo sviluppo improvvisamente con la nuova release non inizi a utilizzare i server in modo molto più efficace (leggi, ha ottenuto un maggior carico e un maggior consumo dal server). Perché allora, le nostre supposizioni iniziali e le conclusioni diventano immediatamente errate. Questo è un rischio che va assunto responsabilmente (o evitato, e allora si paga per rack ovviamente sottoutilizzati).
Nota importante: è consigliabile cercare di distribuire i server di diversi servizi orizzontalmente nelle racks, se possibile. Questo per evitare situazioni in cui un lotto di server per un servizio arriva e le racks vengono riempite verticalmente per aumentare la "densità" (perché è più semplice). Nella realtà, si verifica che una rack sia piena di server a bassa carico dello stesso servizio, mentre un'altra è piena di server ad alto carico. La probabilità di caduta della seconda è notevolmente più alta, poiché il profilo del carico è identico e tutti i server insieme in quella rack iniziano a consumare la stessa quantità a causa dell'aumento del carico.
Tornando alla distribuzione dei server nelle racks. Abbiamo esaminato le limitazioni fisiche in termini di spazio nella rack e le limitazioni legate all'alimentazione, ora diamo un'occhiata anche alla rete. È possibile utilizzare switch da 24/32/48 porte N (per esempio abbiamo switch ToR a 48 porte). Fortunatamente, le opzioni non sono molte, se non si considerano i cavi break-out. Consideriamo scenari in cui abbiamo un switch per rack, uno switch per due o tre racks nel gruppo Rnet. Penso che avere più di tre racks nel gruppo sia già troppo, poiché il problema del cablaggio tra le racks diventa sostanzialmente più grande.
Quindi, per ciascun scenario di rete (1, 2 o 3 racks nel gruppo) distribuiamo i server nelle racks:
Srack = min(Sh, arrotonda(Prack/Pserv), arrotonda(N/Rnet))
Pertanto, per l'opzione con 2 racks nel gruppo:
Srack2 = min(21, arrotonda(6000/300), arrotonda(48/2)) = min(21, 20, 24) = 20 server per rack.
Calcoliamo allo stesso modo le altre opzioni:
Srack1 = 20
Srack3 = 16
E siamo praticamente al traguardo. Calcoliamo il numero di racks per distribuire tutti i nostri server S (facciamo che sia 1000):
R = arrotonda(S / (Srack * Rnet)) * Rnet
R1 = arrotonda(1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R2 = arrotonda(1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R3 = arrotonda(1000 / (16 * 3)) * 3 = 25 * 2 = 63 racks
Ora calcoliamo il TCO per ciascuna opzione sulla base del numero di racks, numero necessario di switch, cablaggio, ecc. Scegliamo l'opzione in cui il TCO è minore. Profitto!
Nota che, sebbene il numero necessario di racks per le opzioni 1 e 2 sia lo stesso, il loro costo sarà diverso, poiché il numero di switch per la seconda opzione è la metà, mentre la lunghezza dei cavi necessari è maggiore.
P.S. Se c'è la possibilità di giocare con la potenza e l'altezza del rack, la variabilità aumenta. Ma il processo può essere ridotto a quanto descritto sopra, semplicemente riempiendo le opzioni. Sì, ci saranno più combinazioni, ma rimane comunque un numero piuttosto limitato: l'alimentazione sul rack per i calcoli può essere incrementata di 1 kW alla volta e i rack standard hanno un numero limitato di dimensioni: 42U, 45U, 47U, 48U, 52U. Qui può aiutare l'analisi What-If di Excel in modalità Data Table. Guardiamo le tabelle risultanti e selezioniamo il minimo.
Fonte: habr.com
