عصري ویب د میډیا مینځپانګې پرته تقریبا د تصور وړ نه ده: نږدې هره انا یو سمارټ فون لري، هرڅوک په ټولنیزو شبکو کې دي، او د ساتنې وخت د شرکتونو لپاره ګران دی. دلته د شرکت کیسه یو نقل دی د دې په اړه چې څنګه هغې د هارډویر حل په کارولو سره د عکسونو تحویل تنظیم کړ ، د فعالیت کومې ستونزې یې په پروسه کې ورسره مخ شوې ، د دوی لامل څه و ، او دا ستونزې څنګه د نګینکس پراساس د سافټویر حل په کارولو سره حل شوې ، پداسې حال کې چې په ټولو کچو کې د غلطۍ زغم ډاډمن کول (). موږ د اولیګ د کیسې لیکوالانو څخه مننه کوو ایفیمووا او الکساندرا ډیمووا، چې په کنفرانس کې یې خپلې تجربې شریکې کړې .
- راځئ چې د عکسونو ذخیره کولو او زیرمه کولو څرنګوالي په اړه د یوې کوچنۍ پیژندنې سره پیل وکړو. موږ یو پرت لرو چیرې چې موږ یې ذخیره کوو، او یو پرت چیرې چې موږ عکسونه ذخیره کوو. په ورته وخت کې ، که موږ غواړو د لوړ چال نرخ ترلاسه کړو او د ذخیره کولو بار کم کړو ، نو دا زموږ لپاره مهم دی چې د انفرادي کارونکي هر عکس په یو کیچنګ سرور کې وي. که نه نو، موږ باید څو ځله ډیر ډیسکونه نصب کړو څومره چې موږ ډیر سرورونه لرو. زموږ د چلولو کچه شاوخوا 99٪ ده، دا دی، موږ د خپل ذخیره کولو بار 100 ځله کموو، او د دې کولو لپاره، 10 کاله وړاندې، کله چې دا ټول جوړ شوي وو، موږ 50 سرورونه درلودل. په دې اساس، د دې عکسونو خدمت کولو لپاره، موږ په اصل کې 50 بهرني ډومینونو ته اړتیا لرو چې دا سرورونه خدمت کوي.
په طبیعي ډول، پوښتنه سمدلاسه راپورته شوه: که زموږ یو سرور ښکته شي او شتون ونلري ، نو د ترافیک کومه برخه له لاسه ورکوو؟ موږ په بازار کې څه وګورو او پریکړه مو وکړه چې د هارډویر یوه ټوټه واخلو ترڅو دا زموږ ټولې ستونزې حل کړي. انتخاب د F5-شبکې شرکت حل باندې راوتلی (کوم چې په دې وروستیو کې NGINX، Inc اخیستی): د BIG-IP سیمه ایز ترافیک مدیر.
د هارډویر دا ټوټه (LTM) څه کوي: دا د اوسپنې روټر دی چې د خپل بهرني بندرونو اوسپنې بې ځایه کیدو رامینځته کوي او تاسو ته اجازه درکوي د شبکې ټوپولوژي پراساس ، په ځینو ترتیباتو کې ، او روغتیایی معاینات ترسره کړئ. دا زموږ لپاره مهمه وه چې د هارډویر دا ټوټه برنامه شي. په دې اساس، موږ کولی شو دا منطق تشریح کړو چې څنګه د یو ځانګړي کاروونکي عکسونه د ځانګړي زیرمې څخه خدمت شوي. دا څه ډول ښکاري؟ د هارډویر یوه ټوټه شتون لري چې انټرنیټ ته په یو ډومین کې ګوري، یو IP، د ایس ایس ایل آفلوډ کوي، د HTTP غوښتنې پارس کوي، د IRule څخه د کیچ شمیره غوره کوي، چیرته چې لاړ شي، او ټرافیک ته اجازه ورکوي چې هلته لاړ شي. په ورته وخت کې ، دا روغتیایی معاینات کوي ، او د یو څه ماشین شتون په صورت کې ، په هغه وخت کې موږ دا رامینځته کړی ترڅو ترافیک یو بیک اپ سرور ته لاړ شي. د ترتیب کولو له نظره، البته، ځینې لنډیزونه شتون لري، مګر په عموم کې هرڅه خورا ساده دي: موږ یو کارت راجستر کوو، په شبکه کې زموږ IP ته د یوې ټاکلې شمیرې لیکنې، موږ وایو چې موږ به په 80 بندرونو کې واورئ. او 443، موږ وایو چې که سرور شتون ونلري، نو تاسو اړتیا لرئ چې بیک اپ ته ټرافيک واستوئ، پدې حالت کې 35، او موږ د منطق یوه ډله تشریح کوو چې دا جوړښت باید څنګه جلا شي. یوازینۍ ستونزه دا وه چې په هغه ژبه کې چې هارډویر پروګرام شوی و Tcl وه. که څوک دا په یاد ولري ... دا ژبه یوازې د لیکلو لپاره د پروګرام کولو لپاره مناسبه ژبه ده:
موږ څه ترلاسه کړل؟ موږ د هارډویر یوه ټوټه ترلاسه کړه چې زموږ د زیربنا لوړه شتون تضمینوي، زموږ ټول ټرافیک ته لاره هواروي، روغتیا ګټې چمتو کوي او یوازې کار کوي. سربیره پردې، دا د اوږدې مودې لپاره کار کوي: په تیرو 10 کلونو کې د دې په اړه هیڅ شکایت شتون نلري. د 2018 په پیل کې ، موږ دمخه په هره ثانیه کې شاوخوا 80k عکسونه لیږو. دا زموږ د دواړو ډیټا مرکزونو څخه شاوخوا 80 ګیګابایټ ترافیک دی.
خو…
د 2018 په پیل کې ، موږ په چارټونو کې یو بد عکس ولید: هغه وخت چې د عکسونو لیږلو کې یې په څرګنده توګه زیاتوالی موندلی و. او دا زموږ سره مناسب ودرول. ستونزه دا ده چې دا چلند یوازې د ټرافیک په جریان کې لیدل کیده - زموږ د شرکت لپاره دا د یکشنبې څخه تر دوشنبې پورې شپه ده. مګر پاتې وخت سیسټم د معمول په څیر چلند وکړ، د ناکامۍ هیڅ نښه نشته.
په هرصورت، ستونزه باید حل شي. موږ ممکنه خنډونه په ګوته کړل او له منځه یوړل شو. تر ټولو لومړی، البته، موږ بهرني اپلنکونه پراخ کړل، د داخلي اپلنکونو بشپړه پلټنه مو ترسره کړه، او ټول ممکنه خنډونه مو وموندل. مګر دا ټول روښانه پایله نه ورکوي، ستونزه له منځه نه ځي.
بل احتمالي خنډ پخپله د عکس کیچونو فعالیت و. او موږ پریکړه وکړه چې شاید ستونزه د دوی سره وي. ښه، موږ فعالیت پراخ کړ - په عمده توګه د عکس کیچونو کې د شبکې بندرونه. خو بیا هم کوم څرګند پرمختګ نه دی لیدل شوی. په نهایت کې ، موږ پخپله د LTM فعالیت ته ډیر پام وکړ ، او دلته موږ په ګرافونو کې یو غمجن عکس ولید: په ټولو CPUs کې بار په اسانۍ سره پرمخ ځي ، مګر بیا ناڅاپه یو پوړ ته راځي. په ورته وخت کې، LTM روغتیایی چکونو او اپلنکونو ته په کافي ډول ځواب ویل بندوي او په تصادفي ډول یې بندول پیلوي، کوم چې د فعالیت جدي تخریب لامل کیږي.
دا، موږ د ستونزې سرچینه پیژندلې، خنډ یې پیژندلی. دا پاتې ده چې پریکړه وکړو چې موږ به څه وکړو.
لومړی، خورا څرګند شی چې موږ یې کولی شو په یو ډول د LTM ځان عصري کول دي. مګر دلته ځینې لنډیزونه شتون لري، ځکه چې دا هارډویر خورا ځانګړی دی، تاسو به نږدې سوپر مارکیټ ته لاړ نه شئ او هغه یې واخلئ. دا یو جلا قرارداد دی، جلا جواز قرارداد، او دا به ډیر وخت ونیسي. دوهم اختیار دا دی چې د خپل ځان لپاره فکر پیل کړئ ، د خپلو اجزاوو په کارولو سره خپل حل سره راشئ ، په غوره توګه د خلاص لاسرسي برنامې په کارولو سره. ټول هغه څه چې پاتې دي دا پریکړه کول دي چې موږ به د دې لپاره څه غوره کړو او د دې ستونزې په حل کولو کې به څومره وخت ولګوو، ځکه چې کاروونکو کافي عکسونه نه دي ترلاسه کړي. له همدې امله، موږ باید دا ټول په خورا چټکۍ سره ترسره کړو، یو ممکن پرون وویل شي.
له هغه ځایه چې دا کار داسې ښکاري چې "د امکان تر حده یو څه وکړئ او د هغه هارډویر په کارولو سره چې موږ یې لرو،" لومړی شی چې موږ فکر کاوه په ساده ډول د مخ څخه ځینې خورا پیاوړي ماشینونه لرې کول وو، هلته نینګکس ځای په ځای کړئ، چې موږ یې پوهیږو چې څنګه. کار وکړئ او هڅه وکړئ ټول ورته منطق پلي کړئ چې هارډویر یې کاوه. دا، په حقیقت کې، موږ خپل هارډویر پریښود، 4 نور سرورونه مو نصب کړل چې موږ یې ترتیب کول، د دوی لپاره بهرني ډومینونه جوړ کړل، لکه څنګه چې 10 کاله وړاندې وو ... که چیرې دا ماشینونه راټیټ شي، موږ یو څه شتون له لاسه ورکړو، مګر بیا هم لږ، دوی په محلي توګه زموږ د کاروونکو ستونزه حل کړه.
په دې اساس، منطق ورته پاتې دی: موږ نګینکس نصب کوو، دا کولی شي SSL-offload ترسره کړي، موږ کولی شو په یو ډول د روټینګ منطق پروګرام کړو، په ترتیبونو کې د روغتیا چکونه او په ساده ډول هغه منطق نقل کړو چې مخکې مو درلود.
راځئ چې د تشکیلاتو لیکلو لپاره ناست شو. په لومړي سر کې داسې بریښي چې هرڅه خورا ساده وو، مګر، له بده مرغه، د هر کار لپاره لارښود موندل خورا ستونزمن دي. له همدې امله ، موږ په ساده ډول د ګوګل کولو وړاندیز نه کوو "د عکسونو لپاره نګینکس څنګه تنظیم کړئ": دا غوره ده چې رسمي اسنادو ته مراجعه وکړئ ، کوم چې به وښیې چې کوم تنظیمات باید لمس شي. مګر دا غوره ده چې خپل ځان ځانګړی پیرامیټر غوره کړئ. ښه، بیا هرڅه ساده دي: موږ هغه سرورونه تشریح کوو چې موږ یې لرو، موږ سندونه تشریح کوو ... مګر ترټولو په زړه پورې شی، په حقیقت کې، پخپله د روټینګ منطق دی.
په لومړي سر کې موږ ته داسې بریښي چې موږ په ساده ډول خپل موقعیت تشریح کوو ، په دې کې زموږ د عکس کیچ شمیر سره سمون خوري ، زموږ د لاسونو یا جنراتور په کارولو سره دا تشریح کوو چې موږ څومره پورته جریانونو ته اړتیا لرو ، په هر اپ سټریم کې موږ هغه سرور په ګوته کوو چې ترافیک باید ورته وي. لاړ شئ، او یو بیک اپ سرور - که اصلي سرور شتون نلري:
مګر، شاید، که هرڅه خورا ساده وي، موږ به په ساده ډول کور ته لاړ شو او هیڅ به یې ونه ویل. بدبختانه ، د ډیفالټ نګینکس تنظیماتو سره ، کوم چې په عموم کې د ډیری کلونو پراختیا په اوږدو کې رامینځته شوي او د دې قضیې لپاره په بشپړ ډول مناسب ندي ... تشکیل داسې ښکاري: که چیرې ځینې اپ سټریم سرور د غوښتنې خطا یا وخت پای ولري ، نګینکس تل بل ته ترافیک بدلوي. سربیره پردې ، د لومړۍ ناکامۍ وروسته ، په 10 ثانیو کې به سرور هم بند شي ، دواړه په غلطۍ او د وخت پای ته رسیدو سره - دا حتی په هیڅ ډول تنظیم کیدی نشي. دا دی ، که موږ د اپ سټریم لارښود کې د وخت پای اختیار لرې یا تنظیم کړو ، نو که څه هم نګینکس به دا غوښتنه پروسس نکړي او د ځینې خورا ښه غلطۍ سره به ځواب ووایی ، سرور به وتړل شي.
د دې څخه د مخنیوي لپاره، موږ دوه شیان ترسره کړل:
a) دوی نګینکس په لاسي ډول د دې کولو څخه منع کړي - او له بده مرغه ، د دې کولو یوازینۍ لار په ساده ډول د اعظمي ناکامیو ترتیبات تنظیم کول دي.
b) موږ په یاد ولرو چې په نورو پروژو کې موږ یو ماډل کاروو چې موږ ته اجازه راکوي د شالید روغتیا معاینات ترسره کړو - په دې اساس، موږ په مکرر ډول روغتیایی معاینات ترسره کړل ترڅو د حادثې په صورت کې د ځنډ وخت لږ وي.
له بده مرغه، دا ټول هم نه دي، ځکه چې په حقیقت کې د دې سکیم د عملیاتو په لومړیو دوو اونیو کې وښودله چې د TCP روغتیا معاینه هم د اعتبار وړ نه ده: په اپ سټریم سرور کې دا ممکن نګینکس نه وي، یا نګینکس په D-State کې، او په دې حالت کې دانه به پیوستون ومني، د روغتیا معاینه به تیریږي، مګر کار نه کوي. له همدې امله، موږ سمدلاسه دا د روغتیا چیک http سره بدله کړه، یو ځانګړی جوړ کړ، کوم چې که دا 200 بیرته راولي، نو هرڅه په دې سکریپټ کې کار کوي. تاسو کولی شئ اضافي منطق ترسره کړئ - د مثال په توګه، د کیچ کولو سرورونو په حالت کې، وګورئ چې د فایل سیسټم په سمه توګه نصب شوی:
او دا به موږ ته مناسب وي، پرته له دې چې په اوس وخت کې سرکټ په بشپړه توګه هغه څه تکرار کړي چې هارډویر یې کړي. مګر موږ غوښتل چې ښه کار وکړو. دمخه ، موږ یو بیک اپ سرور درلود ، او دا شاید خورا ښه نه وي ، ځکه چې که تاسو سل سرورونه ولرئ ، نو کله چې په یوځل کې ډیری ناکام شي ، نو یو بیک اپ سرور امکان نلري چې د بار سره مقابله وکړي. له همدې امله، موږ پریکړه وکړه چې په ټولو سرورونو کې ریزرویشن توزیع کړو: موږ په ساده ډول یو بل جلا اپ سټریم جوړ کړ، ټول سرورونه یې د ځینې پیرامیټونو سره د هغه بار سره سم لیکلي چې دوی یې خدمت کولی شي، ورته روغتیایی معاینات اضافه کړل چې مخکې مو درلودل:
ځکه چې دا ناشونې ده چې په یو اپ سټریم کې بل اپ سټریم ته لاړشئ ، نو دا اړینه وه چې ډاډ ترلاسه کړو چې که اصلي اپ سټریم ، چې موږ په ساده ډول سم ، اړین عکس زیرمه ثبت کړی و ، شتون نلري ، نو موږ په ساده ډول د error_page څخه د بیرته راستنیدو لپاره لاړو. چیرې چې موږ بیک اپ اپ سټریم ته لاړو:
او په لفظي ډول د څلورو سرورونو په اضافه کولو سره ، دا هغه څه دي چې موږ ترلاسه کړل: موږ د بار یوه برخه بدله کړه - موږ دا له LTM څخه دې سرورونو ته لرې کړه ، ورته منطق یې هلته پلي کړ ، د معیاري هارډویر او سافټویر په کارولو سره ، او سمدلاسه بونس ترلاسه کړ چې دا سرورونه کولی شي. اندازه شي، ځکه چې دوی کولی شي په ساده ډول د اړتیا سره سم عرضه شي. ښه، یوازینی منفي دا دی چې موږ د بهرنیو کاروونکو لپاره لوړ شتون له لاسه ورکړ. خو په هغه وخت کې موږ باید دا قرباني ورکړو، ځکه چې دا اړینه وه چې ستونزه ژر تر ژره حل شي. نو، موږ د بار یوه برخه لرې کړه، دا په هغه وخت کې شاوخوا 40٪ وه، LTM ښه احساس وکړ، او په حقیقت کې د ستونزې له پیل څخه دوه اونۍ وروسته، موږ په هر ثانیه کې د 45k غوښتنې نه لیږل پیل کړل، مګر 55k. په حقیقت کې، موږ د 20٪ لخوا وده کړې - دا په واضح ډول هغه ټرافیک دی چې موږ کاروونکي ته نه دی ورکړی. او له هغې وروسته دوی د پاتې ستونزې د حل کولو په اړه فکر کولو پیل وکړ - د لوړ بهرني لاسرسي ډاډ ترلاسه کولو لپاره.
موږ یو څه وقفه درلوده، چې په ترڅ کې مو بحث وکړ چې د دې لپاره به کوم حل وکاروو. د DNS په کارولو سره د اعتبار یقیني کولو لپاره وړاندیزونه شتون درلود، د کور ځینې لیکل شوي سکریپټونو کارول، متحرک روټینګ پروتوکولونه ... ډیری اختیارونه شتون درلود، مګر دا لا دمخه څرګنده شوه چې د ریښتیا د باور وړ عکسونو رسولو لپاره، تاسو اړتیا لرئ یو بل پرت معرفي کړئ چې دا څارنه وکړي. . موږ دې ماشینونو ته د عکس رییسان ویل. هغه سافټویر چې موږ پرې تکیه کړې وه Keepalived:
د پیل کولو لپاره، Keepalived څه شی لري؟ لومړی د VRRP پروتوکول دی چې په پراخه کچه د شبکې کاروونکو ته پیژندل کیږي، د شبکې تجهیزاتو کې موقعیت لري چې بهرني IP پتې ته د غلطۍ زغم چمتو کوي کوم چې پیرودونکي ورسره نښلوي. دویمه برخه IPVS، IP مجازی سرور دی، د عکس روټرونو ترمنځ توازن او پدې کچه د غلطۍ زغم ډاډمن کولو لپاره. او دریم - روغتیایی معاینات.
راځئ چې د لومړۍ برخې سره پیل وکړو: VRRP - دا څه ښکاري؟ دلته یو ځانګړی مجازی IP شتون لري، کوم چې په dns badoocdn.com کې ننوتنه لري، چیرته چې پیرودونکي وصل کیږي. په ځینو وختونو کې، موږ په یو سرور کې IP پته لرو. ساتل شوي کڅوړې د VRRP پروتوکول په کارولو سره د سرورونو ترمینځ چلیږي ، او که ماسټر له رادار څخه ورک شي - سرور ریبوټ شوی یا بل څه ، نو د بیک اپ سرور په اوتومات ډول دا IP پته غوره کوي - هیڅ لاسي عمل ته اړتیا نشته. د ماسټر او بیک اپ ترمینځ توپیر په عمده ډول لومړیتوب دی: څومره چې دا لوړ وي ، هومره لوی چانس چې ماشین به ماسټر شي. یوه خورا لویه ګټه دا ده چې تاسو اړتیا نلرئ پخپله سرور کې IP پتې تنظیم کړئ ، دا کافي دي چې دوی په ترتیب کې تشریح کړئ ، او که چیرې IP پتې ځینې دودیز روټینګ قواعدو ته اړتیا ولري ، دا په مستقیم ډول په ترتیب کې تشریح کیږي ، په کارولو سره. ورته ترکیب لکه څنګه چې په VRRP کڅوړه کې بیان شوی. تاسو به د کوم ناپېژندل شوي شیانو سره مخ نه شئ.
دا په عمل کې څه ښکاري؟ څه پیښیږي که چیرې یو سرور ناکام شي؟ هرڅومره ژر چې ماسټر ورک شي ، زموږ بیک اپ د اعلاناتو ترلاسه کول بندوي او په اوتومات ډول ماسټر کیږي. د یو څه وخت وروسته ، موږ ماسټر ترمیم کړ ، ریبوټ شو ، Keepalived پورته شو - اعلانونه د بیک اپ په پرتله د لوړ لومړیتوب سره راځي ، او بیک اپ په اوتومات ډول بیرته راګرځي ، IP پتې لرې کوي ، هیڅ لاسي عمل ته اړتیا نلري.
په دې توګه، موږ د بهرني IP پتې د غلطۍ زغم ډاډمن کړی دی. بله برخه دا ده چې په یو ډول د بهرني IP پتې څخه د عکس روټرونو ته ترافیک توازن کړئ چې دمخه یې پای ته رسیدلی. د توازن پروتوکولونو سره هرڅه خورا روښانه دي. دا یا یو ساده راؤنډ رابین دی، یا یو څه ډیر پیچلي شیان، wrr، لیست پیوستون او داسې نور. دا اساسا په اسنادو کې تشریح شوی، هیڅ ځانګړی ندی. مګر د تحویلي میتود ... دلته به موږ له نږدې وګورو چې ولې موږ له دوی څخه یو غوره کړ. دا NAT، مستقیم روټینګ او TUN دي. حقیقت دا دی چې موږ سمدلاسه پلان درلود چې له سایټونو څخه 100 ګیګابایټ ټرافیک وړاندې کړو. که تاسو اټکل کوئ، تاسو 10 ګیګابایټ کارتونو ته اړتیا لرئ، سمه ده؟ په یو سرور کې د 10 ګیګابایټ کارتونه دمخه د "معیاري تجهیزاتو" زموږ د مفهوم له دائرې څخه بهر دي. او بیا موږ په یاد ولرو چې موږ یوازې یو څه ترافیک نه ورکوو ، موږ عکسونه ورکوو.
څه ځانګړی دی؟ - د راتلوونکي او وتلو ټرافیک ترمنځ لوی توپیر. راتلونکی ټرافیک خورا کوچنی دی، د وتلو ټرافیک خورا لوی دی:
که تاسو دې ګرافونو ته وګورئ، تاسو لیدلی شئ چې دا مهال مدیر په هره ثانیه کې شاوخوا 200 MB ترلاسه کوي، دا خورا عادي ورځ ده. موږ په هره ثانیه کې 4,500 MB بیرته ورکوو، زموږ تناسب نږدې 1/22 دی. دا لا دمخه روښانه ده چې د 22 کارګر سرورونو ته په بشپړ ډول د وتلو ترافیک چمتو کولو لپاره ، موږ یوازې یو ته اړتیا لرو چې دا اړیکه ومني. دا هغه ځای دی چې مستقیم روټینګ الګوریتم زموږ مرستې ته راځي.
دا څه ډول ښکاري؟ زموږ د عکس رییس، د هغه میز سره سم، د عکس روټرونو ته ارتباط لیږدوي. مګر د عکس روټرونه بیرته راستنیدونکي ترافیک مستقیم انټرنیټ ته لیږي ، پیرودونکي ته یې لیږي ، دا د عکس رییس له لارې بیرته نه ځي ، پدې توګه ، د لږترلږه ماشینونو سره ، موږ د بشپړ غلطی زغم او د ټولو ترافیک پمپ کول تضمین کوو. په تشکیلاتو کې دا داسې ښکاري: موږ الګوریتم مشخص کوو، زموږ په قضیه کې دا یو ساده rr دی، د مستقیم روټینګ طریقه چمتو کړئ او بیا د ټولو اصلي سرورونو لیست پیل کړئ، چې څومره یې لرو. چې دا ټرافیک به مشخص کړي. که موږ هلته یو یا دوه نور سرورونه ولرو، یا څو سرورونه، ورته اړتیا رامنځته کیږي - موږ یوازې دا برخه په ترتیب کې اضافه کوو او ډیره اندیښنه مه کوئ. د ریښتیني سرورونو له اړخ څخه ، د عکس روټر له اړخ څخه ، دا میتود خورا لږ تنظیم کولو ته اړتیا لري ، دا په بشپړ ډول په اسنادو کې بیان شوی ، او هلته هیڅ زیان شتون نلري.
هغه څه چې په ځانګړې توګه ښه دي دا دي چې دا ډول حل د محلي شبکې بنسټیز بیا ډیزاین معنی نه لري؛ دا زموږ لپاره مهم و؛ موږ باید دا د لږ لګښت سره حل کړو. که تاسو وګورئ ، بیا به موږ وګورو چې دا څنګه ښکاري. دلته موږ یو ځانګړی مجازی سرور لرو، په 443 پورټ کې، اوري، پیوستون مني، ټول کاري سرورونه لیست شوي، او تاسو لیدلی شئ چې پیوستون ورته دی، ورکړئ یا یې واخلئ. که موږ په ورته مجازی سرور کې احصایې وګورو، موږ راتلونکی پاکټونه لرو، راتلونکی اړیکې لرو، مګر په بشپړه توګه هیڅ بهر ته نه. وتلې اړیکې مستقیم پیرودونکي ته ځي. ښه، موږ وکولی شو دا غیر متوازن کړو. اوس، څه پیښیږي که زموږ د عکس روټرونو څخه یو ناکام شي؟ په هرصورت، اوسپنه اوسپنه ده. دا کیدای شي د کرنل ډار ته لاړ شي، دا مات کیدی شي، د بریښنا رسول ممکن سوځیدلی وي. هر څه. له همدې امله روغتیایی معایناتو ته اړتیا ده. دوی کولی شي دومره ساده وي لکه څنګه چې وګوري چې بندر څنګه خلاص دی، یا یو څه ډیر پیچلي، د کور لخوا لیکل شوي سکریپټونو پورې چې حتی د سوداګرۍ منطق هم وګوري.
موږ په مینځ کې یو ځای ودریږو: موږ یو ځانګړي ځای ته د https غوښتنه لرو، سکریپټ ویل کیږي، که دا د 200 ځواب سره ځواب ووایي، موږ باور لرو چې هرڅه د دې سرور سره سم دي، دا ژوندی دی او په کافي اندازه فعال کیدی شي. په اسانۍ سره
دا بیا په عمل کې څنګه ښکاري؟ راځئ چې د ساتنې لپاره سرور بند کړو - د مثال په توګه د BIOS فلش کول. په لاګونو کې، موږ سمدلاسه مهال ویش لرو، موږ لومړی کرښه ګورو، بیا د دریو هڅو وروسته دا د "ناکام" په توګه نښه شوی، او دا په ساده ډول له لیست څخه لیرې شوی.
د دویم چلند اختیار هم ممکن دی، کله چې VS په ساده ډول صفر ته ټاکل شوی وي، مګر که عکس بیرته راشي، دا ښه کار نه کوي. سرور راپورته کیږي ، نګینکس هلته پیل کیږي ، د روغتیا معاینه سمدلاسه پوهیږي چې پیوستون کار کوي ، چې هرڅه سم دي ، او سرور زموږ په لیست کې څرګندیږي ، او بار سمدلاسه پدې باندې پلي کیدو پیل کوي. د وظیفې مدیر څخه هیڅ لارښود عمل ته اړتیا نشته. سرور په شپه کې ریبوټ شو - د څارنې څانګه موږ ته د شپې په دې اړه تلیفون نه کوي. دوی تاسو ته خبر ورکوي چې دا پیښ شوي، هرڅه سم دي.
نو، په ساده ډول، د لږ شمیر سرورونو په مرسته، موږ د بهرني غلطی زغم ستونزه حل کړه.
ټول هغه څه چې باید وویل شي دا دي چې دا ټول باید وڅیړل شي. په جلا توګه، دا باید په پام کې ونیول شي چې Keepalivede، لکه څنګه چې ډیر وخت دمخه لیکل شوی سافټویر، د دې د څارنې لپاره یو لړ لارې لري، دواړه د DBus، SMTP، SNMP، او معیاري زیبکس له لارې د چکونو په کارولو سره. برسېره پردې، هغه پخپله پوهیږي چې څنګه د نږدې هرې پرنجي لپاره لیکونه ولیکئ، او ریښتیا ووایئ، په ځینو وختونو کې موږ حتی د هغې د بندولو فکر کاوه، ځکه چې هغه د هر ډول ټرافیک بدلولو، سویچ کولو، د هر IP اتصال لپاره ډیری لیکونه لیکي، او همداسی پسی . البته ، که چیرې ډیری سرورونه شتون ولري ، نو تاسو کولی شئ د دې لیکونو سره ځان غلبه کړئ. موږ د معیاري میتودونو په کارولو سره د عکس روټرونو کې نګینکس څارنه کوو ، او د هارډویر څارنه لا نه ده تللې. البته، موږ به دوه نور شیانو ته مشوره ورکړو: لومړی، بهرنۍ روغتیا معاینه او شتون، ځکه چې حتی که هرڅه کار وکړي، په حقیقت کې، شاید کاروونکي د بهرنیو چمتو کونکو سره د ستونزو یا یو څه پیچلي شیانو له امله عکسونه ترلاسه نکړي. دا تل په بل شبکه کې د ساتلو ارزښت لري، په ایمیزون یا بل کوم ځای کې، یو جلا ماشین چې کولی شي ستاسو سرورونه له بهر څخه پینګ کړي، او دا د هغو کسانو لپاره چې پوهیږي د پیچلي ماشین زده کړې، یا ساده نظارت کولو څرنګوالی، د بې نظمۍ کشف کولو کارولو ارزښت لري. ، لږترلږه د دې لپاره چې تعقیب شي که غوښتنې په چټکۍ سره راټیټ شوي، یا، په برعکس، زیات شوي. دا هم ګټور کیدی شي.
راځئ چې لنډیز وکړو: موږ په حقیقت کې د اوسپنې پوښل شوي محلول ځای په ځای کړ، کوم چې په یو وخت کې زموږ سره مناسب پاتې شو، د کافي ساده سیسټم سره چې هر څه ورته کوي، دا د HTTPS ټرافيک پای ته رسولو او نور سمارټ روټینګ چمتو کوي. اړین روغتیایی معاینات. موږ د دې سیسټم ثبات ډیر کړی دی، دا دی، موږ لاهم د هر پرت لپاره لوړ شتون لرو، او موږ بونس لرو چې دا په هر پرت کې اندازه کول خورا اسانه دي، ځکه چې دا د معیاري سافټویر سره معیاري هارډویر دی، دا دی. ، موږ د ممکنه ستونزو تشخیص ساده کړی دی.
په پای کې مو څه وکړل؟ موږ د 2018 د جنوري په رخصتیو کې ستونزه درلوده. په لومړیو شپږو میاشتو کې پداسې حال کې چې موږ دا سکیم په کار واچوو، موږ دا ټول ټرافیک ته پراخ کړل ترڅو ټول ټرافیک له LTM څخه لیرې کړو، موږ یوازې په یوه ډیټا مرکز کې ټرافيک له 40 ګیګابایټ څخه 60 ګیګابایټ ته وده ورکړه، او په ورته وخت کې. په ټول 2018 کال کې توانیدلي چې په یوه ثانیه کې نږدې درې چنده ډیر عکسونه واستوي.
سرچینه: www.habr.com