نقطه بازگشت؛ VMware Live Recovery، قسمت اول

داشتن Backup خیال مدیر زیرساخت را راحت می‌کند؛ اما فقط تا زمانی که واقعاً به بازیابی اطلاعات نیاز پیدا نکرده باشد.

وقتی یک ماشین مجازی حذف می‌شود، Storage از دسترس خارج می‌شود، سایت اصلی ارتباط خود را از دست می‌دهد یا یک حمله باج‌افزاری بخشی از زیرساخت را آلوده می‌کند، سؤال اصلی این نیست که «آیا Backup داریم؟». سؤال مهم‌تر این است:

سرویس را با چه سرعتی، از کدام نقطه و با چه میزان اطمینان می‌توانیم به مدار بازگردانیم؟

پاسخ VMware به این مسئله، مجموعه‌ای از فناوری‌ها و سرویس‌هاست که امروز آن‌ها را با عنوان VMware Live Recovery می‌شناسیم؛ مجموعه‌ای برای Replication، Disaster Recovery، بازیابی سایبری و هماهنگ‌سازی فرایند بازگرداندن سرویس‌ها.

در این مقاله قرار نیست فقط فهرستی از محصولات VMware را مرور کنیم. هدف این است که بفهمیم هر جزء چه نقشی دارد، کجا استفاده می‌شود و چه تفاوتی میان Backup، Disaster Recovery و Cyber Recovery وجود دارد.

در مقاله بعدی نیز مسیر تکامل این محصولات را از نسخه ۸ تا نسخه‌های ۹ و ۹.۱ بررسی می‌کنیم و به این پرسش پاسخ می‌دهیم که استفاده از آن‌ها در ایران تا چه اندازه امکان‌پذیر است.

VMware Live Recovery دقیقاً چیست؟

VMware Live Recovery را نباید فقط یک نرم‌افزار یا Appliance در نظر گرفت. این عنوان در واقع چتری برای مجموعه‌ای از قابلیت‌های بازیابی VMware است؛ قابلیت‌هایی که از Replication ماشین‌های مجازی شروع می‌شوند و تا بازیابی کامل یک سایت یا ایجاد محیط ایزوله برای مقابله با باج‌افزار ادامه پیدا می‌کنند.

VMware در سال ۲۰۲۴ دو مسیر اصلی بازیابی خود را زیر این نام قرار داد:

• VMware Live Site Recovery
• VMware Live Cyber Recovery

Live Site Recovery بیشتر بر Disaster Recovery، جابه‌جایی برنامه‌ریزی‌شده سرویس‌ها و Failover میان سایت‌ها تمرکز دارد. Live Cyber Recovery برای شرایطی طراحی شده که مسئله فقط خرابی زیرساخت نیست و احتمال آلودگی داده‌ها یا سیستم‌عامل‌ها نیز وجود دارد.

در نسخه‌های جدید، قابلیت‌هایی مانند Enhanced vSphere Replication، vSAN Data Protection، Protection Groups و Recovery Plans نیز با این معماری یکپارچه‌تر شده‌اند.

به همین دلیل، وقتی درباره VMware Live Recovery صحبت می‌کنیم، عملاً درباره چند لایه مختلف صحبت می‌کنیم:

1. حفاظت از داده‌ها
2. تکثیر ماشین‌های مجازی
3. هماهنگ‌سازی فرایند Disaster Recovery
4. بازیابی پس از حملات سایبری
5. مشاهده و مدیریت وضعیت حفاظت از Workloadها

Backup با Disaster Recovery تفاوت دارد

یکی از اشتباهات رایج در طراحی زیرساخت این است که Backup را معادل Disaster Recovery در نظر بگیریم.

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

فرض کنید یک سامانه سازمانی از چهار بخش تشکیل شده است:

• Database Server
• Application Server
• Web Server
• سرویس‌های شبکه و امنیت

اگر تمام این ماشین‌ها Backup داشته باشند، هنوز مشخص نیست کدام ماشین باید ابتدا بازیابی شود. ممکن است روشن‌شدن Web Server قبل از Database باعث خطا شود. آدرس‌های شبکه در سایت بازیابی ممکن است متفاوت باشند و برخی سرویس‌ها نیز پس از راه‌اندازی به اجرای Script یا بررسی دستی نیاز داشته باشند.

Disaster Recovery این فرایند را از یک عملیات پراکنده به یک سناریوی تعریف‌شده تبدیل می‌کند.

در معماری DR مشخص می‌شود:

• کدام ماشین‌ها باید محافظت شوند؟
• داده‌ها با چه فاصله زمانی Replicate شوند؟
• ترتیب روشن‌شدن ماشین‌ها چیست؟
• شبکه مقصد چگونه انتخاب شود؟
• هنگام Failover چه Scriptهایی اجرا شوند؟
• چه زمانی سرویس سالم تلقی شود؟
• Failback به سایت اصلی چگونه انجام شود؟

اینجاست که Recovery Plan معنا پیدا می‌کند.

RPO و RTO؛ دو عددی که معماری بازیابی را تعیین می‌کنند

هر طراحی Disaster Recovery باید از دو سؤال شروع شود:

چه مقدار از داده را می‌توانیم از دست بدهیم؟

سرویس چه مدت می‌تواند از دسترس خارج باشد؟

پاسخ سؤال اول RPO و پاسخ سؤال دوم RTO را مشخص می‌کند.

RPO چیست؟

Recovery Point Objective حداکثر مقدار قابل‌قبول از دست‌رفتن داده را نشان می‌دهد.

اگر RPO یک سامانه ۱۵ دقیقه باشد، سازمان پذیرفته است که در زمان وقوع بحران، حداکثر تغییرات ۱۵ دقیقه آخر از دست برود.

هرچه RPO کوچک‌تر شود، Replication باید با فاصله زمانی کوتاه‌تری انجام شود و در نتیجه نیاز به پهنای باند، Storage و منابع پردازشی بیشتری خواهیم داشت.

Enhanced vSphere Replication در معماری VMware Live Recovery می‌تواند در شرایط و Entitlement مناسب، RPO را تا یک دقیقه کاهش دهد. البته انتخاب RPO یک‌دقیقه‌ای برای تمام ماشین‌ها تصمیم منطقی‌ای نیست. این مقدار باید براساس اهمیت سرویس، نرخ تغییر داده، ظرفیت لینک و توان زیرساخت مقصد تعیین شود.

RTO چیست؟

Recovery Time Objective حداکثر زمان قابل‌قبول برای بازگرداندن سرویس است.

ممکن است از دست‌دادن ۳۰ دقیقه داده برای یک سامانه قابل‌قبول باشد، اما همان سامانه نباید بیشتر از یک ساعت از دسترس خارج بماند. در این حالت RPO برابر ۳۰ دقیقه و RTO برابر یک ساعت خواهد بود.

Recovery Planها، Automation و تست دوره‌ای DR بیشترین تأثیر را روی کاهش RTO دارند. داشتن نسخه Replicate‌شده از ماشین‌ها مفید است، اما اگر فرایند بازیابی چند ساعت درگیر تصمیم‌های دستی و آزمون‌وخطا شود، RTO مورد انتظار تأمین نخواهد شد.

اجزای اصلی VMware Live Recovery

برای شناخت این مجموعه باید نقش هر محصول و فناوری را جداگانه بررسی کنیم.

VMware Live Site Recovery

VMware Live Site Recovery را می‌توان نسل جدید و توسعه‌یافته مسیر VMware Site Recovery Manager دانست.

وظیفه اصلی این محصول، مدیریت و Orchestrate کردن فرایند Disaster Recovery میان سایت محافظت‌شده و سایت بازیابی است. Live Site Recovery خودش Storage داده‌های ماشین مجازی نیست و به‌تنهایی نیز عملیات Replication را انجام نمی‌دهد؛ بلکه Replication موجود را مدیریت کرده و آن را داخل Recovery Plan قرار می‌دهد.

برای انتقال داده می‌توان از روش‌های مختلف استفاده کرد:

• vSphere Replication
• Enhanced vSphere Replication
• Array-Based Replication
• قابلیت‌های Replication سازندگان Storage

در سناریوهای Array-Based Replication معمولاً به Storage Replication Adapter یا SRA سازگار با Storage مورد استفاده نیاز داریم.

Live Site Recovery روی این لایه Replication قرار می‌گیرد و فرایندهای زیر را مدیریت می‌کند:

• تعریف Protection Group
• ساخت Recovery Plan
• تعیین ترتیب روشن‌شدن ماشین‌ها
• Map کردن شبکه‌ها و منابع
• اجرای Planned Migration
• اجرای Disaster Recovery
• انجام Reprotect
• مدیریت Failback
• تست Recovery Plan بدون ایجاد اختلال در سرویس اصلی

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

vSphere Replication

vSphere Replication فناوری تکثیر ماشین‌های مجازی در سطح Hypervisor است.

در این روش، وابستگی مستقیمی به قابلیت Replication در Storage Array وجود ندارد. در نتیجه می‌توان ماشین مجازی را میان Storageهای متفاوت Replicate کرد؛ البته مقصد و مبدأ باید در محدوده معماری و نسخه‌های پشتیبانی‌شده VMware قرار داشته باشند.

برای مثال ممکن است ماشین مجازی در سایت اصلی روی یک FC SAN قرار داشته باشد و نسخه Replicate‌شده آن در سایت بازیابی روی vSAN نگهداری شود.

این انعطاف برای سازمان‌هایی مفید است که در دو سایت از Storage یکسان استفاده نمی‌کنند یا نمی‌خواهند Disaster Recovery آن‌ها به یک برند خاص وابسته باشد.

vSphere Replication برای هر ماشین مجازی Policy و RPO مشخصی در نظر می‌گیرد. بنابراین لازم نیست تمام Workloadها با یک سیاست ثابت محافظت شوند. ماشین‌های حساس می‌توانند RPO کوتاه‌تری داشته باشند و سرویس‌های کم‌اهمیت‌تر با فاصله بیشتری Replicate شوند.

Enhanced vSphere Replication

Enhanced vSphere Replication نسخه بهبود‌یافته Replication در معماری Live Recovery است و با هدف کاهش RPO، افزایش مقیاس‌پذیری و بهبود عملکرد Replication ارائه شده است.

در این معماری، امکان رسیدن به RPO یک‌دقیقه‌ای برای Workloadهای واجد شرایط وجود دارد. اما رسیدن به این عدد به عوامل مختلفی وابسته است:

• میزان تغییرات دیسک ماشین مجازی
• پهنای باند بین سایت‌ها
• Latency شبکه
• توان پردازشی Hostها
• عملکرد Storage مقصد
• تعداد ماشین‌های تحت حفاظت
• نوع لایسنس و Entitlement

بنابراین عبارت «RPO یک دقیقه» را نباید به این معنا برداشت کرد که تمام ماشین‌های مجازی در هر زیرساختی می‌توانند بدون طراحی قبلی با همین RPO محافظت شوند.

در یک معماری حرفه‌ای، ابتدا Workloadها دسته‌بندی می‌شوند و سپس برای هر گروه RPO مناسب انتخاب خواهد شد.

vSAN Data Protection

vSAN Data Protection مجموعه‌ای از قابلیت‌های حفاظت و بازیابی داده در محیط vSAN است. این قابلیت‌ها می‌توانند برای ایجاد Snapshotهای مدیریتی، تعریف Protection Group و حفاظت از ماشین‌های مجازی استفاده شوند.

در اینجا باید میان دو سناریو تفاوت قائل شویم:

• حفاظت محلی از ماشین‌ها روی vSAN
• Replication آن‌ها به یک vSAN دیگر

قابلیت Snapshot و حفاظت محلی الزاماً به VMware Live Recovery Add-on نیاز ندارد؛ اما Replication از راه دور و برخی امکانات پیشرفته بازیابی به Subscription و Entitlement مربوط به Live Recovery یا Protection and Recovery وابسته‌اند.

در VCF 9.1 قابلیت Any-to-vSAN نیز اهمیت بیشتری پیدا کرده است. در این معماری، Workload مبدأ می‌تواند روی vSAN، VMFS یا NFS قرار داشته باشد، اما مقصد بازیابی روی vSAN ساخته می‌شود.

این مدل برای سازمانی جذاب است که در سایت اصلی از SAN یا NAS استفاده می‌کند، اما می‌خواهد Recovery Site جدید خود را بر پایه vSAN طراحی کند.

VMware Live Recovery Appliance

در معماری‌های قدیمی‌تر، اجزای Site Recovery، vSphere Replication و قابلیت‌های مرتبط معمولاً با Applianceها و فرایندهای مدیریتی جداگانه مستقر می‌شدند.

از VMware Live Recovery 9.0.3، اجزای On-Prem این مجموعه در قالب یک Live Recovery Appliance یکپارچه‌تر شدند. این Appliance قابلیت‌های اصلی زیر را کنار یکدیگر قرار می‌دهد:

• VMware Live Site Recovery
• Enhanced vSphere Replication
• vSAN Data Protection

این تغییر صرفاً برای ساده‌کردن ظاهر محصول نیست. کاهش تعداد نقاط مدیریتی، هماهنگ‌ترشدن Upgrade و ساده‌ترشدن استقرار، مستقیماً روی قابلیت نگهداری معماری DR اثر می‌گذارد.

البته یکپارچه‌شدن Appliance به این معنی نیست که تمام قابلیت‌ها بدون لایسنس جداگانه در اختیار سازمان قرار می‌گیرند. هر قابلیت همچنان باید براساس Edition، Subscription و Entitlement خریداری‌شده بررسی شود.

VMware Live Cyber Recovery

Live Cyber Recovery برای شرایطی طراحی شده است که احتمال می‌دهیم داده یا ماشین بازیابی‌شده آلوده باشد.

در Disaster Recovery معمولی فرض می‌کنیم نسخه Replicate‌شده سالم است. اگر سایت اصلی از دسترس خارج شود، Workloadها را در سایت مقصد روشن می‌کنیم. اما در حمله باج‌افزاری این فرض قابل اعتماد نیست.

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

Cyber Recovery باید بتواند:

• تاریخچه عمیق‌تری از Restore Pointها نگهداری کند
• نسخه‌های بازیابی را در محیط ایزوله روشن کند
• ماشین‌ها را پیش از اتصال به شبکه عملیاتی بررسی کند
• از ابزارهای EDR برای تشخیص رفتار مشکوک استفاده کند
• Restore Point سالم را پیدا کند
• فرایند بازگرداندن سرویس را مرحله‌به‌مرحله انجام دهد

این محیط ایزوله معمولاً Clean Room نامیده می‌شود.

در Clean Room، ماشین‌های بازیابی‌شده به شبکه Production متصل نمی‌شوند. ابتدا سیستم‌عامل، سرویس‌ها و داده‌ها بررسی می‌شوند و تنها پس از اطمینان از سلامت آن‌ها، فرایند بازگشت به محیط عملیاتی انجام خواهد شد.

Disaster Recovery با Cyber Recovery یکی نیست

هر دو مفهوم درباره بازگرداندن سرویس هستند، اما فرض اولیه متفاوتی دارند.

در Disaster Recovery معمولاً با خرابی زیرساخت مواجه هستیم:

• قطعی برق
• خرابی Storage
• از دسترس خارج‌شدن سایت
• اشتباه انسانی
• حادثه طبیعی
• اختلال گسترده شبکه

در Cyber Recovery با این احتمال روبه‌رو هستیم که خود داده‌ها یا ماشین‌های مجازی قابل اعتماد نباشند:

• باج‌افزار
• نفوذ طولانی‌مدت
• تخریب عمدی اطلاعات
• آلوده‌شدن Backupها
• Replicate شدن فایل‌های رمزگذاری‌شده
• باقی‌ماندن بدافزار داخل سیستم‌عامل

بنابراین یک Recovery Site معمولی الزاماً Cyber Recovery Site نیست.

برای تبدیل آن به محیط مناسب بازیابی سایبری، به قابلیت‌هایی مانند Immutable Restore Point، شبکه ایزوله، Clean Room، EDR، تحلیل رفتار ماشین و فرایند اعتبارسنجی نیاز داریم.

Protection Group چیست؟

Protection Group مجموعه‌ای منطقی از ماشین‌های مجازی است که باید با یک سیاست مشخص محافظت شوند.

برای مثال می‌توان ماشین‌های یک سامانه مالی را در یک Protection Group قرار داد:

• Database
• Application
• Web
• Authentication
• Monitoring

گروه‌بندی ماشین‌ها باعث می‌شود حفاظت و بازیابی براساس سرویس انجام شود، نه صرفاً براساس نام VM.

این تفاوت مهمی است. کاربران به یک ماشین مجازی نیاز ندارند؛ آن‌ها به سرویس نیاز دارند. اگر سه ماشین از چهار ماشین یک سامانه بازیابی شوند اما Database در دسترس نباشد، سرویس همچنان Down است.

Recovery Plan چیست؟

Recovery Plan سناریوی اجرایی بازگرداندن سرویس است.

در Recovery Plan مشخص می‌کنیم:

• کدام Protection Groupها بازیابی شوند
• ماشین‌ها با چه ترتیبی روشن شوند
• میان مراحل چه مقدار تأخیر وجود داشته باشد
• هر ماشین به کدام Network متصل شود
• چه IP یا تنظیماتی در سایت مقصد اعمال شود
• چه Scriptهایی اجرا شوند
• در کدام مرحله نیاز به تأیید مدیر وجود داشته باشد
• موفقیت بازیابی چگونه ارزیابی شود

برای مثال، Recovery Plan یک سامانه فروش اینترنتی می‌تواند چنین ترتیبی داشته باشد:

1. راه‌اندازی سرویس‌های زیرساختی
2. روشن‌کردن Database
3. بررسی سلامت Database
4. روشن‌کردن Application Server
5. اتصال Application به Database
6. روشن‌کردن Web Server
7. اعمال تنظیمات شبکه مقصد
8. اجرای تست سلامت سرویس
9. تأیید نهایی و انتقال ترافیک کاربران

این برنامه باید پیش از بحران آزمایش شود. Recovery Plan آزمایش‌نشده بیشتر یک فرضیه است تا برنامه Disaster Recovery.

تست Disaster Recovery بدون قطع سرویس اصلی

یکی از قابلیت‌های مهم Live Site Recovery، امکان Test Recovery است.

در این سناریو، ماشین‌های Replicate‌شده در یک شبکه ایزوله در سایت مقصد روشن می‌شوند، بدون اینکه ماشین‌های اصلی خاموش شوند یا Replication عملیاتی از بین برود.

تیم زیرساخت می‌تواند بررسی کند:

• آیا ماشین‌ها روشن می‌شوند؟
• سیستم‌عامل سالم است؟
• ترتیب Boot درست انتخاب شده؟
• سرویس‌ها یکدیگر را پیدا می‌کنند؟
• Scriptها درست اجرا می‌شوند؟
• RTO واقعی چقدر است؟
• آیا Recovery Plan به اصلاح نیاز دارد؟

این تست باید به شکل دوره‌ای انجام شود. تغییر یک IP، اضافه‌شدن یک ماشین جدید یا تغییر Dependency برنامه می‌تواند Recovery Plan قبلی را ناقص کند.

Planned Migration، Failover و Failback چه تفاوتی دارند؟

این سه اصطلاح گاهی به‌جای یکدیگر استفاده می‌شوند، اما کاربرد متفاوتی دارند.

Planned Migration

زمانی استفاده می‌شود که هر دو سایت در دسترس‌اند و قصد داریم Workloadها را به‌صورت کنترل‌شده منتقل کنیم.

برای مثال:

• تعمیرات دیتاسنتر
• جابه‌جایی تجهیزات
• مهاجرت به سایت جدید
• آزمایش عملیاتی Recovery Site
• خاموشی برنامه‌ریزی‌شده

در این حالت تلاش می‌شود آخرین تغییرات Replicate شوند و ماشین‌ها با حداقل Data Loss به مقصد انتقال پیدا کنند.

Disaster Failover

زمانی اجرا می‌شود که سایت اصلی کاملاً یا تا حد زیادی از دسترس خارج شده است. ممکن است امکان Synchronize کردن آخرین تغییرات وجود نداشته باشد؛ بنابراین بازیابی از آخرین نسخه قابل استفاده انجام می‌شود.

در این شرایط مقدار واقعی Data Loss به آخرین Replication موفق و RPO وابسته است.

Failback

پس از رفع مشکل سایت اصلی، ممکن است بخواهیم Workloadها را دوباره به آن بازگردانیم.

Failback فقط روشن‌کردن VMها در سایت اول نیست. ابتدا باید جهت Replication معکوس شود، تغییرات سایت بازیابی به سایت اصلی منتقل شوند و سپس انتقال کنترل‌شده انجام گیرد.

قابلیت Reprotect در این مرحله اهمیت پیدا می‌کند.

VMware Live Recovery در VVF و VCF

Live Site Recovery می‌تواند در محیط‌های VMware vSphere Foundation و VMware Cloud Foundation استفاده شود؛ اما تمام قابلیت‌های بازیابی در این دو پلتفرم یکسان نیستند.

در محیط VVF می‌توان از قابلیت‌های Site Recovery و Replication برای حفاظت از Workloadهای مجازی استفاده کرد. این سناریو برای سازمانی مناسب است که زیرساخت آن عمدتاً بر vSphere، vCenter، ESXi و Storage متمرکز است و به معماری کامل Private Cloud نیاز ندارد.

در VCF، بازیابی می‌تواند با لایه‌های بیشتری از پلتفرم یکپارچه شود:

• vSphere
• vSAN
• VCF Operations
• VCF Automation
• NSX
• vDefend
• VPC
• Advanced Cyber Compliance

در VCF 9.1، اجزای On-Prem مجموعه Live Recovery با عنوان VCF Protection and Recovery معرفی شده‌اند. همچنین Advanced Cyber Compliance یا ACC به‌عنوان Add-on جداگانه، سناریوهای پیشرفته‌تری برای Disaster Recovery، Cyber Recovery، Clean Room و Continuous Compliance فراهم می‌کند.

ACC بخشی از امکانات پایه VCF نیست و نباید آن را قابلیتی رایگان یا پیش‌فرض در تمام نصب‌های VCF 9.1 در نظر گرفت.

از طرف دیگر، ACC برای VVF ارائه نمی‌شود. بنابراین سازمانی که Cyber Recovery پیشرفته و کاملاً On-Prem می‌خواهد، باید علاوه بر معماری VCF، نیازمندی‌ها و Entitlement مربوط به ACC را نیز بررسی کند.

اگر هنوز تفاوت این دو پلتفرم برایتان روشن نیست، مطالعه راهنمای مقایسه VVF و VCF پیش از طراحی معماری بازیابی کمک می‌کند انتخاب دقیق‌تری داشته باشید.

برای هر سناریو کدام قابلیت مناسب است؟

انتخاب راهکار بازیابی باید از نیاز کسب‌وکار شروع شود، نه از نام محصول.

این جدول نقطه شروع تصمیم‌گیری است. طراحی نهایی باید براساس RPO، RTO، بودجه، فاصله سایت‌ها، پهنای باند و نوع Storage انجام شود.

آیا تمام ماشین‌ها باید Replicate شوند؟

معمولاً خیر.

Replication تمام ماشین‌های مجازی بدون طبقه‌بندی، هزینه Storage، شبکه و لایسنس را افزایش می‌دهد و مدیریت Recovery Planها را دشوار می‌کند.

روش بهتر، دسته‌بندی Workloadها براساس اهمیت آن‌هاست.

گروه اول: سرویس‌های حیاتی

این سرویس‌ها باید با RPO کوتاه و Recovery Plan دقیق محافظت شوند؛ مانند سامانه‌های مالی، احراز هویت، بانک اطلاعاتی اصلی و سرویس‌های درآمدزا.

گروه دوم: سرویس‌های مهم

قطعی چندساعته آن‌ها قابل‌تحمل است و می‌توان RPO طولانی‌تری برایشان انتخاب کرد.

گروه سوم: سرویس‌های قابل بازسازی

برخی ماشین‌ها را می‌توان از Template، Automation یا روش‌های دیگر دوباره ایجاد کرد. Replication دائمی این ماشین‌ها ممکن است توجیه اقتصادی نداشته باشد.

این طبقه‌بندی یکی از موضوعات مهم در مسیر حرفه‌ای آموزش VMware و معماری زیرساخت است. شناخت ابزار به‌تنهایی کافی نیست؛ متخصص زیرساخت باید بتواند براساس نیاز کسب‌وکار، معماری مناسب را انتخاب کند.

یک سناریوی واقعی

فرض کنیم یک سازمان دو دیتاسنتر در تهران و اصفهان دارد. سایت تهران محیط Production و سایت اصفهان Recovery Site است.

ماشین‌های حیاتی سازمان روی FC SAN قرار دارند، اما در سایت اصفهان از vSAN استفاده می‌شود. هدف این است که در صورت از دسترس خارج‌شدن سایت تهران، سرویس‌های اصلی حداکثر ظرف یک ساعت در اصفهان فعال شوند.

در چنین معماری‌ای می‌توان:

• از vSphere Replication برای انتقال VMها از FC SAN به vSAN استفاده کرد
• ماشین‌های مرتبط با هر سرویس را داخل Protection Group قرار داد
• برای هر سامانه یک Recovery Plan ساخت
• شبکه‌های Production و Recovery را Map کرد
• ترتیب روشن‌شدن Database، Application و Web را مشخص کرد
• هر سه ماه Test Recovery انجام داد
• پس از رفع مشکل سایت اصلی، از Reprotect و Failback استفاده کرد

اگر تهدید باج‌افزار نیز در Scope پروژه باشد، همین معماری به‌تنهایی کافی نیست. سازمان باید Restore Pointهای ایمن، شبکه Clean Room، ابزار EDR و فرایند اعتبارسنجی ماشین‌ها را نیز در نظر بگیرد.

این مثال نشان می‌دهد VMware Live Recovery یک دکمه جادویی برای بازگرداندن دیتاسنتر نیست. نتیجه نهایی به طراحی درست، تست دوره‌ای و شناخت وابستگی سرویس‌ها بستگی دارد.

جایگاه Live Recovery در مسیر آموزش مجازی‌سازی

در بسیاری از دوره‌های مقدماتی آموزش مجازی سازی، تمرکز اصلی روی ساخت ماشین مجازی، مدیریت ESXi، کار با vCenter و راه‌اندازی Cluster است. این مهارت‌ها پایه کار هستند، اما برای اداره زیرساخت‌های سازمانی کافی نیستند.

یک VMware Administrator حرفه‌ای باید بتواند به پرسش‌های جدی‌تری پاسخ دهد:

• اگر Cluster از دسترس خارج شد چه اتفاقی می‌افتد؟
• اگر سایت اصلی نابود شد، سرویس‌ها کجا اجرا می‌شوند؟
• آخرین نسخه سالم داده مربوط به چه زمانی است؟
• Recovery Plan واقعاً تست شده است؟
• آیا Backupها پس از حمله باج‌افزاری قابل اعتمادند؟
• چه کسی اجازه اجرای Failover دارد؟
• بازگشت به سایت اصلی چگونه انجام می‌شود؟

به همین دلیل، Live Recovery در مسیر پیشرفته آموزش VVF و به‌خصوص آموزش VCF قرار می‌گیرد. این موضوع ترکیبی از دانش vSphere، Storage، Network، Security، Automation و Business Continuity است.

یادگیری منوهای محصول کافی نیست. متخصص باید بتواند میان Backup، Replication، Disaster Recovery و Cyber Recovery مرز روشنی ایجاد کند و برای هر Workload سطح حفاظت متناسبی در نظر بگیرد.

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

پیش از انتخاب VMware Live Recovery، بهتر است حداقل این موارد مشخص شوند:

• نسخه دقیق vCenter و ESXi
• نوع معماری VVF یا VCF
• تعداد ماشین‌های نیازمند حفاظت
• ظرفیت مصرفی و نرخ تغییر داده‌ها
• RPO و RTO هر سرویس
• نوع Storage در مبدأ و مقصد
• پهنای باند و Latency میان سایت‌ها
• نیاز به vSphere Replication یا Array-Based Replication
• سازگاری SRA با Storage
• نیاز به Disaster Recovery یا Cyber Recovery
• امکان استفاده از vSAN در Recovery Site
• نیاز به Clean Room
• مدل لایسنس و Entitlement
• روش تست و مستندسازی Recovery Plan
• مسئولیت تیم‌ها هنگام اعلام بحران

اگر این اطلاعات مشخص نباشند، انتخاب محصول بیشتر شبیه خرید ابزار است تا طراحی راهکار.

VMware Live Recovery چه مسئله‌ای را حل می‌کند؟

ارزش VMware Live Recovery در کنار هم قراردادن چند قابلیت است:

داده‌ها Replicate می‌شوند، ماشین‌ها داخل گروه‌های منطقی قرار می‌گیرند، ترتیب بازیابی در Recovery Plan تعریف می‌شود و کل سناریو پیش از وقوع بحران قابل آزمایش خواهد بود.

در سناریوهای سایبری نیز موضوع فقط بازگرداندن آخرین نسخه نیست. باید بتوان نسخه سالم را پیدا کرد، آن را در محیط ایزوله بررسی کرد و سپس با کمترین ریسک به Production بازگرداند.

پس VMware Live Recovery زمانی بیشترین ارزش را دارد که سازمان از مرحله «Backup داریم» عبور کرده و بخواهد به این اطمینان برسد که:

اگر زیرساخت متوقف شد، برنامه‌ای واقعی و آزمایش‌شده برای بازگرداندن سرویس‌ها وجود دارد.

در مقاله بعدی، محصولات این خانواده را از نسل VMware 8 تا نسخه‌های ۹ و ۹.۱ کنار یکدیگر قرار می‌دهیم. بررسی می‌کنیم SRM و vSphere Replication چه تغییراتی کرده‌اند، VCF Protection and Recovery و Advanced Cyber Compliance چه قابلیت‌هایی اضافه کرده‌اند و کدام‌یک از این راهکارها از نظر فنی، لایسنس و دسترسی به سرویس‌های Cloud در ایران قابل استفاده‌اند.