جدید ڈیٹا سینٹرز میں سیکڑوں فعال آلات نصب ہیں، جن کا احاطہ مختلف قسم کی نگرانی سے کیا جاتا ہے۔ لیکن یہاں تک کہ ایک مثالی انجینئر بھی ہاتھ میں کامل نگرانی کے ساتھ صرف چند منٹوں میں نیٹ ورک کی ناکامی کا صحیح جواب دے سکے گا۔ نیکسٹ ہاپ 2020 کانفرنس کی ایک رپورٹ میں، میں نے ڈی سی نیٹ ورک ڈیزائن کا طریقہ کار پیش کیا، جس میں ایک منفرد خصوصیت ہے - ڈیٹا سینٹر خود کو ملی سیکنڈ میں ٹھیک کرتا ہے۔ مزید واضح طور پر، انجینئر سکون سے مسئلہ کو حل کرتا ہے، جبکہ خدمات صرف اس پر توجہ نہیں دیتی ہیں۔
بہت سے نیٹ ورک انجینئرز کے لیے، ڈیٹا سینٹر نیٹ ورک شروع ہوتا ہے، یقیناً، ٹو آر کے ساتھ، ریک میں ایک سوئچ کے ساتھ۔ ٹی او آر میں عام طور پر دو قسم کے لنک ہوتے ہیں۔ چھوٹے سرورز پر جاتے ہیں، دوسرے - ان میں سے N گنا زیادہ ہیں - پہلے درجے کی ریڑھ کی ہڈی کی طرف، یعنی اس کے اپ لنکس کی طرف جاتے ہیں۔ اپ لنکس کو عام طور پر برابر سمجھا جاتا ہے، اور اپ لنکس کے درمیان ٹریفک 5-ٹپل سے ہیش کی بنیاد پر متوازن ہے، جس میں پروٹو، src_ip، dst_ip، src_port، dst_port شامل ہیں۔ یہاں کوئی حیرت نہیں ہے۔
اگلا، پلان فن تعمیر کیسا لگتا ہے؟ پہلی سطح کی ریڑھ کی ہڈی ایک دوسرے سے جڑی نہیں ہوتی بلکہ سپر اسپائنز کے ذریعے جڑی ہوتی ہے۔ خط X سپر اسپائنز کے لیے ذمہ دار ہوگا؛ یہ تقریباً ایک کراس کنیکٹ کی طرح ہے۔
اور یہ واضح ہے کہ، دوسری طرف، ٹوری پہلی سطح کے تمام ریڑھ کی ہڈیوں سے جڑے ہوئے ہیں۔ اس تصویر میں کیا اہم ہے؟ اگر ہمارا ریک کے اندر تعامل ہوتا ہے، تو بات چیت، یقیناً، ToR سے ہوتی ہے۔ اگر تعامل ماڈیول کے اندر ہوتا ہے، تو تعامل پہلی سطح کی ریڑھ کی ہڈی کے ذریعے ہوتا ہے۔ اگر تعامل انٹر موڈیولر ہے - جیسا کہ یہاں، ToR 1 اور ToR 2 - تو تعامل پہلی اور دوسری دونوں سطحوں کی ریڑھ کی ہڈی سے گزرے گا۔
نظریہ میں، اس طرح کا فن تعمیر آسانی سے قابل توسیع ہے۔ اگر ہمارے پاس پورٹ کی گنجائش، ڈیٹا سینٹر میں اضافی جگہ اور پری لیڈ فائبر ہو تو لین کی تعداد میں ہمیشہ اضافہ کیا جا سکتا ہے، اس طرح سسٹم کی مجموعی صلاحیت میں اضافہ ہوتا ہے۔ یہ کاغذ پر کرنا بہت آسان ہے۔ زندگی میں ایسا ہی ہوگا۔ لیکن آج کی کہانی اس کے بارے میں نہیں ہے۔
میں چاہتا ہوں کہ صحیح نتیجہ اخذ کیا جائے۔ ڈیٹا سینٹر کے اندر ہمارے پاس بہت سے راستے ہیں۔ وہ مشروط طور پر آزاد ہیں۔ ڈیٹا سینٹر کے اندر ایک راستہ صرف ToR کے اندر ہی ممکن ہے۔ ماڈیول کے اندر، ہمارے پاس راستوں کی تعداد لین کی تعداد کے برابر ہے۔ ماڈیولز کے درمیان راستوں کی تعداد طیاروں کی تعداد اور ہر جہاز میں سپر اسپائنز کی تعداد کے برابر ہے۔ اسے واضح کرنے کے لیے، پیمانے کا احساس حاصل کرنے کے لیے، میں ایسے نمبر دوں گا جو Yandex ڈیٹا سینٹرز میں سے ایک کے لیے درست ہیں۔
آٹھ طیارے ہیں، ہر طیارے میں 32 سپر اسپائن ہیں۔ نتیجے کے طور پر، یہ پتہ چلتا ہے کہ ماڈیول کے اندر آٹھ راستے ہیں، اور انٹر موڈیول کے تعامل کے ساتھ ان میں سے 256 پہلے ہی موجود ہیں۔
یعنی، اگر ہم Cookbook تیار کر رہے ہیں، یہ سیکھنے کی کوشش کر رہے ہیں کہ غلطی برداشت کرنے والے ڈیٹا سینٹرز کیسے بنائے جائیں جو خود کو ٹھیک کرتے ہیں، تو پلانر فن تعمیر صحیح انتخاب ہے۔ یہ اسکیلنگ کا مسئلہ حل کرتا ہے، اور نظریہ میں یہ آسان ہے۔ بہت سے آزاد راستے ہیں۔ سوال باقی ہے: اس طرح کا فن تعمیر ناکامیوں سے کیسے بچ سکتا ہے؟ مختلف قسم کی ناکامیاں ہیں۔ اور اب ہم اس پر بات کریں گے۔
ہمارے سپر اسپائن میں سے ایک کو "بیمار" ہونے دیں۔ یہاں میں دو ہوائی جہاز کے فن تعمیر پر واپس آیا۔ ہم مثال کے طور پر ان کے ساتھ رہیں گے کیونکہ یہ دیکھنا آسان ہو جائے گا کہ کم حرکت پذیر حصوں کے ساتھ کیا ہو رہا ہے۔ X11 کو بیمار ہونے دیں۔ اس سے ڈیٹا سینٹرز کے اندر رہنے والی سروسز پر کیا اثر پڑے گا؟ بہت کچھ اس بات پر منحصر ہے کہ ناکامی اصل میں کیسی دکھتی ہے۔
اگر ناکامی اچھی ہے، تو یہ اسی BFD کے آٹومیشن کی سطح پر پکڑی جاتی ہے، آٹومیشن خوشی سے پریشانی والے جوڑوں کو رکھتا ہے اور مسئلہ کو الگ کر دیتا ہے، پھر سب کچھ ٹھیک ہے۔ ہمارے پاس بہت سے راستے ہیں، ٹریفک کو فوری طور پر متبادل راستوں کی طرف موڑ دیا جاتا ہے، اور سروسز کو کچھ نظر نہیں آئے گا۔ یہ ایک اچھی اسکرپٹ ہے۔
ایک برا منظر نامہ یہ ہے کہ اگر ہمیں مسلسل نقصانات ہوتے ہیں، اور آٹومیشن اس مسئلے کو محسوس نہیں کرتا ہے۔ یہ سمجھنے کے لیے کہ یہ کس طرح کسی ایپلیکیشن کو متاثر کرتا ہے، ہمیں تھوڑا سا وقت گزارنا ہوگا کہ TCP کیسے کام کرتا ہے۔
مجھے امید ہے کہ میں اس معلومات سے کسی کو صدمہ نہیں پہنچاؤں گا: TCP ایک ٹرانسمیشن کنفرمیشن پروٹوکول ہے۔ یعنی، سب سے آسان صورت میں، بھیجنے والا دو پیکٹ بھیجتا ہے اور ان پر ایک جمع وصول کرتا ہے: "مجھے دو پیکٹ موصول ہوئے ہیں۔"
اس کے بعد، وہ مزید دو پیکٹ بھیجے گا، اور صورت حال دہرائے گی۔ میں کچھ آسانیاں پیدا کرنے کے لیے پیشگی معذرت خواہ ہوں۔ یہ منظر نامہ درست ہے اگر ونڈو (پرواز میں پیکٹوں کی تعداد) دو ہے۔ بلاشبہ عام صورت میں یہ ضروری نہیں کہ ایسا ہو۔ لیکن ونڈو کا سائز پیکٹ فارورڈنگ سیاق و سباق کو متاثر نہیں کرتا ہے۔
اگر ہم پیکٹ 3 کھو دیں تو کیا ہوگا؟ اس صورت میں، وصول کنندہ کو پیکٹ 1، 2 اور 4 موصول ہوں گے۔ اور وہ SACK آپشن کا استعمال کرتے ہوئے بھیجنے والے کو واضح طور پر بتائے گا: "آپ جانتے ہیں، تین پہنچ گئے، لیکن درمیان میں گم ہو گیا تھا۔" وہ کہتے ہیں، "Ack 2، SACK 4."
اس وقت، بھیجنے والا بغیر کسی پریشانی کے بالکل وہی پیکٹ دہراتا ہے جو کھو گیا تھا۔
لیکن اگر ونڈو میں آخری پیکٹ گم ہو جائے تو صورتحال بالکل مختلف نظر آئے گی۔
وصول کنندہ کو پہلے تین پیکٹ ملتے ہیں اور سب سے پہلے انتظار کرنا شروع ہوتا ہے۔ لینکس کرنل کے TCP اسٹیک میں کچھ اصلاح کی بدولت، یہ ایک جوڑے والے پیکٹ کا انتظار کرے گا جب تک کہ جھنڈے واضح طور پر یہ ظاہر نہ کریں کہ یہ آخری پیکٹ ہے یا اس سے ملتی جلتی کوئی چیز۔ یہ تاخیر شدہ ACK ٹائم آؤٹ کے ختم ہونے تک انتظار کرے گا اور پھر پہلے تین پیکٹوں پر ایک اعتراف بھیجے گا۔ لیکن اب بھیجنے والا انتظار کرے گا۔ اسے نہیں معلوم کہ چوتھا پیکج گم ہو گیا ہے یا آنے والا ہے۔ اور نیٹ ورک کو اوورلوڈ نہ کرنے کے لیے، یہ ایک واضح اشارے کا انتظار کرنے کی کوشش کرے گا کہ پیکٹ گم ہو گیا ہے، یا RTO کا ٹائم آؤٹ ختم ہو جائے گا۔
RTO ٹائم آؤٹ کیا ہے؟ یہ TCP اسٹیک اور کچھ مستقل کے حساب سے زیادہ سے زیادہ RTT ہے۔ یہ کیسا مستقل ہے، اب ہم بات کریں گے۔
لیکن اہم بات یہ ہے کہ اگر ہم دوبارہ بدقسمت ہوتے ہیں اور چوتھا پیکٹ دوبارہ کھو جاتا ہے، تو RTO دوگنا ہو جاتا ہے۔ یعنی، ہر ناکام کوشش کا مطلب ٹائم آؤٹ کو دوگنا کرنا ہے۔
اب دیکھتے ہیں کہ یہ بنیاد کس کے برابر ہے۔ پہلے سے طے شدہ طور پر، کم از کم RTO 200 ms ہے۔ ڈیٹا پیکجز کے لیے یہ کم از کم RTO ہے۔ SYN پیکٹ کے لیے یہ مختلف ہے، 1 سیکنڈ۔ جیسا کہ آپ دیکھ سکتے ہیں، یہاں تک کہ پیکٹ دوبارہ بھیجنے کی پہلی کوشش میں ڈیٹا سینٹر کے اندر RTT سے 100 گنا زیادہ وقت لگے گا۔
اب آتے ہیں اپنے منظر نامے کی طرف۔ سروس کے ساتھ کیا ہو رہا ہے؟ سروس پیکٹ کھونے لگتی ہے۔ سروس کو پہلے مشروط طور پر خوش قسمت رہنے دیں اور ونڈو کے بیچ میں کچھ کھو جائے، پھر اسے ایک SACK موصول ہوتا ہے اور گمشدہ پیکٹوں کو دوبارہ بھیج دیتا ہے۔
لیکن اگر بدقسمتی اپنے آپ کو دہراتی ہے، تو ہمارے پاس ایک آر ٹی او ہے۔ یہاں کیا ضروری ہے؟ ہاں، ہمارے نیٹ ورک میں بہت سارے راستے ہیں۔ لیکن ایک مخصوص TCP کنکشن کی TCP ٹریفک اسی ٹوٹے ہوئے اسٹیک سے گزرتی رہے گی۔ پیکٹ کے نقصانات، بشرطیکہ ہمارا یہ جادوئی X11 خود سے باہر نہ جائے، ایسے علاقوں میں ٹریفک کی روانی کا باعث نہیں بنتا جو مسائل کا شکار نہیں ہیں۔ ہم اسی ٹوٹے ہوئے اسٹیک کے ذریعے پیکٹ پہنچانے کی کوشش کر رہے ہیں۔ یہ ایک جھڑپ کی ناکامی کا باعث بنتا ہے: ڈیٹا سینٹر انٹرایکٹنگ ایپلی کیشنز کا ایک مجموعہ ہے، اور ان تمام ایپلی کیشنز کے کچھ TCP کنکشنز خراب ہونے لگتے ہیں - کیونکہ سپر اسپائن ڈیٹا سینٹر کے اندر موجود تمام ایپلی کیشنز کو متاثر کرتی ہے۔ جیسا کہ کہاوت ہے: اگر آپ نے گھوڑے کو جوتا نہیں لگایا تو گھوڑا لنگڑا ہو گیا۔ گھوڑا لنگڑا ہو گیا - رپورٹ نہیں پہنچائی گئی۔ رپورٹ فراہم نہیں کی گئی - ہم جنگ ہار گئے۔ صرف یہاں گنتی سیکنڈوں میں ہوتی ہے جب سے مسئلہ انحطاط کے اس مرحلے تک پہنچ جاتا ہے جسے خدمات محسوس کرنے لگتی ہیں۔ اس کا مطلب ہے کہ صارفین کہیں نہ کہیں کچھ کھو رہے ہیں۔
دو کلاسک حل ہیں جو ایک دوسرے کی تکمیل کرتے ہیں۔ سب سے پہلے وہ خدمات ہیں جو اسٹرا ڈالنے اور اس مسئلے کو اس طرح حل کرنے کی کوشش کر رہی ہیں: "آئیے TCP اسٹیک میں کچھ موافقت کریں۔ آئیے درخواست کی سطح پر ٹائم آؤٹ بنائیں یا اندرونی صحت کی جانچ کے ساتھ طویل عرصے تک چلنے والے TCP سیشنز۔" مسئلہ یہ ہے کہ اس طرح کے حل: a) بالکل بھی پیمانہ نہ بنائیں۔ ب) بہت ناقص جانچ پڑتال کی جاتی ہے۔ یعنی، یہاں تک کہ اگر سروس غلطی سے TCP اسٹیک کو اس طرح سے ترتیب دیتی ہے جو اسے بہتر بناتی ہے، سب سے پہلے، یہ تمام ایپلیکیشنز اور تمام ڈیٹا سینٹرز پر لاگو ہونے کا امکان نہیں ہے، اور دوسرا، زیادہ تر امکان ہے، یہ نہیں سمجھے گا کہ ایسا کیا گیا تھا۔ صحیح طریقے سے، اور کیا نہیں. یعنی، یہ کام کرتا ہے، لیکن یہ خراب کام کرتا ہے اور پیمانہ نہیں ہوتا ہے۔ اور اگر نیٹ ورک کا مسئلہ ہے تو اس کا ذمہ دار کون ہے؟ یقیناً این او سی۔ NOC کیا کرتا ہے؟
بہت سی سروسز کا خیال ہے کہ NOC میں کام کچھ اس طرح ہوتا ہے۔ لیکن سچ پوچھیں تو صرف یہی نہیں۔
کلاسیکی اسکیم میں NOC بہت سے نگرانی کے نظام کی ترقی میں مصروف ہے۔ یہ دونوں بلیک باکس اور وائٹ باکس مانیٹرنگ ہیں۔ بلیک باکس ریڑھ کی ہڈی کی نگرانی کی ایک مثال کے بارے میں آخری نیکسٹ ہاپ پر الیگزینڈر کلیمینکو۔ ویسے یہ مانیٹرنگ کام کرتی ہے۔ لیکن یہاں تک کہ مثالی نگرانی میں وقت کا وقفہ ہوگا۔ عام طور پر یہ چند منٹوں کا ہوتا ہے۔ اس کے ختم ہونے کے بعد، ڈیوٹی پر موجود انجینئرز کو اس کے آپریشن کو دوبارہ چیک کرنے، مسئلے کو مقامی بنانے اور پھر مسئلے کے علاقے کو بجھانے کے لیے وقت درکار ہوتا ہے۔ یعنی، بہترین صورت میں، مسئلہ کا علاج کرنے میں 5 منٹ لگتے ہیں، بدترین صورت میں، 20 منٹ، اگر یہ فوری طور پر واضح نہ ہو کہ نقصانات کہاں ہوتے ہیں۔ یہ واضح ہے کہ اس تمام وقت - 5 یا 20 منٹ - ہماری خدمات متاثر ہوتی رہیں گی، جو شاید اچھی نہیں ہے۔
آپ واقعی کیا وصول کرنا چاہیں گے؟ ہمارے پاس بہت سارے طریقے ہیں۔ اور مسائل بالکل اس لیے پیدا ہوتے ہیں کیونکہ TCP بہاؤ جو بدقسمت ہوتے ہیں اسی راستے کو استعمال کرتے رہتے ہیں۔ ہمیں ایک ایسی چیز کی ضرورت ہے جو ہمیں ایک TCP کنکشن کے اندر متعدد روٹس استعمال کرنے کی اجازت دے گی۔ ایسا لگتا ہے کہ ہمارے پاس کوئی حل ہے۔ ٹی سی پی ہے، جسے ملٹی پاتھ ٹی سی پی کہا جاتا ہے، یعنی متعدد راستوں کے لیے ٹی سی پی۔ سچ ہے، یہ بالکل مختلف کام کے لیے تیار کیا گیا تھا - ایسے اسمارٹ فونز کے لیے جن میں نیٹ ورک کے متعدد آلات ہیں۔ منتقلی کو زیادہ سے زیادہ کرنے یا پرائمری/بیک اپ موڈ بنانے کے لیے، ایک طریقہ کار تیار کیا گیا تھا جو ایپلیکیشن میں شفاف طریقے سے متعدد تھریڈز (سیشنز) بناتا ہے اور آپ کو ناکامی کی صورت میں ان کے درمیان سوئچ کرنے کی اجازت دیتا ہے۔ یا، جیسا کہ میں نے کہا، لکیر کو زیادہ سے زیادہ کریں۔
لیکن یہاں ایک nuance ہے. یہ سمجھنے کے لیے کہ یہ کیا ہے، ہمیں یہ دیکھنا پڑے گا کہ دھاگے کیسے قائم ہوتے ہیں۔
دھاگوں کو ترتیب وار نصب کیا جاتا ہے۔ پہلا دھاگہ پہلے انسٹال ہوتا ہے۔ اس کے بعد کے دھاگوں کو اس کوکی کا استعمال کرتے ہوئے سیٹ کیا جاتا ہے جس پر اس تھریڈ میں پہلے ہی اتفاق ہو چکا ہے۔ اور یہاں مسئلہ ہے۔
مسئلہ یہ ہے کہ اگر پہلا دھاگہ خود کو قائم نہیں کرتا ہے تو دوسرا اور تیسرا دھاگہ کبھی پیدا نہیں ہوگا۔ یعنی ملٹی پاتھ TCP پہلے بہاؤ میں SYN پیکٹ کے نقصان کو حل نہیں کرتا ہے۔ اور اگر SYN کھو جاتا ہے تو ملٹی پاتھ TCP باقاعدہ TCP میں بدل جاتا ہے۔ اس کا مطلب ہے کہ ڈیٹا سینٹر کے ماحول میں یہ فیکٹری میں ہونے والے نقصانات کے مسئلے کو حل کرنے اور ناکامی کی صورت میں متعدد راستے استعمال کرنا سیکھنے میں ہماری مدد نہیں کرے گا۔
کیا ہماری مدد کر سکتا ہے؟ آپ میں سے کچھ نے عنوان سے پہلے ہی اندازہ لگایا ہے کہ ہماری مزید کہانی میں ایک اہم فیلڈ IPv6 فلو لیبل ہیڈر فیلڈ ہوگا۔ درحقیقت، یہ ایک فیلڈ ہے جو v6 میں ظاہر ہوتا ہے، یہ v4 میں نہیں ہے، یہ 20 بٹس پر قبضہ کرتا ہے، اور اس کے استعمال پر کافی عرصے سے تنازعہ چل رہا ہے۔ یہ بہت دلچسپ ہے - تنازعات تھے، RFC کے اندر کچھ طے کیا گیا تھا، اور اسی وقت لینکس کرنل میں ایک نفاذ ظاہر ہوا، جو کہیں بھی دستاویزی نہیں تھا۔
میں آپ کو دعوت دیتا ہوں کہ تھوڑی سی تفتیش پر میرے ساتھ چلیں۔ آئیے اس پر ایک نظر ڈالتے ہیں کہ پچھلے کچھ سالوں میں لینکس کرنل میں کیا ہو رہا ہے۔
سال 2014 ایک بڑی اور معزز کمپنی کا انجینئر ساکٹ ہیش پر فلو لیبل ویلیو کے انحصار کو لینکس کرنل کی فعالیت میں اضافہ کرتا ہے۔ وہ یہاں کیا ٹھیک کرنے کی کوشش کر رہے تھے؟ اس کا تعلق RFC 6438 سے ہے، جس نے درج ذیل مسئلے پر بات کی۔ ڈیٹا سینٹر کے اندر، IPv4 اکثر IPv6 پیکٹوں میں سمایا جاتا ہے، کیونکہ فیکٹری خود IPv6 ہے، لیکن IPv4 کو کسی نہ کسی طرح باہر دیا جانا چاہیے۔ کافی عرصے سے سوئچز کے ساتھ مسائل تھے جو TCP یا UDP پر جانے اور وہاں src_ports, dst_ports تلاش کرنے کے لیے دو IP ہیڈر کے نیچے نہیں دیکھ سکتے تھے۔ یہ پتہ چلا کہ ہیش، اگر آپ پہلے دو آئی پی ہیڈرز کو دیکھیں تو، تقریباً طے شدہ نکلا۔ اس سے بچنے کے لیے، تاکہ اس انکیپسلیٹڈ ٹریفک کا توازن درست طریقے سے کام کرے، یہ تجویز کیا گیا تھا کہ 5-tuple encapsulated پیکٹ کی ہیش کو فلو لیبل فیلڈ کی قدر میں شامل کیا جائے۔ تقریباً یہی کام دیگر انکیپسولیشن اسکیموں کے لیے کیا گیا تھا، UDP کے لیے، GRE کے لیے، مؤخر الذکر نے GRE Key فیلڈ کا استعمال کیا۔ کسی نہ کسی طرح، یہاں کے مقاصد واضح ہیں۔ اور کم از کم اس وقت وہ کارآمد تھے۔
2015 میں اسی محترم انجینئر کی طرف سے ایک نیا پیچ آتا ہے۔ وہ بہت دلچسپ ہے۔ یہ مندرجہ ذیل کہتا ہے - منفی روٹنگ ایونٹ کی صورت میں ہم ہیش کو بے ترتیب کر دیں گے۔ منفی روٹنگ ایونٹ کیا ہے؟ یہ وہ آر ٹی او ہے جس پر ہم نے پہلے بات کی تھی، یعنی کھڑکی کی دم کا کھو جانا ایک ایسا واقعہ ہے جو واقعی منفی ہے۔ سچ ہے، یہ اندازہ لگانا نسبتاً مشکل ہے کہ یہ وہی ہے۔
2016، ایک اور معروف کمپنی، بھی بڑی. یہ آخری بیساکھیوں کو الگ کرتا ہے اور اسے اس طرح بناتا ہے کہ ہیش، جسے ہم نے پہلے بے ترتیب بنایا تھا، اب ہر SYN ری ٹرانسمیشن کے لیے اور ہر RTO ٹائم آؤٹ کے بعد تبدیل ہوتا ہے۔ اور اس خط میں، پہلی اور آخری بار، حتمی مقصد بیان کیا گیا ہے - اس بات کو یقینی بنانے کے لیے کہ نقصانات یا چینل کی بھیڑ کی صورت میں ٹریفک کو نرمی سے دوبارہ روٹ کرنے اور متعدد راستے استعمال کرنے کی صلاحیت ہو۔ یقینا، اس کے بعد بہت ساری اشاعتیں تھیں، آپ انہیں آسانی سے تلاش کر سکتے ہیں۔
اگرچہ نہیں، آپ نہیں کر سکتے، کیونکہ اس موضوع پر ایک بھی اشاعت نہیں ہوئی ہے۔ لیکن ہم جانتے ہیں!
اور اگر آپ پوری طرح سے نہیں سمجھتے کہ کیا کیا گیا تھا، تو میں آپ کو ابھی بتاؤں گا۔
کیا کیا گیا، لینکس کرنل میں کون سی فعالیت شامل کی گئی؟ txhash ہر RTO ایونٹ کے بعد بے ترتیب قدر میں بدل جاتا ہے۔ یہ روٹنگ کا انتہائی منفی نتیجہ ہے۔ ہیش اس txhash پر منحصر ہے، اور فلو لیبل skb ہیش پر منحصر ہے۔ یہاں فنکشنز پر کچھ حسابات ہیں؛ تمام تفصیلات کو ایک سلائیڈ پر نہیں رکھا جا سکتا۔ اگر کوئی متجسس ہے، تو آپ کرنل کوڈ کے ذریعے جا کر چیک کر سکتے ہیں۔
یہاں کیا ضروری ہے؟ فلو لیبل فیلڈ کی قدر ہر RTO کے بعد بے ترتیب نمبر میں بدل جاتی ہے۔ یہ ہمارے بدقسمت TCP سلسلے کو کیسے متاثر کرتا ہے؟
اگر SACK ہوتا ہے، تو کچھ نہیں بدلتا کیونکہ ہم گمشدہ پیکٹ کو دوبارہ بھیجنے کی کوشش کر رہے ہیں۔ اب تک بہت اچھا۔
لیکن RTO کے معاملے میں، بشرطیکہ ہم نے ToR پر ہیش فنکشن میں فلو لیبل شامل کیا ہو، ٹریفک مختلف راستہ اختیار کر سکتی ہے۔ اور جتنی زیادہ لینیں ہوں گی، اتنا ہی زیادہ موقع ہے کہ اسے کوئی ایسا راستہ ملے گا جو کسی مخصوص ڈیوائس پر ناکامی سے متاثر نہ ہو۔
ایک مسئلہ باقی ہے - RTO۔ بلاشبہ، ایک اور راستہ ہے، لیکن اس میں بہت وقت ضائع ہوتا ہے. 200 ایم ایس بہت زیادہ ہے۔ ایک سیکنڈ بالکل جنگلی ہے۔ پہلے، میں نے ٹائم آؤٹ کے بارے میں بات کی تھی کہ سروسز کنفیگر ہوتی ہیں۔ لہذا، ایک سیکنڈ ایک ٹائم آؤٹ ہے، جو عام طور پر ایپلی کیشن کی سطح پر سروس کے ذریعہ ترتیب دیا جاتا ہے، اور اس میں سروس نسبتاً درست بھی ہوگی۔ مزید یہ کہ، میں دہراتا ہوں، جدید ڈیٹا سینٹر کے اندر حقیقی RTT تقریباً 1 ملی سیکنڈ ہے۔
آپ RTO ٹائم آؤٹ کے ساتھ کیا کر سکتے ہیں؟ ٹائم آؤٹ، جو ڈیٹا پیکٹ کے ضائع ہونے کی صورت میں RTO کے لیے ذمہ دار ہے، صارف کی جگہ سے نسبتاً آسانی سے ترتیب دیا جا سکتا ہے: ایک IP یوٹیلیٹی ہے، اور اس کے پیرامیٹرز میں سے ایک وہی rto_min پر مشتمل ہے۔ اس بات کو مدنظر رکھتے ہوئے کہ یقیناً RTO کو عالمی سطح پر ایڈجسٹ کرنے کی ضرورت نہیں ہے، لیکن دیے گئے سابقوں کے لیے، ایسا طریقہ کار کافی قابل عمل نظر آتا ہے۔
سچ ہے، SYN_RTO کے ساتھ سب کچھ کچھ بدتر ہے۔ یہ قدرتی طور پر کیلوں سے جڑا ہوا ہے۔ دانا کی ایک مقررہ قیمت 1 سیکنڈ ہے، اور بس۔ آپ صارف کی جگہ سے وہاں نہیں پہنچ سکتے۔ ایک ہی راستہ ہے۔
eBPF بچاؤ کے لیے آتا ہے۔ سیدھے الفاظ میں، یہ چھوٹے سی پروگرام ہیں، انہیں کرنل اسٹیک اور ٹی سی پی اسٹیک کے عمل میں مختلف جگہوں پر ہکس میں ڈالا جا سکتا ہے، جس سے آپ بہت بڑی تعداد میں سیٹنگز کو تبدیل کر سکتے ہیں۔ عام طور پر، eBPF ایک طویل مدتی رجحان ہے۔ درجنوں نئے sysctl پیرامیٹرز کو کاٹنے اور IP افادیت کو بڑھانے کے بجائے، تحریک eBPF کی طرف بڑھ رہی ہے اور اپنی فعالیت کو بڑھا رہی ہے۔ eBPF کا استعمال کرتے ہوئے، آپ متحرک طور پر کنجشن کنٹرولز اور مختلف دیگر TCP سیٹنگز کو تبدیل کر سکتے ہیں۔
لیکن یہ ہمارے لیے اہم ہے کہ اسے SYN_RTO اقدار کو تبدیل کرنے کے لیے استعمال کیا جا سکتا ہے۔ مزید یہ کہ، عوامی طور پر پوسٹ کی گئی ایک مثال ہے: . یہاں کیا کیا گیا ہے؟ مثال کام کر رہی ہے، لیکن اپنے آپ میں بہت کھردرا ہے۔ یہاں یہ فرض کیا جاتا ہے کہ ڈیٹا سینٹر کے اندر ہم پہلے 44 بٹس کا موازنہ کرتے ہیں؛ اگر وہ میچ کرتے ہیں، تو ہم ڈیٹا سینٹر کے اندر ہیں۔ اور اس صورت میں ہم SYN_RTO ٹائم آؤٹ ویلیو کو 4ms میں تبدیل کرتے ہیں۔ ایک ہی کام بہت زیادہ خوبصورتی سے کیا جا سکتا ہے۔ لیکن یہ سادہ سی مثال ظاہر کرتی ہے کہ یہ ایک) ممکن ہے؛ ب) نسبتاً آسان۔
ہم پہلے ہی کیا جانتے ہیں؟ حقیقت یہ ہے کہ جہاز کا فن تعمیر اسکیلنگ کی اجازت دیتا ہے، یہ ہمارے لیے انتہائی مفید ثابت ہوتا ہے جب ہم ToR پر فلو لیبل کو فعال کرتے ہیں اور مسائل والے علاقوں میں بہنے کی صلاحیت حاصل کرتے ہیں۔ RTO اور SYN-RTO اقدار کو کم کرنے کا بہترین طریقہ eBPF پروگراموں کا استعمال ہے۔ سوال باقی ہے: کیا توازن کے لیے فلو لیبل استعمال کرنا محفوظ ہے؟ اور یہاں ایک nuance ہے.
فرض کریں کہ آپ کے نیٹ ورک پر ایک سروس ہے جو کسی بھی کاسٹ میں رہتی ہے۔ بدقسمتی سے، میرے پاس کسی بھی کاسٹ کیا ہے اس کے بارے میں تفصیل میں جانے کا وقت نہیں ہے، لیکن یہ ایک تقسیم شدہ سروس ہے جس میں مختلف فزیکل سرورز ایک ہی IP ایڈریس کے ذریعے قابل رسائی ہیں۔ اور یہاں ایک ممکنہ مسئلہ ہے: RTO واقعہ صرف اس وقت نہیں ہو سکتا جب ٹریفک تانے بانے سے گزرے۔ یہ ToR بفر کی سطح پر بھی ہو سکتا ہے: جب کوئی انکاسٹ واقعہ پیش آتا ہے، تو یہ میزبان پر بھی ہو سکتا ہے جب میزبان کچھ پھیلاتا ہے۔ جب کوئی RTO واقعہ ہوتا ہے اور یہ فلو لیبل کو تبدیل کرتا ہے۔ اس صورت میں، ٹریفک کسی بھی دوسری مثال میں جا سکتا ہے۔ آئیے فرض کریں کہ یہ ایک اسٹیٹفول اینی کاسٹ ہے، اس میں کنکشن کی حالت ہے - یہ L3 بیلنسر یا کوئی اور سروس ہو سکتی ہے۔ پھر ایک مسئلہ پیدا ہوتا ہے، کیونکہ RTO کے بعد TCP کنکشن سرور پر آتا ہے، جو اس TCP کنکشن کے بارے میں کچھ نہیں جانتا۔ اور اگر ہمارے پاس کسی بھی کاسٹ سرورز کے درمیان اسٹیٹ شیئرنگ نہیں ہے، تو ایسی ٹریفک کو چھوڑ دیا جائے گا اور TCP کنکشن ٹوٹ جائے گا۔
آپ یہاں کیا کر سکتے ہیں؟ اپنے کنٹرول شدہ ماحول کے اندر، جہاں آپ فلو لیبل بیلنسنگ کو فعال کرتے ہیں، آپ کو کسی بھی کاسٹ سرورز تک رسائی حاصل کرتے وقت فلو لیبل کی قدر کو ریکارڈ کرنے کی ضرورت ہوتی ہے۔ سب سے آسان طریقہ یہ ہے کہ اسی eBPF پروگرام کے ذریعے ایسا کیا جائے۔ لیکن یہاں ایک بہت اہم نکتہ ہے - اگر آپ ڈیٹا سینٹر نیٹ ورک نہیں چلاتے، لیکن ٹیلی کام آپریٹر ہیں تو کیا کریں؟ یہ آپ کا بھی مسئلہ ہے: جونیپر اور اریسٹا کے کچھ ورژن سے شروع کرتے ہوئے، وہ اپنے ہیش فنکشنز میں بطور ڈیفالٹ فلو لیبل شامل کرتے ہیں - سچ کہوں تو، اس وجہ سے جو میرے لیے واضح نہیں ہے۔ اس کی وجہ سے آپ اپنے نیٹ ورک سے گزرنے والے صارفین سے TCP کنکشن چھوڑ سکتے ہیں۔ لہذا میں یہاں اپنے راؤٹرز کی ترتیبات کو چیک کرنے کی انتہائی سفارش کرتا ہوں۔
کسی نہ کسی طرح، مجھے ایسا لگتا ہے کہ ہم تجربات کی طرف بڑھنے کے لیے تیار ہیں۔
جب ہم نے ToR پر فلو لیبل کو فعال کیا، eBPF ایجنٹ کو تیار کیا، جو اب میزبانوں پر رہتا ہے، ہم نے فیصلہ کیا کہ اگلی بڑی ناکامی کا انتظار نہیں کیا جائے گا، بلکہ کنٹرول شدہ دھماکے کیے جائیں گے۔ ہم نے ٹی او آر لیا، جس میں چار اپ لنکس ہیں، اور ان میں سے ایک پر ڈراپ لگاتے ہیں۔ انہوں نے ایک قاعدہ کھینچا اور کہا - اب آپ تمام پیکٹ کھو رہے ہیں۔ جیسا کہ آپ بائیں طرف دیکھ سکتے ہیں، ہمارے پاس فی پیکٹ مانیٹرنگ ہے، جو 75% تک گر گئی ہے، یعنی 25% پیکٹ ضائع ہو گئے ہیں۔ دائیں جانب اس ٹی او آر کے پیچھے رہنے والی خدمات کے گراف ہیں۔ بنیادی طور پر، یہ ریک کے اندر موجود سرورز کے ساتھ انٹرفیس کے ٹریفک گراف ہیں۔ جیسا کہ آپ دیکھ سکتے ہیں، وہ اور بھی نیچے ڈوب گئے۔ وہ کم کیوں ہوئے - 25٪ سے نہیں، لیکن کچھ معاملات میں 3-4 گنا؟ اگر TCP کنکشن بدقسمت ہے، تو یہ ٹوٹے ہوئے جنکشن کے ذریعے پہنچنے کی کوشش کرتا رہتا ہے۔ یہ ڈی سی کے اندر سروس کے عام رویے سے بڑھتا ہے - ایک صارف کی درخواست کے لیے، داخلی خدمات کے لیے N درخواستیں تیار کی جاتی ہیں، اور جواب صارف کے پاس جائے گا جب یا تو تمام ڈیٹا ذرائع جواب دیں گے، یا جب ایپلیکیشن میں ٹائم آؤٹ ہو جائے گا۔ سطح، جسے ابھی بھی ترتیب دینے کی ضرورت ہے۔ یعنی سب کچھ بہت، بہت برا ہے۔
اب وہی تجربہ، لیکن فلو لیبل ویلیو کے ساتھ فعال ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، بائیں جانب ہمارے بیچ کی نگرانی میں اسی 25 فیصد کی کمی واقع ہوئی۔ یہ بالکل درست ہے، کیونکہ یہ دوبارہ ترسیل کے بارے میں کچھ نہیں جانتا ہے، یہ پیکٹ بھیجتا ہے اور صرف ڈیلیور شدہ اور گم شدہ پیکٹوں کی تعداد کے تناسب کو شمار کرتا ہے۔
اور دائیں طرف سروس کا شیڈول ہے۔ آپ کو یہاں پر مسئلہ جوڑ کا اثر نہیں ملے گا۔ انہی ملی سیکنڈ میں، ٹریفک مسئلہ کے علاقے سے تین باقی اپ لنکس کی طرف بہہ گئی جو مسئلہ سے متاثر نہیں ہوئے تھے۔ ہمارے پاس ایک نیٹ ورک ہے جو خود کو ٹھیک کرتا ہے۔
یہ میری آخری سلائیڈ ہے، خلاصہ کرنے کا وقت۔ اب، میں امید کرتا ہوں کہ آپ خود کو شفا دینے والا ڈیٹا سینٹر نیٹ ورک کیسے بنانا جانتے ہیں۔ آپ کو لینکس کرنل آرکائیو سے گزرنے اور وہاں خصوصی پیچ تلاش کرنے کی ضرورت نہیں ہوگی؛ آپ جانتے ہیں کہ اس معاملے میں فلو لیبل مسئلہ کو حل کرتا ہے، لیکن آپ کو اس طریقہ کار سے احتیاط سے رجوع کرنے کی ضرورت ہے۔ اور میں ایک بار پھر اس بات پر زور دیتا ہوں کہ اگر آپ ٹیلی کام آپریٹر ہیں، تو آپ کو فلو لیبل کو ہیش فنکشن کے طور پر استعمال نہیں کرنا چاہیے، ورنہ آپ اپنے صارفین کے سیشن میں خلل ڈالیں گے۔
نیٹ ورک انجینئرز کو ایک تصوراتی تبدیلی سے گزرنا چاہیے: نیٹ ورک ٹی او آر سے نہیں، نیٹ ورک ڈیوائس کے ساتھ نہیں، بلکہ میزبان کے ساتھ شروع ہوتا ہے۔ ایک کافی حیران کن مثال یہ ہے کہ ہم کس طرح eBPF کا استعمال RTO کو تبدیل کرنے اور کسی بھی کاسٹ سروسز کی طرف فلو لیبل کو ٹھیک کرنے کے لیے کرتے ہیں۔
فلو لیبل میکانکس یقینی طور پر کنٹرول شدہ انتظامی طبقہ کے اندر دیگر ایپلی کیشنز کے لیے موزوں ہیں۔ یہ ڈیٹا سینٹرز کے درمیان ٹریفک ہو سکتا ہے، یا آپ باہر جانے والے ٹریفک کو منظم کرنے کے لیے اس طرح کے میکینکس کو خاص طریقے سے استعمال کر سکتے ہیں۔ لیکن میں آپ کو اس کے بارے میں بتاؤں گا، مجھے امید ہے کہ اگلی بار۔ آپ کی توجہ کا بہت شکریہ.
ماخذ: www.habr.com