در زیرساخت‌های سازمانی، از دست رفتن اطلاعات یا از کار افتادن سرورها می‌تواند باعث توقف سرویس‌ها، اختلال در فرآیندهای کسب‌ و کار و خسارت‌های مالی قابل‌ توجه شود. به همین دلیل، سازمان‌ها علاوه بر تهیه نسخه پشتیبان، از Disaster Recovery (DR) برای بازیابی سریع سرویس‌ها پس از وقوع حوادثی مانند خرابی سخت ‌افزار، حملات باج‌ افزاری، خطای انسانی یا قطعی مراکز داده استفاده می‌کنند.

هنگام خرید سرور HPE و طراحی زیرساخت، داشتن یک برنامه Disaster Recovery به اندازه انتخاب سخت ‌افزار مناسب اهمیت دارد؛ زیرا هدف DR تنها بازیابی فایل‌ها نیست، بلکه بازگرداندن کامل ماشین‌های مجازی، پایگاه‌های داده، سرویس‌های شبکه و برنامه‌های کاربردی در کوتاه ‌ترین زمان ممکن و با حداقل از دست رفتن اطلاعات است.

Disaster Recovery چیست و چه تفاوتی با Backup دارد؟

Disaster Recovery (DR) مجموعه‌ای از سیاست‌ها، فرآیندها و فناوری‌ها برای بازگرداندن زیرساخت IT پس از یک اختلال جدی است. واژه Disaster به رخدادهایی مثل خرابی سخت‌‌ افزار، قطعی دیتاسنتر، خطای انسانی، حمله سایبری یا از دسترس خارج شدن سرویس‌های حیاتی اشاره دارد و Recovery یعنی بازگرداندن سیستم‌ها به وضعیت عملیاتی قابل قبول. هدف DR این نیست که فقط فایل‌ها دوباره در دسترس باشند؛ بلکه باید سرورها، ماشین‌های مجازی، سیستم‌ عامل، دیتابیس، اپلیکیشن‌ها، تنظیمات شبکه و وابستگی بین سرویس‌ها نیز طبق یک برنامه از پیش تعیین‌ شده بازیابی شوند.

تفاوت Backup و Disaster Recovery چیست؟

Backup فقط یک کپی از داده‌ها ایجاد می‌کند تا در صورت حذف یا خرابی بتوان آن‌ها را Restore کرد، اما Disaster Recovery مشخص می‌کند این داده‌ها کجا، با چه زیرساختی، در چه مدت زمانی و با چه ترتیبی دوباره وارد سرویس شوند. برای مثال، ممکن است اطلاعات سازمان روی استوریج HP کاملاً Backup شده باشد، اما اگر سرور یا سایت اصلی از دسترس خارج شود، بدون زیر ساخت جایگزین، Replication، Failover و Recovery Plan، سرویس به ‌سرعت برنمی‌گردد.

به همین دلیل Backup به‌ تنهایی کافی نیست. یک سازمان ممکن است نسخه پشتیبان سالم داشته باشد اما بازیابی چند ترابایت داده، ساخت مجدد VMها و راه‌ اندازی سرویس‌ها ساعت‌ها یا حتی بیشتر طول بکشد. در DR این موضوع با شاخص‌های RPO و RTO کنترل می‌شود؛ RPO میزان قابل‌ قبول از دست رفتن داده را مشخص می‌کند و RTO حداکثر زمان مجاز برای بازگرداندن سرویس را.

Disaster Recovery همچنین با Business Continuity فرق دارد. DR روی بازیابی فناوری اطلاعات تمرکز دارد، اما Business Continuity کل فعالیت کسب ‌و کار را در بحران پوشش می‌دهد؛ از نیروی انسانی و فرآیندهای عملیاتی تا ارتباطات و IT. بنابراین DR یکی از اجزای فنی برنامه جامع تداوم کسب ‌و کار محسوب می‌شود.

Disaster Recovery چگونه سرویس‌ها را پس از خرابی بازیابی می‌کند؟

در یک سناریوی Disaster Recovery، معمولاً Primary Site یا سایت اصلی محل اجرای سرورها، ماشین‌های مجازی، دیتابیس‌ها و سرویس‌های سازمان است. در کنار آن، Secondary Site یا سایت ثانویه در نظر گرفته می‌شود که می‌تواند به‌ عنوان Disaster Recovery Site عمل کند؛ یعنی اگر سایت اصلی به دلیل خرابی سخت ‌افزار، قطعی گسترده یا حادثه دیگری از دسترس خارج شود، سرویس‌های حیاتی روی سایت جایگزین راه‌ اندازی شوند.

در طراحی سرور HP برای استوریج و ذخیره‌ سازی، سایت DR باید منابع پردازشی، ظرفیت ذخیره‌ سازی، شبکه و دسترسی لازم برای اجرای سرویس‌های مورد نظر را داشته باشد.

برای هماهنگ نگه‌ داشتن اطلاعات بین سایت اصلی و سایت DR از Replication استفاده می‌شود. اگر تکثیر داده مستقیماً در سطح Storage انجام شود، Storage Replication نام دارد؛ اما اگر ماشین‌های مجازی از طریق لایه مجازی ‌سازی تکثیر شوند، با Hypervisor Replication رو به ‌رو هستیم. در زیرساخت‌های استوریج HP، انتخاب روش Replication باید با توجه به حجم داده، پهنای باند شبکه، فاصله دو سایت و RPO مورد نیاز انجام شود.

Snapshot نیز وضعیت داده یا ماشین مجازی را در یک نقطه زمانی مشخص ثبت می‌کند و امکان بازگشت سریع‌تر به وضعیت قبلی را فراهم می‌سازد؛ البته Snapshot به‌ تنهایی جایگزین Backup مستقل نیست. در مقابل، Continuous Data Protection (CDP) تغییرات داده را به‌ صورت پیوسته یا با فاصله‌های بسیار کوتاه ثبت می‌کند و امکان دستیابی به Recovery Pointهای نزدیک‌تر به زمان خرابی را فراهم می‌کند.

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

بنابراین Primary Site، DR Site، Replication، Snapshot، CDP، Failover و Failback اجزای جدا از هم نیستند؛ این بخش‌ها در کنار یک Recovery Plan از پیش طراحی و آزمایش‌شده کار می‌کنند تا در زمان بحران، داده و سرویس در محدوده RPO و RTO تعیین ‌شده دوباره در دسترس قرار گیرند.

مهم‌ترین اصطلاحات Disaster Recovery که باید بدانید

برای طراحی درست Disaster Recovery فقط داشتن Backup یا یک سرور جایگزین کافی نیست؛ باید معیارهایی وجود داشته باشند که مشخص کنند چه مقدار داده می‌تواند از دست برود، سرویس در چه مدت باید برگردد و فرآیند انتقال به سایت جایگزین چگونه انجام شود. این مفاهیم مخصوصاً در سرور HP برای مجازی سازی اهمیت زیادی دارند، زیرا ممکن است ده‌ها ماشین مجازی و سرویس وابسته به یک زیرساخت باشند و ترتیب بازیابی آن‌ها مستقیماً بر زمان بازگشت کسب ‌و کار اثر بگذارد.

RTO (Recovery Time Objective) حداکثر مدت زمانی است که یک سرویس می‌تواند پس از وقوع حادثه از دسترس خارج بماند. برای مثال، اگر RTO سیستم حسابداری ۳۰ دقیقه تعیین شده باشد، زیرساخت DR باید بتواند حداکثر ظرف ۳۰ دقیقه آن سرویس را دوباره فعال کند. بنابراین هرچه RTO کوتاه‌تر باشد، به Replication سریع‌تر، اتوماسیون بیشتر و منابع آماده‌تری در سایت DR نیاز داریم.

RPO (Recovery Point Objective) میزان قابل ‌قبول از دست رفتن داده را برحسب زمان مشخص می‌کند. مثلاً RPO برابر ۱۵ دقیقه یعنی در بدترین حالت سازمان می‌پذیرد حداکثر تغییرات ۱۵ دقیقه آخر را از دست بدهد. در نتیجه، اگر RPO بسیار پایین باشد، Backup روزانه کافی نیست و باید از Replication یا CDP با فاصله زمانی کوتاه استفاده شود.

SLA یا Service Level Agreement سطح خدمات مورد انتظار را مشخص می‌کند و می‌تواند شامل Availability، زمان پاسخ‌ گویی، RTO، RPO و مسئولیت تیم پشتیبانی باشد. برای مثال، اگر یک سرویس براساس SLA باید 99.9 درصد در دسترس باشد، طراحی DR باید با این سطح از دسترس‌ پذیری هماهنگ شود. هنگام خرید کامپیوتر سرور برای سایت DR نیز همین SLA تعیین می‌کند که سایت جایگزین به چه میزان CPU، RAM، Storage و ظرفیت شبکه نیاز خواهد داشت.

High Availability (HA) به مجموعه روش‌هایی گفته می‌شود که هدف آن‌ها جلوگیری یا کاهش توقف سرویس در خرابی‌های معمول سخت ‌افزاری یا نرم‌ افزاری است. برای مثال، اگر یک Host در کلاستر VMware از کار بیفتد، ماشین‌های مجازی می‌توانند روی Host دیگری اجرا شوند. تفاوت مهم آن با DR این است که HA معمولاً خرابی در همان سایت را مدیریت می‌کند، در حالی که Disaster Recovery برای حوادث بزرگ‌تر مانند از دسترس خارج شدن کل سایت نیز برنامه دارد.

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

Replication فرآیند تکثیر اطلاعات از سیستم اصلی به یک مقصد دیگر است. این انتقال می‌تواند در سطح Storage، ماشین مجازی یا دیتابیس انجام شود و به‌صورت Synchronous یا Asynchronous باشد. در طراحی DR، نوع Replication مستقیماً بر RPO، نیاز شبکه و فاصله قابل‌ قبول میان دو سایت تأثیر دارد.

Recovery Plan سند و فرآیند اجرایی مشخصی است که تعیین می‌کند هنگام بحران دقیقاً چه کاری، با چه ترتیبی و توسط چه فرد یا سیستمی انجام شود. مثلاً ممکن است ابتدا Storage و دیتابیس، سپس Active Directory و در مرحله بعد Application Serverها و سرویس‌های کاربران راه‌ اندازی شوند. بدون Recovery Plan ممکن است تمام Backupها سالم باشند، اما وابستگی‌های بین سرویس‌ها باعث تأخیر یا شکست بازیابی شوند.

در نهایت، Recovery Testing یعنی آزمایش عملی برنامه بازیابی قبل از وقوع بحران واقعی. در این تست بررسی می‌شود که Backup قابل Restore است، Replication سالم انجام می‌شود، VMها در سایت DR بالا می‌آیند، شبکه و DNS درست عمل می‌کنند و RTO و RPO تعیین‌ شده واقعاً قابل دستیابی هستند. بنابراین یک برنامه Disaster Recovery تا زمانی که به‌ صورت دوره‌ای تست نشده باشد، نباید کاملاً قابل اتکا در نظر گرفته شود.

انواع روش‌های Disaster Recovery

انواع روش‌های Disaster Recovery

روش‌های Disaster Recovery با توجه به میزان حساسیت سرویس، حجم داده، بودجه، RTO و RPO انتخاب می‌شوند. بعضی روش‌ها برای بازیابی ساده اطلاعات مناسب‌اند و بعضی دیگر برای سازمان‌هایی طراحی شده‌اند که حتی چند دقیقه قطعی هم برایشان قابل ‌قبول نیست.

اگر زیرساختی مانند خرید سرور DL380 Gen11 برای سرویس‌های حیاتی در نظر گرفته شده باشد، معمولاً یک روش ترکیبی و چند لایه از Backup، Replication و Failover نتیجه مطمئن‌تری ایجاد می‌کند.

1. Backup & Restore

در روش Backup & Restore، از داده‌ها، ماشین‌های مجازی یا سیستم‌ها نسخه پشتیبان تهیه می‌شود و در صورت خرابی، اطلاعات از Backup بازیابی می‌شوند. این روش ساده، قابل ‌اعتماد و نسبتاً کم‌ هزینه است، اما سرعت بازیابی آن به حجم داده و سرعت Storage بستگی دارد و برای RTOهای بسیار کوتاه مناسب نیست.

مزیت: هزینه پایین و پیاده ‌سازی ساده.

محدودیت: زمان Restore می‌تواند طولانی باشد.

مناسب برای: فایل‌ سرور، آرشیو، سیستم‌های کم‌ حساس و کسب ‌و کارهایی که چند ساعت Downtime را تحمل می‌کنند.

2. Snapshot Recovery

Snapshot وضعیت یک Volume یا ماشین مجازی را در یک لحظه مشخص ثبت می‌کند و امکان بازگشت سریع به همان نقطه زمانی را فراهم می‌سازد. چون در بسیاری از سیستم‌ها Snapshot فقط تغییرات داده را ثبت می‌کند، بازیابی آن معمولاً بسیار سریع‌تر از Restore کامل Backup است.

مزیت: بازیابی سریع و مناسب برای خطاهای نرم ‌افزاری یا حذف اشتباه داده.

محدودیت: اگر Storage اصلی از بین برود، Snapshot محلی هم ممکن است از دسترس خارج شود؛ بنابراین جایگزین Backup مستقل نیست.

مناسب برای: VMها، دیتابیس‌ها و سرویس‌هایی که نیاز به بازگشت سریع به وضعیت قبلی دارند.

3. Storage Replication

در Storage Replication، داده‌ها از Storage اصلی به یک Storage دیگر در سایت ثانویه کپی و همگام می‌شوند. این Replication می‌تواند Synchronous باشد که داده تقریباً هم‌ زمان در هر دو سمت نوشته می‌شود، یا Asynchronous باشد که با فاصله زمانی کوتاه انجام می‌شود.

مزیت: RPO پایین و امکان بازیابی سریع در خرابی سایت اصلی.

محدودیت: نیاز به Storage سازگار، پهنای باند مناسب و هزینه بیشتر.

مناسب برای: دیتابیس‌های حساس، ERP، VMware و سازمان‌هایی که تحمل از دست رفتن داده بسیار کمی دارند.

4. Hypervisor Replication

در این روش، ماشین‌های مجازی مستقیماً در سطح Hypervisor به سایت DR Replicate می‌شوند. برای مثال در محیط‌های VMware یا Hyper-V، VMها همراه با دیسک مجازی و تنظیمات مورد نیاز به Host یا Cluster دیگری منتقل می‌شوند.

مزیت: بازیابی سریع VM و عدم وابستگی کامل به Storage Replication.

محدودیت: به منابع کافی در سایت مقصد و مدیریت صحیح شبکه و IP نیاز دارد.

مناسب برای: زیرساخت‌های مجازی ‌سازی، Private Cloud و سازمان‌هایی که بخش زیادی از سرویس‌هایشان روی VM اجرا می‌شود.

5. Continuous Data Protection (CDP)

CDP تغییرات داده را به‌ صورت پیوسته یا در فاصله‌های زمانی بسیار کوتاه ثبت می‌کند و به سازمان اجازه می‌دهد به Recovery Pointهای نزدیک به لحظه خرابی برگردد. این روش در مقایسه با Backupهای دوره‌ای، میزان از دست رفتن داده را بسیار کاهش می‌دهد.

مزیت: RPO بسیار پایین و امکان بازگشت به نقاط زمانی متعدد.

محدودیت: مصرف Storage، پهنای باند و هزینه بالاتر.

مناسب برای: سیستم‌های مالی، دیتابیس‌های تراکنشی و سرویس‌هایی که از دست رفتن حتی چند دقیقه داده قابل ‌قبول نیست.

6. Cloud Disaster Recovery

در Cloud Disaster Recovery، نسخه‌های Backup، VMها یا Replication داده‌ها در زیرساخت ابری نگهداری می‌شوند و در زمان خرابی، سرویس‌ها می‌توانند در Cloud اجرا شوند. این روش نیاز به نگهداری کامل یک دیتاسنتر دوم را کاهش می‌دهد.

مزیت: کاهش هزینه سایت DR فیزیکی و مقیاس ‌پذیری بالا.

محدودیت: وابستگی به اینترنت، هزینه انتقال داده و ملاحظات امنیت و Compliance.

مناسب برای: شرکت‌های کوچک و متوسط، دفاتر چند شعبه‌ای و سازمان‌هایی که سایت دوم مستقل ندارند.

7. Hybrid Disaster Recovery

Hybrid Disaster Recovery ترکیبی از زیرساخت On-Premise و Cloud است. در این مدل، سرویس‌های اصلی روی سرورهای داخلی اجرا می‌شوند اما Backup، Replication یا بخشی از Recovery Environment در Cloud قرار دارد. بعضی سرویس‌های حساس نیز می‌توانند روی سایت DR فیزیکی باقی بمانند.

مزیت: انعطاف بالا، کاهش هزینه و امکان ترکیب چند سطح بازیابی.

محدودیت: مدیریت پیچیده‌تر و نیاز به هماهنگی دقیق میان شبکه، امنیت و سرویس‌های ابری.

مناسب برای: سازمان‌هایی که هم به کنترل زیرساخت داخلی نیاز دارند و هم می‌خواهند از مقیاس‌ پذیری Cloud استفاده کنند.

در عمل، بهترین راهکار Disaster Recovery معمولاً یک روش واحد نیست. برای مثال ممکن است Backup برای نگهداری بلند مدت، Snapshot برای بازیابی سریع خطاهای کوچک، Replication برای سرویس‌های حیاتی و Cloud برای سناریوی از دسترس خارج شدن کامل سایت استفاده شود. انتخاب نهایی باید بر اساس RTO، RPO، اهمیت سرویس، بودجه و ظرفیت زیر ساخت انجام شود.

چک‌ لیست راه‌ اندازی Disaster Recovery روی سرورهای HPE ProLiant

برای پیاده‌ سازی Disaster Recovery روی سرورهای HPE ProLiant، ابتدا باید مشخص شود کدام سرویس‌ها حیاتی هستند، سازمان چه میزان Downtime را تحمل می‌کند و حداکثر چه مقدار از داده‌ها می‌تواند از دست برود. استفاده از راهنمای خرید سرور HP نیز کمک می‌کند ظرفیت پردازنده، RAM، Storage، شبکه و قابلیت توسعه سرور از ابتدا متناسب با نیازهای DR انتخاب شود.

شناسایی سرویس‌های حیاتی: ابتدا سرویس‌هایی مانند Active Directory، دیتابیس، ERP، File Server و ماشین‌های مجازی را براساس اهمیت و وابستگی به یکدیگر اولویت‌ بندی کنید. این اولویت مشخص می‌کند در زمان بحران کدام سرویس باید زودتر بازیابی شود.

تعیین RTO و RPO: برای هر سرویس، حداکثر زمان قابل‌ قبول قطعی (RTO) و حداکثر میزان قابل‌ قبول از دست رفتن داده (RPO) تعیین شود. این دو معیار مبنای انتخاب Backup، Replication و ظرفیت سایت DR هستند.

دسته‌بندی داده‌ها: اطلاعات را به داده‌های حیاتی، عملیاتی و آرشیوی تقسیم کنید. داده‌های حساس معمولاً به Replication یا Recovery Pointهای نزدیک‌تر نیاز دارند، در حالی که برای اطلاعات آرشیوی Backup دوره‌ای می‌تواند کافی باشد.

انتخاب Storage مناسب: ظرفیت، IOPS، Latency، نوع درایو، قابلیت Snapshot و Replication و امکان توسعه Storage بررسی شود. Storage سایت DR نیز باید Performance کافی برای اجرای سرویس‌های حیاتی پس از Failover داشته باشد.

انتخاب RAID مناسب: سطح RAID را براساس Workload، تعداد درایو و Fault Tolerance موردنیاز انتخاب کنید. RAID 10 برای VMها و دیتابیس‌های پرتراکنش مناسب است، در حالی که RAID 6 برای ذخیره‌سازی ظرفیت‌محور با تحمل خرابی بیشتر کاربرد دارد. البته RAID جایگزین Backup نیست.

انتخاب روش Backup و محافظت از نسخه‌ها: علاوه بر Full، Incremental یا Differential بودن Backup، محل ذخیره و Retention Policy نیز مشخص شود. بهتر است حداقل یک نسخه Offsite و یک نسخه Immutable یا غیر قابل‌ تغییر نگهداری شود تا خرابی سایت اصلی یا حملات Ransomware نتوانند تمام نسخه‌های بازیابی را از بین ببرند.

انتخاب روش Replication: براساس RPO، حجم تغییرات داده، فاصله دو سایت و پهنای باند شبکه، Synchronous یا Asynchronous Replication انتخاب شود. Replication نیز به‌ تنهایی Backup محسوب نمی‌شود؛ زیرا حذف یا خرابی منطقی داده ممکن است به مقصد Replicate شود.

انتخاب Hypervisor: در محیط مجازی، Hypervisor باید امکان Replication، Failover و Recovery ماشین‌های مجازی را فراهم کند. منابع سایت DR نیز باید برای اجرای VMهای اولویت‌دار کافی باشند.

طراحی سایت DR و زیرساخت شبکه: سایت جایگزین باید CPU، RAM، Storage و پهنای باند کافی داشته باشد. علاوه بر سخت‌ افزار، باید DNS، IP Addressing، Routing، Firewall، VLAN و اتصال کاربران به سرویس‌ها نیز از قبل طراحی شوند؛ زیرا روشن‌ شدن VM در سایت DR بدون دسترسی صحیح شبکه به معنی بازیابی کامل سرویس نیست.

تنظیم Failover: ترتیب انتقال سرویس‌ها به سایت DR مشخص شود. وابستگی سرویس‌ها نیز اهمیت دارد؛ برای مثال ممکن است ابتدا DNS و Active Directory، سپس Database و بعد Application Serverها راه‌ اندازی شوند.

تنظیم Failback: پس از رفع مشکل سایت اصلی، نباید سرویس‌ها مستقیماً به آن بازگردانده شوند. ابتدا داده‌های ایجاد شده در سایت DR باید Synchronize شوند و سپس Failback به‌ صورت کنترل‌ شده انجام شود تا داده جدیدی از بین نرود.

تست دوره‌ای Recovery: تست DR نباید فقط به Restore کردن چند فایل محدود شود. باید بررسی شود ماشین‌های مجازی Boot می‌شوند، دیتابیس Consistent است، Applicationها اجرا می‌شوند، DNS و شبکه کار می‌کنند و وابستگی بین سرویس‌ها برقرار است. همچنین زمان واقعی Recovery باید با RTO و Recovery Point حاصل‌ شده با RPO مقایسه شود.

مانیتورینگ Backup: موفق بودن Backup Job به‌ تنهایی کافی نیست. سلامت Repository، ظرفیت باقی‌ مانده، خطاهای Backup و مهم‌تر از همه قابلیت Restore واقعی نسخه‌ها باید به‌ صورت دوره‌ای بررسی شود.

مانیتورینگ Replication: وضعیت Synchronization، Replication Lag، خطاهای شبکه و سلامت مقصد DR کنترل شود. افزایش غیر عادی Lag ممکن است باعث شود Recovery Point واقعی با RPO تعیین‌ شده مطابقت نداشته باشد.

مستند سازی فرآیند بازیابی: ترتیب Recovery، وابستگی سرویس‌ها، مشخصات سرورها، تنظیمات شبکه، محل Backupها، مسئول هر مرحله و روش Failover/Failback باید در Recovery Plan ثبت و پس از تغییر زیرساخت به‌ روز رسانی شود.

آموزش تیم فنی: تیم IT باید سناریوهای Restore، Failover و Failback را از قبل تمرین کند و وظیفه هر فرد مشخص باشد. یک برنامه DR زمانی قابل اتکاست که علاوه بر تجهیزات و نرم‌ افزار مناسب، تیم فنی نیز بتواند آن را در شرایط واقعی به‌ درستی اجرا کند.

 

 

پیاده‌ سازی Disaster Recovery روی سرورهای HPE

Disaster Recovery در سرورهای HPE چگونه پیاده‌ سازی می‌شود؟

در سرورهای HPE ProLiant، Disaster Recovery به یک قابلیت یا نرم‌ افزار واحد محدود نمی‌شود؛ بلکه از ترکیب مدیریت سرور، RAID، Backup، Replication، Storage و ابزارهای Orchestration ساخته می‌شود. برای مثال، در زیرساختی مبتنی بر HPE ProLiant DL380 Gen11 می‌توان حفاظت محلی از دیسک‌ها را در سطح RAID انجام داد، Backup را روی یک سیستم مجزا نگهداری کرد و برای سرویس‌های حیاتی Replication و Failover به سایت دوم در نظر گرفت. بنابراین هر کدام از فناوری‌های HPE در یک لایه متفاوت از برنامه DR نقش دارند.

1. HPE Smart Array؛ حفاظت از داده در سطح دیسک

HPE Smart Array خانواده RAID Controllerهای HPE است که مدیریت RAID، درایوها و Fault Tolerance محلی را برعهده دارد. با استفاده از RAIDهایی مانند RAID 1، RAID 5، RAID 6 یا RAID 10 می‌توان از توقف سرویس در اثر خرابی یک یا چند Drive ـ بسته به RAID انتخابی ـ جلوگیری کرد.

نکته مهم این است که RAID به‌تنهایی Disaster Recovery نیست؛ Smart Array بیشتر اولین لایه حفاظت در برابر خرابی محلی Storage محسوب می‌شود. اگر کل سرور یا سایت از دسترس خارج شود، همچنان به Backup یا Replication خارج از سرور نیاز داریم.

2. HPE iLO؛ مدیریت سرور در زمان بحران

HPE iLO (Integrated Lights-Out) امکان مدیریت Out-of-Band سرور را فراهم می‌کند؛ یعنی حتی زمانی که سیستم‌ عامل دچار مشکل شده است، مدیر می‌تواند وضعیت سخت‌ افزار را بررسی کند، سرور را از راه دور روشن یا Restart کند، لاگ‌ها را مشاهده کند و عملیات مدیریتی لازم را انجام دهد.

در DR، iLO بیشتر نقش مدیریت و عیب‌ یابی زیرساخت فیزیکی را دارد و خودش ابزار Backup یا Replication نیست. این قابلیت مخصوصاً زمانی مفید است که تیم فنی دسترسی فیزیکی سریع به سرور ندارد.

3. HPE OneView؛ مدیریت متمرکز زیرساخت

HPE OneView برای مدیریت متمرکز زیرساخت HPE استفاده می‌شود و دید یکپارچه‌تری نسبت به وضعیت سرورها و پیکربندی زیرساخت ایجاد می‌کند. در برنامه Disaster Recovery، داشتن اطلاعات دقیق و استاندارد از Configuration سرورها باعث می‌شود مدیریت و بازسازی زیرساخت ساده‌تر شود.

OneView را نیز نباید با یک DR Software مستقل اشتباه گرفت؛ نقش اصلی آن Infrastructure Management و Configuration Management است و در کنار ابزارهای Backup و Recovery استفاده می‌شود.

4. HPE SimpliVity؛ بازیابی ماشین‌های مجازی و اتوماسیون DR

HPE SimpliVity یک پلتفرم Hyperconverged است که قابلیت‌های پردازش، Storage و Data Protection را یکپارچه می‌کند. در محیط‌های مجازی، قابلیت‌های Backup و Replication آن می‌توانند برای حفاظت و بازیابی VMها مورد استفاده قرار گیرند.

در این بخش، HPE SimpliVity RapidDR اهمیت ویژه‌ای دارد. RapidDR یک ابزار Orchestration برای Disaster Recovery است که Recovery مجموعه‌های از پیش پیکربندی‌ شده ماشین‌های مجازی را میان Production Site و Recovery Site خودکار می‌کند و از Failover و Failback پشتیبانی می‌کند. 

5. HPE StoreOnce؛ نگهداری Backup و بازیابی اطلاعات

HPE StoreOnce راهکار اختصاصی HPE برای Backup Storage است و در برنامه DR می‌تواند به‌ عنوان Repository نسخه‌های پشتیبان مورد استفاده قرار گیرد. قابلیت StoreOnce Catalyst امکان Backup داده به StoreOnce و همچنین Copy Job میان سیستم‌های StoreOnce را فراهم می‌کند؛ Deduplication نیز به استفاده بهینه‌تر از ظرفیت و پهنای باند کمک می‌کند. 

بنابراین StoreOnce بیشتر در لایه Backup و Recovery قرار می‌گیرد و در کنار Replication یا سایت DR، یک نسخه بازیابی مستقل در اختیار سازمان قرار می‌دهد.

6. HPE Alletra؛ Replication و Failover در سطح Storage

HPE Alletra در سناریوهای DR می‌تواند حفاظت را مستقیماً در سطح Storage انجام دهد. برای نمونه، در Alletra 9000 قابلیت Remote Copy امکان Replication داده به سیستم Remote را فراهم می‌کند و از روش‌های Synchronous و Asynchronous پشتیبانی می‌شود. در برخی پیکربندی‌ها نیز قابلیت‌های Failover برای انتقال سرویس Storage به سیستم ثانویه وجود دارد. 

در Replication هم‌زمان می‌توان به RPO بسیار پایین و در شرایط مناسب RPO=0 رسید؛ در مقابل، Replication غیر هم‌ زمان برای فاصله‌های بیشتر و شرایطی که Latency شبکه اهمیت دارد انعطاف بیشتری ارائه می‌کند. 

7. HPE MSA؛ گزینه Storage برای DR در زیرساخت‌های کوچک‌تر

HPE MSA خانواده‌ای از Storageهای HPE است که بیشتر در کسب‌ و کارهای کوچک و متوسط و محیط‌هایی با بودجه محدودتر استفاده می‌شود. بسته به مدل، نسل و لایسنس، قابلیت‌هایی مانند Snapshot و Remote Replication می‌توانند برای ایجاد نسخه‌های بازیابی و انتقال داده به Storage ثانویه مورد استفاده قرار گیرند.

در نتیجه MSA می‌تواند برای سازمانی که به یک DR مبتنی بر Storage نیاز دارد اما زیرساخت Enterprise بزرگ Alletra برای آن ضروری نیست، گزینه قابل بررسی باشد. البته قابلیت دقیق Replication باید براساس مدل MSA و لایسنس آن بررسی شود.

8. HPE Nimble Storage؛ Snapshot و Replication برای بازیابی سریع

HPE Nimble Storage در Disaster Recovery از Snapshot و Replication برای حفاظت از Volumeها استفاده می‌کند. HPE برای Nimble و برخی مدل‌های Alletra امکان Snapshot Replication و Synchronous Replication را ارائه می‌کند؛ در حالت Synchronous و پیکربندی مناسب، امکان حفاظت در برابر خرابی Array یا Site با Recovery خودکار نیز وجود دارد. 

در زمان Disaster نیز Volume مقصد می‌تواند Promote شود تا مالکیت Volume Set را در اختیار بگیرد و داده برای Read/Write در سایت بازیابی در دسترس قرار گیرد. 

در مجموع، پیاده‌ سازی DR در اکوسیستم HPE به‌ صورت چند لایه انجام می‌شود: Smart Array از خرابی دیسک محافظت می‌کند، iLO و OneView مدیریت زیرساخت را پوشش می‌دهند، StoreOnce لایه Backup را تقویت می‌کند، SimpliVity امکان حفاظت و Orchestration ماشین‌های مجازی را فراهم می‌کند و Alletra، Nimble یا MSA می‌توانند در لایه Storage، Snapshot و Replication را در اختیار سازمان قرار دهند. انتخاب ترکیب مناسب این فناوری‌ها باید براساس RTO، RPO، حجم داده، نوع Workload، فاصله سایت‌ها و بودجه پروژه انجام شود.

هنگام طراحی Disaster Recovery به چه نکاتی باید توجه کنیم؟

طراحی Disaster Recovery باید براساس میزان اهمیت سرویس‌ها، RTO و RPO و حجم واقعی Workload انجام شود؛ نه صرفاً با تهیه یک سرور دوم یا چند نسخه Backup. حتی هنگام خرید سرور HPE برای سایت اصلی یا DR باید ظرفیت پردازشی، Storage، شبکه و امکان توسعه آینده طوری انتخاب شوند که در زمان بحران، سرویس‌های اولویت‌دار با افت عملکرد شدید مواجه نشوند.

ظرفیت Storage: فضای ذخیره‌ سازی سایت DR باید علاوه بر حجم فعلی داده، رشد آینده، Snapshotها، نسخه‌های Replicated و فضای مورد نیاز برای Recovery را پوشش دهد. فقط ظرفیت برحسب TB مهم نیست؛ IOPS و Latency نیز باید متناسب با دیتابیس‌ها و ماشین‌های مجازی انتخاب شوند.

سرعت شبکه: Replication میان Primary Site و DR Site مستقیماً به پهنای باند و Latency شبکه وابسته است. حجم تغییرات روزانه داده، RPO و نوع Synchronous یا Asynchronous Replication تعیین می‌کنند چه پهنای باندی لازم است. شبکه ضعیف می‌تواند باعث افزایش Replication Lag و عقب‌ افتادن نسخه سایت DR شود.

RAID: سطح RAID باید بر اساس نوع Workload، تعداد درایوها، Performance و میزان تحمل خرابی انتخاب شود. برای مثال RAID 10 برای I/O پرتراکنش مناسب است، در حالی که RAID 6 ظرفیت قابل استفاده بیشتری همراه با تحمل خرابی دو Drive فراهم می‌کند. RAID فقط از خرابی دیسک محافظت می‌کند و جایگزین Backup یا DR نیست.

UPS و تأمین برق: سرور، Storage، تجهیزات شبکه و زیرساخت Backup باید در برابر قطعی برق محافظت شوند. UPS باید زمان کافی برای ادامه کوتاه‌ مدت سرویس یا Shutdown کنترل‌ شده تجهیزات فراهم کند و در سرویس‌های حیاتی، برق اضطراری و افزونگی Power نیز باید در طراحی لحاظ شوند.

تعداد و ظرفیت سرورها: سایت DR لزوماً به تعداد سرورهای سایت اصلی نیاز ندارد، اما باید CPU، RAM و ظرفیت کافی برای اجرای سرویس‌های حیاتی داشته باشد. برای مثال می‌توان سرویس‌های کم‌ اهمیت را در زمان Disaster غیر فعال کرد و منابع را به دیتابیس، ERP و VMهای حیاتی اختصاص داد.

محل سایت دوم: DR Site نباید در معرض همان ریسک‌های سایت اصلی باشد. فاصله جغرافیایی، مسیرهای ارتباطی مستقل، برق، اینترنت و خطرات منطقه‌ای باید بررسی شوند؛ با این حال افزایش فاصله می‌تواند Latency شبکه را بیشتر کند و بر Replication هم‌ زمان تأثیر بگذارد.

امنیت اطلاعات: سایت DR نیز باید همان کنترل‌های امنیتی سایت اصلی را داشته باشد. Firewall، کنترل دسترسی، MFA، تفکیک سطح دسترسی، Network Segmentation و ثبت Log اهمیت زیادی دارند؛ زیرا یک محیط DR ضعیف می‌تواند به مسیر ورود مهاجم به کل زیرساخت تبدیل شود.

رمزنگاری: داده‌های Backup و Replication باید متناسب با سیاست امنیتی سازمان هم در زمان انتقال (Data in Transit) و هم در حالت ذخیره‌ شده (Data at Rest) رمزنگاری شوند. مدیریت صحیح Encryption Key نیز اهمیت دارد؛ از دست رفتن کلید می‌تواند نسخه سالم Backup را عملاً غیر قابل بازیابی کند.

نسخه‌های Backup:Backupها بهتر است فقط روی زیرساخت اصلی نگهداری نشوند. استفاده از نسخه‌های Offsite و Immutable و جداسازی مناسب Backup از محیط Production، مقاومت در برابر خرابی سایت و Ransomware را افزایش می‌دهد. Retention Policy نیز باید مشخص کند هر نسخه تا چه مدت نگهداری شود.

تست Recovery: داشتن Backup یا Replica بدون آزمایش بازیابی کافی نیست. باید به‌ صورت دوره‌ای Restore داده، Boot ماشین‌های مجازی، Consistency دیتابیس، شبکه، DNS، Applicationها و وابستگی سرویس‌ها آزمایش و زمان واقعی بازیابی با RTO و RPO تعیین‌ شده مقایسه شود.

بودجه پروژه: هزینه DR فقط شامل خرید سرور نیست؛ Storage، تجهیزات شبکه، لایسنس نرم‌ افزار، Backup Repository، پهنای باند، سایت دوم، برق، نگهداری و نیروی فنی نیز باید محاسبه شوند. بهترین طراحی لزوماً گران‌ترین طراحی نیست؛ منابع بیشتر باید به سرویس‌هایی اختصاص پیدا کنند که Downtime یا از دست رفتن داده در آن‌ها بیشترین خسارت را ایجاد می‌کند.

رایج‌ترین اشتباهات هنگام پیاده‌ سازی Disaster Recovery

حتی اگر زیرساخت سخت‌ افزاری مناسبی برای Disaster Recovery در نظر گرفته شود، چند اشتباه در طراحی یا اجرای DR می‌تواند باعث شود برنامه بازیابی دقیقاً در زمان بحران قابل استفاده نباشد. مهم‌ترین اشتباهات عبارت‌اند از:

  • اتکا کردن فقط به Backup: داشتن Backup به معنی داشتن Disaster Recovery نیست. DR باید علاوه بر داده، نحوه بازگرداندن VMها، دیتابیس، شبکه، Applicationها و ترتیب اجرای سرویس‌ها را نیز مشخص کند.
  • تست نکردن Recovery: سالم بودن Backup Job تضمین نمی‌کند Restore نیز موفق باشد. فرآیند Recovery باید دوره‌ای آزمایش شود تا سلامت داده و زمان واقعی بازیابی مشخص شود.
  • نداشتن DR Site: اگر تمام سرورها و نسخه‌های اطلاعات در یک محل باشند، حادثه‌ای در سطح سایت می‌تواند همه آن‌ها را هم‌ زمان از دسترس خارج کند. برای سرویس‌های حیاتی باید مقصد بازیابی جداگانه در نظر گرفته شود.
  • انتخاب Storage نامناسب: Storage سایت DR باید از نظر ظرفیت، IOPS، Latency و قابلیت‌های Snapshot و Replication با RTO و RPO پروژه هماهنگ باشد؛ صرفاً داشتن فضای ذخیره‌ سازی کافی نیست.
  • نداشتن نسخه خارج از سایت: نگهداری تمام Backupها در همان سایت اصلی، آن‌ها را در برابر حوادث فیزیکی و برخی حملات سایبری آسیب‌ پذیر می‌کند. حداقل یک نسخه Offsite و ترجیحاً Immutable اهمیت زیادی دارد.
  • مستند سازی نکردن: تنظیمات شبکه، ترتیب راه‌ اندازی سرویس‌ها، وابستگی VMها و مسئولیت اعضای تیم باید ثبت شوند. در شرایط بحران نمی‌توان فرآیند Recovery را به حافظه افراد وابسته کرد.
  • نداشتن Recovery Plan: باید از قبل مشخص باشد چه سرویس‌هایی، با چه ترتیبی و روی چه منابعی بازیابی می‌شوند و Failover و Failback چگونه انجام خواهند شد.
  • تعیین نکردن RPO و RTO: بدون RTO و RPO نمی‌توان مشخص کرد Backup، Replication و سایت DR واقعاً پاسخگوی نیاز کسب‌ و کار هستند یا خیر؛ این دو معیار پایه انتخاب راهکار بازیابی محسوب می‌شوند.

Disaster Recovery

بهترین سناریوی Disaster Recovery برای انواع کسب‌ و کار

یک الگوی ثابت برای Disaster Recovery همه سازمان‌ها وجود ندارد. نوع Workload، میزان حساسیت داده، تعداد کاربران، RTO و RPO، بودجه و هزینه هر دقیقه Downtime تعیین می‌کنند چه سطحی از DR لازم است. حتی هنگام انتخاب بهترین سرور HP برای کسب‌ و کار نیز باید ظرفیت سایت اصلی و سایت بازیابی متناسب با همین نیازها طراحی شود.

شرکت کوچک: برای کسب‌ و کارهای کوچک معمولاً ترکیب Backup منظم، نسخه Offsite یا Cloud، Snapshot و یک برنامه Restore مستند کافی است. اگر سرویس‌های اصلی روی VM اجرا شوند، نگهداری Replica از VMهای حیاتی می‌تواند زمان بازیابی را کاهش دهد و هزینه ایجاد یک DR Site کامل را نیز تحمیل نکند.

شرکت متوسط: در شرکت‌های متوسط که ERP، دیتابیس یا چندین VM حیاتی دارند، بهتر است علاوه بر Backup مستقل و Immutable، Replication به سرور یا Storage موجود در سایت دوم انجام شود. Failover ماشین‌های حیاتی نیز باید از قبل پیکربندی و آزمایش شود تا RTO به چند ساعت Restore دستی وابسته نباشد.

سازمان بزرگ: سازمان‌های بزرگ معمولاً به DR Site مستقل، Replication، کلاسترهای مجازی، Backup خارج از سایت و فرآیندهای خودکار Failover/Failback نیاز دارند. سرویس‌ها نیز باید براساس اهمیت Tierبندی شوند تا برای هرکدام RTO و RPO متفاوتی تعریف شود.

دیتاسنتر: در دیتاسنترها Availability اهمیت بسیار بالایی دارد؛ بنابراین طراحی می‌تواند شامل چند سایت، Storage Replication، Cluster، Load Balancing، شبکه Redundant و Backup مستقل باشد. همچنین Failover باید به‌ طور منظم آزمایش شود تا خرابی یک Host، Storage یا حتی یک Site باعث توقف گسترده سرویس‌ها نشود.

بانک و سیستم‌های مالی: در این محیط‌ها از دست رفتن تراکنش‌ها می‌تواند بسیار پرهزینه باشد؛ بنابراین RPO و RTO معمولاً سخت‌ گیرانه‌تر تعیین می‌شوند. Replication با تأخیر بسیار کم، سایت DR مستقل، Backupهای Immutable، رمزنگاری و تست مداوم Recovery از بخش‌های مهم طراحی هستند؛ انتخاب دقیق روش همگام‌سازی نیز به Latency، فاصله سایت‌ها و الزامات سازمان بستگی دارد.

ERP: در DR سیستم ERP فقط Database اهمیت ندارد؛ Application Server، Authentication، Storage، شبکه و سرویس‌های وابسته نیز باید بازیابی شوند. بنابراین ترتیب Recovery باید از قبل در Recovery Plan مشخص شده و بازیابی کامل Application به‌ صورت دوره‌ای آزمایش شود.

VMware: برای محیط‌های VMware می‌توان از Backup در سطح VM، Snapshot با کاربرد صحیح و Replication ماشین‌های مجازی به سایت DR استفاده کرد. ترتیب روشن‌ شدن VMها و وابستگی آن‌ها به DNS، Active Directory و Database نیز باید در Recovery Plan مشخص شود.

SQL Server: برای SQL Server باید علاوه بر Backup دیتابیس، Transaction Log و Consistency داده، روش‌های HA/DR متناسب با نسخه و طراحی SQL بررسی شوند. هدف این است که Recovery فقط به روشن‌ شدن Server محدود نشود و دیتابیس تا Recovery Point مورد نظر به وضعیت Consistent بازگردد.

Oracle: در محیط Oracle باید حفاظت از Database، Archive Logها، Configuration و وابستگی‌های سرویس در نظر گرفته شود. با توجه به حساسیت Workload می‌توان Backup و Replication را با قابلیت‌های HA/DR مناسب Oracle ترکیب کرد و فرآیند بازیابی را به‌ صورت دوره‌ای آزمایش کرد.

File Server: برای File Server معمولاً ظرفیت ذخیره‌ سازی و سرعت Restore اهمیت بیشتری دارد. Backup نسخه‌ بندی‌شده، Snapshot، نسخه Offsite و در محیط‌های حساس‌تر Replication به سایت دوم، امکان بازیابی فایل‌های حذف‌ شده و همچنین از دسترس خارج شدن کامل سرور را پوشش می‌دهد.

هوش مصنوعی: در زیرساخت‌های AI علاوه بر Datasetها، باید Modelها، Checkpointهای آموزش، Configuration و داده‌های پردازش‌شده محافظت شوند. به دلیل حجم بالای اطلاعات، Replication کامل همه داده‌ها همیشه اقتصادی نیست؛ بنابراین بهتر است داده‌ها براساس اهمیت Tierبندی شوند و Datasetها و Checkpointهای حیاتی اولویت بیشتری برای Backup و Replication داشته باشند.

جمع‌ بندی

Disaster Recovery در سرورهای HPE ProLiant زمانی مؤثر است که به‌ عنوان یک برنامه کامل برای ادامه و بازیابی سرویس طراحی شود، نه صرفاً تهیه Backup. تعیین RTO و RPO، انتخاب Storage و RAID مناسب، ایجاد نسخه‌های Backup مستقل، Replication، طراحی DR Site، برنامه‌ ریزی Failover و Failback و مهم‌تر از همه تست دوره‌ای Recovery، اجزای اصلی این فرآیند هستند. در نهایت بهترین روش DR باید براساس اهمیت Workload، میزان قابل‌ تحمل از دست رفتن داده، زمان مجاز قطعی، بودجه و زیرساخت هر سازمان انتخاب شود تا در صورت خرابی سرور یا حتی از دسترس خارج شدن سایت اصلی، سرویس‌های حیاتی در کوتاه‌ترین زمان ممکن و با حداقل Data Loss دوباره در دسترس قرار گیرند.

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

سوالات متداول

1. تفاوت Backup و Disaster Recovery چیست؟

Backup تنها یک نسخه از داده‌ها را ذخیره می‌کند، اما Disaster Recovery مجموعه‌ای از راهکارها و فرآیندها برای بازیابی کامل سرویس‌ها، ماشین‌های مجازی، سیستم‌ عامل، تنظیمات شبکه و اطلاعات پس از وقوع حادثه است.

2. RTO و RPO چه تفاوتی با یکدیگر دارند؟

RTO حداکثر زمان قابل ‌قبول برای بازگرداندن سرویس‌ها پس از حادثه را مشخص می‌کند، در حالی که RPO حداکثر میزان اطلاعاتی را تعیین می‌کند که سازمان می‌تواند در زمان بازیابی از دست بدهد.

3. آیا Disaster Recovery فقط برای سازمان‌های بزرگ ضروری است؟

خیر. هر کسب‌ و کاری که توقف سرویس‌ها یا از دست رفتن اطلاعات برای آن هزینه‌بر باشد، باید متناسب با بودجه و اهمیت داده‌های خود، یک برنامه Disaster Recovery داشته باشد.

4. هر چند وقت یک‌ بار باید برنامه Disaster Recovery آزمایش شود؟

بهترین روش این است که برنامه Disaster Recovery به‌ صورت دوره‌ای و پس از هر تغییر مهم در زیرساخت، مانند ارتقای سرورها، Storage، ماشین‌های مجازی یا نرم ‌افزارها، آزمایش و به‌ روز رسانی شود تا در زمان وقوع بحران، فرآیند بازیابی بدون مشکل اجرا شود.