وب مدرن عملاً بدون محتوای رسانهای غیرقابل تصور است: تقریباً هر مادربزرگی یک تلفن هوشمند دارد، همه در رسانههای اجتماعی هستند و از کارافتادگی برای شرکتها پرهزینه است. در اینجا خلاصهای از داستان این شرکت آمده است. در مورد اینکه چگونه تحویل عکسها را با استفاده از یک راهکار سختافزاری سازماندهی کرده، با چه مشکلات عملکردی در این فرآیند مواجه شده، چه چیزی باعث آنها شده و چگونه این مشکلات با استفاده از یک راهکار نرمافزاری مبتنی بر Nginx حل شدهاند، ضمن اینکه تحمل خطا در تمام سطوح تضمین شده است (). با تشکر از نویسندگان داستان اولگ افیمووا و الکساندرا دیمووا، که تجربیات خود را در کنفرانس به اشتراک گذاشتند .
بیایید با یک مقدمه کوتاه در مورد نحوه ذخیره و ذخیره عکسها شروع کنیم. ما یک لایه ذخیرهسازی و یک لایه ذخیرهسازی داریم. اگر میخواهیم به نرخ موفقیت بالا برسیم و بار روی ذخیرهسازی را کاهش دهیم، مهم است که عکس هر کاربر روی یک سرور ذخیرهسازی واحد ذخیره شود. در غیر این صورت، باید دیسکهایی معادل تعداد سرورهای موجود مستقر کنیم. نرخ موفقیت ما حدود ۹۹٪ است، به این معنی که بار روی ذخیرهسازی خود را با ضریب ۱۰۰ کاهش میدهیم. برای رسیدن به این هدف، ۱۰ سال پیش، زمانی که ما در حال ساخت کل این چیز بودیم، ۵۰ سرور داشتیم. در نتیجه، برای ارائه این عکسها، اساساً به ۵۰ دامنه خارجی نیاز داشتیم که توسط این سرورها ارائه شوند.
طبیعتاً بلافاصله این سوال پیش آمد: اگر یکی از سرورهای ما از کار بیفتد و از دسترس خارج شود، چه مقدار ترافیک از دست میدهیم؟ ما به آنچه در بازار موجود بود نگاه کردیم و تصمیم گرفتیم سختافزاری بخریم که تمام مشکلات ما را حل کند. ما یک راهحل از F5-network (که اتفاقاً اخیراً NGINX, Inc. را خریداری کرده است) انتخاب کردیم: BIG-IP Local Traffic Manager.
این سختافزار (LTM) چه کاری انجام میدهد؟ این یک روتر سختافزاری است که افزونگی سختافزاری را روی پورتهای خارجی خود انجام میدهد و ترافیک را بر اساس توپولوژی شبکه و تنظیمات خاص هدایت میکند و بررسیهای سلامت را انجام میدهد. برای ما مهم بود که این سختافزار قابل برنامهریزی باشد. بنابراین، میتوانستیم منطق پشت نحوه ارائه عکسها برای یک کاربر خاص از یک حافظه پنهان خاص را شرح دهیم. چه شکلی است؟ یک قطعه سختافزاری وجود دارد که از طریق یک دامنه واحد، یک آدرس IP واحد به اینترنت دسترسی پیدا میکند، تخلیه SSL را انجام میدهد، درخواستهای HTTP را تجزیه میکند، شماره حافظه پنهان را از IRule برای هدایت ترافیک انتخاب میکند و آن را به آنجا هدایت میکند. همچنین بررسیهای سلامت را انجام میدهد و اگر دستگاهی در دسترس نباشد، ما آن را طوری پیکربندی کردهایم که ترافیک را به یک سرور پشتیبان واحد هدایت کند. البته از نظر پیکربندی، تفاوتهای ظریفی وجود دارد، اما در کل، بسیار ساده است: ما یک نقشه تعریف میکنیم، یک شماره به آدرس IP خود در شبکه اختصاص میدهیم، مشخص میکنیم که روی پورتهای ۸۰ و ۴۴۳ گوش خواهیم داد، مشخص میکنیم که اگر سرور در دسترس نباشد، باید ترافیک را به سمت پشتیبان، در این مورد، پورت ۳۵، هدایت کنیم و مجموعهای از منطقها را برای چگونگی تجزیه این معماری شرح میدهیم. تنها مشکل این بود که سختافزار با Tcl برنامهنویسی شده بود. اگر کسی حتی آن را به خاطر بیاورد... این بیشتر یک زبان فقط نوشتنی است تا یک زبان برنامهنویسی:
چه چیزی به دست آوردیم؟ ما سختافزاری داریم که دسترسیپذیری بالای زیرساختهای ما را تضمین میکند، تمام ترافیک ما را مسیریابی میکند، بررسیهای سلامت را ارائه میدهد و به سادگی کار میکند. و مدت زیادی است که کار میکند: در 10 سال گذشته هیچ مشکلی با آن وجود نداشته است. تا ابتدای سال 2018، ما حدود 80،000 عکس در ثانیه ارائه میدادیم. این تقریباً 80 گیگابایت ترافیک از هر دو مرکز داده ما است.
با این حال…
در آغاز سال ۲۰۱۸، شاهد نکتهای ناخوشایند در نمودارهای خود بودیم: زمان تحویل عکسها به وضوح افزایش یافته بود. و ما دیگر از این موضوع راضی نبودیم. مشکل این بود که این رفتار فقط در ساعات اوج ترافیک - برای شرکت ما، یعنی از یکشنبه شب تا دوشنبه - قابل توجه بود. اما در بقیه اوقات، سیستم طبق معمول رفتار میکرد و هیچ نشانهای از خرابی وجود نداشت.
با این وجود، مشکل باید حل میشد. ما گلوگاههای بالقوه را شناسایی و شروع به حذف آنها کردیم. البته اول و مهمتر از همه، ما لینکهای خارجی را گسترش دادیم، یک ممیزی کامل از لینکهای داخلی انجام دادیم و تمام گلوگاههای احتمالی را شناسایی کردیم. اما هیچ یک از این اقدامات نتیجه مشخصی نداشت؛ مشکل همچنان ادامه داشت.
یکی دیگر از تنگناهای احتمالی، عملکرد خود حافظههای نهان عکس بود. ما تصمیم گرفتیم که شاید مشکل در آنجا باشد. بنابراین، عملکرد را گسترش دادیم - در درجه اول پورتهای شبکه روی حافظههای نهان عکس. اما باز هم، هیچ بهبود واضحی ندیدیم. در نهایت، به عملکرد خود LTM توجه دقیقی کردیم و تصویر ناامیدکنندهای را در نمودارها دیدیم: استفاده از CPU به طور روان شروع شد، اما ناگهان به حالت ثابت رسید. در همان زمان، LTM دیگر به اندازه کافی به بررسیهای سلامت آپلینک پاسخ نداد و شروع به غیرفعال کردن تصادفی آنها کرد که منجر به تخریب جدی عملکرد شد.
خب، ما منبع مشکل و گلوگاه را شناسایی کردهایم. حالا تنها چیزی که باقی مانده این است که تصمیم بگیریم چه کاری انجام دهیم.
اولین و بدیهیترین کاری که میتوانستیم انجام دهیم، مدرنسازی خود LTM بود. اما این کار ظرافتهایی هم دارد، چون این سختافزار کاملاً منحصر به فرد است؛ نمیتوانید فقط به نزدیکترین سوپرمارکت بروید و آن را بخرید. این یک قرارداد جداگانه، یک توافقنامه مجوز جداگانه است و زمان زیادی میبرد. گزینه دوم این است که مستقل فکر کنیم و با استفاده از اجزای خودمان، ترجیحاً با استفاده از نرمافزار متنباز، راهحل خودمان را توسعه دهیم. تنها چیزی که باقی میماند این است که تصمیم بگیریم دقیقاً چه چیزی را برای این انتخاب کنیم و چقدر زمان برای حل این مشکل صرف کنیم، زیرا کاربران عکسهای کافی دریافت نمیکردند. بنابراین، همه این کارها باید خیلی خیلی سریع، عملاً دیروز انجام شود.
از آنجایی که هدف «انجام کاری در سریعترین زمان ممکن با استفاده از سختافزاری که داشتیم» بود، اولین فکر ما این بود که به سادگی چند ماشین کمقدرتتر را از بخش جلویی حذف کنیم، Nginx را که با آن راحت هستیم نصب کنیم و سعی کنیم همان منطقی را که سختافزار قبلاً مدیریت میکرد، پیادهسازی کنیم. بنابراین، اساساً، سختافزار خود را نگه داشتیم، چهار سرور دیگر نصب کردیم که باید پیکربندی میشدند و دامنههای خارجی برای آنها ایجاد کردیم، مشابه کاری که 10 سال پیش انجام داده بودیم... اگر این ماشینها از کار میافتادند، کمی از دسترسپذیری آنها کاسته میشد، اما با این وجود مشکل کاربران خود را به صورت محلی حل میکردیم.
بر این اساس، منطق کار یکسان باقی میماند: ما Nginx را نصب میکنیم، میتواند SSL Offloading را انجام دهد، میتوانیم به نحوی منطق مسیریابی، بررسیهای سلامت در پیکربندیها را برنامهریزی کنیم و به سادگی منطقی را که قبلاً داشتیم، کپی کنیم.
بیایید شروع به نوشتن فایلهای پیکربندی کنیم. در ابتدا، به نظر ساده میرسید، اما متأسفانه، پیدا کردن راهنما برای هر کار بسیار دشوار است. بنابراین، ما صرفاً جستجو در گوگل با عنوان "نحوه پیکربندی Nginx برای عکسها" را توصیه نمیکنیم: بهتر است به مستندات رسمی مراجعه کنید، که به شما نشان میدهد کدام تنظیمات را باید تغییر دهید. با این حال، بهتر است پارامترهای خاص را خودتان انتخاب کنید. پس از آن، همه چیز ساده است: ما سرورهایی را که داریم شرح میدهیم، گواهینامهها را شرح میدهیم... اما جالبترین بخش، در واقع، خود منطق مسیریابی است.
در ابتدا، فکر کردیم که به سادگی موقعیت مکانی خود را توصیف کنیم، شماره حافظه پنهان عکس خود را به صورت دستی یا با یک مولد با آن مطابقت دهیم، تعداد upstream های مورد نیاز خود را شرح دهیم و در هر upstream، سروری را که ترافیک باید به آن برود و همچنین یک سرور پشتیبان را در صورت عدم دسترسی سرور اصلی مشخص کنیم:
اما شاید اگر همه چیز به همین سادگی بود، به سادگی به خانه میرفتیم و چیزی نمیگفتیم. متأسفانه، با تنظیمات پیشفرض Nginx، که در واقع طی سالها توسعه تغییر یافتهاند و دقیقاً برای این مورد استفاده مناسب نیستند... پیکربندی به این شکل است: اگر یک سرور بالادستی با خطای درخواست یا timeout مواجه شود، Nginx همیشه ترافیک را به سرور بعدی تغییر میدهد. علاوه بر این، پس از اولین خرابی، سرور نیز ظرف 10 ثانیه، هم به دلیل خطا و هم به دلیل timeout، خاموش میشود - این حتی قابل تنظیم نیست. بنابراین، اگر گزینه timeout را در دستورالعمل بالادستی حذف یا تنظیم مجدد کنیم، حتی اگر Nginx درخواست را پردازش نکند و با نوعی خطای ناخوشایند پاسخ دهد، سرور همچنان خاموش خواهد شد.
برای جلوگیری از این اتفاق، دو کار انجام دادیم:
الف) Nginx از انجام دستی این کار منع شده بود - و متأسفانه، تنها راه انجام این کار، تنظیم سادهی حداکثر تعداد دفعات خطا است.
ب) ما به یاد داشتیم که در پروژههای دیگر از ماژولی استفاده میکنیم که به ما امکان انجام بررسیهای سلامت پسزمینه را میدهد. بر این اساس، بررسیهای سلامت را نسبتاً مکرر انجام دادیم تا در صورت بروز حادثه، زمان از کار افتادگی به حداقل برسد.
متأسفانه، این تمام ماجرا نیست، زیرا دو هفته اول این راهاندازی نشان داد که بررسی سلامت TCP نیز غیرقابل اعتماد است: ممکن است سرور بالادستی Nginx را اجرا نکند، یا Nginx ممکن است در حالت D اجرا شود، که در این صورت هسته اتصال را میپذیرد، بررسی سلامت با موفقیت انجام میشود، اما کار نخواهد کرد. بنابراین ما بلافاصله آن را با یک بررسی سلامت HTTP جایگزین کردیم و یک بررسی خاص ایجاد کردیم که اگر عدد ۲۰۰ را برگرداند، همه چیز در این اسکریپت کار میکند. منطق اضافی را میتوان پیادهسازی کرد - به عنوان مثال، در مورد سرورهای ذخیرهسازی، بررسی اینکه سیستم فایل به درستی نصب شده است:
ما از این موضوع راضی بودیم، به جز اینکه تنظیمات فعلی کاملاً همان کاری را که سختافزار انجام میداد، تکرار میکرد. اما میخواستیم بهتر عمل کنیم. قبلاً، ما یک سرور پشتیبان داشتیم و این احتمالاً ایدهآل نیست، زیرا اگر صد سرور داشته باشید، اگر چندین سرور به طور همزمان از کار بیفتند، بعید است که یک سرور پشتیبان بتواند بار را تحمل کند. بنابراین تصمیم گرفتیم افزونگی را بین همه سرورها توزیع کنیم: ما به سادگی یک سرور بالادستی جداگانه دیگر ایجاد کردیم، همه سرورها را با پارامترهای خاص بر اساس ظرفیت بارشان به آن اضافه کردیم و همان بررسیهای سلامتی را که قبلاً داشتیم اضافه کردیم:
از آنجایی که دسترسی به یک جریان بالادستی دیگر در داخل یک جریان بالادستی غیرممکن است، باید آن را طوری تنظیم میکردیم که اگر جریان بالادستی اصلی، که برای نوشتن حافظه پنهان عکس صحیح و لازم استفاده میشد، در دسترس نبود، به سادگی از error_page برای دسترسی به جریان پشتیبان استفاده کنیم، جایی که به جریان بالادستی پشتیبان دسترسی پیدا میکردیم:
و با اضافه کردن چهار سرور، به این نتیجه رسیدیم: بخشی از بار را جایگزین کردیم - آن را از LTM به این سرورها منتقل کردیم. ما همین منطق را با استفاده از سختافزار و نرمافزار استاندارد در آنجا پیادهسازی کردیم. ما بلافاصله امتیاز مقیاسپذیری را به دست آوردیم زیرا میتوانستیم به سادگی هر تعداد که نیاز بود را مستقر کنیم. تنها نکته منفی این بود که دسترسی بالا را برای کاربران خارجی از دست دادیم. اما در آن زمان، مجبور شدیم از این امتیاز صرف نظر کنیم زیرا باید مشکل را فوراً حل میکردیم. بنابراین، بخشی از بار را - حدود ۴۰٪ در آن زمان - تخلیه کردیم. LTM بهبود یافت و به معنای واقعی کلمه دو هفته پس از شروع مشکل، ما ۵۵۰۰۰ درخواست در ثانیه را ارائه میدادیم، که از ۴۵۰۰۰ درخواست بیشتر بود. اساساً، ما ۲۰٪ رشد کردیم - این واضح است که ما به ترافیک کمتری خدمات ارائه میدادیم. و پس از آن، شروع به فکر کردن در مورد چگونگی حل مشکل باقی مانده کردیم - تضمین دسترسی خارجی بالا.
ما مکث کوتاهی کردیم و در مورد راهحلی که استفاده میکردیم بحث کردیم. پیشنهادهایی برای اطمینان از قابلیت اطمینان با استفاده از DNS، اسکریپتهای سفارشی، پروتکلهای مسیریابی پویا وجود داشت... گزینههای زیادی وجود داشت، اما مشخص شد که برای تحویل عکس واقعاً قابل اعتماد، باید لایه دیگری برای مدیریت آن معرفی کنیم. ما این دستگاهها را مدیران عکس نامیدیم. ما Keepalived را به عنوان نرمافزاری که به آن تکیه کردیم انتخاب کردیم:
بیایید با اجزای تشکیلدهندهی Keepalived شروع کنیم. اول، پروتکل VRRP که برای متخصصان شبکه بسیار شناخته شده است، روی تجهیزات شبکه قرار دارد و تحمل خطا را برای آدرس IP خارجی که کلاینتها به آن متصل میشوند، فراهم میکند. جزء دوم IPVS، یک سرور مجازی IP، برای متعادلسازی بار بین روترهای نوری و تضمین تحمل خطا در این سطح است. و سوم، بررسیهای سلامت.
بیایید با بخش اول شروع کنیم: VRRP - چه شکلی است؟ یک آدرس IP مجازی با ورودی DNS در badoocdn.com وجود دارد که کلاینتها به آن متصل میشوند. در برههای از زمان، این آدرس IP در یک سرور واحد وجود دارد. بستههای Keepalive با استفاده از پروتکل VRRP بین سرورها ارسال میشوند و اگر سرور اصلی از دید ناپدید شود (به دلیل راهاندازی مجدد یا چیز دیگری)، سرور پشتیبان به طور خودکار این آدرس IP را نمایش میدهد - بدون نیاز به مداخله دستی. تفاوت بین سرورهای اصلی و پشتیبان در درجه اول در اولویت است: هرچه اولویت بالاتر باشد، احتمال اینکه دستگاه به سرور اصلی تبدیل شود بیشتر است. یک مزیت بسیار بزرگ این است که نیازی به پیکربندی آدرسهای IP روی خود سرور ندارید. آنها را میتوان به سادگی در فایل پیکربندی تعریف کرد. اگر این آدرسهای IP به قوانین مسیریابی سفارشی نیاز داشته باشند، مستقیماً در فایل پیکربندی، با استفاده از همان سینتکس موجود در بسته VRRP، تعریف میشوند. با هیچ ویژگی ناآشنایی روبرو نخواهید شد.
این روش در عمل چگونه کار میکند؟ اگر یکی از سرورها از کار بیفتد چه اتفاقی میافتد؟ به محض اینکه سرور اصلی از کار بیفتد، سرور پشتیبان ما دریافت تبلیغات را متوقف میکند و به طور خودکار به سرور اصلی تبدیل میشود. پس از مدتی، سرور اصلی را تعمیر میکنیم، آن را دوباره راهاندازی میکنیم و Keepalived را فعال میکنیم - تبلیغات با اولویت بالاتری نسبت به سرورهای پشتیبان میرسند و سرور پشتیبان به طور خودکار برمیگردد و آدرسهای IP خود را حذف میکند - هیچ اقدام دستی لازم نیست.
بنابراین، ما تحمل خطای آدرس IP خارجی را تضمین کردهایم. گام بعدی این است که به نحوی ترافیک را از آدرس IP خارجی به روترهای عکس متعادل کنیم، که سپس آن را خاتمه میدهند. پروتکلهای متعادلسازی کاملاً واضح هستند. یا یک round-robin ساده است یا چیزهای کمی پیچیدهتر مانند wrr، list connection و غیره. این به طور کلی در مستندات توضیح داده شده است؛ چیز خاصی در مورد آن وجود ندارد. در مورد روش تحویل... بیایید نگاه دقیقتری به این بیندازیم که چرا یکی از آنها را انتخاب کردیم. اینها NAT، Direct Routing و TUN هستند. مسئله این است که ما در ابتدا قصد داشتیم 100 گیگابیت ترافیک را از سایتها تحویل دهیم. این بدان معناست که به 10 کارت گیگابیت نیاز دارید، درست است؟ ده کارت گیگابیت در یک سرور واحد - این فراتر از چیزی است که ما "تجهیزات استاندارد" میدانیم. و سپس به یاد آوردیم که ما فقط ترافیک را تحویل نمیدهیم؛ ما عکسها را تحویل میدهیم.
چه چیزی در مورد آن خاص است؟ — تفاوت زیادی بین ترافیک ورودی و خروجی وجود دارد. ترافیک ورودی بسیار کم است، در حالی که ترافیک خروجی بسیار زیاد است:
با نگاهی به این نمودارها، میتوانید ببینید که مدیر در حال حاضر حدود ۲۰۰ مگابایت در ثانیه دریافت میکند؛ این یک روز معمولی است. ما ۴۵۰۰ مگابایت در ثانیه ارسال میکنیم، نسبتی تقریباً ۱/۲۲. واضح است که برای پشتیبانی کامل از ترافیک خروجی به ۲۲ سرور کارگر، فقط به یک سرور نیاز داریم که این اتصال را بپذیرد. اینجاست که الگوریتم مسیریابی مستقیم وارد عمل میشود.
چه شکلی است؟ Photo Director ما اتصالات را طبق جدول خودش به Photo Routerهای ما هدایت میکند. با این حال، Photo Routerها ترافیک برگشتی را مستقیماً به اینترنت، به کلاینت، ارسال میکنند؛ از Photo Director عبور نمیکند. به این ترتیب، با حداقل تعداد ماشینها، تحمل خطای کامل و جریان ترافیک کامل را تضمین میکنیم. در فایلهای پیکربندی، به این شکل است: ما الگوریتم را مشخص میکنیم - در مورد ما، یک RR ساده - مسیریابی مستقیم را فعال میکنیم و سپس شروع به فهرست کردن تمام سرورهای واقعی که داریم میکنیم که این ترافیک را تعیین میکنند. اگر یک یا دو سرور دیگر اضافه کنیم، یا اگر نیاز پیش بیاید، به سادگی این بخش را به فایل پیکربندی اضافه میکنیم و زیاد نگران آن نیستیم. این روش به پیکربندی بسیار کمی در سمت سرورهای واقعی و همچنین در سمت Photo Router نیاز دارد. به خوبی مستند شده است و هیچ مشکلی وجود ندارد.
نکتهی جالب این است که این راهحل نیازی به بازسازی کامل شبکهی محلی ندارد، که این برای ما مهم بود؛ ما باید این مشکل را با حداقل هزینه حل میکردیم. اگر به ... نگاه کنید خواهیم دید که چگونه به نظر میرسد. در اینجا ما یک سرور مجازی داریم که به پورت ۴۴۳ گوش میدهد، اتصالات را میپذیرد، تمام سرورهای فعال را فهرست میکند و میبینیم که اتصال کم و بیش یکسان است. اگر به آمار روی همان سرور مجازی نگاه کنیم، بستههای ورودی، اتصالات ورودی را میبینیم، اما مطلقاً هیچ خروجی وجود ندارد. اتصالات خروجی مستقیماً به کلاینت میروند. بسیار خب، ما موفق شدهایم آن را نامتعادل کنیم. حالا، اگر یکی از روترهای عکس ما از کار بیفتد چه اتفاقی میافتد؟ سختافزار، سختافزار است، بالاخره. میتواند دچار اختلال هسته شود، میتواند خراب شود، منبع تغذیه میتواند بسوزد. هر چیزی. بررسیهای سلامت برای همین هستند. آنها میتوانند به سادگی بررسی باز بودن یک پورت یا پیچیدهتر، از جمله اسکریپتهای سفارشی باشند که حتی منطق کسب و کار را بررسی میکنند.
ما در جایی بینابین به توافق رسیدهایم: یک درخواست HTTPS به یک مکان خاص داریم، یک اسکریپت فراخوانی میشود و اگر با پاسخ ۲۰۰ پاسخ دهد، فرض میکنیم که سرور مشکلی ندارد، فعال است و میتوانیم با خیال راحت آن را روشن کنیم.
در عمل، این به این شکل است. فرض کنید یک سرور برای تعمیر و نگهداری خاموش میشود - مثلاً برای بهروزرسانی BIOS. بلافاصله یک timeout در گزارشها ظاهر میشود. ما خط اول را میبینیم. سپس، پس از سه بار تلاش، به عنوان "failed" علامتگذاری میشود و سرور به سادگی از لیست حذف میشود.
یک سناریوی ممکن دیگر، تنظیم سادهی VS روی صفر است، اما این روش هنگام ارائه عکسها خوب کار نمیکند. سرور بالا میآید، Nginx شروع به کار میکند، بررسیهای سلامت بلافاصله تشخیص میدهند که اتصال موفقیتآمیز است، همه چیز خوب است و سرور در لیست ما ظاهر میشود و بارگذاری به طور خودکار روی آن اعمال میشود. هیچ اقدام دستی از سوی مدیر در حال انجام وظیفه لازم نیست. سرور یک شبه مجدداً راهاندازی میشود - بخش نظارت در مورد آن با ما تماس نمیگیرد. آنها به ما اطلاع میدهند که این اتفاق افتاده است و همه چیز خوب است.
بنابراین، به روشی نسبتاً ساده، با استفاده از تعداد کمی سرور، مشکل تحمل خطای خارجی را حل کردیم.
شایان ذکر است که البته همه اینها نیاز به نظارت دارند. شایان ذکر است که Keepalivede، به عنوان یک نرمافزار بسیار قدیمی، روشهای زیادی برای نظارت بر آن دارد، از جمله از طریق بررسیهای DBus، SMTP و SNMP و همچنین Zabbix استاندارد. به علاوه، میتواند تقریباً برای هر چیز کوچکی ایمیل ارسال کند و صادقانه بگویم، در یک مقطع حتی غیرفعال کردن آن را در نظر گرفتیم زیرا برای هر سوئیچ ترافیک، هر راهاندازی، هر آدرس IP و غیره ایمیلهای زیادی ارسال میکند. البته، اگر سرورهای زیادی دارید، ممکن است با این ایمیلها مواجه شوید. ما Nginx را روی روترهای عکس با استفاده از روشهای استاندارد نظارت میکنیم و نظارت سختافزاری هنوز وجود دارد. البته ما دو چیز دیگر را توصیه میکنیم: اول، بررسیهای سلامت دسترسی خارجی، زیرا حتی اگر همه چیز کار کند، ممکن است کاربران به دلیل مشکلات با ارائه دهندگان خارجی یا چیزی پیچیدهتر، عکسها را دریافت نکنند. همیشه ارزش دارد که یک دستگاه جداگانه در شبکه دیگری مانند آمازون یا جای دیگری داشته باشید که بتواند سرورهای شما را از خارج پینگ کند. همچنین استفاده از تشخیص ناهنجاری، برای کسانی که در یادگیری ماشینی پیشرفته مهارت دارند، یا نظارت ساده، حداقل برای ردیابی کاهش یا افزایش شدید درخواستها، ارزشمند است. این نیز میتواند مفید باشد.
خلاصه اینکه: ما اساساً راهکار سختافزاری را که در برههای دیگر ما را راضی نمیکرد، با یک سیستم نسبتاً ساده جایگزین کردیم که همان کار را انجام میدهد، یعنی خاتمه ترافیک HTTPS و مسیریابی هوشمند بعدی را با بررسیهای لازم برای سلامت فراهم میکند. ما پایداری این سیستم را افزایش دادهایم، به این معنی که در هر لایه، دسترسیپذیری بالایی را حفظ میکنیم. به علاوه، به عنوان یک امتیاز، سهولت مقیاسپذیری در هر لایه را به دست آوردهایم زیرا این یک سختافزار استاندارد با نرمافزار استاندارد است، به این معنی که عیبیابی خود را ساده کردهایم.
در نهایت چه شد؟ ما در تعطیلات ژانویه ۲۰۱۸ با مشکلی مواجه شدیم. در طول شش ماه اول، در حالی که ما در حال پیادهسازی این سیستم و گسترش آن برای پوشش تمام ترافیک برای تخلیه تمام ترافیک از LTM بودیم، ترافیک را در یک مرکز داده از ۴۰ گیگابیت به ۶۰ گیگابیت افزایش دادیم و در عین حال، در کل سال ۲۰۱۸، توانستیم تقریباً سه برابر بیشتر عکس در ثانیه تحویل دهیم.
منبع: www.habr.com
