چگونه برای High Availability طراحی کنیم؟

چگونه برای High Availability طراحی کنیم؟

در عصری که حضور دیجیتال برای تداوم کسب و کار حیاتی است، مفهوم دسترسی بالا (HA) به سنگ بنای طراحی سیستم تبدیل شده است. در دسترس بودن بالا به سیستم هایی اطلاق می شود که می توانند به طور مداوم بدون خرابی برای دوره های طولانی کار کنند. این مقاله تکامل دسترسی بالا، نحوه اندازه‌گیری، نحوه پیاده‌سازی آن در سیستم‌های مختلف و معاوضه‌های موجود در دستیابی به آن را بررسی می‌کند.

در دسترس بودن بالا – High Availability  چیست؟

مفهوم دسترسی بالا در دهه های 1960 و 1970 با سیستم های محاسباتی نظامی و مالی اولیه که نیاز به قابل اعتماد بودن و تحمل خطا داشتند، سرچشمه گرفت. در عصر اینترنت، انفجاری از برنامه های کاربردی دیجیتال برای تجارت الکترونیک، پرداخت، تحویل، امور مالی و موارد دیگر وجود داشته است. تجربیات مثبت کاربر برای موفقیت کسب و کار بسیار مهم است. این امر نیاز به سیستم هایی با تقریباً 100٪ آپتایم را تشدید کرد تا از دست دادن هزاران کاربر حتی برای دوره های کوتاه جلوگیری شود. به عنوان مثال، در طول یک رویداد فروش فلش تبلیغاتی، تنها یک دقیقه توقف می تواند منجر به شکست کامل و آسیب به شهرت شود. هدف دسترسی بالا این است که اطمینان حاصل شود که یک سیستم یا سرویس در نزدیک به 100٪ مواقع در دسترس و کارآمد است. در حالی که اصطلاحات در دسترس بودن بالا و زمان آپدیت گاهی اوقات به جای یکدیگر استفاده می شوند، در دسترس بودن بالا بیش از اندازه گیری زمان آپدیت را شامل می شود.

چگونه در دسترس بودن بالا – High Availability را اندازه گیری کنیم؟

دو مفهوم کلیدی برای محاسبه در دسترس بودن مرتبط هستند:

میانگین زمان بین خرابی ها (MTBF- Mean Time Between Failures) و میانگین زمان تعمیر (  Mean Time To Repair -MTTR).

MTBF و MTTR

MTBF قابلیت اطمینان سیستم را با جمع‌آوری زمان عملیاتی سیستم و تقسیم آن بر تعداد خرابی‌ها در آن دوره اندازه‌گیری می‌کند. معمولاً در ساعت بیان می شود. MTBF بالاتر نشان دهنده قابلیت اطمینان بهتر است. MTTR میانگین زمان مورد نیاز برای تعمیر یک جزء یا سیستم خراب و بازگشت آن به حالت عملیاتی است. این شامل زمان تشخیص، بازیابی قطعات یدکی، تعمیر واقعی، آزمایش و تایید عملکرد است. MTTR نیز معمولاً بر حسب ساعت اندازه گیری می شود. همانطور که در نمودار زیر نشان داده شده است، دو معیار دیگر مرتبط وجود دارد – MTTD (میانگین زمان تشخیص) و MTTF (میانگین زمان برای شکست). MTTR می‌تواند زمان تشخیص را در بر بگیرد.

The Nines

MTBF و MTTR با هم برای محاسبه در دسترس بودن سیستم حیاتی هستند. در دسترس بودن نسبت کل زمان عملیاتی به مجموع زمان عملیاتی و زمان تعمیر است.

استفاده از فرمول ها:

Availability=MTBFMTBF+MTTR

برای سیستم‌های با دسترسی بالا، هدف به حداکثر رساندن MTBF (شکست‌های کمتر) و به حداقل رساندن MTTR (بازیابی سریع از خرابی‌ها) است. این معیارها به تیم ها کمک می کند تا تصمیمات آگاهانه ای برای بهبود قابلیت اطمینان و در دسترس بودن سیستم بگیرند. همانطور که در نمودار زیر نشان داده شده است، در دسترس بودن محاسبه شده اغلب بر حسب “نه” مورد بحث قرار می گیرد. دستیابی به “3 نه” در دسترس بودن فقط 1.44 دقیقه در روز اجازه توقف می دهد – برای عیب یابی دستی چالش برانگیز است.

“4 nines” تنها به 8.6 ثانیه از کار روزانه اجازه می دهد که به نظارت خودکار، هشدارها و عیب یابی نیاز دارد.

این مورد نیازهایی مانند تشخیص خودکار خرابی و برنامه ریزی برگشت را در طراحی سیستم اضافه می کند.

Typical Architectures

برای دستیابی به در دسترس بودن “4 نه” و فراتر از آن، باید در نظر بگیریم:

۱- طراحی سیستم – طراحی برای شکست با استفاده از:

افزونگی – Redundancy

مبادلات – Tradeoffs

۲- عملیات سیستم و نگهداری – اصول کلیدی عبارتند از:

مدیریت تغییر – Change management

مدیریت ظرفیت تشخیص  – Capacity management

عیب یابی خودکار – Automated detection and troubleshooting

بیایید طرح های سیستم را با جزئیات بیشتری بررسی کنیم.

 Redundancy

فقط کارهای زیادی می‌توانیم انجام دهیم تا یک نمونه واحد را برای تحمل خطا بهینه کنیم. در دسترس بودن بالا اغلب با اضافه کردن افزونه ها به دست می آید. وقتی یک نمونه با شکست مواجه می شود، دیگران مسئولیت را بر عهده می گیرند. برای نمونه های حالت دار مانند ذخیره سازی، ما همچنین به استراتژی های تکثیر داده ها نیاز داریم. بیایید معماری های رایج با اشکال مختلف افزونگی و مبادلات آنها را بررسی کنیم.

Hot-Cold

در معماری hot-cold ، یک نمونه اولیه وجود دارد که همه خواندن و نوشتن از کلاینت‌ها و همچنین یک نمونه پشتیبان را مدیریت می‌کند. کلاینت ها فقط با نمونه اولیه تعامل دارند و از پشتیبان گیری بی اطلاع هستند. نمونه اولیه به طور مداوم داده ها را با نمونه پشتیبان همگام می کند. اگر اولیه شکست بخورد، مداخله دستی برای تغییر کلاینت ها به نمونه پشتیبان مورد نیاز است.

این معماری ساده است اما دارای معایبی است. نمونه پشتیبان نشان دهنده منابع هدر رفته است زیرا در بیشتر مواقع بیکار است. علاوه بر این، اگر اولیه از کار بیفتد، بسته به آخرین زمان همگام‌سازی، احتمال از دست رفتن داده وجود دارد. هنگام بازیابی از پشتیبان گیری، تطبیق دستی وضعیت فعلی لازم است تا مشخص شود چه داده هایی ممکن است از دست رفته باشند. این بدان معناست که مشتریان باید از دست دادن داده‌های احتمالی را تحمل کنند و اطلاعات از دست رفته را دوباره ارسال کنند.

Hot-Warm

معماری hot-cold  منابع را هدر می دهد زیرا نمونه پشتیبان مورد استفاده قرار نمی گیرد. معماری hot-warm  این را با اجازه دادن به مشتریان برای خواندن از نمونه ثانویه/پشتیبان بهینه می کند. اگر اولیه با مشکل مواجه شود، مشتریان همچنان می توانند از ثانویه با ظرفیت کاهش یافته بخوانند.

از آنجایی که خواندن از ثانویه مجاز است، سازگاری داده بین اولیه و ثانویه بسیار مهم است. حتی اگر نمونه اولیه به طور عادی کار کند، داده های قدیمی می توانند از خواندن برگردانده شوند زیرا درخواست ها به هر دو نمونه می روند. در مقایسه باhot-cold ، معماری hot-warm برای بارهای کاری سنگین مانند سایت های خبری و وبلاگ ها مناسب تر است. این مبادله حتی در طول عملیات معمولی به منظور استفاده موثرتر از منابع، خوانده می شود.

Hot-Hot

در معماری hot–hot، هر دو نمونه به عنوان اولیه عمل می کنند و می توانند خواندن و نوشتن را انجام دهند. این انعطاف پذیری را فراهم می کند، اما همچنین به این معنی است که نوشتن می تواند برای هر دو نمونه اتفاق بیفتد، که نیاز به تکرار حالت دو طرفه دارد. اگر داده‌های خاصی نیاز به ترتیب متوالی داشته باشند، این می‌تواند منجر به تضاد داده‌ها شود. به عنوان مثال، اگر شناسه‌های کاربر از یک دنباله تخصیص داده شوند، کاربر Bob ممکن است با ID 10 در نمونه A به پایان برسد، در حالی که کاربر Alice همان شناسه را از نمونه B تخصیص می‌دهد. معماری hot–hot زمانی بهترین عملکرد را دارد که نیازهای تکراری حداقل باشد، معمولاً شامل داده های موقت مانند جلسات و فعالیت های کاربر. در مورد داده هایی که به ضمانت سازگاری قوی نیاز دارند احتیاط کنید.

منبع : https://blog.bytebytego.com/