ډیری خلک د Elasticsearch سره مبارزه کوي. مګر څه پیښیږي کله چې تاسو غواړئ دا د "په ځانګړي ډول لوی حجم کې" د لاګونو ذخیره کولو لپاره وکاروئ؟ او ایا دا هم بې درده ده چې د ډیری ډیټا مرکزونو څخه د ناکامۍ تجربه وکړئ؟ تاسو باید کوم ډول معمارۍ جوړ کړئ، او تاسو به په کومو زیانونو اخته شئ؟
موږ په Odnoklassniki کې پریکړه وکړه چې د لاګ مدیریت مسلې حل کولو لپاره elasticsearch وکاروو، او اوس موږ خپله تجربه له هابر سره شریکوو: دواړه د معمارۍ او د زیانونو په اړه.
زه پیوټر زیتسیف یم، زه په اوډنوکلاسنیکي کې د سیسټم مدیر په توګه کار کوم. مخکې له دې، زه هم یو مدیر وم، د منټیکور لټون، سپنکس لټون، Elasticsearch سره کار کاوه. شاید، که بل ... لټون څرګند شي، زه به شاید ورسره هم کار وکړم. زه په داوطلبانه توګه د خلاصې سرچینې په یو شمیر پروژو کې هم برخه اخلم.
کله چې زه Odnoklassniki ته راغلم، ما په بې پروایی سره په مرکه کې وویل چې زه کولی شم د Elasticsearch سره کار وکړم. وروسته له دې چې ما د هغې ځړول ترلاسه کړل او ځینې ساده کارونه یې بشپړ کړل، ما ته د لاګ مدیریت سیسټم د سمون لوی دنده وسپارل شوه چې په هغه وخت کې شتون درلود.
اړتیاو
د سیسټم اړتیاوې په لاندې ډول ترتیب شوي:
- ګریلوګ باید د مخکینۍ برخې په توګه وکارول شي. ځکه چې شرکت دمخه د دې محصول کارولو تجربه درلوده، پروګرامونکي او ټیسټران یې پوهیدل، دا د دوی لپاره پیژندل شوی او مناسب و.
- د معلوماتو حجم: په اوسط ډول په هره ثانیه کې 50-80 زره پیغامونه، مګر که یو څه مات شي، نو ټرافیک د هیڅ شی لخوا محدود نه دی، دا په هر ثانیه کې 2-3 ملیون لینونه کیدی شي.
- د پیرودونکو سره د لټون پوښتنو پروسس کولو سرعت اړتیاو په اړه بحث کولو سره ، موږ پوهیږو چې د داسې سیسټم کارولو عادي نمونه دا ده: خلک د تیرو دوه ورځو لپاره د دوی غوښتنلیکونو لاګونو په لټه کې دي او نه غواړي چې له یو څخه ډیر انتظار وکړي. د یوې جوړې شوې پوښتنې پایلې لپاره دوهم.
- مدیرانو ټینګار وکړ چې سیسټم په اسانۍ سره د توزیع وړ وي که اړتیا وي، پرته له دې چې دوی ته اړتیا ولري چې دا څنګه کار کوي په ژوره توګه پوه شي.
- نو د ساتنې یوازینۍ دنده چې دا سیسټمونه وخت په وخت اړتیا لري د ځینې هارډویر بدلول دي.
- سربیره پردې، Odnoklassniki یو عالي تخنیکي دود لري: هر هغه خدمت چې موږ یې پیل کوو باید د ډیټا مرکز ناکامۍ ژوندي پاتې شي (ناڅاپه، غیر پلان شوي او په هر وخت کې).
د دې پروژې په پلي کولو کې وروستۍ اړتیا موږ ته خورا ډیر لګښت درلود، چې زه به یې په اړه نور تفصیل سره خبرې وکړم.
چارشنبه
موږ په څلورو ډیټا مرکزونو کې کار کوو، پداسې حال کې چې د Elasticsearch ډیټا نوډونه یوازې په دریو کې موقعیت لري (د یو شمیر غیر تخنیکي دلیلونو لپاره).
دا څلور ډیټا مرکزونه شاوخوا 18 زره مختلف لاګ سرچینې لري - هارډویر ، کانټینرونه ، مجازی ماشینونه.
مهم خصوصیت: کلستر په کانتینرونو کې پیل کیږي په فزیکي ماشینونو کې نه، مګر پر . کانټینرونه د 2 کور تضمین شوي ، د 2.0Ghz v4 سره ورته ، د پاتې کورونو د بیا کارولو امکان سره که دوی بې کاره وي.
په بل عبارت:
توپولوژي
ما په پیل کې د حل عمومي بڼه په لاندې ډول ولیدل:
- 3-4 VIPs د ګریلوګ ډومین د A-ریکارډ شاته دي، دا هغه پته ده چې لاګونه لیږل کیږي.
- هر VIP د LVS بیلانسر دی.
- له هغې وروسته، لاګونه د ګریلوګ بیټرۍ ته ځي، ځینې ډاټا د GELF بڼه کې دي، ځینې یې د سیسلوګ بڼه کې دي.
- بیا دا ټول په لویو بستونو کې د Elasticsearch همغږي کونکو بیټرۍ ته لیکل شوي.
- او دوی، په بدل کې، اړونده ډیټا نوډونو ته د لیکلو او لوستلو غوښتنې لیږي.
اصطلاحات
شاید هرڅوک په تفصیل سره اصطلاحات نه پوهیږي، نو زه غواړم په دې اړه لږ څه فکر وکړم.
Elasticsearch ډیری ډوله نوډونه لري - ماسټر، همغږي کوونکي، د ډاټا نوډ. د مختلف کلسترونو ترمینځ د مختلف لاګ بدلونونو او ارتباط لپاره دوه نور ډولونه شتون لري ، مګر موږ یوازې هغه لیست کارولي.
ماسټر
دا په کلستر کې موجود ټول نوډونه پینګ کوي، د کلستر تازه نقشه ساتي او د نوډونو ترمنځ یې توزیع کوي، د پیښو منطق پروسس کوي، او د کلستر پراخه کور کیپنګ مختلف ډولونه ترسره کوي.
همغږي کوونکي
یو واحد دنده ترسره کوي: د مراجعینو څخه د لوستلو یا لیکلو غوښتنې مني او دا ټرافیک لیږدوي. په هغه صورت کې چې د لیکلو غوښتنه شتون ولري، ډیری احتمال، دا به د ماسټر څخه پوښتنه وکړي چې د اړونده شاخص کوم شارډ باید په کې واچوي، او غوښتنه به نوره لارښوونه وکړي.
د معلوماتو نوډ
ډاټا ذخیره کوي، د لټون پوښتنې ترسره کوي چې له بهر څخه راځي او په هغې کې موقعیت لرونکي شارډونو عملیات ترسره کوي.
ګریلاګ
دا د ELK سټک کې د Logstash سره د کبانا د فیوژن په څیر یو څه دی. ګریلوګ دواړه یو UI او د لاګ پروسس پایپ لاین سره یوځای کوي. د هوډ لاندې، ګریلوګ کافکا او زوکیپر چلوي، کوم چې ګریلوګ ته د کلستر په توګه ارتباط چمتو کوي. ګریلوګ کولی شي لاګونه (کافکا) ذخیره کړي په هغه صورت کې چې Elasticsearch شتون نلري او د ټاکلو مقرراتو سره سم د لوستلو او لیکلو ناکامه غوښتنې تکرار کړئ ، ګروپ او نښه شوي لاګونه. د لوګسټاش په څیر، ګریلوګ فعالیت لري چې د قطارونو بدلولو لپاره مخکې له دې چې دوی Elasticsearch ته ولیکي.
برسېره پردې، ګریلوګ یو جوړ شوی خدمت کشف لري چې اجازه ورکوي، د یو موجود Elasticsearch نوډ پراساس، د ټول کلستر نقشه ترلاسه کړي او د ځانګړي ټګ لخوا یې فلټر کړي، کوم چې دا ممکنه کوي چې ځانګړي کانټینرونو ته مستقیم غوښتنې وړاندې کړي.
په لید کې دا یو څه داسې ښکاري:
دا د یو ځانګړي مثال څخه سکرین شاټ دی. دلته موږ د لټون پوښتنې پراساس هسټوګرام جوړوو او اړونده قطارونه ښکاره کوو.
لیګونه
د سیسټم جوړښت ته بیرته راستنیدل، زه غواړم په دې اړه نور تفصیل ته پام وکړم چې څنګه موږ د شاخص ماډل جوړ کړ ترڅو دا ټول په سمه توګه کار وکړي.
په پورتني ډیاګرام کې، دا ترټولو ټیټه کچه ده: د Elasticsearch ډیټا نوډونه.
انډیکس یو لوی مجازی وجود دی چې د Elasticsearch شارډونو څخه جوړ شوی. په خپل ځان کې، هر شارډ د لوسین شاخص پرته نور څه ندي. او هر یو لوسین شاخص، په بدل کې، یو یا څو برخې لري.
کله چې ډیزاین کول، موږ فکر وکړ چې د دې لپاره چې د ډیټا په لوی مقدار کې د لوستلو سرعت اړتیا پوره کړو، موږ اړتیا درلوده چې دا ډاټا په مساوي ډول د ډیټا نوډونو کې "خپرې" کړو.
دا د دې حقیقت پایله وه چې د هر شاخص شمیره (د نقلونو سره) باید په کلکه د ډیټا نوډونو شمیر سره مساوي وي. لومړی، د دې لپاره چې د نقل کولو فکتور ډاډ ترلاسه کړئ چې دوه سره مساوي وي (دا چې موږ کولی شو د کلستر نیمایي له لاسه ورکړو). او، دوهم، د کلستر په نیمایي کې د لوستلو او لیکلو غوښتنې پروسس کولو لپاره.
موږ لومړی د ذخیره کولو وخت د 30 ورځو په توګه ټاکلی.
د شارډونو ویش په ګرافیک ډول په لاندې ډول ښودل کیدی شي:
ټول تیاره خړ مستطیل یو شاخص دی. په دې کې کیڼ سور مربع لومړنی شارډ دی، په شاخص کې لومړی. او نیلي مربع د نقل شارډ دی. دوی په مختلفو معلوماتو مرکزونو کې موقعیت لري.
کله چې موږ بل شارډ اضافه کړو، دا دریم ډیټا مرکز ته ځي. او، په پای کې، موږ دا جوړښت ترلاسه کوو، کوم چې دا ممکنه کوي چې د ډیټا ثبات له لاسه ورکولو پرته DC له لاسه ورکړي:
د شاخصونو گردش، i.e. د نوي شاخص رامینځته کول او ترټولو زاړه حذف کول ، موږ دا د 48 ساعتونو سره مساوي کړي (د شاخص کارولو طرز سره سم: وروستي 48 ساعتونه ډیری وختونه لټون کیږي).
د دې شاخص گردش وقفه د لاندې دلایلو له امله ده:
کله چې د لټون غوښتنه یو ځانګړي ډیټا نوډ ته راځي ، نو د فعالیت له نظره ، دا خورا ګټور دی کله چې یو شارډ پوښتل کیږي ، که چیرې د هغې اندازه د نوډ د هپ اندازې سره پرتله شي. دا تاسو ته اجازه درکوي چې د شاخص "ګرم" برخه په ډنډ کې وساتئ او ژر تر ژره یې لاسرسی ومومئ. کله چې ډیری "ګرمې برخې" شتون ولري، د شاخص لټون سرعت کمیږي.
کله چې یو نوډ په یوه شارډ کې د لټون پوښتنې اجرا کول پیل کړي، دا د فزیکي ماشین د هایپر تریډینګ کور شمیر سره مساوي شمیر تارونه تخصیص کوي. که چیرې د لټون پوښتنه د شارډونو لوی شمیر اغیزه وکړي، نو د تارونو شمیر په متناسب ډول وده کوي. دا د لټون سرعت باندې منفي اغیزه لري او د نوي معلوماتو لیست کولو باندې منفي اغیزه کوي.
د اړین لټون ځنډ چمتو کولو لپاره، موږ پریکړه وکړه چې یو SSD وکاروو. د غوښتنو ګړندي کولو لپاره ، هغه ماشینونه چې دا کانټینرونه یې کوربه کړي باید لږترلږه 56 کورونه ولري. د 56 شمیره د مشروطه کافي ارزښت په توګه غوره شوې وه چې د تارونو شمیر ټاکي چې Elasticsearch به د عملیاتو پرمهال رامینځته کړي. په Elasitcsearch کې، د تار حوض ډیری پیرامیټونه په مستقیم ډول د شته کورونو په شمیر پورې اړه لري، کوم چې په پایله کې په مستقیم ډول په کلستر کې د نوډونو اړین شمیر اغیزه کوي د اصولو سره سم "لږ کورونه - ډیر نوډونه".
د پایلې په توګه، موږ وموندله چې په اوسط ډول یو شارډ شاوخوا 20 ګیګابایټ وزن لري، او په هر شاخص کې 1 شارډونه شتون لري. په دې اساس، که موږ دوی په هرو 360 ساعتونو کې یو ځل وګرځوو، نو موږ یې 48 لرو. هر شاخص د 15 ورځو لپاره ډاټا لري.
د معلوماتو لیکلو او لوستلو سرکټونه
راځئ چې معلومه کړو چې پدې سیسټم کې ډاټا څنګه ثبت کیږي.
راځئ چې ووایو ځینې غوښتنې له ګریلوګ څخه همغږي کونکي ته راځي. د مثال په توګه، موږ غواړو د 2-3 زره قطارونو شاخص وکړو.
همغږي کوونکي، د ګریلوګ څخه غوښتنه ترلاسه کولو سره، د ماسټر څخه پوښتنه وکړه: "د لیست کولو په غوښتنه کې، موږ په ځانګړې توګه یو شاخص مشخص کړی، مګر په کوم شارډ کې لیکل شوی نه و."
ماسټر ځواب ورکوي: "دا معلومات د شارډ نمبر 71 ته ولیکئ،" بیا وروسته دا مستقیم اړونده ډیټا نوډ ته لیږل کیږي، چیرې چې د شارډ نمبر 71 موقعیت لري.
وروسته له دې چې د راکړې ورکړې لاګ د ریپلیکا شارډ ته نقل شوی، کوم چې په بل ډیټا مرکز کې موقعیت لري.
د لټون غوښتنه له ګریلوګ څخه همغږي کونکي ته راځي. همغږي کونکی دا د شاخص سره سم تنظیموي، پداسې حال کې چې Elasticsearch د راؤنډ-رابین اصول په کارولو سره د لومړني شارډ او ریپلیکا شارډ ترمینځ غوښتنې توزیع کوي.
180 نوډونه په غیر مساوي ډول ځواب ورکوي، او پداسې حال کې چې دوی ځواب ورکوي، همغږي کوونکی هغه معلومات راټولوي چې دمخه د ګړندي ډیټا نوډونو لخوا "سپړل شوي" دي. له دې وروسته، کله چې یا ټول معلومات رارسیدلي وي، یا د غوښتنې وخت پای ته رسیدلی وي، دا هر څه مستقیم پیرودونکي ته ورکوي.
دا ټول سیسټم په اوسط ډول د تیرو 48 ساعتونو لپاره په 300-400ms کې د لټون پوښتنې پروسس کوي، د مخکښ وائلډ کارډ سره دا پوښتنې پرته.
د Elasticsearch سره ګلونه: جاوا ترتیب
د دې لپاره چې دا ټول هغه ډول کار وکړي چې موږ یې په اصل کې غواړو، موږ په کلستر کې د مختلفو شیانو په ډیبګ کولو کې ډیر وخت تیر کړ.
د موندلو ستونزو لومړۍ برخه د هغه لارې پورې اړه وه چې جاوا په Elasticsearch کې د ډیفالټ لخوا تنظیم شوی.
یوه ستونزه
موږ خورا لوی شمیر راپورونه لیدلي چې د لوسین په کچه ، کله چې د شالید دندې پرمخ ځي ، د لوسین برخې ضمیمه د خطا سره ناکامه کیږي. په ورته وخت کې، دا په لاګونو کې روښانه وه چې دا د OutOfMemoryError تېروتنه وه. موږ د ټیلی میټری څخه ولیدل چې هپ وړیا وه، او دا روښانه نده چې ولې دا عملیات ناکام وو.
دا معلومه شوه چې د لوسین شاخص ضمیمه د هپ څخه بهر واقع کیږي. او کانټینرونه د مصرف شوي سرچینو له مخې خورا سخت محدود دي. یوازې هېپ کولی شي په دې سرچینو کې فټ شي (د 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
د ټرپټ سره ستونزې پدې معنی دي چې زموږ کلستر په ثابت ډول کار کوي، مګر د شاخص شوي اسنادو په شمیر کې او د چلولو په جریان کې، فعالیت کافي ندي.
لومړۍ علامه ورسره مخ شوه: په تولید کې د ځینې "چاودنې" په جریان کې ، کله چې خورا لوی شمیر لاګونه ناڅاپه رامینځته کیږي ، د شاخص کولو غلطی es_rejected_execution په ګریلوګ کې په مکرر ډول فلش کول پیل کوي.
دا د دې حقیقت له امله و چې په یوه ډیټا نوډ کې thread_pool.write.queue، تر هغه وخته پورې چې Elasticsearch د دې توان لري چې د شاخص غوښتنې پروسس کړي او معلومات په ډیسک کې شارډ ته اپلوډ کړي، د ډیفالټ په واسطه یوازې 200 غوښتنې زیرمه کړي. او په د دې پیرامیټر په اړه ډیر لږ ویل شوي. یوازې د تارونو اعظمي شمیر او ډیفالټ اندازه په ګوته شوي.
البته، موږ د دې ارزښت مسح کولو ته لاړو او لاندې یې وموندل: په ځانګړې توګه، زموږ په ترتیب کې، تر 300 پورې غوښتنې په ښه توګه ساتل شوي، او لوړ ارزښت د دې حقیقت څخه ډک دی چې موږ بیا په بشپړ GC کې پرواز کوو.
سربیره پردې ، ځکه چې دا د پیغامونو بسته ده چې په یوه غوښتنه کې راځي ، نو دا اړینه وه چې ګریلوګ ټیک کړئ ترڅو دا په ډیری او کوچنیو بستونو کې نه لیکي ، مګر په لویو بستونو کې یا په هر 3 ثانیو کې یو ځل که چیرې بست لاهم بشپړ شوی نه وي. په دې حالت کې، دا معلومه شوه چې هغه معلومات چې موږ یې په Elasticsearch کې لیکو په دوه ثانیو کې نه، بلکې په پنځو کې شتون لري (کوم چې موږ ته ښه مناسب دی)، مګر د ریټریو شمیر چې باید د لوی له لارې فشار راوړلو لپاره جوړ شي. د معلوماتو ذخیره کمه شوې ده.
دا په ځانګړي توګه په هغه شیبو کې مهم دی کله چې یو څه په کوم ځای کې غورځیدلی وي او په غوسه یې د هغې په اړه راپور ورکوي ، ترڅو په بشپړ ډول سپیم شوي لچک ترلاسه نشي ، او یو څه وروسته - ګریلوګ نوډونه چې د بند شوي بفرونو له امله غیر فعال دي.
برسېره پردې، کله چې موږ په تولید کې ورته چاودنې درلودې، موږ د پروګرام کونکو او ټیسټرانو څخه شکایتونه ترلاسه کړل: په هغه وخت کې چې دوی واقعیا دې لاګونو ته اړتیا درلوده، دوی خورا ورو ورو ورکړل شوي.
دوی یې په معلومولو پیل وکړ. له یوې خوا، دا روښانه وه چې د لټون پوښتنې او د لیست کولو پوښتنې دواړه پروسس شوي، په اصل کې، په ورته فزیکي ماشینونو کې، او په یوه لاره یا بل ډول به ځینې کمښتونه وي.
مګر دا په جزوي ډول د دې حقیقت له امله مخنیوی کیدی شي چې د Elasticsearch په شپږمه نسخو کې یو الګوریتم څرګند شو چې تاسو ته اجازه درکوي د اړوندو ډیټا نوډونو ترمینځ پوښتنې توزیع کړئ نه د تصادفي راؤنډ رابین اصول (هغه کانټینر چې شاخص کوي او لومړني لري. شارډ ډیر بوخت کیدی شي، د چټک ځواب ورکولو لپاره به هیڅ لاره شتون ونلري)، مګر د دې غوښتنې لپاره لږ بار شوي کانټینر ته د نقل شارډ سره لیږل کیږي، کوم چې ډیر چټک ځواب ورکوي. په بل عبارت، موږ د use_adaptive_replica_selection ته ورسیدو: ریښتیا.
د لوستلو انځور داسې ښکاري:
دې الګوریتم ته لیږد دا ممکنه کړې چې په هغه شیبو کې د پوښتنې وخت د پام وړ ښه کړي کله چې موږ د لیکلو لپاره د لاګونو لوی جریان درلود.
په نهایت کې ، اصلي ستونزه د معلوماتو مرکز بې درده لرې کول وه.
هغه څه چې موږ د یو DC سره اړیکه له لاسه ورکولو سمدلاسه د کلستر څخه غوښتل:
- که موږ د ناکام معلوماتو مرکز کې اوسنی ماسټر ولرو، نو دا به بیا وټاکل شي او په بل DC کې بل نوډ ته د رول په توګه لیږدول کیږي.
- ماسټر به ژر تر ژره له کلستر څخه ټول د لاسرسي وړ نوډونه لرې کړي.
- د پاتې معلوماتو پراساس، هغه به پوه شي: د ورک شوي ډیټا مرکز کې موږ داسې او داسې لومړني شارډونه درلودل، هغه به په چټکۍ سره په پاتې ډیټا مرکزونو کې د تکمیلي نقل شارډونو ته وده ورکړي، او موږ به د معلوماتو لیست کولو ته دوام ورکړو.
- د دې په پایله کې، د کلستر لیکل او لوستل به په تدریجي ډول خراب شي، مګر په عمومي توګه هر څه به کار وکړي، که څه هم ورو، مګر په ثابت ډول.
لکه څنګه چې دا معلومه شوه، موږ د دې په څیر یو څه غوښتل:
او موږ لاندې ترلاسه کړل:
دا څنګه وشول؟
کله چې د معلوماتو مرکز سقوط وکړ، زموږ ماسټر خنډ شو.
Почему؟
حقیقت دا دی چې ماسټر د TaskBatcher لري، کوم چې په کلستر کې د ځانګړو دندو او پیښو ویشلو مسولیت لري. د نوډ هر ډول وتلو، د ریپلیکا څخه لومړني ته د شارډ هرډول وده، په کوم ځای کې د شارډ جوړولو لپاره کومه دنده - دا ټول لومړی ټاسک بیچر ته ځي، چیرې چې دا په ترتیب سره او په یوه تار کې پروسس کیږي.
د یو ډیټا سنټر د وتلو په وخت کې، دا معلومه شوه چې په ژوندي پاتې ډیټا سنټرونو کې ټول ډیټا نوډونه دا خپله دنده ګڼي چې ماسټر ته خبر ورکړي "موږ داسې او داسې شارډونه او داسې نور ډیټا نوډونه له لاسه ورکړل."
په ورته وخت کې، ژوندي پاتې شوي ډاټا نوډونه دا ټول معلومات اوسني ماسټر ته واستول او هڅه یې وکړه چې د تایید لپاره انتظار وکړي چې هغه یې ومنله. دوی د دې لپاره انتظار نه کاوه، ځکه چې ماسټر د هغه ځواب په پرتله ګړندی دندې ترلاسه کړې. نوډونو د تکرار غوښتنو وخت پای ته ورساوه، او په دې وخت کې ماسټر حتی د ځواب ورکولو هڅه نه کوله، مګر په بشپړ ډول د لومړیتوبونو له مخې د غوښتنو ترتیبولو دنده کې جذب شوی و.
په ټرمینل بڼه کې، دا معلومه شوه چې د معلوماتو نوډونه ماسټر ته سپیم کړي چې دا بشپړ GC ته لاړ. له هغې وروسته، زموږ ماسټر رول یو څه بل نوډ ته لاړ، په بشپړ ډول ورته ورته پیښ شو، او د پایلې په توګه کلستر په بشپړه توګه سقوط وکړ.
موږ اندازه کول ، او د 6.4.0 نسخه دمخه ، چیرې چې دا ټاکل شوی و ، دا زموږ لپاره کافي و چې په ورته وخت کې له 10 څخه یوازې 360 ډیټا نوډونه تولید کړو ترڅو کلسټر په بشپړ ډول بند کړو.
دا یو څه داسې ښکاري:
د 6.4.0 نسخه وروسته، چیرې چې دا ناوړه بګ حل شوی و، د ډیټا نوډونو د ماسټر وژل بند کړل. مګر دې هغه "هوښیار" نه کړ. د مثال په توګه: کله چې موږ 2، 3 یا 10 (د یو بل پرته بل شمیره) ډیټا نوډونه تولیدوو، ماسټر یو څه لومړی پیغام ترلاسه کوي چې وایي چې نوډ A پاتې شوی، او هڅه کوي نوډ B، نوډ C پدې اړه ووایی، نوډ 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 ځانګړتیاوې په پام کې ونیسئ. د لټون او شاخص کولو لپاره د ترتیب کولو اختیارونه او ډیفالټ ارزښتونه تشریح کوي، مګر د thread_pool.management په اړه په بشپړه توګه خاموش دی. دا تارونه پروسس کوي، په ځانګړې توګه، پوښتنې لکه _cat/shards او ورته ورته نور، چې د څارنې لیکلو په وخت کې کارول اسانه دي. هر څومره چې کلستر لوی وي، په هماغه اندازه ورته غوښتنې د وخت په یو واحد کې اجرا کیږي، او پورته ذکر شوي thread_pool.management نه یوازې په رسمي اسنادو کې نه وړاندې کیږي، بلکې د ډیفالټ له مخې تر 5 تارونو پورې محدود دی، کوم چې په چټکۍ سره له مینځه وړل کیږي. کوم چې څارنه په سمه توګه کار کوي.
هغه څه چې زه غواړم په پایله کې ووایم: موږ دا وکړل! موږ وکولی شو خپلو برنامو او پراختیا کونکو ته داسې وسیله ورکړو چې په نږدې هر حالت کې کولی شي په ګړندي او باوري توګه د هغه څه په اړه معلومات چمتو کړي چې په تولید کې پیښیږي.
هو، دا خورا پیچلي وګرځید، مګر، سره له دې، موږ وکولی شو خپلې هیلې په موجوده محصولاتو کې تنظیم کړو، کوم چې موږ د ځان لپاره پیچ او بیا لیکلو ته اړتیا نه درلوده.
سرچینه: www.habr.com