جديد ڊيٽا سينٽرن ۾ سوين فعال ڊوائيسز آهن جيڪي مختلف قسم جي نگراني سان ڍڪيل آهن. پر اڃا به هڪ مڪمل انجنيئر هٿ ۾ مڪمل نگراني سان صرف چند منٽن ۾ نيٽ ورڪ جي ناڪامي جو صحيح جواب ڏيڻ جي قابل هوندو. ايندڙ هاپ 2020 ڪانفرنس ۾ هڪ رپورٽ ۾، مون هڪ ڊيٽا سينٽر نيٽ ورڪ ڊيزائن جو طريقو پيش ڪيو جنهن ۾ هڪ منفرد خصوصيت آهي - ڊيٽا سينٽر پاڻ کي مليس سيڪنڊن ۾ شفا ڏيندو آهي. وڌيڪ واضح طور تي، انجنيئر آرام سان مسئلو حل ڪري ٿو، جڏهن ته خدمتون صرف ان کي نوٽيس نه ڪندا آهن.
ڪيترن ئي نيٽ ورڪ انجنيئرن لاء، ڊيٽا سينٽر نيٽ ورڪ شروع ٿئي ٿو، يقينا، ToR سان، ريڪ ۾ هڪ سوئچ سان. ToR عام طور تي ٻن قسمن جون لنڪس هونديون آهن. ننڍڙا سرور ڏانهن ويندا آهن، ٻيا - انهن مان اين ڀيرا وڌيڪ آهن - پهرين سطح جي اسپائن ڏانهن وڃو، اهو آهي، ان جي اپ لنڪس ڏانهن. Uplinks کي عام طور تي برابر سمجھيو ويندو آھي، ۽ uplinks جي وچ ۾ ٽريفڪ 5-tuple hash جي بنياد تي متوازن آھي، جنھن ۾ proto، src_ip، dst_ip، src_port، dst_port شامل آھن. هتي ڪو به تعجب ناهي.
اڳيون، جهازن جو فن تعمير ڪهڙو نظر اچي ٿو؟ پهرين سطح جي اسپائن هڪ ٻئي سان ڳنڍيل نه آهن، پر سپر اسپن جي ذريعي ڳنڍيل آهن. خط X سپر اسپنز لاء ذميوار هوندو، اهو لڳ ڀڳ هڪ ڪراس ڪنيڪشن وانگر آهي.
۽ اهو واضح آهي ته، ٻئي طرف، توري پهرين سطح جي سڀني اسپائن سان ڳنڍيل آهن. هن تصوير ۾ ڇا اهم آهي؟ جيڪڏهن اسان وٽ ريڪ جي اندر رابطي ۾ آهي، پوء اهو معاملو، يقينا، ToR ذريعي وڃي ٿو. جيڪڏهن ڳالهه ٻولهه ماڊل جي اندر وڃي ٿي، ته پوءِ ڳالهه ٻولهه پهرين سطح جي اسپائن ذريعي ٿئي ٿي. جيڪڏهن ڳالهه ٻولهه intermodular آهي - جيئن هتي، ToR 1 ۽ ToR 2 - پوءِ ڳالهه ٻولهه پهرين ۽ ٻئي سطح جي اسپائن ذريعي ٿيندي.
نظرياتي طور تي، اهڙي فن تعمير آساني سان اسڪيلبل آهي. جيڪڏهن اسان وٽ بندرگاهن جي گنجائش آهي، ڊيٽا سينٽر ۾ جڳهه جو هڪ ذخيرو ۽ اڳ ۾ رکيل فائبر، پوء جهازن جو تعداد هميشه وڌائي سگهجي ٿو، انهي سان سسٽم جي مجموعي صلاحيت وڌائي ٿي. ڪاغذ تي، اهو ڪرڻ بلڪل آسان آهي. حقيقي زندگي ۾ ائين ئي ٿيندو. پر اڄ جي ڪهاڻي ان بابت نه آهي.
مان چاهيان ٿو ته صحيح نتيجا ڪڍيا وڃن. اسان وٽ ڊيٽا سينٽر اندر ڪيترائي رستا آھن. اهي مشروط طور تي آزاد آهن. ڊيٽا سينٽر اندر هڪ طريقو صرف ToR اندر ممڪن آهي. ماڊل جي اندر، اسان وٽ ساڳيون ئي رستا آهن جيئن جهازن جو تعداد. ماڊلز جي وچ ۾ رستن جو تعداد جهازن جي تعداد جي پيداوار ۽ هر جهاز ۾ سپر اسپن جي تعداد جي برابر آهي. ان کي صاف ڪرڻ لاء، پيماني کي محسوس ڪرڻ لاء، آئون انهن انگن کي ڏيندس جيڪي صحيح آهن Yandex ڊيٽا سينٽرن مان هڪ لاء.
اٺ جهاز آهن، هر جهاز ۾ 32 سپر اسپن آهن. نتيجي طور، اهو ظاهر ٿئي ٿو ته ماڊل جي اندر اٺ رستا آهن، ۽ ماڊل وچ ۾ رابطي سان، انهن مان 256 اڳ ۾ ئي آهن.
اهو آهي، جيڪڏهن اسان هڪ ڪڪ بڪ ٺاهي رهيا آهيون، سکڻ جي ڪوشش ڪري رهيا آهيون ته غلطي برداشت ڪندڙ ڊيٽا سينٽر ڪيئن ٺاهيا وڃن جيڪي پاڻ کي شفا ڏين ٿا، پوء پلانر آرڪيٽيڪچر صحيح انتخاب آهي. اهو توهان کي اسڪيلنگ جو مسئلو حل ڪرڻ جي اجازت ڏئي ٿو، ۽ نظرياتي طور تي اهو آسان آهي. اتي ڪيترائي آزاد رستا آھن. سوال رهي ٿو: اهڙي فن تعمير جي ناڪاميءَ کان ڪيئن بچي؟ اتي مختلف حادثا آهن. ۽ اسان هن تي هاڻي بحث ڪنداسين.
اسان جي هڪ سپر اسپن کي بيمار ٿيڻ ڏيو. هتي مان ٻن جهازن جي فن تعمير ڏانهن موٽي آيو آهيان. اسان انهن سان گڏ هڪ مثال طور لٺ ڪنداسين ڇو ته اهو ڏسڻ ۾ آسان ٿيندو ته هتي ڇا ٿي رهيو آهي گهٽ حرڪت واري حصن سان. X11 کي بيمار ٿيڻ ڏيو. اهو ڪيئن متاثر ڪندو خدمتون جيڪي ڊيٽا سينٽرن اندر رهن ٿيون؟ گهڻو ڪجهه منحصر آهي ته ناڪامي اصل ۾ ڪيئن ڏسڻ ۾ اچي ٿي.
جيڪڏهن ناڪامي سٺي آهي، اها ساڳي BFD جي آٽوميشن جي سطح تي پکڙيل آهي، آٽوميشن خوشيء سان مسئلا جوڑوں کي رکي ٿو ۽ مسئلي کي الڳ ڪري ٿو، پوء سڀ ڪجهه ٺيڪ آهي. اسان وٽ ڪيترائي رستا آھن، ٽرئفڪ کي فوري طور تي متبادل رستن ڏانھن موٽايو ويندو آھي، ۽ خدمتون ڪجھ به نوٽيس نه ڪندا. هي هڪ سٺو منظر آهي.
هڪ خراب منظر آهي جيڪڏهن اسان کي مسلسل نقصان آهي، ۽ خودڪار طريقي سان مسئلو نوٽيس نٿو ڪري. اهو سمجھڻ لاءِ ته هي ايپليڪيشن تي ڪيئن اثر انداز ٿئي ٿو، اسان کي ٿورو وقت گذارڻو پوندو بحث ڪرڻ لاءِ ته TCP پروٽوڪول ڪيئن ڪم ڪري ٿو.
مون کي اميد آهي ته مان هن معلومات سان ڪنهن کي به صدمو نه ڏيندس: TCP هڪ هٿ ملائڻ وارو پروٽوڪول آهي. اهو آهي، آسان ترين صورت ۾، موڪليندڙ ٻه پيڪيجز موڪلي ٿو، ۽ انهن تي هڪ مجموعي ايڪو وصول ڪري ٿو: "مون کي ٻه پيڪيج مليا."
ان کان پوء، هو ٻه وڌيڪ پيڪ موڪليندو، ۽ صورتحال ٻيهر ورجائي ويندي. مان ڪجھ آسانيءَ لاءِ اڳ ۾ معافي گھران ٿو. اهو منظر درست آهي جيڪڏهن ونڊو (پرواز ۾ پيڪٽس جو تعداد) ٻه آهي. يقينن، اهو ضروري ناهي ته عام طور تي ڪيس. پر پيڪيٽ فارورڊنگ جي حوالي سان ونڊو سائيز کان متاثر نه ٿيو.
ڇا ٿيندو جيڪڏهن اسان پيڪيج 3 وڃائي ويهون؟ انهي صورت ۾، وصول ڪندڙ کي 1، 2 ۽ 4 پيڪيٽ ملي ويندا. ۽ هو واضح طور تي SACK اختيار استعمال ڪندي موڪليندڙ کي ڄاڻ ڏيندو: "توهان کي خبر آهي، ٽي آيا، پر وچ ۾ گم ٿي ويو." هو چوي ٿو ”اک 2، ساڪ 4“.
هن وقت موڪليندڙ ان پيڪٽ کي ورجائي ٿو جيڪو بغير ڪنهن پريشاني جي گم ٿي ويو هو.
پر جيڪڏهن ونڊو ۾ آخري پيٽ گم ٿي وڃي ته صورتحال بلڪل مختلف نظر ايندي.
وصول ڪندڙ پهريان ٽي پيڪيٽ وصول ڪري ٿو ۽ سڀ کان پهريان انتظار ڪرڻ شروع ڪري ٿو. لينڪس ڪنيل جي TCP اسٽيڪ ۾ ڪجهه اصلاحن جي مهرباني، اهو هڪ جوڙيل پيڪٽ جو انتظار ڪندو، جيستائين جھنڊن ۾ واضح اشارو نه هجي ته هي آخري پيڪيٽ آهي يا اهڙي ڪا شيءِ. اهو انتظار ڪندو جيستائين دير ٿيل ACK ٽائم آئوٽ ختم ٿئي ۽ پوءِ پهرين ٽن پيڪٽن لاءِ اقرار نامو موڪليو. پر هاڻي موڪليندڙ جو انتظار رهندو. هن کي خبر ناهي ته چوٿون پيڪيج گم ٿي ويو آهي يا اچڻ وارو آهي. ۽ نيٽ ورڪ کي اوورلوڊ نه ڪرڻ جي لاءِ، اهو واضح اشارو جو انتظار ڪرڻ جي ڪوشش ڪندو ته پيڪٽ گم ٿي ويو آهي، يا RTO وقت ختم ٿيڻ جو.
RTO وقت ختم ٿيڻ ڇا آهي؟ اهو RTT مان وڌ ۾ وڌ آهي TCP اسٽيڪ جي حساب سان ۽ ڪجهه مسلسل. هي مسلسل ڇا آهي، اسان هاڻي بحث ڪنداسين.
پر اهو ضروري آهي ته جيڪڏهن اسان ٻيهر بدقسمت آهيون ۽ چوٿين پيٽ ٻيهر گم ٿي وڃي ته پوءِ آر ٽي او ٻيڻو ڪري ٿو. اهو آهي، هر ناڪام ڪوشش وقت ختم ٿيڻ جو هڪ ٻيڻو آهي.
هاڻي اچو ته ڏسو ته هي بنياد ڪهڙي برابر آهي. ڊفالٽ طور، گھٽ ۾ گھٽ RTO 200ms آھي. هي ڊيٽا پيڪٽس لاءِ گهٽ ۾ گهٽ RTO آهي. SYN پيڪٽس لاءِ، اھو مختلف آھي، 1 سيڪنڊ. جئين توهان ڏسي سگهو ٿا، پيڪٽ ٻيهر موڪلڻ جي پهرين ڪوشش به ڊيٽا سينٽر اندر RTT کان 100 ڀيرا وڌيڪ وقت وٺندو.
هاڻي اسان جي منظرنامي ڏانهن واپس. خدمت سان ڇا ٿي رهيو آهي؟ خدمت پيڪٽ وڃائڻ شروع ڪري ٿي. اچو ته خدمت شروع ۾ خوش قسمت هجي ۽ ونڊو جي وچ ۾ ڪجهه وڃايو، پوء اهو هڪ SACK وصول ڪري ٿو، گم ٿيل پيڪٽس ٻيهر موڪلي ٿو.
پر جيڪڏهن خراب قسمت ورجائي ٿي، ته اسان وٽ هڪ آر ٽي او آهي. هتي ڇا اهم آهي؟ ها، اسان وٽ نيٽ ورڪ ۾ ڪيترائي رستا آهن. پر هڪ خاص TCP ڪنيڪشن جي TCP ٽريفڪ ساڳي ٽوٽل اسٽيڪ ذريعي جاري رهندي. پيڪٽ جو نقصان، مهيا ڪيو ويو آهي ته اسان جو جادو X11 پنهنجو پاڻ تي ٻاهر نه نڪري، انهن علائقن ڏانهن ٽرئفڪ جي وهڪري جي اڳواڻي نه ڪري جيڪي مسئلا نه آهن. اسان ڪوشش ڪري رهيا آهيون ته هڪ ئي ڀريل اسٽيڪ ذريعي هڪ پيڪٽ پهچائڻ. اهو هڪ cascading ناڪامي جي طرف وٺي ٿو: هڪ ڊيٽا سينٽر رابطي واري ايپليڪيشنن جو هڪ سيٽ آهي، ۽ انهن سڀني ايپليڪيشنن جا ڪجهه TCP ڪنيڪشن خراب ٿيڻ شروع ڪن ٿا - ڇاڪاڻ ته سپر اسپن انهن سڀني ايپليڪيشنن کي متاثر ڪري ٿو جيڪي ڊيٽا سينٽر اندر آهن. جيئن چوڻي آهي ته: جيڪڏهن توهان گهوڙي کي جوتا نه ڪيو، گهوڙو لڱو ٿيندو آهي. گهوڙو لنگهي ويو - رپورٽ نه ڏني وئي هئي؛ پيغام نه پهچايو ويو - اهي جنگ وڃائي ويٺا. صرف هتي ڳڻپ ان لمحي کان سيڪنڊن لاءِ ٿيندي آهي جڏهن مسئلو انحطاط جي اسٽيج تي اچي ٿو ته خدمتون محسوس ڪرڻ شروع ڪن ٿيون. هن جو مطلب اهو آهي ته صارف شايد ڪجهه حاصل نه ڪن.
اتي ٻه کلاسک حل آهن جيڪي هڪ ٻئي کي پورو ڪن ٿا. پهرين اهي خدمتون آهن جيڪي ڪوشش ڪري رهيا آهن اسٽرا وجھڻ ۽ مسئلو حل ڪرڻ جي هن طرح: “اچو ته TCP اسٽيڪ ۾ ڪجهه ٽائيڪ ڪريون. ۽ اچو ته ايپليڪيشن ليول ٽائم آئوٽ يا ڊگھي عرصي وارا TCP سيشن اندروني صحت جي چڪاس سان ڪيون. مسئلو اهو آهي ته اهڙا حل آهن: الف) سڀ ڪجهه نه ماپ؛ ب) تمام خراب آزمائشي. اهو آهي، جيتوڻيڪ جيڪڏهن خدمت حادثاتي طور تي TCP اسٽيڪ کي ترتيب ڏئي ٿي ته اهو بهتر ٿي وڃي، پهرين، اهو ممڪن ناهي ته سڀني ايپليڪيشنن ۽ سڀني ڊيٽا سينٽرن تي لاڳو ٿئي، ۽ ٻيو، گهڻو ڪري، اهو سمجهي نه سگهندو ته ڇا صحيح طريقي سان ڪيو ويو ۽ ڇا ڪيو ويو. نه اھو آھي، اھو ڪم ڪري ٿو، پر اھو خراب ڪم ڪري ٿو ۽ ماپ نٿو ڪري. ۽ جيڪڏهن ڪو نيٽ ورڪ مسئلو آهي، ڪير ذميوار آهي؟ يقيناً NOC. NOC ڇا ڪندو؟
ڪيتريون ئي خدمتون مڃيندا آهن ته NOC ۾، ڪم ڪجهه هن طرح ٿيندو آهي. پر ايماندار ٿيڻ لاء، نه رڳو.
ڪلاسيڪل اسڪيم ۾ NOC ڪيترن ئي نگراني جي ترقي ۾ مصروف آهي. اهي ٻئي بليڪ باڪس مانيٽرنگ ۽ وائيٽ باڪس مانيٽرنگ آهن. بليڪ باڪس جي مثال بابت- اسپائن جي نگراني اليگزينڊر ڪليمينڪو ماضي تي ايندڙ هاپ. رستي ۾، هي نگراني ڪم ڪري ٿو. پر اڃا به مڪمل نگراني ۾ هڪ وقت جي دير هوندي. اهو عام طور تي ڪيترن ئي منٽن آهي. ان جي ڪم ڪرڻ کان پوء، ڊيوٽي تي انجنيئرن کي ان جي آپريشن کي ٻه ڀيرا چيڪ ڪرڻ، مسئلي کي مقامي ڪرڻ، ۽ پوء مسئلي واري علائقي کي ختم ڪرڻ لاء وقت جي ضرورت آهي. اهو آهي، بهترين صورت ۾، مسئلي جو علاج 5 منٽ وٺندو آهي، بدترين 20 منٽن تي، جيڪڏهن اهو فوري طور تي واضح ناهي ته نقصان ڪٿي آهي. اهو واضح آهي ته اهو سڀ وقت - 5 يا 20 منٽ - اسان جي خدمتن کي نقصان پهچائڻ جاري رهندو، جيڪو شايد سٺو ناهي.
توھان ڇا حاصل ڪرڻ چاھيو ٿا؟ اسان وٽ ڪيترائي رستا آھن. ۽ مسئلا صحيح طور تي پيدا ٿين ٿا ڇو ته TCP وهڪري جيڪي بدقسمت آهن ساڳيو رستو استعمال ڪرڻ جاري رکندا آهن. اسان کي ھڪڙي شيء جي ضرورت آھي جيڪا اسان کي ھڪڙي TCP ڪنيڪشن اندر گھڻن رستن کي استعمال ڪرڻ جي اجازت ڏئي. اهو لڳي ٿو ته اسان وٽ هڪ حل آهي. اتي TCP آهي، جنهن کي سڏيو ويندو آهي - multipath TCP، يعني ڪيترن ئي رستن لاء TCP. سچ، اهو هڪ مڪمل طور تي مختلف ڪم لاء تيار ڪيو ويو آهي - اسمارٽ فونز لاء جيڪي ڪيترائي نيٽ ورڪ ڊوائيسز آهن. منتقلي کي وڌائڻ يا بنيادي / بيڪ اپ موڊ ٺاهڻ لاء، هڪ ميڪانيزم ٺاهي وئي جيڪا شفاف طور تي ايپليڪيشن لاء ڪيترائي موضوع (سيشن) ٺاهي ٿي ۽ توهان کي ناڪامي جي صورت ۾ انهن جي وچ ۾ سوئچ ڪرڻ جي اجازت ڏئي ٿي. يا، جيئن مون چيو، بينڊوڊٿ کي وڌايو.
پر هتي هڪ nuance آهي. سمجھڻ لاءِ ته اھو ڇا آھي، اسان کي ڏسڻو پوندو ته سلسلو ڪيئن ٺھيل آھي.
سلسلا ترتيب ڏنل آهن. پهريون وهڪرو پهريون نصب ڪيو ويو آهي. پوءِ ايندڙ وهڪريون ان سلسلي ۾ اڳ ۾ ئي اتفاق ٿيل ڪوڪي استعمال ڪندي سيٽ ڪيون وينديون آهن. ۽ هتي مسئلو آهي.
مسئلو اهو آهي ته جيڪڏهن پهريون ٿريڊ انسٽال نه ٿئي ته ٻيو ۽ ٽيون ٿريڊ ڪڏهن به سامهون نه ايندو. اهو آهي، multipath TCP پهرين اسٽريم ۾ SYN پيڪٽ جي نقصان کي حل نٿو ڪري. ۽ جيڪڏهن SYN گم ٿي وڃي ته، ملٽي پاٿ TCP عام TCP بڻجي ويندو. تنهن ڪري، ڊيٽا سينٽر ماحول ۾، اهو اسان کي ڪارخاني ۾ نقصان جي مسئلي کي حل ڪرڻ ۾ مدد نه ڏيندو ۽ ناڪامي جي صورت ۾ ڪيترن ئي رستن کي ڪيئن استعمال ڪرڻ سکو.
ڇا اسان جي مدد ڪري سگهي ٿو؟ توھان مان ڪجھ اڳ ۾ ئي نالو مان اندازو لڳايو آھي ته اسان جي وڌيڪ ڪهاڻي ۾ اهم فيلڊ IPv6 فلو ليبل هيڊر فيلڊ هوندو. درحقيقت، هي هڪ فيلڊ آهي جيڪو ظاهر ٿئي ٿو v6 ۾، اهو v4 ۾ نه آهي، اهو 20 بٽ وٺندو آهي، ۽ ان جي استعمال بابت هڪ ڊگهي وقت تائين تڪرار آهي. اهو تمام دلچسپ آهي - اتي تڪرار هئا، آر ايف سي جي فريم ورڪ ۾ ڪجهه مقرر ڪيو ويو، ۽ ساڳئي وقت، لينڪس ڪنييل ۾ هڪ عمل ظاهر ٿيو جيڪو ڪٿي به دستاويز نه ڪيو ويو.
مان صلاح ڏيان ٿو ته توهان مون سان گڏ ٿوري تحقيق تي. اچو ته هڪ نظر رکون ته گذريل ڪجهه سالن کان لينڪس ڪنييل ۾ ڇا ٿي رهيو آهي.
سال 2014. هڪ وڏي ۽ معزز ڪمپني مان هڪ انجنيئر لينڪس ڪرنل جي ڪارڪردگي ۾ اضافو ڪري ٿو ساکٽ جي هيش تي فلو ليبل جي قيمت جي انحصار. اهي هتي ڇا ڪرڻ جي ڪوشش ڪري رهيا آهن؟ اهو RFC 6438 سان لاڳاپيل آهي جنهن هيٺ ڏنل مسئلي تي بحث ڪيو. ڊيٽا سينٽر جي اندر، IPv4 اڪثر ڪري IPv6 پيڪٽس ۾ شامل ڪيو ويندو آهي، ڇاڪاڻ ته ڪارخانو پاڻ IPv6 آهي، پر IPv4 کي ڪنهن به طرح ڏنو وڃي. گهڻي وقت تائين سوئچز جا مسئلا هئا جيڪي ٻه IP هيڊرز هيٺ نه ڏسي سگهندا هئا TCP يا UDP ڏانهن وڃڻ ۽ اتي src_ports، dst_ports ڳوليندا. اهو ظاهر ٿيو ته هيش، جيڪڏهن توهان پهرين ٻن IP هيڊرن تي نظر اچن ٿا، لڳ ڀڳ مقرر ڪيو ويو آهي. ھن کان بچڻ لاءِ، انھيءَ لاءِ ته ھن ڍڪيل ٽريفڪ جو توازن صحيح طريقي سان ڪم ڪري، ان کي 5-tuple encapsulated packet مان فلو ليبل فيلڊ جي قدر ۾ شامل ڪرڻ جي تجويز ڏني وئي. تقريبن ساڳيو ڪيو ويو ٻين انڪپسوليشن اسڪيمن لاءِ، UDP لاءِ، GRE لاءِ، بعد ۾ GRE Key فيلڊ استعمال ڪيو ويو. هڪ طريقو يا ٻيو، مقصد هتي واضح آهن. ۽ گهٽ ۾ گهٽ ان موقعي تي اهي مفيد هئا.
2015 ۾، هڪ نئون پيچ ساڳئي معزز انجنيئر طرفان اچي ٿو. هو ڏاڍو دلچسپ آهي. اهو هيٺ ڏنل چوي ٿو - اسان منفي رستي واري واقعي جي صورت ۾ هيش کي ترتيب ڏينداسين. هڪ منفي روٽنگ واقعي ڇا آهي؟ هي RTO آهي جنهن تي اسان اڳ ۾ بحث ڪيو آهي، اهو آهي، ونڊو دم جو نقصان هڪ واقعو آهي جيڪو واقعي منفي آهي. سچ، اهو اندازو ڪرڻ نسبتا ڏکيو آهي ته اهو ڇا آهي.
2016، ٻيو معزز ڪمپني، پڻ وڏو. اهو آخري ڪرچس کي پارس ڪري ٿو ۽ انهي کي ٺاهي ٿو ته هيش جيڪو اسان اڳ ۾ ترتيب ڏنو هو هاڻي هر SYN ريٽرانسمٽ تي ۽ هر RTO وقت ختم ٿيڻ کان پوء تبديل ڪيو ويو آهي. ۽ هن خط ۾، پهريون ۽ آخري وقت لاء، حتمي مقصد آواز آهي - انهي ڳالهه کي يقيني بڻائڻ ته چينلن جي نقصان يا اوورلوڊ جي صورت ۾ ٽرئفڪ کي ڪيترن ئي رستن کي استعمال ڪندي، نرم ري روٽنگ جو امڪان آهي. يقينن، ان کان پوء اتي ڪيترائي اشاعت هئا، توهان انهن کي آساني سان ڳولي سگهو ٿا.
جيتوڻيڪ نه، توهان نٿا ڪري سگهو، ڇو ته هن موضوع تي هڪ به اشاعت نه ڪئي وئي آهي. پر اسان ڄاڻون ٿا!
۽ جيڪڏھن توھان مڪمل طور تي نه سمجھو ته ڇا ڪيو ويو آھي، مان توھان کي ھاڻي ٻڌائيندس.
ڇا ڪيو ويو آهي، لينڪس ڪنيل ۾ ڪهڙي ڪارڪردگي شامل ڪئي وئي آهي؟ txhash هر RTO ايونٽ کان پوءِ بي ترتيب قدر ۾ تبديل ٿي ويندي آهي. اهو ساڳيو منفي رستي جو نتيجو آهي. هيش هن txhash تي منحصر آهي ۽ فلو ليبل skb hash تي منحصر آهي. هتي ڪمن تي ڪجهه حساب ڪتاب آهن، سڀئي تفصيل هڪ سلائڊ تي رکيل نه ٿو ڪري سگهجي. جيڪڏهن ڪو به شوقين آهي، ته توهان ڪريل ڪوڊ ذريعي وڃو ۽ چيڪ ڪري سگهو ٿا.
هتي ڇا اهم آهي؟ فلو ليبل فيلڊ جو قدر هر RTO کان پوءِ بي ترتيب نمبر ۾ تبديل ٿئي ٿو. اهو ڪيئن متاثر ڪري ٿو اسان جي بدقسمت TCP وهڪرو؟
SACK جي صورت ۾، ڪجھ به نه بدليو آھي ڇو ته اسان ڪوشش ڪري رھيا آھيون ھڪ گم ٿيل پيڪٽ ٻيهر موڪلڻ جي. هينئر تائين تمام سٺو.
پر RTO جي صورت ۾، مهيا ڪيو ويو آهي ته اسان ToR تي هيش فنڪشن ۾ فلو ليبل شامل ڪيو آهي، ٽرئفڪ هڪ مختلف رستو وٺي سگهي ٿو. ۽ وڌيڪ جهاز، وڌيڪ ممڪن آهي ته اهو رستو ڳولڻ لاء جيڪو ڪنهن خاص ڊوائيس تي حادثي کان متاثر نه ٿئي.
ھڪڙو مسئلو رھي ٿو - RTO. ٻيو رستو، يقينا، مليو آهي، پر ان تي گهڻو وقت خرچ ڪيو ويندو آهي. 200ms تمام گهڻو آهي. هڪ سيڪنڊ عام طور تي جهنگلي آهي. ان کان اڳ، مون ٽائم آئوٽ بابت ڳالهايو جيڪي خدمتون ترتيب ڏين ٿيون. تنهن ڪري، هڪ سيڪنڊ هڪ ٽائم آئوٽ آهي جيڪو عام طور تي ايپليڪيشن سطح تي هڪ خدمت قائم ڪري ٿو، ۽ انهي ۾ خدمت به نسبتا صحيح هوندي. ان کان علاوه، مان ورجائي ٿو، هڪ جديد ڊيٽا سينٽر اندر حقيقي RTT تقريبا 1 مليسيڪنڊ آهي.
RTO ٽائم آئوٽ بابت ڇا ٿي سگھي ٿو؟ ڊيٽا پيڪيٽ جي نقصان جي صورت ۾ RTO لاءِ ذميوار وقت ختم ٿي سگھي ٿو نسبتا آساني سان صارف جي جاءِ مان ترتيب ڏئي سگهجي ٿو: اتي هڪ IP يوٽيلٽي آهي، ۽ ان جو هڪ پيٽرول ساڳيو rto_min تي مشتمل آهي. انهي تي غور ڪندي، يقينا، توهان کي آر ٽي او کي عالمي سطح تي نه، پر ڏنل اڳڪٿين لاء، اهڙي ميڪانيزم کي ڪافي ڪم ڪندڙ نظر اچي ٿو.
سچ، SYN_RTO سان هر شيء ڪجهه خراب آهي. اهو قدرتي طور تي نيل آهي. قيمت بنيادي ۾ مقرر ڪئي وئي آهي - 1 سيڪنڊ، ۽ اهو آهي. توھان ان تائين رسائي نٿا ڪري سگھو صارف جي جڳھ کان. اتي رڳو هڪ طريقو آهي.
eBPF بچاء لاء اچي ٿو. آسانيءَ سان بيان ڪجي ته اهي ننڍا سي پروگرام آهن، انهن کي ڪنل اسٽيڪ ۽ ٽي سي پي اسٽيڪ جي عمل ۾ مختلف هنڌن تي ٿلهن ۾ داخل ڪري سگهجي ٿو، جنهن سان توهان وڏي تعداد ۾ سيٽنگ تبديل ڪري سگهو ٿا. عام طور تي، اي بي پي ايف هڪ ڊگهي مدت جو رجحان آهي. بجاء ڪيترن ئي نئين sysctl پيٽرولن کي ڏسڻ ۽ IP افاديت کي وڌائڻ جي بدران، تحريڪ eBPF جي هدايت ۾ آهي ۽ ان جي ڪارڪردگي کي وڌايو. eBPF سان، توھان متحرڪ طور تي ڪنجيشن ڪنٽرولز ۽ ٻيون مختلف TCP سيٽنگون تبديل ڪري سگھو ٿا.
پر اسان لاءِ اهو ضروري آهي ته ان جي مدد سان توهان SYN_RTO جي قدرن کي ٽوڙي سگهو ٿا. ۽ اتي ھڪڙو عوامي طور تي پوسٽ ڪيل مثال آھي: . هتي ڇا ڪيو ويو آهي؟ مثال ڪم ڪري رهيو آهي، پر پاڻ ۾ تمام خراب آهي. هتي فرض ڪيو ويو آهي ته ڊيٽا سينٽر جي اندر اسان پهرين 44 بٽس جو مقابلو ڪندا آهيون، جيڪڏهن اهي ملن ٿا، پوء اسان پاڻ کي ڊي سي جي اندر ڳوليندا آهيون. ۽ ھن حالت ۾، اسان SYN_RTO ٽائم آئوٽ جي قيمت 4ms ۾ تبديل ڪريون ٿا. اهو ساڳيو ڪم تمام گهڻي سهڻي نموني ڪري سگهجي ٿو. پر هي سادو مثال ڏيکاري ٿو ته ڇا آهي) ممڪن آهي؛ ب) نسبتا آسان.
اسان اڳ ۾ ئي ڇا ڄاڻون ٿا؟ اهو ته پلانر آرڪيٽيڪچر اسڪيلنگ جي اجازت ڏئي ٿو، اهو اسان لاءِ انتهائي ڪارائتو ثابت ٿيندو جڏهن اسان ToR تي فلو ليبل کي آن ڪندا آهيون ۽ مسئلن جي علائقن جي چوڌاري وهڻ جو موقعو حاصل ڪندا آهيون. RTO ۽ SYN-RTO قدرن کي گهٽائڻ جو بهترين طريقو آهي eBPF پروگرامن کي استعمال ڪرڻ. سوال رهي ٿو: ڇا توازن لاءِ فلو ليبل استعمال ڪرڻ محفوظ آهي؟ ۽ هتي هڪ nuance آهي.
فرض ڪريو توهان وٽ نيٽ ورڪ تي هڪ خدمت آهي جيڪا ڪنهن به ڪاسٽ ۾ رهي ٿي. بدقسمتي سان، مون وٽ وقت نه آهي ته ڪنهن به ڪاسٽ بابت تفصيل ۾ وڃو، پر اهو هڪ ورهايل خدمت آهي جتي مختلف جسماني سرور ساڳئي IP پتي تي موجود آهن. ۽ هتي هڪ ممڪن مسئلو آهي: آر ٽي او واقعو ٿي سگهي ٿو نه رڳو جڏهن ٽريفڪ ڪارخاني مان گذري ٿو. اهو ToR بفر جي سطح تي پڻ ٿي سگهي ٿو: جڏهن هڪ incast واقع ٿئي ٿي، اهو ميزبان تي به ٿي سگهي ٿو جڏهن ميزبان ڪجهه اسپيل ڪري ٿو. جڏهن هڪ RTO واقعو ٿئي ٿو ۽ اهو فلو ليبل تبديل ڪري ٿو. انهي صورت ۾، ٽرئفڪ ڪنهن ٻئي ڪنهن به مثال ڏانهن وڃو. فرض ڪريو اهو هڪ رياستي ڪاسٽ آهي، ان ۾ ڪنيڪشن اسٽيٽ شامل آهي - اهو ٿي سگهي ٿو L3 بيلنسر يا ڪا ٻي خدمت. پوء هڪ مسئلو پيدا ٿئي ٿو، ڇاڪاڻ ته RTO کان پوء، TCP ڪنيڪشن سرور تي اچي ٿو، جيڪو هن TCP ڪنيڪشن بابت ڪجھ به نٿو ڄاڻي. ۽ جيڪڏهن اسان وٽ ڪنهن به ڪاسٽ سرور جي وچ ۾ رياستي شيئرنگ نه آهي، ته پوءِ اهڙي ٽريفڪ ختم ٿي ويندي ۽ TCP ڪنيڪشن ٽٽي ويندو.
هتي ڇا ڪري سگهجي ٿو؟ توهان جي ڪنٽرول ٿيل ماحول ۾، جتي توهان فلو ليبل بيلنس کي فعال ڪريو ٿا، توهان کي فلو ليبل جي قيمت کي درست ڪرڻ جي ضرورت آهي جڏهن ڪنهن به ڪاسٽ سرور تائين رسائي حاصل ڪريو. آسان طريقو اهو آهي ته اهو ساڳيو اي بي پي ايف پروگرام ذريعي ڪيو وڃي. پر هتي هڪ تمام اهم نقطو آهي - ڇا ڪجي جيڪڏهن توهان ڊيٽا سينٽر نيٽ ورڪ نه هلائيندا آهيو، پر هڪ ٽيليڪ آپريٽر آهيو؟ اهو توهان جو مسئلو پڻ آهي: جونيپر ۽ ارسٽا جي ڪجهه نسخن سان شروع ڪندي، انهن ۾ فلو ليبل شامل آهن هيش فنڪشن ۾ ڊفالٽ - ايماندار هجڻ جي، بغير ڪنهن سبب جي مان سمجهان ٿو. اهو توهان جي نيٽ ورڪ ذريعي وڃڻ وارن صارفين کان TCP ڪنيڪشن ڇڏڻ جو سبب بڻجي سگهي ٿو. تنهن ڪري، مان هن جڳهه تي توهان جي روٽر سيٽنگن کي جانچڻ جي صلاح ڏيان ٿو.
هڪ طريقو يا ٻيو، اهو مون کي لڳي ٿو ته اسان تجربن ڏانهن وڃڻ لاء تيار آهيون.
جڏهن اسان ToR تي فلو ليبل تي ڦيرايو، ايجنٽ جي eBPF تيار ڪئي، جيڪو هاڻي ميزبان تي رهي ٿو، اسان فيصلو ڪيو ته ايندڙ وڏي ناڪامي جو انتظار نه ڪنداسين، پر ڪنٽرول ٿيل ڌماڪن کي هلائڻ لاء. اسان ToR ورتو، جنهن ۾ چار اپ لنڪس آهن، ۽ انهن مان هڪ تي ڊراپ ٺاهيون. انهن هڪ قاعدو ٺاهيو، انهن چيو - هاڻي توهان سڀ پيٽ وڃائي رهيا آهيو. جيئن توهان کاٻي پاسي ڏسي سگهو ٿا، اسان وٽ في پيڪيٽ مانيٽرنگ آهي، جيڪا 75 سيڪڙو تائين گهٽجي وئي آهي، يعني 25 سيڪڙو پيڪيٽ گم ٿي ويا آهن. ساڄي پاسي هن ToR جي پويان رهندڙ خدمتن جا گراف آهن. حقيقت ۾، اهي ٽريفڪ گرافس آهن جوڑوں جي سرور سان گڏ ريڪ اندر. جئين توهان ڏسي سگهو ٿا، اهي اڃا به گهٽ ٿي ويا آهن. اهي ڇو هيٺ لهي ويا - 25 سيڪڙو نه، پر ڪجهه ڪيسن ۾ 3-4 ڀيرا؟ جيڪڏهن TCP ڪنيڪشن ناجائز آهي، اهو ٽوٽل انٽرفيس ذريعي پهچڻ جي ڪوشش جاري رکي ٿو. اهو ڊي سي جي اندر خدمت جي عام رويي جي ڪري وڌايو ويو آهي - هڪ صارف جي درخواست لاء، اندروني خدمتن لاء N درخواستون ٺاهيا ويندا آهن، ۽ جواب صارف ڏانهن ويندا، يا ته جڏهن سڀ ڊيٽا جا ذريعا جواب ڏين، يا جڏهن هڪ ٽائم آئوٽ شروع ٿئي. ايپليڪيشن جي سطح، جنهن کي اڃا تائين ترتيب ڏيڻ جي ضرورت آهي. اهو آهي، هر شيء تمام، تمام خراب آهي.
ھاڻي ساڳيو تجربو، پر فلو ليبل سان فعال. جئين توهان ڏسي سگهو ٿا، کاٻي پاسي، اسان جي بيچ جي نگراني ساڳئي 25٪ طرفان ٻڏي وئي. اهو بلڪل صحيح آهي، ڇاڪاڻ ته اهو retransmits جي باري ۾ ڪجھ به نه ڄاڻندو آهي، اهو پيڪٽ موڪليندو آهي ۽ صرف ترسيل ۽ گم ٿيل پيڪٽس جي تعداد جي تناسب کي شمار ڪري ٿو.
۽ ساڄي پاسي سروسز جو شيڊول آهي. توهان هتي هڪ مسئلو گڏيل جو اثر نه لھندين. ٽريفڪ انهن ساڳين مليسيڪينڊن ۾ مسئلي واري علائقي مان وهندي رهي ٿي باقي ٽي اپ لنڪس جيڪي مسئلي کان متاثر نه ٿيا هئا. اسان وٽ ھڪڙو نيٽ ورڪ آھي جيڪو پاڻ کي شفا ڏيندو آھي.
هي منهنجي آخري سلائڊ آهي، اسٽاڪ وٺڻ جو وقت. هاڻي، مون کي اميد آهي ته توهان ڄاڻو ٿا ته هڪ خود شفا جي ڊيٽا سينٽر نيٽ ورڪ ڪيئن ٺاهيو. توهان کي لينڪس ڪنيل آرڪائيو ذريعي وڃڻ جي ضرورت نه پوندي ۽ اتي خاص پيچ ڳولڻ جي ضرورت پوندي، توهان کي خبر آهي ته فلو ليبل هن معاملي ۾ مسئلو حل ڪري ٿو، پر توهان کي هن ميکانيزم کي احتياط سان ڏسڻ جي ضرورت آهي. ۽ مان ٻيهر زور ڏيان ٿو ته جيڪڏهن توهان ڪيريئر آهيو، توهان کي فلو ليبل کي هيش فنڪشن جي طور تي استعمال نه ڪرڻ گهرجي، ٻي صورت ۾ توهان پنهنجي صارفين جي سيشن کي ٽوڙي ڇڏيندا.
نيٽ ورڪ انجنيئرن لاءِ، هڪ تصوراتي شفٽ ٿيڻ جي ضرورت آهي: نيٽ ورڪ ToR سان شروع نٿو ٿئي، نيٽ ورڪ ڊيوائس سان نه، پر ميزبان سان. هڪ انتهائي شاندار مثال اهو آهي ته اسان ڪيئن استعمال ڪريون ٿا eBPF ٻنهي کي RTO کي تبديل ڪرڻ ۽ فلو ليبل کي درست ڪرڻ لاءِ ڪنهن به ڪاسٽ سروسز ڏانهن.
فلو ليبل ميڪيڪڪ يقيني طور تي ڪنٽرول ٿيل انتظامي حصي ۾ ٻين استعمالن لاءِ مناسب آهي. اهو ڊيٽا سينٽرن جي وچ ۾ ٽرئفڪ ٿي سگهي ٿو، يا توهان ٻاهر نڪرڻ واري ٽرئفڪ کي ڪنٽرول ڪرڻ لاء خاص طريقي سان استعمال ڪري سگهو ٿا. پر مان ان بابت ڳالهائيندس، اميد اٿم، ايندڙ وقت. توهان جي توجه لاء تمام گهڻو مهرباني.
جو ذريعو: www.habr.com