مقدمه چک‌لیست طراحی زیرساخت VMware برای سازمان‌های Enterprise
بیشتر پروژه‌های مجازی‌سازی سازمانی با یک جلسه ساده شروع می‌شوند: «چند ماشین مجازی داریم؟ چند سرور بخریم؟» اما پروژه‌هایی که بعد از دو سال هنوز پایدار و قابل‌اتکا هستند، معمولاً قبل از خرید اولین سرور، به ده‌ها سؤال دیگر هم پاسخ داده‌اند: وقتی یک میزبان خراب شود چه می‌شود؟ شبکه ذخیره‌سازی از چه مسیری عبور می‌کند؟ بک‌آپ را کجا بازیابی می‌کنیم؟ و مهم‌تر از همه، پنج سال دیگر این پلتفرم از نظر لایسنس و پشتیبانی کجا خواهد بود؟
این مقاله یک چک‌لیست عملی طراحی زیرساخت VMware است، نه یک توضیح تئوریک. هدف این است که قبل از امضای قرارداد خرید و قبل از نصب اولین ESXi، بتوانید طراحی خود را ردیف‌به‌ردیف بررسی کنید و ضعف‌ها را در مرحله‌ای پیدا کنید که اصلاحشان هنوز ارزان است.
خلاصه سریع طراحی زیرساخت VMware
- طراحی زیرساخت VMware از «استراتژی لایسنس و چرخه عمر» شروع می‌شود، نه از سخت‌افزار.
- قاعده پایه: خوشه حداقل N+1، شبکه و ذخیره‌سازی بدون نقطه شکست واحد، و بک‌آپ تست‌شده.
- رم و I/O ذخیره‌سازی معمولاً پیش از CPU گلوگاه می‌شوند.
- لایسنس بر اساس هسته است و حداقل ۱۶ هسته برای هر پردازنده محاسبه می‌شود؛ تعداد هسته را بدون توجه به لایسنس انتخاب نکنید.
- در ایران، موضوع لایسنس، پشتیبانی رسمی و بروزرسانی را باید جزو ریسک‌های اصلی پروژه ثبت کنید.
وضعیت لایسنس و چرخه عمر VMware در سال ۱۴۰۵؛ چیزهایی که باید قبل از طراحی زیرساخت VMware بدانید
طراحی بدون شناخت وضعیت محصول، خطرناک است. بر اساس منابع منتشرشده تا مهر ۱۴۰۵:
| موضوع | وضعیت |
|---|---|
| لایسنس دائمی (Perpetual) | از اواخر ۲۰۲۳ / ابتدای ۲۰۲۴ فروش آن متوقف شده و مدل اشتراکی جایگزین شده است |
| مدل قیمت‌گذاری | بر اساس هسته فیزیکی، با حداقل ۱۶ هسته برای هر پردازنده |
| vSphere 7 | پایان پشتیبانی عمومی: ۲ اکتبر ۲۰۲۵ (گذشته است) |
| vSphere 8 | پایان پشتیبانی عمومی: ۱۱ اکتبر ۲۰۲۷ |
| vSphere 9 | فقط داخل بسته‌های VVF و VCF عرضه می‌شود، نه به‌صورت مستقل |
| vSphere Standard | فروش آن در ژوئیه ۲۰۲۵ متوقف شد؛ Broadcom اعلام کرده نسخه بروزشده‌ای در راه است و جزئیات آن برای اواسط اکتبر ۲۰۲۶ پیش‌بینی شده است |
| حداقل ۷۲ هسته در هر سفارش | گزارش‌ها متناقض است؛ برخی منابع می‌گویند اعلام و سریعاً پس گرفته شد و برخی آن را برقرار می‌دانند. حتماً از فروشنده رسمی استعلام کنید |
نتیجه عملی برای طراحی: اگر امروز زیرساخت جدیدی طراحی می‌کنید، باید تعیین کنید روی کدام نسخه می‌ایستید و برنامه شما برای پایان پشتیبانی vSphere 8 در اکتبر ۲۰۲۷ چیست. «بعداً فکرش را می‌کنیم» یک استراتژی نیست.
ملاحظه ویژه برای سازمان‌های ایرانی
Broadcom یک شرکت آمریکایی است و مشمول مقررات صادراتی و تحریمی آمریکا می‌شود. در عمل، کانال رسمی خرید، تمدید اشتراک و پشتیبانی برای سازمان‌های ایرانی در دسترس نیست. این یک واقعیت حقوقی و فنی است که باید در ارزیابی ریسک پروژه ثبت شود:
- بروزرسانی‌ها و وصله‌های امنیتی ممکن است در دسترس نباشد.
- پس از پایان پشتیبانی هر نسخه، هیچ مرجع رسمی برای رفع مشکل وجود ندارد.
- پیش از تصمیم‌گیری، مشورت حقوقی و بررسی گزینه‌های جایگزین توصیه می‌شود.
این بخش به معنای تشویق یا راهنمایی برای دور زدن محدودیت‌ها نیست؛ فقط یادآوری می‌کند که «استراتژی خروج» (Exit Strategy) باید از همان روز اول بخشی از طراحی باشد. در بخش ۱۰ چک‌لیست، گزینه‌های جایگزین را مقایسه کرده‌ایم.
چک‌لیست طراحی زیرساخت VMware، بخش به بخش
بخش ۱: الزامات و تحلیل بار کاری
پیش از هر انتخابی، این موارد را مستند کنید:
- فهرست کامل ماشین‌های مجازی فعلی و برنامه‌ریزی‌شده (تعداد، vCPU، رم، دیسک، نوع سرویس)
- میانگین و اوج مصرف CPU، رم و I/O هر سرویس (حداقل ۳۰ روز داده واقعی)
- سرویس‌های حیاتی و RTO/RPO هرکدام
- پیش‌بینی رشد ۳ تا ۵ ساله
- الزامات قانونی یا امنیتی (بانک‌ها، نهادهای دولتی، ISPها)
- برنامه لایسنس، پشتیبانی و استراتژی خروج
- وابستگی‌های نرم‌افزاری (برخی نرم‌افزارها لایسنس بر اساس هسته یا سوکت دارند)
قاعده کلی: اگر داده واقعی مصرف ندارید، سایزینگ شما حدس است. حدس در زیرساخت، یعنی ریسک.
بخش ۲: طراحی محاسبات (Compute)
سایزینگ میزبان‌ها
- تعداد میزبان‌ها حداقل N+1 است (برای سرویس‌های حیاتی در برخی طراحی‌ها N+2)
- تمام میزبان‌های یک خوشه یکسان یا حداقل از یک نسل پردازنده هستند (برای سادگی vMotion و EVC)
- نسبت vCPU به هسته فیزیکی مشخص و محافظه‌کارانه است (برای سرویس‌های حساس معمولاً ۲:۱ تا ۴:۱)
- رم به‌صورت واقعی محاسبه شده و Overcommit رم برای سرویس‌های حیاتی پرهیز شده است
- حدود ۱۰ تا ۲۰٪ حاشیه رم و CPU برای رشد و اوج مصرف در نظر گرفته شده است
- پیکربندی NUMA برای ماشین‌های بزرگ بررسی شده است
- تعداد هسته هر پردازنده با قاعده لایسنس (حداقل ۱۶ هسته در هر CPU) هماهنگ است
مثال سایزینگ (صرفاً برای توضیح)
فرض کنید ۶۰ ماشین مجازی با میانگین ۴ vCPU و ۱۶ گیگابایت رم داریم:
| پارامتر | محاسبه | نتیجه |
|---|---|---|
| مجموع vCPU | ۶۰ × ۴ | ۲۴۰ vCPU |
| هسته فیزیکی لازم با نسبت ۴:۱ | ۲۴۰ ÷ ۴ | حدود ۶۰ هسته |
| مجموع رم | ۶۰ × ۱۶ | ۹۶۰ گیگابایت |
| رم با ۲۰٪ حاشیه | ۹۶۰ × ۱.۲ | حدود ۱۱۵۰ گیگابایت |
با ۳ میزبان و سیاست N+1، باید ۲ میزبان به‌تنهایی بار را تحمل کنند. پس هر میزبان به حداقل ۳۰ هسته و حدود ۵۸۰ گیگابایت رم نیاز دارد. یک پیکربندی منطقی: ۳ میزبان با دو پردازنده ۱۶ هسته‌ای و ۶۴۰ تا ۷۶۸ گیگابایت رم؛ که ۹۶ هسته لایسنس‌پذیر ایجاد می‌کند.
سخت‌افزار و فریمور
- مدل سرور و تمام قطعات (کارت شبکه، HBA، کنترلر RAID) در فهرست سازگاری رسمی VMware (HCL) تأیید شده‌اند
- نسخه فریمور و درایور بر اساس ماتریس سازگاری مشخص و مستند شده است
- کارت مدیریت از راه دور (iLO) فعال، با لایسنس مناسب و در شبکه مدیریت ایزوله است
- ابزار مدیریت چرخه عمر (مانند HPE OneView یا vLCM) برای بروزرسانی هماهنگ در نظر گرفته شده است
- منبع تغذیه دوگانه به دو مسیر برق مستقل وصل می‌شود
برای سرورهای پیشنهادی، به HPE ProLiant DL380 Gen11 مراجعه کنید.
بخش ۳: طراحی ذخیره‌سازی
انتخاب معماری
| گزینه | مناسب برای | نکته |
|---|---|---|
| vSAN / HCI | خوشه‌های متوسط، سادگی عملیات | وابسته به لایسنس و تعداد میزبان؛ نیازمند شبکه سریع |
| SAN خارجی (FC یا iSCSI) | سازمان‌های بزرگ، بارهای کاری حساس، ظرفیت بالا | افزونگی بالا؛ هزینه و پیچیدگی بیشتر |
| NFS / NAS | بارهای سبک تا متوسط، محیط تست، بک‌آپ | کیفیت شبکه و کنترلر تعیین‌کننده است |
| دیسک داخلی (لوکال) | آزمایشگاه، خوشه تک‌میزبان | بدون vMotion و HA واقعی؛ برای محیط حساس مناسب نیست |
چک‌لیست ذخیره‌سازی برای طراحی زیرساخت VMware
- نیاز IOPS، تأخیر (Latency) و توان عبوری هر نوع بار کاری محاسبه شده است
- نوع دیسک (SAS، SATA یا NVMe) با بار کاری هماهنگ است؛ برای دیتابیس معمولاً SSD/NVMe
- سطح RAID مناسب است (برای بارهای تصادفی معمولاً RAID 10)
- مسیرهای چندگانه (Multipathing) و افزونگی کنترلر/سوئیچ SAN تنظیم شده است
- حداقل ۲۰ تا ۳۰٪ فضای خالی در Datastoreها نگه داشته می‌شود (برای اسنپ‌شات و رشد)
- سیاست اسنپ‌شات مشخص است و اسنپ‌شات‌های قدیمی به‌صورت دوره‌ای حذف می‌شوند
- اندازه و تعداد Datastoreها با اصول عملیاتی (نه یک Datastore غول‌پیکر) طراحی شده است
- دیسک‌های اورجینال و سازگار با کنترلر انتخاب شده‌اند؛
- برای HBA، Firmware و درایور بر اساس HCL تأیید شده‌اند
بخش ۴: طراحی شبکه برای طراحی زیرساخت VMware
جداسازی ترافیک
حداقل این ترافیک‌ها باید از هم تفکیک شوند (با VLAN یا کارت شبکه مجزا):
- مدیریت (Management)
- vMotion
- ذخیره‌سازی (iSCSI / NFS / vSAN)
- ترافیک ماشین‌های مجازی (VM Network)
- (در صورت نیاز) Fault Tolerance و Replication
چک‌لیست شبکه برای طراحی زیرساخت VMware
- هر میزبان حداقل ۲ مسیر مستقل برای هر نوع ترافیک حیاتی دارد
- کارت‌های شبکه به دو سوئیچ فیزیکی مجزا متصل‌اند (نه هر دو به یک سوئیچ)
- پهنای باند متناسب است (حداقل ۱۰ گیگابیت برای vMotion و ذخیره‌سازی IPمحور؛ برای vSAN معمولاً ۱۰/۲۵ گیگابیت)
- تنظیمات MTU و VLAN در سراسر مسیر (میزبان، سوئیچ، استوریج) یکسان است
- استفاده از Distributed Switch برای مدیریت متمرکز در خوشه‌های بزرگ بررسی شده است
- شبکه مدیریت و iLO از شبکه کاربران ایزوله است
- سیاست امنیتی شبکه (فایروال، ACL) تعریف شده است
بخش ۵: طراحی خوشه و دسترس‌پذیری
- HA فعال است و Admission Control بر اساس تعداد میزبان‌های قابل‌تحمل خرابی تنظیم شده است
- DRS برای توزیع بار فعال است و حساسیت آن آگاهانه تنظیم شده است
- قوانین Affinity و Anti-Affinity برای سرویس‌های افزونه (مثل دو Domain Controller یا دو وب‌سرور) تعریف شده است
- vMotion و Storage vMotion تست شده‌اند
- سرویس‌های مدیریتی (vCenter، DNS، NTP، Active Directory) به‌گونه‌ای طراحی شده‌اند که وابستگی دایره‌ای ایجاد نکنند
- DNS و NTP مطمئن و افزونه هستند (بسیاری از مشکلات VMware ریشه در زمان و DNS دارند)
- برای سایت‌های بزرگ، جداسازی خوشه مدیریت از خوشه بار کاری بررسی شده است
- برای سرویس‌های بسیار حساس، Fault Tolerance یا معماری مقاوم در سطح برنامه ارزیابی شده است
بخش ۶: امنیت و انطباق
- راهنمای سخت‌سازی (Hardening) رسمی برای ESXi و vCenter اعمال شده است
- دسترسی‌ها بر اساس نقش (RBAC) و با کمترین سطح دسترسی لازم تعریف شده‌اند
- احراز هویت چندعاملی برای vCenter و iLO فعال یا برنامه‌ریزی شده است
- SSH در حالت عادی غیرفعال و Lockdown Mode بررسی شده است
- لاگ‌ها به یک سامانه مرکزی (Syslog/SIEM) ارسال می‌شوند
- گواهی‌ها (Certificates) معتبر و مدیریت‌شده‌اند
- Secure Boot و TPM (در صورت پشتیبانی) فعال‌اند
- برنامه بروزرسانی و وصله امنیتی (Patch Management) با فواصل مشخص تعریف شده است
- فایروال سازمانی و قوانین جداسازی شبکه‌ها طراحی شده‌اند
هشدار: اگر دسترسی به بروزرسانی‌های امنیتی رسمی ندارید، سطح ریسک این بخش بالا می‌رود و لایه‌های جبرانی (ایزولاسیون شدید شبکه، محدودسازی دسترسی، پایش دقیق) اهمیت دوچندان پیدا می‌کنند.
بخش ۷: بک‌آپ و بازیابی از بحران (DR)
- قاعده 3-2-1 رعایت می‌شود (سه نسخه، دو نوع رسانه، یک نسخه خارج از سایت)
- حداقل یک نسخه بک‌آپ تغییرناپذیر (Immutable) یا آفلاین وجود دارد (برای مقابله با باج‌افزار)
- بک‌آپ vCenter و پیکربندی ESXi جداگانه انجام می‌شود
- RPO و RTO هر سرویس با سیاست بک‌آپ/Replication تطبیق دارد
- بازیابی واقعی حداقل هر ۶ تا ۱۲ ماه تست می‌شود
- سناریوی DR مکتوب است: چه کسی، چه ترتیبی، با چه ابزاری
- سایت پشتیبان یا دیتاسنتر ثانویه (در صورت لزوم) و نحوه Replication مشخص شده است
- وابستگی بین سرویس‌ها در ترتیب بازیابی (مثلاً AD و DNS قبل از برنامه‌ها) لحاظ شده است
بخش ۸: زیرساخت فیزیکی (برق، خنک‌سازی، رک)
- هر سرور با دو منبع تغذیه به دو مسیر برق مستقل (دو PDU، ترجیحاً دو UPS) متصل است
- ظرفیت UPS و ژنراتور با رشد آینده و نوسانات برق محلی محاسبه شده است
- چگالی توان هر رک با ظرفیت خنک‌سازی هماهنگ است
- چیدمان راهروی سرد و گرم رعایت شده است
- کابل‌کشی مرتب، برچسب‌گذاری‌شده و مستند است
- امنیت فیزیکی و کنترل تردد اتاق سرور برقرار است
بخش ۹: پایش، عملیات و مستندات
- پایش لحظه‌ای CPU، رم، تأخیر دیسک، وضعیت RAID، دما و برق فعال است
- هشدارها به افراد مشخص و با اولویت‌بندی ارسال می‌شوند
- برنامه ظرفیت (Capacity Planning) دوره‌ای انجام می‌شود (مثلاً هر سه ماه)
- نقشه شبکه، شناسه‌های دسترسی، IPها و روال‌ها مستند و برای حداقل دو نفر قابل‌دسترسی است
- فرآیند مدیریت تغییر (Change Management) وجود دارد
- نسخه‌های نرم‌افزار، فریمور و درایور در یک جدول مرجع نگهداری می‌شوند
- آموزش و جانشین‌پروری برای کلید افراد فنی در نظر گرفته شده است
بخش ۱۰: چرخه عمر، لایسنس و استراتژی خروج
- تاریخ پایان پشتیبانی نرم‌افزار (ESXi/vCenter) و سخت‌افزار ثبت و در تقویم پروژه آمده است
- برنامه مهاجرت یا ارتقا برای قبل از پایان پشتیبانی نسخه فعلی مشخص است
- هزینه کل مالکیت (TCO) شامل سخت‌افزار، لایسنس، پشتیبانی، برق و نیروی انسانی محاسبه شده است
- برای سرورها چرخه تعویض (معمولاً ۴ تا ۶ سال) تعریف شده است
- قطعات یدکی حیاتی (دیسک، منبع تغذیه، فن، کارت شبکه) در انبار موجودند
- استراتژی خروج از پلتفرم فعلی (در صورت قطع دسترسی به لایسنس یا پشتیبانی) بررسی شده است
مقایسه کلی پلتفرم‌های جایگزین
| پلتفرم | نقاط قوت | نکات قابل‌توجه |
|---|---|---|
| VMware vSphere | اکوسیستم بالغ، ابزارهای متنوع، تجربه بازار | مدل اشتراکی؛ محدودیت‌های لایسنس و پشتیبانی در ایران |
| Microsoft Hyper-V | یکپارچگی با ویندوز و Active Directory | وابستگی به لایسنس مایکروسافت؛ آن هم تحت قوانین تحریم |
| Proxmox VE | متن‌باز، مبتنی بر KVM، هزینه لایسنس پایین | نیاز به تخصص لینوکس؛ اکوسیستم سازمانی کوچک‌تر |
| KVM / oVirt / OpenStack | انعطاف‌پذیری و کنترل بالا | پیچیدگی عملیاتی بالا؛ مناسب تیم‌های مجرب |
این جدول فقط نقطه شروع بررسی است. انتخاب نهایی باید بر اساس بار کاری، مهارت تیم و الزامات پشتیبانی انجام شود.
مثال واقعی (سناریوی فرضی): یک شرکت میان‌اندازه ایرانی
فرض کنید یک شرکت ۳۰۰ نفره، ۴۵ ماشین مجازی را روی دو سرور قدیمی و بدون افزونگی ذخیره‌سازی اجرا می‌کند. طراحی جدید با این چک‌لیست چنین نتیجه‌ای می‌دهد:
- بخش ۱: مشخص می‌شود ۸ سرویس حیاتی هستند و RTO آن‌ها ۴ ساعت است.
- بخش ۲: سه میزبان با سیاست N+1 تعیین می‌شود (به‌جای دو میزبان قبلی).
- بخش ۳: استوریج مشترک با افزونگی کنترلر انتخاب می‌شود تا vMotion و HA واقعی فعال شود.
- بخش ۴: شبکه به دو سوئیچ مجزا و با ترافیک جداگانه برای vMotion و ذخیره‌سازی بازطراحی می‌شود.
- بخش ۷: بک‌آپ مستقل خارج از خوشه و تست بازیابی ماهانه برای سرویس‌های حیاتی اضافه می‌شود.
- بخش ۱۰: برنامه خروج و ارزیابی جایگزین‌ها قبل از پایان پشتیبانی نسخه فعلی تدوین می‌شود.
نتیجه: هزینه اولیه بالاتر است، اما احتمال توقف چندروزه به‌شدت کاهش می‌یابد.
مزایای طراحی زیرساخت VMware اصولی با چک‌لیست
- کشف ضعف‌ها قبل از خرید و نصب
- تصمیم‌گیری مالی بر پایه داده، نه حدس
- کاهش احتمال توقف ناگهانی سرویس
- مستندات و استاندارد برای تیم‌های آینده
- مبنای مذاکره شفاف‌تر با تأمین‌کننده و پیمانکار
چالش‌ها و محدودیت‌های طراحی زیرساخت VMware
- نیاز به زمان و داده واقعی برای شروع
- هزینه اولیه بالاتر برای افزونگی
- نیاز به تخصص چندحوزه‌ای (شبکه، ذخیره‌سازی، امنیت، مجازی‌سازی)
- عدم قطعیت در لایسنس و پشتیبانی که روی طراحی بلندمدت اثر می‌گذارد
- محدودیت‌های تأمین و واردات تجهیزات در ایران
چه زمانی چک‌لیست طراحی زیرساخت VMware کامل ضروری است؟
- زمانی که سرویس‌های حیاتی سازمان روی پلتفرم مجازی‌سازی اجرا می‌شوند
- پروژه‌های بانکی، ISP، دولتی و سازمان‌های بزرگ
- هنگام تغییر نسل سخت‌افزار یا مهاجرت پلتفرم
- زمانی که الزامات قراردادی یا قانونی برای دسترس‌پذیری وجود دارد
چه زمانی نسخه ساده‌تر کافی است؟
- محیط تست و آزمایشگاه
- شرکت‌های کوچک با تعداد محدود ماشین مجازی غیرحیاتی
- پروژه‌های موقت؛ در این حالت بخش‌های ۱، ۲، ۳ و ۷ را حتماً رعایت کنید و بقیه را متناسب با ریسک ساده کنید
اشتباهات رایج در طراحی زیرساخت VMware
۱. سایزینگ بدون داده واقعی: عدد حدسی، منشأ بیشتر مشکل‌های عملکردی است.
۲. ندیدن گلوگاه رم و I/O: تمرکز صرف روی هسته‌های CPU، در حالی‌که ذخیره‌سازی و رم زودتر محدود می‌شوند.
۳. خوشه بدون افزونگی واقعی: دو میزبان بدون ظرفیت N+1، در عمل با خرابی یک میزبان دچار بحران می‌شود.
۴. شبکه تک‌مسیره: هر دو کارت شبکه به یک سوئیچ؛ نقطه شکست پنهان.
۵. بک‌آپ بدون تست بازیابی: وجود فایل پشتیبان یعنی نصف کار.
۶. نادیدن لایسنس و چرخه عمر: انتخاب سخت‌افزار و نرم‌افزار بدون برنامه برای پایان پشتیبانی.
۷. سخت‌افزار خارج از HCL: ممکن است در ظاهر کار کند، اما در لحظه بحران پشتیبانی نشود یا بروزرسانی را خراب کند.
۸. پر کردن Datastoreها تا لبه: اسنپ‌شات و رشد داده، فضای خالی می‌خواهند.
سوالات متداول طراحی زیرساخت VMware
۱. حداقل چند میزبان برای یک خوشه VMware سازمانی لازم است؟ برای HA معنادار، حداقل ۳ میزبان با سیاست N+1 توصیه می‌شود. در طراحی‌های خاص (مثل خوشه‌های دومیزبانه با Witness) هم امکان‌پذیر است اما ریسک بیشتری دارد.
۲. آیا RAID جایگزین بک‌آپ است؟ خیر. RAID در برابر خرابی دیسک محافظت می‌کند، نه حذف اشتباهی، باج‌افزار یا خرابی کل سایت.
۳. حداقل شبکه برای vMotion و ذخیره‌سازی IPمحور چیست؟ معمولاً ۱۰ گیگابیت بر ثانیه توصیه می‌شود؛ برای خوشه‌های سنگین یا vSAN، ۲۵ گیگابیت هم رایج است.
۴. چرا تعداد هسته پردازنده روی هزینه لایسنس اثر دارد؟ چون لایسنس بر اساس هسته فیزیکی است و برای هر پردازنده حداقل ۱۶ هسته محاسبه می‌شود. انتخاب پردازنده با هسته کمتر از ۱۶، هزینه لایسنس را کم نمی‌کند.
۵. vSphere 8 تا کی پشتیبانی می‌شود؟ بر اساس منابع منتشرشده، پایان پشتیبانی عمومی در ۱۱ اکتبر ۲۰۲۷ است. برای تاریخ دقیق و گزینه‌های پشتیبانی تمدیدی، منابع رسمی را بررسی کنید.
۶. آیا می‌توان روی سرور قدیمی (مثل Gen9) ESXi جدید نصب کرد؟ بستگی به نسخه و فهرست سازگاری دارد؛ بسیاری از نسخه‌های جدید دیگر از سخت‌افزار قدیمی پشتیبانی نمی‌کنند. پیش از خرید حتماً HCL را بررسی کنید.
۷. آیا سرور باید حتماً iLO داشته باشد؟ برای محیط‌های سازمانی بله؛ مدیریت از راه دور، پایش سخت‌افزار و عیب‌یابی را به‌شدت ساده می‌کند.
۸. بهترین نوع ذخیره‌سازی برای VMware چیست؟ جواب یگانه وجود ندارد. SAN خارجی برای بارهای سنگین و افزونگی بالا، vSAN برای سادگی عملیاتی، و NFS/NAS برای بارهای سبک مناسب هستند.
۹. هر چند وقت یک‌بار باید بازیابی بک‌آپ را تست کنیم؟ برای سرویس‌های حیاتی حداقل هر ۶ تا ۱۲ ماه؛ برای سیستم‌های بسیار حساس، فاصله کوتاه‌تر.
۱۰. اگر دسترسی رسمی به بروزرسانی و پشتیبانی نداشته باشیم چه کنیم؟ ریسک را ثبت و مدیریت کنید: شبکه را شدیداً ایزوله کنید، دسترسی‌ها را محدود کنید، پایش را تقویت کنید، بک‌آپ تغییرناپذیر داشته باشید و برنامه خروج یا مهاجرت به پلتفرم جایگزین را از همین امروز تدوین کنید. برای تصمیم حقوقی هم مشورت بگیرید.
جمع‌بندی
طراحی زیرساخت VMware یعنی تبدیل چند سؤال پراکنده به یک فرآیند منظم: الزامات را مشخص کنید، سخت‌افزار را بر اساس داده سایز کنید، شبکه و ذخیره‌سازی را بدون نقطه شکست واحد بچینید، امنیت و بک‌آپ را از ابتدا وارد طراحی کنید و درباره لایسنس و چرخه عمر صادقانه برنامه‌ریزی کنید.
لازم نیست در اولین قدم همه موارد را کامل کنید. بخش‌های ۱، ۲، ۳ و ۷ (الزامات، محاسبات، ذخیره‌سازی و بک‌آپ) را اول انجام دهید؛ بیشترین ریسک در همین چهار بخش پنهان است.
اگر برای سایزینگ، انتخاب سرور و استوریج مناسب پروژه خود مشاوره می‌خواهید، تیم فنی برسا آماده بررسی سناریوی شماست. سرور HPE DL380 Gen11 8SFF یک پردازنده Xeon Silver 4410Y با کنترلر MR408i-o را هم می‌توانید بررسی کنید.
