Mənə bir chatda belə sual verdilər:
— Şkaflara serverlərin düzgün şəkildə necə yerləşdiriləcəyi ilə bağlı oxumaq üçün bir şey varmı?
Başa düşdüm ki, belə bir mətn bilmirəm, buna görə özümü yazdım.
Birincisi, bu mətndə fiziki serverlər fiziki data mərkəzlərində (DM). İkincisi, güman edək ki, serverlərin sayı kifayət qədərdir: yüzlərlə-minlərlə, daha az sayda bu mətnin heç bir mənası yoxdur. Üçüncüsü, üç məhdudiyyətimiz olduğunu düşünək: şkaflarda fiziki yer, şkaf üçün enerji təminatı və şkafların sırayla yerləşməsi, buna görə yan şkaflardakı serverləri bağlamaq üçün bir ToR switchdən istifadə edə bilərik.
Sualın cavabı çox asılıdır, hansı parametri optimallaşdırdığımız və ən yaxşı nəticəyə nail olmaq üçün nələri dəyişə biləcəyimizdən. Məsələn, minimum yer tutmaq istəyirik ki, daha çox inkişaf üçün yer qalsın. Bəlkə də, şkafların hündürlüyü, şkaf başına güc, PDU-da priz, switchlər qrupu üçün şkafların sayı (bir switch 1, 2 və ya 3 şkaf üçün) seçimində azadlığımız var, kabellərin uzunluğu və çekmə işləri (bu, sıranın sonlarında kritikdir: 10 şkafı olan sırada və 3 şkaf olan switch üçün kabelləri başqa sıraya çəkməli olacağıq ya da switchdəki portlardan tam istifadə edilməyəcək) və s., s. ayrıca serverlərin seçimi və DM seçimi kimi ayrı hekayələr var, hamısını güman edək ki, seçilmişdir.
Bəzi nüansları və detalların başa düşülməsi yaxşı olardı, xüsusilə serverlərin orta / maksimum istehlakını və elektrik təminatını necə aldığımızı. Belə ki, əgər bizim Rusiya elektrikimiz 230V və bir faza şkaf başına varsa, o zaman 32A avtomat ~7kW idarə edə bilər. Tutaq ki, nominal olaraq şkaf başına 6kW üçün ödəyirik. Əgər provayder istehlakımızı yalnız 10 şkafdan ibarət olan sıradan ölçürsə, hər bir şkaf üçün yox və əgər avtomat şərti olaraq 7kW-da dayanırsa, texniki olaraq, ayrı bir şkafda 6.9kW, başqa birində 5.1kW istehlak edə bilərik və hər şey yaxşı olacaq — cəzalandırılmayacaq.
Adətən, əsas məqsədimiz xərclərin minimuma endirilməsidir. Ölçmə üçün ən yaxşı meyar TCO (total cost of ownership — cəmi mülkiyyət xərci) azalmasıdır. Bu, aşağıdakı hissələrdən ibarətdir:
- CAPEX: DM-in, serverlərin, şəbəkə cihazlarının və kabelləşmənin satın alınması
- OPEX: DM icarəsi, istehlak olunan elektrik, xidmət. OPEX, xidmət müddətindən asılıdır. Bu müddətin 3 il olduğunu düşünmək məntiqlidir.
Hissələrin ümumi tortda nə qədər böyük olduğuna görə, ən bahalı olanı optimallaşdırmalıyıq, digərlərini isə bütün qalan resursları mümkün qədər səmərəli istifadə etməyə icazə verməliyik.
Farz edək ki, artıq mövcud bir Mərkəzi Məlumat (DC) var, şkafın layihəsi üçün hündürlük H (nümunə üçün H=47), şkafa elektrik P_rack (P_rack=6 kVt) var, və biz 2U iki yunitli serverlərdən istifadə etməyə qərar veririk. 2..4 yunitini şkafdakı switchlər, patch panelləri və təşkilatçılar üçün çıxardırıq. Yəni, fiziki olaraq, şkafda Sh=rounddown((H-2..4)/h) server yerləşir (yəni Sh = rounddown((47-4)/2)=21 server şkafa). Bunu unutmayaq.
Sadə halda, şkafdakı bütün serverlər eynidir. Beləliklə, əgər şkafı doldursaq, serverlər ilə işləmək mümkündür, hər bir server üçün ortalama güc sərfiyyatı P_serv=P_rack/Sh (P_serv = 6000 Vt/21 = 287 Vt) ayıracaq. Sadəlik naminə burada switchin istehlakını göz ardı edirik.
Bir addım geri atalım və serverin maksimum istehlakını P_max necə müəyyən edəcəyimizi seçək. Çox sadə desək, çox səmərəsiz və tam təhlükəsiz olsa da, serverin enerji blokunda yazılanlara baxmalıyıq — bu, odur.
Daha mürəkkəb, daha səmərəli olması halında, bütün komponentlərin TDP-sini (thermal design package) toplayırıq (bu, tam dəqiq deyil, amma belə də etmək mümkündür).
Adətən komponentlərin TDP-sini (CPU xaric) bilmirik, buna görə də ən doğru, amma ən çətin yanaşmanı alırıq (laboratoriya lazımdır) — müvafiq konfiqurasiyalı eksperimental server götürürük və onu Linpack (CPU və yaddaş) və fio (disklər) ilə yükləyirik, istehlakını ölçürük. Ciddi yanaşmaq istəyiriksə, testlər zamanı soyuq dəhlizdə ən isti mühit yaratmalıyıq, çünki bu, ventilyatorların və CPU-nun istehlakına təsir edir. Müəyyən şərtlərdə və bu konkret yük altında konkret konfiqurasiyalı serverin maksimal istehlakını əldə edirik. Yalnız unutmayaq ki, yeni proqram təminatının, proqram versiyalarının, fərqli şərtlərin nəticəyə təsiri ola bilər.
Beləliklə, P_serv və onu P_max ilə necə müqayisə edəcəyimizi düşünürük. Bu, xidmətlərin işləmə prinsiplərini və texniki rəhbərinizin nə qədər dözümlü olduğunu anlamaqla bağlı bir məsələdir.
Tamamilə risk etməyin, bütün serverlərin eyni anda maksimum istehlak etməyə başlayacağını hesab edək. Eyni zamanda DC-yə bir girişin yarana biləcəyi mümkündür. İnfrastruktur və bu şərtlərdə xidmət təmin etməlidir, buna görə də P_serv ≡ P_max. Bu yanaşma, tamamilə etibarlılığın vacib olduğu bir yanaşmadır.
Ancaq texniki rəhbər yalnız ideal təhlükəsizliyi düşünmürsə, həm də şirkətin maliyyəsi ilə maraqlıdırsa və kifayət qədər cəsarətlidirsə, belə bir qərar verə bilərik ki,
- biz provayderlərimizi idarə etməyə başlayırıq, xüsusilə planlaşdırılmış texniki xidmətləri gözlənilən pik yük anlarında həyata keçirməyi qadağan edirik ki, bir girişin azalmasını minimuma endirək;
- və ya/arxitektura şkafı/radı/DC-nin itməsinə icazə verən bir yanaşmamız var, xidmətlər isə işləməyə davam edir;
- və ya/yaxşı bir şəkildə yükü şkaflar arasında bərabər paylayırıq, buna görə də xidmətlərimiz heç vaxt eyni vaxtda bir şkafda maksimum istehlaka sıçrayacaq.
Burada, yalnızca tahmin yürütmekle kalmayıp, tüketimi izlemek ve sunucuların elektrik tüketimini normal ve pik koşullarında nasıl gerçekleştirdiğini bilmek çok faydalıdır. Bu nedenle, bir miktar analiz sonrasında, teknik müdür elinde olan her şeyi sıkıştırır ve der ki: "Elde edilebilecek maksimum ortalama, sunucuların maksimum tüketimlerinden **şu kadar** daha düşük olacaktır", kısaca Pserv=0.8*Pmax.
Bu durumda, 6 kW'lık bir rafta artık Pmax = 375 W olan 16 sunucu değil, Pserv = 375 W * 0.8 = 300 W olan 20 sunucu bulunur. Yani, daha fazla sunucu. Bu oldukça büyük bir tasarruf — zira o zaman rafta daha az olacak ve orada PDU, anahtarlar ve kablolar için de tasarruf sağlarız. Bu tür bir çözümün ciddi bir dezavantajı, sürekli olarak varsayımlarımızın hala geçerli olup olmadığını izlemektir. Yeni firmware sürümünün fanların ve tüketimin işleyişini önemli ölçüde değiştirmediğinden emin olmalıyız; geliştirme bir anda yeni sürümle sunucuları çok daha etkili kullanmaya başlamadığından (yükseklik ve tüketimi artırdığından) emin olmalıyız. O zaman, hem başlangıçtaki varsayımlarımız hem de sonuçlarımız hemen geçersiz hale gelir. Bu, sorumlu bir şekilde kabul edilmesi (ya da kaçınılması ve o zaman açıkça yeterince yüklenmemiş raflar için ödeme yapılması gereken) bir risktir.
Önemli bir not — sunucuları farklı hizmetlerden raflara yatay olarak dağıtmaya çalışmak önemlidir. Bu, aynı hizmete ait sunucuların bir partisi bir araya gelip raflara dikey olarak yerleştirildiğinde, "yoğunluğu" artırmak için (çünkü bu daha kolay) yaşanan sorunları önlemek içindir. Ancak gerçekte, bir rafta aynı düşük yüklenmeye sahip sunucular bulunurken, diğerinde aynı şekilde yüksek yüklenmeye sahip sunucular olacaktır. İkinci rafın düşme olasılığı çok daha yüksektir, çünkü yük profili aynıdır ve tüm sunucuların bu rafta birlikte yük artışına bağlı olarak eşit miktarda enerji tüketmeye başlaması söz konusudur.
Sunucuların raflardaki dağılımına geri dönelim. Rafta yerle ilgili fiziksel kısıtlamaları ve elektrik tüketimi kısıtlamalarını inceledik, şimdi de ağa bakalım. N (örneğin, 48 portlu ToR anahtarlar) üzerinde 24/32/48 portlu anahtarlar kullanmak mümkündür. Break-out kablolarını düşünmezsek, şansımıza pek fazla seçenek yok. Her raf için bir anahtar, bir grup Rnet içindeki iki veya üç raf için bir anahtar senaryolarını değerlendiriyoruz. Üçten fazla raf içeren bir grubun zaten aşırı olduğunu düşünüyorum, çünkü raflar arasındaki kablolama sorunu çok daha büyük bir hal alıyor.
Öyleyse, her ağ senaryosu için (grupta 1, 2 veya 3 raf) sunucuları raflara dağıtalım:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Böylece, grup içinde 2 raf senaryosu için:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 sunucu raf başına.
Eyn şəkildə digər variantları hesablayırıq:
Srack1 = 20
Srack3 = 16
Və biz demək olar ki, hədəfimizə çatırıq. Bütün serverlərimizin S (gəlin 1000 olsun) bölüşdürülməsi üçün metal qoruyucuların sayını hesablayırıq:
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 ədəd metal qoruyucu
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 ədəd metal qoruyucu
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 ədəd metal qoruyucu
Sonra hər bir variant üçün TCO-nu metal qoruyucu sayına, gərəkli switçlərin sayına, kabelləşdirməyə və s. əsaslanaraq hesablayırıq. TCO az olan variantı seçirik. Qazanc!
Qeyd edək ki, variant 1 və 2 üçün gərəkli metal qoruyucuların sayısı eynidir, lakin onların qiyməti fərqli olacaq, çünki ikinci variant üçün switçlərin sayı iki dəfə azdır, lakin tələb olunan kabellərin uzunluğu daha çoxdur.
P.S. Əgər metal qoruyucudakı gücü və metal qoruyucunun hündürlüyünü oynamaq imkanı varsa, seçimin imkanları artır. Amma prosesi yuxarıda təsvir olunanlara endirmək mümkündür, sadəcə variantları sınaqdan keçirərək. Bəli, kombinasiyalar bir qədər artacaq, amma yenə də olduqca məhdud sayda olacaq - metal qoruyucu üçün gücü hesablayarkən 1 kW artırmaq mümkündür, standart metal qoruyucular məhdud sayda ölçülərdə olur: 42U, 45U, 47U, 48U, 52U. Burada hesablamanı Excel-in
Mənbə: habr.com
