بایوینو - توزیع شوی، د توزیع وړ میټریک راټولونکی

نو تاسو میټریکونه راټول کړئ. لکه څنګه چې موږ یو. موږ میټریک هم راټولوو. البته، د سوداګرۍ لپاره اړین دی. نن ورځ موږ به زموږ د څارنې سیسټم د لومړۍ لینک په اړه وغږیږو - د statsd-compatible aggregation server بایوینو، ولې موږ دا لیکلي او ولې موږ بربیک پریښود.

زموږ د تیرو مقالو څخه (1, 2) تاسو کولی شئ ومومئ چې تر یو څه وخت پورې موږ د کارولو نښې راټولې کړې د. دا په C کې لیکل شوی. د کوډ له نظره، دا د پلګ په څیر ساده دی (دا مهم دی کله چې تاسو مرسته کول غواړئ) او تر ټولو مهم، دا په هر ثانیه کې زموږ د 2 ملیون میټریکونو حجم (MPS) اداره کوي. پرته له کومې ستونزې. سندونه د ستوري سره د 4 ملیون MPS ملاتړ کوي. دا پدې مانا ده چې تاسو به بیان شوي ارقام ترلاسه کړئ که تاسو په لینکس کې شبکه په سمه توګه تنظیم کړئ. (موږ نه پوهیږو چې تاسو څومره MPS ترلاسه کولی شئ که تاسو شبکه پریږدئ لکه څنګه چې ده). د دې ګټو سره سره، موږ د بربیک په اړه ډیری جدي شکایتونه درلودل.

ادعا 1. ګیتوب ، د پروژې پراختیا کونکی ، د دې ملاتړ بند کړ: د پیچونو او فکسونو خپرول ، زموږ منل او (نه یوازې زموږ) PR. په تیرو څو میاشتو کې (د 2018 کال د فبروري څخه تر مارچ پورې)، فعالیت بیا پیل شوی، مګر تر دې دمخه شاوخوا 2 کاله بشپړ آرام و. برسېره پر دې، پروژه د پراختیا په حال کې ده د داخلي Gihub اړتیاو لپاره، کوم چې کولی شي د نوي ځانګړتیاو معرفي کولو کې جدي خنډ شي.

ادعا 2. د محاسبې دقت. بربیک د مجموعې لپاره ټولټال 65536 ارزښتونه راټولوي. زموږ په قضیه کې، د ځینو میترونو لپاره، د راټولولو دوره (30 ثانیو) په جریان کې، ډیر ارزښتونه ممکن راشي (1 په چوکۍ کې). د دې نمونې په پایله کې، اعظمي او لږترلږه ارزښتونه بې ګټې ښکاري. د مثال په توګه، دا ډول:

لکه څنګه چې دا وه

څنګه باید وی

د ورته دلیل لپاره، مقدارونه عموما په غلط ډول محاسبه کیږي. دلته د 32-bit فلوټ اوور فلو سره بګ اضافه کړئ ، کوم چې عموما سرور سیګفالټ ته لیږي کله چې ښکاري بې ګناه میټریک ترلاسه کوي ، او هرڅه عالي کیږي. بګ، په لاره کې، نه دی ټاکل شوی.

او په پای کې، د X ادعا وکړئ. د لیکلو په وخت کې، موږ چمتو یو چې دا ټولو 14 نورو یا لږ کاري سټیټډ پلي کولو ته وړاندې کړو چې موږ یې موندلی شو. راځئ تصور وکړو چې یو واحد زیربنا دومره وده کړې چې د 4 ملیون MPS منل نور کافي ندي. یا حتی که دا لا وده نه وي کړې، مګر میټریکونه لا دمخه ستاسو لپاره خورا مهم دي چې حتی په چارټونو کې لنډ، 2-3 دقیقې ډوب کولی شي دمخه مهم شي او د مدیرانو ترمنځ د نه منلو وړ خپګان لامل شي. څرنګه چې د خپګان درملنه یو بې شکره کار دی، تخنیکي حلونو ته اړتیا ده.

لومړی ، د خطا زغم ، نو په سرور کې ناڅاپه ستونزه په دفتر کې د رواني زومبي اپوکلپس لامل نه کیږي. دوهم، اندازه کول د 4 ملیون MPS څخه ډیر د منلو وړ وي، پرته له دې چې د لینکس شبکې سټیک ته ژور کیندل شي او په آرامۍ سره د اړتیا وړ اندازې ته "په پراخه کچه" وده وکړي.

څرنګه چې موږ د اندازه کولو لپاره خونه درلوده، موږ پریکړه وکړه چې د غلط زغم سره پیل وکړو. "په اړه! د خطا زغم! دا ساده ده، موږ دا کولی شو، "موږ فکر وکړ او 2 سرورونه مو پیل کړل، په هر یو کې د بربیک کاپي پورته کړه. د دې کولو لپاره، موږ باید دواړه سرورونو ته د میټریکونو سره ټرافيک کاپي کړو او حتی د دې لپاره یې ولیکئ کوچنۍ اسانتیا. موږ د دې سره د غلط زغم ستونزه حل کړه، مګر ... ډیر ښه نه. په لومړي سر کې هرڅه عالي ښکاري: هر بربیک د راټولولو خپله نسخه راټولوي ، په هر 30 ثانیو کې یو ځل ګرافیټ ته ډیټا لیکي ، زاړه وقفه له سره لیکي (دا د ګرافیټ اړخ کې ترسره کیږي). که یو سرور ناڅاپه ناکام شي، موږ تل د راټول شوي ډیټا خپل کاپي سره دوهم یو لرو. مګر دلته ستونزه ده: که سرور ناکام شي، په ګرافونو کې "لیدل" ښکاري. دا د دې حقیقت له امله دی چې د بربیک 30-ثانوي وقفې همغږي نه دي، او د حادثې په وخت کې یو له دوی څخه نه لیکل کیږي. کله چې دویم سرور پیل شي، ورته شی پیښیږي. د زغم وړ، مګر زه ښه غواړم! د توزیع کولو ستونزه هم له مینځه تللې نه ده. ټول میټریکونه لاهم یو واحد سرور ته "پرواز" کوي، او له همدې امله موږ د شبکې کچې پورې اړه لري، ورته 2-4 ملیون MPS پورې محدود یو.

که تاسو د ستونزې په اړه لږ فکر وکړئ او په ورته وخت کې د بیلچ سره واوره وخورئ، نو لاندې روښانه مفکوره به ذهن ته راشي: تاسو یو سټیټ ته اړتیا لرئ چې په توزیع شوي حالت کې کار وکړي. دا هغه یو دی چې په وخت او میټریکونو کې د نوډونو ترمنځ همغږي پلي کوي. "البته ، دا ډول حل شاید دمخه شتون ولري ،" موږ وویل او ګوګل ته لاړو…. او دوی هیڅ ونه موندل. د مختلف احصایو لپاره اسنادو ته له تګ وروسته (https://github.com/etsy/statsd/wiki#server-implementations د دسمبر 11.12.2017، XNUMX پورې)، موږ هیڅ شی ونه موندل. په ښکاره ډول ، نه پراختیا کونکي او نه هم د دې حلونو کارونکي لاهم د ډیری میټریکونو سره مخ شوي ، که نه نو دوی به خامخا د یو څه سره راشي.

او بیا موږ د "لوبې" سټیټډ - بایوینو په اړه یادونه وکړه ، کوم چې په Just for Fun hackathon کې لیکل شوی و (د پروژې نوم د هیکاتون له پیل دمخه د سکریپټ لخوا رامینځته شوی و) او پوه شو چې موږ په عاجل ډول خپل سټیټډ ته اړتیا لرو. د څه لپاره؟

• ځکه چې په نړۍ کې ډیر لږ سټیټ کلون شتون لري،
• ځکه چې دا ممکنه ده چې مطلوب یا مطلوب غلطی زغم او پیمانه کولو ته نږدې چمتو کړئ (د سرورونو ترمینځ د راټول شوي میټریکونو همغږي کول او د شخړو لیږلو ستونزې حل کول)
• ځکه چې دا ممکنه ده چې د میټریکونو محاسبه د بربیک په پرتله ډیر دقیق وي،
• ځکه چې تاسو کولی شئ نور تفصيلي احصایې پخپله راټول کړئ، کوم چې بربیک په عملي توګه موږ ته ندي چمتو کړي،
• ځکه چې ما د دې فرصت درلود چې زما د خپل هایپرپرفارمنس توزیع شوي پیمانه غوښتنلیک برنامه کړم ، کوم چې به په بشپړ ډول د بل ورته هایپر جوړښت جوړښت تکرار نکړي ... ښه ، بس.

په څه لیکل؟ البته، په Rust کې. ولې؟

• ځکه چې لا دمخه د پروټوټایپ حل شتون درلود ،
• ځکه چې د مقالې لیکوال لا دمخه په هغه وخت کې زنګ پیژني او لیواله و چې په خلاصې سرچینې کې د ځای په ځای کولو فرصت سره د تولید لپاره پدې کې یو څه ولیکي ،
• ځکه چې د GC سره ژبې زموږ لپاره مناسب ندي د ترلاسه شوي ترافیک طبیعت له امله (تقریبا ریښتیني وخت) او د GC وقفې په عملي ډول د منلو وړ ندي ،
• ځکه چې تاسو د C سره پرتله کولو اعظمي فعالیت ته اړتیا لرئ
• ځکه چې زنګ موږ ته بې ډاره همغږي چمتو کوي، او که موږ دا په C/C++ کې لیکل پیل کړل، نو موږ به د بربیک په پرتله حتی ډیر زیان منونکي، د بفر اوور فلو، د نسل شرایطو او نورو ډارونکي کلمو سره مخ شوي وای.

د زنګ په وړاندې یو دلیل هم شتون درلود. شرکت په زنګ کې د پروژو جوړولو تجربه نه درلوده، او اوس موږ په اصلي پروژه کې د کارولو پلان نه لرو. له همدې امله، جدي ویره وه چې هیڅ شی به کار ونه کړي، مګر موږ پریکړه وکړه چې یو فرصت واخلو او هڅه وکړو.

وخت تېر شو...

په نهایت کې ، د څو ناکامو هڅو وروسته ، لومړۍ کاري نسخه چمتو شوه. څه شوي دي؟ همداسې وشول.

هر نوډ خپل میټریکونه ترلاسه کوي او راټولوي، او د هغه ډولونو لپاره میټریکونه نه راټولوي چیرې چې د دوی بشپړ سیټ د وروستي راټولولو لپاره اړین وي. نوډونه د یو بل سره د یو ډول توزیع شوي لاک پروتوکول لخوا وصل شوي ، کوم چې تاسو ته اجازه درکوي د دوی په مینځ کې یوازینی یو غوره کړئ (دلته موږ ژړل) چې لوی ته د میټریک لیږلو وړ دی. دا ستونزه اوس مهال د حل په حال کې ده قونسلخو په راتلونکي کې د لیکوال ارمانونه پراخیږي خپل تطبيق رافټ، چیرې چې خورا وړ یو به، البته، د توافق مشر نوډ وي. د اجماع سربیره، نوډونه ډیری وختونه (په هره ثانیه کې یو ځل د ډیفالټ لخوا) خپلو ګاونډیانو ته د مخکې راټول شوي میټریک هغه برخې لیږي چې دوی یې په دې ثانیه کې راټول کړي. دا معلومه شوه چې اندازه کول او د غلطۍ زغم ساتل کیږي - هر نوډ لاهم د میټریکونو بشپړ سیټ لري، مګر میټریکونه دمخه راټول شوي، د TCP له لارې لیږل شوي او په بائنری پروتوکول کې کوډ شوي، نو د نقل کولو لګښتونه د UDP په پرتله د پام وړ کم شوي. د کافي لوی شمیر راتلونکو میټریکونو سره سره ، جمع کول خورا لږ حافظې او حتی لږ CPU ته اړتیا لري. زموږ د لوړ فشار وړ وړتیا لپاره، دا یوازې د څو لسیزو میګابایټ ډیټا دی. د اضافي بونس په توګه، موږ په ګرافیټ کې هیڅ غیر ضروري ډیټا بیا لیکو، لکه څنګه چې د بربیک قضیه وه.

د میټریکونو سره د UDP پاکټونه د ساده راؤنډ رابین له لارې د شبکې تجهیزاتو کې د نوډونو ترمینځ غیر متوازن دي. البته، د شبکې هارډویر د پاکټونو مینځپانګه نه تجزیه کوي او له همدې امله کولی شي په هر ثانیه کې له 4M پاکټونو څخه ډیر راوباسي ، د میټریکونو یادونه نه کوي چې په اړه یې هیڅ نه پوهیږي. که موږ په پام کې ونیسو چې میټریکونه په هر پاکټ کې په یو وخت کې نه راځي ، نو موږ پدې ځای کې د فعالیت کومې ستونزې نه وړاندوینه کوو. که چیرې یو سرور خراب شي، د شبکې وسیله په چټکۍ سره (د 1-2 ثانیو دننه) دا حقیقت کشفوي او د غورځیدلي سرور له گردش څخه لیرې کوي. د دې په پایله کې، غیر فعال (د بیلګې په توګه، غیر مشر) نوډونه په چارټونو کې د کمښت په پام کې نیولو پرته په عملي توګه فعال او بند کیدی شي. اعظمي چې موږ له لاسه ورکوو د میټریکونو برخه ده چې په وروستي ثانیه کې راغلي. د یو مشر ناڅاپه له لاسه ورکول/بندول/سوئچ کول به بیا هم یو کوچنی ګډوډي رامینځته کړي (د 30 ثانیو وقفه لاهم له همغږي څخه بهر ده) ، مګر که چیرې د نوډونو ترمینځ اړیکه شتون ولري ، نو دا ستونزې کم کیدی شي ، د مثال په توګه ، د ترکیب پاکټونو لیږلو سره .

د داخلي جوړښت په اړه لږ څه. غوښتنلیک، البته، څو اړخیز دی، مګر د تار کولو جوړښت د هغه څخه توپیر لري چې په بربیک کې کارول کیږي. په بربیک کې تارونه یو شان دي - هر یو د معلوماتو راټولولو او راټولولو لپاره مسؤل دي. په بایوینو کې، کارګران په دوو ډلو ویشل شوي دي: هغه کسان چې د شبکې مسؤل دي او هغه کسان چې د راټولولو مسولیت لري. دا څانګه تاسو ته اجازه درکوي په ډیر انعطاف سره د میټریک ډول پورې اړوند غوښتنلیک اداره کړئ: چیرې چې قوي راټولولو ته اړتیا وي ، تاسو کولی شئ راټولونکي اضافه کړئ ، چیرې چې د شبکې ترافیک ډیر شتون لري ، تاسو کولی شئ د شبکې جریانونو شمیر اضافه کړئ. اوس مهال، زموږ په سرورونو کې موږ په 8 شبکې او 4 راټولولو جریان کې کار کوو.

د شمېرنې (د راټولولو لپاره مسؤل) برخه خورا ستړي ده. د شبکې جریانونو لخوا ډک شوي بفرونه د شمیرنې جریانونو ترمینځ ویشل شوي ، چیرې چې دوی وروسته تجزیه او راټول شوي. د غوښتنې سره سم، نورو نوډونو ته د لیږلو لپاره میټریکونه ورکول کیږي. دا ټول، د نوډونو ترمنځ د معلوماتو لیږلو او د قونسل سره کار کولو په شمول، په غیر متناسب ډول ترسره کیږي، په چوکاټ کې پرمخ ځي ټیکیو.

د پراختیا په جریان کې ډیرې ستونزې د شبکې برخې لخوا رامینځته شوي چې د میټریکونو ترلاسه کولو مسؤلیت لري. په جلا جلا ادارو کې د شبکې جریان جلا کولو اصلي هدف دا وه چې د جریان مصرف وخت کم کړي. نه د ساکټ څخه ډاټا لوستلو لپاره. د غیر متناسب UDP او منظم recvmsg کارولو اختیارونه په چټکۍ سره ورک شوي: لومړی د پیښې پروسس کولو لپاره خورا ډیر کارونکي ځای CPU مصرفوي ، دوهم د ډیری شرایطو سویچونو ته اړتیا لري. له همدې امله دا اوس کارول کیږي recvmmsg د لویو بفرانو سره (او بفران، ښاغلو افسران، تاسو ته هیڅ شی نه دي!). د منظم UDP لپاره ملاتړ د سپکو قضیو لپاره ساتل کیږي چیرې چې recvmmsg ته اړتیا نشته. په ملټي میسیج حالت کې ، دا ممکنه ده چې اصلي شی ترلاسه کړئ: ډیری وخت ، د شبکې تار د OS کتار راوباسي - د ساکټ څخه ډیټا لوستل کیږي او د کارونکي ځای بفر ته یې لیږدوي ، یوازې کله ناکله د ډک شوي بفر ورکولو لپاره بدلیږي. راټولونکي په ساکټ کې قطار په عملي توګه نه راټولیږي، د راټیټ شوي کڅوړو شمیر په عملي توګه وده نه کوي.

تبصره

په ډیفالټ ترتیباتو کې، د بفر اندازه خورا لوی وي. که تاسو ناڅاپه پریکړه وکړئ چې سرور پخپله هڅه وکړئ، تاسو ممکن د دې حقیقت سره مخ شئ چې د لږ شمیر میټریکونو لیږلو وروسته، دوی به ګرافیټ ته ونه رسیږي، د شبکې جریان بفر کې پاتې کیږي. د لږ شمیر میټریکونو سره کار کولو لپاره ، تاسو اړتیا لرئ په ترتیب کې کوچني ارزښتونو ته د بفسیز او کاري قطار اندازه تنظیم کړئ.

په پای کې، د چارټ مینه والو لپاره ځینې چارټونه.

د هر سرور لپاره د راتلونکو میټریکونو شمیر په اړه احصایې: له 2 ملیون څخه ډیر MPS.

د یو نوډ غیر فعال کول او د راتلونکو میټریکونو بیا توزیع کول.

د وتلو میټریکونو احصایې: یوازې یو نوډ تل لیږي - د برید مالک.

د هر نوډ د عملیاتو احصایې، د سیسټم مختلف ماډلونو کې د غلطیتونو په پام کې نیولو سره.

د راتلونکو میټریکونو توضیحات (د میټریک نومونه پټ دي).

موږ په راتلونکي کې د دې ټولو سره څه کولو پلان لرو؟ البته، کوډ ولیکئ، لعنت...! پروژه په اصل کې پلان شوې وه چې خلاصې سرچینې وي او د خپل ژوند په اوږدو کې به همداسې پاتې وي. زموږ په سمدستي پلانونو کې زموږ د رافټ نسخې ته بدلول ، د پیر پروتوکول ډیر پورټ ایبل ته بدلول ، د اضافي داخلي احصایو معرفي کول ، د میټریک نوي ډولونه ، د بګ فکسونه او نور پرمختګونه شامل دي.

البته، هرڅوک د پروژې په پراختیا کې مرسته کولو ته ښه راغلاست ویل کیږي: PR، مسلې رامینځته کړئ، که امکان ولري موږ به ځواب ووایو، ښه کړو، او نور.

د دې په ویلو سره، دا ټول خلک دي، زموږ هاتیان واخلئ!

سرچینه: www.habr.com