چگونه Badoo به توانایی ارائه 200 هزار عکس در ثانیه دست یافت

وب مدرن بدون محتوای رسانه ای تقریباً غیرقابل تصور است: تقریباً هر مادربزرگ یک تلفن هوشمند دارد، همه در شبکه های اجتماعی حضور دارند و توقف خدمات برای شرکت ها پرهزینه است. برای توجه شما، متنی از داستان شرکت Badoo در مورد اینکه او چگونه تحویل عکس ها را با استفاده از یک راه حل سخت افزاری سازماندهی کرد، با چه مشکلات عملکردی در این فرآیند مواجه شد، چه چیزی باعث آنها شد، و چگونه این مشکلات با استفاده از یک راه حل نرم افزاری مبتنی بر Nginx حل شد، در حالی که از تحمل خطا در همه سطوح اطمینان حاصل کرد (تصویری). ما از نویسندگان داستان اولگ تشکر می کنیم سانیس افیمووا و الکساندرا دیمووا که تجربیات خود را در کنفرانس به اشتراک گذاشتند آپتایم روز 4.

بیایید با یک مقدمه کوچک در مورد نحوه ذخیره و ذخیره عکس ها شروع کنیم. ما یک لایه داریم که در آن آنها را ذخیره می کنیم، و یک لایه که در آن عکس ها را ذخیره می کنیم. در عین حال، اگر می‌خواهیم به یک ترفند بزرگ دست یابیم و بار ذخیره‌سازی را کاهش دهیم، برای ما مهم است که هر عکس از یک کاربر جداگانه روی یک سرور ذخیره‌سازی قرار گیرد. در غیر این صورت، باید به تعداد سرورهای بیشتری دیسک نصب کنیم. نرخ ضربه ما حدود 99 درصد است یعنی 100 برابر بار ذخیره سازی خود را کاهش می دهیم و برای این کار 10 سال پیش که همه اینها ساخته می شد 50 سرور داشتیم. بر این اساس، برای دادن این عکس ها، در واقع به 50 دامنه خارجی که این سرورها سرویس می دهند، نیاز داشتیم.

طبیعتاً بلافاصله این سؤال مطرح شد: اگر یکی از سرورهای ما از کار بیفتد و در دسترس نباشد، چه بخشی از ترافیک را از دست می دهیم؟ ما به آنچه در بازار بود نگاه کردیم و تصمیم گرفتیم یک تکه آهن بخریم تا همه مشکلات ما حل شود. انتخاب بر روی راه حل شرکت شبکه F5 افتاد (که اتفاقاً نه چندان دور NGINX، Inc را خریداری کرد): مدیر ترافیک محلی BIG-IP.

کاری که این قطعه آهن (LTM) انجام می دهد: این یک روتر آهنی است که آهن را در پورت های خارجی خود اضافه می کند و به شما امکان می دهد ترافیک را بر اساس توپولوژی شبکه، در برخی تنظیمات مسیریابی کنید و بررسی های سلامت را انجام دهید. برای ما مهم بود که این قطعه آهن قابل برنامه ریزی باشد. بر این اساس، می‌توانیم منطق چگونگی بازگرداندن عکس‌های یک کاربر خاص از یک کش خاص را شرح دهیم. چه شکلی است؟ یک قطعه سخت افزاری وجود دارد که به اینترنت برای یک دامنه، یک ip نگاه می کند، ssl را بارگذاری می کند، درخواست های http را تجزیه می کند، یک شماره کش را از IRule انتخاب می کند، کجا باید برود، و اجازه می دهد ترافیک به آنجا برود. در عین حال بررسی های سلامت را انجام می دهد و در صورت در دسترس نبودن دستگاه، آن را طوری انجام دادیم که در آن زمان ترافیک به یک سرور پشتیبان می رفت. از نقطه نظر پیکربندی، البته، تفاوت های ظریف وجود دارد، اما به طور کلی همه چیز بسیار ساده است: ما یک نقشه را تجویز می کنیم، تعداد مشخصی با IP ما در شبکه مطابقت دارد، می گوییم که در پورت 80 گوش خواهیم داد. و 443، ما می گوییم که اگر سرور در دسترس نیست، باید اجازه دهید ترافیک به نسخه پشتیبان برود، در این مورد، 35th، و ما یک دسته منطق را توضیح می دهیم که چگونه این معماری باید جدا شود. تنها مشکل این بود که زبانی که قطعه آهن با آن برنامه ریزی شده است زبان Tcl است. اگر کسی اصلاً این را به خاطر می آورد ... این زبان بیشتر از یک زبان مناسب برای برنامه نویسی فقط نوشتن است:

چه چیزی به دست آوردیم؟ ما یک قطعه سخت افزاری دریافت کردیم که در دسترس بودن زیرساخت ما را تضمین می کند، تمام ترافیک ما را هدایت می کند، بررسی های بهداشتی را ارائه می دهد و فقط کار می کند. علاوه بر این، مدت زیادی است که کار می کند: در طول 10 سال گذشته، هیچ شکایتی در مورد آن وجود نداشته است. در ابتدای سال 2018، ما در حال رندر کردن 80 هزار عکس در ثانیه بودیم. این چیزی حدود 80 گیگابیت ترافیک از هر دو مرکز داده ما است.

با این حال…

در ابتدای سال 2018، شاهد یک تصویر زشت در نمودارها بودیم: زمان بازگشت عکس ها به وضوح افزایش یافته است. و دیگر مناسب ما نبود. مشکل این است که این رفتار فقط در اوج ترافیک قابل مشاهده بود - برای شرکت ما این شب از یکشنبه تا دوشنبه است. اما بقیه زمان‌ها سیستم طبق معمول رفتار کرد، هیچ نشانه‌ای از شکستگی وجود نداشت.

با این حال، مشکل باید حل می شد. ما گلوگاه های احتمالی را شناسایی کردیم و شروع به رفع آنها کردیم. البته اول از همه، لینک‌های آپلود خارجی را گسترش دادیم، یک بازنگری کامل در آپلینک‌های داخلی انجام دادیم و همه تنگناهای ممکن را پیدا کردیم. اما همه اینها نتیجه آشکاری به همراه نداشت، مشکل ناپدید نشد.

یکی دیگر از گلوگاه های احتمالی عملکرد خود حافظه پنهان عکس بود. و ما به این نتیجه رسیدیم که شاید مشکل به آنها بستگی دارد. خوب، ما عملکرد را گسترش داده ایم - اساساً پورت های شبکه در حافظه پنهان عکس. اما باز هم هیچ پیشرفت واضحی مشاهده نشد. در پایان، ما به عملکرد خود LTM توجه زیادی کردیم و در اینجا تصویر غم انگیزی را روی نمودارها دیدیم: بارگیری همه CPU ها به آرامی شروع می شود، اما سپس به شدت روی قفسه قرار می گیرد. در همان زمان، LTM پاسخ کافی به بررسی سلامت و لینک های بالا را متوقف می کند و شروع به خاموش کردن آنها به طور تصادفی می کند که منجر به کاهش جدی عملکرد می شود.

یعنی ما منبع مشکل را شناسایی کرده ایم، گلوگاه را شناسایی کرده ایم. باقی مانده است که تصمیم بگیریم چه کنیم.

اولین کاری که می‌توانیم انجام دهیم این است که به نوعی خود LTM را مدرن کنیم. اما در اینجا نکات ظریفی وجود دارد، زیرا این اتو کاملا منحصر به فرد است، شما به نزدیکترین سوپرمارکت نخواهید رفت و آن را خریداری نمی کنید. این یک قرارداد جداگانه است، یک قرارداد مجوز جداگانه، و زمان زیادی می برد. گزینه دوم این است که شروع به فکر کردن برای خود کنید، راه حل خود را در مورد اجزای خود، ترجیحاً با استفاده از یک برنامه منبع باز ارائه دهید. فقط باید تصمیم بگیریم که دقیقاً چه چیزی را برای این انتخاب خواهیم کرد و چقدر زمان برای حل این مشکل صرف خواهیم کرد، زیرا کاربران عکسی دریافت نکردند. بنابراین، لازم است همه اینها را خیلی خیلی سریع انجام دهیم، شاید بتوان گفت - دیروز.

از آنجایی که این کار به نظر می رسید "کاری را در اسرع وقت و با استفاده از سخت افزاری که در اختیار داریم انجام دهید"، اولین چیزی که فکر کردیم این بود که برخی از نه قدرتمندترین ماشین ها را از جلو حذف کنیم، Nginx را در آنجا قرار دهیم، که می دانیم چگونه کار کند، و سعی کنید همان منطقی را که قطعه آهن قبلا انجام می داد، پیاده کنید. یعنی در واقع ما سخت افزارمان را رها کردیم، 4 سرور دیگر را که باید پیکربندی می‌کردیم نصب کردیم، دامنه‌های خارجی را به قیاس 10 سال پیش برای آنها ساختیم... اگر این ماشین‌ها سقوط کنند، کمی در دسترس بودن را از دست دادیم. ، اما، با این وجود کمتر، مشکل کاربران ما را به صورت محلی حل کرد.

بر این اساس، منطق یکسان باقی می‌ماند: ما Nginx را نصب می‌کنیم، می‌تواند SSL-offload را انجام دهد، می‌توانیم به نوعی منطق مسیریابی، بررسی سلامت روی تنظیمات را برنامه‌ریزی کنیم و به سادگی منطقی را که قبلا داشتیم کپی کنیم.

می نشینیم تا تنظیمات را بنویسیم. در ابتدا به نظر می رسید که همه چیز بسیار ساده است، اما، متأسفانه، یافتن کتابچه راهنمای هر کار بسیار دشوار است. بنابراین، ما به شما توصیه نمی کنیم که به سادگی "نحوه پیکربندی Nginx برای عکس ها" را در گوگل جستجو کنید: بهتر است به اسناد رسمی مراجعه کنید، که نشان می دهد کدام تنظیمات را باید لمس کرد. اما بهتر است خودتان یک پارامتر خاص را انتخاب کنید. خوب، پس همه چیز ساده است: ما سرورهایی را که در اختیار داریم توصیف می کنیم، گواهینامه ها را توصیف می کنیم ... اما جالب ترین چیز در واقع، خود منطق مسیریابی است.

در ابتدا به نظرمان رسید که ما به سادگی موقعیت مکانی خود را توصیف می کنیم، شماره حافظه پنهان عکس خود را در آن مطابقت می دهیم، با دست خود یا ژنراتور توضیح می دهیم که به چه تعداد upstream نیاز داریم، در هر بالادست سروری را که ترافیک باید به آن منتقل شود را نشان می دهیم، و سرور پشتیبان - در صورتی که سرور اصلی در دسترس نباشد:

اما، احتمالا، اگر همه چیز به این سادگی بود، فقط به خانه می رفتیم و چیزی نمی گفتیم. متأسفانه، با تنظیمات پیش‌فرض Nginx، که به طور کلی، طی سال‌ها توسعه انجام شده‌اند و کاملاً برای این مورد نیستند ... پیکربندی به این صورت است: در صورتی که برخی از سرورهای بالادستی دارای خطای درخواست یا مهلت زمانی باشند، Nginx همیشه ترافیک را به بعدی تغییر می دهد. در همان زمان، پس از اولین شکست، سرور نیز در عرض 10 ثانیه خاموش می شود، هم به اشتباه و هم با وقفه زمانی - این حتی به هیچ وجه قابل پیکربندی نیست. یعنی اگر گزینه timeout را در دستورالعمل upstream حذف یا ریست کنیم، با وجود اینکه Nginx این درخواست را پردازش نمی کند و با خطای نه چندان خوبی پاسخ می دهد، سرور خاموش می شود.

برای جلوگیری از این، دو کار انجام دادیم:

الف) آنها Nginx را از انجام دستی این کار منع کردند - و متأسفانه، تنها راه برای انجام این کار این است که به سادگی تنظیمات حداکثر شکست را تنظیم کنید.

ب) به یاد آوردیم که در پروژه‌های دیگر از ماژولی استفاده می‌کنیم که به شما امکان می‌دهد بررسی‌های سلامت پس‌زمینه را انجام دهید - بر این اساس، ما بررسی‌های بهداشتی کاملاً مکرری انجام دادیم تا در صورت وقوع حادثه حداقل زمان از کار افتادگی را داشته باشیم.

متأسفانه، این هم تمام نیست، زیرا به معنای واقعی کلمه، دو هفته اول عملیات این طرح نشان داد که بررسی سلامت TCP نیز یک چیز غیرقابل اعتماد است: نه Nginx، یا Nginx در حالت D را نمی توان در سرور بالادستی راه اندازی کرد، و در در این صورت هسته اتصال را می پذیرد، بررسی سلامت عبور می کند، اما کار نمی کند. بنابراین، ما بلافاصله آن را با http's Health-check جایگزین کردیم، یک مورد خاص ساختیم، که اگر قبلاً 200 می دهد، همه چیز در این اسکریپت کار می کند. شما می توانید منطق اضافی انجام دهید - به عنوان مثال، در مورد سرورهای کش، بررسی کنید که سیستم فایل به درستی نصب شده است:

و این برای ما مناسب بود، با این تفاوت که در آن لحظه مدار کاملاً همان کاری را که قطعه آهن انجام داد تکرار کرد. اما ما می خواستیم بهتر عمل کنیم. قبلاً یک سرور پشتیبان داشتیم و این احتمالاً خیلی خوب نیست ، زیرا اگر صد سرور دارید ، وقتی چندین سرور به طور همزمان سقوط می کنند ، بعید است که یک سرور پشتیبان با بار مقابله کند. بنابراین، ما تصمیم گرفتیم که رزرو را بین همه سرورها توزیع کنیم: ما به سادگی یک بالادست جداگانه دیگر ایجاد کردیم، همه سرورها را با پارامترهای خاصی مطابق با باری که می توانند ارائه کنند، در آنجا ثبت کردیم، همان بررسی های سلامتی را که قبلا داشتیم اضافه کردیم:

از آنجایی که نمی‌توانید در داخل یک بالادست به بالادست دیگری بروید، باید مطمئن می‌شد که اگر بالادست اصلی، که در آن حافظه پنهان عکس صحیح و لازم را نوشته‌ایم، در دسترس نبود، به سادگی از طریق error_page به عقب‌نشینی رفتیم، از آنجا. به قسمت پشتیبان بالادستی رفتیم:

و به معنای واقعی کلمه با اضافه کردن چهار سرور، این را دریافت کردیم: بخشی از بار را جایگزین کردیم - از LTM به این سرورها برداشته شد، همان منطق را با استفاده از سخت افزار و نرم افزار استاندارد در آنجا پیاده سازی کردیم، بلافاصله پاداشی دریافت کردیم که این سرورها می توانند مقیاس شوند، زیرا می توانند مقیاس شوند. به سادگی به همان اندازه که نیاز دارید قرار دهید. خوب، تنها نکته منفی این است که ما دسترسی بالا را برای کاربران خارجی از دست داده ایم. اما در آن زمان مجبور شدم این را قربانی کنم، زیرا لازم بود بلافاصله مشکل را حل کنم. بنابراین، ما بخشی از بار را حذف کردیم، در آن زمان حدود 40٪ بود، LTM بهتر شد، و به معنای واقعی کلمه دو هفته پس از شروع مشکل، ما شروع به ارائه نه 45k درخواست در ثانیه، بلکه 55k کردیم. در واقع، ما 20٪ رشد کردیم - این به وضوح ترافیکی است که ما به کاربر ندادیم. و پس از آن، آنها شروع به فکر کردن در مورد چگونگی حل مشکل باقی مانده کردند - برای اطمینان از در دسترس بودن خارجی بالا.

ما کمی مکث داشتیم که در طی آن بحث کردیم که چه راه حلی برای این مورد استفاده کنیم. پیشنهادهایی برای اطمینان از قابلیت اطمینان با استفاده از DNS، با کمک برخی از اسکریپت های خودنویس، پروتکل های مسیریابی پویا ... گزینه های زیادی وجود داشت، اما قبلاً مشخص شده بود که برای بازگشت واقعاً قابل اعتماد عکس ها، باید لایه دیگری را معرفی کنید. که این را نظارت خواهد کرد. ما این ماشین ها را کارگردان عکس می نامیم. نرم افزاری که ما به آن تکیه کردیم Keepalived بود:

برای شروع، آنچه Keepalived از آن تشکیل شده است. اولین پروتکل VRRP است که به طور گسترده برای شبکه‌سازان شناخته شده است، که بر روی تجهیزات شبکه قرار دارد که تحمل خطا را برای آدرس IP خارجی که کلاینت‌ها به آن متصل می‌شوند، فراهم می‌کند. بخش دوم IPVS، سرور مجازی IP، برای ایجاد تعادل بین روترهای عکس و ارائه تحمل خطا در این سطح است. و سومین بررسی سلامت است.

بیایید با بخش اول شروع کنیم: VRRP - چگونه به نظر می رسد؟ یک IP مجازی خاص وجود دارد که یک ورودی در dns badoocdn.com دارد، جایی که کلاینت ها به آن متصل می شوند. در مقطعی از زمان، ما یک آدرس IP در یک سرور داریم. بسته های Keepalived بین سرورها با استفاده از پروتکل VRRP اجرا می شوند، و اگر Master از رادار ناپدید شود - سرور راه اندازی مجدد شده است یا چیز دیگری، سرور پشتیبان به طور خودکار این آدرس IP را افزایش می دهد - هیچ اقدام دستی لازم نیست. Master و Backup متفاوت هستند، عمدتاً اولویت: هر چه بالاتر باشد، احتمال اینکه ماشین به Master تبدیل شود بیشتر است. یک مزیت بسیار بزرگ این است که شما نیازی به پیکربندی آدرس های IP در خود سرور ندارید، کافی است آنها را در پیکربندی توضیح دهید، و اگر آدرس های IP به قوانین مسیریابی سفارشی نیاز دارند، این به طور مستقیم در پیکربندی توضیح داده شده است. همان نحوی که در بسته VRRP توضیح داده شده است. شما با چیزهای ناآشنا روبرو نخواهید شد.

در عمل چگونه به نظر می رسد؟ اگر یکی از سرورها خراب شود چه اتفاقی می افتد؟ به محض ناپدید شدن استاد، پشتیبان ما دریافت تبلیغات را متوقف می کند و به طور خودکار استاد می شود. پس از مدتی، ما Master را تعمیر کردیم، راه اندازی مجدد کردیم، Keepalived را افزایش دادیم - تبلیغات با اولویت بالاتر از نسخه پشتیبان می رسد و نسخه پشتیبان به طور خودکار برمی گردد، آدرس های IP را از خود حذف می کند، هیچ اقدام دستی لازم نیست.

بنابراین، ما از تحمل خطای آدرس IP خارجی اطمینان حاصل کرده ایم. بخش بعدی این است که به نوعی ترافیک را از یک آدرس IP خارجی به روترهای عکسی که قبلاً آن را خاتمه داده اند، متعادل کنید. با پروتکل های متعادل کننده، همه چیز به اندازه کافی روشن است. این یا یک دور روبین ساده است یا چیزهای کمی پیچیده تر، wrr، اتصال لیست و غیره. این اساساً در مستندات توضیح داده شده است، هیچ چیز خاصی در مورد آن وجود ندارد. اما روش تحویل ... در اینجا ما با جزئیات بیشتری صحبت خواهیم کرد - چرا یکی از آنها را انتخاب کردیم. اینها NAT، Direct Routing و TUN هستند. واقعیت این است که ما بلافاصله بازگشت 100 گیگابیت ترافیک از سایت ها را تعیین کردیم. اگر متوجه شوید، به کارت های 10 گیگابیتی نیاز دارید، درست است؟ 10 کارت گیگابیتی در یک سرور - این در حال حاضر فراتر از مفهوم "تجهیزات استاندارد" ما است. و سپس به یاد آوردیم که ما فقط مقداری ترافیک را تقدیم نمی‌کنیم، بلکه عکس‌ها را نیز تقدیم می‌کنیم.

ویژگی چیست؟ - تفاوت زیادی بین ترافیک ورودی و خروجی. ترافیک ورودی بسیار کم است، ترافیک خروجی بسیار زیاد است:

اگر به این نمودارها نگاه کنید، می بینید که در حال حاضر حدود 200 مگابایت در ثانیه برای کارگردان ارسال می شود، این معمولی ترین روز است. ما 4,500 مگابایت در ثانیه را پس می دهیم، نسبت آن حدود 1/22 است. از قبل مشخص شده است که برای اینکه بتوانیم ترافیک خروجی را به طور کامل به 22 سرور فعال ارائه کنیم، یکی کافی است که این اتصال را بپذیرد. در اینجا الگوریتم مسیریابی مستقیم، الگوریتم مسیریابی به کمک ما می آید.

چه شکلی است؟ مدیر عکس ما، طبق جدول خود، اتصالات را به روترهای عکس منتقل می کند. اما روترهای عکس، ترافیک معکوس را مستقیماً به اینترنت ارسال می کنند، آن را برای مشتری ارسال می کنند، از طریق مدیر عکس به عقب برنمی گردد، بنابراین، با حداقل تعداد ماشین، تحمل خطا و پمپاژ تمام ترافیک را فراهم می کنیم. در تنظیمات به این صورت است: الگوریتم را مشخص می‌کنیم، در مورد ما یک rr ساده است، روش مسیریابی مستقیم را ارائه می‌دهیم و سپس شروع به لیست کردن تمام سرورهای واقعی می‌کنیم که چند عدد از آنها داریم. که این ترافیک را تعیین می کند. در صورتی که یک یا دو سرور دیگر داشته باشیم، چندین سرور در آنجا ظاهر می شوند، چنین نیازی ایجاد می شود - ما به سادگی این بخش را به پیکربندی اضافه می کنیم و زیاد نگران نباشید. از طرف سرورهای واقعی، از سمت یک مسیریاب عکس، این روش به حداقل پیکربندی نیاز دارد، در مستندات کاملاً توضیح داده شده است و هیچ مشکلی در آن وجود ندارد.

آنچه به خصوص خوشایند است این است که چنین راه حلی به معنای تغییر اساسی در شبکه محلی نیست، این برای ما مهم بود، ما مجبور بودیم آن را با حداقل هزینه حل کنیم. اگر نگاه کنید خروجی فرمان مدیریت IPVSسپس خواهیم دید که چگونه به نظر می رسد. در اینجا ما یک سرور مجازی خاص داریم، روی پورت 443، گوش می دهد، یک اتصال را می پذیرد، همه سرورهای فعال لیست شده اند، و واضح است که اتصال، مثبت یا منفی، یکسان است. اگر به آمار روی همان سرور مجازی نگاه کنیم، بسته های ورودی داریم، اتصالات ورودی، اما مطلقاً هیچ خروجی نداریم. اتصالات خروجی مستقیماً به مشتری می رود. خوب، ما موفق شدیم تعادل را از بین ببریم. حال، اگر یکی از روترهای عکس ما از کار بیفتد، چه اتفاقی می افتد؟ بالاخره آهن آهن است. ممکن است دچار وحشت هسته شود، ممکن است بشکند، منبع تغذیه ممکن است بسوزد. هر چیزی. این همان چیزی است که بررسی های بهداشتی برای آن انجام می شود. آنها می توانند به سادگی بررسی نحوه باز بودن پورت با ما، یا برخی پیچیده تر، تا برخی از اسکریپت های خودنویس که حتی منطق تجاری را بررسی می کنند، باشند.

جایی در وسط توقف کردیم: ما یک درخواست https برای یک مکان خاص داریم، یک اسکریپت اگر با یک پاسخ 200 پاسخ دهد فراخوانی می شود، ما معتقدیم که همه چیز با این سرور خوب است، زنده است و به راحتی می توان آن را روشن کرد. .

چگونه این، دوباره، در عمل به نظر می رسد. سرور خاموش است، برای تعمیر و نگهداری مجاز است - به عنوان مثال، BIOS را فلش می کند. در لاگ ها، ما بلافاصله یک مهلت زمانی داریم، اولین خط را می بینیم، سپس پس از سه بار تلاش به عنوان "ناموفق" علامت گذاری می شود و به سادگی از لیست حذف می شود.

رفتار دوم نیز ممکن است، زمانی که VS به سادگی روی صفر تنظیم شده باشد، اما در مورد بازگرداندن یک عکس، این به خوبی کار نمی کند. سرور بالا می‌رود، Nginx در آنجا راه‌اندازی می‌شود، بلافاصله بررسی‌های سلامت متوجه می‌شوند که اتصال انجام می‌شود، همه چیز خوب است، و سرور در لیست ما ظاهر می‌شود و بار بلافاصله شروع به اعمال خودکار روی آن می‌کند. هیچ اقدام دستی از طرف مدیر وظیفه لازم نیست. در شب، سرور راه اندازی مجدد شد - بخش نظارت در شب در این مورد با ما تماس نمی گیرد. آنها به شما اطلاع دادند که چه اتفاقی افتاده است، همه چیز خوب است.

بنابراین، به روشی نسبتاً ساده، با کمک تعداد کمی از سرورها، مشکل تحمل خطای خارجی را حل کردیم.

باید گفت که همه اینها البته نیاز به نظارت دارند. به طور جداگانه، لازم به ذکر است که Keepalivede، به عنوان یک نرم افزار که مدت ها پیش نوشته شده است، راه های مختلفی برای نظارت بر آن دارد، هم با استفاده از چک از طریق DBus، SMTP، SNMP و Zabbix استاندارد. به علاوه، او خودش می‌داند که چگونه برای هر عطسه‌ای حروف بنویسد، و صادقانه بگویم، در مقطعی حتی فکر کردیم آن را خاموش کنیم، زیرا او برای هر سوئیچ ترافیک، شامل، برای هر IP-shnik و حروف زیادی می‌نویسد. به همین ترتیب . البته، اگر سرورهای زیادی وجود دارد، می توانید خود را با این حروف پر کنید. با استفاده از روش های استاندارد، nginx را روی روترهای عکس نظارت می کنیم و نظارت سخت افزاری از بین نرفته است. البته، ما دو چیز دیگر را توصیه می کنیم: اول، بررسی های سلامت خارجی و دسترسی، زیرا حتی اگر همه چیز کار کند، در واقع این امکان وجود دارد که کاربران به دلیل مشکلات ارائه دهندگان خارجی یا چیزی پیچیده تر، عکس دریافت نکنند. همیشه ارزش دارد که در یک شبکه دیگر، در آمازون یا جای دیگر، یک ماشین جداگانه نگه دارید که می تواند سرورهای شما را از بیرون پینگ کند، و همچنین ارزش استفاده از تشخیص ناهنجاری را دارد، برای کسانی که در یادگیری ماشینی پیچیده یا ساده مهارت دارند. نظارت، حداقل به منظور ردیابی اینکه آیا درخواست ها به شدت کاهش یافته اند یا برعکس، رشد کرده اند. همچنین مفید است.

به طور خلاصه: ما در واقع راه حل آهن را جایگزین کردیم، که در برخی مواقع دیگر مناسب ما نبود، با یک سیستم نسبتاً ساده که همه کارها را یکسان انجام می دهد، یعنی خاتمه ترافیک HTTPS و مسیریابی هوشمند بیشتر با سلامت لازم را فراهم می کند. -چک می کند ما پایداری این سیستم را افزایش داده‌ایم، یعنی هنوز برای هر لایه دسترسی بالایی داریم، به‌علاوه این امتیاز را گرفتیم که مقیاس کردن همه آن در هر لایه بسیار آسان است، زیرا این سخت‌افزار استاندارد با نرم‌افزار استاندارد است، یعنی ، با انجام این کار، تشخیص مشکلات احتمالی را ساده کرده ایم.

به چه نتیجه ای رسیدیم؟ ما در تعطیلات ژانویه 2018 مشکل داشتیم. در طول شش ماه اول، در حالی که ما این طرح را اجرا می‌کردیم و آن را به تمام ترافیک گسترش می‌دادیم، به منظور حذف تمام ترافیک از LTM، فقط ترافیک یک مرکز داده را از 40 گیگابیت به 60 گیگابیت افزایش دادیم و در عین حال. زمان برای کل سال 2018 قادر به ارائه تقریباً سه برابر بیشتر عکس در هر ثانیه بودند.

منبع: www.habr.com