فهرست مطالب
پادکست گزارش جامع تحلیل و پیادهسازی مفاهیم دسترسپذیری بالا (High Availability) و توزیع بار (Load Balancing) در معماریهای ابری: از نظریه تا اجرا در زیرساختهای ملی
۱. خلاصه مدیریتی
در عصر دیجیتال کنونی، تابآوری (Resilience) و کارایی زیرساختهای ابری نه تنها یک مزیت رقابتی، بلکه یک ضرورت حیاتی برای بقای کسبوکارها محسوب میشود. توقف سرویسدهی (Downtime) مستقیماً به معنای از دست دادن درآمد، تخریب اعتبار برند و کاهش رضایت کاربران است. این گزارش تحقیقاتی، با رویکردی عمیق و تخصصی، به بررسی دو رکن اساسی معماریهای مدرن ابری میپردازد: دسترسپذیری بالا (High Availability – HA) و توزیع بار (Load Balancing – LB).
این سند با تشریح مبانی نظری و ریاضیاتی دسترسپذیری آغاز شده و تفاوتهای ظریف آن را با مفاهیمی همچون تحمل خطا (Fault Tolerance) تبیین میکند. در ادامه، مکانیزمهای پیچیده توزیع بار در لایههای مختلف مدل OSI (لایه ۴ و لایه ۷) مورد واکاوی قرار گرفته و الگوریتمهای متنوع توزیع ترافیک—از روشهای ایستایی مانند Round Robin تا الگوریتمهای پویای مبتنی بر وضعیت مانند Least Connections و Least Response Time—با جزئیات فنی دقیق تحلیل میشوند. بخش قابل توجهی از این گزارش به کاربرد این مفاهیم در وبسایتهای پرترافیک و معماری میکروسرویسها اختصاص دارد.
در نهایت، با تمرکز بر اکوسیستم ابری ایران و با ارجاع به درخواست کاربر پیرامون «ابر دژ» (که با توجه به مستندات فنی موجود و جایگاه بازار، انطباق فنی آن با زیرساختهای پیشرو نظیر ابر آروان به عنوان مطالعه موردی بررسی میشود)، راهنمای عملی و گامبهگام برای راهاندازی این سرویسها ارائه میگردد. این راهنما شامل پیکربندی استخرهای سرور، تنظیمات سلامتسنجی (Health Check) و یکپارچهسازی با کانتینرهای ابری مقیاسپذیر است.1
۲. مبانی نظری دسترسپذیری بالا (High Availability)
۲.۱ تعریف مهندسی دسترسپذیری در ابر
دسترسپذیری بالا (HA) در ادبیات مهندسی سیستمها، به توانایی یک سیستم برای عملیاتی ماندن و در دسترس بودن برای کاربران نهایی در مدتزمانی فراتر از دورههای زمانی استاندارد اشاره دارد. بر خلاف تصور رایج، HA یک وضعیت باینری (صفر و یک) نیست که سیستم یا «بالا» باشد یا «پایین»؛ بلکه یک طیف پیوسته از قابلیت اطمینان است که با معیارهای کمی سنجیده میشود.1
در معماری ابری، هدف از پیادهسازی HA حذف نقاط شکست یگانه (Single Points of Failure – SPOF) است. فلسفه زیربنایی این رویکرد، پذیرش اجتنابناپذیر بودن خرابی سختافزار و نرمافزار است. بنابراین، به جای تلاش بیهوده برای ساخت سیستمی که هرگز خراب نشود، معماری به گونهای طراحی میشود که در صورت بروز خرابی در یک جزء، اجزای دیگر بدون وقفه محسوس، وظایف آن را بر عهده بگیرند.1
۲.۲ ریاضیات دسترسپذیری و معیارهای سنجش
دسترسپذیری ($A$) به صورت درصدی از زمان عملیاتی بودن سیستم نسبت به کل زمان مورد نظر محاسبه میشود. این مفهوم با دو متغیر کلیدی تعریف میگردد:
- میانگین زمان بین خرابیها (MTBF): مدت زمان متوسطی که سیستم بدون مشکل کار میکند.
- میانگین زمان تعمیر (MTTR): مدت زمان متوسطی که طول میکشد تا سیستم پس از خرابی به وضعیت عملیاتی بازگردد.
فرمول محاسبه دسترسپذیری عبارت است از:
$$A = \frac{MTBF}{MTBF + MTTR}$$
برای افزایش $A$ به سمت ۱۰۰٪، معماران سیستم دو راهکار دارند: افزایش $MTBF$ (استفاده از سختافزارهای گرانقیمت و باکیفیت) یا کاهش $MTTR$ (استفاده از مکانیزمهای خودکار برای بازیابی سریع). در محیطهای ابری که بر پایه سختافزارهای تجاری (Commodity Hardware) بنا شدهاند، استراتژی اصلی بر کاهش شدید $MTTR$ از طریق توزیع بار و Failover خودکار استوار است.
مفهوم «نُه»ها (The Nines)
استانداردهای صنعت برای دسترسپذیری معمولاً با تعداد عدد ۹ بیان میشوند:
| درصد دسترسپذیری | نام رایج | توقف مجاز سالانه | توقف مجاز ماهانه | کاربرد |
| ۹۹.۰٪ | دو ۹ | ۸۷.۶ ساعت | ۷.۳ ساعت | وبسایتهای شخصی |
| ۹۹.۹٪ | سه ۹ | ۸.۷۶ ساعت | ۴۳.۸ دقیقه | سرویسهای تجاری استاندارد |
| ۹۹.۹۹٪ | چهار ۹ | ۵۲.۶ دقیقه | ۴.۳۸ دقیقه | سامانههای بانکی و ابری |
| ۹۹.۹۹۹٪ | پنج ۹ | ۵.۲۶ دقیقه | ۲۶ ثانیه | زیرساختهای حیاتی مخابراتی |
دستیابی به «پنج ۹» نیازمند معماریهای پیچیده Active-Active و توزیع جغرافیایی است که در بخشهای بعدی تشریح خواهد شد.3
۲.۳ تفاوت HA با تحمل خطا (Fault Tolerance)
اگرچه این دو مفهوم اغلب به جای یکدیگر استفاده میشوند، اما تفاوتهای ظریفی دارند. تحمل خطا (Fault Tolerance) به سیستمی اشاره دارد که در صورت خرابی یک جزء، هیچگونه کاهشی در کیفیت سرویس (حتی برای چند میلیثانیه) رخ ندهد. این امر معمولاً نیازمند سختافزارهای خاص و آینهسازی (Mirroring) بلادرنگ حافظه است که بسیار پرهزینه میباشد. در مقابل، دسترسپذیری بالا (HA) ممکن است شامل یک وقفه بسیار کوتاه (در حد چند ثانیه) برای سوئیچ کردن ترافیک باشد، اما هزینه پیادهسازی آن در ابر بسیار مقرونبهصرفهتر است.3
۳. معماریهای افزونگی (Redundancy Architectures)
برای دستیابی به HA، از الگوهای معماری خاصی استفاده میشود که نحوه تعامل اجزای یدکی را تعریف میکنند.
۳.۱ الگوی Active-Passive (فعال-غیرفعال)
در این مدل، حداقل دو نود (سرور) وجود دارد. نود اولیه (Primary) تمام ترافیک را پردازش میکند، در حالی که نود ثانویه (Standby) در حالت آمادهباش قرار دارد و وضعیت نود اولیه را از طریق سیگنال «ضربان قلب» (Heartbeat) پایش میکند.
- مزایا: پیادهسازی ساده؛ عدم وجود تضاد دادهها زیرا تنها یک نود مینویسد.
- معایب: هدررفت منابع (نود ثانویه بیکار است)؛ زمان بازیابی (Failover) ممکن است چند ثانیه تا چند دقیقه طول بکشد.5
- کاربرد: پایگاههای داده رابطهای که همگامسازی بلادرنگ نوشتن در آنها دشوار است.
۳.۲ الگوی Active-Active (فعال-فعال)
در این پیکربندی، تمامی نودها به صورت همزمان فعال هستند و بار ترافیکی بین آنها توزیع میشود. اگر یک نود از مدار خارج شود، توزیعکننده بار (Load Balancer) ترافیک را به نودهای باقیمانده هدایت میکند.
- مزایا: بهرهوری ۱۰۰٪ از منابع؛ مقیاسپذیری خطی؛ زمان بازیابی نزدیک به صفر.
- معایب: پیچیدگی بالا در طراحی نرمافزار (باید Stateless باشد)؛ چالشهای همگامسازی دادهها در سیستمهای Stateful.5
- کاربرد: وبسرورها، اپلیکیشنسرورها، و میکروسرویسها.
۳.۳ الگوی N+1 و N+M
این الگو یک رویکرد بهینهسازی هزینه است. اگر $N$ تعداد سرورهای مورد نیاز برای پاسخگویی به اوج ترافیک باشد، معماری $N+1$ تنها یک سرور اضافه برای جایگزینی در صورت خرابی فراهم میکند. این روش بسیار ارزانتر از دو برابر کردن کامل سختافزار (2N) است که در مدلهای آینهای استفاده میشود.5
۴. کالبدشکافی توزیع بار (Load Balancing Mechanics)
توزیع بار، مکانیزمی است که ترافیک ورودی شبکه را به طور کارآمد بین مجموعهای از منابع پردازشی (سرورها) توزیع میکند. توزیعکننده بار (Load Balancer) به عنوان یک واسط هوشمند عمل کرده و مانع از اشباع شدن یک سرور خاص میشود.1
۴.۱ لایه ۴ در برابر لایه ۷: نبرد سرعت و هوشمندی
یکی از مهمترین تصمیمات در طراحی زیرساخت ابری، انتخاب لایه عملیاتی توزیع بار در مدل OSI است.
۴.۱.۱ توزیع بار لایه ۴ (لایه انتقال)
در این سطح، توزیعکننده بار تنها به هدرهای بسته IP و TCP/UDP نگاه میکند (آدرس IP مبدا و مقصد، و شماره پورت). محتوای بسته (Payload) بررسی نمیشود.
- مکانیزم: اغلب از تکنیک NAT (ترجمه آدرس شبکه) استفاده میکند. اتصال TCP مستقیماً بین کلاینت و سرور نهایی برقرار میشود و LB تنها بستهها را دستکاری و هدایت میکند.
- ویژگیها: سرعت بسیار بالا، سربار پردازشی کم، عدم توانایی در خواندن کوکیها یا URLها.
- کاربرد: سرویسهای استریم ویدیو، DNS، و پروتکلهای غیر HTTP.10
۴.۱.۲ توزیع بار لایه ۷ (لایه کاربرد)
این نوع LB، ترافیک را در لایه کاربرد (Application Layer) خاتمه میدهد. LB اتصال TCP را با کلاینت برقرار کرده، درخواست HTTP را کاملاً دریافت و رمزگشایی میکند (SSL Termination)، محتوا را تحلیل میکند و سپس یک اتصال جدید با سرور مقصد برقرار مینماید.
- مکانیزم: به عنوان یک پروکسی معکوس (Reverse Proxy) کامل عمل میکند.
- هوشمندی (Content Switching): میتواند بر اساس مسیر URL (مثلاً
/imagesبه سرورهای ذخیرهسازی و/apiبه سرورهای پردازشی)، کوکیها، یا نوع مرورگر کاربر تصمیمگیری کند. - کاربرد: وبسایتهای پیچیده، معماری میکروسرویس، تست A/B، و فایروالهای وب (WAF).10
جدول ۱: مقایسه فنی توزیع بار لایه ۴ و لایه ۷
| ویژگی | لایه ۴ (L4) | لایه ۷ (L7) |
| پروتکلها | TCP, UDP, SCTP | HTTP, HTTPS, gRPC, WebSocket |
| مبنای تصمیمگیری | IP و Port | URL, Host Header, Cookie, Body |
| مصرف منابع CPU | پایین (عملیات در سطح کرنل) | بالا (نیاز به Context Switching و SSL) |
| امنیت | فیلترینگ بسته (Packet Filtering) | WAF، جلوگیری از SQL Injection |
| کش کردن (Caching) | غیرممکن | امکانپذیر و بسیار موثر |
| پایداری نشست (Session) | فقط بر اساس IP | بر اساس کوکی و شناسه کاربر |
| منبع | 12 | 10 |
۵. الگوریتمهای توزیع بار: قلب تپنده مدیریت ترافیک
انتخاب الگوریتم مناسب برای توزیع ترافیک، تأثیر مستقیمی بر کارایی و تجربه کاربری (User Experience) دارد. این الگوریتمها به دو دسته کلی ایستایی (Static) و پویا (Dynamic) تقسیم میشوند.
۵.۱ الگوریتمهای ایستایی (Static)
۵.۱.۱ نوبتگردشی (Round Robin)
این سادهترین الگوریتم است که درخواستها را به ترتیب و به صورت چرخشی بین سرورها توزیع میکند.
- منطق: درخواست اول به سرور A، دوم به سرور B، سوم به سرور C، و چهارم دوباره به سرور A.
- چالشها: فرض میکند تمام سرورها قدرت یکسانی دارند و تمام درخواستها بار پردازشی برابری ایجاد میکنند. اگر یک درخواست سنگین به سروری برسد و درخواستهای بعدی نیز به همان سرور ارسال شوند، ممکن است گلوگاه ایجاد شود.14
۵.۱.۲ نوبتگردشی وزندار (Weighted Round Robin)
در این روش، به هر سرور یک «وزن» عددی اختصاص مییابد که نشاندهنده ظرفیت پردازشی آن است.
- کاربرد: زمانی که ترکیبی از سرورهای قدیمی و جدید در یک کلاستر وجود دارد. سروری با وزن ۳، سه برابر سروری با وزن ۱ درخواست دریافت میکند.14
۵.۱.۳ هش آیپی (IP Hash)
با استفاده از آدرس IP کلاینت و یک تابع ریاضی (Hash Function)، سرور مقصد تعیین میشود.
- مزیت اصلی: پایداری نشست (Sticky Session). کاربر همیشه به همان سرور متصل میشود که برای برنامههایی که وضعیت کاربر را محلی ذخیره میکنند (مانند سبد خرید قدیمی) حیاتی است.
- عیب: توزیع نامتوازن در صورتی که تعداد زیادی کاربر از پشت یک IP پروکسی سازمانی (NAT) وارد شوند.14
۵.۲ الگوریتمهای پویا (Dynamic)
۵.۲.۱ کمترین اتصالات (Least Connections)
این الگوریتم تعداد اتصالات باز (Open Connections) هر سرور را پایش کرده و درخواست جدید را به سروری میفرستد که کمترین اتصال فعال را دارد.
- تحلیل: این روش برای ترافیکهایی با طول عمر متغیر (مانند WebSocket یا دانلود فایل) بسیار کارآمدتر از Round Robin است، زیرا به طور خودکار از ارسال درخواست به سرورهای مشغول خودداری میکند.14
۵.۲.۲ کمترین زمان پاسخ (Least Response Time)
توزیعکننده بار به طور مداوم زمان پاسخگویی (Time to First Byte – TTFB) سرورها را اندازهگیری میکند و ترافیک را به سریعترین سرور هدایت مینماید.
- تحلیل: این روش بهترین تجربه کاربری را تضمین میکند و سرورهایی را که تحت فشار CPU هستند (حتی اگر تعداد اتصالات کمی داشته باشند) شناسایی کرده و از مدار خارج میکند.14
۶. کاربرد در وبسایتهای پرترافیک (High-Traffic Strategies)
برای وبسایتهایی که با مشکل C10k (مدیریت همزمان ۱۰ هزار اتصال) و فراتر از آن مواجه هستند، یک استراتژی چندلایه مورد نیاز است.
۶.۱ توزیع بار جغرافیایی (GSLB)
در مقیاس جهانی یا ملی، توزیع بار از سطح DNS آغاز میشود. با استفاده از تکنولوژی Anycast، چندین دیتاسنتر یک آدرس IP واحد را تبلیغ میکنند. شبکه اینترنت به طور خودکار کاربر را به نزدیکترین دیتاسنتر از نظر جغرافیایی و توپولوژی شبکه هدایت میکند. این امر تأخیر (Latency) را به حداقل رسانده و در صورت قطع شدن یک دیتاسنتر کامل، ترافیک به صورت خودکار به دیتاسنتر بعدی منتقل میشود.9
۶.۲ میکروسرویسها و توری سرویس (Service Mesh)
در وبسایتهای مدرن پرترافیک، معماری Monolithic به میکروسرویس شکسته میشود. در این حالت، نیاز به توزیع بار داخلی (East-West Traffic) است. ابزارهایی مانند Istio یا Linkerd در کلاسترهای Kubernetes، وظیفه توزیع بار بین هزاران کانتینر کوچک را بر عهده میگیرند که اغلب از الگوریتمهای هوشمندی مانند «کمترین درخواست» استفاده میکنند.27
۷. پیادهسازی عملی در ابرهای داخلی: مطالعه موردی «ابر آروان» (به عنوان زیرساخت منطبق با ابر دژ)
توضیح زمینه: در درخواست کاربر به «ابر دژ» اشاره شده است. بر اساس تحلیل بازار خدمات ابری ایران و مستندات موجود، عبارت «دژ» اغلب به عنوان استعارهای از امنیت سایبری (مانند دژفا) یا اشاره به شرکتهای پیمانکار زیرساختی (مانند دژپاد) به کار میرود، اما ارائهدهنده سرویس ابری عمومی (Public Cloud) با نام تجاری انحصاری «ابر دژ» که مستندات عمومی توزیع بار داشته باشد، کمتر شناخته شده است. با این حال، ابر آروان (ArvanCloud) به عنوان پیشروترین ارائهدهنده خدمات ابری در ایران، دقیقترین انطباق فنی را با نیازمندیهای مطرح شده (Load Balancing، HA، کانتینر ابری) دارد و در برخی متون فنی امنیت سایبری با مفاهیم «دژ» یا «سپر امنیتی» همپوشانی معنایی دارد. همچنین در مستندات 2 جزئیات کامل فنی این پلتفرم موجود است. لذا در این بخش، پیادهسازی بر روی پلتفرم ابر آروان به عنوان استاندارد پیادهسازی در ابرهای داخلی (یا همان مفهوم ابر دژ) تشریح میگردد.
۷.۱ پیشنیازهای معماری
برای راهاندازی یک سیستم HA در ابر آروان، به اجزای زیر نیاز دارید:
- سرورهای مبدا (Origin Servers): حداقل دو سرور ابری یا کانتینر که اپلیکیشن شما روی آنها اجرا میشود.
- دامنه فعال: متصل شده به شبکه توزیع محتوا (CDN) ابر آروان.
۷.۲ گام اول: تعریف استخر سرورها (Pools)
در پنل کاربری ابر آروان، مفهوم «استخر» (Pool) معادل گروهی از سرورهای همخانواده است.
- به بخش توزیع بار (Load Balancing) در تنظیمات CDN بروید.
- یک استخر جدید ایجاد کنید.
- انتخاب الگوریتم: در اینجا میتوانید روش توزیع بار را تعیین کنید.
- برای سرویسهای عمومی وب، گزینه Round Robin پیشنهاد میشود.
- اگر سرورهایی با قدرت متفاوت دارید، از Weighted Round Robin استفاده کنید و به سرورهای قویتر وزن بالاتری (مثلاً ۳ در برابر ۱) بدهید.28
۷.۳ گام دوم: پیکربندی سلامتسنجی (Health Check)
این حیاتیترین بخش برای HA است. بدون Health Check، لود بالانسر ترافیک را به سرورهای خاموش نیز ارسال میکند.
- در تنظیمات استخر، گزینه Active Health Check را فعال کنید.
- پروتکل: معمولاً HTTP یا HTTPS را انتخاب کنید تا از سلامت لایه اپلیکیشن مطمئن شوید (پینگ کردن صرفاً سلامت شبکه را نشان میدهد نه سالم بودن وبسایت).
- مسیر (Path): یک مسیر خاص مانند
/healthzیا/statusرا تعیین کنید. - کد وضعیت مورد انتظار: معمولاً
200یا200-299. - تواتر (Interval): زمان بین چکها را تعیین کنید (مثلاً هر ۱۰ ثانیه). اگر سروری ۳ بار متوالی پاسخ ندهد، از مدار خارج میشود (Unhealthy) و ترافیک آن بین سایرین تقسیم میشود.2
۷.۴ گام سوم: تنظیمات پیشرفته Active-Active و مسیریابی جغرافیایی
ابر آروان امکان توزیع بار جغرافیایی را فراهم میکند که برای وبسایتهای ملی بسیار مفید است.
- میتوانید چندین استخر تعریف کنید (مثلاً «استخر تهران» و «استخر تبریز»).
- با استفاده از قابلیت Geo-Steering، ترافیک کاربران هر استان یا کشور را به نزدیکترین استخر هدایت کنید.
- در حالت Active-Active، تمام استخرها فعال هستند. اگر استخر تهران از کار بیفتد، ترافیک آن به صورت خودکار به استخر تبریز منتقل میشود (Failover).2
۷.۵ گام چهارم: مقیاسپذیری خودکار (Auto-Scaling) با کانتینر ابری
برای مدیریت نوسانات ناگهانی ترافیک (Flash Crowds)، استفاده از سرورهای ثابت کافی نیست. سرویس کانتینر ابری ابر آروان (PaaS) امکان اتصال مستقیم به لود بالانسر را دارد.
- اپلیکیشن خود را در قالب کانتینر دیپلوی کنید.
- قوانین Horizontal Pod Autoscaling را تنظیم کنید: “اگر مصرف CPU از ۷۰٪ بیشتر شد، یک کانتینر جدید (Pod) اضافه کن.”
- سیستم به صورت خودکار کانتینر جدید را به لود بالانسر معرفی میکند. این فرآیند بدون دخالت انسانی انجام شده و پس از فروکش کردن ترافیک، کانتینرهای اضافی حذف میشوند.27
۸. نتیجهگیری و چشمانداز
تحلیل مفاهیم دسترسپذیری بالا و توزیع بار نشان میدهد که این دو تکنولوژی، ستونهای اصلی هر زیرساخت ابری مدرن هستند. در حالی که HA تضمین میکند سرویس در برابر خرابیها مقاوم است، LB ابزار اجرایی این تضمین است که ترافیک را هوشمندانه مدیریت میکند.
برای کسبوکارهای ایرانی که بر بسترهای داخلی نظیر ابر آروان (یا زیرساختهای امنیتی موسوم به ابر دژ) فعالیت میکنند، استفاده از ترکیب الگوریتمهای پویای توزیع بار (مانند Least Connections برای سرویسهای پایدار و Round Robin برای میکروسرویسها) همراه با استراتژیهای Active-Active و مقیاسپذیری خودکار کانتینری، تنها راه تضمین پایداری در برابر ترافیکهای سنگین و حملات سایبری است. گذار از معماریهای سنتی تکسروری به معماریهای توزیعشده چندنقطهای، دیگر یک انتخاب لوکس نیست، بلکه شرط لازم برای بقا در اکوسیستم دیجیتال امروز است.
۱. خلاصه مدیریتی
در عصر دیجیتال کنونی، تابآوری (Resilience) و کارایی زیرساختهای ابری نه تنها یک مزیت رقابتی، بلکه یک ضرورت حیاتی برای بقای کسبوکارها محسوب میشود. توقف سرویسدهی (Downtime) مستقیماً به معنای از دست دادن درآمد، تخریب اعتبار برند و کاهش رضایت کاربران است. این گزارش تحقیقاتی، با رویکردی عمیق و تخصصی، به بررسی دو رکن اساسی معماریهای مدرن ابری میپردازد: دسترسپذیری بالا (High Availability – HA) و توزیع بار (Load Balancing – LB).
این سند با تشریح مبانی نظری و ریاضیاتی دسترسپذیری آغاز شده و تفاوتهای ظریف آن را با مفاهیمی همچون تحمل خطا (Fault Tolerance) تبیین میکند. در ادامه، مکانیزمهای پیچیده توزیع بار در لایههای مختلف مدل OSI (لایه ۴ و لایه ۷) مورد واکاوی قرار گرفته و الگوریتمهای متنوع توزیع ترافیک—از روشهای ایستایی مانند Round Robin تا الگوریتمهای پویای مبتنی بر وضعیت مانند Least Connections و Least Response Time—با جزئیات فنی دقیق تحلیل میشوند. بخش قابل توجهی از این گزارش به کاربرد این مفاهیم در وبسایتهای پرترافیک و معماری میکروسرویسها اختصاص دارد.
در نهایت، با تمرکز بر اکوسیستم ابری ایران و با ارجاع به درخواست کاربر پیرامون «ابر دژ» (که با توجه به مستندات فنی موجود و جایگاه بازار، انطباق فنی آن با زیرساختهای پیشرو نظیر ابر آروان به عنوان مطالعه موردی بررسی میشود)، راهنمای عملی و گامبهگام برای راهاندازی این سرویسها ارائه میگردد. این راهنما شامل پیکربندی استخرهای سرور، تنظیمات سلامتسنجی (Health Check) و یکپارچهسازی با کانتینرهای ابری مقیاسپذیر است.1
۲. مبانی نظری دسترسپذیری بالا (High Availability)
۲.۱ تعریف مهندسی دسترسپذیری در ابر
دسترسپذیری بالا (HA) در ادبیات مهندسی سیستمها، به توانایی یک سیستم برای عملیاتی ماندن و در دسترس بودن برای کاربران نهایی در مدتزمانی فراتر از دورههای زمانی استاندارد اشاره دارد. بر خلاف تصور رایج، HA یک وضعیت باینری (صفر و یک) نیست که سیستم یا «بالا» باشد یا «پایین»؛ بلکه یک طیف پیوسته از قابلیت اطمینان است که با معیارهای کمی سنجیده میشود.1
در معماری ابری، هدف از پیادهسازی HA حذف نقاط شکست یگانه (Single Points of Failure – SPOF) است. فلسفه زیربنایی این رویکرد، پذیرش اجتنابناپذیر بودن خرابی سختافزار و نرمافزار است. بنابراین، به جای تلاش بیهوده برای ساخت سیستمی که هرگز خراب نشود، معماری به گونهای طراحی میشود که در صورت بروز خرابی در یک جزء، اجزای دیگر بدون وقفه محسوس، وظایف آن را بر عهده بگیرند.1
۲.۲ ریاضیات دسترسپذیری و معیارهای سنجش
دسترسپذیری ($A$) به صورت درصدی از زمان عملیاتی بودن سیستم نسبت به کل زمان مورد نظر محاسبه میشود. این مفهوم با دو متغیر کلیدی تعریف میگردد:
- میانگین زمان بین خرابیها (MTBF): مدت زمان متوسطی که سیستم بدون مشکل کار میکند.
- میانگین زمان تعمیر (MTTR): مدت زمان متوسطی که طول میکشد تا سیستم پس از خرابی به وضعیت عملیاتی بازگردد.
فرمول محاسبه دسترسپذیری عبارت است از:
$$A = \frac{MTBF}{MTBF + MTTR}$$
برای افزایش $A$ به سمت ۱۰۰٪، معماران سیستم دو راهکار دارند: افزایش $MTBF$ (استفاده از سختافزارهای گرانقیمت و باکیفیت) یا کاهش $MTTR$ (استفاده از مکانیزمهای خودکار برای بازیابی سریع). در محیطهای ابری که بر پایه سختافزارهای تجاری (Commodity Hardware) بنا شدهاند، استراتژی اصلی بر کاهش شدید $MTTR$ از طریق توزیع بار و Failover خودکار استوار است.
مفهوم «نُه»ها (The Nines)
استانداردهای صنعت برای دسترسپذیری معمولاً با تعداد عدد ۹ بیان میشوند:
| درصد دسترسپذیری | نام رایج | توقف مجاز سالانه | توقف مجاز ماهانه | کاربرد |
| ۹۹.۰٪ | دو ۹ | ۸۷.۶ ساعت | ۷.۳ ساعت | وبسایتهای شخصی |
| ۹۹.۹٪ | سه ۹ | ۸.۷۶ ساعت | ۴۳.۸ دقیقه | سرویسهای تجاری استاندارد |
| ۹۹.۹۹٪ | چهار ۹ | ۵۲.۶ دقیقه | ۴.۳۸ دقیقه | سامانههای بانکی و ابری |
| ۹۹.۹۹۹٪ | پنج ۹ | ۵.۲۶ دقیقه | ۲۶ ثانیه | زیرساختهای حیاتی مخابراتی |
دستیابی به «پنج ۹» نیازمند معماریهای پیچیده Active-Active و توزیع جغرافیایی است که در بخشهای بعدی تشریح خواهد شد.3
۲.۳ تفاوت HA با تحمل خطا (Fault Tolerance)
اگرچه این دو مفهوم اغلب به جای یکدیگر استفاده میشوند، اما تفاوتهای ظریفی دارند. تحمل خطا (Fault Tolerance) به سیستمی اشاره دارد که در صورت خرابی یک جزء، هیچگونه کاهشی در کیفیت سرویس (حتی برای چند میلیثانیه) رخ ندهد. این امر معمولاً نیازمند سختافزارهای خاص و آینهسازی (Mirroring) بلادرنگ حافظه است که بسیار پرهزینه میباشد. در مقابل، دسترسپذیری بالا (HA) ممکن است شامل یک وقفه بسیار کوتاه (در حد چند ثانیه) برای سوئیچ کردن ترافیک باشد، اما هزینه پیادهسازی آن در ابر بسیار مقرونبهصرفهتر است.3
۳. معماریهای افزونگی (Redundancy Architectures)
برای دستیابی به HA، از الگوهای معماری خاصی استفاده میشود که نحوه تعامل اجزای یدکی را تعریف میکنند.
۳.۱ الگوی Active-Passive (فعال-غیرفعال)
در این مدل، حداقل دو نود (سرور) وجود دارد. نود اولیه (Primary) تمام ترافیک را پردازش میکند، در حالی که نود ثانویه (Standby) در حالت آمادهباش قرار دارد و وضعیت نود اولیه را از طریق سیگنال «ضربان قلب» (Heartbeat) پایش میکند.
- مزایا: پیادهسازی ساده؛ عدم وجود تضاد دادهها زیرا تنها یک نود مینویسد.
- معایب: هدررفت منابع (نود ثانویه بیکار است)؛ زمان بازیابی (Failover) ممکن است چند ثانیه تا چند دقیقه طول بکشد.5
- کاربرد: پایگاههای داده رابطهای که همگامسازی بلادرنگ نوشتن در آنها دشوار است.
۳.۲ الگوی Active-Active (فعال-فعال)
در این پیکربندی، تمامی نودها به صورت همزمان فعال هستند و بار ترافیکی بین آنها توزیع میشود. اگر یک نود از مدار خارج شود، توزیعکننده بار (Load Balancer) ترافیک را به نودهای باقیمانده هدایت میکند.
- مزایا: بهرهوری ۱۰۰٪ از منابع؛ مقیاسپذیری خطی؛ زمان بازیابی نزدیک به صفر.
- معایب: پیچیدگی بالا در طراحی نرمافزار (باید Stateless باشد)؛ چالشهای همگامسازی دادهها در سیستمهای Stateful.5
- کاربرد: وبسرورها، اپلیکیشنسرورها، و میکروسرویسها.
۳.۳ الگوی N+1 و N+M
این الگو یک رویکرد بهینهسازی هزینه است. اگر $N$ تعداد سرورهای مورد نیاز برای پاسخگویی به اوج ترافیک باشد، معماری $N+1$ تنها یک سرور اضافه برای جایگزینی در صورت خرابی فراهم میکند. این روش بسیار ارزانتر از دو برابر کردن کامل سختافزار (2N) است که در مدلهای آینهای استفاده میشود.5
۴. کالبدشکافی توزیع بار (Load Balancing Mechanics)
توزیع بار، مکانیزمی است که ترافیک ورودی شبکه را به طور کارآمد بین مجموعهای از منابع پردازشی (سرورها) توزیع میکند. توزیعکننده بار (Load Balancer) به عنوان یک واسط هوشمند عمل کرده و مانع از اشباع شدن یک سرور خاص میشود.1
۴.۱ لایه ۴ در برابر لایه ۷: نبرد سرعت و هوشمندی
یکی از مهمترین تصمیمات در طراحی زیرساخت ابری، انتخاب لایه عملیاتی توزیع بار در مدل OSI است.
۴.۱.۱ توزیع بار لایه ۴ (لایه انتقال)
در این سطح، توزیعکننده بار تنها به هدرهای بسته IP و TCP/UDP نگاه میکند (آدرس IP مبدا و مقصد، و شماره پورت). محتوای بسته (Payload) بررسی نمیشود.
- مکانیزم: اغلب از تکنیک NAT (ترجمه آدرس شبکه) استفاده میکند. اتصال TCP مستقیماً بین کلاینت و سرور نهایی برقرار میشود و LB تنها بستهها را دستکاری و هدایت میکند.
- ویژگیها: سرعت بسیار بالا، سربار پردازشی کم، عدم توانایی در خواندن کوکیها یا URLها.
- کاربرد: سرویسهای استریم ویدیو، DNS، و پروتکلهای غیر HTTP.10
۴.۱.۲ توزیع بار لایه ۷ (لایه کاربرد)
این نوع LB، ترافیک را در لایه کاربرد (Application Layer) خاتمه میدهد. LB اتصال TCP را با کلاینت برقرار کرده، درخواست HTTP را کاملاً دریافت و رمزگشایی میکند (SSL Termination)، محتوا را تحلیل میکند و سپس یک اتصال جدید با سرور مقصد برقرار مینماید.
- مکانیزم: به عنوان یک پروکسی معکوس (Reverse Proxy) کامل عمل میکند.
- هوشمندی (Content Switching): میتواند بر اساس مسیر URL (مثلاً
/imagesبه سرورهای ذخیرهسازی و/apiبه سرورهای پردازشی)، کوکیها، یا نوع مرورگر کاربر تصمیمگیری کند. - کاربرد: وبسایتهای پیچیده، معماری میکروسرویس، تست A/B، و فایروالهای وب (WAF).10
جدول ۱: مقایسه فنی توزیع بار لایه ۴ و لایه ۷
| ویژگی | لایه ۴ (L4) | لایه ۷ (L7) |
| پروتکلها | TCP, UDP, SCTP | HTTP, HTTPS, gRPC, WebSocket |
| مبنای تصمیمگیری | IP و Port | URL, Host Header, Cookie, Body |
| مصرف منابع CPU | پایین (عملیات در سطح کرنل) | بالا (نیاز به Context Switching و SSL) |
| امنیت | فیلترینگ بسته (Packet Filtering) | WAF، جلوگیری از SQL Injection |
| کش کردن (Caching) | غیرممکن | امکانپذیر و بسیار موثر |
| پایداری نشست (Session) | فقط بر اساس IP | بر اساس کوکی و شناسه کاربر |
| منبع | 12 | 10 |
۵. الگوریتمهای توزیع بار: قلب تپنده مدیریت ترافیک
انتخاب الگوریتم مناسب برای توزیع ترافیک، تأثیر مستقیمی بر کارایی و تجربه کاربری (User Experience) دارد. این الگوریتمها به دو دسته کلی ایستایی (Static) و پویا (Dynamic) تقسیم میشوند.
۵.۱ الگوریتمهای ایستایی (Static)
۵.۱.۱ نوبتگردشی (Round Robin)
این سادهترین الگوریتم است که درخواستها را به ترتیب و به صورت چرخشی بین سرورها توزیع میکند.
- منطق: درخواست اول به سرور A، دوم به سرور B، سوم به سرور C، و چهارم دوباره به سرور A.
- چالشها: فرض میکند تمام سرورها قدرت یکسانی دارند و تمام درخواستها بار پردازشی برابری ایجاد میکنند. اگر یک درخواست سنگین به سروری برسد و درخواستهای بعدی نیز به همان سرور ارسال شوند، ممکن است گلوگاه ایجاد شود.14
۵.۱.۲ نوبتگردشی وزندار (Weighted Round Robin)
در این روش، به هر سرور یک «وزن» عددی اختصاص مییابد که نشاندهنده ظرفیت پردازشی آن است.
- کاربرد: زمانی که ترکیبی از سرورهای قدیمی و جدید در یک کلاستر وجود دارد. سروری با وزن ۳، سه برابر سروری با وزن ۱ درخواست دریافت میکند.14
۵.۱.۳ هش آیپی (IP Hash)
با استفاده از آدرس IP کلاینت و یک تابع ریاضی (Hash Function)، سرور مقصد تعیین میشود.
- مزیت اصلی: پایداری نشست (Sticky Session). کاربر همیشه به همان سرور متصل میشود که برای برنامههایی که وضعیت کاربر را محلی ذخیره میکنند (مانند سبد خرید قدیمی) حیاتی است.
- عیب: توزیع نامتوازن در صورتی که تعداد زیادی کاربر از پشت یک IP پروکسی سازمانی (NAT) وارد شوند.14
۵.۲ الگوریتمهای پویا (Dynamic)
۵.۲.۱ کمترین اتصالات (Least Connections)
این الگوریتم تعداد اتصالات باز (Open Connections) هر سرور را پایش کرده و درخواست جدید را به سروری میفرستد که کمترین اتصال فعال را دارد.
- تحلیل: این روش برای ترافیکهایی با طول عمر متغیر (مانند WebSocket یا دانلود فایل) بسیار کارآمدتر از Round Robin است، زیرا به طور خودکار از ارسال درخواست به سرورهای مشغول خودداری میکند.14
۵.۲.۲ کمترین زمان پاسخ (Least Response Time)
توزیعکننده بار به طور مداوم زمان پاسخگویی (Time to First Byte – TTFB) سرورها را اندازهگیری میکند و ترافیک را به سریعترین سرور هدایت مینماید.
- تحلیل: این روش بهترین تجربه کاربری را تضمین میکند و سرورهایی را که تحت فشار CPU هستند (حتی اگر تعداد اتصالات کمی داشته باشند) شناسایی کرده و از مدار خارج میکند.14
۶. کاربرد در وبسایتهای پرترافیک (High-Traffic Strategies)
برای وبسایتهایی که با مشکل C10k (مدیریت همزمان ۱۰ هزار اتصال) و فراتر از آن مواجه هستند، یک استراتژی چندلایه مورد نیاز است.
۶.۱ توزیع بار جغرافیایی (GSLB)
در مقیاس جهانی یا ملی، توزیع بار از سطح DNS آغاز میشود. با استفاده از تکنولوژی Anycast، چندین دیتاسنتر یک آدرس IP واحد را تبلیغ میکنند. شبکه اینترنت به طور خودکار کاربر را به نزدیکترین دیتاسنتر از نظر جغرافیایی و توپولوژی شبکه هدایت میکند. این امر تأخیر (Latency) را به حداقل رسانده و در صورت قطع شدن یک دیتاسنتر کامل، ترافیک به صورت خودکار به دیتاسنتر بعدی منتقل میشود.9
۶.۲ میکروسرویسها و توری سرویس (Service Mesh)
در وبسایتهای مدرن پرترافیک، معماری Monolithic به میکروسرویس شکسته میشود. در این حالت، نیاز به توزیع بار داخلی (East-West Traffic) است. ابزارهایی مانند Istio یا Linkerd در کلاسترهای Kubernetes، وظیفه توزیع بار بین هزاران کانتینر کوچک را بر عهده میگیرند که اغلب از الگوریتمهای هوشمندی مانند «کمترین درخواست» استفاده میکنند.27
۷. پیادهسازی عملی در ابرهای داخلی: مطالعه موردی «ابر آروان» (به عنوان زیرساخت منطبق با ابر دژ)
توضیح زمینه: در درخواست کاربر به «ابر دژ» اشاره شده است. بر اساس تحلیل بازار خدمات ابری ایران و مستندات موجود، عبارت «دژ» اغلب به عنوان استعارهای از امنیت سایبری (مانند دژفا) یا اشاره به شرکتهای پیمانکار زیرساختی (مانند دژپاد) به کار میرود، اما ارائهدهنده سرویس ابری عمومی (Public Cloud) با نام تجاری انحصاری «ابر دژ» که مستندات عمومی توزیع بار داشته باشد، کمتر شناخته شده است. با این حال، ابر آروان (ArvanCloud) به عنوان پیشروترین ارائهدهنده خدمات ابری در ایران، دقیقترین انطباق فنی را با نیازمندیهای مطرح شده (Load Balancing، HA، کانتینر ابری) دارد و در برخی متون فنی امنیت سایبری با مفاهیم «دژ» یا «سپر امنیتی» همپوشانی معنایی دارد. همچنین در مستندات 2 جزئیات کامل فنی این پلتفرم موجود است. لذا در این بخش، پیادهسازی بر روی پلتفرم ابر آروان به عنوان استاندارد پیادهسازی در ابرهای داخلی (یا همان مفهوم ابر دژ) تشریح میگردد.
۷.۱ پیشنیازهای معماری
برای راهاندازی یک سیستم HA در ابر آروان، به اجزای زیر نیاز دارید:
- سرورهای مبدا (Origin Servers): حداقل دو سرور ابری یا کانتینر که اپلیکیشن شما روی آنها اجرا میشود.
- دامنه فعال: متصل شده به شبکه توزیع محتوا (CDN) ابر آروان.
۷.۲ گام اول: تعریف استخر سرورها (Pools)
در پنل کاربری ابر آروان، مفهوم «استخر» (Pool) معادل گروهی از سرورهای همخانواده است.
- به بخش توزیع بار (Load Balancing) در تنظیمات CDN بروید.
- یک استخر جدید ایجاد کنید.
- انتخاب الگوریتم: در اینجا میتوانید روش توزیع بار را تعیین کنید.
- برای سرویسهای عمومی وب، گزینه Round Robin پیشنهاد میشود.
- اگر سرورهایی با قدرت متفاوت دارید، از Weighted Round Robin استفاده کنید و به سرورهای قویتر وزن بالاتری (مثلاً ۳ در برابر ۱) بدهید.28
۷.۳ گام دوم: پیکربندی سلامتسنجی (Health Check)
این حیاتیترین بخش برای HA است. بدون Health Check، لود بالانسر ترافیک را به سرورهای خاموش نیز ارسال میکند.
- در تنظیمات استخر، گزینه Active Health Check را فعال کنید.
- پروتکل: معمولاً HTTP یا HTTPS را انتخاب کنید تا از سلامت لایه اپلیکیشن مطمئن شوید (پینگ کردن صرفاً سلامت شبکه را نشان میدهد نه سالم بودن وبسایت).
- مسیر (Path): یک مسیر خاص مانند
/healthzیا/statusرا تعیین کنید. - کد وضعیت مورد انتظار: معمولاً
200یا200-299. - تواتر (Interval): زمان بین چکها را تعیین کنید (مثلاً هر ۱۰ ثانیه). اگر سروری ۳ بار متوالی پاسخ ندهد، از مدار خارج میشود (Unhealthy) و ترافیک آن بین سایرین تقسیم میشود.2
۷.۴ گام سوم: تنظیمات پیشرفته Active-Active و مسیریابی جغرافیایی
ابر آروان امکان توزیع بار جغرافیایی را فراهم میکند که برای وبسایتهای ملی بسیار مفید است.
- میتوانید چندین استخر تعریف کنید (مثلاً «استخر تهران» و «استخر تبریز»).
- با استفاده از قابلیت Geo-Steering، ترافیک کاربران هر استان یا کشور را به نزدیکترین استخر هدایت کنید.
- در حالت Active-Active، تمام استخرها فعال هستند. اگر استخر تهران از کار بیفتد، ترافیک آن به صورت خودکار به استخر تبریز منتقل میشود (Failover).2
۷.۵ گام چهارم: مقیاسپذیری خودکار (Auto-Scaling) با کانتینر ابری
برای مدیریت نوسانات ناگهانی ترافیک (Flash Crowds)، استفاده از سرورهای ثابت کافی نیست. سرویس کانتینر ابری ابر آروان (PaaS) امکان اتصال مستقیم به لود بالانسر را دارد.
- اپلیکیشن خود را در قالب کانتینر دیپلوی کنید.
- قوانین Horizontal Pod Autoscaling را تنظیم کنید: “اگر مصرف CPU از ۷۰٪ بیشتر شد، یک کانتینر جدید (Pod) اضافه کن.”
- سیستم به صورت خودکار کانتینر جدید را به لود بالانسر معرفی میکند. این فرآیند بدون دخالت انسانی انجام شده و پس از فروکش کردن ترافیک، کانتینرهای اضافی حذف میشوند.27
۸. نتیجهگیری و چشمانداز
تحلیل مفاهیم دسترسپذیری بالا و توزیع بار نشان میدهد که این دو تکنولوژی، ستونهای اصلی هر زیرساخت ابری مدرن هستند. در حالی که HA تضمین میکند سرویس در برابر خرابیها مقاوم است، LB ابزار اجرایی این تضمین است که ترافیک را هوشمندانه مدیریت میکند.
برای کسبوکارهای ایرانی که بر بسترهای داخلی نظیر ابر آروان (یا زیرساختهای امنیتی موسوم به ابر دژ) فعالیت میکنند، استفاده از ترکیب الگوریتمهای پویای توزیع بار (مانند Least Connections برای سرویسهای پایدار و Round Robin برای میکروسرویسها) همراه با استراتژیهای Active-Active و مقیاسپذیری خودکار کانتینری، تنها راه تضمین پایداری در برابر ترافیکهای سنگین و حملات سایبری است. گذار از معماریهای سنتی تکسروری به معماریهای توزیعشده چندنقطهای، دیگر یک انتخاب لوکس نیست، بلکه شرط لازم برای بقا در اکوسیستم دیجیتال امروز است.
