توزیع بار در DNS و راهکارهای بهینه سازی

توزیع بار DNS یا : DNS-based Load balancingهمانطور که می دانید، load balancing فرآیند توزیع ترافیک بین دو یا چند سرور برای بهبود عملکرد و افزایش دسترسی پذیری است. سازمان ها از مدل های مختلفی از توزیع بار برای افزایش سرعت وب سایت، اپلیکیشن و حتی شبکه خصوصی خود استفاده می کنند.

بدون توزیع بار، اکثر اپلیکیشن های اینترنتی و وب سایت ها به طور موثری قادر به مدیریت ترافیک نبوده و با مشکلات عملکردی مواجه می شدند.

DNS نیز در مثالی متداول به دفترچه تلفن اینترنت معروف است. کار DNS ترجمه دامنه وبسایت به آدرس IP است. با ترجمه نام های دامنه به آدرس های IP، که به این فرآیند DNS resolution گویند، دیگر افراد نیازی به حفظ کردن اعداد طولانی و بی ربط آدرس های ip ندارند.

در تفسیر DNS ، یک مرورگر کاربر با سرور DNS ارتباط برقرار کرده تا آدرس IP صحیح وب سایت مورد نظر را از آن دریافت کند. این اقدام برای جستجوی یافتن آدرس IP از طریق نام یک دامنه اصطلاحاً DNS query نام دارد.

توزیع بار DNS محور، نوع خاصی از Load balancing است که از DNS برای توزیع ترافیک بین چندین سرور استفاده می کند. این کار با فراهم سازی چند آدرس IP متفاوت در پاسخ به DNS query انجام می شود.

توزیع کنندگان بار یا load balancer ها می توانند از چند روش مختلف یا قوانین متنوع برای انتخاب بین آدرس های IP معرفی شده استفاده کرده و آن را با DNS Query به اشتراک بگذارد.

یکی از این روش های متداول در توزیع بار DNS، تکنیک Round robin نام دارد.

منظور از Round robin DNS چیست؟

Round robin DNS نیز مثل سایر انواع توزیع بار با هدف یکسانی طراحی شده است: بهبود عملکرد سایت و اطمینان خاطر از توزیع صحیح ترافیک.

با این حال، بر خلاف استفاده از یک توزیع کننده بار نرم افزاری یا سخت افزاری، round robin DNS با استفاده از یک سرور DNS به نام Authoritative nameserver کار توزیع بار را عملی می کند.

Authoritative nameserver ها رکوردهای DNS از جمله A records و AAAA records در خود نگه می دارد. این رکوردها شامل نام دامنه و آدرس های IP متناظر با آن هستند.

زمانی که کاربری یک DNS Query درخواست می کند، هدف این جستجو یا query پیدا کردن A record یا AAAA record است. دامنه یک A record مفرد و خاص دارد که با یک آدرس IP مشخص گره خورده است.

این یعنی یک DNS query هر بار آدرس IP یکسانی را ارجاع خواهد داد.

با این وجود، در مدل Round robin DNS، دامنه ها دارای A record های مختلفی هستند، که هر کدام به یک آدرس IP متفاوت متصل است.

زمانی که کوئری های DNS وارد می شوند، آدرس های IP تحت یک چرخه Round robin به کوئری ها پاسخ می دهند؛ که درخواست های ارسالی را به نوبت بین سرورهای درگیر توزیع و پخش می کند.

 انواع دیگر توزیع بار در DNS

در حالی رویکرد Round robin بسیار رایج است، تنها روش برای مسیردهی ترافیک به شمار نمی آید. بیشتر توزیع کنندگان بار به مالکین دامنه اجازه می دهند تا از بین قوانین موجود در خصوص مسیردهی ترافیک، قانون مورد نظر خود را انتخاب کنند.

یک مثال از پیکربندی توزیع بار DNS محور ، الگوریتم وزنی است که سرورهای مختلف با وزن های نسبی بر اساس ظرفیت هندل کردن ترافیک شان مسئول پاسخ دهی به ترافیک می شوند.

سپس ترافیک به صورت تناسبی بین سرورها توزیع می شود؛ برای مثال اگر سرور A دو برابر سرور B ظرفیت داشته باشد، پس توزیع کننده بار دو برابر بیشتر از سرور B ترافیک را به سمت سرور A می فرستد. لود بلنسر اینکار را با بازگرداندن آدرس IP سرور A به کوئری DNS ارسالی انجام می دهد.

دو متد Round robin وزنی و  least connection وزنی، از نمونه های این نوع از توزیع بار هستند.

بسیاری از توزیع بارهای DNS محور، داینامیک یا پویا هستند؛ یعنی لود بلنسر باید سلامت و زمان پاسخ دهی یک سرور را در نظر گرفته و بعد درخواست را به آن اختصاص دهد.

الگوریتم های پویا می توانند مدل های مختلفی داشته باشند؛ برای مثال Least connection یکی از الگوریتم های توزیع بار داینامیک است.

در پیکربندی least connection، رصد سرور مشخص کننده این است که کدام سرور در حال حاضر با کمترین تعداد اتصال یا connection مواجه است. سپس توزیع کننده ترافیک ورودی را به سمت آن سرور هدایت کرده و آدرس IP آن را در پاسخ به DNS Query به کاربر ارائه می کند.

Geo-location نیز یکی دیگر از الگوریتم های محبوب در این حوزه است. در این پیکربندی، load balancer درخواست ها را از یک ناحیه به سمت یک سرور از پیش تعریف شده هدایت می کند. برای مثال تمام درخواست های ارسالی از فرانسه به سمت سرور F هدایت شده و تمام درخواست های ورودی از اسپانیا با سمت سرور S مسیردهی می شوند.

توزیع بار لوکال در مقایسه با توزیع بار جهانی

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

توزیع بار سرور جهانی (GSLB) بر مبنای همان توزیع بار سنتی عمل می کند. با این تفاوت که پخش حجم کاری یا workload دیگر به تنها یک شبکه مفرد یا دیتاسنتر محدود نیست. در عوض، توزیع بار کاری در وسعت کل سیاره ( بین دیتاسنترها ) رخ می دهد.

این موضوع چالش های بسیاری را برای راهکارهای توزیع بار مدرن بهمراه دارد؛  بیشتر از همه، کیفیت اتصال بین موقعیت های جغرافیایی پراکنده سرورها و موقعیت جغرافیایی درخواست کننده (کاربر)، بسیار مهم و حیاتی محسوب می شود.

در گذشته هر راهکار GSLB نسل قدیمی، بر توزیع بار DNS محور تکیه می کرد، که هم اثربخشی و هم عملکرد را محدود می کرد.

امروز، رایانش ابری توانسته یک راهکار فوق العاده برای توزیع بار لوکال و جهانی فراهم کند، که به کمک یک سرویس ابری هر دو سناریو را مدیریت می کند.

DNS: نا هماهنگ و نا آگاه از بار

تا زمانی که استانداردهای توزیع بار سرور جهانی رعایت شوند، راهکارهای DNS برای اکثر اپلیکیشن ها و وب سایت های ساده مناسب بوده و توسط بسیاری از برندهای فعلی نیز مورد استفاده قرار می گیرند.

هر روز ادمین های شبکه ی بیشتری متوجه می شوند که توزیع بار DNS محور بنا به دلایلی نمی تواند نیازمندی های یک سازمان بزرگ را برآورده کند.

یکی از این دلایل این است که توزیع بار DNS محور، از استخرهای توزیع بار استفاده می کنند، که برای نواحی جغرافیایی مختلفی تعریف شده اند. در این شرایط ادمین توزیع بار مشخص می کند که کدام سرورها در دسترس بوده و ترافیک چند وقت یک بار باید به سمت آنها هدایت شود. این کار در حالت تئوری، بالاترین بهره برداری از زیرساخت های پراکنده جغرافیایی را ممکن می سازد.

ولی، توزیع بار DNS محور بر مبنای متدولوژی توزیع Round robin سنتی عمل می کند. یعنی توزیع کنندگان بار، لیستی از سرورها را بررسی کرده و یک اتصال را به نوبت به سمت هر سرور هدایت می کند. هر بار که به انتهای لیست برسد، از بالای لیست مجدداً اتصالات را بین سرورها توزیع خواهد کرد.

مشکل اینجاست که مدل توزیع round robin به اصطلاح load-aware یا آگاه از بار نبوده و توزیع کننده تحت هیچ شرایطی نمی داند که آیا سرور بعدی در صف، در واقع گزینه ی بهینه ای است یا نه.

این موضوع یک سرور را با حجم کاری کم و دیگری را با بار اضافه همراه خواهد کرد.

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

در آخر، توزیع بار DNS محور، مستعد تأخیرات زیادی هستند. این تأخیرات به دلیل تعویض DNS برای اثربخش بودن است، چون باید در سطح ISP ثبت و ضبط شود. ISP ها فقط زمانی کش DNS خود را پاک می کنند که چرخه TTL به اتمام رسد.

این یعنی تا زمانی که کش بروزرسانی نشود، ISP ها از تغییرات به وجود آمده ناآگاه خواهند بود؛ و ترافیک را به سمت سرور اشتباه هدایت و مسیردهی خواهند کرد.

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

تکیه بر TTL به این معناست که تغییرات در مسیرهای توزیع بار، با سرعت بسیار پایین تری تکثیر خواهند شد، که به پاسخ دهی ضعیف تر و کند تر ، Failover یا از کار افتادگی، و توزیع مجدد بار منتج خواهد شد.

علاوه بر این تغییرات به صورت نامتوازن توزیع خواهند شد، چراکه هر ISP دارای قوانین کش DNS مختص به خود می باشد.

مثالی از ضعف توزیع بار DNS محور

بگذارید با یک مثال سناریویی را متصور شویم...

یک اپلیکیشن بر روی دو سرور اجرا می شود، سرور A و سرور B. و چرخه TTL روی یک ساعت تنظیم شده است.

در هر لحظه ای، بار سرور A می تواند تا اندازه ای افزایش یابد که توزیع کننده بار به هدایت ترافیک به سمت سرور  B ملزم شود.

ولی اگر قبل از 20 دقیقه تا آپدیت بعدیِ چرخه TTL، بار به حداکثر خود رسد، چه؟

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

در همین لحظه، تمام ترافیک همچنان به سمت سرور Overloaded یا فول شده از بار، هدایت خواهد شد؛ که تأخیرات فزاینده و تدریجی بزرگی ایجاد به وجود می آورد. در نتیجه تحویل محتوا آهسته تر شده و در نهایت رتبه کیفی سرویس کاهش پیدا می کند؛ این فرآیند می تواند تا از کار افتادگی کامل سرویس پیش رود.

حتی پس از آن 20 دقیقه نیز، برخی از ISP ها همچنان کش DNS را نگه داشته و پاک نمی کنند. این یعنی یک درصد غیر قابل پیش بینی ترافیک همچنان به اشتباه مسیردهی خواهند شد. این مساوی است با عملکردی بسیار ضعیف برای یک سرویس!

قطعی DNS- تأثیر منفی آن بر RTO

راهکارهای حل مشکل Failover یک DNS دارای محدودیت های مشابهی با راهکارهای توزیع بار DNS هستند. با این حال، در سناریوهای بازیابی و رفع مشکل، تاخیر ذاتی یک راهکار توزیع بار DNS خود یک مشکل بزرگ تر است.

در نهایت RTO (Recovery Time Objective) یا مدت زمانی که کسب و کار بتواند بدون در دسترس بود سیستم، به فعالیت خود ادامه دهد، کاهش خواهد یافت.

به علاوه، راهکارهای DNS failover نیز load-aware نیستند؛ این یعنی ممکن است بخشی از بازیابی ناقص بماند.

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

در موارد حساسی مثل تبادلات ارز یا سهام، اگر برخی از کاربران به سمت سرورهای سالم هدایت شده و برخی دیگر به اشتباه به سمت سرور از کار افتاده مسیردهی شوند، به هیچ وجه قابل قبول نخواهد بود.

راهکار میزبان کلود

بهتر است از DNS ابری میزبان کلود برای بهینه سازی و جلوگیری از مشکلات مذکور در این مطلب استفاده کنید. سرویس DNS ابری میزبان کلود دارای ویژگی توزیع بار هوشمند بوده  و به کمک تکنولوژی Anycast فرآیند تفسیر نامه دامنه شما به آدرس های IP سرورهای اصلی یا سرورهای لبه ی CDN را شتاب داده و بهینه می کند.

این سرویس به معماری IP Anycast مجهز بوده و با بکارگیری چندین سرور DNS فیزیکی پر قدرت در شبکه ای یکپارچه، موقعیت جغرافیایی کاربر را در نظر گرفته و با توجه به وضعیت سلامت DNS سرورها و در دسترس بودن آنها، نزدیک ترین سرور را به کلاینت متصل خواهد کرد.

جمع بندی

استفاده از توزیع بار برای وب سایت ها و اپلیکیشن هایی که از چند سرور برای میزبانی استفاده می کنند و یا از سرویس CDN رایگان برخوردار هستند، یک ضرورت است. مسلماً تمام ترافیک را نمی توان به سمت یک آدرس IP هدایت و مسیردهی کرد؛ وگرنه از ابتدا از چند سرور و یا CDN کمک گرفته نمی شد؛ پس برای اینکه ترافیک به روش درستی بین سرورها توزیع شود، باید از یک الگوریتم مسیردهی مناسب بهره برد.

این توزیع بار می تواند در سمت DNS انجام شود، اما به این روش ایرادات گوناگونی گرفته شده در این مطلب به آنها اشاره کردیم؛ راه حل هایی برای بهینه سازی این موضوع وجود داشته و رویکردهای تفسیر دامنه به آدرس های IP به شیوه های مختلف در این مطلب معرفی شدند.  امیدواریم این مطلب برای شما مفید واقع شده باشد.