محصولات آکو
HPE
DELL
Broadcom
خدمات آکو
بلاگ
دانلود
HPE
DELL
Broadcom
Vmware
درباره ما
ارتباط با ما
VMware vSAN یک راهکار Software-Defined Storage است که ظرفیت ذخیرهسازی محلی چند سرور ESXi را تجمیع میکند و آن را بهصورت یک Datastore اشتراکی در اختیار ماشینهای مجازی قرار میدهد. با این معماری، سازمان میتواند منابع پردازشی و Storage را در یک کلاستر یکپارچه توسعه دهد، سیاستهای حفاظت از داده را برای هر VM تعریف کند و وابستگی برخی سناریوها به آرایه ذخیرهسازی خارجی را کاهش دهد.
موفقیت پیادهسازی vSAN به انتخاب معماری مناسب، سختافزار سازگار، شبکه کمتأخیر، Sizing واقعی Workload و طراحی دقیق VM Storage Policy وابسته است. بنابراین vSAN را نباید فقط با جمع ظرفیت خام دیسکهای سرورها ارزیابی کرد.
- vSAN دیسکهای محلی Hostهای ESXi را به یک فضای ذخیرهسازی توزیعشده و اشتراکی تبدیل میکند.
- کلاستر استاندارد vSAN حداقل به سه Host مشارکتکننده در Storage نیاز دارد؛ طراحی دوگرهی به Witness خارجی وابسته است.
- سازگاری Server، Controller، Drive، NIC، Driver و Firmware باید پیش از خرید بررسی شود.
- ظرفیت قابل استفاده به FTT، نوع RAID، Snapshotها، فضای عملیاتی آزاد و سایر سرویسهای داده وابسته است.
- برای معماری ESA باید Storage و شبکه پرسرعت متناسب با ReadyNode Profile و نسخه نرمافزار انتخاب شود.
- VM Storage Policy تعیین میکند هر ماشین مجازی چه سطحی از Availability، Performance و Space Efficiency دریافت کند.
VMware vSAN چیست و چه کاربردی دارد؟
VMware vSAN لایه ذخیرهسازی Software-Defined خانواده VMware است که مستقیماً با ESXi، vCenter Server و قابلیتهای مدیریتی محصولات VMware vSphere یکپارچه میشود. vSAN دستگاههای ذخیرهسازی محلی Hostهای عضو کلاستر را تجمیع میکند و یک Datastore توزیعشده در اختیار ماشینهای مجازی قرار میدهد.
در این معماری، فایلهای ماشین مجازی فقط روی یک دیسک یا یک سرور نگهداری نمیشوند. vSAN اجزای هر Object را مطابق Storage Policy میان Hostها و Fault Domainهای مناسب توزیع میکند. به این ترتیب، خرابی یک Drive یا Host الزاماً به از دست رفتن دسترسی به VM منجر نمیشود؛ مشروط بر اینکه Policy، ظرفیت آزاد و تعداد Nodeها برای سطح حفاظت انتخابشده کافی باشد.
vSAN یک Distributed Datastore مبتنی بر نرمافزار است که Storage محلی چند ESXi Host را به یک Pool مشترک تبدیل میکند و سطح حفاظت، کارایی و مصرف ظرفیت هر VM را با Policy-Based Management کنترل میکند.
تفاوت vSAN با یک RAID نرمافزاری ساده
RAID معمولاً از داده در محدوده یک Server یا Controller محافظت میکند؛ اما vSAN حفاظت را در سطح کلاستر گسترش میدهد. Replica، Witness و مؤلفههای داده میتوانند روی Hostها یا Fault Domainهای متفاوت قرار گیرند. علاوه بر این، vSAN با HA، DRS، vMotion، Storage Policy و مدیریت متمرکز vCenter هماهنگ است.
رابطه vSAN با معماری HCI
در مدل Hyperconverged Infrastructure، منابع Compute و Storage روی Nodeهای یکسان قرار میگیرند و با افزودن Server جدید توسعه پیدا میکنند. vSAN یکی از اجزای اصلی ایجاد چنین معماریای در اکوسیستم VMware است. برای شناخت کاملتر این ساختار میتوانید مقاله معرفی معماری Hyperconverged Infrastructure را مطالعه کنید.
vSAN چگونه کار میکند؟
vSAN روی ESXi Hostهای عضو کلاستر فعال میشود و دستگاههای Storage تأییدشده آنها را در یک معماری توزیعشده مشارکت میدهد. ماشین مجازی پس از دریافت یک Storage Policy به مجموعهای از Objectها مانند VMDK، VM Home، Swap و Namespace تقسیم میشود و vSAN اجزای موردنیاز هر Object را در کلاستر قرار میدهد.
Hostهای ESXi
شبکه vSAN
Datastore توزیعشده
Storage Policy-Based Management
Object-Based Storage در vSAN
vSAN داده ماشین مجازی را بهصورت Object مدیریت میکند. هر Object ممکن است بر اساس Policy به چند Component تقسیم شود و مؤلفههای حفاظت یا Witness داشته باشد. این مدل امکان میدهد دو VM روی یک Datastore مشترک، سطح Availability یا مصرف ظرفیت متفاوتی داشته باشند.
فرایند خرابی و بازسازی داده
هنگام خرابی Drive یا Host، vSAN ابتدا وضعیت مؤلفهها و Policy را ارزیابی میکند. اگر نسخههای سالم داده در دسترس باشند، VM میتواند به فعالیت ادامه دهد. سپس با توجه به نوع خرابی، زمان Repair و ظرفیت آزاد، فرایند Rebuild یا Resync برای بازگرداندن Compliance آغاز میشود.
سرعت عادی VM تنها معیار طراحی شبکه نیست. شبکه باید همزمان توان مدیریت ترافیک تولیدی، vMotion، عملیات Maintenance و حجم بالای Resync پس از خرابی یا توسعه کلاستر را داشته باشد.
تفاوت معماری vSAN ESA و OSA
در vSAN 8 دو معماری اصلی وجود دارد: Original Storage Architecture یا OSA و Express Storage Architecture یا ESA. انتخاب میان آنها باید بر اساس نسل سختافزار، نوع Drive، نسخه ESXi، نیاز کارایی، محدودیتهای پشتیبانی و مسیر توسعه آینده انجام شود.
| معیار | vSAN OSA | vSAN ESA |
|---|---|---|
| ساختار Storage | مبتنی بر Disk Group و تفکیک Cache Tier از Capacity Tier | مبتنی بر Storage Pool و معماری Single-Tier با Driveهای Flash سازگار |
| نوع سختافزار هدف | از Hybrid تا All-Flash، بسته به نسخه و پیکربندی تأییدشده | سختافزار مدرن و عمدتاً NVMe با کارایی و Endurance تأییدشده |
| Failure Domain دستگاه | خرابی Cache Device ممکن است کل Disk Group را تحت تأثیر قرار دهد | خرابی هر Device معمولاً به همان دستگاه محدود میشود و Disk Group وجود ندارد |
| مدیریت Drive | Claim و نگهداری Driveها در قالب Disk Group | مدیریت سادهتر دستگاهها در Storage Pool |
| کارایی RAID و Snapshot | وابسته به Disk Group، Cache و نوع Policy | Data Path جدید با تمرکز بر RAID کارآمد و Native Snapshot مقیاسپذیر |
| سناریوی مناسب | زیرساختهای موجود، سختافزار نسل قبل یا پیکربندیهای پشتیبانیشده OSA | استقرار جدید روی سختافزار مدرن و Workloadهای حساس به Performance |
چه زمانی OSA منطقی است؟
OSA میتواند برای سازمانی منطقی باشد که زیرساخت vSAN موجود و پشتیبانیشده دارد، از سختافزار سازگار با ESA استفاده نمیکند یا میخواهد چرخه عمر تجهیزات فعلی را حفظ کند. در این شرایط، سلامت Disk Groupها، Controller Queue Depth، Endurance دیسک Cache و زمان Rebuild اهمیت زیادی دارد.
چه زمانی ESA انتخاب بهتری است؟
ESA برای Deploymentهای جدیدی طراحی شده است که از Server، NVMe Drive، NIC و Firmware تأییدشده استفاده میکنند و به Performance بالا، Failure Domain کوچکتر، Snapshot کارآمدتر و مدیریت سادهتر Storage Device نیاز دارند.
vSAN Max و جداسازی Compute از Storage
در نسخهها و لایسنسهای پشتیبانیکننده، vSAN Max امکان ایجاد کلاستر Storage مستقل و ارائه Remote Datastore به کلاسترهای Compute را فراهم میکند. این مدل برای سازمانی مفید است که رشد Compute و Storage آن همزمان نیست و میخواهد ظرفیت ذخیرهسازی را مستقلتر توسعه دهد.
وجود NVMe در Server بهتنهایی به معنای امکان استفاده از ESA نیست. مدل Server، Drive، NIC، CPU، Driver، Firmware و ReadyNode Profile باید با نسخه موردنظر vSAN تطبیق داده شود. برای بررسی راهکارهای قابل ارائه میتوانید صفحه محصولات VMware vSAN را مشاهده کنید.
پیشنیازهای سختافزاری و شبکه برای پیادهسازی vSAN
پایداری vSAN بیش از آنکه به نام برند Server وابسته باشد، به سازگاری کامل اجزا و تناسب طراحی با Workload بستگی دارد. استفاده از سختافزار قدرتمند اما تأییدنشده میتواند در زمان Update، خرابی Drive یا دریافت Support مشکلات جدی ایجاد کند.
تعداد Host و طراحی کلاستر
- کلاستر استاندارد vSAN حداقل به سه Host نیاز دارد که ظرفیت Storage به کلاستر ارائه دهند.
- برای محیطهای تولیدی، چهار Host یا بیشتر معمولاً انعطاف عملیاتی مناسبتری برای Maintenance و خرابی ایجاد میکند.
- کلاستر دوگرهی شامل دو Data Host و یک Witness خارج از کلاستر داده است.
- Stretched Cluster به دو سایت داده و Witness Site مستقل نیاز دارد و باید از نظر Latency، Bandwidth و Fault Domain دقیق طراحی شود.
سازگاری Server و قطعات
تمام Capacity Deviceها، Controllerها، NICها، Driverها و Firmwareها باید در پیکربندی معتبر قرار داشته باشند. مقاله vSAN ReadyNodes چیست و چه تفاوتی با سرورهای HCI دارد؟ توضیح میدهد چرا یک ReadyNode صرفاً یک Server مجهز به چند SSD نیست.
CPU و RAM
Drive و Endurance
Controller و Queue Depth
شبکه اختصاصی vSAN
روی هر Host باید حداقل یک VMkernel Adapter برای ترافیک vSAN فعال شود. جداسازی منطقی با VLAN، Redundancy در Uplinkها، تنظیم MTU یکسان در تمام مسیر و کنترل ازدحام از الزامات اصلی طراحی است.
- برای OSA All-Flash معمولاً شبکه 10GbE یا سریعتر مبنای طراحی قرار میگیرد.
- برای ESA بهتر است طراحی 25GbE یا بالاتر بر اساس ReadyNode Profile، نسخه نرمافزار و حجم Workload انجام شود.
- اشتراک Uplink با vMotion یا سایر ترافیکها تنها با Sizing، Redundancy و Network I/O Control مناسب انجام شود.
- ترافیک vSAN نباید بدون ارزیابی روی شبکهای قرار گیرد که همزمان برای iSCSI، NFS یا سرویسهای پرترافیک دیگر استفاده میشود.
استفاده از MTU بزرگ میتواند در برخی طراحیها مفید باشد، اما مهمتر از مقدار MTU، یکسانبودن تنظیمات End-to-End است. ناسازگاری MTU میان VMkernel، vSwitch، Uplink و سوئیچ فیزیکی میتواند باعث Packet Loss و مشکلات دشوار عیبیابی شود.
چگونه با VMware vSAN زیرساخت ذخیرهسازی یکپارچه بسازیم؟
استقرار موفق vSAN با فعالکردن یک گزینه در vCenter آغاز نمیشود. ابتدا باید Workload، سطح Availability، ظرفیت مؤثر، رشد آینده، محدودیتهای شبکه و مدل پشتیبانی مشخص شوند.
- تحلیل Workload: تعداد VMها، ظرفیت مصرفی، نرخ رشد، IOPS، Read/Write Ratio، Latency، Snapshot، Backup Window و Recovery Requirement را اندازهگیری کنید.
- تعیین سطح دسترسپذیری: مشخص کنید هر گروه Workload باید خرابی چند Drive، Host، Rack یا Site را تحمل کند.
- انتخاب OSA، ESA یا معماری جداشده: تصمیم را بر اساس سختافزار موجود، Performance، توسعه آینده و Compatibility بگیرید.
- انتخاب ReadyNode یا Bill of Materials تأییدشده: CPU، RAM، NIC، Drive، Controller، Driver و Firmware را بهصورت یک مجموعه سازگار بررسی کنید.
- طراحی شبکه: VLAN، VMkernel، Uplink Redundancy، Bandwidth، MTU، Routing و Network I/O Control را پیش از Deployment نهایی کنید.
- آمادهسازی ESXi و vCenter: نسخهها، DNS، NTP، Hostname، Certificate، Distributed Switch و تنظیمات Cluster را یکسانسازی کنید.
- فعالسازی vSAN و Claim دستگاهها: Driveها را مطابق معماری انتخابشده در Disk Group یا Storage Pool قرار دهید.
- تعریف VM Storage Policy: Policy جداگانه برای Workloadهای عمومی، حیاتی، دیتابیس، VDI و ماشینهای موقت ایجاد کنید.
- اجرای Health Check و تست Failure: سلامت شبکه، Hardware Compatibility، Performance و رفتار کلاستر هنگام Maintenance یا خرابی را بررسی کنید.
- تحویل عملیاتی و مستندسازی: Runbook مربوط به Capacity، Firmware، Patch، Maintenance Mode، Replacement Drive، Resync و Escalation را آماده کنید.
چرا Pilot Cluster اهمیت دارد؟
Pilot باید نماینده Workload واقعی باشد، نه صرفاً چند VM آزمایشی کممصرف. تستهای Latency، Failure، Rebuild، Maintenance، Backup و Restore باید پیش از انتقال سرویسهای حیاتی انجام شوند. نتیجه آزمایش همچنین میتواند فرضیات اولیه Sizing را اصلاح کند.
Health Check پس از فعالسازی
پس از ایجاد کلاستر، وضعیت Network Partition، Unicast Connectivity، Disk Health، Hardware Compatibility، Object Compliance، Capacity و Resync باید کنترل شود. تست Network Performance نیز باید نشان دهد پهنای باند واقعی به ظرفیت مورد انتظار NICها نزدیک است.
ممکن است کلاستر با تنظیمات حداقلی فعال شود، اما در زمان خرابی یا Resync با افت شدید Performance مواجه شود. معیار پذیرش باید رفتار زیرساخت در شرایط Failure و Maintenance باشد، نه فقط سبز بودن وضعیت اولیه.
VM Storage Policy و حفاظت از داده در vSAN
Storage Policy هسته تصمیمگیری vSAN است. بهجای اعمال یک سطح RAID ثابت روی تمام Datastore، میتوان برای هر VM یا VMDK سطح متفاوتی از Availability، RAID Method، Compression و سایر قابلیتهای پشتیبانیشده تعریف کرد.
Failures to Tolerate یا FTT
FTT مشخص میکند Object مربوط به VM باید چند خرابی همزمان را تحمل کند. افزایش FTT معمولاً به Host، Fault Domain و ظرفیت بیشتری نیاز دارد. نوع حفاظت داده نیز تعیین میکند این افزونگی با Mirroring یا Erasure Coding ایجاد شود.
| Policy نمونه | روش حفاظت | ظرفیت قابل استفاده تقریبی | سناریوی مناسب |
|---|---|---|---|
| FTT=1 | RAID-1 Mirroring | حدود 50 درصد ظرفیت خام | Workloadهای حساس به Performance و کلاسترهای کوچکتر |
| FTT=1 | RAID-5 Erasure Coding | حدود 75 درصد ظرفیت خام | تعادل میان حفاظت، ظرفیت و Performance |
| FTT=2 | RAID-1 Mirroring | حدود 33 درصد ظرفیت خام | Workload بسیار حیاتی با اولویت Performance |
| FTT=2 | RAID-6 Erasure Coding | حدود 67 درصد ظرفیت خام | محیطهای بزرگتر با نیاز حفاظت بالاتر و مصرف ظرفیت بهینهتر |
درصدهای جدول فقط نسبت نظری داده به ظرفیت خام هستند. Metadata، Namespace، Snapshot، Slack Space، Resync Reserve، File Services، Object Overhead و تفاوت معماری میتوانند ظرفیت نهایی قابل استفاده را کاهش دهند.
Storage Policy یکسان برای همه VMها اشتباه است
فایلسرور، Domain Controller، دیتابیس تراکنشی، VDI Replica، Backup Proxy و VM آزمایشی نیاز یکسانی ندارند. استفاده از یک Policy بسیار محافظهکارانه برای همه VMها هزینه ظرفیت را افزایش میدهد؛ در مقابل، Policy ضعیف برای سرویسهای حیاتی ریسک عملیاتی ایجاد میکند.
Policy Compliance
vCenter وضعیت تطابق Objectهای VM با Policy را نمایش میدهد. Noncompliant شدن یک VM میتواند ناشی از خرابی، کمبود ظرفیت، تعداد ناکافی Fault Domain یا تغییر پیکربندی باشد. این وضعیت باید مانیتور شود و فقط یک پیام تزئینی در داشبورد تلقی نشود.
مزایا و کاربردهای سازمانی VMware vSAN
ارزش vSAN فقط در حذف یک Storage Array خلاصه نمیشود. مزیت اصلی آن ایجاد یک مدل عملیاتی یکپارچه برای Compute، Storage و Policy Management در محیط VMware است.
مجازیسازی عمومی
پایگاه داده و OLTP
Virtual Desktop Infrastructure
شعب و Edge
Private Cloud و VCF
Stretched Cluster
توسعه Scale-Out
با افزودن Host، امکان افزایش همزمان Compute و Storage وجود دارد. این ویژگی برای محیطهایی مفید است که رشد دو منبع تقریباً همراستا است. با این حال، اگر فقط یکی از منابع رشد کند، ممکن است معماری HCI سنتی به Overprovisioning منجر شود و باید مدل Compute-Only یا Storage Cluster بررسی شود.
مدیریت متمرکز
ایجاد Datastore، تعریف Storage Policy، مشاهده Capacity، بررسی Resync و کنترل Health از طریق vCenter انجام میشود. کاهش تعداد ابزارهای مدیریتی میتواند عملیات را سادهتر کند، اما همچنان به تخصص Storage، Network، Server و VMware نیاز است.
مقایسه vSAN با Storage سنتی و معماری سهلایه
vSAN همیشه جایگزین مطلق SAN یا NAS نیست. انتخاب صحیح به نوع Workload، رشد منابع، مهارت تیم، سرمایهگذاری موجود، SLA و الزامات استقلال Storage از Compute وابسته است.
| معیار | VMware vSAN | SAN یا Storage خارجی |
|---|---|---|
| مدل معماری | توزیعشده روی Hostهای ESXi یا کلاستر Storage نرمافزاری | آرایه Storage مستقل متصل به Serverها |
| توسعه ظرفیت | اغلب با افزودن Drive یا Node سازگار | با افزودن Drive، Enclosure، Controller یا Array |
| رشد Compute و Storage | در HCI معمولاً به یکدیگر نزدیکاند؛ مدلهای جداشده انعطاف بیشتری دارند | Compute و Storage مستقلتر توسعه پیدا میکنند |
| مدیریت | یکپارچه با vCenter و VM Storage Policy | معمولاً دارای ابزار مدیریت مستقل Vendor |
| شبکه | شبکه East-West میان Hostها برای I/O و Resync حیاتی است | شبکه یا Fabric اختصاصی SAN یا NAS نقش اصلی دارد |
| Fault Domain | Drive، Host، Rack و Site بر اساس طراحی کلاستر و Policy | Drive، Enclosure، Controller و Array بر اساس معماری Storage |
| مهارت موردنیاز | ترکیب دانش VMware، Server، Network و Distributed Storage | دانش Storage، Fabric، Multipathing و Vendor Platform |
| سناریوی مناسب | زیرساخت VMware یکپارچه، HCI، شعب، Private Cloud و Scale-Out | اشتراک Storage میان پلتفرمهای مختلف، رشد مستقل و قابلیتهای تخصصی Array |
اگر سازمان میان vSAN و یک Array خارجی مردد است، مقاله بهترین استوریجها برای مجازیسازی VMware معیارهای بیشتری برای بررسی SAN، NAS و Storageهای All-Flash ارائه میدهد.
همچنین مقایسه Hyperconverged در برابر معماری سهلایه برای سازمانهایی مفید است که هنوز درباره ساختار کلی دیتاسنتر تصمیم نگرفتهاند.
سازمانی که بخش عمده Workload آن روی vSphere اجرا میشود، تیم آن توان مدیریت یک زیرساخت توزیعشده را دارد و رشد Compute و Storage آن قابل پیشبینی است، معمولاً ارزش بیشتری از vSAN دریافت میکند.
محدودیتها و اشتباهات رایج در طراحی vSAN
vSAN میتواند زیرساختی پایدار و مقیاسپذیر ایجاد کند، اما در صورت Sizing ضعیف یا استفاده از قطعات ناسازگار، همان معماری توزیعشده میتواند دامنه مشکلات را افزایش دهد.
محاسبه ظرفیت فقط از روی TB خام
استفاده از سختافزار مشابه اما تأییدنشده
شبکه بدون Redundancy
نادیدهگرفتن Rebuild Window
Policy یکسان برای همه سرویسها
نبود Runbook عملیاتی
نزدیکشدن دائمی به اشباع ظرفیت
کلاستر برای جابهجایی Componentها، Rebuild، Resync و Maintenance به فضای آزاد نیاز دارد. استفاده دائمی از بیشترین ظرفیت قابل نمایش در رابط مدیریتی میتواند زمان بازسازی را افزایش دهد یا مانع حفظ Compliance شود.
نادیدهگرفتن مدل لایسنس
بستهبندی و نحوه محاسبه لایسنس VMware ممکن است با نسخه، نوع قرارداد و محصول Foundation تغییر کند. در طراحی مالی باید ظرفیت خام، Coreهای پردازنده، Entitlement موجود، Support و مسیر Upgrade بهصورت جداگانه بررسی شوند.
Replication، Mirroring و Erasure Coding از Availability محافظت میکنند، اما حذف ناخواسته، خرابی منطقی، Ransomware و نیاز به Retention مستقل را پوشش نمیدهند. Backup جداگانه و قابل بازیابی همچنان ضروری است.
راهنمای Sizing و انتخاب VMware vSAN
Sizing صحیح باید از Workload و SLA آغاز شود، نه از تعداد Bay یا ظرفیت اسمی Drive. برای هر گروه سرویس، وضعیت فعلی و رشد حداقل چندساله باید جداگانه محاسبه شود.
اطلاعات موردنیاز برای Sizing
- تعداد VM و VMDK همراه با ظرفیت مصرفشده واقعی
- رشد ماهانه یا سالانه داده
- Peak IOPS و Average IOPS
- Read/Write Ratio و Block Size
- Latency موردقبول برای هر Application
- تعداد Snapshot و مدت نگهداری آنها
- Backup Window و Restore Requirement
- FTT و RAID Method موردنیاز هر Workload
- تأثیر Maintenance و خرابی همزمان یک Host
- نیاز به Encryption، Stretched Cluster یا File Services
فرمول مفهومی ظرفیت
ظرفیت خام تقریبی برابر است با مجموع داده فعال و رشد پیشبینیشده، ضرب در ضریب حفاظت Policy، بهعلاوه Snapshot، Metadata، فضای Resync، فضای آزاد عملیاتی و Reserve موردنیاز برای Maintenance.
برای مثال، 100 ترابایت داده با FTT=1 و RAID-1 به حدود 200 ترابایت ظرفیت خام فقط برای Replicaها نیاز دارد. سپس باید رشد، Snapshot، Overhead و فضای آزاد عملیاتی نیز به آن افزوده شود. بنابراین خرید دقیقاً 200 ترابایت خام، طراحی ایمن محسوب نمیشود.
چه زمانی vSAN انتخاب مناسبی نیست؟
- زمانی که سازمان فقط یک Server دارد و امکان ایجاد Fault Domain واقعی وجود ندارد.
- زمانی که سختافزار موجود در Compatibility Guide پشتیبانی نمیشود.
- زمانی که Compute و Storage با نرخهای بسیار متفاوت رشد میکنند و مدل جداشده نیز بررسی نشده است.
- زمانی که Workloadها میان چند Hypervisor یا سیستم غیرVMware به Storage مشترک نیاز دارند.
- زمانی که تیم عملیاتی توان مانیتورینگ شبکه، Firmware، Capacity و Storage Policy را ندارد.
- زمانی که یک SAN موجود هنوز ظرفیت، Performance و چرخه پشتیبانی مناسبی ارائه میدهد و تغییر معماری ارزش اقتصادی مشخصی ندارد.
جمعبندی؛ آیا VMware vSAN برای زیرساخت شما مناسب است؟
VMware vSAN با تجمیع Storage محلی Hostهای ESXi، یک Datastore توزیعشده و Policy-Based ایجاد میکند. این راهکار میتواند مدیریت زیرساخت VMware را یکپارچهتر کند، توسعه Scale-Out را سادهتر سازد و سطح حفاظت داده را برای هر VM بهصورت مستقل تعیین کند.
با این حال، ارزش واقعی vSAN فقط زمانی حاصل میشود که انتخاب ESA یا OSA، تعداد Host، شبکه، Drive Endurance، FTT، RAID، ظرفیت آزاد، Backup و لایسنس بهصورت یک معماری واحد طراحی شوند. خرید چند Server پرقدرت بدون Compatibility Check و Workload Sizing جای طراحی فنی را نمیگیرد.
برای محیطهای جدید مبتنی بر سختافزار مدرن، ESA میتواند مسیر مناسبی باشد؛ در حالی که زیرساختهای موجود OSA ممکن است همچنان تا پایان چرخه پشتیبانی ارزش عملیاتی داشته باشند. تصمیم نهایی باید بر اساس دادههای واقعی Performance، رشد ظرفیت، SLA و Total Cost of Ownership گرفته شود.
مطالب، محصولات و خدمات مرتبط
سوالات پرتکرار درباره VMware vSAN
VMware vSAN دقیقاً چه کاری انجام میدهد؟
vSAN ظرفیت Storage محلی Hostهای ESXi را در قالب یک Datastore توزیعشده تجمیع میکند و حفاظت، Placement و مصرف ظرفیت Objectهای ماشین مجازی را بر اساس VM Storage Policy مدیریت میکند.
حداقل چند Host برای راهاندازی vSAN لازم است؟
کلاستر استاندارد vSAN حداقل به سه Host مشارکتکننده در Storage نیاز دارد. در طراحی Two-Node، دو Data Host همراه با یک Witness خارجی استفاده میشوند. برای محیط تولیدی، تعداد بیشتر Host معمولاً انعطاف بهتری برای Maintenance و Failure فراهم میکند.
آیا vSAN بدون Storage خارجی کار میکند؟
بله. در مدل HCI، vSAN از Driveهای محلی Hostها یک Datastore مشترک میسازد و برای اجرای VMها به SAN خارجی وابسته نیست. با این حال، Backup Target، Archive یا سایر سرویسها ممکن است همچنان روی Storage مستقل قرار گیرند.
تفاوت اصلی vSAN ESA و OSA چیست؟
OSA از Disk Group و لایههای Cache و Capacity استفاده میکند. ESA برای سختافزار Flash مدرن طراحی شده و از Storage Pool، Data Path جدید، Failure Domain کوچکتر و قابلیتهای بهینهتر برای RAID و Snapshot بهره میبرد.
آیا میتوان از هر Server یا SSD در vSAN استفاده کرد؟
خیر. Server، Drive، Controller، NIC، Driver و Firmware باید با نسخه vSAN سازگار و در پیکربندی تأییدشده قرار داشته باشند.
آیا vSAN جایگزین Backup و Disaster Recovery است؟
خیر. vSAN با Replication و Storage Policy به Availability کمک میکند، اما Backup مستقل، Retention، بازیابی از حذف منطقی و برنامه Disaster Recovery همچنان موردنیاز است.