په Quay.io کې پوسټ مارټم شتون نلري

نوټ. ژباړه: د اګست په پیل کې، Red Hat په عامه توګه د لاسرسي ستونزې حل کولو په اړه خبرې وکړې چې د دې خدماتو کاروونکي په تیرو میاشتو کې ورسره مخ شوي وو. Quay.io (دا د کانټینر عکسونو لپاره د راجسټری پراساس دی ، کوم چې شرکت د CoreOS پیرود سره ترلاسه کړی). د دې خدمت سره ستاسو د علاقې په پام کې نیولو پرته ، هغه لاره چې د شرکت SRE انجینرانو د حادثې لاملونو تشخیص او له مینځه وړو لپاره اخیستې لارښود دی.

د می په 19، سهار وختي (د ختیځې ورځې د رڼا وخت، EDT)، د quay.io خدمت ټکر شو. حادثې د quay.io مصرف کونکي او د خلاصې سرچینې پروژې دواړه اغیزمن کړل چې د سافټویر جوړولو او توزیع لپاره د quay.io د پلیټ فارم په توګه کاروي. Red Hat د دواړو باور ته ارزښت ورکوي.

د SRE انجنیرانو یوه ډله سمدلاسه ښکیل شوه او هڅه یې وکړه چې ژر تر ژره د Quay خدمت ثبات کړي. په هرصورت، پداسې حال کې چې دوی دا کار کاوه، پیرودونکو د نوي عکسونو د فشارولو وړتیا له لاسه ورکړه، او یوازې کله ناکله دوی وکولی شول موجوده عکسونه راوباسي. د ځینې نامعلوم دلیل لپاره، د quay.io ډیټابیس د بشپړ ظرفیت لپاره د خدمت اندازه کولو وروسته بند شوی و.

«څه بدلون راغلی؟"- دا لومړۍ پوښتنه ده چې معمولا په داسې قضیو کې پوښتل کیږي. موږ ولیدل چې د مسلې لږ وخت دمخه، د OpenShift وقف شوي کلستر (کوم چې quay.io پرمخ وړي) نسخه 4.3.19 ته تازه کول پیل کړل. له هغه وخته چې quay.io په Red Hat OpenShift Dedicated (OSD) چلیږي، منظم تازه کول معمول وو او هیڅکله یې ستونزې نه رامینځته کړې. سربیره پردې، په تیرو شپږو میاشتو کې، موږ په خدمت کې د کوم خنډ پرته څو ځله د Quay کلسترونه لوړ کړي دي.

پداسې حال کې چې موږ هڅه کوله چې خدمت بیرته راوباسئ، نورو انجینرانو د سافټویر پخوانۍ نسخه سره د نوي OSD کلستر چمتو کول پیل کړل، ترڅو که څه پیښ شي، دوی کولی شي په دې کې هرڅه ځای پرځای کړي.

د اصلي لاملونو تحلیل

د ناکامۍ اصلي علامه د لسګونو زرو ډیټابیس اتصالاتو واوره وه ، کوم چې د MySQL مثال په مؤثره توګه د کار وړ نه و. دا د ستونزې تشخیص ستونزمن کړی. موږ د پیرودونکو څخه د ډیرو اړیکو حد ټاکلی ترڅو د SRE ټیم سره د مسلې ارزولو کې مرسته وکړي. موږ ډیټابیس ته کوم غیر معمولي ترافیک ونه لید: په حقیقت کې ، ډیری غوښتنې لوستل شوي ، او یوازې یو څو لیکل شوي.

موږ هم هڅه وکړه چې د ډیټابیس ټرافیک کې یوه نمونه وپیژنو چې د دې واورې د اوریدو لامل کیدی شي. په هرصورت، موږ په لاګونو کې هیڅ ډول نمونې نشو موندلی. پداسې حال کې چې د OSD 4.3.18 سره نوي کلستر ته چمتو کیدو ته انتظار باسي ، موږ د quay.io پوډونو په لاره اچولو ته دوام ورکړ. هرکله چې کلستر بشپړ ظرفیت ته ورسیږي، ډیټابیس به کنګل کیږي. د دې معنی دا وه چې د ټولو quay.io پوډونو سربیره د RDS مثال بیا پیل کول اړین وو.

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

Quay.io په نوي OSD کلستر کې په ثابت ډول کار وکړ، نو موږ بیرته د ډیټابیس لاګونو ته لاړ، مګر داسې اړیکه یې ونه موندله چې خنډونه تشریح کړي. د OpenShift انجینرانو زموږ سره کار وکړ ترڅو پوه شي چې آیا په Red Hat OpenShift 4.3.19 کې بدلونونه کولی شي د Quay سره ستونزې رامینځته کړي. په هرصورت، هیڅ شی ونه موندل شو، او دا ممکنه نه وه چې د لابراتوار شرایطو کې ستونزه بیا تولید کړي.

دوهم ناکامي

د می په 28 ، د ماسپښین EDT څخه لږ دمخه ، quay.io د ورته نښې سره یوځل بیا ټکر شو: ډیټابیس بند شوی و. او بیا مو خپلې ټولې هڅې په تحقیقاتو کې واچولې. تر ټولو لومړی، دا اړینه وه چې خدمت بیرته راوباسي. په هرصورت دا ځل د RDS ریبوټ کول او د quay.io پوډونو بیا پیل کول هیڅ ونه کړل: د ارتباطاتو یو بل واوره د اډه ویجاړه کړې ده. اخر ولې؟

Quay په Python کې لیکل شوی او هر پوډ د یو واحد واحد کانټینر په توګه کار کوي. د کانټینر چلولو وخت په ورته وخت کې ډیری موازي دندې پرمخ وړي. موږ کتابتون کاروو gevent لاندې gunicorn د ویب غوښتنلیکونو پروسس کولو لپاره. کله چې غوښتنه Quay ته راځي (زموږ د خپل API له لارې، یا د Docker's API له لارې)، دا د جیوینټ کارګر ګمارل کیږي. معمولا دا کارګر باید د ډیټابیس سره اړیکه ونیسي. د لومړۍ ناکامۍ وروسته، موږ وموندله چې د جیوینټ کارګران د ډیفالټ ترتیباتو په کارولو سره ډیټابیس سره وصل شوي.

د Quay پوډونو د پام وړ شمیر او په هره ثانیه کې په زرګونو راتلونکو غوښتنو ته په پام سره، د ډیټابیس لوی شمیر اړیکې کولی شي په تیوریکي توګه د MySQL مثال له پامه وغورځوي. د څارنې څخه مننه، دا معلومه شوه چې Quay په هره ثانیه کې په اوسط ډول 5 زره غوښتنې پروسس کوي. د ډیټابیس سره د اړیکو شمیر تقریبا ورته وو. 5 زره اړیکې زموږ د RDS مثال په ظرفیت کې ښه وې (کوم چې د لسګونو زرو په اړه نشي ویل کیدی). د ځینو دلیلونو لپاره د اړیکو په شمیر کې غیر متوقع سپکونه شتون درلودپه هرصورت، موږ د راتلونکو غوښتنو سره هیڅ اړیکه نه ده لیدلې.

دا ځل موږ هوډ درلود چې د ستونزې سرچینه ومومئ او له منځه یوسو، او خپل ځان په ریبوټ پورې محدود نه کړو. د Quay کوډبیس ته د هر کارمند لپاره ډیټابیس ته د ارتباطاتو شمیر محدودولو لپاره بدلونونه رامینځته شوي gevent دا شمیره په ترتیب کې یو پیرامیټر شو: دا ممکنه وه چې دا د نوي کانټینر عکس رامینځته کولو پرته په الوتنه کې بدل کړئ. د دې موندلو لپاره چې څومره اړیکې په ریښتیني ډول اداره کیدی شي ، موږ په سټینګ چاپیریال کې ډیری ازموینې ترسره کړې ، مختلف ارزښتونه تنظیم کړل ترڅو وګورو چې دا به د بار ازموینې سناریو باندې څنګه اغیزه وکړي. په پایله کې، دا وموندل شوه Quay د 502 غلطیو اچول پیل کوي کله چې د اړیکو شمیر له 10 زرو څخه ډیر وي.

موږ سمدلاسه دا نوې نسخه تولید ته ځای په ځای کړه او د ډیټابیس اتصال مهالویش څارنه یې پیل کړه. په تیرو وختونو کې، اډه شاوخوا 20 دقیقې وروسته تړل شوې وه. د 30 ستونزو څخه پاک دقیقو وروسته موږ امید درلود، او یو ساعت وروسته موږ باور درلود. موږ سایټ ته ترافیک بیرته راستانه کړ او د پوسټ مارټم تحلیل مو پیل کړ.

د بندیدو لامل شوي ستونزې څخه د تیرولو اداره کول ، موږ د هغې اصلي لاملونه نه دي موندلي. دا تایید شوه چې دا په OpenShift 4.3.19 کې د کوم بدلون سره تړاو نلري، ځکه چې ورته شی په 4.3.18 نسخه کې پیښ شوي، کوم چې مخکې له کومې ستونزې پرته د Quay سره کار کاوه.

په ښکاره ډول په کلستر کې بل څه پټ وو.

مفصله مطالعه

Quay.io پرته له کومې ستونزې د شپږو کلونو لپاره ډیټابیس سره وصل کولو لپاره ډیفالټ تنظیمات کارولي. څه بدل شول؟ دا روښانه ده چې دا ټول وخت په quay.io کې ترافیک په ثابت ډول وده کوي. زموږ په قضیه کې، داسې ښکاري چې یو څه حد ته رسیدلی وي، کوم چې د اړیکو د واورې تودوخې لپاره د محرک په توګه کار کاوه. موږ د دویمې ناکامۍ وروسته د ډیټابیس لاګونو مطالعې ته دوام ورکړ، مګر هیڅ ډول نمونې یا څرګندې اړیکې مو ونه موندلې.

په ورته وخت کې، د SRE ټیم د Quay غوښتنې مشاهده کولو او د عمومي خدماتو روغتیا ته وده ورکولو باندې کار کوي. نوي میټریکونه او ډشبورډونه ځای په ځای شوي دي، دا په ګوته کوي چې د کوې کومې برخې د پیرودونکو لخوا خورا په تقاضا کې دي.

Quay.io د جون تر 9 پورې ښه کار وکړ. نن سهار (EDT) موږ بیا د ډیټابیس اړیکو شمیر کې د پام وړ زیاتوالی ولید. دا ځل د ځنډ وخت نه و، ځکه چې نوي پیرامیټر د دوی شمیر محدود کړی او دوی ته اجازه نه ورکوي چې د MySQL throughput څخه ډیر شي. په هرصورت، د نیم ساعت لپاره، ډیری کاروونکو د quay.io ورو فعالیت یادونه وکړه. موږ په چټکۍ سره د اضافي څارنې وسیلو په کارولو سره ټول ممکنه معلومات راټول کړل. ناڅاپه یوه بیلګه راڅرګنده شوه.

په ارتباطاتو کې د زیاتوالي دمخه ، د اپلیکیشن راجسټری API ته لوی شمیر غوښتنې شوې وې. د اپلیکیشن راجسټری د quay.io یو لږ پیژندل شوی خصوصیت دی. دا تاسو ته اجازه درکوي چې شیان لکه هیلم چارټونه او کانټینرونه د بډایه میټاډاټا سره ذخیره کړئ. د quay.io ډیری کاروونکي د دې ځانګړتیا سره کار نه کوي، مګر د Red Hat OpenShift په فعاله توګه کاروي. OperatorHub د OpenShift برخې په توګه ټول آپریټرونه د اپلیکیشن راجستر کې ذخیره کوي. دا آپریټرونه د OpenShift کاري بار اکوسیستم او د شریک متمرکز عملیاتي ماډل (د دوهمې ورځې عملیات) اساس جوړوي.

هر OpenShift 4 کلستر د جوړ شوي OperatorHub څخه آپریټرونه کاروي ترڅو د نصب کولو لپاره موجود آپریټرانو لیست خپور کړي او هغه ته تازه معلومات چمتو کړي چې دمخه نصب شوي. د OpenShift 4 د ډیریدونکي شهرت سره، په ټوله نړۍ کې د کلسترونو شمیر هم ډیر شوی. د دې کلسترونو څخه هر یو د جوړ شوي OperatorHub چلولو لپاره د آپریټر مینځپانګه ډاونلوډ کوي ، د quay.io دننه د اپلیکیشن راجسټری د شالید په توګه کاروي. د ستونزې سرچینې لپاره زموږ په لټون کې، موږ دا حقیقت له لاسه ورکړ چې لکه څنګه چې OpenShift په تدریجي ډول په شهرت کې وده کوي، د quay.io په نادره کارول شویو فعالیتونو کې بار هم ډیر شوی..

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

د لاملونو له منځه وړل

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

د API غوښتنې چې دمخه یې نیم دقیقې وخت نیولی اوس په ملی ثانیو کې بشپړ شوي. راتلونکې اونۍ موږ په تولید کې بدلونونه ځای په ځای کړل، او له هغه وخت راهیسې quay.io په ثابت ډول کار کوي. د دې وخت په جریان کې ، د اپلیکیشن راجسټری پای پواینټ کې ترافیک کې ډیری تیز رفتارونه شتون درلود ، مګر پرمختګونو د ډیټابیس بندیدو مخه ونیوله.

موږ څه زده کړل؟

دا روښانه ده چې هر خدمت هڅه کوي د وخت څخه مخنیوی وکړي. زموږ په قضیه کې، موږ باور لرو چې وروستي بندښت د quay.io ښه کولو کې مرسته کړې. موږ یو څو مهم درسونه زده کړل چې موږ یې غواړو شریک کړو:

1. د دې په اړه معلومات چې څوک ستاسو خدمت کاروي او څنګه هیڅکله بې ځایه ندي. ځکه چې کوې "یوازې کار کړی،" موږ هیڅکله د ترافیک اصلاح کولو او بار اداره کولو لپاره وخت نه ورکوو. دې ټولو د امنیت غلط احساس رامینځته کړی چې خدمت کولی شي په غیر مستقیم ډول اندازه کړي.
2. کله چې خدمت کم شي، بیرته ترلاسه کول او چلول یو لوړ لومړیتوب دی.. ځکه چې Quay د لومړي بند په جریان کې د تړل شوي ډیټابیس څخه رنځ ته دوام ورکړ ، زموږ معیاري پروسیجرونو مطلوب تاثیر نه درلود او موږ نشو کولی د دوی په کارولو سره خدمت بیرته راوباسئ. دا د داسې وضعیت لامل شوی چیرې چې وخت باید د اصلي لامل موندلو په تمه د معلوماتو تحلیل او راټولولو کې مصرف شي - د دې پرځای چې د فعالیت بیا رغولو لپاره ټولې هڅې تمرکز وکړي.
3. د هر خدمت ځانګړتیا اغیزه ارزونه وکړئ. پیرودونکو په ندرت سره د اپلیکیشن راجسټری کارولې ، نو دا زموږ د ټیم لپاره لومړیتوب نه و. کله چې د محصول ځینې ځانګړتیاوې په سختۍ سره کارول کیږي، د دوی کیګونه په ندرت سره څرګندیږي، او پراختیا کونکي د کوډ څارنه بندوي. د دې غلط فهمۍ ښکار کیدل اسانه دي چې دا باید داسې وي - تر هغه چې ناڅاپه دا فعالیت د یوې لویې پیښې په مرکز کې ومومي.

څه راتلونکو؟

د خدماتو ثبات ډاډمن کولو لپاره کار هیڅکله نه دریږي او موږ په دوامداره توګه وده کوو. لکه څنګه چې د ټرافیک حجم په quay.io کې وده کوي، موږ پوهیږو چې موږ مسؤلیت لرو چې هر هغه څه وکړو چې موږ یې کولی شو د خپلو پیرودونکو باور ته وده ورکړو. له همدې امله، موږ اوس په لاندې کارونو کار کوو:

1. یوازې د لوستلو ډیټابیس نقلونه ځای په ځای کړئ ترڅو خدمت سره د RDS لومړني مثال سره د ستونزو په صورت کې مناسب ترافیک اداره کولو کې مرسته وکړي.
2. د RDS مثال تازه کول. اوسنی نسخه پخپله ستونزه نده. بلکه، موږ په ساده ډول غواړو هغه غلط لار لیرې کړو (کوم چې موږ د ناکامۍ پرمهال تعقیب کړی)؛ د سافټویر تازه ساتل به د راتلونکي بندیدو په حالت کې یو بل فاکتور له مینځه ویسي.
3. په ټول کلستر کې اضافي کیشینګ. موږ د ساحو لټون ته دوام ورکوو چیرې چې کیشینګ کولی شي په ډیټابیس کې بار کم کړي.
4. د ویب اپلیکیشن فایر وال (WAF) اضافه کول ترڅو وګوري چې څوک quay.io سره وصل دی او ولې.
5. د راتلونکي ریلیز سره پیل کول ، د ریډ هیټ اوپن شیف کلسترونه به په quay.io کې موجود کانټینر عکسونو پراساس د آپریټر کتلاګ په ګټه د اپلیکیشن راجسټری پریږدي.
6. د اپلیکیشن راجسټری لپاره اوږدمهاله بدیل ممکن د خلاص کانټینر نوښت (OCI) هنري ځانګړتیاو لپاره ملاتړ وي. دا اوس مهال د اصلي Quay فعالیت په توګه پلي کیږي او کاروونکو ته به شتون ولري کله چې مشخصات پخپله نهایی شي.

پورتني ټول په quay.io کې د Red Hat د روانې پانګونې برخه ده ځکه چې موږ د کوچني "Startup-style" ټیم څخه د SRE پرمخ وړونکي پلیټ فارم ته حرکت کوو. موږ پوهیږو چې زموږ ډیری پیرودونکي د دوی ورځني کار (د ریډ هټ په شمول) کې په quay.io تکیه کوي او موږ هڅه کوو د وروستي بندیدو او د ښه کولو لپاره روانو هڅو په اړه د امکان تر حده شفاف واوسو.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

• «د CoreOS کانټینر عکسونو لپاره د ریډ هیټ خلاص سرچینه راجسټری کوډ - Quay»
• «زموږ د SRE ورځني ژوند څخه عملي کیسې. 2 برخه»
• «څنګه په کوبرنیټس کې د پوډ لومړیتوبونه د ګرافانا لابراتوارونو کې د ځنډ لامل شوي".

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