Në një nga bisedat, më u bë një pyetje:
— A ka ndonjë gjë për të lexuar, si të paketojmë serverat në rack?
E kuptova që nuk dija një tekst të tillë, prandaj shkrova timin.
Së pari, ky tekst është për serverat fizikë në qendrat fizike të të dhënave (DC). Së dyti, le të supozojmë se kemi shumë servera: qindra-mijëra, për numra më të vogla ky tekst nuk ka kuptim. Së tretë, le të supozojmë se kemi tre kufizues: hapësira fizike në rack, energjia elektrike për rack, dhe le të themi se rack-et janë vendosur në radhë, kështu që mund të përdorim një switch ToR për të lidhur serverat në rack-et fqinje.
Përgjigjja në pyetje varet shumë nga çfarë parametri ne po optimizojmë dhe çfarë mund të ndryshojmë për të arritur rezultat më të mirë. Për shembull, ndoshta na nevojitet të zëmë sa më pak hapësirë, që të lëmë më shumë për rritje të mëtejshme. Ndoshta kemi liri të zgjedhim lartësinë e rack-ëve, fuqinë për rack, prizat në PDU, numrin e rack-ëve në grupin e switches (një switch për 1, 2 ose 3 rack-e), gjatësinë e kabllove dhe punimet e tërheqjes (kjo është kritike në fund të radhëve: nëse kemi 10 rack-e në një radhë dhe 3 rack-e në switch, do të duhet të tërheqim kabllot në një radhë tjetër ose të mos përdorim portet në switch), etj., etj. Historia është më vete: zgjedhja e serverave dhe zgjedhja e DC, le të supozojmë se ato janë zgjedhur.
Do të ishte mirë të kuptonim disa nuanca dhe detaje, në veçanti, konsumimin mesatar/maksimal të serverave, dhe si na jepet energjia elektrike. Nëse kemi furnizim elektrik rus 230V dhe një fazë për rack, atëherë një automatik 32A mund të mbajë ~7kW. Le të supozojmë se nominalisht paguajmë për 6kW për rack. Nëse ofruesi ynë mat konsumimin tonë vetëm për një radhë me 10 rack-e, e jo për secilën rack, dhe nëse automatik është vendosur në një pikë që mban kushërisht 7kW, atëherë teknikisht mund të kemi në një rack 6.9kW, në tjetrën 5.1kW dhe gjithçka do të ishte në rregull — pa ndëshkime.
Zakonisht, qëllimi ynë kryesor është minimizimi i shpenzimeve. Kriteri më i mirë për matjen është ulja e TCO (kosto totale e pronësisë). Kjo përbëhet nga pjesët e mëposhtme:
- CAPEX: blerja e infrastrukturës së DC, serverave, pajisjeve rrjetore dhe kabllovimi
- OPEX: qiraja e DC, energjia elektrike e konsumuar, mirëmbajtja. OPEX varet nga koha e shërbimit. Është e arsyeshme të supozohet se është e barabartë me 3 vjet.
Në varësi të asaj se sa të mëdha janë pjesët e veçanta në tortën e përgjithshme, na nevojitet të optimizojmë atë më të shtrenjtën, ndërsa pjesët e tjera le t'i përdorim sa më eficient.
Le të supozojmë se kemi një DC ekzistues, kemi lartësinë e rack-ut H njësish (për shembull H=47), energjinë për rack Prack (Prack=6kW), dhe kemi vendosur të përdorim h=2U servera dy njëshe. Të heqim 2..4 njësitë nga rack-u për switches, panelet patch dhe organizatorët. Pra, fizikisht, kemi në rack Sh=rounddown((H-2..4)/h) servera (dmth. Sh = rounddown((47-4)/2)=21 server në rack). Na mbetet ta mbajmë mend këtë Sh.
Në rastin e thjeshtë, të gjithë serverat në rack janë të njëjtë. Pra, nëse e mbushim rack-un serverëve, atëherë për çdo server ne do të mund të shpenzojmë mesatarisht fuqinë Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Për thjeshtësi, këtu injorojmë konsumimin e switch-it.
Të bëjmë një hap mbrapa dhe të përcaktojmë se çfarë është konsumimi maksimal i serverit Pmax. Nëse është shumë e thjeshtë, shumë joefikas dhe krejtësisht e sigurt, atëherë le të lexojmë çfarë është shkruar në bllokun e energjisë të serverit — kjo është ajo.
Nëse është më e komplikuar, më efektiv, atëherë merrni TDP (paketa e projektit termal) të të gjithë komponentëve dhe përzini (këto nuk janë shumë të vërteta, por mund të bëni edhe kështu).
Zakonisht ne nuk e dimë TDP-në e Komponentëve (përveç CPU), prandaj marrim qasjen më të drejtë, por edhe më të komplikuar (kemi nevojë për një laborator) — marrim një server eksperimental me konfigurimin e nevojshëm dhe e ngarkojmë, për shembull, me Linpack (CPU dhe memorie) dhe fio (disku), masim konsumimin. Nëse bëjmë këtë me seriozitet, duhet gjithashtu të krijojmë ambientin më të ngrohtë në korridorin e ftohtë gjatë testimeve, sepse kjo ndikon gjithashtu në konsumimin e ventilatorëve dhe të CPU-së. Marrim konsumimin maksimal të një serveri të caktuar me një konfigurim të caktuar në këto kushte të caktuara nën këtë ngarkesë të caktuar. Thjesht mbani në mend se një firmware i ri, një version tjetër i softuerit dhe kushte të tjera mund të ndikojnë në rezultatin.
Pra, kthehemi te Pserv dhe si ta krahasojmë me Pmax. Kjo është një çështje e kuptimit të funksionimit të shërbimeve dhe sa të forta janë nervat e menaxherit tuaj teknik.
Nëse nuk dëshirojmë të rrezikojmë, atëherë supozojmë se të gjithë serverat mund të fillojnë menjëherë të konsumojnë maksimalin e tyre. Në të njëjtën herë mund të krijohet një hyrje për DC. Infrastruktura në këto kushte duhet të ofrojë shërbime, prandaj Pserv ≡ Pmax. Ky është një qasje ku e rëndësishme është siguria absolute.
Nëse drejtori teknik mendon jo vetëm për sigurinë perfekte, por edhe për paratë e kompanisë dhe është mjaft guximtar, mund të vendoset se
- ne fillojmë të menaxhojmë ofruesit tanë, veçanërisht duke ndaluar kryerjen e mirëmbajtjes së planifikuar në momentet e ngarkesës maksimale të planifikuar për të minimizuar rënien e një futjeje;
- dhe/ose arkitektura jonë lejon të humbasim një raft/rresht/datacenter, ndërsa shërbimet vazhdojnë të punojnë;
- dhe/ose ne mirëshpërndajmë ngarkesën horizontalisht nëpër rafte, prandaj shërbimet tona kurrë nuk arrijnë maksimumin e konsumit në një raft të vetëm.
Këtu është shumë e dobishme të monitorojmë konsumin dhe të dimë se si realisht serverët konsumojnë energji në kushte normale dhe në pikun e ngarkesës. Prandaj, pas një analize të caktuar, drejtori teknik përmbledh gjithçka që ka dhe thotë: "ne marrim një vendim me forcë, që mesatarja maksimale e arritshme e konsumit të serverëve në raft është **kaq shumë** më poshtë se maksimumi i konsumit", duke e përshkruar si Pserv=0.8*Pmax.
Dhe atëherë në një raft me 6kW nuk futen më 16 serverë me Pmax = 375W, por 20 serverë me Pserv = 375W * 0.8 = 300W. Në praktikë, do të thotë 25% më shumë serverë. Kjo është një kursim i madh - sepse na duhen menjëherë 25% më pak rafte (dhe gjithashtu kursejmë për PDU, switch dhe kabllo). Një disavantazh i rëndësishëm i këtij vendimi është se duhet të monitorojmë vazhdimisht nëse supozimet tona janë ende të sakta. Nëse versioni i ri i firmware-it nuk ndikon në mënyrë të konsiderueshme në punën e ventilatorëve dhe konsumit, nëse zhvillimi papritmas me një version të ri nuk fillon të përdorë serverët më në mënyrë më efikase (domethënë arrijmë ngarkim më të lartë dhe konsum më të madh në server). Sepse atëherë supozimet tona fillestare dhe përfundimet bëhen menjëherë të pavlefshme. Ky është një rrezik që duhet pranuar përgjegjësisht (ose të shmanget dhe pastaj të paguani për rafte të dukshëm të pavolitura).
Një vërejtje e rëndësishme - është e nevojshme të përpiqemi të shpërndajmë serverët nga shërbime të ndryshme horizontalisht në rafte, nëse është e mundur. Kjo është e nevojshme për të shmangur situatat kur një grup serverësh për një shërbim vjen, rafte ngushtohet verticalisht me të, për të rritur "dendësinë" (sepse është më e lehtë). Në praktikë, ndodhi që një raft u mbush me serverë të ngarkuar të ulët të një shërbimi, ndërsa një tjetër me të ngarkuar të lartë. Probabiliteti i rënies së serverëve të dytë është shumë më i lartë, sepse profili i ngarkesës është i njëjtë, dhe të gjithë serverët së bashku në këtë raft fillojnë të konsumojnë të njëjtin nivel të lartë për shkak të rritjes së ngarkesës.
Le të kthehemi te shpërndarja e serverëve në rafte. Ne shqyrtuam kufizimet fizike për hapësirë në raft dhe kufizimet për energji elektrike, tani le të shikojmë edhe në rrjet. Mund të përdorim switch-e me 24/32/48 porte N (për shembull, kemi switch-e ToR 48-portesh). Fatmirësisht, opsionet nuk janë shumë, nëse nuk mendojmë për kabllo break-out. Po shqyrtojmë skenarët kur kemi një switch në raft, një switch për dy ose tri rafte në grupin Rnet. Mendoj se më shumë se tre rafte në grup është tepër, sepse problemi i kabllove mes rafteve bëhet shumë më i madh.
Pra, për çdo skenar rrjeti (1, 2 ose 3 rafte në grup) do të shpërndajmë serverët në rafte:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Kështu, për variantin me 2 rafte në grup:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serverë në raft.
Njësoj llogarisim për variantet e tjera:
Srack1 = 20
Srack3 = 16
Dhe ne jemi pothuajse në objektiv. Le të llogarisim numrin e rafteve për shpërndarjen e të gjithë serverëve tanë S (le të jetë 1000):
R = roundup(S /(Srack * Rnet)) * Rnet
R1 = roundup(1000 /(20 * 1)) * 1 = 50 * 1 = 50 rafte
R2 = roundup(1000 /(20 * 2)) * 2 = 25 * 2 = 50 rafte
R3 = roundup(1000 /(16 * 3)) * 3 = 25 * 2 = 63 rafte
Pastaj llogarisim TCO për çdo variant mbi bazën e numrit të rafteve, numrit të nevojshëm të switch-eve, kabllove, etj. Zgjidhim atë variant ku TCO është më i vogël. Profit!
Vëreni se megjithëse numri i nevojshëm i rafteve për variantet 1 dhe 2 është i njëjtë, çmimi i tyre do të jetë ndryshe, sepse numri i switch-eve për variantin e dytë është dyfish më i vogël, ndërsa gjatësia e kabllove të nevojshme është më e madhe.
P.S. Nëse ka mundësi të luajmë me fuqinë në raft dhe lartësinë e raftit, variabiliteti rritet. Por procesi mund të reduktohet në atë që përshkruhet më sipër, duke provuar variantet. Po, do të ketë më shumë kombime, por akoma një numër shumë të kufizuar - energjia në raft për llogaritje mund të rritet në hapa prej 1 kW, rafte tipike janë me një numër të kufizuar dimensionesh: 42U, 45U, 47U, 48U, 52U. Dhe këtu llogaritja mund të ndihmojë analiza What-If në Excel në modalitetin e Data Table. Shikoni tabelat e marra dhe zgjidhni minimumin.
Burimi: habr.com
