هفته‌ی گذشته صابر مسگری مدیر محصول تیم CDN آروان‌کلاد با مقاله‌ی Advancements in CDN Load Balancing :The Journey from DNS to Modern Solutions در نشست CAPIF 3 کشور قرقیزستان حضور پیدا کرد. مقاله‌ی ارایه‌شده‌ی مسگری به موضوع چالش‌های مرتبط با DNS و توزیع بار در شبکهی توزیع محتوا متمرکز بود. او هم‌چنین راهکارهای پیشنهادی برای مدیریت ترافیک بار در CDN را با توجه به تجربه‌های آروان‌کلاد بررسی کرد. در ادامه بخشی از مهم‌ترین مواردی که در این ارایه مطرح شد، آمده است:
توزیع بار (Load Balancing): از زمان پیدایش اینترنت، مساله‌ی توزیع بار یکی از اصلی‌ترین دغدغه‌های سرویس‌های تحت وب بوده است. یعنی مهم است که مدیریت ترافیکِ درحال افزایش و دسترس‌پذیری به بالاترین سطح سرویس‌ها به‌راحتی انجام شود. این نیازهای دایمی یکی از مهم‌ترین مواردی است که توسعه‌دهندگان CDN را مقابل پرسشی دایمی برای بهبود خدمات‌شان قرار می‌دهد.
تصویر بالا مدل مدیریت سیستم توزیع بار است.
توزیع بار و شبکهی توزیع محتوا
شبکه‌های توزیع محتوا، به‌دلیل ساختار توزیع‌شده و گسترده‌‌شان به‌عنوان یک زیرساخت مناسب برای ارایه‌ی سرویس توزیع بار همواره درخور توجه بوده‌اند. این شبکه به‌دلیل در اختیار داشتن نقاط حضور (POP) در منطقه‌های جغرافیایی مختلف دنیا، امکان دریافت ترافیک از نزدیک‌ترین ناحیه‌ی جغرافیایی نسبت به خودش را دارد و با این توانایی از تجمیع ترافیک در یک یا چند نقطه‌ی جغرافیایی جلوگیری می‌کند.
شبکهی توزیع محتوا می‌تواند از راه سرویس توزیع بار، ترافیک دریافتی خود را در هر نقطه (PoP) مدیریت کند. این مدیریت به دو شکل انجام می‌شود؛ اول: بخشی از ترافیک که خودِ شبکهی توزیع محتوا امکان پاسخگویی آن را دارد (محتوای ذخیره‌شده) و آن را از همان نقطه به کاربر تحویل می‌دهد. دوم: درخواست‌هایی که لازم است به سمت سرورهای اصلی وب‌سایت/سرویس ارسال شود.
توزیع بار به کمک DNS و مشکلات آن
در ابتدا شبکه‌های توزیع محتوا از DNS به‌عنوان یک راهکار برای توزیع بار ترافیک ورودی به پاپ‌سایت‌ها استفاده می‌کنند. به این شکل که در زمان پاسخگویی به درخواست‌های DNS کاربر، IP نزدیک‌ترین پاپ‌سایت، به محل جغرافیایی کاربر برگردانده می‌شود و درخواست‌های HTTP کاربر به آن پاپ‌سایت هدایت می‌شود و به این شکل می‌تواند ترافیک را میان پاپ‌سایت‌های مختلف در نقاط مختلف جهان توزیع کنند.
اما این روش محدودیت‌های متعددی داشته:
– به دلیل cache شدن پاسخ‌های DNS و وجود TTL، امکان کنترل دقیقی روی میزان ترافیک ورودی به هر پاپ‌سایت وجود نداشت و هم‌چنین اگر نیاز به خارج شدن از مدارِ یک پاپ‌سایت باشد، با فرآیند زمان‌بری برای دریافت پاسخ از DNS روبه‌رو خواهیم شد.
– به‌دلیل استفاده‌ی کاربران از سرویس‌های DNS عمومی، مانند: 9.9.9.9 , 1.1.1.1 به جای ارسال درخواست مستقیم به سرویس‌های DNS Authoritative، امکان تشخیص موقعیت جغرافیایی واقعی کاربر بسیار محدود است. زیرا سرویس Authoritative به‌جای مشاهده‌ی موقعیت جغرافیایی واقعی، موقعیت DNS عمومی را به‌عنوان درخواست‌دهنده شناسایی می‌کند. حتا با وجود توسعه‌ی EDNS، این استاندارد به‌شکل کامل تایید توسعه‌دهندگان شبکه را ندارد. همه‌ی این علت‌ها باعث شد که نیاز به مکانیزم دیگری برای توزیع بار ورودی به شبکهی توزیع محتوا احساس شود.
استفاده از BGP Anycast
به‌کمک این روش، تمامی نقاط شبکهی توزیع محتوا به‌کمک BGP Advertisement یک IP Range ثابت و یک‌سان خواهند داشت و هنگامی‌که درخواستی از سمت کاربر به این IP ارسال می‌شود، این درخواست به‌شکل خودکار از سوی نزدیک‌ترین نقطه‌ی CDN دریافت خواهد شد. این راهکار مسایل مختلفی را به‌شکل هم‌زمان حل خواهد کرد:
– اگر نیاز به قطع ترافیک ورودی یک پاپ‌سایت باشد، قطع BGP امکان‌پذیر خواهد بود و مانند روش DNS، مشکلاتی مانند تاخیر و TTL را نخواهد داشت.
– به‌کمک یک‌سان بودن آدرس IP تمامی پاپ‌های CDN امکان اینکه یکی از این پاپ‌سایت‌ها به شکل متمرکز هدف حمله‌ی DDoS قرار بگیرد، مرتفع خواهد شد و ترافیک ورودی میان تمامی پاپ‌سایت‌ها توزیع می‌شود.
– توزیع بار به‌کمک مسیریابی در لایه‌ی شبکهی زیرساخت اینترنت انجام خواهد شد و نیازی به کمک گرفتن از موقعیت جغرافیایی IP درخواست‌دهنده (بدون قطعیت در اتصال شبکه)، برای هدایت ترافیک به نزدیک‌ترین پاپ‌سایت CDN نخواهد بود.
مهم‌ترین مشکلات توزیع بار در هر پاپ‌سایت CDN
پس از توزیع بار ترافیک ورودی به پاپ‌سایت‌های CDN نیاز است که این ترافیک ورودی به هر پاپ‌سایت، میان سرورهای مختلف آن پاپ‌سایت توزیع شود. چون هر پاپ‌سایت ممکن است متشکل از چندده تا چندصد یا چندهزار سرور مختلف باشد. نیاز است که ترافیک ورودی میان این سرورها به‌شکلی توزیع شود که بیش‌ترین استفاده‌ی ممکن از این زیرساخت به‌شکل متناسب انجام شود.
راهکارهایی مانند استفاده از ECMP یکی از راه‌های متداول توزیع بار ترافیک در درون هر دیتاسنتر به‌شمار می‌رود. اما این روش‌ها محدودیت‌های بسیاری دارد؛ مانند نبود امکان تنظیم وزن و کنترل ترافیک هر مسیر به‌شکل دقیق، مشکلات مربوط به مقیاس‌پذیری در حالت وجود تعداد بالای سرورها، نبود امکان کنترل ترافیک هر مسیر به‌شکل لحظه‌ای و… . به همین دلیل نیاز است که از روش دیگری برای کنترل دقیق‌تر ترافیک درون هر پاپ‌سایت استفاده شود.
راه‌حل؛ استفاده از DSR برای توزیع بار
قابلیت (DSR :Direct Server Response) روشی است که به‌کمک آن Load balancer تنها به مدیریت درخواست‌های ورودی می‌پردازد و پاسخ‌ها را به‌جای عبور از Load balancer، به‌شکل مستقیم به کاربر ارسال می‌شود و load balancer از مسیر پاسخ خارج می‌شود. به‌کمک این روش، کاهش بار load balancer شده و مصرف منابع را کاهش می‌دهد.
یکی از ابزارهایی که برای توزیع بار به‌کمک روش DSR است؛ ابزار Katran که محصول شرکت Meta است. این ابزار به‌کمک استفاده از XDP برای پردازش مدیریت سریع بسته‌های شبکه در Cornell Linux و هم‌چنین استفاده از DSR برای حذف پردازش پاسخ‌های ارسالی به‌سمت کاربر می‌تواند میلیون‌ها درخواست را در ثانیه مدیریت کند و مقیاس‌پذیری بالایی را در مواجهه با ترافیک بالا در لبه‌ی شبکه در اختیار قرار دهد. البته این ابزار برای اینکه بتواند هم‌زمان به‌شکل داخل و بین‌دیتاسنتری استفاده شود، نیاز به تغییرات متعددی داشته است.
مانند:
– پیاده‌سازی سرویس سنجش سلامت و Monitoring بهتر
– فایروال EBPF و پشتیبانی از Ipv6
– Monitoring مرکزی و اضافه شدن Maintenance Mode
– توزیع بار بین‌دیتاسنتری
ما هم در آروان‌کلاد توانسته‌ایم با استفاده‌ی هم‌زمان از BGP Anycast و استفاده از Katran و اعمال تغییراتی در آن به‌عنوان یک ابزار load balancer به نام DSR ترافیک ورودی را در سرورهای لبه مدیریت کنیم و دسترس‌پذیری بالایی را در سرویس‌های خود ارایه دهیم.
