ڪيترائي ماڻهو Elasticsearch سان جدوجهد ڪن ٿا. پر ڇا ٿيندو جڏھن توھان ان کي استعمال ڪرڻ چاھيو ٿا لاگز کي ذخيرو ڪرڻ لاءِ ”خاص طور تي وڏي مقدار ۾“؟ ۽ ڇا ڪيترن ئي ڊيٽا سينٽرن مان ڪنهن جي ناڪامي جو تجربو ڪرڻ به بي درد آهي؟ توهان کي ڪهڙي قسم جو فن تعمير ڪرڻ گهرجي، ۽ توهان کي ڪهڙي قسم جي نقصانن تي ٿڪايو ويندو؟
اسان Odnoklassniki ۾ لاگ مئنيجمينٽ جي مسئلي کي حل ڪرڻ لاءِ elasticsearch استعمال ڪرڻ جو فيصلو ڪيو، ۽ ھاڻي ھبر سان پنھنجو تجربو شيئر ڪريون ٿا: فن تعمير بابت ۽ نقصانن بابت.
مان Pyotr Zaitsev آهيان، مان Odnoklassniki ۾ هڪ سسٽم ايڊمنسٽريٽر طور ڪم ڪريان ٿو. ان کان اڳ، مان پڻ هڪ منتظم هو، Manticore ڳولا، Sphinx ڳولا، Elasticsearch سان ڪم ڪيو. شايد، جيڪڏهن ڪا ٻي ڳولها ظاهر ٿئي ٿي، مان شايد ان سان گڏ ڪم ڪندس. مان رضاڪارانه بنيادن تي ڪيترن ئي اوپن سورس منصوبن ۾ پڻ حصو وٺندو آهيان.
جڏهن آئون Odnoklassniki وٽ آيو آهيان، مون انٽرويو ۾ لاپرواهي سان چيو ته مان Elasticsearch سان ڪم ڪري سگهان ٿو. ان کان پوءِ مون کي ان جو پتو پئجي ويو ۽ ڪجهه سادو ڪم مڪمل ڪرڻ بعد، مون کي ان وقت موجود لاگ مئنيجمينٽ سسٽم کي سڌارڻ جو وڏو ڪم ڏنو ويو.
گه
سسٽم جي گهرج هيٺ ڏنل ترتيب ڏني وئي آهي:
- گريلوگ کي فرنٽ اينڊ طور استعمال ڪيو ويندو هو. ڇو ته ڪمپني اڳ ۾ ئي هن پراڊڪٽ کي استعمال ڪندي تجربو ڪيو هو، پروگرامرز ۽ ٽيسٽرز ان کي ڄاڻن ٿا، اهو انهن لاء واقف ۽ آسان هو.
- ڊيٽا جو مقدار: سراسري طور تي 50-80 هزار پيغام في سيڪنڊ، پر جيڪڏهن ڪجهه ڀڃي، پوء ٽرئفڪ ڪنهن به شيء سان محدود نه آهي، اهو ٿي سگهي ٿو 2-3 ملين لائينون في سيڪنڊ
- گراهڪن سان بحث ڪرڻ کان پوءِ ڳولا جي سوالن جي پروسيسنگ جي رفتار جي ضرورتن تي، اسان محسوس ڪيو ته اهڙي سسٽم کي استعمال ڪرڻ جو عام نمونو هي آهي: ماڻهو گذريل ٻن ڏينهن کان پنهنجي ايپليڪيشن جا لاگ ڳولي رهيا آهن ۽ هڪ کان وڌيڪ انتظار ڪرڻ نٿا چاهين. ٻيو هڪ ٺهيل سوال جي نتيجي لاء.
- منتظمين اصرار ڪيو ته سسٽم کي آساني سان اسپيبلبل هجي جيڪڏهن ضروري هجي، انهن جي ضرورت کان سواءِ ان جي ڪم ڪرڻ جي گہرائي ۾.
- تنهن ڪري صرف سار سنڀال جو ڪم جيڪو انهن سسٽم کي وقتي طور تي ڪجهه هارڊويئر کي تبديل ڪرڻ جي ضرورت آهي.
- ان کان علاوه، Odnoklassniki هڪ بهترين ٽيڪنيڪل روايت آهي: ڪا به خدمت جيڪا اسان شروع ڪريون ان کي لازمي طور تي ڊيٽا سينٽر جي ناڪامي کان بچڻ گهرجي (اوچتو، غير منصوبابندي ۽ بلڪل ڪنهن به وقت).
هن منصوبي تي عمل ڪرڻ جي آخري ضرورت اسان کي تمام گهڻو خرچ ڪيو، جنهن بابت آئون وڌيڪ تفصيل سان ڳالهائيندس.
اربع
اسان چار ڊيٽا سينٽرن ۾ ڪم ڪريون ٿا، جڏهن ته Elasticsearch ڊيٽا نوڊس صرف ٽن ۾ واقع ٿي سگھن ٿا (ڪيترن ئي غير ٽيڪنيڪل سببن جي ڪري).
اهي چار ڊيٽا سينٽر لڳ ڀڳ 18 هزار مختلف لاگ ذريعن تي مشتمل آهن - هارڊويئر، ڪنٽينرز، ورچوئل مشينون.
اھم خصوصيت: ڪلستر ڪنٽينرز ۾ شروع ٿئي ٿو جسماني مشينن تي نه، پر . ڪنٽينرز کي 2 ڪور جي ضمانت ڏني وئي آهي، 2.0Ghz v4 سان ملندڙ، باقي ڪورز کي ٻيهر استعمال ڪرڻ جي امڪان سان جيڪڏهن اهي بيڪار آهن.
ٻين لفظن ۾:
Topology
مون شروعاتي طور تي حل جي عام شڪل کي ھيٺئين طور ڏٺو:
- 3-4 VIPs گريلوگ ڊومين جي A-رڪارڊ جي پويان آهن، هي اهو پتو آهي جنهن تي لاگ موڪليا ويا آهن.
- هر VIP هڪ LVS بيلنس آهي.
- ان کان پوء، لاگز گريلوگ بيٽري ڏانھن وڃو، ڪجھ ڊيٽا GELF فارميٽ ۾ آھي، ڪجھ syslog فارميٽ ۾.
- ان کان پوء اهو سڀ ڪجهه لکيو ويو آهي وڏي بيچ ۾ Elasticsearch coordinators جي بيٽري ڏانهن.
- ۽ اھي، موڙ ۾، لکندا ۽ پڙھندا درخواستون لاڳاپيل ڊيٽا نوڊس ڏانھن.
اصطلاحات
شايد هرڪو نه سمجھي اصطلاحن کي تفصيل سان، تنهنڪري مان ان تي ٿورو غور ڪرڻ چاهيندس.
Elasticsearch ڪيترن ئي قسمن جا نوڊس آهن - ماسٽر، ڪوآرڊينيٽر، ڊيٽا نوڊ. هتي ٻه ٻيا قسم آهن مختلف لاگ ٽرانسفارميشن ۽ مختلف ڪلسترن جي وچ ۾ رابطي لاءِ، پر اسان صرف انهن کي استعمال ڪيو جيڪي فهرست ڏنل آهن.
ماسٽر
اهو ڪلستر ۾ موجود سڀني نوڊس کي پنگ ڪري ٿو، هڪ جديد ڪلستر نقشي کي برقرار رکي ٿو ۽ ان کي نوڊس جي وچ ۾ ورهائي ٿو، واقعن جي منطق کي پروسيس ڪري ٿو، ۽ مختلف قسم جي ڪلسٽر وائڊ هائوس ڪيپنگ کي انجام ڏئي ٿو.
تنظيمڪار
ھڪڙي ھڪڙي ڪم کي انجام ڏئي ٿو: ڪلائنٽ کان پڙھڻ يا لکڻ جي درخواستن کي قبول ڪري ٿو ۽ ھن ٽرئفڪ کي رستو ڏئي ٿو. جيڪڏهن ڪا لکڻ جي درخواست آهي، گهڻو ڪري، اهو ماسٽر کان پڇندو ته لاڳاپيل انڊيڪس جو ڪهڙو شارڊ ان ۾ رکڻ گهرجي، ۽ درخواست کي اڳتي وڌايو ويندو.
ڊيٽا نوڊ
ڊيٽا کي ذخيرو ڪري ٿو، ٻاهران اچڻ واري ڳولا جي سوالن کي انجام ڏئي ٿو ۽ ان تي واقع شارڊز تي عمل ڪري ٿو.
سريلي بلاگ
هي هڪ ELK اسٽيڪ ۾ Logstash سان Kibana جي فيوزن وانگر آهي. Graylog هڪ UI ۽ هڪ لاگ پروسيسنگ پائپ لائن ٻنهي کي گڏ ڪري ٿو. هود جي هيٺان، گريلاگ ڪافڪا ۽ زوڪيپر کي هلائي ٿو، جيڪي گريلاگ کي ڪلستر طور ڪنيڪشن فراهم ڪن ٿا. گريلاگ لاگز کي ڪيش ڪري سگھي ٿو (ڪافڪا) جي صورت ۾ Elasticsearch دستياب نه آھي ۽ ناڪام پڙھڻ ۽ لکڻ جي درخواستن کي ورجائي سگھي ٿو، مخصوص ضابطن جي مطابق لاگ لاگ ۽ نشان ھڻڻ. Logstash وانگر، Graylog ۾ ڪارڪردگي آهي قطار کي تبديل ڪرڻ کان اڳ انهن کي Elasticsearch ڏانهن لکڻ.
ان کان علاوه، گريلوگ وٽ هڪ تعمير ٿيل سروس دريافت آهي جيڪا اجازت ڏئي ٿي، هڪ دستياب ايلسٽسٽڪ سرچ نوڊ جي بنياد تي، پوري ڪلسٽر نقشي کي حاصل ڪرڻ ۽ ان کي هڪ مخصوص ٽيگ ذريعي فلٽر ڪرڻ جي اجازت ڏئي ٿي، جيڪا مخصوص ڪنٽينرز ڏانهن درخواستن کي سڌو ڪرڻ ممڪن بڻائي ٿي.
بصري طور اهو ڪجهه هن طرح نظر اچي ٿو:
هي هڪ خاص مثال مان هڪ اسڪرين شاٽ آهي. هتي اسان ڳولا جي سوال جي بنياد تي هڪ هسٽوگرام ٺاهيندا آهيون ۽ لاڳاپيل قطار ڏيکاريندا آهيون.
انڊيڪس
سسٽم آرڪيٽيڪچر ڏانهن واپسي، مان وڌيڪ تفصيل سان رهڻ چاهيندس ته اسان انڊيڪس ماڊل ڪيئن ٺاهيو ته جيئن اهو سڀ ڪجهه صحيح ڪم ڪري.
مٿي ڏنل ڊراگرام ۾، هي آهي هيٺين سطح: Elasticsearch ڊيٽا نوڊس.
هڪ انڊيڪس هڪ وڏو مجازي ادارو آهي جيڪو Elasticsearch شارڊز مان ٺهيل آهي. پاڻ ۾، هر هڪ شارڊ هڪ لوسن انڊيڪس کان وڌيڪ ناهي. ۽ هر لوسن انڊيڪس، موڙ ۾، هڪ يا وڌيڪ حصن تي مشتمل آهي.
ڊزائين ڪرڻ وقت، اسان سمجهيو ته ڊيٽا جي وڏي مقدار تي پڙهڻ جي رفتار جي ضرورت کي پورو ڪرڻ لاءِ، اسان کي هن ڊيٽا کي "پکڙيل" ڪرڻ جي ضرورت آهي ڊيٽا جي نوڊس ۾ برابر.
ان جي نتيجي ۾ حقيقت اها آهي ته شارڊز جو تعداد في انڊيڪس (نقل سان) سختي سان ڊيٽا نوڊس جي تعداد جي برابر هجڻ گهرجي. سڀ کان پهريان، هڪ نقلي عنصر کي يقيني بڻائڻ لاء ٻن جي برابر آهي (اهو آهي، اسان ڪلستر جو اڌ وڃائي سگهون ٿا). ۽، ٻيو، گهٽ ۾ گهٽ اڌ ڪلستر تي درخواستون پڙهڻ ۽ لکڻ جي عمل ڪرڻ لاء.
اسان پهريون ڀيرو 30 ڏينهن جي طور تي اسٽوريج وقت مقرر ڪيو.
شارڊ جي ورڇ کي هيٺ ڏنل گرافڪ طور تي پيش ڪري سگهجي ٿو:
سڄو ڳاڙهو ڳاڙهو مستطيل هڪ انڊيڪس آهي. ان ۾ کاٻي ڳاڙهي چورس پرائمري شارڊ آهي، انڊيڪس ۾ پهريون. ۽ نيرو چورس هڪ نقلي شارڊ آهي. اهي مختلف ڊيٽا سينٽرن ۾ واقع آهن.
جڏهن اسان هڪ ٻيو شارڊ شامل ڪندا آهيون، اهو ٽيون ڊيٽا سينٽر ڏانهن ويندو آهي. ۽، آخر ۾، اسان هي ڍانچي حاصل ڪندا آهيون، جيڪا ڊيٽا جي استحڪام کي وڃائڻ کان سواء ڊي سي کي وڃائڻ ممڪن بڻائي ٿي:
انڊيڪس جي گردش، يعني. نئين انڊيڪس ٺاهڻ ۽ پراڻي ترين کي حذف ڪندي، اسان ان کي 48 ڪلاڪن جي برابر ڪيو (انڊيڪس استعمال جي نموني جي مطابق: آخري 48 ڪلاڪ اڪثر ڳولها ويندا آهن).
هي انڊيڪس گردش وقفو هيٺين سببن جي ڪري آهي:
جڏهن ڳولا جي درخواست هڪ مخصوص ڊيٽا نوڊ تي پهچي ٿي، پوء، ڪارڪردگي جي نقطي نظر کان، اهو وڌيڪ فائدي وارو آهي جڏهن هڪ شارڊ پڇيو ويندو آهي، جيڪڏهن ان جي سائيز نوڊ جي هپ جي سائيز جي مقابلي ۾ آهي. هي توهان کي انڊيڪس جي "گرم" حصي کي ڍير ۾ رکڻ جي اجازت ڏئي ٿو ۽ جلدي ان تائين رسائي. جڏهن اتي تمام گهڻا "گرم حصا" آهن، انڊيڪس ڳولا جي رفتار گهٽجي ٿي.
جڏهن هڪ نوڊ هڪ شارڊ تي ڳولا جي سوال تي عمل ڪرڻ شروع ڪري ٿو، اهو فزيڪل مشين جي هائپر ٿريڊنگ ڪور جي تعداد جي برابر موضوعن جو تعداد مختص ڪري ٿو. جيڪڏهن ڳولا جو سوال وڏي تعداد ۾ شارڊز کي متاثر ڪري ٿو، ته پوءِ موضوعن جو تعداد تناسب سان وڌي ٿو. اهو ڳولا جي رفتار تي منفي اثر آهي ۽ نئين ڊيٽا جي انڊيڪسنگ کي منفي طور تي متاثر ڪري ٿو.
ضروري ڳولا جي ويڪرائي مهيا ڪرڻ لاء، اسان هڪ SSD استعمال ڪرڻ جو فيصلو ڪيو. جلدي درخواستن تي عمل ڪرڻ لاءِ، مشينون جيڪي انهن ڪنٽينرز کي ميزباني ڪنديون هيون انهن کي گهٽ ۾ گهٽ 56 ڪور هجڻ گهرجن. 56 جي انگن اکرن کي مشروط طور تي ڪافي قدر جي طور تي چونڊيو ويو جيڪو سلسلو جو تعداد طئي ڪري ٿو جيڪو Elasticsearch آپريشن دوران پيدا ڪندو. Elasitcsearch ۾، ڪيترائي ٿريڊ پول پيٽرولر سڌو سنئون موجود ڪور جي تعداد تي منحصر آهن، جنهن جي نتيجي ۾ سڌو سنئون اثر پوي ٿو ڪلستر ۾ نوڊس جي گهربل تعداد جي اصول مطابق "گهٽ ڪور - وڌيڪ نوڊس".
نتيجي طور، اسان ڏٺو ته سراسري طور تي هڪ شارڊ اٽڪل 20 گيگا بائيٽ وزن آهي، ۽ هر انڊيڪس ۾ 1 شارڊ آهن. ان مطابق، جيڪڏهن اسان انهن کي هر 360 ڪلاڪن ۾ هڪ ڀيرو گھمايو، پوء اسان وٽ انهن مان 48 آهن. هر انڊيڪس ۾ 15 ڏينهن جي ڊيٽا شامل آهي.
ڊيٽا لکڻ ۽ پڙهڻ سرڪٽ
اچو ته ڄاڻون ته هن سسٽم ۾ ڊيٽا ڪيئن رڪارڊ ٿيل آهي.
اچو ته ڪجهه درخواست Graylog کان ڪوآرڊينيٽر تائين پهچي. مثال طور، اسان 2-3 هزار قطار کي انڊيڪس ڪرڻ چاهيون ٿا.
ڪوآرڊينيٽر، گريلوگ کان هڪ درخواست وصول ڪندي، ماسٽر کان سوال ڪيو: ”انڊيڪسنگ جي درخواست ۾، اسان خاص طور تي هڪ انڊيڪس مقرر ڪيو، پر ان کي ڪهڙي شارڊ ۾ لکڻو آهي، ان جي وضاحت نه ڪئي وئي آهي.
ماسٽر جواب ڏئي ٿو: "هن معلومات کي شارڊ نمبر 71 تي لکو،" جنهن کان پوء اهو سڌو سنئون لاڳاپيل ڊيٽا نوڊ ڏانهن موڪليو ويو، جتي پرائمري-شارڊ نمبر 71 واقع آهي.
جنهن کان پوءِ ٽرانزيڪشن لاگ هڪ ريپليڪا-شارڊ ڏانهن نقل ڪيو ويو آهي، جيڪو ٻئي ڊيٽا سينٽر ۾ واقع آهي.
هڪ ڳولا جي درخواست اچي ٿي Graylog کان ڪوآرڊينيٽر ڏانهن. ڪوآرڊينيٽر ان کي انڊيڪس جي مطابق ريڊائريڪٽ ڪري ٿو، جڏهن ته Elasticsearch راؤنڊ-رابن اصول استعمال ڪندي پرائمري-شارڊ ۽ ريپليڪا-شارڊ جي وچ ۾ درخواستون ورهائي ٿو.
180 نوڊس هڪجهڙائي سان جواب ڏين ٿا، ۽ جڏهن اهي جواب ڏئي رهيا آهن، ڪوآرڊينيٽر معلومات گڏ ڪري رهيو آهي جيڪا اڳ ۾ ئي تيز ڊيٽا نوڊس پاران ”اسٽيٽ آئوٽ“ ڪئي وئي آهي. ان کان پوء، جڏهن يا ته سموري معلومات پهچي وئي آهي، يا درخواست وقت ختم ٿي وئي آهي، اهو سڀ ڪجهه سڌو سنئون ڪلائنٽ کي ڏئي ٿو.
اهو سڄو سسٽم سراسري طور تي گذريل 48 ڪلاڪن لاءِ 300-400ms ۾ ڳولا جي سوالن کي پروسيس ڪري ٿو، انهن سوالن کي سواءِ هڪ معروف وائلڊ ڪارڊ سان.
Elasticsearch سان گل: جاوا سيٽ اپ
اهو سڀ ڪم ڪرڻ لاءِ جيئن اسان اصل ۾ چاهيون ٿا، اسان تمام گهڻو وقت گذاريو ڪلستر ۾ مختلف قسم جي شين کي ڊيبگ ڪرڻ ۾.
دريافت ڪيل مسئلن جو پهريون حصو ان طريقي سان لاڳاپيل هو جو جاوا اڳ ۾ ترتيب ڏنل آهي Elasticsearch ۾.
مسئلو هڪ
اسان وڏي تعداد ۾ رپورٽون ڏٺيون آهن ته لوسن جي سطح تي، جڏهن پس منظر جون نوڪريون هلي رهيون آهن، لوسين سيگمينٽ هڪ غلطي سان ناڪام ٿي. ساڳئي وقت، اهو لاگ ان ۾ واضح هو ته هي هڪ OutOfMemoryError غلطي هئي. اسان ٽيليميٽري مان ڏٺو ته هپ آزاد هئي، ۽ اهو واضح ناهي ته هي آپريشن ڇو ناڪام ٿي رهيو هو.
اهو ظاهر ٿيو ته لوسن انڊيڪس هپ کان ٻاهر نڪرندو آهي. ۽ ڪنٽينر استعمال ٿيل وسيلن جي لحاظ کان ڪافي حد تائين محدود آهن. صرف heap انهن وسيلن ۾ فٽ ٿي سگهي ٿو (heap.size جي قيمت تقريباً RAM جي برابر هئي)، ۽ ڪجهه آف-هيپ آپريشنز ميموري مختص ڪرڻ جي غلطي سان حادثا ٿي ويا جيڪڏهن ڪنهن سبب جي ڪري اهي ~ 500MB ۾ مناسب نه هجن جيڪي حد کان اڳ رهي.
حل بلڪل معمولي هو: ڪنٽينر لاءِ موجود رام جي مقدار وڌي وئي هئي، جنهن کان پوءِ اسان وساري ويٺاسين ته اسان وٽ به اهڙا مسئلا هئا.
مسئلو ٻه
ڪلستر جي شروعات کان 4-5 ڏينهن بعد، اسان ڏٺو ته ڊيٽا نوڊس وقتي طور تي ڪلستر مان نڪرڻ شروع ڪيو ۽ 10-20 سيڪنڊن کان پوء ان ۾ داخل ٿيو.
جڏهن اسان ان کي سمجهڻ شروع ڪيو، اهو ظاهر ٿيو ته هي آف هيپ ميموري ۾ Elasticsearch ڪنهن به طريقي سان ڪنٽرول نه آهي. جڏهن اسان ڪنٽينر کي وڌيڪ ياداشت ڏني، اسان مختلف معلومات سان سڌو بفر پول ڀرڻ جي قابل هئا، ۽ اهو صرف صاف ڪيو ويو جڏهن واضح GC Elasticsearch کان شروع ڪيو ويو.
ڪجهه حالتن ۾، هن آپريشن ڪافي ڊگهو وقت ورتو، ۽ هن وقت دوران ڪلستر هن نوڊ کي اڳ ۾ ئي نڪتل طور تي نشان لڳايو. اهو مسئلو چڱي طرح بيان ڪيو ويو آهي .
حل هن ريت هو: اسان انهن عملن لاءِ هيپ کان ٻاهر ميموري جي وڏي مقدار کي استعمال ڪرڻ جي جاوا جي صلاحيت کي محدود ڪيو. اسان ان کي 16 گيگا بائيٽ تائين محدود ڪيو (-XX:MaxDirectMemorySize=16g)، انهي ڳالهه کي يقيني بڻائڻ ته واضح GC کي گهڻو ڪري سڏيو ويو ۽ تمام تيز پروسيس ڪيو ويو، ان سان هاڻي ڪلستر کي غير مستحڪم نه ٿيندو.
مسئلو ٽيون
جيڪڏهن توهان سوچيو ٿا ته مسئلا "نوڊس کي سڀ کان وڌيڪ غير متوقع لمحن ۾ ڪلستر ڇڏڻ" سان ختم ٿي ويا آهن، توهان غلط آهيو.
جڏهن اسان انڊيڪس سان ڪم کي ترتيب ڏنو، اسان mmapfs کي چونڊيو تازي ٽڪرن تي وڏي ڀاڱي سان. اها ڪافي غلطي هئي، ڇاڪاڻ ته جڏهن mmapfs استعمال ڪندي فائل کي RAM ۾ ميپ ڪيو ويندو آهي، ۽ پوء اسان ميپ ٿيل فائل سان ڪم ڪندا آهيون. ان جي ڪري، اهو ظاهر ٿئي ٿو ته جڏهن GC ايپليڪيشن ۾ موضوعن کي روڪڻ جي ڪوشش ڪري ٿو، اسان ڪافي دير تائين محفوظ هنڌ ڏانهن وڃون ٿا، ۽ ان جي رستي تي، ايپليڪيشن ماسٽر جي درخواستن جو جواب ڏيڻ کان روڪي ٿي ته ڇا اهو زنده آهي. . ان جي مطابق، ماسٽر يقين رکي ٿو ته نوڊ هاڻي ڪلستر ۾ موجود ناهي. ان کان پوء، 5-10 سيڪنڊن کان پوء، ڪچرو گڏ ڪرڻ وارو ڪم ڪري ٿو، نوڊ زندگي ۾ اچي ٿو، ٻيهر ڪلستر ۾ داخل ٿئي ٿو ۽ شارڊ شروع ڪرڻ شروع ڪري ٿو. اهو سڀ ڪجهه تمام گهڻو محسوس ٿيو ”جنهن جي پيداوار اسان مستحق آهيون“ ۽ ڪنهن به سنجيده لاءِ مناسب نه هئي.
هن رويي کان نجات حاصل ڪرڻ لاء، اسان پهريون ڀيرو معياري niofs ڏانهن تبديل ڪيو، ۽ پوء، جڏهن اسان لڏپلاڻ جي پنجين نسخن کان ڇهين تائين لڏپلاڻ ڪئي، اسان هائبرڊفس جي ڪوشش ڪئي، جتي اهو مسئلو ٻيهر پيدا نه ڪيو ويو. توهان اسٽوريج جي قسمن بابت وڌيڪ پڙهي سگهو ٿا .
مسئلو چار
ان کان پوء هڪ ٻيو تمام دلچسپ مسئلو هو جنهن کي اسان رڪارڊ وقت تائين علاج ڪيو. اسان ان کي 2-3 مهينن تائين پڪڙيو ڇاڪاڻ ته ان جو نمونو بلڪل سمجھ کان ٻاهر هو.
ڪڏهن ڪڏهن اسان جا ڪوآرڊينيٽر فل GC ڏانهن ويندا هئا، عام طور تي ڪجهه دير لنچ کان پوءِ، ۽ ڪڏهن به اتان واپس نه ايندا هئا. ساڳئي وقت، جڏهن GC دير سان لاگ ان ڪيو، اهو هن طرح نظر آيو: سڀ ڪجهه ٺيڪ ٿي رهيو آهي، ٺيڪ، ٺيڪ، ۽ پوء اوچتو سڀ ڪجهه تمام خراب ٿي رهيو آهي.
پهرين ۾ اسان سوچيو ته اسان وٽ هڪ برائي استعمال ڪندڙ آهي جيڪو ڪنهن قسم جي درخواست شروع ڪري رهيو هو جيڪو ڪم ڪندڙ موڊ کان ڪوآرڊينيٽر کي ڇڪي ڇڏيو. اسان گهڻي وقت تائين درخواستون داخل ڪيون، اهو معلوم ڪرڻ جي ڪوشش ڪئي ته ڇا ٿي رهيو آهي.
نتيجي طور، اهو ظاهر ٿيو ته هن وقت جڏهن هڪ صارف هڪ وڏي درخواست شروع ڪري ٿو، ۽ اهو هڪ مخصوص Elasticsearch ڪوآرڊينيٽر ڏانهن وڃي ٿو، ڪجهه نوڊس ٻين جي ڀيٽ ۾ وڌيڪ جواب ڏين ٿا.
۽ جڏهن ڪوآرڊينيٽر سڀني نوڊس کان جواب جو انتظار ڪري رهيو آهي، هو انهن نوڊس مان موڪليل نتيجن کي گڏ ڪري ٿو جيڪي اڳ ۾ ئي جواب ڏئي چڪا آهن. GC لاءِ، هن جو مطلب آهي ته اسان جي هيپ استعمال جا نمونا تمام جلدي تبديل ٿيندا آهن. ۽ GC جيڪو اسان استعمال ڪيو اهو ڪم کي منهن نه ڏئي سگهيو.
هن صورتحال ۾ ڪلستر جي رويي کي تبديل ڪرڻ لاءِ اسان کي صرف هڪ حل مليو آهي JDK13 ڏانهن لڏپلاڻ ۽ شيننڊوهه ڪچري جي ڪليڪٽر جو استعمال. اهو مسئلو حل ڪيو، اسان جي ڪوآرڊينيٽر گر ٿيڻ بند ٿي ويا.
اهو آهي جتي جاوا سان مسئلا ختم ٿي ويا ۽ بينڊوڊٿ مسئلا شروع ٿيا.
Elasticsearch سان "بيري": throughput
Throput سان مسئلن جو مطلب اهو آهي ته اسان جو ڪلستر مستحڪم طور تي ڪم ڪري ٿو، پر انڊيڪس ٿيل دستاويزن جي تعداد ۾ چوٽي تي ۽ مشق دوران، ڪارڪردگي ڪافي نه آهي.
پهرين علامت سامهون آئي: پيداوار ۾ ڪجهه ”ڌماڪن“ جي دوران، جڏهن اوچتو لاگن جو تمام وڏو تعداد پيدا ٿئي ٿو، انڊيڪسنگ جي غلطي es_rejected_execution گريلوگ ۾ اڪثر چمڪائڻ شروع ڪري ٿي.
اهو ان حقيقت جي ڪري هو ته هڪ ڊيٽا نوڊ تي thread_pool.write.queue، ان وقت تائين Elasticsearch انڊيڪسنگ جي درخواست کي پروسيس ڪرڻ ۽ ڊسڪ تي شارڊ تي معلومات اپ لوڊ ڪرڻ جي قابل آهي، صرف 200 درخواستن کي ڊفالٽ ڪيش ڪرڻ جي قابل آهي. ۽ اندر هن پيراگراف جي باري ۾ تمام ٿورو چيو ويندو آهي. صرف موضوعن جو وڌ ۾ وڌ تعداد ۽ ڊفالٽ سائيز ڏيکاريل آھن.
يقينن، اسان هن قدر کي موڙ ڪرڻ لاءِ ويا هئاسين ۽ هيٺ ڏنل معلوم ڪيو: خاص طور تي، اسان جي سيٽ اپ ۾، 300 تائين درخواستون چڱيءَ طرح محفوظ ڪيون ويون آهن، ۽ هڪ اعليٰ قدر ان حقيقت سان ڀريل آهي ته اسان ٻيهر مڪمل GC ۾ اڏامون ٿا.
ان کان علاوه، ڇاڪاڻ ته اهي پيغامن جا بيچ آهن جيڪي هڪ درخواست جي اندر پهچي ويندا آهن، اهو ضروري هو ته گريلاگ کي ٽوڪ ڪيو وڃي ته جيئن اهو اڪثر ۽ ننڍن بيچن ۾ نه، پر وڏي بيچ ۾ يا هر 3 سيڪنڊن ۾ هڪ ڀيرو جيڪڏهن بيچ اڃا مڪمل نه آهي. انهي صورت ۾، اهو ظاهر ٿئي ٿو ته اها معلومات جيڪا اسان Elasticsearch ۾ لکندا آهيون اها ٻن سيڪنڊن ۾ نه، پر پنجن ۾ دستياب ٿي ويندي آهي (جيڪو اسان کي بلڪل مناسب آهي)، پر ريٽرن جو تعداد جيڪو وڏي پئماني تي دٻائڻ لاء ٺاهيو وڃي ٿو. معلومات جو ذخيرو گھٽجي ويو آهي.
اهو خاص طور تي انهن لمحن ۾ اهم آهي جڏهن ڪا شيءِ ڪٿي حادثو ٿي چڪي آهي ۽ ان جي باري ۾ سختي سان رپورٽ ڪري ٿو، ته جيئن مڪمل طور تي اسپام ٿيل لچڪدار حاصل نه ٿئي، ۽ ڪجهه وقت کان پوء - گريلوگ نوڊس جيڪي بند ٿيل بفرن جي ڪري ناگزير آهن.
ان کان علاوه، جڏهن اسان وٽ پيداوار ۾ اهي ساڳيون ڌماڪا هئا، اسان پروگرامرز ۽ ٽيسٽرن کان شڪايتون حاصل ڪيون: هن وقت جڏهن انهن کي واقعي انهن لاگن جي ضرورت هئي، انهن کي تمام سستي ڏني وئي.
ان کي سمجهڻ لڳا. هڪ پاسي، اهو واضح هو ته ڳولا جي سوالن ۽ انڊيڪسنگ سوالن تي عمل ڪيو ويو، لازمي طور تي، ساڳئي جسماني مشينن تي، ۽ هڪ طريقو يا ٻيو ڪجهه خاص گهٽتائي هوندي.
پر اهو جزوي طور تي ان حقيقت جي ڪري روڪيو ويو آهي ته Elasticsearch جي ڇهين ورزن ۾، هڪ الگورٿم ظاهر ٿيو جيڪو توهان کي لاڳاپيل ڊيٽا نوڊس جي وچ ۾ سوالن کي ورهائڻ جي اجازت ڏئي ٿو نه بي ترتيب واري راؤنڊ-رابن اصول جي مطابق (اهو ڪنٽينر جيڪو انڊيڪس ڪري ٿو ۽ پرائمري کي رکي ٿو. -shard تمام مصروف ٿي سگھي ٿو، تڪڙو جواب ڏيڻ جو ڪو طريقو نه ھوندو)، پر ھن درخواست کي ھڪ گھٽ لوڊ ٿيل ڪنٽينر ڏانھن موٽڻ لاءِ ريپليڪا-شارڊ، جيڪو گھڻو تيز جواب ڏيندو. ٻين لفظن ۾، اسان پهچي ويا آهيون use_adaptive_replica_selection: true.
پڙهڻ واري تصوير هن طرح ڏسڻ شروع ٿئي ٿي:
هن الگورتھم جي منتقلي ان لمحن ۾ سوال جي وقت کي خاص طور تي بهتر ڪرڻ ممڪن بڻائي ڇڏيو جڏهن اسان وٽ لکڻ لاءِ لاگن جو وڏو وهڪرو هو.
آخرڪار، بنيادي مسئلو ڊيٽا سينٽر جي بي دردي ختم ڪرڻ هو.
جيڪو اسان چاهيون ٿا ڪلستر کان فوري طور تي هڪ ڊي سي سان رابطو وڃائڻ کان پوءِ:
- جيڪڏهن اسان وٽ هڪ موجوده ماسٽر آهي ناڪام ڊيٽا سينٽر ۾، پوء اهو ٻيهر چونڊيو ويندو ۽ هڪ ڪردار جي طور تي هڪ ٻئي ڊي سي ۾ ٻئي نوڊ ڏانهن منتقل ڪيو ويندو.
- ماسٽر جلدي ختم ڪري ڇڏيندو ڪلستر مان سڀ ناقابل رسائڊ نوڊس.
- باقي انهن جي بنياد تي، هو سمجھندو: گم ٿيل ڊيٽا سينٽر ۾ اسان وٽ اھڙا ۽ اھڙا پرائمري شارڊ ھئا، ھو جلد ئي باقي ڊيٽا سينٽرن ۾ ڪمپليمينٽري ريپليڪا شارڊز کي فروغ ڏيندو، ۽ اسان ڊيٽا کي انڊيڪس ڪرڻ جاري رکنداسين.
- ان جي نتيجي ۾، ڪلستر جي لکڻ ۽ پڙهڻ جو طريقو آهستي آهستي خراب ٿيندو، پر عام طور تي سڀ ڪجهه ڪم ڪندو، جيتوڻيڪ سست، پر مستحڪم.
جيئن ته اهو نڪتو، اسان هن وانگر ڪجهه چاهيون ٿا:
۽ اسان کي هيٺيون مليون آهن:
اهو ڪيئن ٿيو؟
جڏهن ڊيٽا سينٽر ڪري پيو، اسان جو ماسٽر رڪاوٽ بڻجي ويو.
ڇو؟
حقيقت اها آهي ته ماسٽر وٽ هڪ TaskBatcher آهي، جيڪو ڪلستر ۾ ڪجهه ڪمن ۽ واقعن کي ورهائڻ جو ذميوار آهي. ڪو به نوڊ نڪرڻ، ريپليڪا کان پرائمري تائين شارڊ جو ڪو به واڌارو، ڪنهن به جاءِ تي شارڊ ٺاهڻ جو ڪو به ڪم - اهو سڀ پهريون وڃي TaskBatcher ڏانهن، جتي اهو ترتيب سان ۽ هڪ سلسلي ۾ پروسيس ڪيو ويندو آهي.
هڪ ڊيٽا سينٽر جي واپسي جي وقت، اهو ظاهر ٿيو ته بقايا ڊيٽا سينٽرن ۾ سڀني ڊيٽا نوڊس اهو پنهنجو فرض سمجهندا آهن ته ماسٽر کي خبر ڏيو ته "اسان فلاڻي ۽ اهڙيون شارڊز ۽ فلاڻي ڊيٽا نوڊس کي وڃائي ڇڏيو آهي."
ساڳئي وقت، بچيل ڊيٽا نوڊس هن سڀني معلومات کي موجوده ماسٽر ڏانهن موڪليو ۽ تصديق ڪرڻ جي انتظار ڪرڻ جي ڪوشش ڪئي ته هن ان کي قبول ڪيو. هنن ان لاءِ انتظار نه ڪيو، ڇاڪاڻ ته ماسٽر ڪمن کي تيزيءَ سان حاصل ڪري سگهي ٿو جيترو هو جواب ڏئي سگهي ٿو. نوڊس بار بار درخواستن جو وقت ختم ڪري ڇڏيو، ۽ ماسٽر هن وقت انهن کي جواب ڏيڻ جي ڪوشش نه ڪئي، پر مڪمل طور تي ترجيحن جي ترتيب ڏيڻ جي ڪم ۾ مڪمل طور تي جذب ٿي ويو.
ٽرمينل فارم ۾، اهو ظاهر ٿيو ته ڊيٽا نوڊس ماسٽر کي اسپام ڪيو ته اهو مڪمل GC ۾ ويو. ان کان پوء، اسان جو ماسٽر ڪردار ڪجهه ايندڙ نوڊ ڏانهن منتقل ڪيو ويو، بلڪل ساڳيو شيء ان سان ٿيو، ۽ نتيجي ۾ ڪلستر مڪمل طور تي ختم ٿي ويو.
اسان ماپون ورتيون، ۽ ورجن 6.4.0 کان اڳ، جتي اهو طئي ڪيو ويو هو، اهو اسان لاءِ هڪ ئي وقت 10 مان صرف 360 ڊيٽا نوڊس ڪڍڻ لاءِ ڪافي هو ته جيئن ڪلسٽر کي مڪمل طور تي بند ڪيو وڃي.
اهو ڪجهه هن طرح نظر آيو:
ورزن 6.4.0 کان پوء، جتي هي خوفناڪ بگ مقرر ڪيو ويو، ڊيٽا نوڊس ماسٽر کي مارڻ بند ڪيو. پر اهو هن کي "هوشيار" نه ڪيو. يعني: جڏهن اسان 2، 3 يا 10 (هڪ کان سواءِ ٻيو ڪو به انگ) ڊيٽا نوڊس ڪڍيون ٿا، ته ماسٽر کي پهريون پيغام ملي ٿو جيڪو چوي ٿو ته نوڊ A ڇڏي ويو آهي، ۽ node B، node C کي ان بابت ٻڌائڻ جي ڪوشش ڪندو آهي، node D.
۽ هن وقت، اهو صرف 20-30 سيڪنڊن جي برابر، ڪنهن کي ڪنهن شيءِ بابت ٻڌائڻ جي ڪوشش لاءِ وقت مقرر ڪرڻ سان ئي حل ٿي سگهي ٿو، ۽ اهڙيءَ طرح ڪلسٽر کان ٻاهر وڃڻ واري ڊيٽا سينٽر جي رفتار کي ڪنٽرول ڪري سگهجي ٿو.
اصولي طور تي، اھو انھن ضرورتن سان ٺھي ٿو جيڪي شروعاتي طور تي پيش ڪيا ويا آھن فائنل پراڊڪٽ کي منصوبي جي حصي طور، پر "خالص سائنس" جي نقطي نظر کان اھو ھڪڙو بگ آھي. جيڪو، رستي ۾، ڊولپرز طرفان ڪاميابيء سان مقرر ڪيو ويو نسخو 7.2 ۾.
ان کان علاوه، جڏهن هڪ خاص ڊيٽا نوڊ ٻاهر نڪري ويو، اهو ظاهر ٿيو ته ان جي نڪرڻ بابت معلومات کي ڦهلائڻ سڄي ڪلستر کي ٻڌائڻ کان وڌيڪ اهم هو ته ان تي اهڙا ۽ اهڙيون پرائمري-شارڊز موجود آهن (هڪ ٻئي ڊيٽا ۾ ريپليڪا-شارڊ کي فروغ ڏيڻ لاء. پرائمري ۾ مرڪز، ۽ معلومات ۾ انهن تي لکي سگهجي ٿو).
تنهن ڪري، جڏهن سڀ ڪجهه اڳ ۾ ئي مري ويو آهي، جاري ڪيل ڊيٽا نوڊس فوري طور تي اسٽيل طور نشان نه هوندا آهن. ان جي مطابق، اسان کي انتظار ڪرڻ تي مجبور ڪيو وڃي ٿو جيستائين سڀئي پنگ جاري ٿيل ڊيٽا نوڊس تائين ختم نه ٿين، ۽ صرف ان کان پوء اسان جو ڪلستر اسان کي ٻڌائڻ شروع ڪري ٿو ته اتي، اتي، ۽ اتي اسان کي معلومات کي رڪارڊ ڪرڻ جاري رکڻ جي ضرورت آهي. توھان ھن بابت وڌيڪ پڙھي سگھو ٿا .
نتيجي طور، اڄ ڊيٽا سينٽر کي ڪڍڻ جو عمل اسان کي رش جي ڪلاڪ دوران تقريبا 5 منٽ وٺندو آهي. اهڙي وڏي ۽ بيڪار ڪولوسس لاء، هي هڪ تمام سٺو نتيجو آهي.
نتيجي طور، اسان ھيٺ ڏنل فيصلي تي آيا:
- اسان وٽ 360 ڊيٽا نوڊس آهن 700 گيگا بائيٽ ڊسڪ سان.
- 60 ڪوآرڊينيٽر انهن ساڳين ڊيٽا نوڊس ذريعي ٽريفڪ کي روٽ ڪرڻ لاءِ.
- 40 ماسٽرس جيڪي اسان 6.4.0 کان اڳ واري ورزن کان وٺي هڪ قسم جي ورثي جي طور تي ڇڏيا آهن - ڊيٽا سينٽر جي واپسي کان بچڻ لاءِ، اسان ذهني طور تي ڪيترن ئي مشينن کي وڃائڻ لاءِ تيار هئاسين ته جيئن ماسٽرن جي ڪورم جي ضمانت ڏني وڃي. بدترين صورت حال
- ھڪڙي ڪنٽينر تي ڪردار کي گڏ ڪرڻ جي ڪا به ڪوشش حقيقت سان ملي ٿي ته جلدي يا بعد ۾ نوڊ لوڊ ھيٺ ڀڃي ڇڏيندي.
- سڄو ڪلستر 31 گيگا بائيٽ جو heap.size استعمال ڪري ٿو: سائيز کي گھٽائڻ جي سڀني ڪوششن جي نتيجي ۾ يا ته وڏي ڳولا واري سوالن تي ڪجهه نوڊس کي مارڻ جي نتيجي ۾ معروف وائلڊ ڪارڊ سان يا سرڪٽ برڪر حاصل ڪرڻ ۾ ئي Elasticsearch ۾.
- ان کان علاوه، ڳولا جي ڪارڪردگي کي يقيني بڻائڻ لاء، اسان ڪلستر ۾ شيون جي تعداد کي ممڪن طور تي ننڍڙو رکڻ جي ڪوشش ڪئي، ممڪن طور تي ڪجھ واقعن تي عمل ڪرڻ لاء ممڪن حد تائين جيڪي اسان ماسٽر ۾ حاصل ڪيا.
آخر ۾ نگراني جي باري ۾
انهي کي يقيني بڻائڻ لاءِ ته هي سڀ ڪم جيئن ارادو ڪيو وڃي، اسان هيٺ ڏنل نگراني ڪريون ٿا:
- هر ڊيٽا نوڊ اسان جي ڪلائوڊ کي رپورٽ ڪري ٿو ته اهو موجود آهي، ۽ ان تي اهڙا ۽ اهڙيون شارڊز آهن. جڏهن اسان ڪنهن شيءِ کي وسايو ٿا، ڪلستر 2-3 سيڪنڊن کان پوءِ رپورٽ ڪري ٿو ته مرڪز A ۾ اسان نوڊس 2، 3 ۽ 4 کي وجھي ڇڏيو آهي - ان جو مطلب اهو آهي ته ٻين ڊيٽا سينٽرن ۾ اسين ڪنهن به حالت ۾ انهن نوڊس کي نه ٿا ڪري سگهون جن تي صرف هڪ شارڊ آهي. کاٻو.
- ماسٽر جي رويي جي نوعيت کي ڄاڻڻ، اسان التوا واري ڪمن جي تعداد تي تمام غور سان ڏسون ٿا. ڇاڪاڻ ته هڪ به اٽڪيل ڪم، جيڪڏهن اهو وقت تي ختم نه ٿيو ته، نظرياتي طور تي ڪجهه هنگامي حالتن ۾ اهو سبب بڻجي سگهي ٿو، مثال طور، پرائمري ۾ ريپليڪا شارڊ جو واڌارو ڪم نه ٿو ڪري، جنهن ڪري انڊيڪسنگ ڪم ڪرڻ بند ٿي ويندي.
- اسان ڪچري جي جمع ڪرڻ جي دير تي پڻ تمام ويجهي نظر رکون ٿا، ڇاڪاڻ ته اسان کي اڳ ۾ ئي بهتر ڪرڻ دوران هن سان گڏ وڏيون مشڪلاتون آهن.
- ٿريڊ ذريعي رد ڪري ٿو اڳ ۾ سمجھڻ لاءِ ته ڪٿي رڪاوٽ آهي.
- خير، معياري ميٽرڪس جهڙوڪ هيپ، رام ۽ I/O.
جڏهن مانيٽرنگ جي تعمير ڪريو، توهان کي لازمي طور تي غور ڪرڻ گهرجي ٿريڊ پول جي خاصيتن ۾ Elasticsearch. تشريح جي اختيارن ۽ ڊفالٽ قدرن کي بيان ڪري ٿو ڳولا ۽ انڊيڪسنگ لاءِ، پر thread_pool.management بابت مڪمل طور تي خاموش آهي. اهي ٿريڊ پروسيس ڪن ٿا، خاص طور تي، سوالن جهڙوڪ _cat/shards ۽ ٻيا ملندڙ جلندڙ، جيڪي لکڻ جي نگراني ڪرڻ وقت استعمال ڪرڻ ۾ آسان آهن. ڪلسٽر جيترو وڏو هوندو، اوترو ئي وڌيڪ اهڙيون درخواستون في يونٽ وقت تي عمل ۾ اينديون آهن، ۽ مٿي ڄاڻايل thread_pool.management نه رڳو سرڪاري دستاويزن ۾ پيش ڪيو ويندو آهي، پر ڊفالٽ طور 5 موضوعن تائين محدود هوندو آهي، جنهن کي تمام جلدي ختم ڪيو ويندو آهي، بعد ۾ جيڪو مانيٽرنگ صحيح ڪم ڪرڻ بند ڪري ٿو.
مان آخر ۾ ڇا چوڻ چاهيان ٿو: اسان اهو ڪيو! اسان اسان جي پروگرامرز ۽ ڊولپرز کي هڪ اوزار ڏيڻ جي قابل هئا، جيڪو تقريبا ڪنهن به صورتحال ۾، جلدي ۽ معتبر طور تي معلومات مهيا ڪري سگهي ٿو پيداوار ۾ ڇا ٿي رهيو آهي.
ها، اهو ڪافي پيچيده ٿي ويو، پر، ان جي باوجود، اسان پنهنجي خواهش کي موجوده شين ۾ فٽ ڪرڻ ۾ ڪامياب ٿي ويا، جن کي اسان کي پاڻ لاء پيچ ۽ ٻيهر لکڻ جي ضرورت ناهي.
جو ذريعو: www.habr.com