اجرای برنامه های کاربردی حیاتی در فضای ابری با استراتژی و معماری مناسب امکان پذیر است. بسیاری از سازمانها که زیرساختهای خود را مدیریت میکنند سعی کردهاند محیطهای کاربردی با دسترسی بالا (HA) ایجاد کنند – که در آن برنامهها حداقل 99.99٪ مواقع در دسترس خواهند بود – با استفاده از چندین سرور یا ماشینهای مجازی (VMs) که بهعنوان یک خوشه شکستی پیکربندی شدهاند. برای مثال، اگر گره خوشهای که یک برنامه کاربردی حیاتی را اجرا میکند، از کار بیفتد، یک گره ثانویه در خوشه شکستخورده میتواند در یک لحظه کنترل را به دست بگیرد و از جایی که گره دیگر متوقف شده است ادامه دهد.
شبکه منطقه ذخیرهسازی
چنین خوشههای شکستی معمولاً برای ذخیرهسازی دادههای مشترک به یک شبکه منطقه ذخیرهسازی (SAN) متکی هستند. اما یک SAN مشترک خود یک نقطه شکست واحد را تشکیل می دهد که می تواند دسترسی بالا را به خطر بیندازد. اگر SAN از کار بیفتد، پایگاه داده SQL Server یا Oracle که از سیستمهای مهم ماموریت شما پشتیبانی میکند، در دسترس نیست، و مهم نیست که چه تعداد گره در خوشه failover آماده تعامل با آن هستند.
برای سازمانهایی که ابر را برای یک محیط برنامه HA در نظر میگیرند، یک مشکل مهمتر وجود دارد: در حالی که برخی از فروشندگان ابر گزینههای ذخیرهسازی مشترک را ارائه میدهند، همه گزینهها 99.99٪ در دسترس بودن را تضمین نمیکنند.
آیا این بدان معناست که باید ابر را به عنوان گزینه ای برای محیط برنامه HA رها کنید؟ نه: این فقط به این معنی است که شما باید در مورد نحوه پیکربندی یک خوشه شکست مجدد فکر کنید.
درک دسترسی بالا در فضای ابری
اولین چیزی که در مورد ابر باید فهمید این است که چرخش و پیکربندی ماشین های مجازی جدید بسیار آسان است. در واقع، Azure، AWS، و Google همگی ایجاد خوشههای با قابلیت دسترسی بالا متشکل از ماشینهای مجازی متعددی را که در مراکز داده مختلف اجرا میشوند، آسان میکنند – که بهعنوان مناطق یا مناطق در دسترس نیز شناخته میشوند. با پیکربندی ماشین های مجازی خود در چندین منطقه، خطر این که یک فاجعه در سطح منطقه می تواند تمام زیرساخت های حیاتی شما را از بین ببرد را از بین می برد.
اما اگر قراردادهای سطح سرویس (SLA) را از ارائه دهندگان اصلی ابر بخوانید، متوجه یک هشدار مهم خواهید شد: اگر خوشه HA خود را با ماشین های مجازی در چندین منطقه پیکربندی کنید، SLA ها تضمین می کنند که حداقل می توانید به آن دسترسی داشته باشید. حداقل 99.99 درصد مواقع یکی از آن گره هاست. این تضمین نمی کند که برنامه شما کاربردی باشد، فقط می توانید به یکی از VM ها دسترسی داشته باشید.
این یک تمایز مهم است که به مشکل SAN بازمی گردد: اگر برنامه های شما نتوانند به داده های شما دسترسی داشته باشند، مهم نیست که به چند ماشین مجازی دسترسی داشته باشید.
داده ها را به اشتراک بگذارید، نه فضای ذخیره سازی
این ما را به موضوع بازنگری در نحوه پیکربندی یک خوشه شکست در فضای ابری بازمی گرداند.
اگر انتظار دارید که هر VM در خوشه شکست مبتنی بر ابر شما بتواند در صورت خرابی بارهای کاری تولید شما را به عهده بگیرد – و به همین دلیل است که برای شروع یک راه حل HA را به کار گرفته اید – باید هر VM را در پیکربندی کنید. خوشه failover شما با فضای ذخیره سازی خودش. علاوه بر این، شما به مکانیزمی نیاز دارید که به طور فعال داده های موجود در ذخیره سازی گره خوشه فعال را به گره های ثانویه تکرار کند. به این ترتیب، اگر ماشین مجازی فعال به هر دلیلی آفلاین شود، خوشه میتواند به یک ماشین مجازی ثانویه که تمام دادههای مورد نیاز برای فعال کردن برنامه شما را برای بازگشت آنلاین در عرض چند ثانیه دارد، شکست بخورد.
بهترین راه حل های سازمانی
راه حل های متنوعی برای تکثیر داده ها وجود دارد که می تواند خدماتی را که سازمان شما برای اطمینان از در دسترس بودن واقعی برنامه در یک استقرار مبتنی بر ابر به آن نیاز دارد، ارائه دهد. برای شروع، به دنبال خدمات تکرار همزمان، در سطح بلوک باشید. سرویسهای همزمان تضمین میکنند که هر تراکنش نوشته شده در ذخیرهسازی در سیستم اصلی، قبل از اینکه تراکنش کامل در نظر گرفته شود، در سیستمهای ثانویه نیز نوشته میشود. سرویسهای تکرار در سطح بلوک نیز مهم هستند، زیرا تضمین میکنند که هر دادهای که در فضای ذخیرهسازی اولیه نوشته میشود در حافظه ثانویه نیز تکرار میشود. اگر زیرساخت ابری اصلی شما از بیش از یک برنامه پشتیبانی میکند یا اگر از آن ذخیرهسازی بهعنوان یک مخزن برای چندین برنامه استفاده میکنید، همه آن دادهها نه فقط دادههای مرتبط با پایگاه داده Oracle یا SQL Server شما – در زیرساخت ثانویه تکرار میشوند. اگر زیرساخت ثانویه به طور غیرمنتظره ای وارد سرویس شود، برای هر برنامه یا کاربر در دسترس خواهد بود.