ریکوں میں سرورز کی تقسیم کو بہتر بنانا

ایک چیٹ میں مجھ سے ایک سوال پوچھا گیا:

— کیا ایسی کوئی چیز ہے جس کے بارے میں میں پڑھ سکتا ہوں کہ سرورز کو ریک میں کیسے صحیح طریقے سے پیک کیا جائے؟

میں نے محسوس کیا کہ میں ایسی تحریر نہیں جانتا، اس لیے میں نے خود لکھا۔

سب سے پہلے، یہ متن فزیکل ڈیٹا سینٹرز (DCs) میں فزیکل سرورز کے بارے میں ہے۔ دوسرا، ہم سمجھتے ہیں کہ بہت سارے سرورز ہیں: سیکڑوں-ہزاروں؛ ایک چھوٹی تعداد کے لیے یہ متن کوئی معنی نہیں رکھتا۔ تیسرا، ہم سمجھتے ہیں کہ ہمارے پاس تین رکاوٹیں ہیں: ریک میں جسمانی جگہ، فی ریک میں بجلی کی فراہمی، اور ریک کو قطاروں میں کھڑے ہونے دیں تاکہ ہم ملحقہ ریک میں سرورز کو جوڑنے کے لیے ایک ToR سوئچ استعمال کر سکیں۔

سوال کا جواب بہت زیادہ اس بات پر منحصر ہے کہ ہم کس پیرامیٹر کو بہتر بنا رہے ہیں اور بہترین نتیجہ حاصل کرنے کے لیے ہم کیا مختلف کر سکتے ہیں۔ مثال کے طور پر، مزید ترقی کے لیے مزید جگہ چھوڑنے کے لیے ہمیں صرف کم از کم جگہ لینے کی ضرورت ہے۔ یا ہوسکتا ہے کہ ہمیں ریک کی اونچائی، پاور فی ریک، PDU میں ساکٹ، سوئچز کے گروپ میں ریک کی تعداد (1، 2 یا 3 ریک کے لیے ایک سوئچ)، تاروں کی لمبائی اور کھینچنے کا کام ( یہ قطاروں کے آخر میں اہم ہے: ایک قطار میں 10 ریک اور 3 ریک فی سوئچ کے ساتھ، آپ کو تاروں کو دوسری قطار میں کھینچنا پڑے گا یا سوئچ میں موجود بندرگاہوں کو کم استعمال کرنا پڑے گا)، وغیرہ۔ الگ کہانیاں: سرورز کا انتخاب اور ڈی سی کا انتخاب، ہم فرض کریں گے کہ وہ منتخب ہیں۔

کچھ باریکیوں اور تفصیلات کو سمجھنا اچھا ہو گا، خاص طور پر، سرورز کی اوسط/زیادہ سے زیادہ کھپت، اور ہمیں بجلی کیسے فراہم کی جاتی ہے۔ لہذا، اگر ہمارے پاس روسی پاور سپلائی 230V ہے اور فی ریک ایک فیز ہے، تو 32A مشین ~7kW کو سنبھال سکتی ہے۔ ہم کہتے ہیں کہ ہم 6kW فی ریک کے لیے برائے نام ادائیگی کرتے ہیں۔ اگر فراہم کنندہ ہماری کھپت کو صرف 10 ریک کی قطار کے لیے ماپتا ہے، نہ کہ ہر ریک کے لیے، اور اگر مشین مشروط طور پر 7 کلو واٹ کٹ آف پر سیٹ کی گئی ہے، تو تکنیکی طور پر ہم ایک ریک میں 6.9 کلو واٹ، دوسرے میں 5.1 کلوواٹ اور سب کچھ ٹھیک ہو جائے گا - سزا نہیں ہے.

عام طور پر ہمارا بنیادی مقصد اخراجات کو کم کرنا ہوتا ہے۔ پیمائش کرنے کا بہترین معیار TCO (ملکیت کی کل لاگت) میں کمی ہے۔ یہ مندرجہ ذیل ٹکڑوں پر مشتمل ہے:

• CAPEX: DC انفراسٹرکچر، سرورز، نیٹ ورک ہارڈویئر اور کیبلنگ کی خریداری
• اوپیکس: ڈی سی رینٹل، بجلی کی کھپت، دیکھ بھال۔ OPEX سروس کی زندگی پر منحصر ہے۔ اسے 3 سال سمجھنا مناسب ہے۔

مجموعی پائی میں انفرادی ٹکڑے کتنے بڑے ہیں اس پر انحصار کرتے ہوئے، ہمیں سب سے زیادہ مہنگے کو بہتر بنانے کی ضرورت ہے، اور باقی تمام وسائل کو زیادہ سے زیادہ مؤثر طریقے سے استعمال کرنے دیں۔

فرض کریں کہ ہمارے پاس ایک موجودہ DC ہے، H یونٹس کی ایک ریک کی اونچائی ہے (مثال کے طور پر، H=47)، بجلی فی ریک Prack (Prack=6kW)، اور ہم نے h=2U دو یونٹ سرور استعمال کرنے کا فیصلہ کیا۔ ہم سوئچز، پیچ پینلز اور منتظمین کے لیے ریک سے 2..4 یونٹ ہٹا دیں گے۔ وہ. جسمانی طور پر، ہمارے ریک میں Sh=rounddown((H-2..4)/h) سرورز ہیں (یعنی Sh = راؤنڈ ڈاؤن((47-4)/2)=21 سرور فی ریک)۔ آئیے اس Sh.

سادہ صورت میں، ریک میں موجود تمام سرور ایک جیسے ہیں۔ مجموعی طور پر، اگر ہم سرورز سے ریک بھرتے ہیں، تو ہر سرور پر ہم اوسطاً پاور Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) خرچ کر سکتے ہیں۔ سادگی کے لیے، ہم یہاں سوئچ کی کھپت کو نظر انداز کرتے ہیں۔

آئیے ایک قدم ایک طرف رکھیں اور اس بات کا تعین کریں کہ Pmax سرور کی زیادہ سے زیادہ استعمال کیا ہے۔ اگر یہ بہت آسان، بہت غیر موثر اور مکمل طور پر محفوظ ہے، تو ہم پڑھتے ہیں کہ سرور کی پاور سپلائی پر کیا لکھا ہے - یہ ہے۔

اگر یہ زیادہ پیچیدہ اور زیادہ کارآمد ہے، تو ہم تمام اجزاء کا TDP (تھرمل ڈیزائن پیکج) لیتے ہیں اور اس کا خلاصہ کرتے ہیں (یہ زیادہ درست نہیں ہے، لیکن یہ ممکن ہے)۔

عام طور پر ہم اجزاء کے ٹی ڈی پی کو نہیں جانتے ہیں (سوائے سی پی یو کے)، اس لیے ہم سب سے درست، بلکہ سب سے پیچیدہ طریقہ اختیار کرتے ہیں (ہمیں لیبارٹری کی ضرورت ہے) - ہم مطلوبہ ترتیب کا ایک تجرباتی سرور لیتے ہیں اور اسے لوڈ کرتے ہیں، مثال کے طور پر، Linpack (CPU اور میموری) اور fio (ڈسک) کے ساتھ، ہم کھپت کی پیمائش کرتے ہیں۔ اگر ہم اسے سنجیدگی سے لیں تو ہمیں ٹیسٹ کے دوران سرد راہداری میں گرم ترین ماحول پیدا کرنے کی بھی ضرورت ہے، کیونکہ اس سے پنکھے کی کھپت اور CPU کی کھپت دونوں متاثر ہوں گی۔ ہم اس مخصوص بوجھ کے تحت ان مخصوص حالات میں ایک مخصوص ترتیب کے ساتھ ایک مخصوص سرور کی زیادہ سے زیادہ کھپت حاصل کرتے ہیں۔ ہمارا سیدھا مطلب ہے کہ نیا سسٹم فرم ویئر، ایک مختلف سافٹ ویئر ورژن، اور دیگر حالات نتیجہ کو متاثر کر سکتے ہیں۔

تو، Pserv پر واپس جائیں اور ہم Pmax کے ساتھ اس کا موازنہ کیسے کریں۔ یہ سمجھنے کی بات ہے کہ سروسز کیسے کام کرتی ہیں اور آپ کے تکنیکی ڈائریکٹر کے اعصاب کتنے مضبوط ہیں۔

اگر ہم بالکل بھی کوئی خطرہ مول نہیں لیتے ہیں، تو ہمیں یقین ہے کہ تمام سرور بیک وقت اپنی زیادہ سے زیادہ استعمال کرنا شروع کر سکتے ہیں۔ اسی لمحے، DC میں ایک ان پٹ ہو سکتا ہے۔ ان حالات میں بھی، انفرا کو سروس فراہم کرنا ضروری ہے، لہذا Pserv ≡ Pmax. یہ ایک ایسا نقطہ نظر ہے جہاں وشوسنییتا بالکل اہم ہے۔

اگر ٹیک ڈائریکٹر نہ صرف مثالی سیکورٹی کے بارے میں سوچتا ہے بلکہ کمپنی کے پیسے کے بارے میں بھی سوچتا ہے اور کافی بہادر ہے، تو آپ فیصلہ کر سکتے ہیں کہ

• ہم اپنے وینڈرز کو منظم کرنا شروع کر رہے ہیں، خاص طور پر، ہم ایک ان پٹ میں کمی کو کم کرنے کے لیے منصوبہ بند چوٹی کے بوجھ کے وقت طے شدہ دیکھ بھال پر پابندی لگا رہے ہیں۔
• اور/یا ہمارا فن تعمیر آپ کو ریک/رو/DC کھونے کی اجازت دیتا ہے، لیکن خدمات کام کرتی رہتی ہیں۔
• اور/یا ہم ریک پر بوجھ کو افقی طور پر اچھی طرح سے پھیلاتے ہیں، اس لیے ہماری خدمات کبھی بھی ایک ریک میں زیادہ سے زیادہ استعمال تک نہیں جائیں گی۔

یہاں یہ صرف اندازہ لگانا ہی نہیں بلکہ کھپت کی نگرانی کرنے اور یہ جاننے کے لیے بھی بہت مفید ہے کہ سرورز عام اور چوٹی کے حالات میں بجلی کیسے استعمال کرتے ہیں۔ لہذا، کچھ تجزیے کے بعد، ٹیک ڈائریکٹر اپنے پاس موجود ہر چیز کو نچوڑ لیتا ہے اور کہتا ہے: "ہم ایک رضاکارانہ فیصلہ کرتے ہیں کہ فی ریک زیادہ سے زیادہ سرور کی کھپت کی زیادہ سے زیادہ قابل حصول اوسط زیادہ سے زیادہ کھپت سے **اتنی زیادہ** نیچے ہے،" مشروط طور پر Pserv = 0.8* Pmax

اور پھر 6kW کا ریک مزید Pmax = 16W کے ساتھ 375 سرورز کو نہیں رکھ سکتا، لیکن Pserv = 20W * 375 = 0.8W کے ساتھ 300 سرورز کو ایڈجسٹ کر سکتا ہے۔ وہ. 25% زیادہ سرورز۔ یہ ایک بہت بڑی بچت ہے - سب کے بعد، ہمیں فوری طور پر 25% کم ریک کی ضرورت ہے (اور ہم PDUs، سوئچز اور کیبلز پر بھی بچت کریں گے)۔ اس طرح کے حل کا ایک سنگین نقصان یہ ہے کہ ہمیں مسلسل نگرانی کرنی چاہیے کہ ہمارے مفروضے اب بھی درست ہیں۔ کہ نیا فرم ویئر ورژن شائقین کے آپریشن اور کھپت کو نمایاں طور پر تبدیل نہیں کرتا ہے، کہ نئی ریلیز کے ساتھ اچانک ترقی نے سرورز کو زیادہ موثر طریقے سے استعمال کرنا شروع نہیں کیا (پڑھیں: انہوں نے سرور پر زیادہ بوجھ اور زیادہ کھپت حاصل کی)۔ آخر کار ہمارے ابتدائی مفروضے اور نتائج دونوں فوراً ہی غلط ہو جاتے ہیں۔ یہ ایک ایسا خطرہ ہے جسے ذمہ داری سے لیا جانا چاہیے (یا اس سے گریز کیا جائے اور پھر ظاہر ہے کہ کم استعمال شدہ ریک کے لیے ادائیگی کی جائے)۔

ایک اہم نوٹ - اگر ممکن ہو تو آپ کو مختلف سروسز کے سرورز کو افقی طور پر ریک میں تقسیم کرنے کی کوشش کرنی چاہیے۔ یہ ضروری ہے تاکہ حالات ایسے نہ ہوں جب سرورز کا ایک بیچ ایک سروس کے لیے آتا ہے، ریک عمودی طور پر اس سے بھری ہوتی ہیں تاکہ "کثافت" کو بڑھایا جا سکے (کیونکہ اس طرح یہ آسان ہے)۔ حقیقت میں، یہ پتہ چلتا ہے کہ ایک ریک ایک ہی سروس کے ایک جیسے کم لوڈ سرورز سے بھرا ہوا ہے، اور دوسرا اتنا ہی زیادہ لوڈ سرورز سے بھرا ہوا ہے۔ دوسرے زوال کا امکان نمایاں طور پر زیادہ ہے، کیونکہ لوڈ پروفائل ایک جیسا ہے، اور اس ریک میں موجود تمام سرورز بڑھتے ہوئے بوجھ کے نتیجے میں ایک ہی مقدار میں استعمال کرنا شروع کر دیتے ہیں۔

آئیے ریک میں سرورز کی تقسیم پر واپس آتے ہیں۔ ہم نے فزیکل ریک اسپیس اور پاور کی حدود کو دیکھا ہے، اب آئیے نیٹ ورک کو دیکھتے ہیں۔ آپ 24/32/48 N بندرگاہوں کے ساتھ سوئچ استعمال کر سکتے ہیں (مثال کے طور پر، ہمارے پاس 48-پورٹ ٹو آر سوئچز ہیں)۔ خوش قسمتی سے، اگر آپ بریک آؤٹ کیبلز کے بارے میں نہیں سوچتے ہیں تو بہت سے اختیارات نہیں ہیں۔ ہم ان منظرناموں پر غور کر رہے ہیں جب ہمارے پاس فی ریک ایک سوئچ ہو، Rnet گروپ میں دو یا تین ریک کے لیے ایک سوئچ ہو۔ مجھے ایسا لگتا ہے کہ ایک گروپ میں تین سے زیادہ ریک پہلے ہی بہت زیادہ ہیں، کیونکہ... ریک کے درمیان کیبلنگ کا مسئلہ بہت بڑا ہو جاتا ہے۔

لہذا، نیٹ ورک کے ہر منظر نامے کے لیے (ایک گروپ میں 1، 2 یا 3 ریک)، ہم سرورز کو ریک میں تقسیم کرتے ہیں:

Srack = منٹ (Sh، راؤنڈ ڈاؤن (Prack/Pserv)، راؤنڈ ڈاؤن (N/Rnet))

اس طرح، ایک گروپ میں 2 ریک والے آپشن کے لیے:

Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 سرورز فی ریک۔

ہم باقی اختیارات پر اسی طرح غور کرتے ہیں:

Srack1 = 20
Srack3 = 16

اور ہم تقریباً وہاں ہیں۔ ہم اپنے تمام سرورز کو تقسیم کرنے کے لیے ریک کی تعداد گنتے ہیں (اسے 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 کے لیے ریک کی مطلوبہ تعداد ایک جیسی ہے، لیکن ان کی قیمت مختلف ہوگی، کیونکہ دوسرے آپشن کے لیے سوئچز کی تعداد نصف ہے، اور مطلوبہ کیبلز کی لمبائی لمبی ہے۔

PS اگر آپ کو پاور فی ریک اور ریک کی اونچائی کے ساتھ کھیلنے کا موقع ملتا ہے تو تغیر پذیری بڑھ جاتی ہے۔ لیکن اس عمل کو صرف اختیارات سے گزر کر اوپر بیان کردہ تک کم کیا جا سکتا ہے۔ ہاں، مزید امتزاجات ہوں گے، لیکن پھر بھی بہت محدود تعداد - حساب کے لیے ریک کو بجلی کی فراہمی 1 کلو واٹ کے مراحل میں بڑھائی جا سکتی ہے، عام ریک محدود تعداد میں معیاری سائز میں آتے ہیں: 42U، 45U، 47U، 48U ، 52 یو۔ اور یہاں ڈیٹا ٹیبل موڈ میں Excel کا What-If تجزیہ حساب میں مدد کر سکتا ہے۔ ہم موصول ہونے والی پلیٹوں کو دیکھتے ہیں اور کم از کم کا انتخاب کرتے ہیں۔

ماخذ: www.habr.com