VMware vSAN 8 and Earlier راهکاری برای ذخیرهسازی نرمافزارمحور (Software-Defined Storage) در زیرساختهای مجازی VMware است که با تجمیع منابع ذخیرهسازی سرورهای سازگار، یک فضای ذخیرهسازی توزیعشده و قابل مدیریت ایجاد میکند. نسخه هشتم با معرفی معماری Express Storage Architecture یا ESA، در کنار معماری پیشین OSA، امکان انتخاب میان حفظ زیرساخت موجود و استفاده از ذخیرهسازی بهینهشده برای سختافزارهای NVMe را فراهم کرد. این راهکار برای دیتاسنترهای سازمانی، زیرساختهای HCI، ماشینهای مجازی و ابر خصوصی کاربرد دارد؛ با این شرط که معماری، سختافزار، شبکه و مجوزهای نرمافزاری متناسب با نیاز واقعی سازمان انتخاب شوند.
VMware vSAN یک فناوری ذخیرهسازی توزیعشده است که در اکوسیستم مجازیسازی VMware فعالیت میکند. این فناوری منابع ذخیرهسازی محلی میزبانهای ESXi را در قالب یک Datastore منطقی در اختیار ماشینهای مجازی قرار میدهد و بسیاری از عملیات ذخیرهسازی را با مدیریت متمرکز زیرساخت هماهنگ میکند.
ترکیب vSAN با پلتفرم VMware vSphere امکان مدیریت پردازش، حافظه، ماشینهای مجازی و ذخیرهسازی را در یک اکوسیستم مشترک فراهم میسازد. این یکپارچگی بهویژه در سازمانهایی ارزشمند است که قصد توسعه زیرساخت مجازی خود را بدون افزایش پیچیدگی مدیریت چند سامانه مستقل دارند.
vSAN مخفف Virtual SAN است؛ یک راهکار Software-Defined Storage که با توزیع و مدیریت دادهها میان میزبانهای سازگار، ذخیرهسازی اشتراکی موردنیاز ماشینهای مجازی را فراهم میکند. حفاظت و محل قرارگیری دادهها بر اساس سیاستهای ذخیرهسازی تعیین میشود.
در معماری Hyper-Converged Infrastructure یا HCI، منابع پردازشی، ذخیرهسازی و اجزای موردنیاز شبکه در یک زیرساخت نرمافزارمحور هماهنگ میشوند. vSAN نقش لایه ذخیرهسازی این معماری را بر عهده دارد. برای شناخت ساختار و مزایای این مدل میتوان معماری زیرساخت Hyperconverged را نیز بررسی کرد.
استفاده از vSAN الزاماً به معنای حذف تمام تجهیزات SAN یا NAS سازمان نیست. در محیطهایی که تجهیزات ذخیرهسازی خارجی همچنان پاسخگوی نیازهای ظرفیت، کارایی و تداوم خدمت هستند، معماری سنتی یا ترکیبی نیز میتواند توجیه فنی و اقتصادی داشته باشد.
نسخههای اولیه vSAN بر ذخیرهسازی توزیعشده، استفاده از دیسکهای محلی و مدیریت یکپارچه با vSphere تمرکز داشتند. در نسلهای بعدی، قابلیتهایی مانند All-Flash، سیاستهای پیشرفته حفاظت داده، Deduplication و Compression در معماریهای پشتیبانیشده، رمزنگاری، مدیریت سلامت و بهینهسازی کارایی توسعه یافتند.
تحول شاخص در vSAN 8 معرفی Express Storage Architecture بود؛ معماری جدیدی که برای استفاده مؤثرتر از SSDهای NVMe، پردازندههای مدرن و شبکههای پرسرعت طراحی شد. با این حال OSA نیز در vSAN 8 باقی ماند تا سازمانها بتوانند بر اساس سختافزار و الزامات خود، معماری مناسب را انتخاب کنند.
مهمترین تصمیم فنی هنگام انتخاب VMware vSAN 8، تعیین معماری ذخیرهسازی است. OSA و ESA هر دو از مدیریت ذخیرهسازی توزیعشده پشتیبانی میکنند، اما نحوه سازماندهی دیسکها، پردازش I/O، مدیریت ظرفیت و الزامات سختافزاری آنها متفاوت است.
OSA معماری اصلی vSAN است و از ساختار Disk Group استفاده میکند. در این ساختار، دستگاه Cache و دستگاههای Capacity نقشهای جداگانه دارند. این مدل برای طیف متنوعی از سختافزارهای تأییدشده، از جمله پیکربندیهای Hybrid و All-Flash، طراحی شده است.
در محیطهایی که زیرساخت قبلی vSAN از سختافزارهای سازگار با OSA استفاده میکند، ارتقا به نسخه پشتیبانیشده vSAN 8 با حفظ معماری OSA میتواند گزینه عملیتری نسبت به بازطراحی کامل باشد.
ESA با بازطراحی مسیر داده و ساختار ذخیرهسازی، وابستگی به Disk Groupهای سنتی و دستگاه Cache اختصاصی را حذف میکند. این معماری از Storage Pool مبتنی بر دستگاههای ذخیرهسازی مورد تأیید استفاده میکند و برای بهرهبرداری از SSDهای NVMe با کارایی بالا بهینه شده است.
سیستم فایل Log-Structured، بهبود مسیر نوشتن داده، فشردهسازی کارآمدتر و موتور جدید Snapshot از ویژگیهای مهم ESA هستند. این قابلیتها میتوانند در Workloadهای مناسب، کارایی و بهرهوری ظرفیت را در مقایسه با OSA افزایش دهند؛ اما میزان بهبود به سختافزار، اندازه I/O، الگوی دسترسی و پیکربندی وابسته است.
نقش NVMe در این معماری اهمیت زیادی دارد. برای شناخت ویژگیهای این فناوری و تفاوت آن با رابطهای ذخیرهسازی قدیمیتر، مطالعه فناوری NVMe در ذخیرهسازی سریع مفید است.
| معیار | vSAN OSA | vSAN ESA |
|---|---|---|
| نوع معماری | Original Storage Architecture | Express Storage Architecture |
| سازماندهی ذخیرهسازی | Disk Group با لایه Cache و Capacity | Storage Pool بدون Cache Disk اختصاصی |
| نوع درایو | دستگاههای سازگار SAS، SATA یا NVMe بر اساس طراحی | دستگاههای NVMe تأییدشده برای ESA |
| مسیر پردازش I/O | معماری اصلی vSAN | مسیر داده بازطراحیشده و Log-Structured |
| حفاظت داده | RAID-1 و RAID-5/6 بر اساس شرایط پشتیبانی | RAID-1 و Erasure Coding بهینهشده |
| فشردهسازی | بر اساس تنظیمات و قابلیتهای معماری OSA | فشردهسازی بهینهتر با کنترل سیاستمحور |
| Snapshot | مکانیزم Snapshot مرتبط با معماری اصلی | موتور Native Snapshot بازطراحیشده |
| سختافزار | گزینههای سازگار متنوعتر | نیازمند پیکربندی تأییدشده ESA |
| سناریوی مناسب | حفظ یا ارتقای زیرساخت سازگار موجود | پیادهسازی جدید با اولویت کارایی و بهرهوری |
تبدیل معماری یک کلاستر OSA به ESA صرفاً با فعالکردن یک گزینه یا ارتقای نسخه نرمافزار انجام نمیشود. برای مهاجرت باید سازگاری سختافزار، روش انتقال Workload، ظرفیت مقصد، الزامات شبکه و نسخه نرمافزار بررسی شود. در بسیاری از سناریوها ایجاد کلاستر ESA جدید و انتقال کنترلشده ماشینهای مجازی راهکار مناسبتری است.
ارزش اصلی VMware vSAN 8 فقط در تجمیع ظرفیت دیسکها نیست؛ بلکه در مدیریت سیاستمحور دادهها، هماهنگی با ماشینهای مجازی و امکان توسعه ظرفیت و کارایی در یک زیرساخت استاندارد قرار دارد.
معماری ESA با مسیر پردازش بهینهشده، امکان استفاده مؤثرتر از توان عملیاتی NVMe را فراهم میکند. نتیجه واقعی به تأخیر شبکه، سختافزار و الگوی I/O بستگی دارد.
فشردهسازی داده و سیاستهای حفاظت مبتنی بر Erasure Coding میتوانند ظرفیت مؤثر را افزایش دهند. میزان صرفهجویی برای همه دادهها یکسان نیست.
مدیران زیرساخت میتوانند وضعیت Datastore، سلامت کلاستر و سیاستهای ذخیرهسازی را از طریق ابزارهای مدیریتی VMware بررسی کنند.
Storage Policy-Based Management امکان تعیین سطح تحمل خطا و سایر ویژگیهای قابل پشتیبانی را برای اشیای ذخیرهسازی ماشینهای مجازی فراهم میکند.
ظرفیت و توان پردازشی کلاستر با افزودن میزبانها یا منابع سازگار قابل توسعه است؛ البته با رعایت محدودیتهای نسخه، معماری و طراحی کلاستر.
هماهنگی با vSphere، vCenter و برخی قابلیتهای VMware Cloud Foundation به سادهتر شدن مدیریت چرخه عمر زیرساخت کمک میکند.
یکی از تغییرات مهم ESA بازطراحی مسیر نوشتن داده است. استفاده از ساختار Log-Structured و بهینهسازی پردازش دادهها میتواند Write Amplification را کاهش دهد و اجرای Workloadهای دارای I/O سنگین را بهبود بخشد.
در بهروزرسانیهای نسخه هشتم نیز قابلیتهایی برای بهینهسازی بیشتر مسیر نوشتن و مدیریت سیاستهای ذخیرهسازی معرفی شدند. بنابراین مقایسه عملکرد باید بر اساس نسخه و Build دقیق انجام شود، نه صرفاً عنوان vSAN 8.
مفهوم Cache و Capacity در OSA نباید با Tiering خودکار داده میان لایههای Hot و Cold یکسان در نظر گرفته شود. در ESA نیز مزیت اصلی از طراحی Storage Pool، فشردهسازی و پردازش بهینه داده حاصل میشود، نه الزاماً انتقال خودکار داده میان چند رده متفاوت دیسک.
ظرفیت قابل استفاده باید پس از محاسبه سربار Fault Tolerance، نوع RAID، دادههای مدیریتی، فضای رزرو عملیاتی و نرخ واقعی کاهش داده تعیین شود.
VMware vSAN 8 یک محصول نرمافزاری با پیکربندی وابسته به زیرساخت است. به همین دلیل، مشخصات آن مانند یک استوریج سختافزاری ثابت نیست و ظرفیت، عملکرد، تعداد میزبانها و امکانات نهایی به معماری و نسخه مورد استفاده وابسته خواهند بود.
| مؤلفه | توضیحات |
|---|---|
| تولیدکننده | VMware / Broadcom |
| نوع راهکار | Software-Defined Storage و HCI |
| نسل مورد بررسی | VMware vSAN 8 و نسخههای پیشین |
| معماریهای نسخه 8 | OSA و ESA |
| محیط میزبان | سرورهای ESXi با نسخه و پیکربندی سازگار |
| مدیریت | VMware vCenter Server |
| ذخیرهسازی | منابع محلی میزبانهای عضو کلاستر |
| مدیریت سیاست | Storage Policy-Based Management |
| حفاظت داده | Mirroring، Erasure Coding و مکانیزمهای بازسازی |
| قابلیتهای امنیتی | رمزنگاری داده در حالت سکون و انتقال، با شرایط پشتیبانی مربوطه |
| شبکه | اترنت پرسرعت با پهنای باند و طراحی متناسب با نسخه و معماری |
| ظرفیت نهایی | وابسته به تعداد نود، درایو، سیاست ذخیرهسازی و محدودیتهای نسخه |
| مجوز نرمافزاری | وابسته به Entitlement، بسته تجاری و شرایط Licensing |
سرورهای مورد استفاده در vSAN باید از نظر پردازنده، حافظه، کنترلر ذخیرهسازی، SSD، کارت شبکه، Firmware و Driver با معماری و نسخه موردنظر سازگار باشند. صرف پشتیبانی سرور از ESXi به معنی تأیید خودکار آن برای vSAN نیست.
در پیادهسازی ESA، انتخاب پیکربندی تأییدشده اهمیت بیشتری پیدا میکند. استفاده از ReadyNodeهای معتبر به کاهش ریسک ناسازگاری کمک میکند. برای بررسی تفاوت این پیکربندیها، مقاله معرفی vSAN ReadyNodes اطلاعات تکمیلی ارائه میدهد.
کارایی vSAN به شبکه ارتباطی میان میزبانها وابسته است. پهنای باند، تأخیر، Redundancy، ازدحام ترافیک و تنظیمات مرتبط با ارتباطات کلاستر باید متناسب با حجم تبادل داده و عملیات Resync طراحی شوند.
ظرفیت Raw با ظرفیت قابل استفاده برابر نیست. در طراحی کلاستر باید Failure To Tolerate، نوع RAID، رشد داده، فضای موردنیاز عملیات تعمیر و بازسازی، ظرفیت آزاد عملیاتی و نیازهای عملکردی ماشینهای مجازی محاسبه شوند.
برای طراحی کلاستر، ارزیابی سازگاری یا مهاجرت زیرساخت، استفاده از خدمات مجازیسازی زیرساخت آکو میتواند مسیر تحلیل نیازمندیها و انتخاب پیکربندی مناسب را مشخص کند.
vSAN قابلیتهایی برای حفاظت از اطلاعات در برابر خرابی تجهیزات و برخی تهدیدهای امنیتی ارائه میدهد. با این حال، سطح واقعی تابآوری به سیاستهای ذخیرهسازی، تعداد نودها، طراحی Fault Domain، تنظیمات امنیتی و وجود راهکار مستقل Backup بستگی دارد.
vSAN از قابلیتهای Data-at-Rest Encryption و Data-in-Transit Encryption در پیکربندیهای پشتیبانیشده بهره میبرد. رمزنگاری دادههای ذخیرهشده و رمزنگاری ترافیک ذخیرهسازی دو قابلیت مجزا هستند و باید مطابق الزامات امنیتی سازمان بررسی و فعال شوند.
استفاده از این امکانات ممکن است به تنظیمات مدیریت کلید، نسخه نرمافزاری، شرایط Licensing و سایر پیشنیازهای فنی وابسته باشد. همچنین نمیتوان بدون آزمون، تأثیر عملکردی رمزنگاری را در همه Workloadها صفر در نظر گرفت.
با استفاده از Storage Policy میتوان سطح تحمل خطا را متناسب با توپولوژی کلاستر تعیین کرد. vSAN بسته به سیاست انتخابشده از روشهایی مانند Mirroring یا Erasure Coding برای حفاظت از دادهها استفاده میکند.
Fault Domain به توزیع مؤلفههای داده میان دامنههای خرابی تعریفشده کمک میکند. در صورت خرابی میزبان یا دستگاه ذخیرهسازی، مکانیزمهای تعمیر و Resync میتوانند برای بازگرداندن سطح حفاظت موردنیاز وارد عمل شوند؛ مشروط بر اینکه منابع و ظرفیت کافی وجود داشته باشد.
ESA دارای موتور Native Snapshot بازطراحیشده است که کارایی و مقیاسپذیری عملیات Snapshot را نسبت به مکانیزمهای پیشین بهبود میدهد. سازگاری این ویژگی با ابزارهای Backup باید بر اساس نسخه نرمافزار بررسی شود.
Snapshot و Self-Healing بهتنهایی برای حفاظت در برابر حذف منطقی داده، باجافزار، خرابی گسترده سایت یا خطاهای مدیریتی کافی نیستند. سازمانها باید راهبرد Backup و Disaster Recovery مستقلی با اهداف مشخص RPO و RTO داشته باشند.
در محیطهای حساس، ترکیب طراحی صحیح vSAN با خدمات پشتیبانگیری و بازیابی اطلاعات آکو میتواند به تعریف راهبرد منسجم حفاظت از داده، نگهداری نسخههای بازیابی و آزمون سناریوهای بحران کمک کند.
مدیریت روزمره VMware vSAN با ابزارهای اکوسیستم vSphere انجام میشود. مدیران زیرساخت میتوانند سلامت کلاستر، مصرف ظرفیت، تأخیر ذخیرهسازی، وضعیت دستگاهها و عملیات بازسازی داده را بررسی کنند.
vSAN Skyline Health مجموعهای از بررسیهای سلامت و هشدارهای مرتبط با کلاستر را ارائه میدهد. این بررسیها در شناسایی مشکلات سازگاری، ارتباطات شبکه، ظرفیت، وضعیت دیسکها و شرایط عملیاتی نقش دارند.
قابلیتهای Health و Performance Monitoring در شناسایی Bottleneckها مفید هستند، اما نباید آنها را معادل رفع خودکار همه مشکلات، پیشبینی قطعی خرابیها یا تنظیم خودکار تمام منابع CPU و RAM دانست.
برای تحلیل عملکرد کلاستر، شاخصهایی مانند IOPS، Throughput، Latency، میزان مصرف ظرفیت و ترافیک Resync باید در کنار یکدیگر بررسی شوند. تمرکز بر یک شاخص، مانند بیشترین IOPS، تصویر کاملی از عملکرد واقعی فراهم نمیکند.
عملیات نگهداری و ارتقا نیز باید با بررسی Compatibility، سلامت کلاستر، سیاستهای Evacuation و وجود ظرفیت کافی انجام شوند. امکان ادامه سرویسدهی هنگام Maintenance به طراحی و وضعیت کلاستر وابسته است و بدون شرایط مناسب نمیتوان نبود Downtime را تضمین کرد.
vSAN برای سازمانهایی مناسب است که به دنبال هماهنگی ذخیرهسازی با زیرساخت مجازی هستند. تصمیم نهایی باید بر اساس نوع بار کاری، الزامات دسترسپذیری، هزینه عملیاتی و ظرفیت توسعه آینده انجام شود.
فراهمکردن Datastore مشترک برای ماشینهای مجازی و مدیریت سیاستهای ذخیرهسازی در کلاسترهای سازمانی.
استفاده بهعنوان لایه ذخیرهسازی در معماریهای ابری سازگار با اکوسیستم VMware و VMware Cloud Foundation.
اجرای Workloadهای سازمانی با سیاستهای حفاظت و ظرفیت متناسب؛ مشروط به انجام Sizing و آزمون عملکرد واقعی.
پشتیبانی از محیطهای Desktop Virtualization با توجه به الگوی Boot Storm، تراکم ماشینهای مجازی و نیازمندی I/O.
در معماریهای سازگار VMware، vSAN میتواند بخشی از زیرساخت ذخیرهسازی Workloadهای Cloud-Native باشد. امکانات ارائه فضای ذخیرهسازی برای کانتینرها به نسخه vSphere، اجزای Kubernetes، Driverهای مرتبط و پیکربندی نرمافزاری وابسته است.
ارتباط vSAN با پلتفرمهای مدیریت زیرساخت و سرویسهای ابری را میتوان در چارچوب معماری VMware Cloud Foundation بررسی کرد.
مقایسه vSAN باید میان سه موضوع تمایز ایجاد کند: تفاوت نسلهای نرمافزاری، تفاوت معماری OSA و ESA، و تفاوت مدل عملیاتی آن با راهکارهای ذخیرهسازی یا HCI سایر تولیدکنندگان.
تفاوت اصلی vSAN 8 با نسل هفتم، ارائه معماری ESA در کنار OSA است. در نسخههای قدیمیتر، معماری اصلی مبتنی بر Disk Group مورد استفاده قرار میگرفت؛ در حالی که vSAN 8 امکان پیادهسازی ذخیرهسازی بهینهشده برای NVMe را در سختافزارهای سازگار فراهم کرد.
| معیار | vSAN 7 و قبلتر | vSAN 8 |
|---|---|---|
| معماری | OSA | OSA و ESA |
| بهینهسازی برای NVMe | در چارچوب معماری OSA | معماری اختصاصی ESA برای سختافزار تأییدشده |
| پردازش I/O | مسیر پردازش اصلی | مسیر داده بازطراحیشده در ESA |
| مدیریت Snapshot | مکانیزمهای نسل قبلی | موتور Native Snapshot جدید در ESA |
| ارتقا | وابسته به نسخه، Build و سختافزار | امکان ارتقا یا استقرار جدید با پیشنیازهای مربوطه |
| وضعیت پشتیبانی | باید برای هر نسخه بررسی شود | وابسته به چرخه عمر محصول و قرارداد معتبر |
دوره General Support نسخه vSAN 7 در تاریخ ۲ اکتبر ۲۰۲۵ به پایان رسیده است. بنابراین برای محیطهای عملیاتی مبتنی بر نسخههای قدیمی باید وضعیت قرارداد پشتیبانی، دسترسی به اصلاحیهها، امنیت و مسیر ارتقا بهصورت مستقل بررسی شود. درباره vSAN 8 نیز نسخه و Build دقیق ملاک بررسی چرخه عمر و پشتیبانی است.
VMware vSAN، Nutanix، HPE SimpliVity و Dell PowerFlex از نظر معماری، نحوه مدیریت، مدل مجوزدهی و الزامات پیادهسازی تفاوت دارند. انتخاب مناسب صرفاً بر اساس نام محصول یا یک شاخص عملکردی انجام نمیشود.
| راهکار | ویژگی شاخص | نکته تصمیمگیری |
|---|---|---|
| VMware vSAN | یکپارچگی عمیق با اکوسیستم VMware | سازگاری سختافزار و Licensing |
| Nutanix | پلتفرم HCI با ابزارهای مدیریتی اختصاصی | مدل عملیاتی، Hypervisor و هزینه کل راهکار |
| HPE SimpliVity | راهکار HCI یکپارچه با اکوسیستم HPE | مدل سختافزار، نسل محصول و پشتیبانی |
| Dell PowerFlex | ذخیرهسازی نرمافزارمحور مقیاسپذیر | انعطاف معماری، مدل استقرار و نیاز به توسعه |
برتری عملکردی یا اقتصادی یک راهکار نسبت به دیگری بدون مشخصبودن Workload، پیکربندی سختافزار، مدل لایسنس و هزینههای نگهداری قابل تعمیم نیست.
خرید یا استقرار VMware vSAN 8 باید بر اساس تحلیل نیازهای واقعی زیرساخت انجام شود. نسخه نرمافزار بهتنهایی تعیینکننده کارایی، سطح حفاظت یا هزینه نهایی نیست.
شرایط صدور مجوز VMware در دورههای مختلف تغییر کرده است. دسترسی به امکانات vSAN میتواند به نوع اشتراک، بسته نرمافزاری، ظرفیت مجاز، Entitlement و نسخههای پشتیبانیشده وابسته باشد.
در برآورد Total Cost of Ownership یا TCO، باید هزینه لایسنس، سرورها، SSDها، شبکه، برق، خنکسازی، پشتیبانی، ارتقا و منابع انسانی مدیریت زیرساخت لحاظ شود. بنابراین کاهش هزینه نسبت به SAN سنتی نتیجه قطعی همه پروژهها نیست.
در محیطهایی که سختافزار موجود با ESA سازگار نیست، بودجه توسعه شبکه محدود است، بار کاری به ذخیرهسازی خارجی اختصاصی نیاز دارد یا مدل لایسنس از نظر اقتصادی توجیه ندارد، باید سایر معماریهای ذخیرهسازی نیز بررسی شوند.
همچنین سازمانهایی که همچنان از نسخههای قدیمی استفاده میکنند، باید امنیت، وضعیت پشتیبانی و قابلیت ارتقا را در اولویت تصمیمگیری قرار دهند.
نتیجه نهایی: VMware vSAN 8 یک راهکار ذخیرهسازی نرمافزارمحور برای زیرساختهای مبتنی بر VMware است که با ارائه دو معماری OSA و ESA، امکان انتخاب میان حفظ زیرساخت سازگار موجود و استفاده از سختافزار جدیدتر را فراهم میکند.
ESA برای سازمانهایی که به کارایی بالا، NVMe و بهرهوری ظرفیت توجه ویژه دارند، گزینهای قابل بررسی است؛ در مقابل، OSA ممکن است برای برخی زیرساختهای موجود انتخاب عملیتری باشد.
تصمیم صحیح به ارزیابی Compatibility، Sizing، ظرفیت قابل استفاده، Workload، Networking، Licensing و برنامه پشتیبانی بستگی دارد. برای محیطهای قدیمی نیز باید مسیر ارتقا یا مهاجرت به نسخههای پشتیبانیشده در نظر گرفته شود.
برای بررسی بیشتر فناوری، روش پیادهسازی و راهکارهای مرتبط با VMware vSAN، منابع زیر میتوانند مسیر تصمیمگیری و طراحی زیرساخت را تکمیل کنند.
بررسی خانواده محصولات VMware vSAN برای شناخت جایگاه این فناوری در سبد راهکارهای مجازیسازی.
مطالعه راهنمای ساخت زیرساخت ذخیرهسازی با VMware vSAN برای آشنایی با مفاهیم پیادهسازی و طراحی.
آشنایی با خدمات آموزش و انتقال دانش آکو برای توسعه مهارت تیم فنی در مدیریت زیرساخت سازمانی.
VMware vSAN 8 یک راهکار ذخیرهسازی نرمافزارمحور است که با استفاده از منابع ذخیرهسازی سرورهای سازگار، فضای ذخیرهسازی توزیعشده برای ماشینهای مجازی ایجاد میکند. کاربرد اصلی آن در HCI، دیتاسنترهای مجازی و زیرساختهای ابری سازگار است.
OSA معماری اصلی vSAN و مبتنی بر Disk Group با تفکیک Cache و Capacity است. ESA معماری جدیدتری است که برای سختافزار NVMe تأییدشده طراحی شده، از Storage Pool استفاده میکند و مسیر پردازش داده و Snapshot در آن بازطراحی شده است.
خیر. VMware vSAN 8 هر دو معماری OSA و ESA را ارائه میکند. انتخاب معماری باید متناسب با سختافزار موجود، نسخه نرمافزار، الزامات کارایی و برنامه توسعه انجام شود.
تغییر معماری OSA به ESA یک تبدیل ساده درونکلاستری نیست. بسته به نسخه و قابلیتهای محیط، باید از روش مهاجرت پشتیبانیشده، کلاستر مقصد سازگار و برنامه انتقال داده یا ماشینهای مجازی استفاده شود.
برای ایجاد Datastore بومی vSAN، استفاده از آرایه SAN خارجی الزامی نیست؛ زیرا vSAN از منابع ذخیرهسازی میزبانهای عضو کلاستر بهره میبرد. البته استفاده همزمان از ذخیرهسازی خارجی در معماری کلی سازمان میتواند همچنان کاربرد داشته باشد.
خیر. Snapshot برای برخی سناریوهای بازگشت به وضعیت قبلی مفید است، اما جایگزین نسخه پشتیبان مستقل، محافظت در برابر باجافزار یا برنامه Disaster Recovery نیست.
بله، در صورت طراحی و پیکربندی صحیح میتواند برای این Workloadها مناسب باشد. پیش از استقرار باید نیازمندیهای عملکردی، الگوی دسترسی، ظرفیت مؤثر، شبکه و شرایط پشتیبانی بررسی شوند.
هزینه به بسته نرمافزاری، Entitlement معتبر، نوع اشتراک، شرایط Licensing و مشخصات زیرساخت بستگی دارد. برای تعیین هزینه واقعی باید وضعیت مجوز، ظرفیت و نیازهای فنی سازمان مشخص شود.
برای انتخاب معماری OSA یا ESA، بررسی سازگاری سختافزار، طراحی کلاستر، محاسبه ظرفیت، ارزیابی مجوزهای نرمافزاری و برنامهریزی مهاجرت یا ارتقا، میتوانید نیازمندیهای زیرساخت سازمان خود را با کارشناسان آکو مطرح کنید. بررسی نسخه و شرایط تأمین یا پشتیبانی، پیش از ارائه پیشنهاد نهایی ضروری است.