خلاصه اجرایی: برای vSAN باید جداگانه ظرفیت، کارایی، Availability، Resilience و Lifecycle را محاسبه کرد. انتخاب ESA یا OSA، نوع Drive، Storage Policy، شبکه و Failure Domain باید با نسخه مقصد و Compatibility Guide هماهنگ باشد. هیچ درصد ثابت عمومی جای داده واقعی Workload را نمیگیرد.
چرا ظرفیت خام گمراهکننده است؟
جمع ظرفیت Driveها ساده است، اما مصرف واقعی به Storage Policy، حفاظت داده، Overhead، Slack عملیاتی، Snapshot، رشد و Rebuild وابسته است. دو Cluster با ظرفیت خام یکسان میتوانند Usable Capacity و رفتار Failure کاملاً متفاوتی داشته باشند.
در طراحی، حداقل چهار عدد باید جدا گزارش شود: Raw، Policy-adjusted، Operationally usable و Available after growth. اگر فقط عدد خام در Proposal دیده شود، تصمیمگیر نمیداند در Maintenance یا خرابی چه مقدار ظرفیت باقی میماند.
ظرفیتی که در حالت Failure یا Maintenance اجازه Repair و جابهجایی نمیدهد، ظرفیت آزاد قابل اتکا نیست.
Workload را با Average توصیف نکنید
Average IOPS یا مصرف میانگین، Peak و رفتار Burst را پنهان میکند. Inventory باید Read/Write ratio، Block size، Latency SLO، Working set، Growth، Snapshot/Backup window و حساسیت اپلیکیشن را در بازه مناسب ثبت کند.
| داده | چرا لازم است؟ | خطای رایج |
|---|---|---|
| Peak IOPS/Throughput | برآورد فشار واقعی و Headroom | استفاده از میانگین ماهانه |
| Latency SLO | تعریف کیفیت سرویس قابل سنجش | گفتن «سریع باشد» بدون عدد |
| Working set | شناخت رفتار Cache و Media | فرض یکسان برای همه VMها |
| Growth | زمان رسیدن به Trigger توسعه | افزودن درصد ثابت بدون برنامه |
| Failure behavior | ظرفیت و Performance هنگام خرابی | Sizing فقط در حالت Normal |
Database، VDI، فایلسرور، Kubernetes و AI هرکدام الگوی متفاوتی دارند. Policy و Placement باید بر اساس گروه Workload باشد، نه یک تنظیم مشترک برای کل Datastore.
ESA یا OSA؛ انتخاب معماری، نه نام جدید
انتخاب Express Storage Architecture یا Original Storage Architecture باید با نسخه VCF، سختافزار پشتیبانیشده، نوع Device، Performance target و مسیر Lifecycle انجام شود. نمیتوان مزایای یک معماری را به هر سرور یا هر Drive تعمیم داد.
سازگاری
مدل Server، Controller، NIC و Drive باید برای Architecture و Release مقصد تأیید شوند.
اقتصاد
هزینه Media، Core، Network و رشد با ظرفیت قابل استفاده سنجیده میشود.
عملیات
مهارت تیم، Monitoring، Upgrade و تعویض قطعه بخشی از TCO هستند.
مهاجرت
مسیر انتقال داده، پنجره تغییر و ظرفیت موقت باید پیش از انتخاب روشن باشد.
اگر محیط فعلی OSA است، تصمیم به ESA نباید داخل همان Change ارتقای Core پنهان شود. Feature adoption یا Migration بهتر است دامنه، Runbook و Validation مستقل داشته باشد.
Storage Policy واحد اندازهگیری واقعی است
vSAN ظرفیت و Availability را براساس Policy به Workload ارائه میکند. FTT، Failure Tolerance Method، Stripe، IOPS limit، Compression یا Encryption میتوانند بر مصرف و کارایی اثر بگذارند. Policy باید با Tier سرویس و Recovery requirement مرتبط باشد.
| Tier | نیاز کسبوکار | تصمیم فنی | Evidence |
|---|---|---|---|
| Critical | SLO سختگیرانه و تحمل خرابی | Policy محافظتیتر و ظرفیت رزرو مناسب | Application test + failure test |
| Standard | تعادل هزینه و Availability | Policy استاندارد سازمان | Baseline performance |
| Transient | داده قابل بازسازی | Policy متناسب با ریسک | Owner approval + recovery method |
نام Tier بهتنهایی کافی نیست. تیم اپلیکیشن باید بداند Policy دقیقاً چه خرابیای را تحمل میکند و چه چیزی Backup محسوب نمیشود.
Failure Domain را روی نقشه فیزیکی بنویسید
حفاظت منطقی وقتی ارزش دارد که با Rack، Chassis، Power، ToR و Site همراستا باشد. اگر Replicaها روی اجزایی با Failure مشترک قرار گیرند، عدد FTT میتواند حس امنیت نادرست بسازد.
Design باید خرابی Drive، Host، Rack، Network و Site را جدا بررسی کند. برای Stretched Cluster، Witness، Latency، Bandwidth، Isolation و سناریوی Split باید براساس مستند نسخه و نیاز کسبوکار ارزیابی شوند.
Performance را در Normal و Degraded بسنجید
Benchmark کوتاه در Cluster خالی نماینده Production نیست. آزمایش باید با Policy واقعی، Dataset مناسب، Warm-up، Peak profile و Background task مانند Resync انجام شود. مهمتر از عدد IOPS، پایداری Latency در بار و خرابی است.
Normal
Peak workload با Headroom و بدون Saturation.
Maintenance
خروج Host و ادامه سرویس در ظرفیت باقیمانده.
Repair/Resync
همزمانی بازسازی داده با Workload بحرانی.
Queue، Congestion، CPU، Network و Device latency باید همزمان دیده شوند تا گلوگاه بهاشتباه به Storage نسبت داده نشود.
شبکه vSAN بخشی از Storage است
Bandwidth اسمی NIC کافی نیست. Redundancy، MTU، Buffer، Oversubscription، RDMA در صورت استفاده، Driver/Firmware و Failover path روی نتیجه اثر دارند. مسیرهای vSAN باید با ترافیک vMotion و Management در حالت Peak و Maintenance سنجیده شوند.
تست شبکه باید دوطرفه و end-to-end باشد. خطای یک Uplink یا ToR نباید Cluster را به ظرفیتی زیر معیار پذیرش ببرد.
HCL را در سطح Component بررسی کنید
Server model، Controller، Drive، NIC، Firmware و Driver یک Stack هستند. استفاده از قطعهای با نام نزدیک یا Firmware متفاوت میتواند ترکیب پشتیبانینشده بسازد. Drive endurance و ظرفیت Spare نیز باید با Write profile و زمان تعویض در ایران سنجیده شوند.
Lead time قطعه و دسترسی به مدل یکسان، بخشی از Availability است. معماریای که جایگزینی قطعه آن هفتهها طول میکشد، باید Spare strategy روشن داشته باشد.
Rebuild، Maintenance و Capacity Trigger
Slack space باید امکان عملیات روزمره و Failure را حفظ کند. Trigger توسعه باید پیش از رسیدن به نقطه بحرانی فعال شود، چون خرید و نصب Hardware زمان میبرد. Threshold واحد برای همه Clusterها مناسب نیست؛ سرعت رشد و زمان Procurement تعیینکنندهاند.
Observe
Capacity، growth، latency، congestion و component health پیوسته ثبت شوند.
Forecast
زمان رسیدن به Trigger با سناریوی رشد و Failure محاسبه شود.
Act
افزودن Disk/Host یا بازطراحی Policy پیش از کمبود اجرا شود.
Validate
پس از تغییر، Balance، Policy compliance و Performance دوباره سنجیده شود.
Object Storage در VCF ۹.۱.۱؛ وضعیت را درست بیان کنید
Broadcom در اعلام VCF ۹.۱.۱ از vSAN Object Storage بهعنوان Tech Preview نام برده است. بنابراین نباید آن را بدون کنترل وضعیت نسخه، Support و محدودیتها مبنای Production design قرار داد. Tech Preview برای ارزیابی قابلیت و Use Case مفید است، اما تعهد عملیاتی باید از مستند رسمی و وضعیت GA همان زمان بیاید.
اگر S3-compatible storage برای AI، Backup یا اپلیکیشن لازم است، Data protection، Multi-tenancy، Performance، API compatibility و lifecycle باید مستقل ارزیابی شوند.
یک سناریوی Sizing قابل دفاع
فرض کنید سه گروه Workload دارید: Database حساس به Latency، VMهای عمومی و داده موقت تحلیلی. بهجای یک Policy مشترک، برای هر Tier ظرفیت، Performance، FTT و Growth جدا محاسبه میشود. سپس حالت خروج یک Host و زمان Rebuild شبیهسازی میشود.
خروجی ممکن است نشان دهد ظرفیت خام کافی است اما Network یا Slack پاسخگو نیست؛ یا اینکه با اصلاح Policy و Archive بخشی از داده، خرید فوری کاهش مییابد. این نتیجه از داده واقعی میآید، نه از نسبت ثابت Raw به Usable.
پرسشهای متداول
چند درصد ظرفیت vSAN باید آزاد بماند؟
درصد ثابت عمومی مناسب نیست. Architecture، Policy، Failure، Maintenance، رشد و زمان Procurement باید تعیین کنند.
آیا ESA همیشه سریعتر و بهتر است؟
انتخاب به سختافزار پشتیبانیشده، Workload، نسخه و هدف عملیاتی بستگی دارد. مقایسه باید روی محیط نماینده انجام شود.
آیا vSAN جای Backup را میگیرد؟
خیر. Availability و Data protection یکسان نیستند. Backup و Restore مستقل لازماند.
آیا Object Storage جدید برای Production آماده است؟
در اعلام VCF ۹.۱.۱ بهعنوان Tech Preview معرفی شده؛ وضعیت روز و مستند Support باید پیش از هر تصمیم بررسی شود.
منابع رسمی و یادداشت فنی
برای Sizing و Compatibility نهایی، مستند همان Build، VMware Compatibility Guide و BOM واقعی مرجع هستند.
برای مطالعه بعدی
Sizing را با داده Workload انجام دهید
Capacity، Policy، Failure Domain، Network و Growth را در یک Workbook قابل بازبینی جمع کنید.