آنچه در مقاله میخوانید
اگر صاحب یک وبسایت پربازدید، اپلیکیشن یا کسبوکار آنلاین هستید، احتمالا از خود پرسیدهاید که high availability چیست و چه کاربردی دارد؛ این مفهوم به معنای توانایی یک سامانه در ارائۀ خدمات پایدار، مداوم و با حداقل قطعی ممکن است، به طوری که اگر سرور یا قطعهای دچار نقص فنی شد، کسبوکار متوقف نشود و کاربران بدون احساس اختلال به خدمات خود دسترسی داشته باشند. در این مقاله قصد داریم به زبانی شفاف، استاندارد و کاربردی بررسی کنیم که High Availability چیست و چطور با تکنیک حیاتی Anti-Affinity میتوان از خاموشیهای ناگهانی سرورها و دیتابیسها جلوگیری کرد.
مفهوم دسترسیپذیری بالا و HA چیست؟
برای درک درست پایداری سیستم، ابتدا باید بررسی کنیم که معنای دقیق Ha چیست. واژۀ HA مخفف عبارت High Availability است و به راهکارهایی اشاره دارد که میزان در دسترس بودن یک سرویس را به بالاترین حد ممکن (نزدیک به ۱۰۰ درصد زمان کاری) میرسانند.
در این راستا، یک شبکه high availability به شکلی پیکربندی میشود که راههای ارتباطی و تجهیزات زیرساختی، مسیرهای موازی و جایگزین داشته باشند. اگر یکی از کابلها یا مسیرها قطع شود، بستۀ اطلاعاتی سریعاً از مسیر دوم عبور میکند تا اتصالات پایدار بمانند. پیادهسازی اصولی یک شبکۀ Redundancy در این لایه تضمین میکند که اختلال در یک سوئیچ، روتر یا درگاه ارتباطی هرگز به قطعی سرویس منجر نشود. سازمانها و کسبوکارهای آنلاین به خوبی میدانند ارزش عملیاتی high availability چیست؛ زیرا حتی چند دقیقه خاموشی ناخواسته میتواند اعتبار برند را زیر سوال ببرد، مشتریان را به سمت رقبا هدایت کند و زیان مالی زیادی به همراه بیاورد.
چرا سیستمها دچار قطعی میشوند و پیامد آن چیست؟
قطعی سرورها همیشه به خاطر باگهای برنامهنویسی نیست و عوامل مختلفی باعث ایجاد وقفه در سرویسها میشوند که از این عوامل میتوان به موارد زیر اشاره کرد:
- نقص فنی سختافزار: سوختن منبع تغذیه (پاور)، خرابی پردازنده یا سوختن حافظۀ رم.
- مشکلات ارتباطی و شبکه: بروز اختلال در روترها، سوییچها یا قطعشدن کابلهای دیتاسنتر.
- اشتباهات انسانی حین ارتقا: تغییرات اشتباه در تنظیمات یا آپدیتهای ناگهانی سیستمعامل.
- فجایع محیطی: نوسانات شدید برق یا خرابی سیستمهای خنککننده در سالن سرور.
زمانی که زیرساخت فاقد پایداری مناسب باشد، کاربر با خطاهای مختلف روبهرو میشود و سبد خرید یا خدمات بانکی متوقف خواهد شد. به همین علت، شناخت دقیق اینکه مزیت high availability چیست، امنیت خاطر مدیران فنی و ثبات مالی شرکتها را تضمین میکند.
به عنوان نمونه، شرکت متا (Meta / فیسبوک سابق) در ۴ اکتبر ۲۰۲۱ به دلیل یک خطای پیکربندی در روترها و پروتکل مسیریابی شبکه (BGP) که منجر به قطع ارتباط سرورهای DNS با کل اینترنت شد، نزدیک به ۶ ساعت دچار قطعی کامل و سراسری شد. در این حادثه تمامی پلتفرمهای اینستاگرام، واتساپ و فیسبوک از مدار خارج شدند و طبق گزارش تحلیلی موسسۀ Spanning، این شرکت حدود ۱۰۰ میلیون دلار از درآمدهای خود را از دست داد و همزمان میلیونها کاربر فعال به سمت پلتفرمهای رقیب مهاجرت کردند.
تفاوت High Availability با مفاهیم مجاور (FT ،DR و Backup)
در دنیای میزبانی سرور، مفاهیم متعددی برای حفظ بقای سیستم وجود دارند که گاهی با یکدیگر اشتباه گرفته میشوند. تعدادی از مهمترین این موارد عبارتاند از:
- تحمل خطا (Fault Tolerance): در سیستمهای تحمل خطا، هدف رسیدن به صفر ثانیه قطعی است. این کار نیازمند تکثیر ۱۰۰ درصدی تمام سختافزارها و اجرای موازی و لحظهای دستورات است که هزینۀ فوقالعاده سنگینی دارد و معمولاً فقط در تجهیزات حساس پزشکی یا سیستمهای هوانوردی اجرا میشود.
- بازیابی پس از بحران (Disaster Recovery): این مفهوم به برنامههای کلی یک شرکت برای نجات زیرساخت در زمان رخدادهای بسیار بزرگ (مثل سیل، زلزله یا تخریب کامل ساختمان دیتاسنتر) اشاره دارد.
- پشتیبانگیری (Backup): بکاپ یعنی تهیۀ یک نسخۀ کپی از دادهها در فواصل زمانی مشخص. اگرچه بکاپ برای بازگردانی اطلاعات مفید است، اما فرایند بازیابی آن زمانبر بوده و بلافاصله قطعی سرور را برطرف نمیکند.
در مقابل، معماری HA با مدیریت هوشمندانه خرابیهای معمول قطعات، سعی میکند قطعی را در کوتاهترین زمان ممکن و با هزینهای بسیار کمتر از سیستمهای Fault Tolerance مهار سازد.
معیارهای ارزیابی پایداری و جدول سطوح آپتایم
سطح پایداری هر سرور یا سرویس ابری بر مبنای درصدی از زمان دسترسپذیری در سال سنجیده میشود که به آن «تعداد ۹ها» (Nines) میگویند. جدول زیر مدت زمان مجاز خاموشی سرور را در طول یک سال برای سطوح مختلف نمایش میدهد:
| سطح دسترسیپذیری | حداکثر زمان قطعی مجاز در طول سال | نمونه کاربری عمومی |
| 99% | ۸۷ ساعت و ۴۰ دقیقه | سرورهای معمولی و پروژههای غیرحساس درونسازمانی |
| 99.9% (Three Nines) | ۸ ساعت و ۴۶ دقیقه | سرویسهای ابری عمومی و نرمافزارهای تجاری استاندارد |
| 99.99% (Four Nines) | ۵۲ دقیقه و ۳۶ ثانیه | فروشگاههای اینترنتی بزرگ و دیتاسنترهای تخصصی |
| 99.999% (Five Nines) | ۵ دقیقه و ۱۶ ثانیه | پلتفرمهای بانکی، خدمات اضطراری و مالی حساس |
در کنار این درصدها، مدیران زیرساخت برای سنجش سلامت سیستمها از ۴ معیار دیگر نیز استفاده میکنند:
- معیار MTBF: میانگین زمانی است که سیستم بدون هیچ نقصی به کار خود ادامه میدهد.
- معیار MTTR: میانگین زمانی است که تیم فنی برای برطرف کردن عیب و روشن کردن مجدد سرور نیاز دارد.
- معیار RTO: نشان دهندۀ بیشترین زمانی است که کسبوکار میتواند خاموش ماندن سیستم را تحمل کند بدون اینکه صدمه ببیند.
- معیار RPO: نشان دهندۀ حداکثر فاصلۀ زمانی مجاز برای از دست رفتن اطلاعات است؛ یعنی چه مقدار از آخرین اطلاعات ذخیرهنشده را میتوان نادیده گرفت.
4 رکن مهم در طراحی معماری پایدار high availability چیست؟
برای اینکه سیستم در مواجهه با خطا از کار نیفتد و دسترسیپذیری سرویس در بالاترین سطح ممکن حفظ شود، باید چند اصل زیرساختی و کلیدی در طراحی شبکه و سرورها پیادهسازی شود.
۱) حذف نقاط تکی شکست (Single Point of Failure – SPOF)
نقطۀ شکست تکی به هر قطعه، کابل، سوئیچ یا سروری گفته میشود که در صورت از کار افتادن، کل سرویس را متوقف میکند. در یک معماری اصولی، هیچ بخش حیاتی نباید منفرد باشد؛ از این رو برای تمام مسیرهای ارتباطی، منابع تغذیه و گرههای پردازشی، نسخۀ جایگزین و پشتیبان در نظر گرفته میشود تا خرابی یک بخش به از دست رفتن کل سیستم منجر نشود.
۲) پیادهسازی مدلهای افزونگی سختافزاری و نرمافزاری (Redundancy)
تجهیزات پشتیبان بر اساس حساسیت سرویس و بودجۀ زیرساخت به الگوهای متفاوتی چیدمان میشوند. در مدل N+1 همواره یک دستگاه رزرو در کنار مجموعهای از دستگاههای فعال قرار میگیرد تا بار دستگاه آسیبدیده را بر دوش بکشد. در سوی دیگر، در مدلهای حساسی مانند 2N کل ظرفیت پردازشی، ذخیرهسازی و ارتباطی سیستم به صورت موازی و دو برابر پیادهسازی میشود تا پایداری کامل تحت هر شرایطی تضمین شود.
۳) فعالسازی مکانیزم سوئیچ خودکار (Failover)
تنها وجود سرور پشتیبان کافی نیست، بلکه انتقال ترافیک کاربران به سرور دوم باید کاملاً خودکار و در کسری از ثانیه انجام پذیرد. سیستمهای مانیتورینگ و لود بالانسرها به محض تشخیص قطعی یا افت عملکرد نود اصلی، درخواستها را بدون نیاز به دخالت دستی اپراتور به گرههای سالم هدایت میکنند تا کاربر نهایی متوجه هیچگونه قطعی یا اختلال نشود.
۴) نظارت پیوسته بر وضعیت سلامت سرویسها (Heartbeat)
مکانیزم ضربان سیستم یا Heartbeat سیگنالهای دورهای و منظمی است که میان نودهای کلاستر رد و بدل میشود تا پاسخدهی و سلامت هر سرور را تأیید کند. در صورتی که ارسال یا دریافت این پالسها برای مدت مشخصی متوقف شود، سامانۀ وضعیت نود مورد نظر را بحرانی تلقی کرده و فرایندهای بازیابی یا جایگزینی خودکار را بلافاصله فعال میسازد.
قانون Anti-Affinity چیست و چرا برای ساخت HA واقعی الزامی است؟
فرض کنید برای دیتابیس خود دو ماشین مجازی با نامهای Master و Slave راهاندازی کردهاید تا اگر یکی خاموش شد، دیگری به کاربران سرویس دهد. اما اگر هر دو ماشین مجازی روی یک سرور فیزیکی واحد درون دیتاسنتر روشن باشند، چه اتفاقی میافتد؟ اگر مادربرد آن سرور بسوزد، هر دو نسخۀ دیتابیس به صورت همزمان از بین میروند و کل پایداری سیستم نابود میشود و اینجاست که نقش Anti-Affinity نمایان میشود.
به زبان ساده قانون Anti-Affinity نوعی دستور مدیریتی در نرمافزارهای مجازیسازی و کانتینری است. بر اساس این قاعده، نسخههای کپی یک سرویس هرگز نباید روی یک سختافزار، رک یا منبع برق مشترک قرار گیرند. بسیاری از تیمهای فنی دچار این خطای ذهنی میشوند که ساخت چند سرور مجازی به تنهایی پایداری سیستم را تضمین میکند؛ در حالی که بدون اعمال این جداسازی، تمام ماشینها عملا در یک سبد مشترک قرار دارند. به عنوان نمونه در پایگاههای داده، اجرای دقیق این قانون تضمین میکند نود اصلی روی سرور فیزیکی اول و نود کپی روی سرور فیزیکی دوم مستقر شود تا با خرابی یک هاست، کل سرویس از دسترس خارج نشود.
اگر قصد دارید محیطهای مجازیسازی خود را با بالاترین ضریب اطمینان راهاندازی کنید، تهیۀ سرور اختصاصی در رکها یا سالنهای دیتاسنتر مجزا، فضای مطمئنی را برای اجرای دقیق این قوانین فراهم میکند.
چگونه HA را در لایۀ اپلیکیشن و پایگاه داده پیاده کنیم؟
دسترسیپذیری بالا تنها به تجهیزات سختافزاری محدود نمیشود و برای پایداری کامل سرویس، باید لایههای نرمافزاری، پردازشی و ذخیرهسازی داده نیز همگام با آن ساختاردهی شوند. در این لایهها معمولاً از روشهای زیر استفاده میشود:
۱) خوشهبندی سرورها
با اجرای معماری کلاسترینگ سرور، چندین نود مجزا به یکدیگر متصل میشوند تا مانند یک سیستم واحد عمل کنند. در این حالت، بار پردازشی میان سرورها به اشتراک گذاشته میشود و در صورت از دست رفتن یکی از نودها، نودهای دیگر بدون وقفه وظایف آن را پوشش میدهند تا برنامه بدون قطعی به فعالیت خود ادامه دهد.
۲) توزیع هوشمندانۀ ترافیک ورودی
استفاده از ابزارهای لود بالانسینگ مانع از اشباع منابع یک سرور بر اثر هجوم درخواستها میشود. لود بالانسر با رصد وضعیت سلامت هر سیستم، ترافیک کاربران را به شکل متعادل بین سرورهای آمادهبهکار پخش میکند و به محض تشخیص نقص در یکی از نودها، درخواستهای جدید را به مقصدهای سالم تغییر جهت میدهد.
۳) همگامسازی بلادرنگ پایگاه داده
پایداری در لایۀ دیتابیس با تکنیکهای کپیبرداری داده (Replication) و خوشهبندی پایگاه داده محقق میشود. در این سناریو، دادههای ثبتشده بلافاصله میان نودهای مختلف همگامسازی میشوند تا در زمان از دسترس خارج شدن پایگاه داده اصلی، نسخۀ جایگزین بدون از دست رفتن اطلاعات یا وقفه در عملیات خواندن و نوشتن وارد مدار شود.
۴) انتقال پردازش و کش به لبۀ شبکه
در سناریوهای پایداری بالا، سرازیر شدن حجم عظیمی از درخواستها برای فایلهای ایستا نظیر تصاویر، فایلهای CSS و جاوا اسکریپت میتواند پهنای باند و منابع پردازشی سرور اصلی را اشباع کند و باعث قطعی سرویس شود. برای مهار این ریسک، محتوای ایستا روی مجموعهای از سرورهای لبه در سراسر جهان ذخیره میشود تا درخواست کاربران بدون درگیر کردن سرور اصلی پاسخ داده شود. این سازوکار علاوه بر شتاببخشی به لود صفحات، یک سپر امنیتی در برابر حملات سنگین و جهشهای ناگهانی ترافیک ایجاد میکند.
اگر با سازوکار فنی این شبکه و نحوۀ مسیریابی ترافیک آن آشنایی ندارید، پیشنهاد میکنیم برای بررسی دقیقتر عملکرد و مزایای آن، مقالۀ Cdn چیست را مطالعه کنید.
چکلیست بررسی سلامت و نگهداری مستمر زیرساخت
حتی بینقصترین زیرساختها نیز بدون مراقبت دائمی در امان نخواهند بود. برای تضمین دسترسیپذیری مداوم، این کارها را در اولویت قرار دهید:
- نصب ابزارهای نظارت دائمی: مصرف پردازنده، فضای دیسک، وضعیت شبکه و خطاهای سرویس را با ابزارهای مانیتورینگ زیر نظر بگیرید.
- آزمایش دورهای فرایند Failover: سناریوهای قطعی برق یا سرور را به صورت ساختگی تمرین کنید تا مطمئن شوید سوییچ خودکار بدون ایراد کار میکند.
- جدا کردن محیطهای کاری: کدهای آزمایشی و تستهای برنامهنویسی را هرگز روی سرورهای اصلی اجرا نکنید تا خطای انسانی کاهش یابد.
کلام آخر
با جمعبندی مباحث مطرحشده، مشخص میشود که هدف کلیدی high availability چیست؛ ساخت سامانهای قابل اعتماد که در صورت وقوع هرگونه خطای داخلی، بدون افت عملکرد به فعالیت خود ادامه دهد. ترکیب افزونگی در تجهیزات، توزیع هوشمندانه بار، نظارت مداوم و جداسازی هوشمند سرورها با قانون Anti-Affinity، همان زیربنای مستحکمی است که کسبوکار شما را ۲۴ ساعته و در ۳۶۵ روز سال در دسترس نگه میدارد.
منابع
سوالات متداول
شاید تفاوت آنها ناچیز به نظر برسد، اما در بازۀ یکساله، آپتایم ۹۹.۹٪ اجازۀ حدود ۸ ساعت و ۴۶ دقیقه قطعی را میدهد، در حالی که در آپتایم ۹۹.۹۹٪ این مقدار به کمتر از ۵۳ دقیقه در تمام طول سال محدود میشود.
خیر. بکاپ فقط یک فایل پشتیبان است که اگر سرور بسوزد، بازگرداندن آن ساعتها زمان میبرد، اما در High Availability، سرور دوم فوراً وظایف سرور خاموش را ادامه میدهد و کاربر اصلاً متوجه قطعی نمیشود.
این قانون تضمین میکند که سرور اصلی و سرور کمکی دیتابیس به هیچ وجه روی یک بستر فیزیکی قرار نگیرند، تا اگر سختافزار دچار حادثه شد، دیتای شما در دستگاه دوم سالم بماند.
