High availability یا به اختصار HA در شبکه به معنی تلاش برای بالا بردن سطح دسترسی پذیری و افزایش زمان uptime یک دستگاه است. یک دستگاه برای high available بودن، باید بتواند هنگام بروز مشکل، در سریع‌ترین زمان ممکن آن را شناسایی کند و اگر یک سرویس به این دلیل از دسترس خارج شده بود، برای آن جایگزینی داشته باشد و تا زمان رفع مشکل به درخواست‌های کاربران پاسخ بدهد. از آنجایی که امکان بروز یک مشکل در برنامه‌ی در حال اجرا، یا برای سرورهای سرویس دهنده همیشه وجود دارد، عملا مدت زمان uptime سرویس‌ها هیچ‌وقت 100% نخواهد بود. ولی هرچه این مقدار به 100 نزدیک‌تر باشد به این معنی است که سرویس ارایه شده پایدار‌تر است.
یکی از راه‌های پیاده‌سازی HA، استفاده از redundancy یا افزونگی است. به این معنی که برای هر سرویس ارایه شده، حداقل دو پشتیبان وجود داشته باشد. شیوه‌ی توزیع ترافیک بین دو پشتیبان می‌تواند متفاوت باشد. در یکی از معماری‌ها به نام active-active، هر دو پشتیبان به طور هم‌زمان ترافیک ورودی و درخواست‌های کاربران را دریافت میکنند و زمانی که یکی از آنها به هر دلیلی از دسترس خارج شود، تمام ترافیک تا زمانی که اشکال به وجود آمده برطرف شود، به پشتیبان دوم ارسال میشود. در مقابل، در معماری active-passive، در شرایط عادی تنها یکی از پشتیبان‌ها درخواست‌ها را دریافت میکند و پشتیبان دیگر در زمان بروز مشکل، جایگزین آن میشود که در حال حاضر Raja PAM از معماری active-passive استفاده می کند.
با استفاده از افزونگی از به جود آمدن تک نقطه‌ی شکست یا SPOF (single point of failure) جلوگیری میشود. وجود SPOF به معنی ساختار سیستم دستگاهی است که هیچ جایگزینی ندارد و اگر از دسترس خارج شود، برای مدتی سرویسی که ارایه میکند، قطع میشود. برای نمونه، شبکه‌ای از سرورها را در نظر بگیرید که در آن یک فایروال وظیفه‌ی کنترل ترافیک ورودی را برعهده دارد. اگر فایروال برای مدتی خاموش شود، احتمالا سرورها قادر به دریافت ترافیک ورودی یا حتی ارسال بسته نیستند و اگر چنین اتفاقی رخ دهد، حمله کردن به این سرورها بسیار راحت‌تر از قبل خواهد بود.
چرا high available بودن اهمیت دارد؟
همان‌طور که پیش‌تر بیان شد، HA بودن یک سرویس سبب میشود در زمان بروز مشکل‌های غیرقابل پیش‌بینی، سرویس دادن به کاربران هم‌چنان ادامه داشته باشد.
در رابطه با ذخیره کردن اطلاعات و نگهداری پایگاه‌های داده، این موضوع اهمیت بیشتری پیدا میکند. زمانی که یک سرویس دچار مشکل میشود، تا هنگامی که مشکل برطرف شود، به درخواست‌های کاربران پاسخ داده نمی‌شود. ولی زمانی که یک پایگاه داده از دسترس خارج میشود یا عملکردی مانند قبل ندارد، احتمالا اطلاعات و داده‌های کاربران تا زمان رفع مشکل ذخیره نخواهند شد. مشکل اساسی‌تر هنگامی اتفاق می‌افتد که تمام داده‌هایی که روی یک حافظه وجود دارند، از بین بروند. در این شرایط اگر این اطلاعات روی هیچ حافظه‌ی دیگری وجود نداشته باشند، به طور کلی از بین می‌روند و شاید دیگر قابل برگشت نباشند.
نحوه طراحی سیستم‌های High availability
در دنیای آمار و احتمال و ریاضی چیزی به اسم 100 درصد وجود ندارد. نمی‌توان انتظار داشت که در صددرصد مواقع حالتی مطلوبی رخ دهد. نمی‌توان تصور کرد که حتی یک ماشین تمامی وظایف خود را در 100 در 100 زمان به‌خوبی انجام دهد. غیرممکن است که در سیستم و سرویسی نمره 100 از 100 را در عملکرد آن ثبت کرد. مطلوب‌ترین حالت ممکن، نزدیک‌ترین عدد ممکن به صد خواهد بود که در High availability این عدد 99.999 است.
یعنی در دسترسی‌های سطح بالا انتظار می‌رود که به‌احتمال 1 هزارم امکان ازدست‌رفتن دسترسی وجود دارد. این رقم قابل‌قبول و حتی بسیار مطلوب بوده و تا میزان زیادی اطمینان و اعتماد به یک service را برآورده می‌سازد. اما برای رسیدن به آن، باید 3 نکته مهم و اساسی را در طراحی سیستم‌های HA در نظر داشت :
- نبود نقطه شکست یکتا
- Crossover قابل اعتماد
- تشخیص شکست
نبود نقاط شکست یکتا
منظور از نقاط شکست، اجزاء مختلفی از سیستم‌ها و سرویس‌ها بوده که در صورت خرابی و ازدست‌دادن آنها، کل سیستم سرویس از دسترس خارج خواهد شد. حال در طراحی سیستم‌های دسترسی بالا باید این نکته مهم را در نظر داشت که در کل سیستم نباید حتی یک نقطه شکست تنها وجود داشته باشد. یعنی اجزائی که نقطه شکست محسوب می‌شوند، حداقل باید ۲ عدد از آنها وجود داشته باشد .
برای مثال در شبکه (network) سازمان‌ها و شرکت‌ها، سرور یک نقطه شکست است. زیرا در صورت خرابی آن نتورکی وجود نخواهد داشت. از‌این‌رو در طراحی High availability یک شبکه باید از ۲ سرور (حداقل) استفاده کرد تا ریسک ازدست رفتن سیستم کاهش یابد.
Crossover معبر قابل‌اعتماد
معبر یا crossover مولفه‌ای است که به‌عنوان راه حل پشتیبان از آن یاد میشود. مانند استفاده از Y به‌جای X برای جلوگیری از آفلاین شدن سرویس یا سیستم در زمانی که X را از دست دهیم.
تشخیص شکست
دو نکته بالا برای جلوگیری از قطع دسترسی کامل سرویس‌ها در زمان شکست اجزاء بودند، درحالی‌که تشخیص شکست، بیشتر به‌منظور بهبود عملکرد HA استفاده میشود. یعنی در یک سرویس و سیستم باید شکست‌ها و خرابی‌ها قابل‌مشاهده باشند تا هم به‌سرعت تعمیر شوند و هم در آینده از وقوع دوباره آنها تاحدامکان جلوگیری کرد.
برای اطمینان از تحقق High availability، علاوه بر سه نکته مهم و اساسی ذکر شده، استفاده از سیستم متعادل‌کننده بار نیز در طراحی دسترسی بالا لازم است. زمانی که کاربران زیادی از سرویس ارائه شده استفاده میکنند، نیاز است تا حجم بالای درخواست‌ها دریافتی و پاسخ‌های ارسالی بر اساس منابع موجود متعادل شود.
نحوه کارکرد HA
PAM را در دو سرور مجزا deploy میکنیم. به pam اصلی لایسنس ha-master و به دومین سرور pam ،لایسنس ha-slave را اختصاص میدهیم.
نکته :HA Raja PAM از معماری active-passive استفاده می کند.
تنظیمات
به سرور pam master رفته:
از منوی side bar وارد setting شده سپس به بخش high availability میرویم.
- صفحه ی باز شده تنها یک قسمت دارد که با فشردن دکمه ی refresh یک secret code ساخته میشود.
به سرور pam slave رفته:
از منوی side bar وارد setting شده سپس به بخش high availability میرویم.
صفحه ی باز شده 5 آیتم دارد:
- Master URL Address: در واقع همان آدرس ip سرور pam master که بصورت -> Http://ip server master / data-service وارد میشود.
- Master Secret: همان Secret Code تولید شده را در این بخش می گذاریم.
- Sync Interval Minutes: چند ثانیه یکبار میخواهید pam slave با pam master همگام سازی شود؟
- High Availibility Sync Activate: برای انجام عملیات همکام سازی باید این گزینه فعال باشد.
- Last Sync AT: آخرین زمانی که PAM SLAVE و PAM MASTER همگام سازی شده است.
چگونگی کار
طبق Sync Interval Minutes که در قسمت pam slave انتخاب کردیم هر n ثانیه یک بار pam slave به pam master متصل می شود و اطلاعات را در پایگاه داده خود ذخیره میکند.
هنگامی که به هر دلیلی PAM Master از سرویسی ارائه ندهد PAM Slave جای آن را می گیرد و کاربران می توانند از PAM Slave بدون downtime از PAM استفاده نمایند.
