آنچه امروز می خواهم به اشتراک بگذارم این است که چه نوع استراتژی های بازیابی فاجعه را می توانیم در محیط ابری AWS استفاده کنیم.
در مورد استراتژی های بازیابی فاجعه صحبت کنید و در مورد گزینه ها صحبت کنید
ما بازیابی فاجعه را در فضای ابری به صورت زیر انجام خواهیم داد
شما باید به اطلاعات نزدیک باشید.
- پشتیبان گیری بازیابی
- چراغ خلبان
- آماده باش گرم
- چند سایت (فعال/فعال)
قبل از اینکه در مورد گزینه های بالا به شما بگویم، ابتدا
من می خواهم فاجعه را در رابطه با IT توضیح دهم.
از نظر محیط غیر فناوری اطلاعات، فاجعه به معنای باد است، سیل کنار آتش همه ما قبلاً از آسیب ناشی از نفرت می دانیم. در این مناطق زیست محیطی طرح های بازیابی بلایا وجود دارد. تیم های نجات غریق، نجات و غیره چگونه می توان از بلایای طبیعی در زندگی واقعی جلوگیری کرد؟ اگر اتفاق بیفتد چه باید کرد؟ همچین چیزی
بنابراین، بیایید به IT برگردیم. در جامعه فنی ما، فاجعه زمانی است که محیط‌هایی که ما مدیریت می‌کنیم، مانند نرم‌افزار و زیرساخت‌ها، به دلیل چیزی از کار می‌افتند (مثلاً: خرابی ژنراتور DC، خرابی پیوند شبکه، و خرابی منطقه‌ای در ابر) داشتن یک طرح بازیابی بلایا ضروری است. نکته اصلی این است که چگونه زمانی که از کار افتاده اید ریکاوری کنید.
سپس فرض می کنم که فاجعه را درک کرده ام. بنابراین، چهار (2) اصطلاح وجود دارد که باید در صورت وقوع فاجعه بدانید.
RTO و RPO دو اصطلاح به نام وجود دارد
(1). مخفف RTO Recovery Time Objective است، و اگر باید تعریف را به زبان برمه ای درک کنید، واضح ترین راه برای بیان آن این است که توضیح دهید پس از اتمام Down چقدر طول می کشد تا بازیابی شود. به عنوان مثال، اگر 1 Hour RTO در الزامات پروژه ذکر شده باشد، مشخص می کنیم که سیستم باید ظرف یک ساعت پس از از کار افتادن سیستم بازیابی شود. اگر ظرف یک ساعت خراب شود، ممکن است طبق SLA (توافقنامه سطح خدمات) بازپرداخت شود. در مورد SLA بعدا توضیح خواهم داد.
(2). RPO مخفف Recovery Point Objective است، و اگر آن را به زبان برمه ای بگوییم، مانند تعیین میزان از دست دادن داده های سیستممان است. به عنوان مثال، اگر RPO را 8 ساعت یا کمتر تنظیم کنیم، به این معنی است که می توانیم 8 ساعت از دست دادن اطلاعات را بپذیریم. اصلی‌ترین چیزی که می‌خواهم بگویم این است که می‌توانید داده‌هایی را که در 8 ساعت قبل از زمان خاموشی بوده از دست بدهید. به عنوان مثال، فرض کنید سیستم در ساعت 10 صبح روز 10 پایین می‌آید، منظور ما این است که ما در ساعت 2:00 صبح روز دهم یک نسخه پشتیبان داریم. بنابراین باید داده ها را بین (2) صبح تا (10) صبح از دست بدهیم. بعد فکر کنم دیدمش بنابراین، اگر می خواهید یک RPO 1 ساعته داشته باشید، باید هر ساعت یک نسخه پشتیبان تهیه کنید.
اگر این همه است، امیدوارم RTO و RPO را درک کرده باشید.
بنابراین، تکنسین های ما، به ویژه مهندسان سیستم، DevOps، مهندسان ابر، و معماران ابری
هر بار می خواهیم یک سیستم خاص را پیاده سازی کنیم و یک معمار انجام دهیم
سیستم ما به چه مقدار RTO نیاز دارد؟ نحوه تنظیم RPO به اهمیت سیستم شما بستگی دارد.
برای سیستم های کاملاً حیاتی (مانند بانکی، پزشکی و غیره)، RTO و RPO برای مدت زمان کوتاهی تنظیم می شوند. کسب‌وکارهای متوسط، مانند کسب‌وکارهای کوچک، باید برای مدت طولانی از کار بیفتند.
بسته به شرایط RTO و RPO، هزینه گزینه های بازیابی کمی متفاوت خواهد بود. من این گزینه ها/استراتژی بازیابی را در قسمت بعدی (2) ارائه خواهم کرد.
امیدوارم همه منتظر بمانند و بخوانند.
اگر همه آن را دوست دارید، می توانید لایک کنید و به اشتراک بگذارید، نظر بدهید…
کاانگ تانت لوین
AWS Community Builder
میانمار
