در vSAN 8، بخش مهم داستان روی بلوغ معماری ESA و فاصلهگرفتن تدریجی از محدودیتهای OSA متمرکز بود. vSAN 9 دامنه را بزرگتر کرد و قابلیتهایی مانند Replication بومی میان دیتاستورهای vSAN و Global Deduplication را وارد نسل جدید کرد؛ هرچند Deduplication در نسخه 9 هنوز بهصورت Limited Availability ارائه میشد. حالا vSAN 9.1 آمده تا چند قابلیت آزمایشی یا محدود را به ابزارهای قابلاستفاده در طراحی واقعی دیتاسنتر تبدیل کند.
اگر بخواهیم پاسخ کوتاهی بدهیم، ارزش اصلی vSAN 9.1 در چهار محور دیده میشود: کاهش مصرف ظرفیت با Compression جدید و Deduplication سراسری، انعطاف بیشتر میان کلاسترهای OSA و ESA، توسعه جدی Protection and Recovery و آمادهشدن Storage برای محیطهای Kubernetes، Private Cloud و سناریوهای چندسایتی.
این مقاله بخشی از مسیر تخصصی آموزش VMware در ابرکلاس است و تلاش میکند vSAN 9.1 را از زاویه معماری و تصمیمگیری بررسی کند؛ نه صرفاً به شکل فهرستی از قابلیتهای جدید.
vSAN 9.1 دقیقاً چه نقشی در VCF و VVF دارد؟
vSAN لایه Software-Defined Storage پلتفرم VMware است. دیسکهای محلی سرورها را در قالب یک Datastore اشتراکی و Policy-Based در اختیار ماشینهای مجازی، سرویسهای Kubernetes و سایر Workloadها قرار میدهد. نتیجه این معماری، حذف وابستگی مستقیم سیاستهای ذخیرهسازی از سختافزار یک آرایه مشخص است.
در VMware Cloud Foundation، vSAN یکی از اجزای اصلی Private Cloud محسوب میشود و با vSphere، VCF Operations، VKS و سرویسهای Protection and Recovery یکپارچه است. در VMware vSphere Foundation نیز vSAN نقش ذخیرهسازی یکپارچه پلتفرم را دارد. برای درک تفاوت جایگاه این محصول در دو بسته، مقاله مقایسه VVF و VCF در VMware 9.1 مکمل مناسبی است.
مقایسه vSAN 8، vSAN 9 و vSAN 9.1
| حوزه | vSAN 8.x | vSAN 9.0 | vSAN 9.1 |
|---|---|---|---|
| معماری Storage | عرضه و بلوغ ESA در کنار OSA | گسترش ESA و Storage Clusterهای مستقل | اتصال منعطفتر OSA و ESA و اشتراک Storage Cluster میان vCenterها |
| Compression | LZ4 در ESA؛ طراحی کمهزینه و سریع | ادامه مدل قبلی | ZSTD تنظیمشده برای vSAN، همیشه فعال و مؤثر روی Writeهای جدید |
| Global Deduplication | فاقد Deduplication سراسری ESA در سطح کلاستر | Limited Availability | GA برای کلاسترهای واجد شرایط، همراه پشتیبانی از Data-at-Rest Encryption |
| Replication | قابلیتهای Data Protection در نسلهای پایانی 8.x | Replication از vSAN به vSAN | Multi-Source Replication از vSAN، VMFS و NFS به vSAN ESA |
| Snapshot Retention | Snapshotهای سریع و Immutable در نسخههای جدیدتر 8.x | محافظت و Replication بومی گستردهتر | Retention سلسلهمراتبی GFS، عضویت مبتنی بر Tag و Manual Seeding |
| Cloud-Native Storage | CSI و Persistent Volume روی vSphere with Tanzu | افزایش Scale و یکپارچگی VCF | افزایش شدید Scale، Linked Clone، RWX برای VM Service و S3 در حالت Tech Preview |
| عملیات | مدیریت عمدتاً از vCenter و Skyline Health | دید یکپارچهتر در VCF Operations | Performance Insights، Diagnostic Action و مدیریت خودکارتر Storage Policy |
این جدول یک نکته مهم را نشان میدهد: vSAN 9.1 جایگزین معماری ESA نیست؛ مرحلهای برای بهرهبرداری کاملتر از ESA است. بسیاری از قابلیتهای شاخص این نسخه، بهخصوص Global Deduplication جدید، Replication مقصد و Compression تازه، باید با وابستگیهای ESA و Topology بررسی شوند.
تغییر اول: Compression جدید با ZSTD
در نسخههای قبلی ESA، الگوریتم LZ4 به دلیل سرعت بالا و سربار کم استفاده میشد. در vSAN 9.1، Broadcom از نسخه تنظیمشده الگوریتم Zstandard یا ZSTD استفاده کرده است. هدف این تغییر، دستیابی به Compression Ratio بهتر بدون تحمیل سربار نامتناسب به CPU و مسیر I/O است.
Compression در vSAN ESA 9.1 یک قابلیت Always-On است و در سطح بلوک 4KB عمل میکند. داده در صورت امکان با Incrementهای 512 بایتی فشرده میشود. این موضوع فقط به کاهش مصرف دیسک محدود نیست؛ داده فشردهتر به معنی ترافیک کمتر در مسیر شبکه vSAN و حجم پردازش کمتر در لایههای پایینتر Storage Stack نیز هست.
بعد از Upgrade چه اتفاقی برای دادههای قبلی میافتد؟
پس از ارتقا، Health Service نیاز به بهروزرسانی Disk Format را اعلام میکند. این مرحله طبق توضیحات رسمی یک تغییر Metadata سبک و Non-Disruptive است. دادههای موجود فوراً با ZSTD بازنویسی نمیشوند و Compression قبلی خود را نگه میدارند؛ اما وقتی خوانده و دوباره نوشته شوند، از الگوریتم جدید استفاده خواهند کرد. بنابراین انتظار مشاهده ناگهانی تمام صرفهجویی ظرفیت بلافاصله بعد از Upgrade منطقی نیست.
تغییر دوم: Global Deduplication از Limited Availability به GA رسید
در vSAN 9.0، Global Deduplication معرفی شد، اما دسترسی آن محدود بود. در vSAN 9.1 این قابلیت برای کلاسترهای پشتیبانیشده General Availability شده است. Deduplication در این معماری در سطح کل کلاستر انجام میشود، نه در محدوده یک Disk Group یا جفت Controller. هرچه دامنه Deduplication بزرگتر باشد، احتمال یافتن بلوکهای تکراری میان Workloadهای مختلف بیشتر میشود.
فرآیند Deduplication بهصورت Post-Process و در پسزمینه اجرا میشود. vSAN زمانی فعالیت را افزایش میدهد که منابع CPU اجازه دهند. طبق مستند فنی Broadcom، این قابلیت روی HCI Cluster و vSAN Storage Clusterهای 3 تا 64 Host پشتیبانی میشود.
سه محدودیت مهم Global Deduplication
- در زمان انتشار vSAN 9.1، این قابلیت برای Stretched Cluster و 2-Node Cluster پشتیبانی نمیشود.
- غیرفعالکردن Deduplication فقط پردازش پسزمینه را متوقف میکند؛ بلوکهایی که قبلاً Deduplicate شدهاند بهصورت خودکار Inflate نمیشوند.
- فعالسازی آن باید پس از بررسی نوع Workload، نسبت دادههای تکراری، Headroom ظرفیت و وضعیت منابع کلاستر انجام شود؛ عدد کاهش ظرفیت برای همه محیطها یکسان نیست.
برخلاف عرضه محدود نسخه 9، در نسخه 9.1 استفاده از Global Deduplication همراه با vSAN Data-at-Rest Encryption پشتیبانی میشود. داده برای مقایسه Hashها بهطور موقت در حافظه پردازش میشود، درحالیکه وضعیت رمزگذاریشده داده روی دیسک حفظ میشود.
تغییر سوم: OSA و ESA دیگر دو جزیره جدا نیستند
یکی از موانع عملی مهاجرت این بود که سازمانها معمولاً نمیتوانند همه نسلهای سختافزار را همزمان تعویض کنند. ممکن است چند کلاستر OSA هنوز عمر مفید داشته باشند، درحالیکه کلاسترهای جدید با ESA ساخته شدهاند. در نسخههای قبل، Mount کردن Remote Datastore میان این معماریها محدودیت داشت.
vSAN 9.1 این جداسازی را کاهش میدهد. کلاسترهای OSA و ESA میتوانند Remote Datastoreهای هر دو معماری را Mount کنند و Compute Cluster نیز میتواند همزمان به OSA و ESA متصل شود. این قابلیت به تیم زیرساخت اجازه میدهد کلاستر قدیمی را بهعنوان Compute بازاستفاده کند و Storage پرسرعت را از یک vSAN Storage Cluster جدید دریافت کند.
قابلیت مهم دیگر، اشتراک vSAN Storage Cluster در مرز چند vCenter است. در نتیجه یک کلاستر ذخیرهسازی متمرکز میتواند ظرفیت خود را در اختیار چند دامنه مدیریتی بگذارد؛ الگویی شبیه Shared Storage سنتی، اما با کنترل Policy-Based و Scale-Out.
تغییر چهارم: vSAN Protection and Recovery جدیتر شده است
نام vSAN Data Protection در VCF 9.1 به vSAN Protection and Recovery تغییر کرده است. این تغییر نام با توسعه دامنه محصول همراه است. در vSAN 9.0، Replication بومی عمدتاً از vSAN به vSAN انجام میشد. در 9.1، منبع میتواند vSAN، VMFS یا NFS باشد، ولی مقصد Replication باید یک vSAN ESA Cluster باشد.
این معماری امکان Fan-In را ایجاد میکند: چند کلاستر یا سایت منبع میتوانند Workloadهای خود را به یک Recovery Site متمرکز بفرستند. برای هر سایت، vCenter و Protection and Recovery Appliance مربوط به همان سایت لازم است و ارتباط از طریق Site Pairing برقرار میشود. برای Replication و Orchestration بین سایتها باید نقش Site Recovery Manager یا افزونه VMware Advanced Cyber Compliance نیز در طراحی لحاظ شود.
قابلیتهای عملیاتی جدید Recovery
- GFS Retention: نگهداری Snapshotها در سطوح ساعتی، روزانه، هفتگی و ماهانه بهجای FIFO ساده.
- Protection Group با Tag: ماشینهای جدید پس از دریافت Tag مناسب میتوانند خودکار وارد گروه حفاظت شوند.
- Manual Replica Seeding: انتقال فیزیکی Seed اولیه برای محیطهایی با Dataset بزرگ یا WAN محدود و سپس اجرای Differential Sync.
- On-Premises Clean Room: با افزونه Advanced Cyber Compliance میتوان محیط بازیابی ایزوله و تحت مالکیت سازمان طراحی کرد.
Manual Seeding برای دیتاسنترهای ایران اهمیت ویژهای دارد؛ زیرا Full Sync چند ده ترابایت داده روی ارتباط بینشهری یا لینک محدود، گاهی از نظر زمان و هزینه عملی نیست.
تغییر پنجم: Storage برای Kubernetes و توسعهدهندهها
در vSAN 9.1 سقف تعداد Persistent Volumeهای نوع Read Write Once برای هر Supervisor از 7,500 به 25,000 افزایش یافته و سقف سطح vCenter از 30,000 به 50,000 رسیده است. این اعداد بیشتر از آنکه برای یک کلاستر کوچک مهم باشند، برای محیطهای Multi-Tenant و Platform Engineering معنا دارند.
Linked Clone برای Persistent Volumeهای مبتنی بر First Class Disk نیز اضافه شده است. بهجای ساخت Full Cloneهای حجیم، چند محیط Development یا Test میتوانند از Base Data مشترک استفاده کنند و فقط تغییرات خود را نگه دارند. پشتیبانی RWX برای VM Service VMها، نامگذاری Kubernetes-Compliant برای Storage Policy و عملیات Snapshot یکسانتر میان VMهای سنتی و VM Service از دیگر تغییرات این حوزهاند.
Native S3 Object Storage؛ فعلاً Tech Preview
vSAN 9.1 یک پیادهسازی S3-Compatible را در حالت Tech Preview ارائه میکند. این سرویس Block، File و Object را زیر یک پلتفرم قرار میدهد و از Multi-Tenancy و Bucket-as-a-Service از مسیر VCF Automation صحبت میکند. عبارت Tech Preview بسیار مهم است: این قابلیت را نباید بدون بررسی Support Statement و محدودیتهای Release Notes، پایه یک سرویس Production یا SLA قراردادی قرار داد.
عملیات، سیاستگذاری و Stretched Cluster
VCF Operations در نسخه 9.1 الگوی Performance هر کلاستر را پایش میکند، Baseline میسازد و انحراف از رفتار معمول را برای Root Cause Analysis نمایش میدهد. همچنین اطلاعات Diagnostic vSAN و برخی اقدامهای اصلاحی از داخل VCF Console در دسترس قرار میگیرند تا جابهجایی دائمی میان چند رابط مدیریتی کمتر شود.
در بخش Storage Policy، پلتفرم میتواند بر اساس اندازه کلاستر بالاترین سطح Fault Tolerance و Erasure Coding مناسب را پیشنهاد یا اعمال کند. این Automation جای طراحی را نمیگیرد، اما خطاهای ناشی از Policyهای ناسازگار با تعداد Host را کاهش میدهد.
برای Stretched Cluster نیز امکان قراردادن کل یک Site در Maintenance Mode با Pre-Checkهای هدایتشده اضافه شده است. در سناریوی خاصی که یک Site در Maintenance باشد و Site دوم و Witness همزمان از دسترس خارج شوند، امکان Self-Recovery سایت سالم بدون وابستگی مستقیم به Support فراهم شده است.
سناریوی واقعی: مهاجرت تدریجی بدون کنارگذاشتن OSA
فرض کنید یک سازمان سه کلاستر vSAN OSA روی سختافزار نسل قبل دارد و قصد دارد یک کلاستر ESA جدید برای Workloadهای حساس بسازد. در vSAN 9.1 میتوان کلاستر ESA را بهعنوان Storage Cluster مرکزی طراحی کرد، بخشی از کلاسترهای قدیمی را به Compute-Only تبدیل کرد و Remote Datastoreهای OSA و ESA را همزمان در اختیار Workloadها گذاشت.
در سایت پشتیبان، یک ESA Cluster با دیسکهای ظرفیتمحور میتواند مقصد Multi-Source Replication برای VMهای روی vSAN، VMFS و NFS باشد. Snapshot Retention سلسلهمراتبی، Tag-Based Protection و Manual Seeding نیز هزینه عملیاتی این طراحی را کاهش میدهند. این سناریو نشان میدهد مهاجرت به 9.1 الزاماً پروژه تعویض همزمان همه سرورها نیست.
پیشنیازهای Upgrade و فعالسازی قابلیتها
- Compatibility را قطعی کنید. مدل Server، Controller، NVMe، Firmware و Driver باید با VCG و ReadyNodeهای مورد تأیید نسخه مقصد تطبیق داده شوند.
- وابستگی ESA را بررسی کنید. وجود عبارت vSAN 9.1 به معنی قابلاستفادهبودن همه قابلیتها روی هر OSA Cluster نیست.
- Topology را کنترل کنید. برای نمونه، Global Deduplication فعلاً روی 2-Node و Stretched Cluster پشتیبانی نمیشود.
- ظرفیت و CPU Headroom را اندازه بگیرید. Deduplication پسزمینه کمهزینه طراحی شده، اما بدون Baseline نباید روی نسبت صرفهجویی یا سربار آن فرض قطعی ساخت.
- Disk Format Update را در Runbook قرار دهید. فعالشدن Compression جدید بعد از Upgrade به این بهروزرسانی Metadata وابسته است.
- Recovery را بهصورت End-to-End طراحی کنید. vCenter، Protection and Recovery Appliance، Site Pairing، SRM یا ACC، شبکه Replication و فضای Retention باید یکجا دیده شوند.
- لایسنس و Entitlement را پیش از دانلود بررسی کنید. جزئیات مدل جدید را میتوانید در راهنمای لایسنس VMware 9 و 9.1 بخوانید.
آیا vSAN 9.1 در ایران قابلاستفاده است؟
از نظر معماری، vSAN یک محصول On-Premises است و برای اجرای روزمره Storage به سرویس Cloud عمومی وابستگی دائمی ندارد. VCF نیز مسیر رسمی Online Depot و Offline Depot را برای محیطهای متصل و Air-Gapped ارائه میکند. بنابراین پیادهسازی فنی در یک دیتاسنتر Disconnected امکانپذیر است.
محدودیت اصلی در ایران معمولاً خود Data Path محصول نیست؛ زنجیره تهیه قانونی لایسنس، Entitlement، دسترسی به Broadcom Support Portal، دریافت Binary و Patch، فعالسازی Depot و دریافت Support رسمی است. نکته مهم این است که از VCF Installer 9.1، Broadcom استفاده از Activation Code را جایگزین Download Token کرده است. برای دریافت آن باید Software Depot ID در VCF Installer یا VCF Download Tool ساخته و در VCF Business Services ثبت شود.
در محیط آفلاین، همچنان یک سیستم واسط متصل برای دریافت Bundleها و انتقال آنها به Offline Depot لازم است. داشتن فایل ISO بهتنهایی برای بهرهبرداری پایدار کافی نیست؛ Compatibility Data، Patchها، Lifecycle Bundleها، Activation Code معتبر و مسیر پشتیبانی باید از ابتدا در طرح تأمین دیده شوند.
نتیجه عملی این است: vSAN 9.1 در ایران از نظر فنی قابل پیادهسازی است، اما قابل پشتیبانی و قابل بهروزرسانیبودن آن به شیوه تأمین Entitlement و دسترسی سازمان به سرویسهای Broadcom وابسته است. پیش از طراحی Production باید این بخش بهصورت قراردادی و مستند روشن شود.
آیا باید از vSAN 8 یا 9 به 9.1 مهاجرت کنیم؟
برای یک محیط پایدار vSAN 8 که سختافزار آن در VCG نسخه 9.1 تأیید نشده، صرف وجود Compression بهتر دلیل کافی برای Upgrade نیست. ابتدا چرخه عمر Hardware و Firmware را بررسی کنید. اما اگر سازمان به یکی از موارد زیر نیاز دارد، نسخه 9.1 ارزش بررسی جدی دارد:
- کاهش ظرفیت مصرفی در ESA با Global Deduplication پشتیبانیشده و Compression جدید؛
- همزیستی بلندمدت کلاسترهای OSA و ESA؛
- Recovery متمرکز از منابع vSAN، VMFS و NFS؛
- Retention عمیق برای مقابله با Ransomware؛
- Scale بالاتر برای VKS و Persistent Volumeها؛
- مدیریت Storage چند vCenter و چند Site از مدل یکپارچهتر VCF.
برای Deployment جدید، رفتن مستقیم به 9.1 معمولاً منطقیتر از توقف روی 9.0 است؛ به شرط آنکه BOM، Compatibility، Entitlement و محدودیت قابلیتهای Tech Preview پیش از اجرا کنترل شده باشند. در یک مسیر حرفهای آموزش VCF و آموزش مجازی سازی، یادگیری vSAN باید همزمان شامل SPBM، ESA، Failure Domain، Lifecycle و Protection باشد؛ چون Storage Policy بدون شناخت معماری فیزیکی، فقط یک تنظیم در رابط کاربری است.
پرسشهای متداول درباره vSAN 9.1
آیا Global Deduplication در vSAN 9.1 بهصورت GA ارائه شده است؟
بله. این قابلیت که در vSAN 9.0 دسترسی محدود داشت، در 9.1 برای کلاسترهای پشتیبانیشده GA شده است. روی HCI و Storage Clusterهای 3 تا 64 Host پشتیبانی میشود، اما در زمان انتشار برای 2-Node و Stretched Cluster پشتیبانی نمیشود.
آیا بعد از Upgrade همه دادهها فوراً با ZSTD فشرده میشوند؟
خیر. دادههای موجود تا زمانی که خوانده و دوباره نوشته نشوند Compression قبلی را حفظ میکنند. Writeهای جدید پس از Update شدن Disk Format از روش جدید استفاده میکنند.
آیا OSA در vSAN 9.1 حذف شده است؟
خیر. یکی از ارزشهای 9.1 دقیقاً انعطاف بیشتر برای استفاده همزمان از OSA و ESA در Remote Datastoreها و بازاستفاده از کلاسترهای قدیمی است.
آیا S3 Object Storage در vSAN 9.1 برای Production آماده است؟
در معرفی رسمی این قابلیت با وضعیت Tech Preview اعلام شده است. استفاده Production باید فقط پس از بررسی Release Notes، Support Statement و وضعیت دقیق Build انجام شود.
آیا Replication از SAN خارجی به vSAN ممکن است؟
اگر VM روی VMFS یا NFS قرار دارد، Multi-Source Replication در 9.1 میتواند آن را به vSAN ESA مقصد محافظت کند. طراحی بینسایتی به Protection and Recovery Appliance و برحسب سناریو به SRM یا ACC وابسته است.
برای آموزش VVF و آموزش VCF، یادگیری کدام بخشهای vSAN ضروری است؟
برای مسیر VVF باید SPBM، ESA و OSA، Disk Group و Storage Pool، Failure Domain، Availability Policy، Capacity Planning و Lifecycle را شناخت. در مسیر VCF، این مباحث با Storage Cluster، VCF Operations، VKS، Multi-Site Protection، Offline Depot و Automation تکمیل میشوند.
