دردسترس بودن بالا (HA) چیست؟
درعلم فناوری اطلاعات ، اصطلاح High Availability به سیستمی (شبکه ، سرور یا cluster و …) گفته می شود که برای جلوگیری از از دست دادن سرویس، با کاهش یا مدیریت خرابی ها و به حداقل رساندن زمان خرابی برنامه ریزی شده ، طراحی شده است. البته در محاسبات ، اصطلاح در دسترس بودن برای توصیف دوره زمانی موجود بودن سرویس و همچنین مدت زمان مورد نیاز سیستم برای پاسخگویی به درخواستی که توسط کاربر انجام شده است ، استفاده می شود. در دسترس بودن بالا کیفیت یک سیستم یا جزیی از سیستم است که سطح بالایی از عملکرد عملیاتی را برای مدت زمان مشخص تضمین می کند.
اندازه گیری در دسترس بودن
در دسترس بودن عموما به صورت درصدی بیان می شود که نشان می دهد از یک سیستم یا جز خاص در یک بازه زمانی مشخص، چه زمان در دسترس بودن انتظار می رود . معمولا این بازه ی زمانی سالانه است و هدف ایده آل در دسترس بودن 100% است اما چون تقریبا غیر قابل دستیابی است ، هدف در دسترس بودن 99.999 % بیان می شود. برای مثال سیستمی که 99٪ در دسترس بودن را در یک دوره یک ساله تضمین می کند ، می تواند تا 3.65 روز خرابی (1٪) داشته باشد.
در دسترس بودن بالا چه زمانی مهم است؟
هنگام راه اندازی سیستم های تولید قوی ، به حداقل رساندن زمان خرابی و قطع خدمات معمولاً از اولویت بالایی برخوردار است. صرف نظر از اینکه سیستم ها و نرم افزارهای شما چقدر قابل اعتماد هستند ، مشکلاتی ممکن است پیش بیاید که باعث کاهش عملکرد برنامه ها یا سرورهای شما شود اجرای در دسترس بودن بالا(HA) برای زیرساخت های شما یک استراتژی مفید برای کاهش تأثیر این نوع رویدادها است. سیستم های بسیار در دسترس (Highly Available Systems)می توانند به صورت اتوماتیک از خرابی سرور بازیابی شوند.
مدیریت در دسترس بودن بالا
در دسترس بودن بالا تنها با برنامه ریزی دقیق و نظارت مداوم حاصل می شود.یک نقطه شروع خوب برای برنامه ریزی در دسترس بودن بالا ، شناسایی خدماتی است که باید برای تداوم تجارت در دسترس باشند و آنهایی که باید در دسترس باشند.برای مثال خدماتی که برای سلامتی افراد و یا خدمات مالی افراد مورد استفاده قرار می گیرند، از اهمیت بالایی برخوردارند و در دسترس بودن همیشگی آن ها بسیار مهم است.
در مرحله بعد ، سیستم ها یا اجزای تشکیل دهنده هر سرویس را شناسایی کرده و نقاط احتمالی خرابی این سیستم ها را لیست کنید. هر نقطه از خرابی باید در ابتدا بررسی شود و یک پایه تحمل شکست ایجاد شود. برخی از سوالت اصلی برای پرسیدن در مورد نقاط معمول شکست عبارتند از:
- میزان استفاده از پهنای باند: سیستم شما چه در زمان اوج و چه در زمان بیکاری پهنای باند مصرف می کند؟ این اطلاعات را از روترهای مدیریت شده و تجزیه و تحلیل گزارش خدمات اینترنت اطلاعات (Internet Information Service) دریافت کنید. از آن برای برنامه ریزی برای تخصیص پهنای باند برای پیک های مصرف مانند ( روزهای شلوغ خرید و …) استفاده کنید .
- در دسترس بودن و قابلیت مشاهده HTTP: آیا شما درخواست های HTTP سیستم را به صورت داخلی ، به ازای هر ISP و هر موقعیت جغرافیایی کنترل می کنید؟ مشکلات مربوط به درخواست های داخلی می تواند به عنوان یک هشدار اولیه در مورد مشکلات ظاهری باشد. درخواستهای HTTP از شبکه های ISP را پیگیری کنید تا مشخص شود که آیا کاربران این شبکه ها می توانند به خدمات شما دسترسی پیدا کنند یا خیر و درخواستها را از مکانهای مختلف جغرافیایی رصد کنید تا اطمینان حاصل کنید که کاربران از هرجای دنیا قادر به استفاده از خدمات شما هستند.
- معیارهای عملکرد: آیا شما بر تعداد کاربرانی که از سایت شما بازدید می کنند یا از برنامه های سازمانی شما استفاده می کنند ، نظارت می کنید و این تعداد را با تأخیر درخواست ها مقایسه می کنید؟ آیا سرورها را بر اساس عملکرد گروه بندی کرده اید و آیا ظرفیت دیسک و میزان ورودی و خروجی را کنترل می کنید؟
چه چیزی یک سیستم را HA قرار می دهد و چگونه انجام می شود؟
یکی از اهداف در دسترس بودن بالا ، از بین بردن نقاط خرابی در زیرساخت های شما است. یک نقطه خرابی ، یکی از اجزای پشته فناوری شما ست که در صورت عدم دسترسی ، باعث قطع سرویس می شود. به همین ترتیب ، هر جز لازم برای عملکرد مناسب برنامه شما که redundancy ندارد ، به عنوان یک نقطه خرابی در نظر گرفته می شود.
برای از بین بردن نقاط خرابی تکی ، هر لایه از پشته ی فناوری شما باید برای redundancy آماده شود. به عنوان مثال ، تصور کنید که یک زیرساخت متشکل از دو وب سرور مشابه و اضافی در load balancer دارید. ترافیکی که از سرویس گیرنده ها می آید به طور مساوی بین وب سرورها توزیع می شود ، اما اگر یکی از سرورها خراب شود ، load balancer تمام ترافیک را به سمت سرور آنلاین باقیمانده هدایت می کند.
لایه وب سرور در این حالت یک نقطه خرابی نیست بدلیل این که: مولفه های اضافی برای همان کار در جای خود قرار دارند و در این جا load balancer (توازن کننده بار) قادر به شناسایی خرابی در اجزا است.
یک سوال ممکن است پیش بیاید، اگر load balancer از حالت آفلاین خارج شود چه اتفاقی می افتد؟
در این حالت، لایه load balancer خود یک نقطه خرابی است و از بین بردن این نقطه شکست باقی مانده ، ممکن است سخت باشد. حتی اگربتوان برای دست یابی به redundancy به راحتی یک load balancer اضافی را پیکربندی کنید ، اما بالاتر از خود توازن کننده های بار، لایه ای داریم که بتواند تشخیص و بازیابی خرابی را انجام دهد؟
شناسایی و ریکاوری نقص برای سیستم های زائد می تواند با استفاده از یک رویکرد از بالا به پایین (top-to-bottom) انجام شود: لایه بالایی مسئول نظارت بر لایه ای که دقیقا در زیر آن قرار دارد، برای خرابی ها می شود. در حالتی که ما بررسی کردیم ، load balancer لایه بالایی است. اگر یکی از وب سرورها (لایه پایین) از دسترس خارج شود ، load balancer هدایت درخواست ها را برای آن سرور خاص متوقف می کند.
سناریوی لایه بالا به پایین
با چنین سناریویی ، رویکرد توزیع شده ضروری است. چندین گره اضافی باید به عنوان یک cluster به یکدیگر متصل شوند که در آن هر گره باید به همان اندازه توانایی شناسایی خرابی و بازیابی را داشته باشد.
ایجاد خوشه (cluster)
از چه نرم افزاری برای پیکربندی (HA) می توان استفاده کرد ؟
هر لایه از یک سیستم بسیار در دسترس از نظر نرم افزار و پیکربندی نیازهای متفاوتی خواهد داشت. با این حال در سطح برنامه ، میزان load balancer ها، یک نرم افزار اساسی برای ایجاد هرگونه تنظیم با قابلیت دسترسی بالا است. HAProxy (پروکسی با در دسترس بودن بالا) یک گزینه معمول برای تعادل بار است ، زیرا می تواند تعادل بار را در چندین لایه و انواع مختلف سرورها ، از جمله سرورهای پایگاه داده ، کنترل کند.
چه تفاوتی بین دسترسی زیاد (HA) و افزونگی (Redundancy) وجود دارد؟
افزونگی (Redundancy) به تنهایی نمی تواند در دسترس بودن زیاد (HA) را تضمین کند. یک سیستم همچنین به مکانیزم های شناسایی شکست نیاز دارد. توانایی انجام آزمایش در دسترس بودن بالا و ظرفیت انجام اقدامات اصلاحی هر زمان که یکی از اجزای پشته در دسترس نباشد نیز ضروری است. رویکردهای توزیع شده از بالا به پایین یا توزیع شده در دسترس بودن بالا می تواند موفقیت آمیز باشد و تکنیک های مبتنی بر سخت افزار یا نرم افزار برای کاهش زمان خرابی نیز موثر هستند. نکته این جاست که افزونگی یک رویکرد مبتنی بر سخت افزار است. از طرف دیگر ، اجرای استراتژی های در دسترس بالا تقریباً همیشه شامل نرم افزار است.
در دسترس بودن بالا (HA) در برابر تحمل خطا (Fault Tolerance)
در دسترس بودن بالا(HA) و تحمل خطا (Falut Tolerance) هر دو به تکنیک هایی برای ارائه سطح بالایی از زمان کار اشاره دارد. با این حال ، استراتژی های تحمل خطا در مقابل استراتژی های در دسترس بودن بالا، به طور متفاوتی به آن هدف می رسند. محاسبات تحمل خطا نیازمند افزونگی کامل در سخت افزار است. چندین سیستم همزمان برای دستیابی به تحمل خطا عمل می کنند ، به طور یکسان برنامه ها را معکوس می کنند و دستورالعمل ها را با هم اجرا می کنند. وقتی سیستم اصلی خراب شود ، سیستم دیگری باید بدون از دست دادن زمان کار ، سیستم را کنترل کند. برای دستیابی به محاسبات متحمل خطا ، به سخت افزار تخصصی نیاز دارید. این سیستم باید بتواند بلافاصله خطاهای موجود در اجزا را تشخیص داده و چندین سیستم را قادر سازد تا همزمان کار کنند.
دردسترس بودن بالا در مقابل تحمل پذیری خطا
در نهایت متوجه شدیم که در دسترس بودن بالا (HA) زیرمجموعه مهمی از مهندسی قابلیت اطمینان است ، که متمرکز بر این است که یک سیستم یا م مولفه از عملکرد عملیاتی بالایی در یک دوره زمانی مشخص برخوردار باشد. در نگاه اول ، اجرای آن کاملاً پیچیده به نظر می رسد. با این حال ، این می تواند مزایای فوق العاده ای برای سیستم هایی که به افزایش قابلیت اطمینان نیاز دارند ، به همراه داشته باشد.