هي هڪ ڊگهي ڪهاڻي جو تسلسل آهي اسان جي ٿلهي رستي جي باري ۾ هڪ طاقتور، تيز لوڊ سسٽم ٺاهڻ لاءِ جيڪو ايڪسچينج جي آپريشن کي يقيني بڻائي ٿو. پهريون حصو هتي آهي:
پراسرار غلطي
ڪيترن ئي تجربن کان پوء، تازه ڪاري واپار ۽ صاف ڪرڻ وارو نظام آپريشن ۾ رکيو ويو، ۽ اسان کي هڪ بگ مليو جنهن جي باري ۾ اسان هڪ جاسوسي-صوفي ڪهاڻي لکي سگهون ٿا.
مکيه سرور تي شروع ٿيڻ کان ٿوري دير کان پوء، ھڪڙي ٽرانزيڪشن تي عمل ڪيو ويو ھڪڙي غلطي سان. بهرحال، بيڪ اپ سرور تي سڀ ڪجھ ٺيڪ هو. اهو ظاهر ٿيو ته مکيه سرور تي ايڪسپينٽ کي ڳڻڻ جي هڪ سادي رياضياتي آپريشن حقيقي دليل کان منفي نتيجو ڏنو! اسان پنھنجي تحقيق کي جاري رکيو، ۽ SSE2 رجسٽر ۾ اسان کي ھڪڙي بٽ ۾ فرق مليو، جيڪو سچل پوائنٽ نمبرن سان ڪم ڪرڻ وقت گول ڪرڻ جو ذميوار آھي.
اسان هڪ سادي ٽيسٽ يوٽيلٽي لکيو آهي جنهن کي گول ڪرڻ واري بٽ سيٽ سان ايڪسپونٽ کي ڳڻڻ لاءِ. اهو ظاهر ٿيو ته RedHat Linux جي نسخي ۾ جيڪو اسان استعمال ڪيو، اتي رياضياتي فنڪشن سان ڪم ڪرڻ ۾ هڪ خرابي هئي جڏهن خراب قسمت بٽ داخل ڪيو ويو. اسان RedHat کي اها خبر ڏني، ٿوري دير کان پوء اسان کي انهن کان هڪ پيچ مليو ۽ ان کي رول آئوٽ ڪيو. غلطي هاڻي نه ٿي آهي، پر اهو واضح ناهي ته اهو ساٽ ڪٿان آيو آهي؟ فنڪشن ان جي ذميواري هئي fesetround C ٻولي مان. اسان مبينا غلطي جي ڳولا ۾ اسان جي ڪوڊ جو احتياط سان تجزيو ڪيو: اسان سڀني ممڪن حالتن جي جانچ ڪئي؛ سڀني ڪمن کي ڏٺو جيڪو گولنگ استعمال ڪيو؛ ناڪام سيشن کي ٻيهر پيدا ڪرڻ جي ڪوشش ڪئي؛ استعمال ڪيو ويو مختلف compilers مختلف اختيارن سان؛ جامد ۽ متحرڪ تجزيو استعمال ڪيو ويو.
غلطي جو سبب معلوم نه ٿي سگهيو.
پوءِ انهن هارڊويئر کي جانچڻ شروع ڪيو: انهن پروسيسرز جي لوڊ ٽيسٽ ڪئي. رام چيڪ ڪيو؛ اسان هڪ سيل ۾ گھڻ-بٽ غلطي جي بلڪل ممڪن صورتحال لاءِ ٽيسٽون به ڪيون. ڪو فائدو نه ٿيو.
آخر ۾، اسان هاءِ انرجي فزڪس جي دنيا جي هڪ نظريي تي قائم ٿياسين: ڪجهه اعليٰ توانائي وارو ذرڙو اسان جي ڊيٽا سينٽر ۾ اڏامي ويو، ڪيس جي ڀت کي ڇهيو، پروسيسر کي ڌڪ هنيو ۽ ٽريگر لچ کي ان ئي حصي ۾ لٺ ڪرڻ جو سبب بڻيو. هن بيڪار نظريي کي ”نيوٽرينو“ سڏيو ويو. جيڪڏهن توهان ذرات جي فزڪس کان پري آهيو: نيوٽرينوس تقريبن ٻاهرئين دنيا سان رابطو نه ڪندا آهن، ۽ يقيني طور تي پروسيسر جي آپريشن کي متاثر ڪرڻ جي قابل نه هوندا آهن.
ڇاڪاڻ ته اهو ممڪن نه هو ته ناڪامي جو سبب ڳولڻ، "جرح ڪندڙ" سرور صرف صورت ۾ آپريشن کان هٽايو ويو.
ڪجهه وقت کان پوء، اسان گرم بيڪ اپ سسٽم کي بهتر ڪرڻ شروع ڪيو: اسان نام نهاد "گرم ذخيرا" (گرم) متعارف ڪرايو - asynchronous replicas. انهن ٽرانزيڪشن جو هڪ وهڪرو حاصل ڪيو جيڪو مختلف ڊيٽا سينٽرن ۾ واقع ٿي سگهي ٿو، پر گرمي ٻين سرورن سان فعال طور تي رابطو نه ڪيو.
ائين ڇو ڪيو ويو؟ جيڪڏهن بيڪ اپ سرور ناڪام ٿئي ٿو، ته پوء گرم سان ڳنڍيل مکيه سرور سان نئون بيڪ اپ بڻجي ويندو آهي. اهو آهي، هڪ ناڪامي کان پوء، سسٽم هڪ مکيه سرور سان نه رهي جيستائين واپاري سيشن جي آخر تائين.
۽ جڏهن سسٽم جو نئون نسخو آزمائيو ويو ۽ آپريشن ۾ رکيو ويو، گولنگ بٽ غلطي ٻيهر ٿي وئي. ان کان علاوه، گرم سرورن جي تعداد ۾ اضافو سان، غلطي اڪثر ظاهر ٿيڻ لڳو. ساڳئي وقت، وينڊر کي ڏيکارڻ لاء ڪجھ به نه هو، ڇاڪاڻ ته ڪو به ٺوس ثبوت نه هو.
صورتحال جي ايندڙ تجزيي دوران، هڪ نظريو پيدا ٿيو ته مسئلو او ايس سان لاڳاپيل ٿي سگهي ٿو. اسان هڪ سادي پروگرام لکيو آهي جيڪو هڪ فنکشن کي لامحدود لوپ ۾ سڏي ٿو fesetround، موجوده حالت کي ياد ڪري ٿو ۽ ان کي ننڊ ذريعي چيڪ ڪري ٿو، ۽ اهو ڪيترن ئي مقابلي واري سلسلي ۾ ڪيو ويندو آهي. سمهڻ لاءِ پيرا ميٽرز ۽ سلسلن جو تعداد چونڊڻ کان پوءِ، اسان يوٽيليٽي کي هلائڻ جي اٽڪل 5 منٽن کان پوءِ بٽ ناڪامي کي مسلسل ٻيهر پيدا ڪرڻ شروع ڪيو. بهرحال، Red Hat سپورٽ ان کي ٻيهر پيدا ڪرڻ جي قابل نه هئي. اسان جي ٻين سرورن جي جاچ پڌري ڪئي وئي آهي ته صرف اهي جيڪي ڪجهه خاص پروسيسرز سان گڏ غلطي لاء حساس آهن. ساڳئي وقت، هڪ نئين ڪنييل ڏانهن سوئچنگ مسئلو حل ڪيو. آخر ۾، اسان صرف او ايس کي تبديل ڪيو، ۽ بگ جو حقيقي سبب واضح نه رهيو.
۽ اوچتو گذريل سال Habré تي هڪ مضمون شايع ٿيو." ان ۾ بيان ڪيل صورتحال اسان جي بلڪل ساڳي هئي، پر مصنف تحقيق کي اڳتي وڌايو ۽ هڪ نظريو پيش ڪيو ته غلطي مائڪرو ڪوڊ ۾ هئي. ۽ جڏهن لينڪس ڪنيلز کي اپڊيٽ ڪيو ويو آهي، ٺاهيندڙن کي مائڪرو ڪوڊ پڻ اپڊيٽ ڪندا آهن.
سسٽم جي وڌيڪ ترقي
جيتوڻيڪ اسان غلطي کان نجات حاصل ڪئي، هن ڪهاڻي اسان کي سسٽم جي فن تعمير تي ٻيهر غور ڪرڻ تي مجبور ڪيو. آخرڪار، اسان اهڙين ڪيڙن جي ورجائي کان محفوظ نه هئاسين.
هيٺيون اصول رزرويشن سسٽم ۾ ايندڙ سڌارن لاءِ بنياد بڻيا:
- توهان ڪنهن تي اعتبار نه ٿا ڪري سگهو. سرور صحيح ڪم نه ڪري سگھن ٿا.
- اڪثريت رزرويشن.
- اتفاق راءِ کي يقيني بڻائڻ. اڪثريت رزرويشن لاء هڪ منطقي اضافو جي طور تي.
- ٻيڻو ناڪامي ممڪن آهي.
- حياتياتي. نئين گرم اسٽينڊ بائي اسڪيم پوئين هڪ کان وڌيڪ خراب نه هجڻ گهرجي. آخري سرور تائين واپار کي بغير بغير اڳتي وڌڻ گهرجي.
- ويڪرائي ۾ ٿورو اضافو. ڪو به بند وقت وڏو مالي نقصان داخل ڪري ٿو.
- گھٽ ۾ گھٽ نيٽ ورڪ رابطي کي ممڪن طور تي گھٽ ۾ گھٽ رکڻ لاء.
- سيڪنڊن ۾ نئون ماسٽر سرور چونڊيو.
مارڪيٽ تي موجود حلن مان ڪو به اسان لاءِ مناسب نه هو، ۽ رافٽ پروٽوڪول اڃا پنهنجي ابتدائي دور ۾ هو، تنهن ڪري اسان پنهنجو حل ٺاهيو.
نيٽ ورڪنگ
رزرويشن سسٽم کان علاوه، اسان نيٽ ورڪ رابطي کي جديد ڪرڻ شروع ڪيو. I/O سبسسٽم ڪيترن ئي عملن تي مشتمل هو، جن جو تمام گهڻو اثر خرابي ۽ ويڪرائي تي پيو. ٽي سي پي ڪنيڪشن کي هٿي وٺرائڻ لاءِ سوين عملن سان، اسان کي مسلسل انهن جي وچ ۾ مٽجڻ تي مجبور ڪيو ويو، ۽ مائڪرو سيڪنڊ اسڪيل تي اهو هڪ بلڪه وقت وٺڻ وارو آپريشن آهي. پر بدترين حصو اهو آهي ته جڏهن هڪ پروسيسنگ پروسيسنگ لاء هڪ پيڪٽ حاصل ڪيو، اهو ان کي هڪ سسٽم وي قطار ڏانهن موڪليو ۽ پوء هڪ ٻئي سسٽم وي قطار مان هڪ واقعي جو انتظار ڪيو. بهرحال، جڏهن نوڊس جو وڏو تعداد هوندو آهي، هڪ عمل ۾ نئين TCP پيڪيٽ جي آمد ۽ ٻئي ۾ قطار ۾ ڊيٽا جي وصولي OS لاءِ ٻه مقابلي واري واقعن جي نمائندگي ڪن ٿا. انهي صورت ۾، جيڪڏهن ٻنهي ڪمن لاء ڪو به جسماني پروسيسر موجود نه آهي، هڪ پروسيس ڪيو ويندو، ۽ ٻيو هڪ انتظار جي قطار ۾ رکيو ويندو. نتيجن جي اڳڪٿي ڪرڻ ناممڪن آهي.
اهڙين حالتن ۾، متحرڪ عمل جي ترجيحي ڪنٽرول استعمال ڪري سگهجي ٿي، پر ان لاءِ وسيلن جي استعمال جي ضرورت هوندي سسٽم ڪالن جي. نتيجي طور، اسان کلاسک ايپول استعمال ڪندي ھڪڙي سلسلي ۾ تبديل ڪيو، ھن رفتار کي تمام گھڻو وڌايو ۽ ٽرانزيڪشن پروسيسنگ وقت گھٽائي ڇڏيو. اسان سسٽم وي ذريعي الڳ نيٽ ورڪ ڪميونيڪيشن پروسيسز ۽ ڪميونيڪيشن کان به نجات حاصل ڪئي، سسٽم ڪالز جي تعداد ۾ نمايان طور تي گهٽتائي ڪئي ۽ آپريشن جي ترجيحن کي ڪنٽرول ڪرڻ شروع ڪيو. اڪيلو I/O سب سسٽم تي، اهو ممڪن هو ته 8-17 مائڪرو سيڪنڊن کي بچائڻ لاء، منظر جي لحاظ کان. هي سنگل ٿريڊ اسڪيم ان وقت کان وٺي اڻ مٽ استعمال ڪيو ويو آهي؛ هڪ ايپول ٿريڊ مارجن سان سڀني ڪنيڪشن جي خدمت لاءِ ڪافي آهي.
ٽرانزيڪشن پروسيسنگ
اسان جي سسٽم تي وڌندڙ لوڊ لڳ ڀڳ سڀني حصن کي اپڊيٽ ڪرڻ جي ضرورت آهي. پر، بدقسمتي سان، تازو سالن ۾ پروسيسر جي گھڙي جي رفتار جي واڌ ۾ جمود هاڻي ان کي ممڪن نه ڪيو آهي ته پروسيس جي سر تي پيماني تي. تنهن ڪري، اسان انجڻ جي عمل کي ٽن سطحن ۾ ورهائڻ جو فيصلو ڪيو، انهن مان مصروف ترين آهي خطري جي چڪاس جو نظام، جيڪو اڪائونٽن ۾ فنڊن جي دستيابي جو جائزو وٺي ٿو ۽ پاڻ ٽرانزيڪشن ٺاهي ٿو. پر پئسا مختلف ڪرنسي ۾ ٿي سگهي ٿو، ۽ اهو معلوم ڪرڻ ضروري هو ته ڪهڙي بنياد تي درخواستن جي پروسيسنگ کي ورهايو وڃي.
منطقي حل اهو آهي ته ان کي ڪرنسي جي ذريعي ورهايو وڃي: هڪ سرور ڊالر ۾ واپار ڪندو آهي، ٻيو پائونڊ ۾، ۽ ٽيون يورو ۾. پر جيڪڏهن، اهڙي اسڪيم سان، ٻه ٽرانزيڪشن مختلف ڪرنسي خريد ڪرڻ لاءِ موڪليا وڃن ٿا، ته پوءِ والٽ ڊسيڪرونائيزيشن جو مسئلو پيدا ٿيندو. پر هم وقت سازي ڏکيو ۽ قيمتي آهي. تنهن ڪري، اهو صحيح ٿيندو ته شارڊ الڳ الڳ پرس ذريعي ۽ الڳ الڳ اوزار سان. رستي ۾، اڪثر مغربي ايڪسچينجز وٽ خطرن کي جانچڻ جو ڪم نه آهي جيترو اسان ڪندا آهيون، تنهنڪري اڪثر ڪري اهو آف لائن ڪيو ويندو آهي. اسان کي آن لائن تصديق لاڳو ڪرڻ جي ضرورت آهي.
اچو ته هڪ مثال سان وضاحت ڪريون. هڪ واپاري $30 خريد ڪرڻ چاهي ٿو، ۽ درخواست ٽرانزيڪشن جي تصديق ڏانهن وڃي ٿي: اسان چيڪ ڪريون ٿا ته ڇا هن تاجر کي هن تجارتي موڊ جي اجازت آهي ۽ ڇا هن وٽ ضروري حق آهن. جيڪڏهن سڀ ڪجهه ترتيب ۾ آهي، درخواست خطري جي تصديق واري نظام ڏانهن وڃي ٿي، يعني. هڪ ٽرانزيڪشن کي ختم ڪرڻ لاء فنڊ جي ڪافي مقدار کي جانچڻ لاء. اتي هڪ نوٽ آهي ته گهربل رقم هن وقت بلاڪ آهي. درخواست وري واپار واري نظام ڏانهن موڪلي وئي آهي، جيڪو ٽرانزيڪشن کي منظور يا رد ڪري ٿو. اچو ته چئو ته ٽرانزيڪشن منظور ٿيل آهي - پوء خطري جي تصديق واري نظام کي نشان لڳايو ويو آهي ته پئسا انلاڪ ٿيل آهي، ۽ روبل ڊالر ۾ تبديل ٿي ويا آهن.
عام طور تي، خطري جي چڪاس واري نظام ۾ پيچيده الگورتھم شامل آهن ۽ وڏي مقدار ۾ تمام گهڻي وسيلن جي حسابن کي انجام ڏئي ٿو، ۽ صرف "اڪائونٽ بيلنس" کي چيڪ نٿو ڪري، جيئن اهو پهرين نظر ۾ لڳي سگهي ٿو.
جڏهن اسان انجڻ جي عمل کي سطحن ۾ ورهائڻ شروع ڪيو، اسان کي هڪ مسئلو پيش آيو: ڪوڊ جيڪو ان وقت موجود هو، فعال طور تي ڊيٽا جي ساڳي صف کي تصديق ۽ تصديق جي مرحلن تي استعمال ڪيو، جنهن کي پوري ڪوڊ بيس کي ٻيهر لکڻ جي ضرورت هئي. نتيجي طور، اسان جديد پروسيسرز کان هدايتون پروسيسنگ لاء هڪ ٽيڪنڪ قرض ورتو آهي: انهن مان هر هڪ کي ننڍن مرحلن ۾ ورهايو ويو آهي ۽ ڪيترن ئي ڪارناما هڪ چڪر ۾ متوازي طور تي ڪيا ويا آهن.
ڪوڊ جي ننڍڙي موافقت کان پوء، اسان متوازي ٽرانزيڪشن پروسيسنگ لاء هڪ پائپ لائن ٺاهي، جنهن ۾ ٽرانزيڪشن کي پائپ لائن جي 4 مرحلن ۾ ورهايو ويو: نيٽ ورڪ رابطي، تصديق، عملدرآمد ۽ نتيجن جي اشاعت.
اچو ته هڪ مثال ڏسو. اسان وٽ ٻه پروسيسنگ سسٽم آهن، سيريل ۽ متوازي. پهريون ٽرانزيڪشن اچي ٿو ۽ ٻنهي سسٽم ۾ تصديق لاءِ موڪليو ويو آهي. ٻيو ٽرانزيڪشن فوري طور تي اچي ٿو: هڪ متوازي نظام ۾ اهو فوري طور تي ڪم ڪرڻ لاء ورتو ويو آهي، ۽ هڪ ترتيب واري نظام ۾ اهو هڪ قطار ۾ رکيل آهي پهرين ٽرانزيڪشن جي موجوده پروسيسنگ اسٽيج ذريعي وڃڻ جي انتظار ۾. اهو آهي، پائپ لائن پروسيسنگ جو بنيادي فائدو اهو آهي ته اسان ٽرانزيڪشن جي قطار کي تيزيء سان پروسيس ڪندا آهيون.
اهو ڪيئن آهي اسان ASTS + سسٽم سان گڏ آيا آهيون.
سچ، نه ته هر شيءِ ڪنويرز سان ايتري هموار آهي. اچو ته چئو ته اسان وٽ هڪ ٽرانزيڪشن آهي جيڪو پاڙيسري ٽرانزيڪشن ۾ ڊيٽا جي صفن کي متاثر ڪري ٿو؛ هي هڪ بدلي لاء هڪ عام صورتحال آهي. اهڙي ٽرانزيڪشن کي پائيپ لائين ۾ نه ٿو ڪري سگهجي ڇاڪاڻ ته اهو ٻين کي متاثر ڪري سگهي ٿو. هن صورتحال کي ڊيٽا جو خطرو سڏيو ويندو آهي، ۽ اهڙيون ٽرانزيڪشن کي الڳ الڳ پروسيس ڪيو ويندو آهي: جڏهن قطار ۾ "تيز" ٽرانزيڪشن ختم ٿي وڃي ٿي، پائپ لائن بند ٿي وڃي ٿي، سسٽم "سست" ٽرانزيڪشن کي پروسيس ڪري ٿو، ۽ پوء پائپ لائن ٻيهر شروع ٿئي ٿو. خوشقسمتيءَ سان، مجموعي وهڪري ۾ اهڙين ٽرانزيڪشن جو تناسب تمام ننڍڙو آهي، تنهن ڪري پائيپ لائين تمام گهٽ رڪجي ٿي ته اهو مجموعي ڪارڪردگيءَ تي اثر انداز نه ٿئي.
ان کان پوء اسان عملدرآمد جي ٽن موضوعن کي هم وقت سازي جي مسئلي کي حل ڪرڻ شروع ڪيو. نتيجو هڪ سسٽم هو جيڪو هڪ انگوزي بفر جي بنياد تي مقرر ٿيل سائيز سيلز سان. هن سسٽم ۾، هر شي پروسيسنگ جي رفتار جي تابع آهي؛ ڊيٽا نقل نه ڪئي وئي آهي.
- سڀ ايندڙ نيٽ ورڪ پيڪيٽ مختص ڪرڻ واري مرحلي ۾ داخل ٿين ٿا.
- اسان انھن کي ھڪڙي صف ۾ رکون ٿا ۽ انھن کي نشان لڳايو جيئن اسٽيج # 1 لاءِ دستياب آھي.
- ٻيو ٽرانزيڪشن اچي چڪو آهي، اهو ٻيهر اسٽيج نمبر 1 لاء دستياب آهي.
- پهريون پروسيسنگ ٿريڊ موجود ٽرانزيڪشن کي ڏسي ٿو، انهن کي پروسيس ڪري ٿو، ۽ انهن کي ٻئي پروسيسنگ سلسلي جي ايندڙ اسٽيج تي منتقل ڪري ٿو.
- اهو وري پهرين ٽرانزيڪشن کي پروسيس ڪري ٿو ۽ لاڳاپيل سيل کي پرچم ڏئي ٿو
deleted- اهو هاڻي نئين استعمال لاء دستياب آهي.
سڄي قطار کي هن طريقي سان عمل ڪيو ويندو آهي.
هر اسٽيج جي پروسيسنگ ۾ يونٽ يا ڏهه مائڪرو سيڪنڊن جي ضرورت آهي. ۽ جيڪڏهن اسان معياري OS هم وقت سازي اسڪيمن کي استعمال ڪندا آهيون، ته پوءِ اسان پاڻ کي هم وقت سازي تي وڌيڪ وقت وڃائي ويهنداسين. ان ڪري اسان اسپن لاک استعمال ڪرڻ شروع ڪيو. بهرحال، اهو حقيقي وقت واري نظام ۾ تمام خراب فارم آهي، ۽ RedHat سختي سان اهو ڪرڻ جي سفارش نٿو ڪري، تنهنڪري اسان 100 ms لاء اسپن لاڪ لاڳو ڪريون ٿا، ۽ پوء بند ٿيڻ جي امڪان کي ختم ڪرڻ لاء سيمفور موڊ تي سوئچ ڪريو.
نتيجي طور، اسان في سيڪنڊ اٽڪل 8 ملين ٽرانزيڪشن جي ڪارڪردگي حاصل ڪئي. ۽ لفظي ٻن مهينن بعد LMAX Disruptor جي باري ۾ اسان ڏٺو ته هڪ سرڪٽ جي وضاحت ساڳي ڪارڪردگي سان.
ھاڻي ھڪڙي مرحلي تي عملدرآمد جا ڪيترائي سلسلا ٿي سگھن ٿا. سڀئي ٽرانزيڪشن هڪ هڪ ڪري عمل ڪيا ويا، ترتيب ۾ اهي وصول ڪيا ويا. نتيجي طور، چوٽي جي ڪارڪردگي 18 هزار کان 50 هزار ٽرانزيڪشن في سيڪنڊ تائين وڌي وئي.
مٽا سٽا خطري جي انتظام جو نظام
تڪميل جي ڪا به حد ناهي، ۽ جلد ئي اسان ٻيهر جديد ڪرڻ شروع ڪيو: ASTS+ جي فريم ورڪ جي اندر، اسان خطري جي انتظام ۽ آبادي جي آپريشن سسٽم کي خودمختيار حصن ۾ منتقل ڪرڻ شروع ڪيو. اسان هڪ لچڪدار جديد فن تعمير ۽ هڪ نئين درجه بندي خطري واري ماڊل کي ترقي ڪئي، ۽ ڪوشش ڪئي ته ڪلاس کي استعمال ڪرڻ جي جتي ممڪن هجي. fixed_point بدران بدران double.
پر هڪ مسئلو فوري طور تي پيدا ٿيو: سڀني ڪاروباري منطق کي هم وقت سازي ڪيئن ڪجي جيڪو ڪيترن سالن کان ڪم ڪري رهيو آهي ۽ ان کي نئين سسٽم ڏانهن منتقل ڪيو وڃي؟ نتيجي طور، نئين نظام جي prototype جو پهريون نسخو ڇڏي ڏنو وڃي ها. ٻيو نسخو، جيڪو هن وقت پيداوار ۾ ڪم ڪري رهيو آهي، ساڳئي ڪوڊ تي ٻڌل آهي، جيڪو واپار ۽ خطري جي حصن ۾ ڪم ڪري ٿو. ترقي جي دوران، ڪرڻ لاء سڀ کان ڏکيو ڪم ٻن نسخن جي وچ ۾ گيٽ ملائي ويو. اسان جي ساٿي Evgeniy Mazurenok هن آپريشن کي هر هفتي ڪيو ۽ هر ڀيري هن هڪ ڊگهي وقت تائين لعنت ڪئي.
جڏهن هڪ نئون نظام چونڊيو، اسان کي فوري طور تي رابطي جو مسئلو حل ڪرڻو پوندو. جڏهن ڊيٽا بس چونڊيو، اهو ضروري هو ته مستحڪم جٽ ۽ گهٽ ۾ گهٽ ويڪرائي کي يقيني بڻائي. InfiniBand RDMA نيٽورڪ ھن لاءِ بھترين موزون ھو: اوسط پروسيسنگ وقت 4 G Ethernet نيٽ ورڪن جي ڀيٽ ۾ 10 ڀيرا گھٽ آھي. پر ڇا واقعي اسان کي متاثر ڪيو سيڪڙو ۾ فرق هو - 99 ۽ 99,9.
يقينا، InfiniBand ان جا چئلينج آهن. پهرين، هڪ مختلف API - ساکٽ جي بدران ibverbs. ٻيو، اتي تقريبن ڪو به وسيع طور تي دستياب ناهي اوپن سورس پيغام رسائيندڙ حل. اسان پنهنجو پروٽوٽائپ ٺاهڻ جي ڪوشش ڪئي، پر اهو تمام ڏکيو ثابت ٿيو، تنهنڪري اسان هڪ تجارتي حل چونڊيو - Confinity Low Latency Messaging (اڳوڻي IBM MQ LLM).
ان کان پوء خطري جي نظام کي صحيح طور تي ورهائڻ جو ڪم پيدا ٿيو. جيڪڏهن توهان صرف خطري انجڻ کي هٽائي ڇڏيو ۽ هڪ وچولي نوڊ نه ٺاهي، پوء ٻن ذريعن کان ٽرانزيڪشن ملائي سگهجي ٿو.
نام نهاد الٽرا لو ليٽيسي حلن ۾ ري آرڊرنگ موڊ آهي: ٻن ذريعن مان ٽرانزيڪشن گهربل ترتيب ۾ ترتيب ڏئي سگهجي ٿي وصولي تي؛ اهو آرڊر بابت معلومات جي تبادلي لاءِ هڪ الڳ چينل استعمال ڪندي لاڳو ڪيو ويندو آهي. پر اسان اڃا تائين هن موڊ کي استعمال نه ڪيو آهي: اهو سڄي عمل کي پيچيده ڪري ٿو، ۽ ڪيترن ئي حلن ۾ اهو سڀ ڪجهه سپورٽ ناهي. ان کان علاوه، هر ٽرانزيڪشن کي لاڳاپيل ٽائم اسٽيمپ مقرر ڪرڻو پوندو، ۽ اسان جي اسڪيم ۾ هن ميڪانيزم کي صحيح طريقي سان لاڳو ڪرڻ تمام ڏکيو آهي. تنهن ڪري، اسان هڪ پيغام بروکر سان گڏ کلاسک اسڪيم استعمال ڪيو، اهو آهي، هڪ موڪليندڙ سان جيڪو رسڪ انجڻ جي وچ ۾ پيغام ورهائي ٿو.
ٻيو مسئلو ڪلائنٽ جي رسائي سان لاڳاپيل هو: جيڪڏهن ڪيترائي رسڪ گيٽ ويز آهن، ڪلائنٽ کي انهن مان هر هڪ سان ڳنڍڻ جي ضرورت آهي، ۽ انهي کي ڪلائنٽ پرت ۾ تبديلين جي ضرورت پوندي. اسان هن اسٽيج تي هن کان پري ٿيڻ چاهيون ٿا، تنهنڪري موجوده خطري گيٽ وي ڊيزائن سڄي ڊيٽا وهڪرو کي پروسيس ڪري ٿو. هي تمام گهڻي حد تائين وڌ کان وڌ ان پٽ کي محدود ڪري ٿو، پر سسٽم جي انضمام کي تمام گهڻو آسان بڻائي ٿو.
نقل
اسان جي سسٽم کي ناڪامي جو هڪ نقطو نه هجڻ گهرجي، اهو آهي، سڀني اجزاء کي نقل ڪيو وڃي، پيغام بروکر سميت. اسان CLLM سسٽم استعمال ڪندي هن مسئلي کي حل ڪيو: اهو هڪ RCMS ڪلستر تي مشتمل آهي جنهن ۾ ٻه موڪليندڙ ماسٽر-غلام موڊ ۾ ڪم ڪري سگهن ٿا، ۽ جڏهن هڪ ناڪام ٿئي ٿو، سسٽم خودڪار طريقي سان ٻئي ڏانهن سوئچ ڪري ٿو.
بيڪ اپ ڊيٽا سينٽر سان ڪم ڪرڻ
InfiniBand هڪ مقامي نيٽ ورڪ جي طور تي آپريشن لاءِ بهتر ڪيو ويو آهي، يعني ريڪ مائونٽ سامان کي ڳنڍڻ لاءِ، ۽ هڪ InfiniBand نيٽ ورڪ ٻن جاگرافيائي طور تي ورهايل ڊيٽا سينٽرن جي وچ ۾ قائم نٿو ڪري سگهجي. تنهن ڪري، اسان هڪ پل / ڊسپيچر تي عمل ڪيو، جيڪو باقاعده ايٿرنيٽ نيٽ ورڪ ذريعي پيغام اسٽوريج سان ڳنڍيندو آهي ۽ سڀني ٽرانزيڪشن کي سيڪنڊ IB نيٽ ورڪ ڏانهن رلي ٿو. جڏهن اسان کي ڊيٽا سينٽر مان لڏپلاڻ ڪرڻ جي ضرورت آهي، اسان اهو چونڊي سگھون ٿا ته ڪهڙو ڊيٽا سينٽر هاڻي ڪم ڪرڻ لاء.
نتيجو
مٿين سڀني کي هڪ ڀيرو نه ڪيو ويو؛ اهو هڪ نئين فن تعمير جي ترقي لاء ڪيترن ئي ورهاڱي ورتو. اسان هڪ مهيني ۾ پروٽوٽائپ ٺاهيو، پر ان کي ڪم ڪندڙ حالت ۾ آڻڻ ۾ ٻن سالن کان وڌيڪ وقت لڳي ويو. اسان ٽرانزيڪشن پروسيسنگ وقت وڌائڻ ۽ سسٽم جي اعتماد کي وڌائڻ جي وچ ۾ بهترين سمجھوتا حاصل ڪرڻ جي ڪوشش ڪئي.
جيئن ته سسٽم تمام گهڻو اپڊيٽ ڪيو ويو، اسان ٻن آزاد ذريعن کان ڊيٽا جي بحالي تي عمل ڪيو. جيڪڏهن پيغام جو اسٽور ڪجهه سببن جي ڪري صحيح طريقي سان ڪم نه ڪري رهيو آهي، ته توهان ٽرانزيڪشن لاگ کي ٻئي ذريعن کان وٺي سگهو ٿا - رسڪ انجڻ کان. اهو اصول سڄي نظام ۾ پکڙيل آهي.
ٻين شين مان، اسان ڪلائنٽ API کي محفوظ ڪرڻ جي قابل هئا ته جيئن نه بروکرز ۽ نه ئي ڪنهن ٻئي کي نئين فن تعمير لاء اهم ڪم جي ضرورت هوندي. اسان کي ڪجهه انٽرفيس تبديل ڪرڻو پيو، پر آپريٽنگ ماڊل ۾ اهم تبديليون ڪرڻ جي ڪا ضرورت نه هئي.
اسان اسان جي پليٽ فارم جي موجوده ورزن کي سڏيو Rebus - هڪ مخفف جي طور تي فن تعمير ۾ ٻه سڀ کان وڌيڪ قابل ذڪر جدت، خطر انجڻ ۽ BUS.
شروعات ۾، اسان صرف صاف ڪرڻ وارو حصو مختص ڪرڻ چاهيندا هئا، پر نتيجو هڪ وڏو ورهايل نظام هو. ڪلائنٽ ھاڻي يا ته واپاري گيٽ وي، ڪليئرنگ گيٽ وي، يا ٻئي سان رابطو ڪري سگھن ٿا.
جيڪو اسان آخرڪار حاصل ڪيو:
دير جي سطح کي گھٽايو. ٽرانزيڪشن جي هڪ ننڍڙي مقدار سان، سسٽم اڳئين ورزن وانگر ساڳيو ڪم ڪري ٿو، پر ساڳئي وقت تمام گهڻو لوڊ برداشت ڪري سگهي ٿو.
چوٽي جي ڪارڪردگي 50 هزار کان 180 هزار ٽرانزيڪشن في سيڪنڊ تائين وڌي وئي. هڪ وڌيڪ اضافو آرڊر جي ميلاپ جي واحد وهڪرو طرفان رڪاوٽ آهي.
وڌيڪ بهتري لاءِ ٻه طريقا آهن: متوازي ملائڻ ۽ گيٽ وي سان ڪم ڪرڻ جو طريقو تبديل ڪرڻ. ھاڻي سڀ گيٽ ويز ھڪ نقلي اسڪيم جي مطابق ڪم ڪن ٿا، جيڪي اھڙي لوڊ ھيٺ، عام طور تي ڪم ڪرڻ بند ٿي وڃن ٿا.
آخرڪار، آئون انهن کي ڪجهه صلاح ڏيان ٿو جيڪي انٽرنيشنل سسٽم کي حتمي شڪل ڏئي رهيا آهن:
- هر وقت بدترين لاءِ تيار رهو. مسئلا هميشه غير متوقع طور تي پيدا ٿيندا آهن.
- اهو عام طور تي ناممڪن آهي جلدي فن تعمير کي ٻيهر ٺاهڻ. خاص طور تي جيڪڏهن توهان ڪيترن ئي اشارن تي وڌ ۾ وڌ اعتبار حاصل ڪرڻ جي ضرورت آهي. وڌيڪ نوڊس، وڌيڪ وسيلن جي حمايت لاء گهربل.
- سڀ ڪسٽم ۽ ملڪيت جي حل جي ضرورت هوندي اضافي وسيلن جي تحقيق، مدد ۽ سار سنڀال لاء.
- ناڪامي کان پوءِ سسٽم جي اعتبار ۽ بحالي جي مسئلن کي حل ڪرڻ کي بند نه ڪريو؛ انهن کي ابتدائي ڊيزائن اسٽيج تي حساب ۾ وٺو.
جو ذريعو: www.habr.com