Chatlardan birida menga savol berildi:
β Serverlarni javonlarga qanday qilib to'g'ri joylashtirish haqida o'qishim mumkin bo'lgan biror narsa bormi?
Men bunday matnni bilmasligimni angladim, shuning uchun men o'zim yozdim.
Birinchidan, bu matn jismoniy ma'lumotlar markazlaridagi (DC) jismoniy serverlar haqida. Ikkinchidan, biz serverlar juda ko'p ekanligiga ishonamiz: yuzlab-minglab; kichikroq raqam uchun bu matn mantiqiy emas. Uchinchidan, bizda uchta cheklov bor deb hisoblaymiz: stendlarda jismoniy bo'sh joy, har bir rafga quvvat manbai va qo'shni tokchalardagi serverlarni ulash uchun bitta ToR kommutatoridan foydalanishimiz uchun raftlar qatorda turishiga ruxsat bering.
Savolga javob biz qaysi parametrni optimallashtirganimizga va eng yaxshi natijaga erishish uchun nimani o'zgartirishimiz mumkinligiga bog'liq. Masalan, keyingi o'sish uchun ko'proq joy qoldirish uchun biz minimal joy egallashimiz kerak. Yoki biz raflarning balandligini, har bir raf uchun quvvatni, PDUdagi rozetkalarni, kalitlar guruhidagi raftlar sonini (1, 2 yoki 3 ta raf uchun bitta kalit), simlar uzunligini va tortish ishlarini tanlashda erkinlikka egamiz. bu qatorlarning oxirida juda muhim: ketma-ket 10 ta raf va har bir kalitda 3 ta raf bilan siz simlarni boshqa qatorga tortishingiz yoki kalitdagi portlarni kam ishlatishingiz kerak) va hokazo. Alohida hikoyalar: serverlarni tanlash va DC ni tanlash, biz ular tanlangan deb hisoblaymiz.
Ba'zi nuances va tafsilotlarni, xususan, serverlarning o'rtacha/maksimal iste'molini va bizga elektr energiyasini qanday etkazib berishni tushunish yaxshi bo'lar edi. Shunday qilib, agar bizda 230V rusumli quvvat manbai va har bir raf uchun bir faza bo'lsa, u holda 32A mashinasi ~ 7 kVt quvvatga ega. Aytaylik, biz har bir raf uchun nominal 6 kVt uchun to'laymiz. Agar provayder bizning iste'molimizni har bir raf uchun emas, balki faqat 10 ta raf uchun o'lchasa va agar mashina shartli ravishda 7 kVt quvvatga ega bo'lsa, texnik jihatdan biz bitta rafda 6.9 kVt, boshqasida 5.1 kVt iste'mol qilishimiz mumkin. hammasi yaxshi bo'ladi - jazolanmaydi.
Odatda bizning asosiy maqsadimiz xarajatlarni minimallashtirishdir. O'lchash uchun eng yaxshi mezon - bu TCO ning qisqarishi (egalikning umumiy qiymati). U quyidagi qismlardan iborat:
- CAPEX: DC infratuzilmasi, serverlar, tarmoq uskunalari va kabellarni sotib olish
- OPEX: DC ijarasi, elektr energiyasini iste'mol qilish, texnik xizmat ko'rsatish. OPEX xizmat muddatiga bog'liq. Buni 3 yil deb hisoblash o'rinli.
Alohida bo'laklarning umumiy pirogda qanchalik kattaligiga qarab, biz eng qimmatini optimallashtirishimiz kerak, qolganlari esa qolgan barcha resurslardan iloji boricha samarali foydalanishlariga imkon berishimiz kerak.
Aytaylik, bizda mavjud DC bor, H birliklarining raf balandligi (masalan, H=47), har bir rack uchun elektr quvvati Prack (Prack=6kVt) va biz h=2U ikki birlikli serverlardan foydalanishga qaror qildik. Kalitlar, patch panellar va organizatorlar uchun rafdan 2..4 birlikni olib tashlaymiz. Bular. jismonan, bizning rafimizda Sh=rounddown((H-2..4)/h) serverlar mavjud (yaΚΌni Sh = rounddown((47-4)/2)=har bir rafga 21 server). Keling, ushbu Sh.
Oddiy holatda, rafdagi barcha serverlar bir xil. Umuman olganda, agar biz rafni serverlar bilan to'ldirsak, har bir serverda o'rtacha Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) quvvat sarflashimiz mumkin. Oddiylik uchun biz bu erda kalit sarfini e'tiborsiz qoldiramiz.
Keling, bir qadam chetga olib, Pmax maksimal server iste'moli nima ekanligini aniqlaymiz. Agar bu juda oddiy, juda samarasiz va mutlaqo xavfsiz bo'lsa, biz serverning quvvat manbaida nima yozilganligini o'qiymiz - bu shunday.
Agar u yanada murakkab va samaraliroq bo'lsa, unda biz barcha komponentlarning TDP (issiqlik dizayn paketi) ni olamiz va uni umumlashtiramiz (bu juda to'g'ri emas, lekin bu mumkin).
Odatda biz komponentlarning TDP ni bilmaymiz (protsessordan tashqari), shuning uchun biz eng to'g'ri, ammo eng murakkab yondashuvni qabul qilamiz (bizga laboratoriya kerak) - biz kerakli konfiguratsiyaning eksperimental serverini olamiz va uni yuklaymiz, masalan, Linpack (CPU va xotira) va fio (disklar) bilan biz iste'molni o'lchaymiz. Agar biz buni jiddiy qabul qilsak, sinovlar vaqtida sovuq koridorda ham eng issiq muhitni yaratishimiz kerak, chunki bu ham fan iste'moliga, ham CPU iste'moliga ta'sir qiladi. Biz ushbu o'ziga xos yuk ostida ushbu o'ziga xos sharoitlarda ma'lum bir konfiguratsiyaga ega ma'lum bir serverning maksimal iste'molini olamiz. Biz shunchaki yangi tizim proshivkasi, boshqa dasturiy ta'minot versiyasi va boshqa shartlar natijaga ta'sir qilishi mumkinligini nazarda tutamiz.
Shunday qilib, Pservga qayting va uni Pmax bilan qanday taqqoslaymiz. Bu xizmatlar qanday ishlashini va texnik direktoringizning asablari qanchalik kuchli ekanligini tushunish masalasi.
Agar biz hech qanday tavakkal qilmasak, barcha serverlar bir vaqtning o'zida maksimal darajada iste'mol qila boshlashiga ishonamiz. Shu bilan birga, DC ga bitta kirish sodir bo'lishi mumkin. Bunday sharoitlarda ham infra xizmat ko'rsatishi kerak, shuning uchun Pserv β‘ Pmax. Bu ishonchlilik juda muhim bo'lgan yondashuv.
Agar texnologiya direktori nafaqat ideal xavfsizlik, balki kompaniyaning puli haqida ham o'ylasa va etarlicha jasur bo'lsa, unda siz shunday qaror qabul qilishingiz mumkin.
- Biz sotuvchilarimizni boshqarishni boshlaymiz, xususan, biz bitta kirishda pasayishni minimallashtirish uchun rejalashtirilgan eng yuqori yuk vaqtida rejalashtirilgan texnik xizmat ko'rsatishni taqiqlaymiz;
- va/yoki bizning arxitekturamiz sizga raf/qator/DCni yo'qotish imkonini beradi, lekin xizmatlar ishlashda davom etadi;
- va/yoki biz yukni tokchalar bo'ylab yaxshi gorizontal ravishda yoyamiz, shuning uchun bizning xizmatlarimiz hech qachon bir javonda maksimal iste'molga o'tmaydi.
Bu erda shunchaki taxmin qilish emas, balki iste'molni kuzatish va serverlar normal va eng yuqori sharoitlarda elektr energiyasini qanday iste'mol qilishini bilish juda foydali. Shuning uchun, ba'zi tahlillardan so'ng, texnik direktor o'zida mavjud bo'lgan hamma narsani siqib chiqaradi va shunday deydi: "biz ixtiyoriy qaror qabul qilamizki, har bir raf uchun maksimal server iste'molining maksimal erishiladigan o'rtacha qiymati maksimal iste'moldan **shunchalik ** past bo'ladi", shartli ravishda Pserv = 0.8* Pmax.
Va keyin 6 kVt quvvatli raf endi Pmax = 16 Vt bo'lgan 375 ta serverni sig'dira olmaydi, lekin Pserv = 20 Vt * 375 = 0.8 Vt bo'lgan 300 serverni sig'dira olmaydi. Bular. 25% ko'proq serverlar. Bu juda katta tejamkorlik - axir, bizga zudlik bilan 25% kamroq tokchalar kerak (va biz PDU, kalit va kabellarni ham tejaymiz). Bunday yechimning jiddiy kamchiligi shundaki, biz doimo bizning taxminlarimiz hali ham to'g'ri ekanligini kuzatishimiz kerak. Yangi proshivka versiyasi muxlislarning ishlashini va iste'molini sezilarli darajada o'zgartirmasligi, yangi versiya bilan to'satdan ishlab chiqish serverlardan unchalik samarali foydalanishni boshlamaganligi (o'qing: ular serverda katta yuk va ko'proq iste'molga erishdilar). Axir, bizning dastlabki taxminlarimiz ham, xulosalarimiz ham darhol noto'g'ri bo'ladi. Bu mas'uliyat bilan qabul qilinishi kerak bo'lgan xavf (yoki oldini olish va keyin aniq ishlatilmagan raflar uchun to'lash).
Muhim eslatma - iloji bo'lsa, turli xil xizmatlarning serverlarini gorizontal ravishda raflar bo'ylab taqsimlashga harakat qilishingiz kerak. Bu bitta xizmat uchun serverlarning bir partiyasi kelganda vaziyatlar yuzaga kelmasligi uchun kerak, "zichlik" ni oshirish uchun raflar vertikal ravishda o'rnatiladi (chunki bu osonroq). Haqiqatda ma'lum bo'lishicha, bitta stend bir xil xizmatning bir xil kam yuklangan serverlari bilan, ikkinchisi esa bir xil darajada yuqori yuklangan serverlar bilan to'ldirilgan. Ikkinchi tushish ehtimoli sezilarli darajada yuqori, chunki yuklash profili bir xil bo'ladi va ushbu rafdagi barcha serverlar yuk ortishi natijasida bir xil miqdorda iste'mol qila boshlaydi.
Keling, serverlarni raflarda taqsimlashga qaytaylik. Biz jismoniy raf maydoni va quvvat cheklovlarini ko'rib chiqdik, endi tarmoqni ko'rib chiqaylik. Siz 24/32/48 N portli kalitlardan foydalanishingiz mumkin (masalan, bizda 48 portli ToR kalitlari mavjud). Yaxshiyamki, agar siz uzilish kabellari haqida o'ylamasangiz, ko'p variantlar mavjud emas. Biz stsenariylarni ko'rib chiqmoqdamiz, agar bizda Rnet guruhida bitta rafga bitta kalit, ikkita yoki uchta raf uchun bitta kalit mavjud. Menimcha, bir guruhda uchtadan ortiq raf allaqachon juda ko'p, chunki ... raflar orasidagi kabel muammosi ancha katta bo'ladi.
Shunday qilib, har bir tarmoq stsenariysi uchun (guruhdagi 1, 2 yoki 3 ta raf) biz serverlarni raflar o'rtasida taqsimlaymiz:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Shunday qilib, guruhdagi 2 ta rafli variant uchun:
Srack2 = min (21, yaxlitlash (6000/300), yaxlitlash (48/2)) = min (21, 20, 24) = har bir rafga 20 ta server.
Qolgan variantlarni xuddi shu tarzda ko'rib chiqamiz:
Srack1 = 20
Srack3 = 16
Va biz deyarli u erdamiz. Biz barcha S serverlarimizni tarqatish uchun raftlar sonini hisoblaymiz (u 1000 bo'lsin):
R = yaxlitlash (S / (Srack * Rnet)) * Rnet
R1 = yaxlitlash (1000 / (20 * 1)) * 1 = 50 * 1 = 50 ta raf
R2 = yaxlitlash (1000 / (20 * 2)) * 2 = 25 * 2 = 50 ta raf
R3 = yaxlitlash (1000 / (16 * 3)) * 3 = 25 * 2 = 63 ta raf
Keyinchalik, biz har bir variant uchun TCO ni tokchalar soni, kerakli kalitlar soni, kabellar va boshqalar asosida hisoblaymiz. TCO pastroq bo'lgan variantni tanlaymiz. Foyda!
E'tibor bering, 1 va 2-variantlar uchun talab qilinadigan tokchalar soni bir xil bo'lsa-da, ularning narxi boshqacha bo'ladi, chunki ikkinchi variant uchun kalitlarning soni ikki baravar ko'p, zarur kabellarning uzunligi esa uzunroq.
P.S. Agar sizda raftaning quvvati va balandligi bilan o'ynash imkoningiz bo'lsa, o'zgaruvchanlik ortadi. Ammo jarayonni faqat variantlardan o'tish orqali yuqorida tavsiflanganga qisqartirish mumkin. Ha, ko'proq kombinatsiyalar bo'ladi, lekin hali ham juda cheklangan raqam - hisoblash uchun rafga quvvat manbai 1 kVt ga ko'paytirilishi mumkin, odatiy raftlar cheklangan miqdordagi standart o'lchamlarda keladi: 42U, 45U, 47U, 48U , 52U. Va bu erda Excelning "Ma'lumotlar jadvali" rejimida "What-If" tahlili hisob-kitoblarda yordam berishi mumkin. Qabul qilingan plitalarga qaraymiz va minimalni tanlaymiz.
Manba: www.habr.com