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

در نسل VMware 8، طراحی Disaster Recovery مسیر نسبتاً مشخصی داشت. برای Replication ماشین‌های مجازی از vSphere Replication استفاده می‌کردیم و برای ساخت Recovery Plan، اجرای Failover، Reprotect و Failback سراغ Site Recovery Manager می‌رفتیم. اگر هم بازیابی پس از باج‌افزار مطرح بود، باید از سرویس‌های ابری جداگانه‌ای مانند VMware Cloud Disaster Recovery و VMware Ransomware Recovery کمک می‌گرفتیم.

در VMware 9 و به‌خصوص VCF 9.1، این معماری تغییر کرده است. محصولات فقط تغییر نام نداده‌اند؛ مرز میان Replication، Snapshot، Disaster Recovery و Cyber Recovery نیز جابه‌جا شده است.

VMware Live Recovery Appliance چند سرویس قبلاً جدا را کنار یکدیگر قرار می‌دهد. vSAN از یک Storage صرف به بخشی از معماری Protection and Recovery تبدیل شده و Advanced Cyber Compliance امکان ساخت Clean Room کاملاً On-Premises را فراهم می‌کند.

این مقاله ادامه مطلب نقطه بازگشت؛ VMware Live Recovery است. در مقاله اول با اجزا و کاربردهای Live Recovery آشنا شدیم. اینجا مسیر تکامل محصولات را از نسل 8 تا نسخه‌های 9 و 9.1 بررسی می‌کنیم و در انتها به این پرسش می‌رسیم که کدام قابلیت‌ها در ایران قابل استفاده‌اند.

قبل از مقایسه، یک ابهام را برطرف کنیم

محصول مستقلی با عنوان «VMware Live Recovery 8» وجود نداشت.

در نسل 8، قابلیت‌هایی که امروز زیر معماری Live Recovery قرار گرفته‌اند، میان چند محصول و سرویس تقسیم شده بودند:

• VMware Site Recovery Manager
• vSphere Replication
• VMware Cloud Disaster Recovery
• VMware Ransomware Recovery
• قابلیت‌های Replication سازندگان Storage
• vSAN Data Protection در vSAN 8 Update 3

VMware در سال 2024 عنوان Live Recovery را معرفی کرد و دو خانواده اصلی را زیر این نام قرار داد:

• VMware Live Site Recovery، نام جدید Site Recovery Manager
• VMware Live Cyber Recovery، حاصل ترکیب مسیر VMware Cloud Disaster Recovery و VMware Ransomware Recovery

بنابراین مقایسه نسخه‌های 8، 9 و 9.1 باید براساس قابلیت‌ها و محصولات معادل انجام شود، نه فقط نام محصولات.

نقشه تغییر محصولات از نسخه 8 تا 9.1

نکته مهم این است که «نسخه 9.1» در این مقاله بیشتر به اکوسیستم VCF 9.1 اشاره دارد. نباید تصور کنیم تمام قابلیت‌های جدید داخل یک محصول با نام VMware Live Recovery 9.1 و یک لایسنس واحد عرضه می‌شوند.

معماری بازیابی در نسل VMware 8 چگونه بود؟

Site Recovery Manager 8.x

در نسخه 8، VMware Site Recovery Manager یا SRM هسته اصلی Orchestration در Disaster Recovery بود.

SRM عملیات زیر را مدیریت می‌کرد:

• ساخت Protection Group
• تعریف Recovery Plan
• تعیین ترتیب روشن‌شدن ماشین‌ها
• Map کردن Networkها
• تخصیص Folder و Resource Pool مقصد
• Planned Migration
• Disaster Failover
• Reprotect
• Failback
• تست Recovery Plan در شبکه ایزوله

SRM خودش داده ماشین‌های مجازی را کپی نمی‌کرد. برای Replication به یکی از این دو روش نیاز داشت:

• vSphere Replication
• Array-Based Replication

این معماری هنوز از نظر منطقی معتبر است. چیزی که در نسل جدید تغییر کرده، نحوه استقرار، مدیریت، لایسنس و یکپارچگی آن با vSAN و VCF است.

vSphere Replication 8.x

vSphere Replication یک راهکار Hypervisor-Based بود که Replication را در سطح ماشین مجازی انجام می‌داد. مزیت مهم آن، استقلال نسبی از Storage بود.

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

بااین‌حال در نسل 8، vSphere Replication و SRM معمولاً با Applianceها و چرخه مدیریتی جداگانه پیاده‌سازی می‌شدند. در محیط‌های بزرگ، مقیاس‌پذیری، توزیع بار و مدیریت اجزای متعدد نیز پیچیدگی بیشتری ایجاد می‌کرد.

Array-Based Replication

سازمان‌هایی که از Storageهای Enterprise استفاده می‌کردند، معمولاً Replication را در سطح Array انجام می‌دادند.

در این مدل، SRM از طریق Storage Replication Adapter با Storage ارتباط برقرار می‌کرد. مزیت اصلی آن استفاده از قابلیت‌های Native خود Storage بود، اما چند وابستگی نیز ایجاد می‌شد:

• سازگاری نسخه SRA با SRM
• سازگاری Firmware و نرم‌افزار Storage
• وابستگی به Vendor
• Replication در سطح LUN یا Volume
• پیچیدگی بیشتر بازیابی ماشین‌های منفرد

این روش در نسخه 9 حذف نشده است. Array-Based Replication همچنان پشتیبانی می‌شود، اما از 20 اوت 2025 مسئولیت توسعه و انتشار SRAها بیشتر بر عهده سازندگان Storage قرار گرفته و Broadcom دیگر آن‌ها را مستقیماً Certification نمی‌کند. پیش از هر Upgrade باید وضعیت SRA از طرف Vendor بررسی شود.

VMware Cloud Disaster Recovery و Ransomware Recovery

در نسل 8، بازیابی ابری و بازیابی پس از باج‌افزار در قالب سرویس‌هایی جدا از SRM عرضه می‌شدند.

VMware Cloud Disaster Recovery برای نگهداری نسخه‌های محافظت‌شده در Cloud و بازیابی روی VMware Cloud on AWS طراحی شده بود. VMware Ransomware Recovery نیز قابلیت‌هایی مانند موارد زیر را اضافه می‌کرد:

• Isolated Recovery Environment
• انتخاب Restore Point سالم
• تحلیل رفتاری ماشین روشن‌شده
• Network Isolation
• Guided Recovery Workflow

این تفکیک باعث می‌شد Disaster Recovery سنتی و Cyber Recovery دو مسیر محصولی و مدیریتی متفاوت داشته باشند.

آغاز VMware Live Recovery چه چیزی را تغییر داد؟

VMware Live Recovery در سال 2024 با هدف نزدیک‌کردن دو مسیر بازیابی معرفی شد:

• Disaster Recovery سنتی
• Cyber Recovery پس از باج‌افزار

طبق معرفی رسمی VMware Live Recovery، این مجموعه از دو Technology Stack اصلی تشکیل شد:

• VMware Live Site Recovery، نام جدید SRM
• VMware Live Cyber Recovery، نام جدید مسیر Cloud Disaster Recovery و Ransomware Recovery

این تغییر در ابتدا بیشتر یکپارچگی محصولی، مدیریتی و Subscription ایجاد کرد. تحول مهم معماری On-Premises با VCF 9 و VMware Live Recovery 9.0.3 شکل روشن‌تری پیدا کرد.

تغییرات VMware Live Recovery در نسخه 9

یک Appliance به‌جای چند جزء پراکنده

از VMware Live Recovery 9.0.3، اجزای اصلی On-Premises در یک Appliance ترکیب شدند:

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

این تغییر استقرار و Lifecycle Management را ساده‌تر می‌کند. به‌جای نگهداری چند Appliance با Update و تنظیمات مستقل، بخش مهمی از سرویس‌های Protection and Recovery از یک نقطه مشترک مدیریت می‌شوند.

در سناریوهای پیچیده مانند Shared Recovery Site، همچنان می‌توان Add-on Site Recovery Service Appliance مستقر کرد. Array Manager و SRA نیز برای Replication مبتنی بر Storage باید جداگانه پیکربندی شوند.

Enhanced vSphere Replication به روش پیش‌فرض تبدیل شد

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

بهبودهای اصلی آن عبارت‌اند از:

• Data Path بهینه‌تر
• کاهش وابستگی ترافیک Replication به Appliance
• توزیع خودکار بار
• مقیاس‌پذیری بهتر
• پشتیبانی از RPO کوتاه‌تر
• Network Encryption اجباری
• امکان مدیریت گروهی تنظیمات Replication

در Subscription مربوط به VMware Live Recovery، RPO می‌تواند تا یک دقیقه کاهش پیدا کند. در برخی لایسنس‌های Legacy SRM، Enhanced Replication قابل استفاده است، اما حداقل RPO معمولاً در سطح پنج دقیقه باقی می‌ماند.

پس RPO یک‌دقیقه‌ای فقط یک قابلیت فنی نیست؛ به نوع Entitlement نیز وابسته است. راهنمای رسمی ارتقا به Enhanced vSphere Replication

vSAN-to-vSAN Replication

vSAN Data Protection ابتدا در vSAN 8 U3 و VCF 5.2 معرفی شد. در آن نسخه، تمرکز اصلی روی حفاظت محلی بود:

• Snapshot در سطح VM
• Protection Group
• نگهداری حداکثر 200 Snapshot برای هر VM
• Immutable Snapshot
• بازیابی VM حذف‌شده
• Clone از Snapshot

در VCF 9، قابلیت vSAN-to-vSAN Replication اضافه شد. ماشین‌ها و Snapshotهای آن‌ها می‌توانستند از یک vSAN ESA به vSAN ESA دیگری Replicate شوند.

این Replication در سطح VM انجام می‌شود؛ برخلاف بسیاری از راهکارهای Array-Based که واحد مدیریتی آن‌ها LUN یا Volume است.

مزیت‌های این مدل عبارت‌اند از:

• Replication فقط ماشین‌های موردنیاز
• کاهش مصرف Storage مقصد
• کاهش ترافیک اضافی
• Recovery ساده‌تر ماشین‌های منفرد
• یکپارچگی با Protection Group و Recovery Plan
• امکان ایجاد تاریخچه عمیق‌تری از Restore Pointها

قابلیت حفاظت محلی vSAN بخشی از Entitlement اصلی VCF است، اما Replication بین سایت‌ها و Orchestration کامل DR به Add-on مربوط به Site Recovery یا ACC نیاز دارد.

مشاهده وضعیت Recovery در VCF Operations

در VCF 9، اطلاعات حفاظت و بازیابی به VCF Operations نزدیک‌تر شد. مدیر زیرساخت می‌تواند دید متمرکزتری نسبت به این موارد داشته باشد:

• تعداد VMهای محافظت‌شده
• ماشین‌های فاقد Protection
• وضعیت Replication
• ظرفیت Storage محافظت‌شده
• وضعیت Cyber Recovery
• وضعیت Disaster Recovery
• Remote Snapshotها

این قابلیت جای کنسول تخصصی SRM یا Live Cyber Recovery را نمی‌گیرد، اما برای مانیتورینگ کل Private Cloud دید یکپارچه‌تری ایجاد می‌کند.

Clean Room در VCF 9

در VCF 9 و VLR 9.0.3، VMware یک معماری Validated Solution برای ساخت Isolated Recovery Environment در دیتاسنتر خود سازمان ارائه کرد.

اجزای این معماری شامل موارد زیر بودند:

• VCF Workload Domain برای اجرای ماشین‌های بازیابی
• vSAN ESA به‌عنوان Cyber Data Vault
• Immutable Snapshot
• Enhanced vSphere Replication
• vDefend برای Network Isolation
• VMware Live Recovery برای Orchestration
• ابزار EDR برای بررسی ماشین‌ها

این قابلیت برای سازمان‌هایی اهمیت داشت که به‌دلیل Data Sovereignty یا مقررات داخلی نمی‌توانستند نسخه‌های بازیابی را در Public Cloud نگهداری کنند.

در نسخه 9، این معماری هنوز بیشتر در قالب یک طراحی معتبر و قابل پیاده‌سازی ارائه می‌شد. در VCF 9.1، مسیر On-Premises Cyber Recovery با Advanced Cyber Compliance ساختار محصولی روشن‌تری پیدا کرد.

چه چیزی در VCF 9.1 تغییر کرد؟

vSAN Data Protection به vSAN Protection and Recovery رسید

در VCF 9.1، نام vSAN Data Protection به vSAN Protection and Recovery تغییر کرد. این تغییر نام با توسعه دامنه محصول همراه است.

نسخه قبلی بیشتر روی Snapshot و حفاظت از داده تمرکز داشت. نسخه 9.1 علاوه بر حفاظت محلی، نقش پررنگ‌تری در Replication، Disaster Recovery و Cyber Recovery ایفا می‌کند.

Multi-Source Replication

در VCF 9، Replication داخلی vSAN به مسیر vSAN-to-vSAN محدود بود. مبدأ و مقصد هر دو باید vSAN ESA می‌بودند.

در VCF 9.1، مبدأ می‌تواند یکی از این Storageها باشد:

• vSAN
• VMFS
• NFS

مقصد باید vSAN ESA باشد.

این قابلیت که گاهی Any-to-vSAN نیز نامیده می‌شود، امکان ساخت یک Recovery Site متمرکز را فراهم می‌کند. سازمان می‌تواند Workloadهای چند Cluster با Storageهای مختلف را در یک سایت مبتنی بر vSAN محافظت کند.

این معماری برای بسیاری از دیتاسنترهای ایران کاربردی است؛ چون معمولاً در سایت اصلی ترکیبی از FC SAN، NFS و vSAN وجود دارد، اما می‌توان سایت بازیابی جدید را یکپارچه و مبتنی بر vSAN ESA طراحی کرد.

معماری Fan-in 

Multi-Source Replication امکان Replication چند مبدأ به یک مقصد مرکزی را فراهم می‌کند.

برای نمونه، سه Cluster زیر را در نظر بگیرید:

• Cluster مالی روی VMFS
• Cluster سرویس‌های عمومی روی NFS
• Cluster جدید روی vSAN

در VCF 9.1 می‌توان هر سه را به یک vSAN ESA Cluster در Recovery Site متصل کرد. هر Source Site و Recovery Site به vCenter و Protection and Recovery Appliance مربوط به خود نیاز دارد و میان سایت‌ها Pairing انجام می‌شود.

این مدل هزینه ایجاد Recovery Siteهای جداگانه را کاهش می‌دهد و مدیریت حفاظت را متمرکزتر می‌کند.

نگهداری Snapshotها

در نسخه‌های قبلی، Retention بیشتر به روش‌های ترتیبی و FIFO وابسته بود. VCF 9.1 از الگوی سلسله‌مراتبی GFS پشتیبانی می‌کند:

• Hourly
• Daily
• Weekly
• Monthly

به‌جای نگهداری تمام Snapshotها با فاصله زمانی یکسان، می‌توان برای دوره‌های مختلف تاریخچه متفاوتی ساخت.

برای مثال:

• Snapshot ساعتی برای یک روز
• Snapshot روزانه برای یک هفته
• Snapshot هفتگی برای یک ماه
• Snapshot ماهانه برای شش ماه

این قابلیت در Cyber Recovery اهمیت زیادی دارد. ممکن است آخرین Restore Pointها آلوده باشند و تیم امنیت مجبور شود برای یافتن یک نسخه سالم، چند هفته یا چند ماه به عقب بازگردد.

عضویت داینامیک با vSphere Tag

در VCF 9.1، عضویت VMها در Protection Group می‌تواند براساس vSphere Tag انجام شود.

برای مثال، هر ماشین دارای Tag زیر به‌صورت خودکار وارد گروه حفاظت حیاتی شود:

Recovery-Tier-1

در این حالت، اضافه‌شدن VM جدید به یک سرویس دیگر باعث نمی‌شود تیم زیرساخت فراموش کند آن را به Protection Group اضافه کند. Policy حفاظت همراه با Tag روی Workload اعمال می‌شود.

Manual Replica Seeding

اولین Full Sync برای ماشین‌های حجیم می‌تواند پهنای باند زیادی مصرف کند. VCF 9.1 امکان Manual Seeding را اضافه کرده است.

نسخه اولیه داده می‌تواند از مسیر دیگری به سایت مقصد منتقل شود و سپس Replication فقط اختلاف میان نسخه Seedشده و وضعیت جدید مبدأ را Synchronize کند.

این قابلیت برای سایت‌هایی با لینک WAN محدود یا چند ده ترابایت داده، کاربردی است.

Advanced Cyber Compliance چیست؟

VMware Advanced Cyber Compliance یا ACC یک Advanced Service جداگانه برای VCF است. این محصول بخشی از لایسنس پایه VCF محسوب نمی‌شود.

ACC سه حوزه اصلی را پوشش می‌دهد:

• Continuous Compliance
• Platform Security
• Cyber and Disaster Recovery

در بخش Recovery، قابلیت‌های زیر در اختیار سازمان قرار می‌گیرد:

• Enhanced vSphere Replication
• RPO تا یک دقیقه
• Orchestration کامل Disaster Recovery
• Cyber Recovery کاملاً On-Premises
• Isolated Recovery Environment
• EDR یکپارچه
• Guided Recovery Workflow
• Multi-Tenant Disaster Recovery
• Policy-Based VPC Connectivity
• File and Folder-Level Restore

طبق FAQ رسمی Advanced Cyber Compliance، مشتری دارای Entitlement پایه VCF فقط از Operational Recovery محلی، مانند Local Snapshot، برخوردار است. برای Replication از راه دور، Disaster Recovery Orchestration و Cyber Recovery باید SRM یا ACC تهیه شود.

تفاوت ACC و SRM

اگر هدف فقط Failover، Failback و تست DR میان دو سایت باشد، SRM انتخاب مستقیم‌تر و سبک‌تری است.

اگر سازمان علاوه بر DR به Clean Room، بررسی آلودگی، EDR، Compliance و بازیابی پس از باج‌افزار نیاز دارد، ACC معماری کامل‌تری ارائه می‌کند.

نیازمندی‌های Cyber Recovery در VCF 9.1

برای ساخت Clean Room کاملاً On-Premises با ACC، شرایط مهمی وجود دارد:

• Recovery Site باید VCF 9.1 باشد.
• در Recovery Site به vSAN ESA نیاز است.
• vDefend برای ایزوله‌سازی شبکه VMها لازم است.
• در Recovery Site باید VPC ساخته شود.
• EDR برای اعتبارسنجی Restore Pointها استفاده می‌شود.
• Carbon Black گزینه پیش‌فرض است.
• CrowdStrike Falcon با مدل BYOL قابل استفاده است.
• Storage سایت اصلی الزاماً نباید vSAN باشد.
• NSX در Protected Site الزام اجباری ندارد.
• Cyber Recovery برنامه‌های Containerized فعلاً پشتیبانی نمی‌شود.

بنابراین ACC فقط یک لایسنس نرم‌افزاری نیست. Recovery Site باید از ابتدا برای نقش Cyber Vault و Clean Room طراحی شود.

مقایسه نهایی VMware 8، 9 و 9.1

آیا ارتقا از SRM 8 به نسخه 9 یک Upgrade ساده است؟

خیر. این مسیر باید به‌عنوان تغییر معماری بررسی شود، نه صرفاً نصب نسخه جدید.

پیش از ارتقا باید موارد زیر مشخص شوند:

نسخه دقیق اجزا

نسخه‌های زیر باید ثبت شوند:

• vCenter Server
• ESXi
• Site Recovery Manager
• vSphere Replication
• Storage Firmware
• SRA
• NSX
• vSAN

سپس مسیر پشتیبانی‌شده در Product Interoperability Matrix بررسی شود.

تبدیل Replication قدیمی به Enhanced Replication

در VLR Appliance جدید، Enhanced vSphere Replication روش اصلی و پشتیبانی‌شده برای Site-to-Site Replication است.

بنابراین ماشین‌هایی که هنوز با Replication قدیمی محافظت می‌شوند، باید پیش از مهاجرت کامل به Appliance جدید Reconfigure شوند.

بررسی وضعیت SRA

اگر Replication در سطح Storage انجام می‌شود، باید Vendor تأیید کند که SRA موردنظر با نسخه جدید SRM، vCenter و Firmware سازگار است.

وجود یک فایل SRA قدیمی به معنای پشتیبانی رسمی آن در نسخه 9 نیست.

بازنگری Recovery Plan

Recovery Planهای موجود باید از نظر این موارد بررسی شوند:

• Network Mapping
• Folder Mapping
• Resource Mapping
• IP Customization
• Boot Priority
• Dependencies
• Scriptها
• Test Network
• Reprotect
• Failback

حتی اگر Recovery Plan پس از Upgrade بدون خطا نمایش داده شود، باید دوباره Test Recovery اجرا شود.

بررسی نوع Entitlement

لایسنس Legacy SRM، VMware Live Recovery Subscription، SRM Add-on و ACC دسترسی یکسانی ایجاد نمی‌کنند.

برای مثال:

• Local Snapshot در vSAN ESA می‌تواند در Entitlement اصلی VCF قرار داشته باشد.
• RPO یک‌دقیقه‌ای Enhanced Replication به Entitlement مربوطه نیاز دارد.
• DR Orchestration به SRM یا ACC نیاز دارد.
• Cyber Recovery کاملاً On-Premises فقط از طریق ACC ارائه می‌شود.
• Live Recovery Cloud به Subscription و زیرساخت Cloud جداگانه وابسته است.

آیا VMware Live Recovery در ایران کار می‌کند؟

پاسخ کوتاه این است:

بخش‌های On-Premises از نظر فنی قابل اجرا هستند، اما دسترسی رسمی به لایسنس، Subscription، Onboarding، Cloud و پشتیبانی مسئله جداگانه‌ای است.

نباید «قابل نصب بودن» را با «قابل خرید و پشتیبانی بودن» یکسان دانست.

Live Site Recovery و vSphere Replication

طبق FAQ رسمی VMware Live Recovery، VMware Live Site Recovery می‌تواند در حالت Offline و بدون اتصال اینترنت کار کند.

بنابراین از نظر فنی می‌توان در ایران معماری زیر را پیاده‌سازی کرد:

• Protected Site در یک دیتاسنتر داخلی
• Recovery Site در دیتاسنتر داخلی دیگر
• دو vCenter
• Enhanced vSphere Replication
• Live Site Recovery یا SRM
• ارتباط WAN اختصاصی میان سایت‌ها

برای اجرای Failover، Test Recovery و Failback در این معماری، وابستگی دائمی به اینترنت عمومی وجود ندارد.

مشکل اصلی تهیه قانونی نرم‌افزار، Entitlement معتبر، Update، Compatibility Data و پشتیبانی رسمی است.

Array-Based Replication

این روش نیز می‌تواند کاملاً داخل شبکه سازمان کار کند. اما وضعیت آن به Vendor Storage وابسته است.

باید بررسی شود:

• SRA نسخه جدید منتشر شده است؟
• Firmware فعلی پشتیبانی می‌شود؟
• Vendor در ایران خدمات ارائه می‌دهد؟
• فایل‌های Update و Documentation در دسترس‌اند؟
• در صورت بروز خطا چه مرجعی پاسخ‌گو است؟

از نظر فنی قابل اجراست، اما بدون SRA معتبر می‌تواند هنگام Upgrade به یک بن‌بست عملیاتی تبدیل شود.

vSAN Protection and Recovery

حفاظت محلی vSAN ESA و Snapshotها به سرویس Cloud وابسته نیستند. در نتیجه از نظر فنی در دیتاسنتر داخلی قابل استفاده‌اند.

Replication به سایت دیگر نیز می‌تواند از طریق شبکه داخلی یا WAN خصوصی انجام شود. این بخش نیز الزام فنی برای انتقال داده به Public Cloud ندارد.

بااین‌حال فعال‌بودن قابلیت‌های Remote Replication و Orchestration به Entitlement صحیح نیاز دارد.

VMware Live Cyber Recovery Cloud

این سرویس به اجزای Cloud-Based وابسته است:

• VMware Live Recovery Cloud Console
• Connector VM
• Scale-out Cloud File System
• زیرساخت VMware Cloud on AWS
• Cloud Hosts و Storage
• Subscription فعال
• دسترسی شبکه‌ای و تجاری به سرویس

به همین دلیل، Live Cyber Recovery Cloud را نباید برای یک سازمان مستقر در ایران به‌عنوان گزینه قطعی و قابل اتکای معماری در نظر گرفت.

حتی اگر اتصال فنی موقت به سرویس برقرار شود، موضوعات زیر باقی می‌مانند:

• امکان خرید رسمی
• منطقه سرویس‌دهی
• Billing
• تمدید Subscription
• دسترسی به Support
• خطر قطع سرویس
• محدودیت‌های تجاری و صادراتی

این سرویس برای ایران در رده «وابسته به تأیید رسمی Vendor» قرار می‌گیرد، نه یک راهکار تضمین‌شده.

Advanced Cyber Compliance

ACC از نظر معماری On-Premises است و برای حفظ Data Sovereignty طراحی شده است. داده‌ها، Cyber Vault و Clean Room می‌توانند داخل دیتاسنترهای خود سازمان باقی بمانند.

اما فعال‌سازی آن صرفاً با واردکردن یک License Key آفلاین انجام نمی‌شود. طبق FAQ رسمی، مشتری پس از خرید Welcome Email دریافت می‌کند و باید فرایند Onboarding را طی کند.

پس برای یک سازمان ایرانی دو نتیجه متفاوت داریم:

• اجرای معماری از نظر فنی امکان‌پذیر است.
• دریافت رسمی ACC، Onboarding و پشتیبانی باید جداگانه تأیید شود و نمی‌توان آن را قطعی فرض کرد.

وضعیت عملی قابلیت‌ها در ایران

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

بنابراین تصمیم نهایی خرید یا ارائه سرویس باید براساس قرارداد Broadcom، قوانین صادراتی، نوع سازمان و تأیید فروشنده مجاز انجام شود. اجرای نسخه فاقد Entitlement یا دور زدن سازوکار فعال‌سازی، جایگزین قابل دفاعی برای طراحی سازمانی نیست.

برای یک سازمان ایرانی کدام معماری منطقی‌تر است؟

برای اغلب سازمان‌های ایرانی، معماری On-Premises قابل‌کنترل‌تر است:

• دو سایت داخلی
• دو vCenter
• Enhanced vSphere Replication
• SRM برای Orchestration
• vSAN ESA در Recovery Site در صورت امکان
• Immutable Snapshot
• Backup مستقل از Replication
• شبکه ایزوله برای تست بازیابی
• EDR مستقل
• Offline Depot برای Updateهای تأییدشده
• مستندسازی Recovery Plan و اجرای Drill دوره‌ای

اگر ACC با Entitlement معتبر و Onboarding رسمی در دسترس باشد، می‌توان Clean Room، EDR و Cyber Recovery Workflow را یکپارچه‌تر کرد. در غیر این صورت باید Cyber Recovery را با ترکیبی از vSAN Protection، SRM، vDefend، EDR و Runbookهای کنترل‌شده طراحی کرد.

این معماری از نظر یکپارچگی به سطح ACC نمی‌رسد، اما وابستگی کمتری به سرویس Cloud دارد و با محدودیت‌های عملیاتی ایران سازگارتر است.

ارتقا به 9.1 برای چه سازمانی ارزش دارد؟

مهاجرت به معماری 9.1 زمانی توجیه بیشتری دارد که سازمان یکی از نیازهای زیر را داشته باشد:

• Replication چند Storage مختلف به یک vSAN Recovery Site
• ایجاد سایت بازیابی مشترک برای چند Cluster
• RPO کوتاه‌تر با Enhanced Replication
• Snapshot Retention بلندمدت
• مدیریت خودکار Protection Group با Tag
• Manual Seeding برای داده‌های حجیم
• Clean Room کاملاً On-Premises
• Cyber Recovery با EDR یکپارچه
• Multi-Tenant Disaster Recovery
• مشاهده متمرکزتر وضعیت Protection در VCF Operations

اگر سازمان فقط تعداد محدودی VM دارد و SRM 8 به همراه Replication موجود، RPO و RTO موردنیاز را تأمین می‌کند، ارتقا صرفاً به‌دلیل تغییر نام محصولات منطقی نیست.

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

جمع‌بندی

در نسل VMware 8، Site Recovery Manager، vSphere Replication، Cloud Disaster Recovery و Ransomware Recovery مسیرهای نسبتاً جداگانه‌ای داشتند.

در VMware 9، این اجزا به معماری یکپارچه‌تری نزدیک شدند. VMware Live Recovery Appliance مدیریت Site Recovery، Enhanced Replication و vSAN Data Protection را ساده‌تر کرد. vSAN-to-vSAN Replication، RPO یک‌دقیقه‌ای و مشاهده وضعیت حفاظت در VCF Operations نیز مسیر بازیابی را به خود پلتفرم VCF نزدیک‌تر کردند.

VCF 9.1 این مسیر را توسعه داده است. vSAN Protection and Recovery اکنون می‌تواند Workloadهای مستقر روی vSAN، VMFS و NFS را به یک vSAN ESA Recovery Site منتقل کند. GFS Retention، Tag-Based Protection Groups، Manual Seeding و Advanced Cyber Compliance نیز فاصله میان Disaster Recovery و Cyber Recovery را کمتر کرده‌اند.

برای متخصصانی که مسیر آموزش VMware، آموزش VCF و آموزش VVF را دنبال می‌کنند، نکته اصلی حفظ‌کردن نام محصولات نیست. باید بدانند هر لایه چه مسئولیتی دارد:

• vSphere Replication داده را منتقل می‌کند.
• SRM فرایند Disaster Recovery را Orchestrate می‌کند.
• vSAN Protection and Recovery از Snapshot و Replication پشتیبانی می‌کند.
• Live Cyber Recovery مسیر بازیابی ابری را فراهم می‌کند.
• ACC بازیابی سایبری و Clean Room محلی را به VCF اضافه می‌کند.

در ایران، معماری‌های On-Premises از نظر فنی قابل اجرا هستند و Live Site Recovery حتی می‌تواند در حالت Offline کار کند. محدودیت اصلی در بخش فنی نیست؛ دسترسی رسمی به Entitlement، Subscription، Onboarding، Update و Support تعیین می‌کند کدام قابلیت در یک پروژه سازمانی واقعاً قابل اتکا خواهد بود.