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, presumiamo che ci siano 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, così possiamo usare uno switch ToR per connettere i server nei rack adiacenti.
La risposta alla domanda dipende molto da quale parametro stiamo ottimizzando e cosa possiamo variare per ottenere il miglior risultato. Ad esempio, potremmo dover occupare il minor spazio possibile, per lasciare più spazio per una futura crescita. O magari abbiamo 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 posa (questo è critico all'estremità delle file: con 10 rack in fila e 3 rack su uno switch, dovremo tirare i cavi in un'altra fila, o sottoutilizzare le porte dello switch), ecc., ecc. Storie separate: la scelta dei server e la scelta del DC, presumeremo che siano già stati scelti.
Sarebbe utile comprendere alcuni dettagli e sfumature, 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ò gestire ~7kW. Supponiamo che paghiamo nominalmente per 6kW per rack. Se il fornitore misura il nostro consumo solo da una fila di 10 rack, e non da ogni singolo rack, e se l'interruttore è impostato a una soglia di 7kW, allora tecnicamente possiamo consumare 6.9kW in un rack, 5.1kW in un altro e andrà tutto bene — non saremo puniti.
Di solito, il nostro obiettivo principale è la minimizzazione dei costi. Il miglior criterio per la misurazione è la riduzione del TCO (total cost of ownership — costo totale di proprietà). Esso si compone delle seguenti parti:
- CAPEX: acquisto dell'infrastruttura del DC, server, hardware di rete e cablaggio
- OPEX: affitto del DC, energia elettrica consumata, manutenzione. L'OPEX dipende dalla durata del servizio. È ragionevole supporre che sia pari a 3 anni.
A seconda di quanto sono grandi le varie parti nel complesso, dobbiamo ottimizzare la più costosa e lasciare che il resto utilizzi tutte le rimanenti risorse nel modo più efficace possibile.
Supponiamo di avere già un DC esistente, c'è un'altezza rack H unità (per esempio H=47), energia elettrica per rack Prack (Prack=6kW), e decidiamo di usare server 2U a h=2U. Rimuoviamo 2..4 unità dal rack per switch, patch panel e organizer. Quindi, fisicamente, nel nostro rack ci stanno Sh=rounddown((H-2..4)/h) server (cioè Sh = rounddown((47-4)/2)=21 server per rack). Ricordiamoci di questo Sh.
Nel caso più semplice, tutti i server nel rack sono identici. In totale, se riempiamo il rack server, allora per ciascun server possiamo spendere in media energia Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Per semplicità ignoreremo qui il consumo dello switch.
Facciamo un passo indietro e definiamo cos'è il consumo massimo del server Pmax. Se vogliamo semplificare, in modo molto inefficiente e totalmente sicuro, possiamo guardare ciò che è scritto sull'alimentatore del server — ed è questo.
Se le cose si complicano, più efficienti, prendiamo il TDP (thermal design package) di tutti i componenti e sommiamo (non è proprio corretto, ma può funzionare).
Di solito non conosciamo il TDP dei componenti (tranne la CPU), quindi utilizziamo l'approccio più corretto ma anche più complesso (richiede un laboratorio) — prendiamo un server sperimentale con la configurazione necessaria e lo carichiamo, ad esempio, con Linpack (CPU e memoria) e fio (dischi), misuriamo il consumo. Se vogliamo essere seri, bisogna anche creare un ambiente il più caldo possibile nel corridoio freddo durante i test, perché ça influisce sul consumo delle ventole e sul consumo della CPU. Otteniamo il consumo massimo di un server specifico con una configurazione specifica in queste condizioni specifiche sotto questo carico specifico. Ricordiamoci solo che un nuovo firmware, una diversa versione del software, altre condizioni possono influire sul risultato.
In sintesi, torniamo a Pserv e a come confrontarlo con Pmax. Questa è una questione di comprensione del funzionamento dei servizi e di quanto siano forti i nervi del tuo tecnico.
Se non vogliamo correre rischi, consideriamo che tutti i server possano iniziare a consumare il loro massimo contemporaneamente. In quel momento, potrebbe esserci un solo ingresso nel DC. L'infrastruttura, anche in queste condizioni, deve fornire il servizio, quindi Pserv ≡ Pmax. Questo approccio è assolutamente importante per l'affidabilità.
Se il CTO pensa non solo alla sicurezza ideale, ma anche ai costi dell'azienda e ha abbastanza coraggio, possiamo concludere che
- iniziamo a gestire i nostri fornitori, in particolare vietando la manutenzione programmata nei momenti di carico massimo previsto per minimizzare il calo di un input;
- e/o la nostra architettura consente di perdere un rack/riga/datacenter, mentre i servizi continuano a funzionare;
- e/o distribuiamo bene il carico orizzontalmente tra i rack, quindi i nostri servizi non raggiungono mai il massimo consumo in un singolo rack tutti insieme.
È molto utile non solo fare ipotesi, ma monitorare il consumo e sapere quanto realmente i server consumano elettricità in condizioni normali e di picco. Dopo un'analisi, quindi, il CTO riduce tutto ciò che ha e dice: «decidiamo, con una scelta forte, che il massimo medio raggiungibile dai picchi di consumo dei server per rack è **tanto** inferiore al massimo consumo», in termini semplici Pserv=0.8*Pmax.
Così, in un rack da 6kW non ci stanno più 16 server con Pmax = 375W, ma 20 server con Pserv = 375W * 0.8 = 300W. Cioè, il 25% in più di server. Questo rappresenta un grande risparmio — poiché anche i rack necessari diminuiscono immediatamente del 25% (e risparmiamo anche su PDU, switch e cavi). Un serio svantaggio di questa soluzione è che dobbiamo monitorare costantemente che le nostre supposizioni siano ancora valide. Che una nuova versione del firmware non cambi in modo significativo il funzionamento delle ventole e il consumo, che lo sviluppo non inizi improvvisamente a utilizzare i server in modo molto più efficiente (in altre parole, che non raggiunga un carico maggiore e un consumo più elevato sui server). In questo caso, sia le nostre supposizioni iniziali che le conclusioni diventano immediatamente errate. Questo è un rischio che deve essere affrontato responsabilmente (o evitato, e quindi pagare per rack evidentemente sottoutilizzati).
È importante notare che si dovrebbe cercare di distribuire i server di diversi servizi orizzontalmente tra i rack, se possibile. Questo è necessario per evitare situazioni in cui un gruppo di server per un servizio arriva e i rack vengono riempiti verticalmente per aumentare la 'densità' (perché è più semplice). In realtà, però, ci si ritrova con un rack pieno di server a bassa domanda dello stesso servizio e un altro pieno di server ad alta domanda. La probabilità che il secondo crolli è notevolmente più alta, poiché il profilo di carico è identico e tutti i server insieme in quel rack iniziano a consumare molto di più a causa dell'aumento del carico.
Torniamo alla distribuzione dei server nei rack. Abbiamo esaminato i limiti fisici dello spazio nel rack e le limitazioni relative all'alimentazione, ora diamo un'occhiata anche alla rete. Possiamo utilizzare switch con 24/32/48 porte N (per esempio abbiamo switch ToR da 48 porte). Le opzioni, per fortuna, non sono molte, se non consideriamo i cavi break-out. Consideriamo gli scenari in cui abbiamo uno switch per rack, uno switch per due o tre rack nel gruppo Rnet. Penso che avere più di tre rack in un gruppo sia già eccessivo, poiché il problema del cablaggio fra i rack diventa notevolmente più complicato.
Quindi, per ogni scenario di rete (1, 2 o 3 rack in gruppo) distribuiamo i server tra i rack:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Quindi, per l'opzione con 2 rack nel gruppo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 server per rack.
Analogamente calcoliamo le altre opzioni:
Srack1 = 20
Srack3 = 16
E siamo praticamente al traguardo. Calcoliamo il numero di rack per distribuire tutti i nostri server S (diciamo 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rack
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rack
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rack
In seguito calcoliamo il TCO per ogni opzione in base al numero di rack, al numero necessario di switch, cablaggio, ecc. Scegliamo l'opzione in cui il TCO è inferiore. Profitto!
Da notare che anche se il numero necessario di rack per le opzioni 1 e 2 è lo stesso, il loro prezzo sarà diverso, poiché il numero di switch per la seconda opzione è dimezzato, mentre la lunghezza dei cavi necessari è maggiore.
P.S. Se c'è la possibilità di giocare con la potenza per rack e l'altezza del rack, la variabilità aumenta. Ma il processo può essere ridotto a quanto descritto sopra, semplicemente testando varie opzioni. Sì, ci saranno più combinazioni, ma comunque un numero piuttosto limitato — l'alimentazione per rack per il calcolo può essere aumentata in incrementi di 1 kW, e ci sono un numero limitato di dimensioni standardizzate per i rack: 42U, 45U, 47U, 48U, 52U. E qui può aiutare l'analisi What-If di Excel in modalità Data Table. Osserviamo le tabelle ottenute e scegliamo il minimo.
Fonte: habr.com
