In una delle chat mi è stata posta una domanda:
— C'è qualcosa che posso leggere su come imballare correttamente i server nei rack?
Mi sono reso conto che non conoscevo un testo del genere, quindi ho scritto il mio.
Innanzitutto, questo testo riguarda i server fisici nei data center fisici (DC). In secondo luogo, crediamo che i server siano parecchi: centinaia-migliaia; per un numero inferiore questo testo non ha senso. In terzo luogo, consideriamo di avere tre vincoli: spazio fisico nei rack, alimentazione per rack e disposizione dei rack in file in modo da poter utilizzare uno switch ToR per connettere i server in rack adiacenti.
La risposta alla domanda dipende molto da quale parametro stiamo ottimizzando e da cosa possiamo variare per ottenere il miglior risultato. Ad esempio, basta occupare un minimo di spazio per lasciarne di più per un'ulteriore crescita. O forse abbiamo libertà nella scelta dell'altezza dei rack, della potenza per rack, delle prese nella PDU, del numero di rack in un gruppo di interruttori (un interruttore per 1, 2 o 3 rack), della lunghezza dei cavi e del lavoro di trazione ( questo è fondamentale alle estremità delle file: con 10 rack in fila e 3 rack per switch, dovrai tirare i cavi su un'altra fila o sottoutilizzare le porte dello switch), ecc., Ecc. Storie separate: selezione dei server e selezione dei DC, supponiamo che siano selezionati.
Sarebbe bene comprendere alcune sfumature e dettagli, in particolare il consumo medio/massimo dei server e come ci viene fornita l'elettricità. Quindi, se disponiamo di un'alimentazione russa da 230 V e una fase per rack, una macchina da 32 A può gestire circa 7 kW. Diciamo che paghiamo nominalmente 6kW per rack. Se il fornitore misura il nostro consumo solo per una fila di 10 rack, e non per ciascun rack, e se la macchina è impostata con un limite condizionale di 7 kW, allora tecnicamente possiamo consumare 6.9 kW in un singolo rack, 5.1 kW in un altro e andrà tutto bene, non sarà punibile.
Di solito il nostro obiettivo principale è ridurre al minimo i costi. Il miglior criterio da misurare è la riduzione del TCO (costo totale di proprietà). E' composto dai seguenti pezzi:
- CAPEX: acquisto di infrastrutture DC, server, hardware di rete e cavi
- OPEX: noleggio DC, consumo di elettricità, manutenzione. L'OPEX dipende dalla durata di servizio. È ragionevole supporre che siano 3 anni.
A seconda della dimensione dei singoli pezzi nella torta complessiva, dobbiamo ottimizzare quelli più costosi e lasciare che gli altri utilizzino tutte le risorse rimanenti nel modo più efficiente possibile.
Supponiamo di avere un DC esistente, un'altezza rack di H unità (ad esempio, H=47), elettricità per rack Prack (Prack=6kW) e di aver deciso di utilizzare server a due unità h=2U. Rimuoveremo 2..4 unità dal rack per interruttori, pannelli di permutazione e organizzatori. Quelli. fisicamente, abbiamo server Sh=rounddown((H-2..4)/h) nel nostro rack (ovvero Sh = rounddown((47-4)/2)=21 server per rack). Ricordiamo questo Sh.
Nel caso semplice, tutti i server in un rack sono identici. In totale, se riempiamo un rack di server, allora su ciascun server possiamo spendere in media la potenza Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Per semplicità, qui ignoriamo il consumo dello switch.
Facciamo un passo da parte e determiniamo qual è il consumo massimo del server Pmax. Se è molto semplice, molto inefficace e completamente sicuro, leggiamo ciò che è scritto sull'alimentatore del server: eccolo.
Se è più complicato, più efficiente, allora prendiamo il TDP (pacchetto di progettazione termica) di tutti i componenti e lo riassumiamo (questo non è del tutto vero, ma è possibile).
Di solito non conosciamo il TDP dei componenti (ad eccezione della CPU), quindi adottiamo l'approccio più corretto, ma anche il più complesso (abbiamo bisogno di un laboratorio): prendiamo un server sperimentale con la configurazione richiesta e lo carichiamo, ad esempio con Linpack (CPU e memoria) e fio (dischi) si misurano i consumi. Se lo prendiamo sul serio, dobbiamo anche creare l'ambiente più caldo nel corridoio freddo durante i test, perché questo influenzerà sia il consumo delle ventole che quello della CPU. Otteniamo il consumo massimo di un server specifico con una configurazione specifica in queste condizioni specifiche con questo carico specifico. Intendiamo semplicemente che il nuovo firmware del sistema, una diversa versione del software e altre condizioni potrebbero influenzare il risultato.
Quindi torniamo a Pserv e a come lo confrontiamo con Pmax. Si tratta di capire come funzionano i servizi e quanto sono forti i nervi del tuo direttore tecnico.
Se non corriamo alcun rischio, crediamo che tutti i server possano iniziare a consumare al massimo contemporaneamente. Nello stesso momento può verificarsi un ingresso nella DC. Anche in queste condizioni, infra deve fornire il servizio, quindi Pserv ≡ Pmax. Questo è un approccio in cui l’affidabilità è assolutamente importante.
Se il direttore tecnico pensa non solo alla sicurezza ideale, ma anche al denaro dell’azienda ed è abbastanza coraggioso, allora puoi decidere
- Stiamo iniziando a gestire i nostri fornitori, in particolare stiamo vietando la manutenzione programmata nei momenti di picco di carico pianificato per ridurre al minimo il calo di un input;
- e/o la nostra architettura consente di perdere un rack/fila/DC, ma i servizi continuano a funzionare;
- e/o distribuiamo bene il carico orizzontalmente sugli scaffali, in modo che i nostri servizi non raggiungano mai il consumo massimo in uno scaffale tutti insieme.
Qui è molto utile non solo indovinare, ma monitorare i consumi e sapere come i server effettivamente consumano elettricità in condizioni normali e di punta. Pertanto, dopo alcune analisi, il direttore tecnico spreme tutto ciò che ha e dice: "decidiamo volontariamente che la media massima ottenibile del consumo massimo di server per rack è **molto** inferiore al consumo massimo", condizionatamente Pserv = 0.8*Pmax.
E poi un rack da 6kW non può più ospitare 16 server con Pmax = 375W, ma 20 server con Pserv = 375W * 0.8 = 300W. Quelli. 25% di server in più. Si tratta di un notevole risparmio: dopo tutto, avremo immediatamente bisogno del 25% in meno di rack (e risparmieremo anche su PDU, switch e cavi). Un grave svantaggio di tale soluzione è che dobbiamo monitorare costantemente che le nostre ipotesi siano ancora corrette. Che la nuova versione firmware non modifica in modo significativo il funzionamento delle ventole e i consumi, che lo sviluppo improvvisamente con la nuova release non ha iniziato a utilizzare i server in modo molto più efficiente (leggi: hanno ottenuto un carico maggiore e un consumo maggiore sul server). Dopotutto, sia le nostre ipotesi iniziali che le nostre conclusioni diventano immediatamente errate. Questo è un rischio che deve essere preso in modo responsabile (o evitato e poi pagato per scaffalature evidentemente sottoutilizzate).
Una nota importante: dovresti provare a distribuire i server di diversi servizi orizzontalmente sui rack, se possibile. Ciò è necessario affinché non si verifichino situazioni in cui arriva un lotto di server per un servizio, i rack ne vengono riempiti verticalmente per aumentare la "densità" (perché è più semplice in questo modo). In realtà, si scopre che un rack è pieno di server identici a basso carico dello stesso servizio e l'altro è pieno di server altrettanto carichi elevati. La probabilità della seconda caduta è significativamente più alta, perché il profilo di carico è lo stesso e tutti i server insieme in questo rack iniziano a consumare la stessa quantità a causa dell'aumento del carico.
Torniamo alla distribuzione dei server nei rack. Abbiamo esaminato lo spazio fisico del rack e le limitazioni di potenza, ora diamo un'occhiata alla rete. Puoi utilizzare switch con porte 24/32/48 N (ad esempio, abbiamo switch ToR a 48 porte). Fortunatamente, non ci sono molte opzioni se non si pensa ai cavi breakout. Stiamo considerando scenari in cui abbiamo uno switch per rack, uno switch per due o tre rack nel gruppo Rnet. Mi sembra che più di tre rack in un gruppo siano già troppi, perché... il problema del cablaggio tra i rack diventa molto più grande.
Quindi, per ogni scenario di rete (1, 2 o 3 rack in un gruppo), distribuiamo i server tra i rack:
Srack = min(Sh, arrotondamento(Prack/Pserv), arrotondamento(N/Rnet))
Pertanto, per l'opzione con 2 rack in un gruppo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 server per rack.
Consideriamo le restanti opzioni allo stesso modo:
Srack1 = 20
Srack3 = 16
E ci siamo quasi. Contiamo il numero di rack per distribuire tutti i nostri server S (supponiamo che sia 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = arrotondamento(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rack
R2 = arrotondamento(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rack
R3 = arrotondamento(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rack
Successivamente, calcoliamo il TCO per ciascuna opzione in base al numero di rack, al numero richiesto di switch, al cablaggio, ecc. Scegliamo l'opzione in cui il TCO è inferiore. Profitto!
Si noti che sebbene il numero richiesto di rack per le opzioni 1 e 2 sia lo stesso, il loro prezzo sarà diverso il numero di interruttori per la seconda opzione è la metà e la lunghezza dei cavi necessari è maggiore.
PS Se hai la possibilità di giocare con la potenza per rack e l'altezza del rack, la variabilità aumenta. Ma il processo può essere ridotto a quello sopra descritto semplicemente esaminando le opzioni. Sì, ci saranno più combinazioni, ma si tratterà comunque di un numero molto limitato: l'alimentazione al rack per il calcolo può essere aumentata in incrementi di 1 kW, i rack tipici sono disponibili in un numero limitato di dimensioni standard: 42U, 45U, 47U, 48U , 52U. E qui l’analisi What-If di Excel in modalità Tabella dati può aiutare con i calcoli. Guardiamo i piatti ricevuti e scegliamo il minimo.
Fonte: habr.com