Çatların birində mənə belə bir sual verildi:
— Serverləri rəflərə necə düzgün yığmaq barədə oxuya biləcəyim bir şey varmı?
Belə bir mətni bilmədiyimi başa düşdüm və özümü yazdım.
Birincisi, bu mətn fiziki məlumat mərkəzlərindəki (DC) fiziki serverlər haqqındadır. İkincisi, biz hesab edirik ki, kifayət qədər çox server var: yüzlərlə-minlərlə; daha az sayda bu mətnin mənası yoxdur. Üçüncüsü, biz hesab edirik ki, bizim üç məhdudiyyətimiz var: rəflərdə fiziki boşluq, hər rack üçün enerji təchizatı və rəflərin cərgələrdə dayanmasına icazə verin ki, bitişik raflarda serverləri birləşdirmək üçün bir ToR keçidindən istifadə edək.
Sualın cavabı hansı parametri optimallaşdırdığımızdan və ən yaxşı nəticə əldə etmək üçün nəyi dəyişə biləcəyimizdən çox asılıdır. Məsələn, daha çox böyümə üçün daha çox yer buraxmaq üçün sadəcə minimum yer tutmalıyıq. Və ya bəlkə də rafların hündürlüyünü, hər rəf üçün gücü, PDU-dakı rozetkaları, bir qrup açardakı rəflərin sayını (1, 2 və ya 3 rəf üçün bir açar), naqillərin uzunluğunu və çəkmə işini seçməkdə azadlığımız var ( bu, cərgələrin uclarında vacibdir: cərgədə 10 rəf və hər keçiddə 3 rəf ilə siz naqilləri başqa cərgəyə çəkməli və ya keçiddəki portlardan az istifadə etməli olacaqsınız) və s. Ayrı-ayrı hekayələr: serverlərin seçilməsi və DC-lərin seçilməsi, onların seçildiyini güman edəcəyik.
Bəzi nüansları və detalları, xüsusən də serverlərin orta/maksimum istehlakını və elektrik enerjisinin bizə necə verildiyini başa düşmək yaxşı olardı. Beləliklə, əgər bizdə 230V gücündə bir Rusiya enerji təchizatı və hər rack üçün bir faza varsa, o zaman 32A maşın ~ 7kW gücündə ola bilər. Deyək ki, biz nominal olaraq rack üçün 6 kVt ödəyirik. Əgər provayder istehlakımızı hər bir rəf üçün deyil, yalnız 10 rəf üçün ölçürsə və maşın şərti olaraq 7 kVt kəsmə nöqtəsinə qoyulursa, texniki olaraq bir rəfdə 6.9 kVt, digərində 5.1 kVt istehlak edə bilərik və hər şey yaxşı olacaq - cəzalandırılmayacaq.
Adətən bizim əsas məqsədimiz xərcləri minimuma endirməkdir. Ölçmək üçün ən yaxşı meyar TCO-nun azaldılmasıdır (mülkiyyətin ümumi dəyəri). Aşağıdakı hissələrdən ibarətdir:
- CAPEX: DC infrastrukturunun, serverlərin, şəbəkə avadanlıqlarının və kabellərin alınması
- OPEX: DC icarəsi, elektrik istehlakı, texniki xidmət. OPEX xidmət müddətindən asılıdır. Bunun 3 il olduğunu düşünmək ağlabatandır.
Ayrı-ayrı parçaların ümumi tortda nə qədər böyük olmasından asılı olaraq, biz ən bahalısını optimallaşdırmalıyıq, qalanlarına isə qalan bütün resurslardan mümkün qədər səmərəli istifadə etməsinə icazə verməliyik.
Tutaq ki, bizdə mövcud DC var, H vahidlərinin rack hündürlüyü var (məsələn, H=47), rack üzrə elektrik enerjisi Prack (Prack=6kW) və biz h=2U iki vahidli serverlərdən istifadə etmək qərarına gəldik. Biz açarlar, patç panellər və təşkilatçılar üçün rafdan 2..4 ədəd çıxaracağıq. Bunlar. fiziki olaraq bizim rafımızda Sh=rounddown((H-2..4)/h) serverlərimiz var (yəni Sh = rounddown((47-4)/2)=hər rack üçün 21 server). Gəlin bu Ş.
Sadə halda, rafdakı bütün serverlər eynidir. Ümumilikdə, bir rəfi serverlərlə doldursaq, onda hər bir serverdə orta hesabla güc sərf edə bilərik Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Sadəlik üçün burada keçid istehlakına məhəl qoymuruq.
Bir addım kənara ataq və maksimum server istehlakının Pmax nə olduğunu müəyyən edək. Çox sadə, çox təsirsiz və tamamilə təhlükəsizdirsə, serverin enerji təchizatında yazılanları oxuyuruq - budur.
Daha mürəkkəb, daha səmərəlidirsə, bütün komponentlərin TDP-ni (termal dizayn paketi) götürürük və ümumiləşdiririk (bu çox doğru deyil, lakin mümkündür).
Adətən biz komponentlərin TDP-ni bilmirik (CPU istisna olmaqla), buna görə də ən düzgün, eyni zamanda ən mürəkkəb yanaşmanı (laboratoriyaya ehtiyacımız var) götürürük - lazımi konfiqurasiyanın eksperimental serverini götürürük və onu yükləyirik, məsələn, Linpack (CPU və yaddaş) və fio (disklər) ilə istehlakı ölçürük. Əgər bunu ciddi qəbul etsək, testlər zamanı soyuq dəhlizdə də ən isti mühiti yaratmalıyıq, çünki bu, həm fan istehlakına, həm də CPU istehlakına təsir edəcək. Bu xüsusi yük altında bu xüsusi şərtlərdə xüsusi konfiqurasiyaya malik xüsusi serverin maksimum istehlakını əldə edirik. Sadəcə demək istəyirik ki, yeni sistem proqram təminatı, fərqli proqram versiyası və digər şərtlər nəticəyə təsir edə bilər.
Beləliklə, Pservə qayıdın və onu Pmax ilə necə müqayisə edirik. Bu, xidmətlərin necə işlədiyini və texniki direktorunuzun əsəblərinin nə qədər güclü olduğunu başa düşmək məsələsidir.
Əgər heç bir risk etməsək, inanırıq ki, bütün serverlər eyni vaxtda maksimumunu istehlak etməyə başlaya bilər. Eyni zamanda DC-yə bir giriş baş verə bilər. Hətta bu şərtlər altında infra xidmət göstərməlidir, ona görə də Pserv ≡ Pmax. Bu, etibarlılığın tamamilə vacib olduğu bir yanaşmadır.
Əgər texnoloji direktor təkcə ideal təhlükəsizlik haqqında deyil, həm də şirkətin pulu haqqında düşünürsə və kifayət qədər cəsarətlidirsə, onda siz qərar verə bilərsiniz ki,
- Biz təchizatçılarımızı idarə etməyə başlayırıq, xüsusən, bir girişdə azalmanı minimuma endirmək üçün planlaşdırılan pik yükün olduğu vaxtlarda planlı təmiri qadağan edirik;
- və/yaxud arxitekturamız sizə rack/sətir/DC itirməyə imkan verir, lakin xidmətlər işləməyə davam edir;
- və/yaxud biz yükü rəflər arasında üfüqi şəkildə yaxşı yayırıq, buna görə də xidmətlərimiz heç vaxt birlikdə bir stendə maksimum istehlak səviyyəsinə yüksəlməyəcək.
Burada sadəcə təxmin etmək deyil, istehlakı izləmək və serverlərin normal və pik şəraitdə həqiqətən elektrik enerjisini necə istehlak etdiyini bilmək çox faydalıdır. Buna görə də, bəzi təhlillərdən sonra texnoloji direktor əlində olan hər şeyi sıxır və deyir: "Biz könüllü qərar veririk ki, bir rack üçün maksimum server istehlakının əldə edilə bilən maksimum ortalaması maksimum istehlakdan **o qədər** aşağıdır" şərti olaraq Pserv = 0.8* Pmax.
Və sonra 6 kVt rack artıq Pmax = 16W olan 375 serveri deyil, Pserv = 20W * 375 = 0.8W olan 300 serveri yerləşdirə bilər. Bunlar. 25% daha çox server. Bu, çox böyük qənaətdir - axırda bizə dərhal 25% daha az raf lazımdır (və PDU-lara, açarlara və kabellərə də qənaət edəcəyik). Belə bir həllin ciddi dezavantajı, fərziyyələrimizin hələ də doğru olduğuna daim nəzarət etməliyik. Yeni proqram təminatının fanatların işini və istehlakını əhəmiyyətli dərəcədə dəyişdirməməsi, yeni buraxılışla birdən-birə inkişafın serverlərdən daha səmərəli istifadə etməyə başlamaması (oxu: onlar serverdə daha çox yük və daha çox istehlak əldə etdilər). Axı, o zaman həm ilkin fərziyyələrimiz, həm də nəticələrimiz dərhal yanlış olur. Bu, məsuliyyətlə qəbul edilməli olan bir riskdir (yaxud qarşısını almaq və sonra açıq-aydın istifadə olunmayan raflar üçün ödəniş etmək).
Əhəmiyyətli bir qeyd - mümkünsə, müxtəlif xidmətlərdən serverləri raflar arasında üfüqi şəkildə yaymağa çalışmalısınız. Bu, bir xidmət üçün serverlərin bir dəstəsi gəldiyi zaman vəziyyətlərin baş verməməsi üçün lazımdır, "sıxlığı" artırmaq üçün raflar şaquli şəkildə doludur (çünki bu daha asandır). Reallıqda belə çıxır ki, bir raf eyni xidmətin eyni aşağı yüklü serverləri ilə, digəri isə eyni dərəcədə yüksək yüklü serverlərlə doludur. İkinci düşmə ehtimalı əhəmiyyətli dərəcədə yüksəkdir, çünki yük profili eynidir və bu rafdakı bütün serverlər artan yük nəticəsində eyni miqdarda istehlak etməyə başlayır.
Qayıdaq serverlərin raflarda paylanmasına. Fiziki raf sahəsinə və güc məhdudiyyətlərinə baxdıq, indi şəbəkəyə baxaq. Siz 24/32/48 N portlu açarlardan istifadə edə bilərsiniz (məsələn, bizdə 48 portlu ToR açarları var). Xoşbəxtlikdən, sökülən kabellər haqqında düşünməsəniz, çoxlu seçim yoxdur. Rnet qrupunda hər rack üçün bir keçid, iki və ya üç rəf üçün bir keçid olduqda ssenariləri nəzərdən keçiririk. Mənə elə gəlir ki, bir qrupda üçdən çox rəf artıq çoxdur, çünki... raflar arasında kabel problemi daha böyük olur.
Beləliklə, hər bir şəbəkə ssenarisi üçün (bir qrupda 1, 2 və ya 3 rəf) serverləri raflar arasında paylayırıq:
Srack = min(Sh, yuvarlaqlaşdırma(Prack/Pserv), yuvarlaqlaşdırma(N/Rnet))
Beləliklə, bir qrupda 2 raflı seçim üçün:
Srack2 = min(21, yuvarlaqlaşdırma(6000/300), yuvarlaqlaşdırma(48/2)) = min(21, 20, 24) = hər rack üçün 20 server.
Qalan variantları eyni şəkildə nəzərdən keçiririk:
Srack1 = 20
Srack3 = 16
Və demək olar ki, oradayıq. Bütün S serverlərimizi yaymaq üçün rafların sayını hesablayırıq (1000 olsun):
R = ümumiləşdirmə (S / (Srack * Rnet)) * Rnet
R1 = ümumiləşdirmə (1000 / (20 * 1)) * 1 = 50 * 1 = 50 raf
R2 = ümumiləşdirmə (1000 / (20 * 2)) * 2 = 25 * 2 = 50 raf
R3 = ümumiləşdirmə (1000 / (16 * 3)) * 3 = 25 * 2 = 63 raf
Sonra, hər bir seçim üçün TCO-nu rafların sayına, lazımi sayda açarlara, kabellərə və s. TCO-nun aşağı olduğu variantı seçirik. Mənfəət!
Qeyd edək ki, 1 və 2-ci variantlar üçün tələb olunan rəflərin sayı eyni olsa da, onların qiyməti fərqli olacaq, çünki ikinci seçim üçün açarların sayı yarıya qədərdir və tələb olunan kabellərin uzunluğu daha uzundur.
P.S. Hər rəfdə güc və rəfin hündürlüyü ilə oynamaq imkanınız varsa, dəyişkənlik artır. Ancaq sadəcə variantları nəzərdən keçirməklə prosesi yuxarıda təsvir edilənə endirmək olar. Bəli, daha çox birləşmələr olacaq, lakin hələ də çox məhdud sayda - hesablama üçün rafa enerji təchizatı 1 kVt addımlarla artırıla bilər, tipik raflar məhdud sayda standart ölçülərdə gəlir: 42U, 45U, 47U, 48U , 52U. Və burada Excel-in Məlumat Cədvəli rejimində What-If təhlili hesablamalarda kömək edə bilər. Alınan plitələrə baxırıq və minimumu seçirik.
Mənbə: www.habr.com