هنگامی که یک سرویس با شکست مواجه می شود، شکست معمولاً ناشی از چیزی است که معماری فرض می کند هرگز شکست نخواهد خورد. به همین دلیل است که کسب‌وکارهایی که به عملکرد قوی، بازیابی قابل پیش‌بینی و کنترل دقیق‌تر زیرساخت نیاز دارند، اغلب فراتر از اتکای کامل به ابر هستند. اگر انعطاف پذیری برای عملیات شما اهمیت دارد، تحمل خطا باید در خود سیستم طراحی شود، نه اینکه به مدل در دسترس بودن یک پلت فرم واحد واگذار شود.
معماری مقاوم به خطا به چه معناست؟
معماری مقاوم در برابر خطا به گونه ای طراحی شده است که در صورت خرابی یک یا چند جزء به کار خود ادامه دهد. به جای اینکه مشکل سرور، خطای حافظه، خطای نرم افزار یا قطع شبکه باعث شود کل سرویس قطع شود، سیستم مشکل را جدا می کند و عملکردهای حیاتی را در دسترس نگه می دارد.
بدون وابستگی به ابر، این رویکرد طراحی سنجیده تر می شود. برای سرپوش گذاشتن بر شکست، کاملاً به انتزاعات مدیریت شده تکیه نمی کنید. شما تاب آوری را مستقیماً در محاسبات، ذخیره سازی، شبکه، طراحی اپلیکیشن و برنامه ریزی بازیابی ایجاد می کنید.
نقاط منفرد شکست را حذف کنید
قانون اول ساده است. اگر یک ماشین، یک مسیر شبکه، یک دستگاه ذخیره سازی یا یک سایت بتواند کل سرویس را قطع کند، معماری هنوز شکننده است.
ما ایجاد افزونگی در مهمترین لایه ها را توصیه می کنیم:
- حساب میکنم
- ذخیره سازی
- شبکه
- پایگاه داده
- DNS
- پشتیبان گیری و بازیابی
این سطح پایه تحمل خطا است. یک جزء آسیب دیده نباید به توقف کار تبدیل شود.
نکته: افزونگی تنها زمانی کار می کند که هر مسیر پشتیبان واقعا مستقل باشد.
خدمات را بین مکان ها توزیع کنید
سرورهای اضافی در یک مرکز مفید هستند، اما خطر در سطح سایت همچنان وجود دارد. اگر همه چیز در یک مکان باشد، مشکل مسیریابی، رویداد برق یا قطع مرکز داده همچنان می‌تواند بر سرویس کامل تأثیر بگذارد.
توزیع بارهای کاری بین مکان های فردی شعاع شکست را کاهش می دهد. این ممکن است به معنای استفاده از قفسه‌ها، امکانات یا شهرهای مختلف بسته به بار، مشخصات ترافیک و هدف بازیابی باشد. برای کسب‌وکارهایی که کاربران منطقه‌ای دارند، برنامه‌ریزی مکان همچنین از تأخیر کمتر و تداوم بهتر در همان زمان پشتیبانی می‌کند.
از داده ها محافظت کنید، نه فقط زمان کار
سرورهای برنامه اغلب می توانند به سرعت جایگزین شوند. بازیابی از دست دادن داده ها، فساد یا شکاف های تکراری بسیار دشوارتر است. به همین دلیل است که طراحی مقاوم در برابر خطا باید شامل استراتژی های قوی حفاظت از داده ها باشد، نه فقط محاسبات اضافی.
توصیه می کنیم ترکیب کنید:
- پایگاه داده های تکراری
- ذخیره سازی اضافی
- پشتیبان گیری معمولی
- روش های ترمیم آزمایش شده و آزمایش شده
در دسترس بودن بدون داده های قابل بازیابی پایداری نیست. این فقط تداوم جزئی است.
نکته: پشتیبان گیری یک استراتژی بازیابی نیست تا زمانی که بازیابی آزمایش شود.
از جداسازی خطا برای جلوگیری از شکست آبشاری استفاده کنید
بسیاری از اختلالات کوچک شروع می شوند. یک سرویس کند می شود، تلاش های مجدد افزایش می یابد، صف ها ایجاد می شوند و سیستم های بالادستی ناپایدار می شوند. در عرض چند دقیقه، یک مشکل محلی در سراسر محیط پخش می شود.
جداسازی عیب چیزی است که این واکنش زنجیره ای را متوقف می کند. جداسازی بارهای کاری، محدود کردن تلاش های مجدد، اجرای مهلت های زمانی، و جداسازی سرویس های حیاتی به محدود کردن آسیب کمک می کند. هدف جلوگیری از هر شکستی نیست. هدف این است که یک شکست خیلی زیاد نباشد.
سیستم را در زمان واقعی نظارت کنید
نظارت به شما می گوید که چیزی شکست خورده است. مشاهده‌پذیری به شما کمک می‌کند بفهمید چرا شکست خورده و مشکل در کجا گسترش می‌یابد.
در محیط های توزیع شده، این مهم است زیرا علائم قابل مشاهده اغلب به دور از علت اصلی ظاهر می شوند. معیارها، گزارش‌ها، ردیابی‌ها و نمایان بودن وابستگی از تجزیه و تحلیل و بازیابی ریشه‌ای سریع‌تر پشتیبانی می‌کنند. بدون این لایه، تیم ها اغلب به جای حل مشکل واقعی به نویز واکنش نشان می دهند.
نکته: اگر نتوانید جریان خطاهای سرویس را ردیابی کنید، بازیابی همیشه بیشتر طول می کشد.
ظرفیت ارتفاع را حفظ کنید
اگر سیستم های باقیمانده نتوانند پس از خرابی بار را تحمل کنند، افزونگی ضعیف است. اگر گره های سالم از قبل به ظرفیت نزدیک باشند، یک جزء از دست رفته همچنان می تواند باعث اختلال در سرویس شود.
محیط‌های مقاوم به خطا به محاسبات، پهنای باند و عملکرد ذخیره‌سازی اضافی نیاز دارند تا جهش‌ها، خرابی‌ها و تقاضای غیرمنتظره را برآورده کنند. این یکی از دلایلی است که کیفیت زیرساخت در پروژه های غیر وابسته به ابر اهمیت زیادی دارد. ریکاوری برای کار به فضا نیاز دارد.
Dataplugs از این نیازهای انعطاف پذیری با راه حل های سرور اختصاصی در هنگ کنگ، توکیو و لس آنجلس پشتیبانی می کند که توسط سخت افزار کلاس سازمانی، اتصال جهانی BGP، گزینه های بهینه شده برای CN2 و پشتیبانی فنی 24/7 پشتیبانی می شود. این به کسب و کارها زیرساخت قوی تری برای در دسترس بودن، تداوم و بازیابی کنترل شده می دهد.
قبل از اینکه شکست شما را آزمایش کند تست کنید
نمودارهای معماری اغلب قوی به نظر می رسند تا زمانی که یک حادثه واقعی شکاف ها را آشکار کند. به همین دلیل است که آزمایش به اندازه طراحی مهم است.
ما اعتبار سنجی را توصیه می کنیم:
- رفتار شکست
- بازیابی نسخه پشتیبان
- مدیریت تراکم ترافیک
- بازیابی پایگاه داده
- واکنش رد وابستگی
قوی ترین سیستم ها آنهایی نیستند که هرگز شکست نخورند. آنها قبلاً تحت شرایط شکست کنترل شده آزمایش شده اند.
نتیجه گیری
برای طراحی معماری‌های مقاوم به خطا بدون وابستگی به ابر، تمرکز باید بر حذف نقاط شکست، توزیع ریسک، حفاظت از داده‌ها، جداسازی خطاها، تقویت قابلیت مشاهده و آزمایش مسیرهای بازیابی از قبل باشد. انعطاف‌پذیری واقعی از انتخاب معماری ناشی می‌شود که همچنان در هنگام خرابی سخت‌افزار، تحلیل رفتن شبکه‌ها، یا در دسترس نبودن محیط، پابرجاست.
برای کسب‌وکارهایی که خواهان کنترل بیشتر بر زمان، بهره‌وری و تداوم هستند، زیرساخت‌های اختصاصی می‌تواند بخشی قوی از این استراتژی باشد. Dataplugs سرورهای اختصاصی و راه‌حل‌های میزبانی را ارائه می‌کند که برای پشتیبانی از استقرار انعطاف‌پذیر با سخت‌افزار درجه یک سازمانی، اتصال شبکه قوی و پشتیبانی عملیاتی 24/7 طراحی شده‌اند.
برای اطلاعات بیشتر، به Dataplugs مراجعه کنید یا با sales@dataplugs.com تماس بگیرید.
