Într-una dintre conversații mi s-a pus o întrebare:
— Pot citi ceva despre cum să împachetez corect serverele în rafturi?
Mi-am dat seama că nu cunoșteam un astfel de text, așa că l-am scris pe al meu.
În primul rând, acest text este despre serverele fizice din centrele de date fizice (DC). În al doilea rând, credem că există destul de multe servere: sute-mii pentru un număr mai mic, acest text nu are sens; În al treilea rând, considerăm că avem trei constrângeri: spațiu fizic în rafturi, sursă de alimentare pe rafturi și lăsăm rafturile să stea în rânduri, astfel încât să putem folosi un comutator ToR pentru a conecta serverele din rafturile adiacente.
Răspunsul la întrebare depinde foarte mult de ce parametru optimizăm și de ce putem varia pentru a obține cel mai bun rezultat. De exemplu, trebuie doar să ocupăm un minim de spațiu pentru a lăsa mai mult pentru creștere ulterioară. Sau poate avem libertate în a alege înălțimea rack-urilor, puterea per rack, prize în PDU, numărul de rack-uri dintr-un grup de comutatoare (un întrerupător pentru 1, 2 sau 3 rack-uri), lungimea firelor și lucrul de tragere ( acest lucru este critic la capetele rândurilor: cu 10 rafturi la rând și 3 rafturi pe comutator, va trebui să trageți firele pe alt rând sau să subutilizați porturile din comutator), etc., etc. Povești separate: selecția serverelor și selecția DC-urilor, vom presupune că acestea sunt selectate.
Ar fi bine să înțelegem câteva dintre nuanțe și detalii, în special, consumul mediu/maxim al serverelor și modul în care ne este furnizată electricitatea. Deci, dacă avem o sursă de alimentare rusească de 230V și o fază per rack, atunci o mașină de 32A poate gestiona ~7kW. Să presupunem că plătim nominal pentru 6 kW per rack. Dacă furnizorul măsoară consumul nostru doar pentru un rând de 10 rafturi și nu pentru fiecare rafturi și dacă mașina este setată la o limită condiționată de 7 kW, atunci din punct de vedere tehnic putem consuma 6.9 kW într-un singur rack, 5.1 kW în altul și totul va fi ok - nu se pedepsește.
De obicei, scopul nostru principal este de a minimiza costurile. Cel mai bun criteriu de măsurat este reducerea TCO (costul total de proprietate). Este format din următoarele piese:
- CAPEX: achiziționarea infrastructurii DC, servere, hardware de rețea și cablare
- OPEX: inchiriere DC, consum de energie electrica, intretinere. OPEX depinde de durata de viață. Este rezonabil să presupunem că este de 3 ani.
În funcție de cât de mari sunt piesele individuale în plăcinta generală, trebuie să le optimizăm pe cele mai scumpe și să lăsăm restul să folosească toate resursele rămase cât mai eficient posibil.
Să presupunem că avem un DC existent, există o înălțime de rack de unități H (de exemplu, H=47), electricitate per rack Prack (Prack=6kW) și am decis să folosim servere cu două unități h=2U. Vom scoate 2..4 unități din rack pentru comutatoare, panouri de corecție și organizatoare. Acestea. fizic, avem servere Sh=rounddown((H-2..4)/h) în rack (adică Sh = rounddown((47-4)/2)=21 servere per rack). Să ne amintim acest Sh.
În cazul simplu, toate serverele dintr-un rack sunt identice. În total, dacă umplem un rack cu servere, atunci pe fiecare server putem cheltui în medie puterea Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Pentru simplitate, ignorăm aici consumul de comutator.
Să facem un pas deoparte și să stabilim care este consumul maxim de server Pmax. Dacă este foarte simplu, foarte ineficient și complet sigur, atunci citim ce este scris pe sursa de alimentare a serverului - asta este.
Dacă este mai complicat, mai eficient, atunci luăm TDP (pachetul de design termic) al tuturor componentelor și îl rezumăm (acest lucru nu este foarte adevărat, dar este posibil).
De obicei nu cunoaștem TDP-ul componentelor (cu excepția procesorului), așa că luăm cea mai corectă, dar și cea mai complexă abordare (avem nevoie de un laborator) - luăm un server experimental cu configurația necesară și îl încărcăm, de exemplu, cu Linpack (CPU și memorie) și fio (discuri), măsuram consumul. Dacă o luăm în serios, trebuie să creăm și cel mai cald mediu în coridorul rece în timpul testelor, deoarece acest lucru va afecta atât consumul ventilatorului, cât și consumul procesorului. Obținem consumul maxim al unui anumit server cu o anumită configurație în aceste condiții specifice sub această încărcare specifică. Ne referim pur și simplu că noul firmware de sistem, o versiune diferită de software și alte condiții pot afecta rezultatul.
Deci, revenim la Pserv și cum îl comparăm cu Pmax. Este o chestiune de a înțelege cum funcționează serviciile și cât de puternici sunt nervii directorului tău tehnic.
Dacă nu ne asumăm niciun risc, credem că toate serverele pot începe simultan să consume maxim. În același moment, poate apărea o intrare în DC. Chiar și în aceste condiții, infra trebuie să ofere serviciu, deci Pserv ≡ Pmax. Aceasta este o abordare în care fiabilitatea este absolut importantă.
Dacă directorul de tehnologie se gândește nu numai la securitatea ideală, ci și la banii companiei și este suficient de curajos, atunci puteți decide că
- Începem să ne gestionăm furnizorii, în special, interzicem întreținerea programată în momentele de sarcină maximă planificată pentru a minimiza scăderea într-o singură intrare;
- și/sau arhitectura noastră vă permite să pierdeți un rack/rând/DC, dar serviciile continuă să funcționeze;
- și/sau răspândim încărcătura bine pe orizontală pe rafturi, astfel încât serviciile noastre nu vor atinge niciodată consumul maxim într-un singur rafturi.
Aici este foarte util nu doar să ghicești, ci și să monitorizezi consumul și să știi câtă energie electrică consumă efectiv serverele în condiții normale și de vârf. Prin urmare, după câteva analize, directorul tech stoarce tot ce are și spune: „luăm o decizie volitivă că media maximă realizabilă a consumului maxim de server pe rack este **atât de mult** sub consumul maxim”, condiționat Pserv = 0.8* Pmax.
Și atunci un rack de 6kW nu mai poate găzdui 16 servere cu Pmax = 375W, ci 20 de servere cu Pserv = 375W * 0.8 = 300W. Acestea. Cu 25% mai multe servere. Aceasta este o economie foarte mare - la urma urmei, avem nevoie imediat de 25% mai puține rafturi (și vom economisi și la PDU-uri, comutatoare și cabluri). Un dezavantaj serios al unei astfel de soluții este că trebuie să monitorizăm constant dacă presupunerile noastre sunt încă corecte. Că noua versiune de firmware nu schimbă semnificativ funcționarea ventilatoarelor și consumul, că dezvoltarea brusc cu noua versiune nu a început să folosească serverele mult mai eficient (citiți: au obținut o încărcare mai mare și un consum mai mare pe server). La urma urmei, atunci atât ipotezele noastre inițiale, cât și concluziile noastre devin imediat incorecte. Acesta este un risc care trebuie asumat în mod responsabil (sau evitat și apoi plătit pentru rafturile evident subutilizate).
O notă importantă - ar trebui să încercați să distribuiți serverele de la diferite servicii orizontal peste rafturi, dacă este posibil. Acest lucru este necesar pentru ca situațiile să nu se întâmple când sosește un lot de servere pentru un serviciu, rafturile sunt împachetate vertical cu el pentru a crește „densitatea” (pentru că este mai ușor așa). În realitate, se dovedește că un rack este umplut cu servere identice cu încărcare redusă ale aceluiași serviciu, iar celălalt este plin cu servere la fel de mare. Probabilitatea ca al doilea să cadă este semnificativ mai mare, deoarece profilul de încărcare este același și toate serverele împreună din acest rack încep să consume aceeași cantitate ca urmare a încărcării crescute.
Să revenim la distribuția serverelor în rafturi. Ne-am uitat la limitarea spațiului fizic în rack și a puterii, acum să ne uităm la rețea. Puteți utiliza comutatoare cu porturi 24/32/48 N (de exemplu, avem comutatoare ToR cu 48 de porturi). Din fericire, nu există multe opțiuni dacă nu vă gândiți la cablurile de rupere. Luăm în considerare scenarii când avem un comutator pe rack, un comutator pentru două sau trei rack-uri în grupul Rnet. Mi se pare că mai mult de trei rafturi într-un grup este deja prea mult, pentru că... problema cablajului între rafturi devine mult mai mare.
Deci, pentru fiecare scenariu de rețea (1, 2 sau 3 rafturi într-un grup), distribuim serverele între rafturi:
Srack = min(Sh, rotunjire în jos(Prack/Pserv), rotunjire în jos (N/Rnet))
Astfel, pentru opțiunea cu 2 rafturi într-un grup:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 de servere per rack.
Luăm în considerare opțiunile rămase în același mod:
Srack1 = 20
Srack3 = 16
Și aproape suntem acolo. Numărăm numărul de rafturi pentru a distribui toate serverele noastre S (să fie 1000):
R = rotunjire (S / (Srack * Rnet)) * Rnet
R1 = rotunjire (1000 / (20 * 1)) * 1 = 50 * 1 = 50 rafturi
R2 = rotunjire (1000 / (20 * 2)) * 2 = 25 * 2 = 50 rafturi
R3 = rotunjire (1000 / (16 * 3)) * 3 = 25 * 2 = 63 rafturi
Apoi, calculăm TCO pentru fiecare opțiune în funcție de numărul de rack-uri, numărul necesar de comutatoare, cablare etc. Alegem opțiunea în care TCO este mai mic. Profit!
Rețineți că, deși numărul necesar de rafturi pentru opțiunile 1 și 2 este același, prețul lor va fi diferit, deoarece numărul de comutatoare pentru a doua opțiune este la jumătate, iar lungimea cablurilor necesare este mai mare.
PS Dacă aveți ocazia să vă jucați cu puterea per rack și înălțimea rack-ului, variabilitatea crește. Dar procesul poate fi redus la cel descris mai sus prin simpla parcurgere a opțiunilor. Da, vor exista mai multe combinații, dar totuși un număr foarte limitat - sursa de alimentare a rack-ului pentru calcul poate fi mărită în pași de 1 kW, rafturile tipice vin într-un număr limitat de dimensiuni standard: 42U, 45U, 47U, 48U , 52U. Și aici analiza Excel ce se întâmplă în modul Tabel de date poate ajuta la calcule. Ne uităm la plăcuțele primite și selectăm minimul.
Sursa: www.habr.com