Нэг чат дээр надаас асуулт асуусан:
— Серверүүдийг тавиурт хэрхэн зөв савлах талаар уншиж чадах зүйл байна уу?
Би ийм бичвэр мэдэхгүй гэдгээ мэдээд өөрөө бичсэн.
Нэгдүгээрт, энэ текст нь физик өгөгдлийн төв (DC) дахь физик серверүүдийн тухай юм. Хоёрдугаарт, бид маш олон серверүүд байдаг гэдэгт бид итгэдэг: хэдэн зуун мянган; цөөн тооны хувьд энэ текст утгагүй юм. Гуравдугаарт, бид гурван хязгаарлалттай гэж үзэж байна: тавиур дахь физик зай, тавиур тус бүрийн цахилгаан хангамж, тавиуруудыг эгнээнд байрлуулж, зэргэлдээ тавиурууд дахь серверүүдийг холбохын тулд нэг ToR шилжүүлэгчийг ашиглах боломжтой.
Асуултын хариулт нь бид ямар параметрийг оновчтой болгож, хамгийн сайн үр дүнд хүрэхийн тулд юуг өөрчилж чадахаас ихээхэн хамаарна. Жишээлбэл, бид цаашдын өсөлтөд илүү ихийг үлдээхийн тулд хамгийн бага зай эзлэх хэрэгтэй. Эсвэл бид тавиурын өндөр, нэг тавиурын хүч, PDU дахь залгуур, бүлэг унтраалга дахь тавиурын тоо (1, 2 эсвэл 3 тавиурын нэг унтраалга), утаснуудын урт, татах ажлыг сонгох эрх чөлөөтэй байж магадгүй юм. Энэ нь эгнээний төгсгөлд чухал ач холбогдолтой: нэг эгнээнд 10 тавиур, шилжүүлэгч бүрт 3 тавиуртай бол та утсыг өөр эгнээ рүү татах эсвэл шилжүүлэгчийн портуудыг дутуу ашиглах хэрэгтэй болно) гэх мэт. Тусдаа түүхүүд: сервер сонгох ба DC-г сонгох, бид тэдгээрийг сонгосон гэж үзэх болно.
Зарим нэг нюанс, нарийн ширийн зүйлийг, тухайлбал серверүүдийн дундаж/хамгийн их хэрэглээ, цахилгаан эрчим хүчийг бидэнд хэрхэн нийлүүлж байгааг ойлгох нь зүйтэй болов уу. Тиймээс, хэрэв бид Оросын 230 В-ын цахилгаан хангамжтай, тавиур бүрт нэг фазтай бол 32А машин ~ 7 кВт-ыг тэсвэрлэх чадвартай. Бид тавиур бүрт 6 кВт-ын төлбөрийг нэрлэсэн гэж бодъё. Хэрэв үйлчилгээ үзүүлэгч нь бидний хэрэглээг тавиур тус бүрээр биш, зөвхөн 10 тавиурын эгнээнд хэмждэг бөгөөд хэрэв машиныг болзолт 7 кВт-ын хязгаарт тохируулсан бол техникийн хувьд бид нэг тавиур дээр 6.9 кВт, өөр тавиур дээр 5.1 кВт эрчим хүч хэрэглэж болно. Бүх зүйл сайхан болно - шийтгэл хүлээхгүй.
Ихэвчлэн бидний гол зорилго бол зардлыг багасгах явдал юм. Хэмжих хамгийн сайн шалгуур бол TCO (эзэмшлийн нийт өртөг)-ийн бууралт юм. Энэ нь дараах хэсгүүдээс бүрдэнэ.
- CAPEX: DC дэд бүтэц, сервер, сүлжээний техник хангамж, кабель худалдан авах
- OPEX: DC түрээс, цахилгааны хэрэглээ, засвар үйлчилгээ. OPEX нь үйлчилгээний хугацаанаас хамаарна. Үүнийг 3 жил гэж үзэх үндэслэлтэй.
Нийт бялуунд хэр том хэсгүүд байгаагаас хамааран бид хамгийн үнэтэйг нь оновчтой болгож, үлдсэн бүх нөөцийг аль болох үр ашигтай ашиглах боломжийг олгох хэрэгтэй.
Бидэнд одоо байгаа тогтмол гүйдэл байгаа гэж бодъё, тавиурын өндөр нь H нэгж (жишээ нь, H=47), rack тутамд цахилгаан эрчим хүч (Prack=6kW), бид h=2U хоёр нэгж сервер ашиглахаар шийдсэн. Бид унтраалга, засварын самбар, зохион байгуулагчийн тавиураас 2..4 нэгжийг салгана. Тэдгээр. физикийн хувьд, бидний өлгүүрт Sh=rounddown((H-2..4)/h) серверүүд байгаа (жишээ нь Sh = rounddown((47-4)/2)=21 сервер). Энэ Ш.Батхүүг санацгаая.
Энгийн тохиолдолд тавиур дээрх бүх серверүүд ижил байна. Нийтдээ, хэрэв бид тавиурыг серверээр дүүргэх юм бол сервер тус бүр дээр Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) хүчийг дунджаар зарцуулж болно. Энгийн байхын тулд бид энд шилжүүлэгчийн хэрэглээг үл тоомсорлодог.
Нэг алхмыг хойш тавиад серверийн хамгийн их хэрэглээ Pmax хэд болохыг тодорхойлъё. Хэрэв энэ нь маш энгийн, үр дүнгүй, бүрэн аюулгүй бол серверийн тэжээлийн хангамж дээр юу бичсэнийг уншина уу.
Хэрэв энэ нь илүү төвөгтэй, илүү үр дүнтэй бол бид бүх бүрэлдэхүүн хэсгүүдийн TDP (дулааны дизайны багц) -ийг авч, нэгтгэн дүгнэж болно (энэ нь тийм ч үнэн биш, гэхдээ боломжтой).
Бид ихэвчлэн бүрэлдэхүүн хэсгүүдийн TDP-ийг мэддэггүй (CPU-ээс бусад), тиймээс бид хамгийн зөв, гэхдээ бас хамгийн төвөгтэй хандлагыг (бидэнд лаборатори хэрэгтэй) ашигладаг - бид шаардлагатай тохиргооны туршилтын серверийг авч, ачаалдаг. жишээ нь, Linpack (CPU болон санах ой) болон fio (диск) ашиглан бид хэрэглээг хэмждэг. Хэрэв бид үүнийг нухацтай авч үзэх юм бол туршилтын үеэр хүйтэн коридорт хамгийн дулаан орчныг бүрдүүлэх хэрэгтэй, учир нь энэ нь сэнсний хэрэглээ болон CPU-ийн хэрэглээнд хоёуланд нь нөлөөлнө. Бид энэ ачааллын дор эдгээр тодорхой нөхцөлд тодорхой тохиргоотой тодорхой серверийн хамгийн их хэрэглээг авдаг. Бид зүгээр л системийн шинэ програм хангамж, өөр програм хангамжийн хувилбар болон бусад нөхцөл байдал үр дүнд нөлөөлж болзошгүй гэсэн үг юм.
Тиймээс, Pserv руу буцаж очоод бид үүнийг Pmax-тай хэрхэн харьцуулах вэ. Энэ нь үйлчилгээ хэрхэн ажилладаг, таны техникийн захирлын мэдрэл хэр хүчтэй болохыг ойлгох асуудал юм.
Хэрэв бид ямар ч эрсдэл хүлээхгүй бол бүх серверүүд нэгэн зэрэг хамгийн дээд хэмжээгээ ашиглаж эхэлнэ гэдэгт бид итгэдэг. Үүний зэрэгцээ DC-д нэг оролт гарч болзошгүй. Эдгээр нөхцөлд ч гэсэн infra нь үйлчилгээ үзүүлэх ёстой тул Pserv ≡ Pmax. Энэ бол найдвартай байдал туйлын чухал байдаг арга юм.
Технологийн захирал зөвхөн аюулгүй байдлын талаар төдийгүй компанийн мөнгөний талаар бодож, хангалттай зоригтой байвал та үүнийг шийдэж болно.
- Бид борлуулагчдаа удирдаж эхэлж байна, ялангуяа нэг оролтын уналтыг багасгахын тулд төлөвлөсөн оргил ачааллын үед хуваарьт засвар үйлчилгээ хийхийг хориглож байна;
- ба/эсвэл манай архитектур нь тавиур/мөр/ДС-г алдах боломжийг олгодог боловч үйлчилгээнүүд үргэлжлүүлэн ажилласаар байна;
- ба/эсвэл бид ачааллыг тавиурууд дээр хэвтээ байдлаар сайн тараадаг тул манай үйлчилгээ хэзээ ч нэг тавиур дээр хамгийн их хэрэглээнд хүрэхгүй.
Энд зөвхөн таамаглахаас гадна хэрэглээг хянах, серверүүд хэвийн болон оргил нөхцөлд хэрхэн цахилгаан зарцуулдагийг мэдэхэд маш хэрэгтэй. Тиймээс, зарим нэг дүн шинжилгээ хийсний дараа технологийн захирал өөрт байгаа бүхнээ шахаж: "Бид сайн дураараа шийдвэр гаргаж, нэг тавиур дээрх хамгийн их серверийн хэрэглээний дундаж нь хамгийн их хэрэглээнээс **маш их** доогуур байна" гэж нөхцөлт байдлаар Pserv = 0.8* Pmax.
Дараа нь 6 кВт-ын тавиур нь Pmax = 16 Вт-тай 375 серверийг багтаах боломжгүй, харин Pserv = 20 Вт * 375 = 0.8 Вт-тай 300 сервер багтах боломжгүй. Тэдгээр. 25% илүү серверүүд. Энэ бол маш том хэмнэлт юм - эцэст нь бидэнд нэн даруй 25% бага тавиур хэрэгтэй (мөн бид PDU, унтраалга, кабелийг хэмнэх болно). Ийм шийдлийн ноцтой сул тал бол бидний таамаглал зөв хэвээр байгаа эсэхийг байнга хянаж байх ёстой. Програм хангамжийн шинэ хувилбар нь фэнүүдийн ажиллагаа, хэрэглээг эрс өөрчилдөггүй, шинэ хувилбартай гэнэт хөгжүүлэлт нь серверүүдийг илүү үр дүнтэй ашиглаж эхлээгүй (унш: тэд илүү их ачаалал, сервер дээр илүү их зарцуулсан). Эцсийн эцэст бидний анхны таамаглал, дүгнэлт хоёулаа тэр даруй буруу болно. Энэ бол хариуцлагатай байх ёстой эрсдэл юм (эсвэл зайлсхийх, дараа нь илт дутуу ашигласан тавиурын төлбөрийг төлөх).
Чухал тэмдэглэл - хэрэв боломжтой бол та өөр өөр үйлчилгээний серверүүдийг тавиур дээр хэвтээ байдлаар түгээхийг хичээх хэрэгтэй. Энэ нь нэг үйлчилгээнд нэг багц сервер ирэхэд ийм нөхцөл байдал үүсэхгүйн тулд шаардлагатай бөгөөд "нягтрал" -ыг нэмэгдүүлэхийн тулд тавиурууд нь босоо байдлаар савлагдсан байдаг (учир нь энэ нь илүү хялбар байдаг). Бодит байдал дээр нэг тавиур нь ижил үйлчилгээний ачаалал багатай серверүүдээр дүүрсэн, нөгөө нь адилхан өндөр ачаалалтай серверүүдээр дүүрсэн байна. Хоёр дахь уналтын магадлал нэлээд өндөр, учир нь ачааллын профайл ижил бөгөөд энэ тавиур дээрх бүх серверүүд ачаалал ихэссэний үр дүнд ижил хэмжээгээр хэрэглэж эхэлдэг.
Тавиур дахь серверүүдийн хуваарилалт руу буцаж орцгооё. Бид тавиурын физик орон зай, тэжээлийн хязгаарлалтыг харлаа, одоо сүлжээг харцгаая. Та 24/32/48 N порттой унтраалга ашиглаж болно (жишээлбэл, бид 48 порттой ToR шилжүүлэгчтэй). Аз болоход, хэрэв та эвдэрсэн кабелийн талаар бодохгүй бол тийм ч олон сонголт байдаггүй. Бид Rnet бүлэгт нэг тавиур, хоёр эсвэл гурван тавиурт нэг унтраалгатай байх хувилбаруудыг авч үзэж байна. Нэг бүлэгт гурваас дээш тавиур хийх нь аль хэдийн хэтэрхий их юм шиг санагдаж байна, учир нь ... тавиуруудын хоорондох кабелийн асуудал илүү том болно.
Тиймээс, сүлжээний хувилбар бүрийн хувьд (бүлэгт 1, 2 эсвэл 3 тавиур) бид серверүүдийг тавиуруудын хооронд хуваарилдаг.
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Тиймээс, бүлэгт 2 тавиур бүхий сонголтуудын хувьд:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = rack бүрт 20 сервер.
Бид үлдсэн сонголтуудыг ижил аргаар авч үздэг.
Srack1 = 20
Srack3 = 16
Тэгээд бид бараг тэнд байна. Бид бүх S серверээ түгээх тавиуруудын тоог тоолдог (энэ нь 1000 байх ёстой):
R = тойм (S / (Srack * Rnet)) * Rnet
R1 = тойм (1000 / (20 * 1)) * 1 = 50 * 1 = 50 тавиур
R2 = тойм (1000 / (20 * 2)) * 2 = 25 * 2 = 50 тавиур
R3 = тойм (1000 / (16 * 3)) * 3 = 25 * 2 = 63 тавиур
Дараа нь бид тавиурын тоо, шаардлагатай тооны унтраалга, кабель гэх мэт дээр үндэслэн сонголт бүрийн TCO-ийг тооцоолно. TCO бага байх сонголтыг бид сонгодог. Ашиг!
Хэдийгээр 1 ба 2-р сонголтуудад шаардлагатай тавиуруудын тоо ижил боловч үнэ нь өөр байх болно гэдгийг анхаарна уу. Хоёрдахь хувилбарт шилжүүлэгчийн тоо хоёр дахин их, шаардлагатай кабелийн урт нь илүү урт байна.
P.S. Хэрэв та тавиурын хүч болон тавиурын өндрөөр тоглож чадвал хэлбэлзэл нэмэгдэнэ. Гэхдээ зүгээр л сонголтуудыг дамжуулснаар процессыг дээр дурдсантай адилтгаж болно. Тийм ээ, илүү олон хослолууд байх болно, гэхдээ маш хязгаарлагдмал тоо хэвээр байна - тооцооллын зориулалттай тавиурын тэжээлийн хангамжийг 1 кВт-ын алхамаар нэмэгдүүлэх боломжтой, ердийн тавиурууд нь хязгаарлагдмал тооны стандарт хэмжээтэй байдаг: 42U, 45U, 47U, 48U , 52U. Энд Excel-ийн Өгөгдлийн Хүснэгт горим дахь "Хэрэв-Хэрэв"-ийн шинжилгээ нь тооцоололд тусалж чадна. Бид хүлээн авсан ялтсуудыг хараад хамгийн бага хэмжээг сонгоно.
Эх сурвалж: www.habr.com