فرض کنید سرویس شما در نیمهشب از دسترس خارج میشود. چقدر طول میکشد تا متوجه شوید؟ چقدر طول میکشد تا مشکل را حل کنید؟ در این مدت چقدر درآمد یا اعتماد کاربران را از دست میدهید؟ High Availability (دسترسپذیری بالا) مجموعهای از تکنیکهاست که تضمین میکند سرویس شما حتی در صورت بروز مشکل، در دسترس بماند.
High Availability چیست؟
High Availability یا HA به توانایی یک سیستم برای ادامهٔ فعالیت در دورههای زمانی طولانی و با حداقل Downtime گفته میشود. HA معمولاً با درصدهایی مثل "۹۹٫۹۹٪" (چهار تا ۹) اندازهگیری میشود که به معنی کمتر از یک ساعت Downtime در سال است.
| Uptime درصد | Downtime مجاز در سال | مثال |
|---|---|---|
| ۹۹٪ (Two 9s) | ۳.۶۵ روز | سرویسهای غیرحساس |
| ۹۹٫۹٪ (Three 9s) | ۸.۷۶ ساعت | سرویسهای معمولی |
| ۹۹٫۹۹٪ (Four 9s) | ۵۲.۵ دقیقه | سرویسهای حساس |
| ۹۹٫۹۹۹٪ (Five 9s) | ۵.۲۶ دقیقه | سیستمهای حیاتی (بانک، مخابرات) |
تفاوت HA با Fault Tolerance
این دو مفهوم اغلب اشتباه گرفته میشوند:
- Fault Tolerance — سیستم میتواند یک خرابی را تحمل کند بدون این که هیچ تأثیری روی عملکرد ببیند. مثلاً دو سرور که دقیقاً یک کار را انجام میدهند و اگر یکی خراب شود، دیگری بدون لحظهای مکث ادامه میدهد.
- High Availability — سیستم در سریعترین زمان ممکن (چند دقیقه تا چند ساعت) پس از خرابی به حالت عادی برمیگردد. یک سرور Backup وجود دارد اما راهاندازی آن چند دقیقه طول میکشد.
Fault Tolerance گران و پیچیده است اما Downtime صفر دارد. HA هزینه کمتری دارد اما چند دقیقه Downtime قابل قبول است.
روشهای پیادهسازی HA
۱. Redundancy (افزونگی)
مهمترین اصل HA: هیچ تکنقطهای (Single Point of Failure) در سیستم وجود نداشته باشد. اگر یک سرور دارید، آن سرور تکنقطهٔ شکست است. اگر دو سرور دارید و یکی خراب شد، دومی کار را ادامه میدهد.
- سرورهای متعدد (Multi-Node)
- دیسکهای متعدد (RAID)
- اتصال اینترنت متعدد (Multi-Homing)
- منبع تغذیهٔ متعدد (Dual PSU)
۲. Failover و Automatic Recovery
اگر سرور اصلی خراب شد، به صورت خودکار به سرور Backup سوئیچ کنید. ابزارهایی مثل Keepalived، Pacemaker و Corosync این کار را انجام میدهند. در محیطهای ابری، سرویسهایی مثل Load Balancer با Health Check به صورت خودکار سرور خراب را از چرخه خارج میکنند.
۳. Clustering
چند سرور به صورت یک کلاستر کار میکنند. اگر یکی خراب شود، بقیه کار را ادامه میدهند. بانکهای اطلاعاتی مثل PostgreSQL و MySQL حالتهای Cluster مانند Primary-Replica و Multi-Master دارند.
۴. Geographic Redundancy
اگر کل یک دیتاسنتر (مثلاً در تهران) از دسترس خارج شد، دیتاسنتر دیگر (مثلاً در آلمان) کار را ادامه میدهد. این بالاترین سطح HA است و توسط CDNها و DNS Anycast پیادهسازی میشود.
الگوهای معماری HA
| الگو | توضیح | مثال |
|---|---|---|
| Active-Passive | یک سرور فعال، یک سرور آمادهبهکار. در صورت خرابی، سرویس به سرور دوم منتقل میشود | Keepalived + Floating IP |
| Active-Active | هر دو سرور همزمان فعالند و بار ترافیک بین آنها تقسیم میشود | Load Balancer + Multiple App Servers |
| Primary-Replica | دیتابیس اصلی (Primary) مینویسد، Replicaها میخوانند. در صورت خرابی Primary، یکی از Replicaها جایگزین میشود | PostgreSQL Streaming Replication |
| Multi-Region | سرویس در چند منطقهٔ جغرافیایی اجرا میشود | DNS Anycast + Global Load Balancer |
چالشهای HA
- هزینه — سرورهای اضافه، لایسنس، پهنای باند و نیروی متخصص هزینه دارد
- پیچیدگی — هرچه Redundancy بیشتر باشد، مدیریت سختتر است
- Split Brain — وقتی ارتباط بین سرورها قطع میشود و هر دو فکر میکنند دیگری خراب است و هر دو فعال میشوند
- دیتابیس — اطمینان از Consistency دادهها در حالت Multi-Node چالشبرانگیز است
نتیجهگیری
High Availability یک الزام است، نه یک گزینه لوکس. کاربران انتظار دارند سرویس شما همیشه در دسترس باشد و رقبای شما آمادهاند جای شما را بگیرند. برای شروع، تکنقاط شکست (Single Points of Failure) سیستم خود را شناسایی کنید و آنها را با Redundancy پوشش دهید. لازم نیست از روز اول Five 9s داشته باشید — از Active-Passive ساده شروع کنید و به تدریج به سطح بالاتر برسید.