ہم نے ایک ڈیٹا سینٹر نیٹ ورک ڈیزائن تیار کیا ہے جو 100 ہزار سرورز سے بڑے کمپیوٹنگ کلسٹرز کی تعیناتی کی اجازت دیتا ہے جس کی چوٹی بائسیکشن بینڈوڈتھ ایک پیٹا بائٹ فی سیکنڈ سے زیادہ ہے۔
دمتری افاناسیف کی رپورٹ سے آپ نئے ڈیزائن کے بنیادی اصولوں، اسکیلنگ ٹوپولاجیز، اس سے پیدا ہونے والے مسائل، ان کو حل کرنے کے آپشنز، جدید نیٹ ورک ڈیوائسز کے فارورڈنگ ہوائی جہاز کے افعال کو روٹنگ اور اسکیلنگ کی خصوصیات کے بارے میں جانیں گے۔ ECMP روٹس کی ایک بڑی تعداد کے ساتھ ٹوپولاجیز۔ اس کے علاوہ، دیما نے بیرونی رابطے کی تنظیم، جسمانی تہہ، کیبلنگ کے نظام اور صلاحیت کو مزید بڑھانے کے طریقوں کے بارے میں مختصراً بات کی۔
- سب کو دوپہر بخیر! میرا نام دمتری افاناسیف ہے، میں Yandex میں نیٹ ورک آرکیٹیکٹ ہوں اور بنیادی طور پر ڈیٹا سینٹر نیٹ ورکس کو ڈیزائن کرتا ہوں۔
میری کہانی Yandex ڈیٹا سینٹرز کے تازہ ترین نیٹ ورک کے بارے میں ہوگی۔ یہ ہمارے پاس موجود ڈیزائن کا بہت زیادہ ارتقاء ہے، لیکن ساتھ ہی کچھ نئے عناصر بھی ہیں۔ یہ ایک جائزہ پریزنٹیشن ہے کیونکہ بہت ساری معلومات کو تھوڑے سے وقت میں پیک کیا جانا تھا۔ ہم ایک منطقی ٹوپولوجی کو منتخب کرکے شروع کریں گے۔ اس کے بعد کنٹرول ہوائی جہاز کا ایک جائزہ ہوگا اور ڈیٹا پلین اسکیل ایبلٹی کے ساتھ مسائل ہوں گے، جسمانی سطح پر کیا ہوگا اس کا انتخاب، اور ہم آلات کی کچھ خصوصیات کو دیکھیں گے۔ آئیے تھوڑا سا چھوتے ہیں کہ MPLS کے ساتھ ڈیٹا سینٹر میں کیا ہو رہا ہے، جس کے بارے میں ہم نے کچھ عرصہ پہلے بات کی تھی۔
تو، لوڈ اور خدمات کے لحاظ سے Yandex کیا ہے؟ Yandex ایک عام ہائپر اسکیلر ہے۔ اگر ہم صارفین کو دیکھیں تو ہم بنیادی طور پر صارف کی درخواستوں پر کارروائی کرتے ہیں۔ نیز مختلف اسٹریمنگ سروسز اور ڈیٹا ٹرانسفر، کیونکہ ہمارے پاس اسٹوریج سروسز بھی ہیں۔ اگر پسدید کے قریب ہے، تو وہاں بنیادی ڈھانچے کا بوجھ اور خدمات ظاہر ہوتی ہیں، جیسے تقسیم شدہ آبجیکٹ اسٹوریج، ڈیٹا کی نقل اور یقیناً مسلسل قطاریں۔ کام کے بوجھ کی اہم اقسام میں سے ایک MapReduce اور اسی طرح کے نظام، سٹریم پروسیسنگ، مشین لرننگ وغیرہ ہیں۔
انفراسٹرکچر کیسا ہے جس کے اوپر یہ سب ہوتا ہے؟ ایک بار پھر، ہم ایک خوبصورت عام ہائپر اسکیلر ہیں، حالانکہ ہم شاید اسپیکٹرم کے کم ہائپر اسکیلر سائیڈ کے تھوڑا قریب ہیں۔ لیکن ہم میں تمام صفات موجود ہیں۔ ہم جہاں بھی ممکن ہو کموڈٹی ہارڈویئر اور افقی اسکیلنگ کا استعمال کرتے ہیں۔ ہمارے پاس وسائل کا مکمل پولنگ ہے: ہم انفرادی مشینوں، انفرادی ریکوں کے ساتھ کام نہیں کرتے ہیں، لیکن انہیں کچھ اضافی خدمات کے ساتھ قابل تبادلہ وسائل کے ایک بڑے تالاب میں جوڑتے ہیں جو منصوبہ بندی اور مختص کرنے سے متعلق ہیں، اور اس پورے پول کے ساتھ کام کرتے ہیں۔
لہذا ہمارے پاس اگلی سطح ہے - کمپیوٹنگ کلسٹر کی سطح پر آپریٹنگ سسٹم۔ یہ بہت اہم ہے کہ ہم ٹیکنالوجی کے اسٹیک کو مکمل طور پر کنٹرول کریں جسے ہم استعمال کرتے ہیں۔ ہم اینڈ پوائنٹس (میزبان)، نیٹ ورک اور سافٹ ویئر اسٹیک کو کنٹرول کرتے ہیں۔
ہمارے پاس روس اور بیرون ملک کئی بڑے ڈیٹا سینٹرز ہیں۔ وہ ایک ریڑھ کی ہڈی کے ذریعہ متحد ہیں جو MPLS ٹیکنالوجی کا استعمال کرتا ہے۔ ہمارا اندرونی انفراسٹرکچر تقریباً مکمل طور پر IPv6 پر بنایا گیا ہے، لیکن چونکہ ہمیں بیرونی ٹریفک کی خدمت کرنے کی ضرورت ہے جو اب بھی بنیادی طور پر IPv4 پر آتی ہے، ہمیں کسی نہ کسی طرح IPv4 پر آنے والی درخواستوں کو فرنٹ اینڈ سرورز تک پہنچانا چاہیے، اور تھوڑا سا مزید بیرونی IPv4- انٹرنیٹ پر جانا چاہیے۔ مثال کے طور پر، اشاریہ سازی کے لیے۔
ڈیٹا سینٹر نیٹ ورک ڈیزائنز کی آخری چند تکرار میں ملٹی لیئر کلوس ٹوپولاجیز استعمال کی گئی ہیں اور یہ صرف L3 ہیں۔ ہم نے تھوڑی دیر پہلے L2 کو چھوڑا اور سکون کی سانس لی۔ آخر میں، ہمارے بنیادی ڈھانچے میں لاکھوں کمپیوٹ (سرور) مثالیں شامل ہیں۔ کچھ عرصہ پہلے کلسٹر کا زیادہ سے زیادہ سائز تقریباً 10 ہزار سرورز تھا۔ یہ بڑی حد تک اس وجہ سے ہے کہ وہی کلسٹر سطح کے آپریٹنگ سسٹم، شیڈولرز، وسائل کی تقسیم وغیرہ کیسے کام کر سکتے ہیں۔ چونکہ انفراسٹرکچر سافٹ ویئر کی طرف پیش رفت ہوئی ہے، اس لیے ہدف کا سائز اب ایک کمپیوٹنگ کلسٹر میں تقریباً 100 ہزار سرورز ہے، اور ہمارے پاس ایک کام ہے - نیٹ ورک فیکٹریاں بنانے کے قابل ہونا جو اس طرح کے کلسٹر میں موثر وسائل کو جمع کرنے کی اجازت دیتی ہے۔
ہم ڈیٹا سینٹر نیٹ ورک سے کیا چاہتے ہیں؟ سب سے پہلے، بہت سستی اور کافی یکساں تقسیم شدہ بینڈوڈتھ ہے۔ کیونکہ نیٹ ورک وہ ریڑھ کی ہڈی ہے جس کے ذریعے ہم وسائل جمع کر سکتے ہیں۔ نئے ہدف کا سائز ایک کلسٹر میں تقریباً 100 ہزار سرورز ہے۔
ہم یقیناً ایک قابل توسیع اور مستحکم کنٹرول طیارہ بھی چاہتے ہیں، کیونکہ اتنے بڑے انفراسٹرکچر پر بے ترتیب واقعات سے بھی بہت سارے سر درد پیدا ہوتے ہیں، اور ہم نہیں چاہتے کہ کنٹرول طیارہ ہمارے لیے بھی سر درد لائے۔ ساتھ ہی ہم اس میں ریاست کو مائنس کرنا چاہتے ہیں۔ حالت جتنی چھوٹی ہوگی، سب کچھ اتنا ہی بہتر اور مستحکم ہوگا، اور تشخیص کرنا اتنا ہی آسان ہوگا۔
یقینا، ہمیں آٹومیشن کی ضرورت ہے، کیونکہ اس طرح کے بنیادی ڈھانچے کو دستی طور پر منظم کرنا ناممکن ہے، اور یہ کچھ عرصے سے ناممکن ہے۔ ہمیں ممکنہ حد تک آپریشنل سپورٹ اور CI/CD سپورٹ کی ضرورت ہے جس حد تک یہ فراہم کی جا سکتی ہے۔
ڈیٹا سینٹرز اور کلسٹرز کے اتنے سائز کے ساتھ، سروس میں رکاوٹ کے بغیر اضافی تعیناتی اور توسیع کی حمایت کا کام کافی تیز ہو گیا ہے۔ اگر ایک ہزار مشینوں کے سائز کے کلسٹرز پر، شاید دس ہزار مشینوں کے قریب، وہ اب بھی ایک آپریشن کے طور پر تیار کی جا سکتی ہیں - یعنی، ہم انفراسٹرکچر کی توسیع کا منصوبہ بنا رہے ہیں، اور کئی ہزار مشینیں ایک آپریشن کے طور پر شامل کی جائیں گی، پھر ایک لاکھ مشینوں کے سائز کا ایک جھرمٹ اس طرح فوری طور پر پیدا نہیں ہوتا ہے، یہ ایک وقت کے ساتھ بنایا جاتا ہے۔ اور یہ ضروری ہے کہ اس وقت جو کچھ پہلے ہی نکالا جا چکا ہے، جو بنیادی ڈھانچہ تعینات کیا گیا ہے، دستیاب ہونا چاہیے۔
اور ایک ضرورت جو ہمارے پاس تھی اور رہ گئی: ملٹی ٹیننسی کے لیے سپورٹ، یعنی ورچوئلائزیشن یا نیٹ ورک سیگمنٹیشن۔ اب ہمیں نیٹ ورک فیبرک کی سطح پر ایسا کرنے کی ضرورت نہیں ہے، کیونکہ شارڈنگ میزبانوں کے پاس چلی گئی ہے، اور اس نے ہمارے لیے اسکیلنگ کو بہت آسان بنا دیا ہے۔ IPv6 اور ایڈریس کی ایک بڑی جگہ کا شکریہ، ہمیں اندرونی انفراسٹرکچر میں ڈپلیکیٹ ایڈریس استعمال کرنے کی ضرورت نہیں تھی؛ تمام ایڈریسنگ پہلے سے ہی منفرد تھی۔ اور اس حقیقت کا شکریہ کہ ہم نے فلٹرنگ اور نیٹ ورک سیگمنٹیشن کو میزبانوں کے لیے لے لیا ہے، ہمیں ڈیٹا سینٹر نیٹ ورکس میں کوئی ورچوئل نیٹ ورک انٹیٹی بنانے کی ضرورت نہیں ہے۔
ایک بہت اہم چیز وہ ہے جس کی ہمیں ضرورت نہیں ہے۔ اگر نیٹ ورک سے کچھ فنکشنز کو ہٹایا جا سکتا ہے، تو یہ زندگی کو بہت آسان بنا دیتا ہے، اور، ایک اصول کے طور پر، دستیاب آلات اور سافٹ ویئر کے انتخاب کو وسعت دیتا ہے، جس سے تشخیص بہت آسان ہو جاتا ہے۔
تو، وہ کون سی چیز ہے جس کی ہمیں ضرورت نہیں ہے، ہم کس چیز کو ترک کرنے میں کامیاب رہے ہیں، جب یہ ہوا تو ہمیشہ خوشی کے ساتھ نہیں، بلکہ عمل مکمل ہونے پر بڑی راحت کے ساتھ؟
سب سے پہلے، L2 کو ترک کرنا۔ ہمیں L2 کی ضرورت نہیں ہے، نہ اصلی اور نہ ہی نقلی۔ غیر استعمال شدہ زیادہ تر اس حقیقت کی وجہ سے کہ ہم ایپلیکیشن اسٹیک کو کنٹرول کرتے ہیں۔ ہماری ایپلی کیشنز افقی طور پر توسیع پذیر ہیں، وہ L3 ایڈریسنگ کے ساتھ کام کرتی ہیں، وہ زیادہ پریشان نہیں ہیں کہ کچھ انفرادی مثال باہر چلی گئی ہے، وہ صرف ایک نیا رول آؤٹ کرتے ہیں، اسے پرانے ایڈریس پر رول آؤٹ کرنے کی ضرورت نہیں ہے، کیونکہ وہاں ایک کلسٹر میں موجود مشینوں کی سروس کی دریافت اور نگرانی کی الگ سطح۔ ہم یہ کام نیٹ ورک کو نہیں سونپتے ہیں۔ نیٹ ورک کا کام پوائنٹ A سے پوائنٹ B تک پیکٹ پہنچانا ہے۔
ہمارے پاس ایسے حالات بھی نہیں ہیں جہاں پتے نیٹ ورک کے اندر منتقل ہوتے ہیں، اور اس کی نگرانی کرنے کی ضرورت ہے۔ بہت سے ڈیزائنوں میں VM کی نقل و حرکت کو سپورٹ کرنے کے لیے عام طور پر اس کی ضرورت ہوتی ہے۔ ہم بڑے Yandex کے اندرونی انفراسٹرکچر میں ورچوئل مشینوں کی نقل و حرکت کا استعمال نہیں کرتے ہیں، اور اس کے علاوہ، ہم سمجھتے ہیں کہ اگر ایسا کیا جائے تو بھی نیٹ ورک سپورٹ کے ساتھ ایسا نہیں ہونا چاہیے۔ اگر واقعی ایسا کرنے کی ضرورت ہے، تو اسے میزبان کی سطح پر کرنے کی ضرورت ہے، اور ایسے ایڈریسز کو دھکیلنے کی ضرورت ہے جو اوورلیز میں منتقل ہو سکتے ہیں، تاکہ انڈرلے کے روٹنگ سسٹم (ٹرانسپورٹ نیٹ ورک) کو چھونے یا بہت زیادہ متحرک تبدیلیاں نہ کریں۔ .
ایک اور ٹیکنالوجی جو ہم استعمال نہیں کرتے وہ ملٹی کاسٹ ہے۔ اگر آپ چاہیں تو میں آپ کو تفصیل سے بتا سکتا ہوں کہ کیوں۔ اس سے زندگی بہت آسان ہو جاتی ہے، کیونکہ اگر کسی نے اس سے نمٹا ہے اور یہ دیکھا ہے کہ ملٹی کاسٹ کنٹرول طیارہ کیسا لگتا ہے، سب سے آسان تنصیبات کے علاوہ، یہ ایک بڑا درد سر ہے۔ اور مزید کیا ہے، مثال کے طور پر ایک اچھی طرح سے کام کرنے والے اوپن سورس کے نفاذ کو تلاش کرنا مشکل ہے۔
آخر میں، ہم اپنے نیٹ ورکس کو ڈیزائن کرتے ہیں تاکہ وہ زیادہ تبدیل نہ ہوں۔ ہم اس حقیقت پر اعتماد کر سکتے ہیں کہ روٹنگ سسٹم میں بیرونی واقعات کا بہاؤ چھوٹا ہے۔
جب ہم ڈیٹا سینٹر نیٹ ورک تیار کرتے ہیں تو کون سے مسائل پیدا ہوتے ہیں اور کن پابندیوں کو مدنظر رکھنا چاہیے؟ لاگت، بالکل. اسکیل ایبلٹی، وہ سطح جس تک ہم بڑھنا چاہتے ہیں۔ سروس کو روکنے کے بغیر توسیع کرنے کی ضرورت ہے. بینڈوتھ، دستیابی نگرانی کے نظام، آپریشنل ٹیموں کے لیے نیٹ ورک پر کیا ہو رہا ہے اس کی مرئیت۔ آٹومیشن سپورٹ - ایک بار پھر، زیادہ سے زیادہ، کیونکہ مختلف کاموں کو مختلف سطحوں پر حل کیا جا سکتا ہے، بشمول اضافی تہوں کا تعارف۔ ٹھیک ہے، [ممکنہ طور پر] دکانداروں پر منحصر نہیں ہے۔ اگرچہ مختلف تاریخی ادوار میں، اس بات پر منحصر ہے کہ آپ کس حصے کو دیکھتے ہیں، یہ آزادی حاصل کرنا آسان تھا یا زیادہ مشکل۔ اگر ہم نیٹ ورک ڈیوائس چپس کا ایک کراس سیکشن لیں، تو حال ہی میں یہ بہت مشروط تھا کہ دکانداروں سے آزادی کے بارے میں بات کی جائے، اگر ہم بھی اعلی تھرو پٹ کے ساتھ چپس چاہتے ہیں۔
ہم اپنا نیٹ ورک بنانے کے لیے کون سی منطقی ٹوپولوجی استعمال کریں گے؟ یہ ملٹی لیول Clos ہوگا۔ درحقیقت، اس وقت کوئی حقیقی متبادل نہیں ہے۔ اور Clos ٹوپولوجی کافی اچھی ہے، یہاں تک کہ جب ہمارے پاس بڑے ریڈکس سوئچز ہوں تو مختلف جدید ٹوپولاجیوں کے مقابلے میں جو کہ اب تعلیمی دلچسپی کے شعبے میں زیادہ ہیں۔
ملٹی لیول Clos نیٹ ورک کی ساخت کس طرح ہے اور اس میں مختلف عناصر کو کیا کہا جاتا ہے؟ سب سے پہلے، ہوا نے اپنے آپ کو یہ بتانے کے لیے کہ شمال کہاں ہے، جنوب کہاں ہے، مشرق کہاں ہے، مغرب کہاں ہے۔ اس قسم کے نیٹ ورک عام طور پر وہ لوگ بناتے ہیں جن کے پاس مغرب-مشرق کی بہت بڑی ٹریفک ہوتی ہے۔ جہاں تک باقی عناصر کا تعلق ہے، سب سے اوپر ایک ورچوئل سوئچ ہے جو چھوٹے سوئچز سے جمع ہوتا ہے۔ یہ Clos نیٹ ورکس کی تکراری تعمیر کا بنیادی خیال ہے۔ ہم عناصر کو کسی قسم کے ریڈکس کے ساتھ لیتے ہیں اور ان کو جوڑتے ہیں تاکہ ہمیں جو ملتا ہے اسے بڑے ریڈکس کے ساتھ سوئچ سمجھا جا سکے۔ اگر آپ کو مزید ضرورت ہو تو، طریقہ کار کو دہرایا جا سکتا ہے۔
صورتوں میں، مثال کے طور پر، دو سطحی Clos کے ساتھ، جب میرے خاکے میں عمودی اجزاء کی واضح طور پر شناخت کرنا ممکن ہو، تو انہیں عام طور پر طیارہ کہا جاتا ہے۔ اگر ہم تین سطحوں کے اسپائن سوئچز کے ساتھ Clos بنائیں (جن میں سے سبھی باؤنڈری یا ٹی او آر سوئچ نہیں ہیں اور جو صرف ٹرانزٹ کے لیے استعمال ہوتے ہیں)، تو ہوائی جہاز زیادہ پیچیدہ نظر آئیں گے؛ دو سطح والے بالکل ایسے ہی نظر آتے ہیں۔ ہم ٹی او آر یا لیف سوئچ کے بلاک کو کہتے ہیں اور ان کے ساتھ منسلک پہلی سطح کے ریڑھ کی ہڈی کے سوئچ کو پوڈ کہتے ہیں۔ Pod کے اوپری حصے میں اسپائن-1 کی سطح کے اسپائن سوئچز Pod کا سب سے اوپر، Pod کا سب سے اوپر ہے۔ وہ سوئچ جو پوری فیکٹری کے اوپری حصے میں واقع ہیں وہ فیکٹری کی اوپری تہہ ہیں، کپڑے کا ٹاپ۔
یقیناً، سوال یہ پیدا ہوتا ہے: Clos نیٹ ورک کچھ عرصے سے بنائے گئے ہیں؛ یہ خیال عام طور پر کلاسیکی ٹیلی فونی، TDM نیٹ ورکس کے زمانے سے آتا ہے۔ شاید کچھ بہتر ظاہر ہوا ہے، شاید کچھ بہتر کیا جا سکتا ہے؟ ہاں اور نہ. نظریاتی طور پر ہاں، عملی طور پر مستقبل قریب میں یقینی طور پر نہیں۔ چونکہ بہت ساری دلچسپ ٹوپولاجیاں ہیں، ان میں سے کچھ پیداوار میں بھی استعمال ہوتی ہیں، مثال کے طور پر، ڈریگن فلائی HPC ایپلی کیشنز میں استعمال ہوتی ہے۔ Xpander، FatClique، Jellyfish جیسی دلچسپ ٹوپولاجیاں بھی ہیں۔ اگر آپ حال ہی میں SIGCOMM یا NSDI جیسی کانفرنسوں کی رپورٹس پر نظر ڈالتے ہیں، تو آپ کو متبادل ٹوپولاجیز پر کام کی کافی بڑی تعداد مل سکتی ہے جن میں Clos سے بہتر خصوصیات (ایک یا دوسری) ہیں۔
لیکن ان تمام ٹوپولاجیوں میں ایک دلچسپ خاصیت ہے۔ یہ ڈیٹا سینٹر نیٹ ورکس میں ان کے نفاذ کو روکتا ہے، جسے ہم کموڈٹی ہارڈویئر پر بنانے کی کوشش کر رہے ہیں اور جس کی قیمت کافی معقول ہے۔ ان تمام متبادل ٹوپولاجیوں میں، بدقسمتی سے زیادہ تر بینڈوڈتھ مختصر ترین راستوں کے ذریعے قابل رسائی نہیں ہے۔ لہذا، ہم فوری طور پر روایتی کنٹرول طیارے کو استعمال کرنے کا موقع کھو دیتے ہیں.
نظریاتی طور پر مسئلہ کا حل معلوم ہوتا ہے۔ یہ، مثال کے طور پر، k-shortest پاتھ کا استعمال کرتے ہوئے لنک اسٹیٹ کی ترمیم ہیں، لیکن، دوبارہ، ایسے کوئی پروٹوکول نہیں ہیں جو پیداوار میں لاگو کیے جائیں اور آلات پر وسیع پیمانے پر دستیاب ہوں۔
مزید برآں، چونکہ زیادہ تر صلاحیت مختصر ترین راستوں کے ذریعے قابل رسائی نہیں ہے، اس لیے ہمیں ان تمام راستوں کو منتخب کرنے کے لیے صرف کنٹرول طیارے سے زیادہ میں ترمیم کرنے کی ضرورت ہے (اور ویسے، یہ کنٹرول طیارے میں نمایاں طور پر زیادہ حالت ہے)۔ ہمیں ابھی بھی فارورڈنگ جہاز میں ترمیم کرنے کی ضرورت ہے، اور، ایک اصول کے طور پر، کم از کم دو اضافی خصوصیات درکار ہیں۔ یہ پیکٹ فارورڈنگ کے بارے میں تمام فیصلے ایک بار کرنے کی صلاحیت ہے، مثال کے طور پر، میزبان پر۔ درحقیقت، یہ سورس روٹنگ ہے، بعض اوقات انٹر کنکشن نیٹ ورکس کے لٹریچر میں اسے ایک بار میں فارورڈنگ فیصلے کہا جاتا ہے۔ اور اڈاپٹیو روٹنگ ایک ایسا فنکشن ہے جس کی ہمیں نیٹ ورک کے عناصر پر ضرورت ہوتی ہے، جو ابلتا ہے، مثال کے طور پر، اس حقیقت کے لیے کہ ہم قطار میں کم سے کم بوجھ کے بارے میں معلومات کی بنیاد پر اگلی ہاپ کا انتخاب کرتے ہیں۔ مثال کے طور پر، دوسرے اختیارات ممکن ہیں۔
اس طرح، سمت دلچسپ ہے، لیکن افسوس، ہم اسے ابھی لاگو نہیں کر سکتے ہیں.
ٹھیک ہے، ہم Clos منطقی ٹوپولوجی پر طے پا گئے۔ ہم اس کی پیمائش کیسے کریں گے؟ آئیے دیکھتے ہیں کہ یہ کیسے کام کرتا ہے اور کیا کیا جا سکتا ہے۔
Clos نیٹ ورک میں دو اہم پیرامیٹرز ہیں جو ہم کسی نہ کسی طرح مختلف ہو سکتے ہیں اور کچھ نتائج حاصل کر سکتے ہیں: عناصر کا ریڈکس اور نیٹ ورک میں لیولز کی تعداد۔ میرے پاس اسکیمیٹک ڈایاگرام ہے کہ دونوں سائز کو کیسے متاثر کرتے ہیں۔ مثالی طور پر، ہم دونوں کو یکجا کرتے ہیں۔
یہ دیکھا جا سکتا ہے کہ Clos نیٹ ورک کی آخری چوڑائی جنوبی ریڈکس کے ریڑھ کی ہڈی کے سوئچ کی تمام سطحوں کی پیداوار ہے، ہمارے پاس کتنے لنکس ہیں، یہ کیسے شاخیں بناتا ہے۔ اس طرح ہم نیٹ ورک کا سائز پیمانہ کرتے ہیں۔
صلاحیت کے حوالے سے، خاص طور پر ٹی او آر سوئچز پر، اسکیلنگ کے دو اختیارات ہیں۔ یا تو ہم عام ٹوپولوجی کو برقرار رکھتے ہوئے، تیز روابط استعمال کر سکتے ہیں، یا ہم مزید طیارے شامل کر سکتے ہیں۔
اگر آپ Clos نیٹ ورک کے توسیع شدہ ورژن کو دیکھتے ہیں (نچلے دائیں کونے میں) اور نیچے Clos نیٹ ورک کے ساتھ اس تصویر پر واپس آتے ہیں...
... پھر یہ بالکل وہی ٹوپولوجی ہے، لیکن اس سلائیڈ پر یہ زیادہ مضبوطی سے گرا ہوا ہے اور فیکٹری کے طیارے ایک دوسرے پر لپٹے ہوئے ہیں۔ یہ ویسا ہی ہے.
Clos نیٹ ورک کو پیمانہ کرنا نمبروں میں کیسا لگتا ہے؟ یہاں میں ڈیٹا فراہم کرتا ہوں کہ نیٹ ورک کی زیادہ سے زیادہ چوڑائی کتنی حاصل کی جا سکتی ہے، ریک کی زیادہ سے زیادہ تعداد، ٹی او آر سوئچز یا لیف سوئچ، اگر وہ ریک میں نہیں ہیں، تو ہم اس بنیاد پر حاصل کر سکتے ہیں کہ ہم ریڑھ کی ہڈی کی سطح کے لیے کون سے سوئچز کا ریڈکس استعمال کرتے ہیں، اور ہم کتنی سطحیں استعمال کرتے ہیں۔
20 کلو واٹ فی ریک کی بنیاد پر ہمارے پاس کتنے ریک ہیں، کتنے سرورز اور تقریباً یہ سب کچھ کتنا استعمال کر سکتا ہے۔ تھوڑا پہلے میں نے ذکر کیا تھا کہ ہم تقریباً 100 ہزار سرورز کے کلسٹر سائز کا ہدف رکھتے ہیں۔
دیکھا جا سکتا ہے کہ اس پورے ڈیزائن میں ڈھائی آپشنز دلچسپی کے حامل ہیں۔ ریڑھ کی ہڈی کی دو تہوں اور 64-پورٹ سوئچز کے ساتھ ایک آپشن موجود ہے، جو تھوڑا سا چھوٹا پڑتا ہے۔ پھر 128-پورٹ (ریڈکس 128 کے ساتھ) ریڑھ کی ہڈی کے دو لیول والے سوئچز، یا ریڈکس 32 کے ساتھ تین لیول والے سوئچز کے لیے بالکل موزوں آپشنز ہیں۔ اور تمام صورتوں میں، جہاں زیادہ ریڈکسز اور زیادہ پرتیں ہیں، آپ ایک بہت بڑا نیٹ ورک بنا سکتے ہیں، لیکن اگر آپ متوقع کھپت کو دیکھیں تو عام طور پر گیگا واٹ ہوتے ہیں۔ ایک کیبل بچھانا ممکن ہے، لیکن ہمیں ایک جگہ پر اتنی بجلی ملنے کا امکان نہیں ہے۔ اگر آپ ڈیٹا سینٹرز کے اعدادوشمار اور عوامی ڈیٹا کو دیکھیں تو آپ کو 150 میگاواٹ سے زیادہ کی تخمینہ صلاحیت والے بہت کم ڈیٹا سینٹرز مل سکتے ہیں۔ بڑے عام طور پر ڈیٹا سینٹر کیمپس ہوتے ہیں، کئی بڑے ڈیٹا سینٹرز ایک دوسرے کے بالکل قریب واقع ہوتے ہیں۔
ایک اور اہم پیرامیٹر ہے۔ اگر آپ بائیں کالم کو دیکھیں تو وہاں قابل استعمال بینڈوتھ درج ہے۔ یہ دیکھنا آسان ہے کہ Clos نیٹ ورک میں بندرگاہوں کا ایک اہم حصہ سوئچ کو ایک دوسرے سے جوڑنے کے لیے استعمال ہوتا ہے۔ قابل استعمال بینڈوڈتھ، ایک مفید پٹی، ایسی چیز ہے جو سرورز کی طرف باہر دی جا سکتی ہے۔ قدرتی طور پر، میں مشروط بندرگاہوں اور خاص طور پر بینڈ کے بارے میں بات کر رہا ہوں۔ ایک اصول کے طور پر، نیٹ ورک کے اندر روابط سرورز کی طرف روابط سے زیادہ تیز ہوتے ہیں، لیکن فی یونٹ بینڈوڈتھ، جتنا ہم اسے اپنے سرور کے آلات پر بھیج سکتے ہیں، نیٹ ورک کے اندر ہی کچھ بینڈوتھ باقی ہے۔ اور ہم جتنی زیادہ سطحیں بنائیں گے، اس پٹی کو باہر فراہم کرنے کی مخصوص قیمت اتنی ہی زیادہ ہوگی۔
مزید یہ کہ یہ اضافی بینڈ بھی بالکل ایک جیسا نہیں ہے۔ جب کہ اسپین چھوٹے ہوتے ہیں، ہم DAC (ڈائریکٹ اٹیچ کاپر، یعنی ٹوینیکس کیبلز)، یا ملٹی موڈ آپٹکس جیسی کوئی چیز استعمال کر سکتے ہیں، جس کی قیمت اس سے بھی کم یا زیادہ معقول ہے۔ جیسے ہی ہم لمبے اسپین کی طرف جاتے ہیں - ایک اصول کے طور پر، یہ سنگل موڈ آپٹکس ہیں، اور اس اضافی بینڈوڈتھ کی قیمت نمایاں طور پر بڑھ جاتی ہے۔
اور ایک بار پھر، پچھلی سلائیڈ پر واپس آتے ہوئے، اگر ہم اوور سبسکرپشن کے بغیر Clos نیٹ ورک بناتے ہیں، تو ڈائیگرام کو دیکھنا آسان ہے، یہ دیکھنا کہ نیٹ ورک کس طرح بنتا ہے - ریڑھ کی ہڈی کے سوئچ کے ہر سطح کو شامل کرتے ہوئے، ہم پوری پٹی کو دہراتے ہیں جو نیچے پلس لیول - نیز وہی بینڈ، سوئچز پر اتنی ہی تعداد میں بندرگاہیں جو پچھلی سطح پر تھیں، اور اتنی ہی تعداد میں ٹرانسسیور۔ لہذا، ریڑھ کی ہڈی کے سوئچ کی سطحوں کی تعداد کو کم سے کم کرنا انتہائی ضروری ہے۔
اس تصویر کی بنیاد پر، یہ واضح ہے کہ ہم واقعی 128 کے ریڈکس کے ساتھ سوئچ جیسی چیز بنانا چاہتے ہیں۔
یہاں، اصولی طور پر، سب کچھ وہی ہے جو میں نے ابھی کہا؛ یہ بعد میں غور کے لیے ایک سلائیڈ ہے۔
وہاں کیا اختیارات ہیں جو ہم اس طرح کے سوئچ کے طور پر منتخب کر سکتے ہیں؟ ہمارے لیے یہ بہت خوشگوار خبر ہے کہ اب ایسے نیٹ ورکس آخر کار سنگل چپ سوئچز پر بنائے جا سکتے ہیں۔ اور یہ بہت عمدہ ہے، ان میں بہت ساری اچھی خصوصیات ہیں۔ مثال کے طور پر، ان کا تقریباً کوئی اندرونی ڈھانچہ نہیں ہے۔ اس کا مطلب ہے کہ وہ زیادہ آسانی سے ٹوٹ جاتے ہیں۔ وہ ہر طرح سے ٹوٹتے ہیں، لیکن خوش قسمتی سے وہ مکمل طور پر ٹوٹ جاتے ہیں۔ ماڈیولر ڈیوائسز میں بڑی تعداد میں خرابیاں ہوتی ہیں (بہت ناخوشگوار)، جب پڑوسیوں اور کنٹرول طیارے کے نقطہ نظر سے لگتا ہے کہ یہ کام کر رہا ہے، لیکن، مثال کے طور پر، کپڑے کا کچھ حصہ کھو گیا ہے اور یہ کام نہیں کر رہا ہے۔ پوری صلاحیت پر. اور اس کی طرف ٹریفک اس حقیقت کی بنیاد پر متوازن ہے کہ یہ مکمل طور پر فعال ہے، اور ہم اوورلوڈ ہو سکتے ہیں۔
یا، مثال کے طور پر، بیک پلین کے ساتھ مسائل پیدا ہوتے ہیں، کیونکہ ماڈیولر ڈیوائس کے اندر بھی تیز رفتار SerDes موجود ہیں - یہ واقعی اندر سے پیچیدہ ہے۔ یا تو فارورڈنگ عناصر کے درمیان اشارے مطابقت پذیر ہیں یا مطابقت پذیر نہیں ہیں۔ عام طور پر، کوئی بھی پیداواری ماڈیولر ڈیوائس جس میں عناصر کی ایک بڑی تعداد ہوتی ہے، اصول کے طور پر، اپنے اندر وہی Clos نیٹ ورک ہوتا ہے، لیکن اس کی تشخیص کرنا بہت مشکل ہوتا ہے۔ اکثر خود وینڈر کے لیے بھی تشخیص کرنا مشکل ہوتا ہے۔
اور اس میں ناکامی کے منظرناموں کی ایک بڑی تعداد ہے جس میں آلہ تنزلی کا شکار ہوتا ہے، لیکن مکمل طور پر ٹوپولوجی سے باہر نہیں آتا۔ چونکہ ہمارا نیٹ ورک بڑا ہے، ایک جیسے عناصر کے درمیان توازن کو فعال طور پر استعمال کیا جاتا ہے، نیٹ ورک بہت باقاعدہ ہے، یعنی ایک راستہ جس پر سب کچھ ترتیب میں ہے دوسرے راستے سے مختلف نہیں ہے، ہمارے لیے یہ زیادہ فائدہ مند ہے کہ ہم صرف کچھ چیزوں کو کھو دیں۔ ٹوپولوجی کے آلات ایسی صورت حال میں ختم ہونے کے بجائے جہاں ان میں سے کچھ کام کرنے لگتے ہیں، لیکن ان میں سے کچھ کام نہیں کرتے۔
سنگل چپ آلات کی اگلی اچھی خصوصیت یہ ہے کہ وہ بہتر اور تیزی سے تیار ہوتے ہیں۔ وہ بھی بہتر صلاحیت کے حامل ہوتے ہیں۔ اگر ہم ایک دائرے پر موجود بڑے اسمبلڈ ڈھانچے کو لیں، تو اسی رفتار کی بندرگاہوں کے لیے فی ریک یونٹ کی گنجائش ماڈیولر ڈیوائسز کے مقابلے میں تقریباً دگنی ہے۔ ایک چپ کے ارد گرد بنائے گئے آلات ماڈیولر کے مقابلے میں نمایاں طور پر سستے ہیں اور کم توانائی استعمال کرتے ہیں۔
لیکن، ظاہر ہے، یہ سب ایک وجہ سے ہے، اس کے نقصانات بھی ہیں۔ سب سے پہلے، ریڈکس ماڈیولر آلات کے مقابلے میں تقریبا ہمیشہ چھوٹا ہوتا ہے. اگر ہم 128 بندرگاہوں کے ساتھ ایک چپ کے ارد گرد ایک آلہ حاصل کر سکتے ہیں، تو ہم اب بغیر کسی پریشانی کے کئی سو بندرگاہوں کے ساتھ ایک ماڈیولر حاصل کر سکتے ہیں۔
یہ فارورڈنگ ٹیبلز کا نمایاں طور پر چھوٹا سائز ہے اور، ایک اصول کے طور پر، ڈیٹا پلین اسکیل ایبلٹی سے متعلق ہر چیز۔ اتلی بفرز۔ اور، ایک اصول کے طور پر، بلکہ محدود فعالیت. لیکن یہ پتہ چلتا ہے کہ اگر آپ ان پابندیوں کو جانتے ہیں اور ان کو روکنے کے لئے وقت پر خیال رکھتے ہیں یا صرف ان کو مدنظر رکھتے ہیں، تو یہ اتنا خوفناک نہیں ہے۔ حقیقت یہ ہے کہ ریڈکس چھوٹا ہے 128 کے ریڈکس والے آلات پر اب کوئی مسئلہ نہیں ہے جو آخر کار حال ہی میں ظاہر ہوا ہے؛ ہم ریڑھ کی ہڈی کی دو تہوں میں بنا سکتے ہیں۔ لیکن دو سے چھوٹی کوئی بھی چیز بنانا اب بھی ناممکن ہے جو ہمارے لیے دلچسپ ہو۔ ایک سطح کے ساتھ، بہت چھوٹے کلسٹرز حاصل کیے جاتے ہیں۔ یہاں تک کہ ہمارے سابقہ ڈیزائن اور تقاضے اب بھی ان سے زیادہ ہیں۔
درحقیقت، اگر اچانک حل کہیں دہانے پر ہے، تو پیمانے کا ایک طریقہ باقی ہے۔ چونکہ آخری (یا پہلی)، سب سے نچلی سطح جہاں سرورز جڑے ہوئے ہیں وہ ٹو آر سوئچز یا لیف سوئچز ہیں، ہمیں ان سے ایک ریک جوڑنے کی ضرورت نہیں ہے۔ اس لیے، اگر حل تقریباً نصف تک کم ہو جاتا ہے، تو آپ نچلی سطح پر ایک بڑے ریڈکس والے سوئچ کو استعمال کرنے اور جڑنے کے بارے میں سوچ سکتے ہیں، مثال کے طور پر، ایک سوئچ میں دو یا تین ریک۔ یہ بھی ایک آپشن ہے، اس کی قیمتیں ہیں، لیکن یہ کافی اچھی طرح سے کام کرتا ہے اور جب آپ کو سائز سے دوگنا تک پہنچنے کی ضرورت ہو تو یہ ایک اچھا حل ہو سکتا ہے۔
خلاصہ کرنے کے لیے، ہم ریڑھ کی ہڈی کی دو سطحوں کے ساتھ ایک ٹوپولوجی پر تعمیر کر رہے ہیں، آٹھ فیکٹری تہوں کے ساتھ۔
فزکس کا کیا ہوگا؟ بہت آسان حساب۔ اگر ہمارے پاس ریڑھ کی ہڈی کی دو سطحیں ہیں، تو ہمارے پاس سوئچ کے صرف تین درجے ہیں، اور ہم توقع کرتے ہیں کہ نیٹ ورک میں تین کیبل سیگمنٹ ہوں گے: سرورز سے لیف سوئچ تک، ریڑھ کی ہڈی 1 تک، ریڑھ کی ہڈی تک 2۔ وہ اختیارات جو ہم کر سکتے ہیں۔ استعمال ہیں - یہ ٹوینیکس، ملٹی موڈ، سنگل موڈ ہیں۔ اور یہاں ہمیں اس بات پر غور کرنے کی ضرورت ہے کہ کون سی پٹی دستیاب ہے، اس کی قیمت کتنی ہو گی، جسمانی طول و عرض کیا ہیں، ہم کن اسپین کو کور کر سکتے ہیں، اور ہم کس طرح اپ گریڈ کریں گے۔
لاگت کے لحاظ سے، سب کچھ لائن میں کیا جا سکتا ہے. Twinaxes ایکٹو آپٹکس کے مقابلے میں نمایاں طور پر سستے ہیں، ملٹی موڈ ٹرانسیور سے سستے ہیں، اگر آپ اسے آخر سے فی پرواز لیتے ہیں، تو 100 گیگا بٹ سوئچ پورٹ سے کچھ سستا ہے۔ اور، براہ کرم نوٹ کریں، اس کی لاگت سنگل موڈ آپٹکس سے کم ہے، کیونکہ پروازوں پر جہاں سنگل موڈ کی ضرورت ہوتی ہے، ڈیٹا سینٹرز میں کئی وجوہات کی بناء پر CWDM استعمال کرنا سمجھ میں آتا ہے، جبکہ متوازی سنگل موڈ (PSM) کام کرنے کے لیے زیادہ آسان نہیں ہے۔ کے ساتھ، بہت بڑے پیک فائبرز حاصل کیے جاتے ہیں، اور اگر ہم ان ٹیکنالوجیز پر توجہ مرکوز کرتے ہیں، تو ہمیں تقریباً درج ذیل قیمت کا درجہ بندی حاصل ہوتی ہے۔
ایک اور نوٹ: بدقسمتی سے، جداگانہ 100 سے 4x25 ملٹی موڈ پورٹس استعمال کرنا بہت ممکن نہیں ہے۔ SFP28 ٹرانسیور کی ڈیزائن خصوصیات کی وجہ سے، یہ 28 Gbit QSFP100 سے زیادہ سستا نہیں ہے۔ اور ملٹی موڈ کے لئے یہ جدا کرنا بہت اچھی طرح سے کام نہیں کرتا ہے۔
ایک اور حد یہ ہے کہ کمپیوٹنگ کلسٹرز کے سائز اور سرورز کی تعداد کی وجہ سے، ہمارے ڈیٹا سینٹرز جسمانی طور پر بڑے ہوتے ہیں۔ اس کا مطلب یہ ہے کہ کم از کم ایک فلائٹ سنگل موڈ کے ساتھ کرنی ہوگی۔ ایک بار پھر، Pods کے جسمانی سائز کی وجہ سے، ٹوئنیکس (تانبے کی تاروں) کے دو اسپین کو چلانا ممکن نہیں ہوگا۔
نتیجے کے طور پر، اگر ہم قیمت کو بہتر بناتے ہیں اور اس ڈیزائن کی جیومیٹری کو مدنظر رکھتے ہیں، تو ہمیں CWDM کا استعمال کرتے ہوئے ٹوئنیکس کا ایک اسپین، ملٹی موڈ کا ایک اسپین اور سنگل موڈ کا ایک اسپین ملتا ہے۔ یہ ممکنہ اپ گریڈ کے راستوں کو مدنظر رکھتا ہے۔
حال ہی میں ایسا لگتا ہے کہ ہم کہاں جا رہے ہیں اور کیا ممکن ہے۔ یہ واضح ہے، کم از کم، ملٹی موڈ اور سنگل موڈ دونوں کے لیے 50-گیگابٹ SerDes کی طرف کیسے جانا ہے۔ مزید برآں، اگر آپ دیکھیں کہ 400G کے لیے اب اور مستقبل میں سنگل موڈ ٹرانسیور میں کیا ہے، اکثر یہاں تک کہ جب 50G SerDes الیکٹریکل سائیڈ سے آتے ہیں، 100 Gbps فی لین پہلے ہی آپٹکس میں جا سکتے ہیں۔ اس لیے، یہ بالکل ممکن ہے کہ 50 پر جانے کے بجائے، 100 گیگابٹ SerDes اور 100 Gbps فی لین میں منتقل ہو جائے، کیونکہ بہت سے دکانداروں کے وعدوں کے مطابق، ان کی دستیابی بہت جلد متوقع ہے۔ وہ مدت جب 50G SerDes سب سے تیز تھے، ایسا لگتا ہے، زیادہ لمبا نہیں ہوگا، کیونکہ 100G SerDes کی پہلی کاپیاں تقریباً اگلے سال آ رہی ہیں۔ اور اس کے بعد کچھ عرصے بعد وہ شاید معقول رقم کے قابل ہو جائیں گے۔
طبیعیات کے انتخاب کے بارے میں ایک اور اہمیت۔ اصولی طور پر، ہم پہلے ہی 400G SerDes کا استعمال کرتے ہوئے 200 یا 50 گیگابٹ بندرگاہیں استعمال کر سکتے ہیں۔ لیکن یہ پتہ چلتا ہے کہ یہ زیادہ معنی نہیں رکھتا ہے، کیونکہ، جیسا کہ میں نے پہلے کہا، ہم سوئچز پر کافی بڑا ریڈکس چاہتے ہیں، یقینا وجہ کے اندر۔ ہم 128 چاہتے ہیں۔ اور اگر ہمارے پاس چپ کی صلاحیت محدود ہے اور ہم لنک کی رفتار بڑھاتے ہیں، تو ریڈکس قدرتی طور پر کم ہو جاتا ہے، کوئی معجزہ نہیں ہوتا۔
اور ہم طیاروں کا استعمال کرتے ہوئے کل صلاحیت کو بڑھا سکتے ہیں، اور کوئی خاص لاگت نہیں ہے؛ ہم طیاروں کی تعداد میں اضافہ کر سکتے ہیں۔ اور اگر ہم ریڈکس کھو دیتے ہیں، تو ہمیں ایک اضافی لیول متعارف کرانا پڑے گا، اس لیے موجودہ صورتحال میں، فی چپ موجودہ زیادہ سے زیادہ دستیاب صلاحیت کے ساتھ، یہ پتہ چلتا ہے کہ 100 گیگا بٹ بندرگاہوں کو استعمال کرنا زیادہ موثر ہے، کیونکہ وہ آپ کو اجازت دیتے ہیں۔ ایک بڑا ریڈکس حاصل کرنے کے لیے۔
اگلا سوال یہ ہے کہ فزکس کو کس طرح منظم کیا جاتا ہے، لیکن کیبل انفراسٹرکچر کے نقطہ نظر سے۔ یہ ایک مضحکہ خیز انداز میں منظم کیا جاتا ہے کہ باہر کر دیتا ہے. لیف سوئچز اور فرسٹ لیول اسپائنز کے درمیان کیبلنگ - وہاں بہت سے لنکس نہیں ہیں، ہر چیز نسبتاً سادہ بنائی گئی ہے۔ لیکن اگر ہم ایک طیارہ لیں تو اندر کیا ہوتا ہے کہ ہمیں پہلی سطح کی تمام ریڑھ کی ہڈیوں کو دوسرے درجے کی تمام ریڑھ کی ہڈیوں سے جوڑنے کی ضرورت ہے۔
اس کے علاوہ، ایک اصول کے طور پر، کچھ خواہشات ہیں کہ اسے ڈیٹا سینٹر کے اندر کیسا نظر آنا چاہیے۔ مثال کے طور پر، ہم واقعی کیبلز کو ایک بنڈل میں جوڑنا چاہتے تھے اور انہیں کھینچنا چاہتے تھے تاکہ ایک اعلی کثافت والا پیچ پینل مکمل طور پر ایک پیچ پینل میں چلا جائے، تاکہ لمبائی کے لحاظ سے کوئی چڑیا گھر نہ ہو۔ ہم اس مسئلے کو حل کرنے میں کامیاب ہوگئے۔ اگر آپ ابتدائی طور پر منطقی ٹوپولوجی پر نظر ڈالیں تو آپ دیکھ سکتے ہیں کہ ہوائی جہاز خود مختار ہیں، ہر طیارہ اپنے طور پر بنایا جا سکتا ہے۔ لیکن جب ہم اس طرح کے بنڈل کو جوڑتے ہیں اور پورے پیچ پینل کو ایک پیچ پینل میں گھسیٹنا چاہتے ہیں، تو ہمیں ایک بنڈل کے اندر مختلف طیاروں کو ملانا پڑتا ہے اور آپٹیکل کراس کنکشن کی شکل میں ایک درمیانی ڈھانچہ متعارف کرانا پڑتا ہے تاکہ انہیں دوبارہ پیک کیا جا سکے۔ ایک سیگمنٹ پر، دوسرے سیگمنٹ پر انہیں کیسے جمع کیا جائے گا۔ اس کا شکریہ، ہمیں ایک اچھی خصوصیت ملتی ہے: تمام پیچیدہ سوئچنگ ریک سے آگے نہیں جاتی ہے۔ جب آپ کو کسی چیز کو بہت مضبوطی سے جوڑنے کی ضرورت ہوتی ہے، "طیاروں کو کھولیں"، جیسا کہ اسے کبھی کبھی Clos نیٹ ورکس میں کہا جاتا ہے، یہ سب ایک ریک کے اندر مرتکز ہوتا ہے۔ ہمارے پاس ریکوں کے درمیان سوئچنگ، انفرادی روابط تک، انتہائی جدا جدا نہیں ہے۔
کیبل کے بنیادی ڈھانچے کی منطقی تنظیم کے نقطہ نظر سے یہ اس طرح نظر آتا ہے۔ بائیں طرف کی تصویر میں، کثیر رنگ کے بلاکس پہلے درجے کی ریڑھ کی ہڈی کے سوئچ کے بلاکس، ہر ایک میں آٹھ ٹکڑے، اور ان سے آنے والی کیبلز کے چار بنڈل دکھاتے ہیں، جو جا کر ریڑھ کی ہڈی کے سوئچز کے بلاکس سے آنے والے بنڈلوں سے جڑ جاتے ہیں۔ .
چھوٹے چوکور چوراہوں کی نشاندہی کرتے ہیں۔ اوپر بائیں جانب ایسے ہر ایک چوراہے کا ٹوٹنا ہے، یہ دراصل ایک 512 بائی 512 پورٹ کراس کنیکٹ ماڈیول ہے جو کیبلز کو دوبارہ پیک کرتا ہے تاکہ وہ مکمل طور پر ایک ریک میں آجائیں، جہاں صرف ایک سپائن-2 طیارہ ہے۔ اور دائیں طرف، اس تصویر کا اسکین کچھ زیادہ تفصیل سے ہے جو کہ ریڑھ کی ہڈی کی سطح پر کئی پوڈز کے حوالے سے ہے، اور اسے کراس کنیکٹ میں کیسے پیک کیا جاتا ہے، یہ اسپائن-1 کی سطح پر کیسے آتا ہے۔
یہ ایسا ہی لگتا ہے۔ ابھی تک مکمل طور پر جمع نہ ہونے والا اسپائن-2 اسٹینڈ (بائیں طرف) اور کراس کنیکٹ اسٹینڈ۔ بدقسمتی سے، وہاں دیکھنے کے لیے بہت کچھ نہیں ہے۔ یہ پورا ڈھانچہ ابھی ہمارے ایک بڑے ڈیٹا سینٹرز میں تعینات کیا جا رہا ہے جسے بڑھایا جا رہا ہے۔ یہ کام جاری ہے، یہ اچھا لگے گا، اسے بہتر طریقے سے بھرا جائے گا۔
ایک اہم سوال: ہم نے منطقی ٹوپولوجی کا انتخاب کیا اور فزکس بنایا۔ کنٹرول طیارے کا کیا ہوگا؟ یہ آپریٹنگ تجربے سے بہت اچھی طرح سے جانا جاتا ہے، ایسی متعدد رپورٹس ہیں کہ لنک اسٹیٹ پروٹوکول اچھے ہیں، ان کے ساتھ کام کرنا خوشی کی بات ہے، لیکن، بدقسمتی سے، وہ ایک گھنے جڑے ہوئے ٹوپولوجی پر اچھی طرح سے پیمائش نہیں کرتے ہیں۔ اور ایک اہم عنصر ہے جو اس کو روکتا ہے - لنک اسٹیٹ پروٹوکول میں سیلاب اس طرح کام کرتا ہے۔ اگر آپ صرف فلڈنگ الگورتھم لیں اور دیکھیں کہ ہمارے نیٹ ورک کی ساخت کس طرح ہے، آپ دیکھ سکتے ہیں کہ ہر قدم پر ایک بہت بڑا فین آؤٹ ہوگا، اور یہ اپ ڈیٹس کے ساتھ کنٹرول طیارے کو آسانی سے سیلاب کر دے گا۔ خاص طور پر، ایسی ٹوپولاجیاں لنک اسٹیٹ پروٹوکول میں روایتی فلڈنگ الگورتھم کے ساتھ بہت خراب طریقے سے گھل مل جاتی ہیں۔
انتخاب BGP استعمال کرنا ہے۔ اسے صحیح طریقے سے تیار کرنے کا طریقہ RFC 7938 میں بڑے ڈیٹا سینٹرز میں BGP کے استعمال کے بارے میں بیان کیا گیا ہے۔ بنیادی آئیڈیاز سادہ ہیں: فی میزبان کم از کم سابقے کی تعداد اور نیٹ ورک پر عام طور پر کم از کم سابقے کی تعداد، اگر ممکن ہو تو جمع کا استعمال کریں، اور پاتھ ہنٹنگ کو دبا دیں۔ ہم اپ ڈیٹس کی بہت محتاط، بہت کنٹرول شدہ تقسیم چاہتے ہیں، جسے ویلی فری کہا جاتا ہے۔ ہم چاہتے ہیں کہ اپ ڈیٹس کو نیٹ ورک سے گزرتے ہی ایک بار تعینات کیا جائے۔ اگر وہ نیچے سے نکلتے ہیں، تو وہ اوپر جاتے ہیں، ایک بار سے زیادہ نہیں کھلتے۔ کوئی zigzags نہیں ہونا چاہئے. زگ زیگ بہت خراب ہیں۔
ایسا کرنے کے لیے، ہم ایک ایسا ڈیزائن استعمال کرتے ہیں جو کہ بنیادی BGP میکانزم کو استعمال کرنے کے لیے کافی آسان ہے۔ یعنی، ہم لنک لوکل پر چلنے والے ای بی جی پی کا استعمال کرتے ہیں، اور خود مختار نظام کو اس طرح تفویض کیا گیا ہے: ٹی او آر پر ایک خود مختار نظام، ایک پوڈ کے اسپائن-1 سوئچ کے پورے بلاک پر ایک خودمختار نظام، اور پورے ٹاپ پر ایک عام خود مختار نظام۔ کپڑے کی. یہ دیکھنا اور دیکھنا مشکل نہیں ہے کہ یہاں تک کہ BGP کا نارمل رویہ ہمیں اپ ڈیٹس کی تقسیم فراہم کرتا ہے جو ہم چاہتے ہیں۔
قدرتی طور پر، ایڈریسنگ اور ایڈریس ایگریگیشن کو اس طرح ڈیزائن کرنا ہوتا ہے کہ یہ روٹنگ کے بنائے جانے کے طریقے سے مطابقت رکھتا ہو، تاکہ یہ کنٹرول جہاز کے استحکام کو یقینی بنائے۔ ٹرانسپورٹ میں L3 ایڈریسنگ ٹوپولوجی سے منسلک ہے، کیونکہ اس کے بغیر جمع کرنا ناممکن ہے؛ اس کے بغیر، انفرادی ایڈریس روٹنگ سسٹم میں داخل ہو جائیں گے۔ اور ایک اور بات یہ ہے کہ ایگریگیشن، بدقسمتی سے، ملٹی پاتھ کے ساتھ بہت اچھی طرح سے نہیں ملتی، کیونکہ جب ہمارے پاس ملٹی پاتھ ہوتا ہے اور ہمارے پاس ایگریگیشن ہوتا ہے تو سب کچھ ٹھیک ہوتا ہے، جب پورا نیٹ ورک صحت مند ہوتا ہے، اس میں کوئی ناکامی نہیں ہوتی۔ بدقسمتی سے، جیسے ہی نیٹ ورک میں ناکامیاں ظاہر ہوتی ہیں اور ٹوپولوجی کی ہم آہنگی ختم ہو جاتی ہے، ہم اس مقام پر پہنچ سکتے ہیں جہاں سے یونٹ کا اعلان کیا گیا تھا، جہاں سے ہم مزید وہاں نہیں جا سکتے جہاں ہمیں جانا ہے۔ لہٰذا، جہاں مزید ملٹی پاتھ نہیں ہے وہاں جمع کرنا بہتر ہے، ہمارے معاملے میں یہ ٹو آر سوئچز ہیں۔
اصل میں، یہ مجموعی طور پر ممکن ہے، لیکن احتیاط سے. اگر ہم نیٹ ورک کی ناکامی ہونے پر کنٹرول شدہ تفریق کر سکتے ہیں۔ لیکن یہ کافی مشکل کام ہے، ہم نے یہاں تک سوچا کہ کیا ایسا کرنا ممکن ہے، کیا اضافی آٹومیشن شامل کرنا ممکن ہے، اور محدود ریاستی مشینیں جو مطلوبہ رویہ حاصل کرنے کے لیے BGP کو صحیح طریقے سے کِک کریں گی۔ بدقسمتی سے، کارنر کیسز کی پروسیسنگ بہت غیر واضح اور پیچیدہ ہے، اور یہ کام BGP کے ساتھ بیرونی اٹیچمنٹ منسلک کرنے سے حل نہیں ہوتا ہے۔
اس سلسلے میں بہت دلچسپ کام RIFT پروٹوکول کے فریم ورک کے اندر کیا گیا ہے، جس پر اگلی رپورٹ میں بات کی جائے گی۔
ایک اور اہم بات یہ ہے کہ ڈیٹا پلینز گھنے ٹوپولاجیز میں کیسے پیمانہ کرتے ہیں، جہاں ہمارے پاس متبادل راستے کی ایک بڑی تعداد ہے۔ اس صورت میں، کئی اضافی ڈیٹا ڈھانچے استعمال کیے جاتے ہیں: ECMP گروپس، جو بدلے میں نیکسٹ ہاپ گروپس کی وضاحت کرتے ہیں۔
عام طور پر کام کرنے والے نیٹ ورک میں، ناکامیوں کے بغیر، جب ہم Clos ٹوپولوجی کو اوپر جاتے ہیں، تو صرف ایک گروپ کا استعمال کرنا کافی ہوتا ہے، کیونکہ ہر وہ چیز جو مقامی نہیں ہوتی ہے، پہلے سے طے شدہ طور پر بیان کی جاتی ہے، ہم اوپر جا سکتے ہیں۔ جب ہم اوپر سے نیچے جنوب کی طرف جاتے ہیں، تو تمام راستے ECMP نہیں ہوتے، وہ سنگل پاتھ پاتھ ہوتے ہیں۔ سب کچھ ٹھیک ہے. مصیبت یہ ہے، اور کلاسک کلوس ٹوپولوجی کی خاصیت یہ ہے کہ اگر ہم ٹاپ آف فیبرک کو دیکھیں، کسی بھی عنصر پر، نیچے کسی بھی عنصر کے لیے صرف ایک راستہ ہے۔ اگر اس راستے میں ناکامیاں واقع ہوتی ہیں، تو فیکٹری کے اوپری حصے میں یہ خاص عنصر ان سابقوں کے لیے بالکل غلط ہو جاتا ہے جو ٹوٹے ہوئے راستے کے پیچھے ہوتے ہیں۔ لیکن باقی کے لیے یہ درست ہے، اور ہمیں ECMP گروپس کو پارس کرنا ہوگا اور ایک نئی ریاست متعارف کرانی ہوگی۔
جدید آلات پر ڈیٹا پلین اسکیل ایبلٹی کیسی نظر آتی ہے؟ اگر ہم LPM (سب سے لمبا سابقہ میچ) کرتے ہیں، تو سب کچھ بہت اچھا ہے، 100k سے زیادہ سابقے ہیں۔ اگر ہم نیکسٹ ہاپ گروپس کے بارے میں بات کر رہے ہیں، تو سب کچھ بدتر ہے، 2-4 ہزار۔ اگر ہم ایک ٹیبل کے بارے میں بات کر رہے ہیں جس میں نیکسٹ ہاپس (یا ملحقہ) کی تفصیل ہے تو یہ 16k سے 64k تک ہے۔ اور یہ ایک مسئلہ بن سکتا ہے۔ اور یہاں ہم ایک دلچسپ اختلاف کی طرف آتے ہیں: ڈیٹا سینٹرز میں MPLS کا کیا ہوا؟ اصولی طور پر، ہم یہ کرنا چاہتے تھے۔
دو باتیں ہوئیں۔ ہم نے میزبانوں پر مائیکرو سیگمنٹیشن کیا؛ ہمیں اب اسے نیٹ ورک پر کرنے کی ضرورت نہیں رہی۔ یہ مختلف دکانداروں کی حمایت کے ساتھ بہت اچھا نہیں تھا، اور اس سے بھی زیادہ MPLS کے ساتھ سفید بکسوں پر کھلے نفاذ کے ساتھ۔ اور MPLS، کم از کم اس کے روایتی نفاذ، بدقسمتی سے، ECMP کے ساتھ بہت خراب طریقے سے جوڑتا ہے۔ اور اسی لیے۔
آئی پی کے لیے ECMP فارورڈنگ ڈھانچہ ایسا لگتا ہے۔ سابقے کی ایک بڑی تعداد ایک ہی گروپ اور ایک ہی نیکسٹ ہاپس بلاک (یا ملحقہ، مختلف آلات کے لیے مختلف دستاویزات میں اسے مختلف طریقے سے کہا جا سکتا ہے) استعمال کر سکتے ہیں۔ نکتہ یہ ہے کہ اسے آؤٹ گوئنگ پورٹ کے طور پر بیان کیا گیا ہے اور درست نیکسٹ ہاپ پر جانے کے لیے میک ایڈریس کو کیا لکھنا ہے۔ آئی پی کے لیے سب کچھ آسان نظر آتا ہے، آپ ایک ہی گروپ، وہی نیکسٹ ہاپس بلاک کے لیے بہت بڑی تعداد میں سابقے استعمال کر سکتے ہیں۔
کلاسک MPLS فن تعمیر کا مطلب یہ ہے کہ باہر جانے والے انٹرفیس پر منحصر ہے، لیبل کو مختلف اقدار پر دوبارہ لکھا جا سکتا ہے۔ لہذا، ہمیں ہر ان پٹ لیبل کے لیے ایک گروپ اور ایک نیکسٹ ہاپس بلاک رکھنے کی ضرورت ہے۔ اور یہ، افسوس، پیمانہ نہیں ہے.
یہ دیکھنا آسان ہے کہ ہمارے ڈیزائن میں ہمیں تقریباً 4000 TOR سوئچز کی ضرورت تھی، زیادہ سے زیادہ چوڑائی 64 ECMP راستوں کی تھی، اگر ہم اسپائن-1 سے ہٹ کر اسپائن-2 کی طرف جاتے ہیں۔ ہم بمشکل ECMP گروپس کے ایک ٹیبل میں داخل ہوتے ہیں، اگر ToR کے ساتھ صرف ایک سابقہ ختم ہوجاتا ہے، اور ہم نیکسٹ ہاپس ٹیبل میں بالکل نہیں آتے۔
یہ سب نا امید نہیں ہے، کیونکہ سیگمنٹ روٹنگ جیسے فن تعمیر میں عالمی لیبل شامل ہوتے ہیں۔ رسمی طور پر، ان تمام نیکسٹ ہاپس بلاکس کو دوبارہ گرانا ممکن ہوگا۔ ایسا کرنے کے لیے، آپ کو وائلڈ کارڈ کی قسم کے آپریشن کی ضرورت ہے: ایک لیبل لیں اور بغیر کسی خاص قدر کے اسی پر دوبارہ لکھیں۔ لیکن بدقسمتی سے، یہ دستیاب نفاذ میں بہت زیادہ موجود نہیں ہے۔
اور آخر میں، ہمیں ڈیٹا سینٹر میں بیرونی ٹریفک لانے کی ضرورت ہے۔ یہ کیسے کرنا ہے؟ پہلے، ٹریفک کو Clos نیٹ ورک میں اوپر سے متعارف کرایا گیا تھا۔ یعنی، ایسے ایج روٹرز تھے جو کپڑے کے اوپری حصے میں موجود تمام آلات سے جڑے ہوئے تھے۔ یہ حل چھوٹے سے درمیانے سائز پر کافی اچھا کام کرتا ہے۔ بدقسمتی سے، اس طرح پورے نیٹ ورک پر ٹریفک کو متوازی طور پر بھیجنے کے لیے، ہمیں ٹاپ آف فیبرک کے تمام عناصر پر بیک وقت پہنچنے کی ضرورت ہے، اور جب ان میں سے سو سے زیادہ ہوں، تو پتہ چلتا ہے کہ ہمیں ایک بڑے کنارے راؤٹرز پر ریڈکس۔ عام طور پر، یہ پیسہ خرچ کرتا ہے، کیونکہ کنارے روٹر زیادہ فعال ہیں، ان پر بندرگاہیں زیادہ مہنگی ہوں گی، اور ڈیزائن بہت خوبصورت نہیں ہے.
دوسرا آپشن یہ ہے کہ اس طرح کی ٹریفک کو نیچے سے شروع کیا جائے۔ اس بات کی تصدیق کرنا آسان ہے کہ Clos ٹوپولوجی کو اس طرح بنایا گیا ہے کہ نیچے سے آنے والی ٹریفک، یعنی ToR کی طرف سے، پورے نیٹ ورک کو لوڈ کرتے ہوئے، پورے ٹاپ آف فیبرک میں دو تکرار میں یکساں طور پر تقسیم ہو جاتی ہے۔ لہذا، ہم ایک خاص قسم کی Pod، Edge Pod متعارف کراتے ہیں، جو بیرونی رابطہ فراہم کرتا ہے۔
ایک اور آپشن ہے۔ مثال کے طور پر فیس بک یہی کرتا ہے۔ وہ اسے فیبرک ایگریگیٹر یا HGRID کہتے ہیں۔ متعدد ڈیٹا سینٹرز کو جوڑنے کے لیے ریڑھ کی ہڈی کی ایک اضافی سطح متعارف کرائی جا رہی ہے۔ یہ ڈیزائن ممکن ہے اگر ہمارے پاس انٹرفیس میں اضافی افعال یا انکیپسولیشن تبدیلیاں نہ ہوں۔ اگر وہ اضافی ٹچ پوائنٹس ہیں، تو یہ مشکل ہے۔ عام طور پر، ڈیٹا سینٹر کے مختلف حصوں کو الگ کرنے کے لیے مزید افعال اور ایک قسم کی جھلی ہوتی ہے۔ اس طرح کی جھلی کو بڑا بنانے کا کوئی فائدہ نہیں، لیکن اگر کسی وجہ سے اس کی واقعی ضرورت ہو، تو اسے لے جانے کے امکان پر غور کرنا، اسے زیادہ سے زیادہ چوڑا بنانے اور میزبانوں کو منتقل کرنے کا مطلب ہے۔ یہ بہت سے کلاؤڈ آپریٹرز کے ذریعہ کیا جاتا ہے، مثال کے طور پر۔ ان کے اوورلیز ہیں، وہ میزبانوں سے شروع ہوتے ہیں۔
ہم ترقی کے کیا مواقع دیکھتے ہیں؟ سب سے پہلے، CI/CD پائپ لائن کے لیے سپورٹ کو بہتر بنانا۔ ہم جس طرح سے اڑنا چاہتے ہیں اسی طرح ہم آزماتے ہیں اور جس طرح سے ہم اڑتے ہیں اس کی جانچ کرنا چاہتے ہیں۔ یہ بہت اچھی طرح سے کام نہیں کرتا ہے، کیونکہ بنیادی ڈھانچہ بڑا ہے اور اسے ٹیسٹ کے لیے نقل کرنا ناممکن ہے۔ آپ کو یہ سمجھنے کی ضرورت ہے کہ پروڈکشن انفراسٹرکچر میں ٹیسٹنگ عناصر کو چھوڑے بغیر کیسے متعارف کرایا جائے۔
بہتر آلات اور بہتر نگرانی تقریباً کبھی ضرورت سے زیادہ نہیں ہوتی۔ سارا سوال کوشش اور واپسی کا توازن ہے۔ اگر آپ اسے معقول کوشش کے ساتھ شامل کر سکتے ہیں تو بہت اچھا ہے۔
نیٹ ورک ڈیوائسز کے لیے آپریٹنگ سسٹم کھولیں۔ بہتر پروٹوکول اور بہتر روٹنگ سسٹم، جیسے RIFT۔ بھیڑ کو کنٹرول کرنے کی بہتر اسکیموں کے استعمال میں تحقیق کی بھی ضرورت ہے اور شاید تعارف، کم از کم کچھ مقامات پر، کلسٹر کے اندر آر ڈی ایم اے سپورٹ کا۔
مستقبل کو مزید دیکھتے ہوئے، ہمیں جدید ٹوپولاجیز اور ممکنہ طور پر ایسے نیٹ ورکس کی ضرورت ہے جو کم اوور ہیڈ استعمال کرتے ہوں۔ تازہ چیزوں میں سے، حال ہی میں HPC Cray Slingshot کے لیے فیبرک ٹیکنالوجی کے بارے میں اشاعتیں ہوئی ہیں، جو کہ کموڈٹی ایتھرنیٹ پر مبنی ہے، لیکن اس میں بہت چھوٹے ہیڈر استعمال کرنے کا اختیار ہے۔ نتیجے کے طور پر، اوور ہیڈ کم ہو جاتا ہے.
ہر چیز کو ہر ممکن حد تک آسان رکھنا چاہئے، لیکن آسان نہیں۔ پیچیدگی توسیع پذیری کی دشمن ہے۔ سادگی اور باقاعدہ ڈھانچہ ہمارے دوست ہیں۔ اگر آپ کہیں سکیل آؤٹ کر سکتے ہیں تو کر لیں۔ اور عام طور پر، اب نیٹ ورک ٹیکنالوجیز میں شامل ہونا بہت اچھا ہے۔ بہت ساری دلچسپ چیزیں چل رہی ہیں۔ شکریہ
ماخذ: www.habr.com