در بسیاری از سازمانها، ساخت یک ماشین مجازی برای دیتابیس کار سختی نیست؛ بخش دشوار از جایی شروع میشود که باید دهها یا صدها نمونه PostgreSQL، MySQL و SQL Server را با نسخه، ظرفیت، سیاست پشتیبانگیری، شبکه، دسترسی و چرخه وصلهگذاری یکسان اداره کرد. VMware Data Services Manager 9.1 یا DSM 9.1 قرار است همین فاصله میان «تحویل زیرساخت» و «ارائه دیتابیس بهعنوان سرویس» را در VMware Cloud Foundation پر کند.
مهمترین تغییر این نسخه، GA شدن Microsoft SQL Server 2022 است. SQL Server در DSM 9.0 بهصورت Tech Preview وارد شد؛ اما در 9.1 به یک Data Service تولیدی در کنار PostgreSQL و MySQL تبدیل شده است. بااینحال، DSM بخشی رایگان از هسته VCF نیست. Broadcom آن را یک VCF Advanced Service با مجوز جداگانه معرفی میکند و مجوز خود SQL Server نیز باید مستقل از لایسنس DSM و VCF بررسی شود.
VMware Data Services Manager 9.1 دقیقاً چیست؟
DSM یک پلتفرم Database-as-a-Service برای استقرار، حاکمیت و عملیات روز دوم دیتابیسها روی زیرساخت VMware است. مدیر زیرساخت بهجای ساختن دستی VM، نصب سیستمعامل و موتور دیتابیس و تحویل آن به DBA، سیاستهایی تعریف میکند که مشخص میکنند چه موتور و نسخهای، روی کدام Compute و Storage Policy، با چه شبکه، اندازه، Backup Location و سطح دسترسی قابل مصرف است.
توسعهدهنده یا تیم محصول سپس از کاتالوگ VCF Automation، رابط DSM یا API، سرویس مجاز را درخواست میکند. DSM استقرار را طبق Guardrailهای زیرساخت انجام میدهد و عملیاتهایی مانند Backup، Restore، Patch، Scale، Clone و Monitoring را تا جایی که موتور و Topology انتخابشده پشتیبانی میکنند، در یک مدل متمرکز قرار میدهد.
بنابراین DSM جایگزین خود PostgreSQL، MySQL یا SQL Server نیست. همچنین یک ابزار عمومی مدیریت هر دیتابیسی که قبلاً در هر VM نصب شده باشد محسوب نمیشود. ارزش آن در ایجاد یک Fleet استاندارد و Policy-Driven از دیتابیسهای Provisionشده تحت مدیریت DSM است.
جایگاه DSM 9.1 در معماری VCF
در VCF 9.1، DSM در مرز چند لایه قرار میگیرد: vSphere و Storage منابع را فراهم میکنند؛ شبکه میتواند بر پایه VDS یا NSX طراحی شود؛ VCF Automation تجربه Self-Service و چندمستاجری را ارائه میدهد؛ VCF Operations میتواند دید عمیقتری از زیرساخت و Metricها بدهد؛ و DSM چرخه عمر Data Service را مدیریت میکند.
Provider و Control Plane
Provider VM نقطه مدیریتی اصلی DSM است و تنظیمات، Policyها، ارتباط با vCenter و عملیات Fleet را نگه میدارد. افزونه DSM در vSphere Client نیز برای استقرار و مدیریت اجزای سرویس استفاده میشود. این لایه باید DNS، NTP، Certificate، مسیرهای شبکه و Repositoryهای لازم را بهدرستی ببیند؛ خطای این پیشنیازها معمولاً خود را در مراحل بعدی بهشکل Provisioning ناقص یا Data Service با وضعیت Critical نشان میدهد.
Infrastructure Policy و Data Service Policy
Infrastructure Policy مرز مصرف منابع را تعیین میکند: Cluster یا Compute، Storage Policy، شبکه، Namespace و اجزای زیرساختی مجاز. Data Service Policy آن زیرساخت را به سرویس قابل مصرف تبدیل میکند و موتور، نسخه، Topology، Backup، Size و گزینههای مجاز را برای یک Tenant یا گروه مشخص محدود میسازد.
این تفکیک مهم است. تیم زیرساخت لازم نیست دسترسی مستقیم vCenter را به توسعهدهنده بدهد و تیم برنامه نیز برای هر دیتابیس تیکت طراحی شبکه یا ساخت VM باز نمیکند. Self-Service به معنی حذف کنترل نیست؛ بلکه کنترل از اجرای دستی به Policy منتقل میشود.
Consumption Operator و VCF Automation
برای مصرف دیتابیس در Organization Portal، سرویس DSM و Consumption Operator روی Supervisor آماده میشوند و DSM به VCF Automation متصل میشود. Tenant در محدوده Organization، Project و Namespace خود سرویس میسازد. Broadcom در Release Notes نسخه 9.1 اعلام کرده که Self-Service از رابط Organization برای هر سه موتور SQL Server، MySQL و PostgreSQL پشتیبانی کامل دارد.
این اتصال برای معماری Application Platform معنا دارد: یک تیم میتواند VM، کلاستر VKS و دیتابیس را از یک مدل کاتالوگی دریافت کند. برای شناخت لایه Automation، مقاله VCF Automation 9.1 و VCF Operations Orchestrator و برای لایه Kubernetes مقاله VKS 3.6 در VCF 9.1 مکمل مستقیم این مطلباند.
چه دیتابیسهایی در DSM 9.1 پشتیبانی میشوند؟
| Data Service | جایگاه در 9.1 | قابلیت شاخص | نکته طراحی |
|---|---|---|---|
| PostgreSQL | GA | Lifecycle، HA، Backup/Restore، Monitoring و pgvector | برای RAG و Vector Search مناسب است، اما Benchmark و طراحی ظرفیت همچنان ضروری است |
| MySQL | GA | مدیریت Policy-Driven و Fast Cloning | Clone سریع برای Dev/Test ارزشمند است؛ Retention و مصرف Storage باید کنترل شود |
| Microsoft SQL Server 2022 | GA در DSM 9.1 | Standalone یا سهگرهای Always On Availability Group، AD و DNS | مجوز Microsoft، Windows/AD، Edition و Design مربوط به AG جداگانه بررسی میشوند |
فهرست دقیق Buildها و Cumulative Updateهای پشتیبانیشده باید هنگام طراحی از ماتریس همان Build DSM خوانده شود. عبارت «SQL Server 2022» به این معنی نیست که هر ISO، CU یا ترکیب سیستمعامل دلخواه پشتیبانی میشود. همین اصل درباره شاخههای PostgreSQL و MySQL هم صدق میکند.
قابلیتهای جدید VMware Data Services Manager 9.1
SQL Server 2022 از Tech Preview به GA رسید
در DSM 9.0، SQL Server یک Technical Preview بود و نباید برای بارکاری تولیدی بهعنوان قابلیت دارای پشتیبانی کامل معرفی میشد. DSM 9.1 این وضعیت را تغییر داد. اکنون Editionهای Standard، Enterprise و Developer در چارچوب اعلامشده محصول قابل استفادهاند و ابزارهای متعارف DBA مانند SQL Server Management Studio، PowerShell، SQLCMD و SQL Server Agent همچنان تجربه آشنای SQL Server را حفظ میکنند.
برای محیط Production میتوان یک Always On Availability Group سهگرهای ساخت و برای Dev/Test یا سرویسهای سادهتر از حالت تکVM استفاده کرد. DSM فرایند ساخت زیرساخت، اتصال به Active Directory، ثبت DNS و Policy را خودکار میکند؛ اما مسئولیت طراحی RPO/RTO، Quorum، Failure Domain، ظرفیت شبکه و مجوز SQL Server از بین نمیرود.
Self-Service یکپارچه برای هر سه موتور
در 9.1، تجربه مصرف دیتابیس از VCF Automation Organization UI برای PostgreSQL، MySQL و SQL Server کاملتر شده است. Tenant فقط گزینههایی را میبیند که Provider در Data Service Policy مجاز کرده است. این مدل برای Service Provider داخلی یا سازمان چندواحدی مفید است، چون Quota، Namespace Isolation و سیاستهای متفاوت Production و Dev/Test را میتوان بدون ساخت چند زیرساخت مدیریتی مستقل ارائه کرد.
PostgreSQL برای بارکاریهای AI و pgvector
پشتیبانی از pgvector باعث میشود PostgreSQL تحت مدیریت DSM بتواند نقش Vector Store را در برخی معماریهای RAG و Semantic Search ایفا کند. این ارتباط با VCF Private AI Services 9.1 مهم است: سرویس AI برای داده برداری به یک دیتابیس خارجی نیاز دارد و DSM میتواند PostgreSQL استانداردشده را فراهم کند.
بااینحال، اضافهشدن Extension بهتنهایی دیتابیس را برای هر مقیاس AI آماده نمیکند. اندازه Embedding، Index Type، نرخ Ingest، Memory، Storage Latency، Backup Window و الگوی Query باید با داده واقعی آزمایش شوند. DSM عملیات را استاندارد میکند؛ طراحی منطقی دیتابیس و Performance Engineering همچنان وظیفه تیم داده است.
Fast Cloning برای MySQL
Fast Clone برای ساخت سریع نسخههای Dev/Test از MySQL، زمان انتظار تیم توسعه را کاهش میدهد. سناریوی درست این است که Snapshot یا Clone تحت Policy مشخص، با TTL و Masking داده حساس عرضه شود. اگر چرخه حذف، Quota و نامگذاری تعریف نشود، همان قابلیتی که سرعت توسعه را بالا میبرد میتواند به انباشت Cloneهای بدون مالک و مصرف پیشبینینشده Storage منجر شود.
Monitoring و اتصال به VCF Operations
DSM Metricها و Alertهای سطح Data Service را ارائه میکند و در سناریوهای پشتیبانیشده امکان ارسال Metric به VCF Operations وجود دارد. مزیت، همبستگی رفتار دیتابیس با Compute، Memory و Storage زیرین است. اگر Query کند شده، تیم میتواند بررسی کند آیا علت داخل موتور است یا همزمان Storage Latency، CPU Contention یا کمبود ظرفیت زیرساخت رخ داده است.
این یکپارچگی جای ابزارهای تخصصی Query Tuning یا تجربه DBA را نمیگیرد. VCF Operations تصویر زیرساختی و روندها را غنی میکند؛ Execution Plan، Schema Design، Locking و منطق برنامه همچنان نیازمند ابزار و تخصص موتور دیتابیساند. برای شناخت این لایه، مقاله VCF Operations 9.1 را ببینید.
مقایسه DSM در نسل vSphere 8، VCF 9.0 و VCF 9.1
| موضوع | نسل vSphere 8 / DSM 2.x | DSM 9.0 | DSM 9.1 |
|---|---|---|---|
| جایگاه محصول | پلتفرم مستقلتر برای Data Services روی vSphere | VCF Advanced Service با اتصال عمیقتر به VCF Automation | Advanced Service یکپارچه با VCF 9.1 و مجوز جداگانه |
| PostgreSQL و MySQL | موتورهای اصلی تولیدی | GA با عملیات Fleet و Self-Service توسعهیافته | GA؛ pgvector، Fast Clone و تجربه مصرف یکپارچهتر |
| SQL Server | در دامنه اصلی DSM نبود | Tech Preview؛ سپس قابلیتهای تکمیلی در شاخه 9.0.x | SQL Server 2022 بهصورت GA |
| VCF Automation | وابستگی بیشتر به گردشکار DSM/vSphere | Data Service Policy، Quota و Namespace Self-Service | مصرف کامل هر سه موتور در Organization UI |
| سناریوی AI | PostgreSQL قابل استفاده، اما اتصال پلتفرمی محدودتر | همراستایی با Private AI و Data Serviceهای VCF | PostgreSQL/pgvector بهعنوان لایه داده نزدیک PAIS و VKS |
این جدول مسیر محصول را نشان میدهد، نه Upgrade Matrix. برای ارتقا باید Release Notes و Interoperability همان Build بررسی شود. طبق KB رسمی Broadcom، ارتقای مستقیم DSM 2.2.3 به 9.1 پشتیبانی نمیشود و مسیر مرحلهای 2.2.3 به 9.0 و سپس 9.1 لازم است.
سناریوی واقعی: DBaaS برای تیمهای توسعه و DBA
فرض کنید یک سازمان سه گروه بارکاری دارد: سامانه مالی روی SQL Server، اپلیکیشنهای جدید روی PostgreSQL و سرویسهای وب روی MySQL. در مدل سنتی، هر تیم برای VM، IP، Storage، نصب موتور، Backup و دسترسی چند تیکت جدا باز میکند. نتیجه معمولاً چند الگوی نامگذاری، نسخههای Patch متفاوت و Backupهایی است که کیفیت آنها فقط هنگام Restore مشخص میشود.
در DSM، تیم پلتفرم سه دسته Policy طراحی میکند:
- Production: Storage Policy سریع و مقاوم، Backup خارج از کلاستر، Monitoring سختگیرانه، اندازههای محدود و Topology دارای HA.
- Dev/Test: اندازه کوچکتر، Clone سریع، Retention کوتاه و Quota مشخص برای هر Project.
- Data/AI: PostgreSQL دارای نسخه و Extension تأییدشده، ظرفیت Memory و Storage متناسب با Vector Search و اتصال کنترلشده به VKS یا PAIS.
توسعهدهنده سرویس را بدون دسترسی به vCenter دریافت میکند؛ DBA همچنان مالک Schema، Performance و Data Protection منطقی است؛ و تیم VCF ظرفیت، شبکه، Storage و Lifecycle پلتفرم را کنترل میکند. ارزش DSM در حذف نقشها نیست، بلکه در تعریف مرز مسئولیت روشن میان آنهاست.
نیازمندیهای مهم پیش از پیادهسازی
نسخه و سازگاری
VCF، vCenter، DSM، Supervisor Service و Data Service Bundleها باید در ترکیب پشتیبانیشده باشند. نام 9.1 در دو محصول بهتنهایی اثبات سازگاری همه Patchها نیست. Upgrade Sequence، Release Notes و Compatibility Guide باید پیش از Change Window بررسی شوند.
DNS، NTP و Certificate
Provider، Supervisor، Database VMها، Active Directory و Clientها باید نامها را بهدرستی Resolve کنند و زمان هماهنگ داشته باشند. برای SQL Server، ثبت DNS و Windows Authentication به طراحی درست AD وابسته است. Certificate خودامضا برای Lab قابل تحمل است، اما در Production باید Trust Chain، SAN و فرایند Renewal از ابتدا طراحی شود.
شبکه و IPAM
Management Network، Database Workload Network، مسیر دسترسی Client، DNS، Backup Repository و Registry باید مشخص باشند. استفاده از NSX امکان Segmentation و سیاستگذاری غنیتری میدهد، اما پیچیدگی عیبیابی را نیز افزایش میدهد. KB 442248 نمونهای است که Provisioning PostgreSQL بهعلت بازنگشتن پاسخ DNS در مسیر NSX Gateway Firewall متوقف میشود؛ پس Reachability Test باید قبل از نصب انجام شود.
Storage و Backup
Storage Policy باید بر اساس IOPS، Latency، Failure Tolerance و ظرفیت واقعی دیتابیس تعریف شود، نه صرفاً برچسب Gold یا Silver. Backup Location، Retention، Encryption و Restore Test نیز باید جزو طراحی باشند. Snapshot سریع یا Clone، جای Backup مستقل و آزمودهشده را نمیگیرد.
محدودیتها و Known Issueهای مهم DSM 9.1
- Multi-Zone در 9.1.0: KB 447948 میگوید Data Service Policy در DSM 9.1.0 فقط Infrastructure Policyهای Single-Zone را نمایش میدهد. پشتیبانی Multi-Zone برای 9.1.1 برنامهریزی شده است؛ تا آن زمان باید Policy تکZone ساخت.
- Log Bundle روی NSX: طبق KB 447128، جمعآوری Log دیتابیس برای Clusterهای مستقر روی NSX Topology ممکن است شکست بخورد. این محدودیت را پیش از تدوین Runbook پشتیبانی در نظر بگیرید.
- Namespace ساختهشده با Quick Start: در برخی نامهای طولانی، DSM نمیتواند Namespace متناظر را بسازد و خطای "binding" not found رخ میدهد. KB 445160 توصیه میکند تا ارائه Fix از Workflow عادی ساخت Organization، Project و Namespace استفاده شود.
- PostgreSQL 12 و 13: Release Notes اعلام کرده DSM 9.1.0 آخرین Release پشتیبان این دو شاخه است و در Maintenance Release بعدی حذف میشوند. برنامه Upgrade دیتابیس باید قبل از ارتقای DSM آماده باشد.
لایسنس DSM و SQL Server
Broadcom صریحاً DSM 9.1 را VCF Advanced Service با License جدا از VCF Core معرفی کرده است. بنابراین وجود DSM در مستندات یا Console VCF به معنی Entitlement رایگان آن نیست. SKU، Metric، Support و حق دریافت Bundle باید از قرارداد و Broadcom Support Portal مشتری کنترل شود.
برای SQL Server نیز پذیرش EULA در فرایند ساخت، جای مجوز قانونی Microsoft را نمیگیرد. Edition انتخابشده، تعداد Core، Software Assurance، Mobility Rights و مدل لایسنس Windows/SQL باید توسط مسئول لایسنس سازمان با شرایط جاری Microsoft تطبیق داده شود. DSM عملیات را خودکار میکند، اما مجوز موتور تجاری را تأمین نمیکند.
DSM 9.1 در محیط آفلاین و شرایط ایران
Broadcom برای VCF Automation در Network-Isolated Environment مسیر رسمی ارائه کرده است: Bundleها و Imageها باید در محیط متصل دریافت، اعتبارسنجی و به Private Registry داخلی منتقل شوند؛ سپس Supervisor و Consumption Operator از Registry داخلی استفاده کنند. این طراحی فقط Mirror کردن یک OVA نیست. Provider Update Bundle، Data Service Versionها، Container Imageها، Registry Certificate، DNS و مسیر Backup باید در Runbook آفلاین دیده شوند.
در ایران، پیش از خرید یا اجرای Production باید دسترسی واقعی حساب سازمان به Broadcom Support Portal، Entitlement دانلود DSM، Update Bundleها و اسناد مجوز آزموده شود. Download Token یا Registry Mirror نباید از منبع نامعتبر تهیه شود. برای SQL Server نیز دسترسی قانونی به Media، CU و مجوز Microsoft موضوعی مستقل است.
راهکار عملی برای محیط جدا از اینترنت، ساخت یک ایستگاه انتقال کنترلشده است: دریافت از حساب مجاز، ثبت Hash و Manifest، اسکن امنیتی، انتقال به Registry/Repository داخلی، نگهداری نسخه قبلی و اجرای Update ابتدا در Lab. اگر این زنجیره تعریف نشده باشد، DSM در روز نصب کار میکند اما در نخستین Patch یا افزودن نسخه دیتابیس به بنبست عملیاتی میرسد.
این موضوع در مسیر آموزش VMware کجا قرار میگیرد؟
DSM نقطه شروع آموزش مجازی سازی نیست. برای فهم درست آن باید ابتدا vSphere، Storage Policy، شبکه، DNS، Certificate و مفاهیم HA را شناخت؛ سپس VCF Automation، Namespace و Self-Service را یاد گرفت و بعد وارد DBaaS شد. در مسیر آموزش VMware ابرکلاس، DSM یک مهارت Advanced Service برای VCF Admin، Platform Engineer و DBA زیرساخت است.
در آموزش VCF باید روی مرز مسئولیت بین VI Admin، DSM Provider Admin، DBA و Tenant تمرکز شود. آموزش VVF برای پایه Compute و Storage مفید است، اما تجربه چندمستاجری کامل DSM با VCF Automation و Advanced Services فراتر از یک پیادهسازی صرفاً VVF است. تمرین درست نیز فقط «ساخت یک PostgreSQL» نیست؛ باید Policy، Backup، Restore، Patch، Failure، Quota و Audit را پوشش دهد.
جمعبندی فنی
VMware Data Services Manager 9.1 دیتابیس را از یک VM سفارشی به سرویسی Policy-Driven در VCF نزدیک میکند. مزیت اصلی، استانداردسازی چرخه کامل PostgreSQL، MySQL و اکنون SQL Server 2022 است: Provider Guardrail تعیین میکند، Tenant Self-Service مصرف میکند و عملیات Backup، Patch، Monitoring و Scale در یک Fleet قابل اداره قرار میگیرد.
بااینحال، DSM ابزار جادویی حذف DBA یا طراحی زیرساخت نیست. موفقیت آن به Compatibility، DNS و NTP، Network Path، Storage Policy، Backup آزمودهشده، Registry و Repository، مدل مسئولیت و مجوزهای جداگانه وابسته است. برای سازمانی با چند تیم و تعداد زیاد دیتابیس، این استانداردسازی ارزشمند است؛ برای چند دیتابیس محدود و ثابت، هزینه و پیچیدگی Control Plane باید با روش مدیریت فعلی مقایسه شود.
پرسشهای متداول
آیا VMware Data Services Manager 9.1 داخل لایسنس پایه VCF است؟
خیر. Broadcom آن را VCF Advanced Service با مجوز جداگانه معرفی میکند. Entitlement دقیق باید از قرارداد مشتری بررسی شود.
آیا SQL Server در DSM 9.1 برای Production پشتیبانی میشود؟
بله. SQL Server 2022 در DSM 9.1 از Tech Preview نسخه 9.0 به GA رسیده است. Build، CU، Edition، Topology و مجوز Microsoft باید مطابق اسناد جاری کنترل شوند.
DSM 9.1 چه دیتابیسهایی را مدیریت میکند؟
موتورهای اصلی پشتیبانیشده PostgreSQL، MySQL و Microsoft SQL Server هستند. DSM یک ابزار عمومی برای Onboard کردن خودکار هر دیتابیس موجود یا موتورهایی مانند Oracle نیست.
آیا DSM بدون VCF Automation قابل استفاده است؟
DSM رابط و API مدیریتی خود را دارد؛ اما تجربه چندمستاجری و Self-Service یکپارچه VCF از اتصال به VCF Automation، Organization، Project و Namespace حاصل میشود.
آیا Multi-Zone در DSM 9.1.0 پشتیبانی میشود؟
برای Data Service Policy، نسخه 9.1.0 محدود به Infrastructure Policy تکZone است. Broadcom رفع این محدودیت را برای 9.1.1 اعلام کرده؛ وضعیت Build جاری باید پیش از طراحی دوباره بررسی شود.
آیا میتوان DSM 9.1 را در محیط Air-Gapped اجرا کرد؟
بله، مسیر رسمی Network-Isolated وجود دارد؛ اما Private Registry، Bundleهای DSM، Imageهای Data Service، Certificate، DNS و فرایند انتقال و بهروزرسانی باید از قبل آماده شوند.
منابع رسمی
- VMware Data Services Manager 9.1 Release Notes
- معرفی DSM 9.1 و SQL Server GA، ۵ مه ۲۰۲۶
- SQL Server DBaaS در DSM 9.1، ۱۴ مه ۲۰۲۶
- معماری و اجزای DSM 9.1
- Detailed Design رسمی DSM برای VCF 9.1
- KB 447948: محدودیت Multi-Zone در DSM 9.1.0
- KB 447128: مشکل جمعآوری Log روی NSX Topology
- KB 445160: خطای binding در Namespaceهای Quick Start
- KB 453247: مسیر ارتقای DSM 2.2.3 به 9.1