پایگاه خبری راه پرداخت دارای مجوز به شماره ۷۴۵۷۲ از وزارت فرهنگ و ارشاد اسلامی و بخشی از «شبکه عصر تراکنش» است. راه پرداخت فعالیت خود را از دوم اردیبهشتماه ۱۳۹۰ شروع کرده و اکنون پرمخاطبترین رسانه ایران در زمینه فناوریهای مالی، بانکداری و پرداخت و استارتآپهای فینتک است.
میتوان گفت برای کسبوکارها و کاربران حرفهای حوزهی فناوری، روشن است که استراتژی بازیابی پس از بحران DRaaS یک راهکار مهم برای تداوم در روزهای حادثههای غیرمنتظره شناخته میشود. آمارهای جهانی نشان میدهد که استفاده از Disaster Recovery به یک روند بینالمللی مهم تبدیل شده است و کسبوکارها از آن بهعنوان راهکاری برای تداوم در روزهای حادثههای غیرمنتظره استفاده میکنند. این راهکار در محصولات مختلفی مانند آبجکت استوریج، دیتابیس ابری، Cloud Security و… خود را به روشهای گوناگونی نشان میدهد.
به گزارش روابط عمومی آروانکلاد، اما آنطرف ماجرا، وقتی یک کسبوکار به اهمیت استفاده از DRaaS در زنجیره ارائه خدماتش آگاه شد، چگونه میتواند برای بهرهمندی از آن اقدام کند و شرکتهای ارایهدهنده این راهکار برای سادهسازی استفاده از DRaaS باید چه پیشنهادهایی داشته باشند؟ و درنهایت چه مسیر گامبهگامی برای بهرهمندی از چارچوبهای استاندارد (Well-Architected Framework) وجود دارد؟ برای پاسخ به همه این پرسشها نیاز است که یک برنامه منسجم برای استفاده از «بازیابی پس از بحران» یا همان DRP تعریف کرد. Disaster Recovery Plan همان برنامه منسجمی است که به کسبوکارها کمک میکند تا از راهکار Disaster Recovery استفاده کنند.
در ادامه مهمترین گامهای استفاده از DRP در سازوکار راهکار Disaster Recovery آروانکلاد خواهد آمد.
گام اول: آمادگی ذهنی کسبوکار و ذینفعان مهم
آموزش و آگاهیرسانی، نخستین گام برای کسبوکارها در آغاز استفاده از راهکار DRaaS است؛ به این ترتیب، آنها، فارغ از نوع صنعت و اندازهشان، باید مطمین شوند که همه کارکنان از نقش خود در برنامه DRP آگاه هستند. این مسئله تا آنجا مهم است که اختلالهای عملیاتی و مالی را کاهش میدهد؛ هرچه این آگاهی بیشتر باشد، احتمال اختلالها کمتر و درنهایت به حفظ اعتبار و اعتماد به کسبوکارها کمک میکند.
گام دوم: آگاهی نسبت به نیازهای کسبوکار در DRaaS
کسبوکارها در گام دوم این برنامه، باید نسبت به نیازهایشان در استفاده از راهکار «بازیابی پس از بحران» شفاف باشند. به این معنا که بدانند بهطور دقیق از Disaster Recovery چه میخواهد؟ پس این گام، دو سوی کلی دارد: یک سو؛ نقش یک شرکت ارائهدهنده محصولات ابری و در سوی دیگر؛ نقش کسبوکارهایی که میخواهند از DRaaS استفاده کنند، از جمله کسبوکارهای ارائهدهنده خدمات ابری مانند آروانکلاد، مسئولیت پایداری زیرساختهای فیزیکی و نرمافزاری ابر را در این زنجیره بهعهده دارند. بهعلاوه، مواردی مانند سلامت دیتاسنترها، پایداری شبکه، تامین برق و امنیت فیزیکی تجهیزات را هم در تعهداتشان تعریف میکنند.
کسبوکارها هم برای بهرهمندی از خدمات DRaaS باید نوعی معماری مقاوم برای برنامههای خود بر بستر زیرساخت ابری را تهیه کنند؛ مواردی مانند پشتیبانگیری منظم، انتخاب استراتژی DR مناسب برای هر سرویس و آزمون دورهای از آنها. بهعلاوه، این کسبوکارها باید به دو پرسش مهم هم پاسخ دهند: برای بازیابی دادهها تا چه میزان محدودیت زمانی دارند و تا کجا حاضرند که ریسک از دست دادن اطلاعات را بپذیرند؟ این دو هدف، هزینه و پیچیدگی برنامهریزی و استراتژی DR کسبوکارشان را تعیین میکند.
یک نمونه از نوع انتخاب استراتژیهای DRaaS در این جدول آمده است:
| RPO (هدف نقطهی بازیابی) | RTO (هدف زمان بازیابی) |
| بیشترین زمانی که برای از دست رفتن دادهها تصور میکنید. | بیشترین زمانی که سرویس شما میتواند قطع باشد. |
| راهنمای تصمیمگیری | |
| اگر پاسخ به پرسش بالا صفر ثانیه باشد، یعنی باید سازوکاری را انتخاب کرد که در لحظهای که دادهای ذخیره میشود، یک کپی همزمان از آن به محل پشتیبان منتقل شود. اگر پاسخ به این پرسش، برای نمونه، ۴ ساعت باشد، یعنی انتخاب میکنید که دادههای ۴ ساعت اخیر را از دست بدهید. این یعنی باید هر ۴ ساعت یک بار بکآپ بگیرید. | اگر پاسخ به پرسش بالا، ۵ دقیقه باشد، یعنی از لحظهی قطعی تا زمانیکه سایت دوباره دردسترس قرار بگیرد و کاربران دوباره بتوانند از خدمات شما استفاده کنند، نباید بیشتر از ۵ دقیقه طول بکشد. این مسئله نیاز به زیرساختهای همیشه روشن دارد. |
دربارهی تصمیمگیری این مساله (DRP) باید در نظر داشت که هرچه RPO و RTO سختگیرانهتر (یعنی نزدیکتر به صفر) باشند، استراتژی کسبوکار پیچیدهتر و هزینه پیادهسازی و نگهداری آن نیازمند هزینه بیشتری خواهد بود.
گام سوم: نوشتن گامبهگام نقشه DR کسبوکار
مورد اول؛ تعیین اهمیت نقش کسبوکار: کسبوکارها پیش از طراحی و تصمیمگیری درباره برنامه DR کسبوکار باید نقشهای از تأثیر کسبوکار (Business Impact Analysis) سازمان خود داشته باشند؛ یعنی به این نکته پاسخ داده شود که کدامیک از فرایندها برای کسبوکارشان حیاتیترین است؟ برای نمونه، فرایند تراکنشها، جزو ویژگیهای حیاتی یک کسبوکار مالی و بانکی بهشمار میآید و این کسبوکارها نمیتوانند ریسک توقف ثانیهای این نوع خدماتشان را بپذیرند.
مورد دوم؛ اولویتبندی سرویسهای کسبوکار: سرویسهایی که برای کسبوکار بیشترین اهمیت را دارد، باید در سه بخش «حیاتی»، «مهم» و «غیرضروری» دستهبندی و برای هر کدام از آنها یک هدف واقعبینانه از RTO و RPO مشخص شود. نوعی راهنمایی از شیوه اولویتبندی محصولات به این شرح است که حیاتی (Tier 1): محصول/سرویسی که نباید حتی یک دقیقه قطع شود. (مانند درگاه پرداخت برای کسبوکارهای مالی و بانکی)؛ مهم (Tier 2): محصول یا سرویسی که قطع شدنش ایرادی ندارد، اما باید در طول نیمساعت به چرخهی ارائه خدمت بازگردد. (مانند پنل مدیریت درون سازمان) و غیرضروری (Tier 3): محصول یا سرویسی که وصل شدن آن میتواند با تأخیر چند هفتهای باشد. (مانند سامانهی آرشیو سازمانی).
سپس باید محصولات را براساس شاخص RPO و RTO تقسیمبندی کرد. همانطور که بالاتر درباره تعریف این دو شاخص توضیح داده شده بود، باید در نظر گرفته شود که هر کسبوکار میخواهد کدام محصول خود با چه تأخیر و میزان احتمالیِ از دست رفتن دادهها همراه باشد؟ یا کدام محصول بدون از دست رفتن دادهها عمل کند؟
همچنین پس از اولویتبندی بالا، نوع پیادهسازی بر اساس سرویس هم باید تعیین شود که برنامههای بدون حالت Stateless: این برنامهها هیچ اطلاعاتی از Session کاربر را نگه نمیدارند جابهجایی ترافیک برایشان بسیار آسان است (مانند یک ماشین حساب ساده)؛ برنامههای با حالت Stateful: این برنامهها اطلاعات کاربر را ذخیره میکنند (مانند سبد خرید کاربر). برای این برنامهها باید راهی برای کپی کردن یا اشتراکگذاری اطلاعات سبد خرید بین دو دیتاسنتر تعریف شود (مانند یک حافظه Cache توزیعشده) و پایگاهها داده Databases: این بخش همیشه پیچیدهترین است. باید تصمیم گرفته شود که همگامسازی همزمان (Synchronous)، یعنی RPO صفر است اما ممکن است سایت کمی کند شود و یا همگامسازی ناهمزمان (Asynchronous)، یعنی سایت سریع کار میکند، اما ممکن است دادههای چند ثانیه اخیر از دست بروند.
مورد سوم؛ انتخاب معماری DRaaS برای هر محصول: درنهایت هم یکی از معماریهای DRaaS با توجه به استراتژی مناسب براساس هدفهای RTO/RPO محصولات باید انتخاب شود. راهنمای نوشتن برنامه DRaaS در آروانکلاد به این صورت است که:
- آیا سرویسهای کلیدی ما شناسایی و اولویتبندی شدهاند؟
- آیا هدفهای زمانی (RTO/RPO) برای هر کدام از محصولات تعریف شده است؟
- آیا پشتیبانگیری (Backup) بهشکل منظم و خودکار انجام میشود؟
- آیا پشتیبانگیری در برابر دسترسیهای غیرمجاز، رمزنگاری شدهاند؟
- آیا پشتیبانگیری در یک دیتاسنتر بهطور کلی مجزا (یعنی در یک منطقهی جغرافیایی دیگر آروانکلاد) نگهداری میشوند؟
- آیا پیش از این، فرایند بازگردانی داده (Restore) را آزمایش کردهایم؟
- آیا یک دفترچه راهنمای گامبهگام (Runbook) برای تیمهای فنی در زمان بحران داریم؟
- آیا ابزاری برای تشخیص فوری قطعی (مانیتورینگ) داریم؟
- آیا فرایند سوییچ (Failover) به سایت پشتیبان، تا جای ممکن، خودکار شده است؟
- آیا برنامه مشخصی برای بازگشت به سایت اصلی (Failback) پس از رفع بحران داریم؟
گام چهارم: نقش آروانکلاد در پیادهسازی معماری DRaaS
کسبوکارها و کاربرانی که میخواهند از DRaaS آروانکلاد استفاده کنند، باید از میان چهار معماری کلی در پیادهسازی DRaaS استراتژی مرتبط با اولویتهایشان را انتخاب کنند. استراتژیهای چهارگانه زیر بهترتیب هزینه، سرعت و پیچیدگی مرتب شدهاند و به کسبوکارها در انتخاب دقیقتر کمک میکنند:
استراتژی اول: پشتیبانگیری و بازیابی (Backup and Restore): این استراتژی، ارزانترین روش در انواع راهکارهای DRaaS است و شبیه داشتن یک حافظه External Hard Drives عمل میکند. در وضعیت اجرا هم هیچ زیرساخت دومی پیش از این مرحله، روشن نیست. پس در زمان حادثه، ابتدا باید سرورها ساخته شوند، سپس پشتیبانها را روی آن کپی شوند.
این استراتژی برای سرویسهایی مناسب است که قطع شدن طولانی برایشان مشکل جدی ایجاد نمیکند (مانند آرشیو دادههای قدیمی). به این ترتیب این استراتژی در شاخصهای RTO / RPO در وضعیت «بسیار طولانی» قرار دارد؛ یعنی زمان بازیابی در این استراتژی، چیزی میان چند ساعت تا چند روز است.
در فرایند بازیابی (Failover) هم ساختن سرور جدید (از روی اسنپشات)، دانلود دادهها (از Object Storage آروانکلاد) و درنهایت تغییر آدرس اینترنتی (DNS) به سرور جدید انجام میشود.
استراتژی دوم: پایلوت لایت (Pilot Light): این استراتژی شبیه داشتن یک کامپیوتر خاموش اما با هارد روشن است. آروانکلاد در این نوع استراتژی، در منطقه (Regen) دوم فقط بخش حیاتی (بهطور معمول دیتابیسها) را روشن نگه میدارد و دادهها بهطور مداوم به آن فرستاده میشوند. به این ترتیب در این وضعیت، سرورهای دیگر خاموش میمانند.
این روش برای برنامههای مهم درونسازمانی که میتوانند چند ساعت قطع باشند، مناسب است. همچنین در این استراتژی، وضعیت شاخصهای RTO / RPO از دهها دقیقه تا چند ساعت تأخیر را ثبت میکنند.
فرایند بازیابی (Failover) در این استراتژی به این شکل است که سرورهای خاموش، روشن میشود، قدرت (منابع) سرورها را به بیشترین حالت خودشان رسانده میشوند، دیتابیس پشتیبان فعال میشود و ترافیک به سمت آن هدایت میشود.
استراتژی سوم: آمادهباش گرم (Warm Standby – Active/Passive): این وضعیت شبیه داشتن یک کامپیوتر روشن، اما کممصرف است؛ یعنی یک کپی کامل از سایت کسبوکار بهشکل همیشگی اما با منابع کمتر (حدود نیمی از ظرفیت) روشن میماند و دادهها بهشکل Real-Time کپی میشوند.
این وضعیت برای فروشگاههای آنلاین یا APIهای مهم که نمیتوانند بیشتر از چند دقیقه قطع باشند، مناسب است. وضعیت این استراتژی در شاخصهای RTO / RPO از چند دقیقه تا یک ساعت تعریف میشود.
بهعلاوه، فرایند بازیابی Failover هم در این شاخص، بهشکل خودکار عمل میکند؛ یعنی قطعی سرویس از سمت لودبالانسر (Load Balancer) آروانکلاد تشخیص و ترافیک به سایت پشتیبان هدایت میشود. سپس یک دستور خودکار، منابع سرورهای پشتیبان را به ظرفیت کامل میرساند.
استراتژی چهارم: چندشهری/ چندمنطقهای (Multi-Site – Active/Active)
گرانترین و سریعترین روش، شبیه داشتن دو فروشگاه بهطور کامل یکسان است. در این استراتژی هر فروشگاه بهطور همزمان به مشتریهایشان سرویس میدهند. این استراتژی برای سرویسهای حیاتی مانند درگاههای پرداخت (با قطعی صفر) مناسب است. بنابراین وضعیت شاخص RTO / RPO هم در این استراتژی نزدیک به صفر است.
بهعلاوه، فرایند بازیابی (Failover) در این استراتژی بهشکل کامل آنی و نامحسوس عمل میکند؛ یعنی اگر یک دیتاسنتر از کار بیافتد، شبکه توزیع محتوا (CDN) یا لودبالانسر جغرافیایی آروانکلاد، همان لحظه کاربران را به دیتاسنتر دیگر هدایت میکند و کاربر بهطور کلی متوجه قطعی نمیشود.
خلاصهای از مهمترین شاخصهای تعیینکننده این استراتژیها در جدول زیر آمده است:
گام پنجم: آزمون، خودکارسازی و مدیریت
پس از تمام این مراحل و برای کسب اطمینان از این که این برنامه یک راهکار اجرایی است، باید همیشه آن را تمرین کرد:
- آزمون منظم (DR Drills): باید بهشکل دورهای برای نمونه در هر فصل، فرایند بازیابی واقعی را شبیهسازی شود. این کار مانند تمرین فرود اضطراری هواپیما است؛ نقاط ضعف پیدا میشود و از آماده بودن تیم اطمینان حاصل میشود.
- خودکارسازی: تا جایی که میتوان، همه مراحل (پشتیبانگیری، سوییچ کردن، برگرداندن) را با استفاده از API یا ابزارهای مدیریت زیرساخت (مانند Terraform) خودکار میشود تا خطای انسانی کاهش یابد و RTO (زمان بازیابی) سریعتر شود.
- برنامهی بازگشت به حالت عادی (Failback): بعد از آنکه بحران اصلی تمام شد، باید با احتیاط به سایت اصلی بازگشت. این فرایند شامل کپی کردن تمام دادههای جدیدی است که در سایت پشتیبان، تولید شده است. پس باید این بازگشت به سایت اصلی و سپس هدایت تدریجی ترافیک در این مرحله تمرین شود.
آروانکلاد در تمام این مراحل و جزئیات مسیر انتخاب اولویتها و استراتژی DRaaS همراه مشتریان است تا بتوانند برنامهDRP شخصیسازیشده کسبوکارشان را بسازند و اجرایی کنند. علاقهمندان میتوانند برای استفاده از راهکار بازیابی پس از بحران آروانکلاد به این لینک ورود کنند.
منبع
آروانکلاد