VMware vSphere برای پشتیبان شبکه

قبل از اینکه وارد ESXi یا vCenter شوی باید خود مفهوم مجازی‌سازی را روشن بفهمی، چون اگر این پایه مبهم باشد بعداً تفاوت Host، VM، Datastore، vSwitch و Resource Pool فقط به مجموعه‌ای از اسم‌ها تبدیل می‌شود. در یک سرور فیزیکی عادی، سیستم‌عامل مستقیماً از CPU، RAM، کارت شبکه و Storage همان دستگاه استفاده می‌کند و معمولاً یک سیستم‌عامل اصلی روی سخت‌افزار اجرا می‌شود. در مجازی‌سازی، یک لایه به نام Hypervisor بین سخت‌افزار و ماشین‌های مجازی قرار می‌گیرد و منابع فیزیکی را به شکل کنترل‌شده بین چند VM تقسیم می‌کند. هر VM برای سیستم‌عامل داخل خودش شبیه یک کامپیوتر مستقل است و CPU مجازی، RAM مجازی، دیسک مجازی و کارت شبکه مجازی دارد، اما این منابع در نهایت از همان سخت‌افزار واقعی Host تأمین می‌شوند. مزیت اصلی این معماری فقط کم‌کردن تعداد سرورها نیست؛ جداسازی سرویس‌ها، ساده‌ترشدن مدیریت، امکان جابه‌جایی VMها، Snapshot برای تغییر کوتاه‌مدت، Backup مبتنی بر VM، استفاده بهتر از منابع و بازیابی سریع‌تر سرویس‌ها از دلایل مهم استفاده از مجازی‌سازی در شرکت‌ها هستند. Hypervisorهای نوع یک یا Type 1 مستقیماً روی سرور نصب می‌شوند و برای محیط سازمانی مناسب‌اند، در حالی که محصولاتی مثل VMware Workstation روی یک سیستم‌عامل میزبان اجرا می‌شوند و بیشتر برای Lab، تست و آموزش کاربرد دارند. در این پک تمرکز اصلی ما روی مجازی‌سازی سازمانی VMware vSphere است تا بتوانی یک Host را نصب کنی، شبکه و Storage را بسازی، VM ایجاد کنی، vCenter را بشناسی و بعد وارد نگهداری، امنیت، Backup و عیب‌یابی واقعی شوی

در گفتگوهای روزمره گاهی عبارت‌های VMware، ESXi، vSphere و vCenter به جای هم استفاده می‌شوند، اما برای یک پشتیبان شبکه باید دقیق بدانی هر کدام به چه چیزی اشاره می‌کنند. vSphere نام پلتفرم مجازی‌سازی سازمانی VMware است و مجموعه‌ای از قابلیت‌ها برای اجرای VM، مدیریت Hostها، شبکه، Storage، Cluster، Availability و عملیات روزمره را شامل می‌شود. ESXi در نسل‌های رایج vSphere 7 و 8 همان Hypervisor نصب‌شده روی سرور فیزیکی است و مستقیماً VMها را اجرا می‌کند. در مستندات نسل جدید vSphere 9 عنوان ESX بیشتر دیده می‌شود، اما در محیط‌های عملی هنوز تعداد بسیار زیادی از زیرساخت‌ها با ESXi 7 و 8 کار می‌کنند، بنابراین در این آموزش هر جا از Host ESXi صحبت می‌کنیم منظور همان میزبان Hypervisor خانواده vSphere است. VMware Host Client رابط وب مستقیم هر Host است و معمولاً با رفتن به آدرس HTTPS همان ESXi باز می‌شود؛ اگر فقط یک Host داشته باشی بسیاری از کارهای پایه مثل ساخت VM، Datastore و vSwitch را از همین رابط انجام می‌دهی. vCenter Server لایه مدیریت مرکزی است و وقتی چند Host، Cluster، vMotion، HA، DRS، Roleهای متمرکز یا عملیات سازمانی‌تر داشته باشی اهمیتش مشخص می‌شود. vSphere Client رابط وبی است که از طریق vCenter وارد آن می‌شوی و Inventory کل زیرساخت را یکجا می‌بینی. پس ESXi محل اجرای VM است، vCenter مدیر مرکزی محیط است و vSphere نام پلتفرم و مجموعه قابلیت‌هایی است که این اجزا را کنار هم قرار می‌دهد

یکی از اشتباه‌های رایج این است که نصب VMware را از مرحله Boot کردن ISO شروع کنیم، در حالی که کیفیت محیط مجازی‌سازی قبل از آن و با انتخاب سخت‌افزار، Firmware، RAID، NIC، Storage و طراحی شبکه تعیین می‌شود. سروری که قرار است چند VM مهم را اجرا کند باید از نظر CPU، مقدار RAM، تعداد و سرعت کارت‌های شبکه، Controller ذخیره‌سازی و دیسک‌ها برای بار کاری واقعی انتخاب شود. قابلیت Virtualization پردازنده مثل Intel VT-x یا AMD-V باید در BIOS یا UEFI فعال باشد و برای بعضی سناریوها قابلیت‌هایی مثل IOMMU یا VT-d هم اهمیت پیدا می‌کند. قبل از نصب باید Hardware Compatibility را بر اساس راهنمای سازگاری Broadcom و همچنین Matrix سازنده سرور بررسی کنی، چون دیدن یک NIC یا RAID Controller توسط سیستم‌عامل‌های عمومی به این معنی نیست که Driver و Firmware آن برای ESXi یا ESX مورد استفاده تو پشتیبانی می‌شود. Firmware قدیمی یا ترکیب Driver و Firmware ناسازگار می‌تواند بعداً خودش را به شکل قطع شبکه، PSOD، مشکل Storage یا Performance نشان دهد. برای Production بهتر است Management Network را از ابتدا طراحی کنی، IP ثابت، Gateway، DNS، NTP و Hostname مشخص داشته باشی و اگر چند Host داری Naming Convention یکسان تعریف کنی. همچنین تصمیم بگیر ISO نصب عمومی VMware استفاده می‌کنی یا Custom Image سازنده سرور مثل Dell، HPE یا Lenovo، چون Imageهای OEM معمولاً Driver و Componentهای مورد نیاز سخت‌افزار همان Vendor را بهتر پوشش می‌دهند

نصب Hypervisor از نظر تعداد کلیک‌ها ساده به نظر می‌رسد، اما تصمیم‌های این مرحله می‌توانند مستقیماً روی دسترسی و Storage اثر بگذارند. بعد از Boot از Media نصب، Installer سخت‌افزار را شناسایی می‌کند و دیسک یا Device مقصد را برای نصب نشان می‌دهد. اینجا باید کاملاً مطمئن باشی کدام Device برای خود Hypervisor است و کدام Storage برای Data یا VMها استفاده خواهد شد. در سرورهای Enterprise معمول است که سیستم‌عامل Hypervisor روی Boot Device یا RAID کوچک جداگانه قرار بگیرد و Datastore روی Storage دیگری ساخته شود، اما معماری دقیق به مدل سرور و طراحی سازمان بستگی دارد. اگر Installer هیچ Disk یا NIC مورد انتظار را نمی‌بیند، قبل از هر چیز به Driver، Firmware، RAID Mode و سازگاری سخت‌افزار شک کن و با تغییرهای تصادفی ادامه نده. رمز root باید قوی، ثبت‌شده در محل امن و مطابق سیاست دسترسی شرکت باشد. بعد از پایان نصب و Reboot، صفحه Direct Console User Interface یا DCUI ظاهر می‌شود و از آنجا Management Network، DNS، Hostname و تست ارتباط را انجام می‌دهی. در نصب Production هیچ‌وقت به این دلیل که Installer جلو می‌رود نتیجه نگیر که همه چیز سالم است؛ بعد از اولین Boot باید سلامت NICها، Storage، Sensorها، Time، DNS و Logها را هم بررسی کنی تا مطمئن شوی Host فقط «نصب شده» نیست بلکه برای استفاده آماده است

DCUI همان رابط کنسولی مستقیم Host است که معمولاً روی مانیتور سرور یا از طریق iLO، iDRAC و ابزار مدیریت Out-of-Band می‌بینی. ارزش DCUI وقتی مشخص می‌شود که شبکه مدیریت خراب است و دیگر Host Client یا vCenter در دسترس نیستند. در Configure Management Network ابتدا Adapter یا Adapterهایی را که باید Management Traffic را حمل کنند انتخاب می‌کنی، سپس VLAN در صورت نیاز، IPv4 یا IPv6، DNS و Hostname را تنظیم می‌کنی. Management IP برای Host باید در محیط سازمانی ثابت و مستند باشد؛ استفاده از DHCP ممکن است در Lab قابل قبول باشد اما برای Host Production می‌تواند باعث تغییر IP و گم‌شدن مسیرهای مدیریتی، DNS یا Monitoring شود. اگر Management روی VLAN خاصی قرار دارد باید هم VLAN ID روی Port Group و هم تنظیم Trunk یا Access روی Switch فیزیکی با طراحی یکسان باشد. Test Management Network فقط یک دکمه تشریفاتی نیست؛ این تست باید Gateway و DNS Serverها را بررسی کند و اگر FQDN یا DNS مهم است، Name Resolution را هم کنترل کنی. هر تغییر روی Management Network خطر قطع دسترسی دارد، به‌خصوص اگر از راه دور کار می‌کنی؛ بنابراین قبل از تغییر NIC، VLAN یا Gateway باید مسیر جایگزین مثل iLO یا iDRAC و اطلاعات فعلی را در اختیار داشته باشی

بعد از اینکه Management Network درست شد، با مرورگر به آدرس HTTPS Host وارد می‌شوی و Host Client را می‌بینی. اولین کار یک پشتیبان حرفه‌ای این نیست که سریع VM بسازد؛ ابتدا باید Host را بخواند. در Summary نسخه Hypervisor، Uptime، وضعیت کلی، CPU و Memory، Datastoreها، Network و Warningها را ببین. منوی Host برای تنظیمات خود Hypervisor است، Virtual Machines فهرست VMهای ثبت‌شده را نشان می‌دهد، Storage شامل Datastoreها و Storage Adapterها است و Networking ساختار Physical NIC، Virtual Switch، Port Group و VMkernel NIC را نمایش می‌دهد. بخش Monitor برای Performance، Events، Tasks و Logها مهم است. هر تغییر در محیط VMware تقریباً یک Task یا Event تولید می‌کند و همین اطلاعات برای فهمیدن اینکه چه کسی، چه زمانی و چه عملی انجام داده بسیار ارزشمند است. همچنین Services را بشناس و بدان SSH و ESXi Shell بهتر است همیشه بی‌دلیل روشن نمانند. اگر Warning مربوط به License، NTP، Storage یا Hardware می‌بینی آن را نادیده نگیر؛ Warning همیشه خرابی فوری نیست اما در مستندسازی اولیه باید علتش مشخص باشد. از همین مرحله Naming و توضیح Host را استاندارد کن تا بعداً در محیط چند‌Hostی دچار سردرگمی نشوی

در VMware واژه Storage چند لایه دارد و اگر آن‌ها را قاطی کنی ممکن است هنگام عیب‌یابی یا توسعه ظرفیت تصمیم خطرناک بگیری. در پایین‌ترین سطح یک Device یا LUN داری که می‌تواند Local Disk، RAID Volume، SAN LUN، iSCSI Target، Fibre Channel یا نوع دیگری از Storage باشد. روی بعضی Deviceها فایل‌سیستم VMFS ساخته می‌شود و به شکل Datastore در اختیار Host قرار می‌گیرد، در NFS خود Share شبکه به عنوان Datastore Mount می‌شود. Datastore مثل یک فضای فایل برای VMware است که پوشه VMها، ISOها، Templateها و فایل‌های مربوط به ماشین مجازی داخل آن قرار می‌گیرند. هر VM معمولاً فایل پیکربندی VMX، دیسک یا دیسک‌های VMDK، فایل‌های Log و فایل‌های دیگری مثل NVRAM و در برخی حالت‌ها VSWP دارد. دانستن این فایل‌ها باعث می‌شود بفهمی «Remove from Inventory» با «Delete from Disk» یک چیز نیست؛ اولی فقط ثبت VM در Inventory را حذف می‌کند اما فایل‌ها روی Datastore باقی می‌مانند، در حالی که Delete می‌تواند داده واقعی VM را پاک کند. ظرفیت Datastore نیز باید جدا از فضای آزاد داخل Windows یا Linux مهمان بررسی شود، چون ممکن است Guest داخل درایو خودش فضای آزاد نشان بدهد ولی Datastore Host پر شده باشد و VM دیگر نتواند VMDK یا Snapshot را رشد دهد

برای یک Host آزمایشگاهی ممکن است Local Datastore کاملاً کافی باشد، اما وقتی چند Host، vMotion، HA یا نگهداری بدون Downtime می‌خواهی Storage مشترک نقش مهم‌تری پیدا می‌کند. VMFS فایل‌سیستم VMware برای Block Storage است و معمولاً روی Local Disk، Fibre Channel LUN یا iSCSI LUN دیده می‌شود. در iSCSI، Storage از طریق IP Network ارائه می‌شود و در نتیجه طراحی VLAN، MTU، Multipathing، NIC و Switch فیزیکی مستقیماً روی Storage اثر دارد. NFS از دید VMware یک File-based Datastore است که از یک NFS Server یا Storage Appliance Mount می‌شود. هیچ‌کدام را نباید فقط با برچسب «بهتر» یا «بدتر» انتخاب کرد؛ ظرفیت، Performance، Redundancy، Latency، قابلیت‌های Storage Array، Backup، هزینه و مهارت تیم همگی در انتخاب دخیل‌اند. برای محیط‌های چند‌Hostی باید مطمئن شوی Hostهای لازم به Datastore مشترک دسترسی پایدار دارند. اگر یک VM روی Storage محلی Host A باشد، روشن‌کردن همان VM روی Host B بدون انتقال فایل‌ها ممکن نیست. در طراحی iSCSI نیز بهتر است Management Traffic و Storage Traffic را منطقی جدا کنی و قبل از استفاده از Jumbo Frame مطمئن شوی MTU در تمام مسیر از VMkernel تا Switch و Storage یکسان است؛ Jumbo Frame نصفه‌نیمه می‌تواند خطاهای بسیار گیج‌کننده ایجاد کند

ایجاد Datastore جدید یا افزایش ظرفیت Datastore موجود از عملیات‌هایی است که باید با بیشترین دقت انجام شود، چون انتخاب Device اشتباه می‌تواند به داده‌های موجود آسیب بزند. برای Datastore جدید، ابتدا Device یا LUN را با شناسه، ظرفیت و مسیرهایش شناسایی کن و مطمئن شو Data موجود روی آن وجود ندارد یا استفاده آن در طراحی تأیید شده است. برای افزایش Datastore موجود، اگر Backend Storage ابتدا LUN را بزرگ کرده باشد، ESXi باید تغییر ظرفیت Device را ببیند و در بسیاری از سناریوها Rescan لازم است. بعد از آن ظرفیت VMFS را افزایش می‌دهی. در Cluster لازم است تغییر Storage بین Hostها هماهنگ باشد و بعد از Expansion همه Hostهای مرتبط Rescan شوند تا دید یکسانی از ظرفیت داشته باشند. Broadcom در راهنمای رسمی هشدار می‌دهد که Filterهای vCenter برای جلوگیری از استفاده ناسالم از LUNها نباید بی‌دلیل غیرفعال شوند. از دید عملی، همیشه قبل از Expansion فضای آزاد فعلی، Snapshotهای بزرگ، Backup Jobهای در حال اجرا و وضعیت Array را بررسی کن. افزایش ظرفیت درمان اصلی طراحی نامناسب نیست؛ اگر Datastore دائماً به مرز پرشدن می‌رسد باید علت رشد را پیدا کنی، نه اینکه هر بار فقط چند گیگابایت اضافه کنی

شبکه در ESXi زمانی ساده می‌شود که مسیر Packet را از کارت شبکه مجازی VM تا Switch فیزیکی روی کاغذ بکشی. داخل VM یک vNIC مثل vmxnet3 یا E1000E وجود دارد. این vNIC به Port Group وصل می‌شود. Port Group روی یک Virtual Switch قرار دارد و Virtual Switch از Uplink یا همان Physical NICهای ESXi که معمولاً vmnic0، vmnic1 و مانند آن نام دارند برای خروج ترافیک به شبکه فیزیکی استفاده می‌کند. برای ترافیک‌های خود Host مثل Management، vMotion، iSCSI یا vSAN معمولاً VMkernel NIC با نام vmk0، vmk1 و غیره وجود دارد. VLAN معمولاً روی Port Group مشخص می‌شود و باید با Trunk یا Access Configuration روی Switch فیزیکی سازگار باشد. vSphere Standard Switch یا vSS روی هر Host به صورت محلی مدیریت می‌شود، در حالی که vSphere Distributed Switch مدیریت شبکه را در سطح vCenter متمرکز می‌کند و قابلیت‌های بیشتری دارد. برای پشتیبان شبکه مهم‌ترین کار این است که بدانی هر مشکل در کدام لایه است؛ اگر Physical NIC Link Down باشد تغییر IP داخل VM چیزی را حل نمی‌کند، اگر VLAN اشتباه روی Port Group باشد Ping Gateway داخل Guest ممکن است شکست بخورد با اینکه vmnic سالم است. همین مدل لایه‌ای پایه اصلی عیب‌یابی شبکه VMware است

وقتی یک VM یا خود Host ارتباط شبکه ندارد، وسوسه‌انگیز است که مستقیم سراغ IP، Firewall یا VLAN برویم، اما عیب‌یابی حرفه‌ای از Physical Layer شروع می‌شود. در Host Client بخش Networking > Physical NICs باید vmnicهای شناسایی‌شده، Driver، MAC Address، Link Speed و وضعیت Link را ببینی. اگر NIC مورد انتظار اصلاً دیده نمی‌شود موضوع می‌تواند Driver، Firmware، PCIe Slot یا ناسازگاری سخت‌افزار باشد. اگر NIC دیده می‌شود ولی Link Down است، کابل، SFP، Switch Port، Speed Negotiation و Port Shutdown باید بررسی شوند. در سرورهایی با چند NIC، حتماً Map فیزیکی بساز که بدانی vmnic0 واقعاً به کدام Port Switch وصل است؛ حدس بر اساس ترتیب کارت‌ها اشتباه رایجی است. Broadcom برای موارد NIC Missing تأکید می‌کند Driver و Firmware باید با Hardware سازگار باشند. در محیط Production قبل از Update Driver یا Firmware باید نسخه فعلی، Compatibility و Rollback Plan را ثبت کنی. اگر یک Uplink از Team قطع شده ولی Uplink دیگر فعال است ممکن است کاربران هیچ قطعی واضحی نبینند، اما Redundancy از بین رفته باشد و خرابی دوم سرویس را قطع کند؛ بنابراین Monitoring Link State اهمیت زیادی دارد

Port Group رابط منطقی بین VM یا VMkernel و Virtual Switch است. در شبکه‌های شرکتی معمولاً برای هر VLAN یا نوع Traffic یک Port Group با نام واضح ساخته می‌شود؛ مثلاً PG-SERVER-VLAN20 یا MGMT-VLAN10. نام به تنهایی هیچ کاری انجام نمی‌دهد و VLAN ID واقعی باید درست تنظیم شود. اگر Port Group روی VLAN 20 است ولی Port فیزیکی Switch فقط VLAN 10 را عبور می‌دهد، VM ارتباط نخواهد داشت. اگر Switch Port به شکل Trunk است، VLANهای لازم باید Allowed باشند. NIC Teaming مشخص می‌کند کدام Uplink Active، Standby یا Unused است و Load Balancing و Failover چگونه انجام می‌شود. برای Management یا Storage بهتر است طراحی Redundancy را آگاهانه انجام بدهی و فقط دو NIC را بدون شناخت Policy کنار هم نگذاری. MTU نیز باید در vSwitch، VMkernel و شبکه فیزیکی هماهنگ باشد. تغییر VLAN Management از راه دور یکی از عملیات‌های پرریسک است؛ یک عدد اشتباه می‌تواند Session تو را قطع کند. قبل از تغییر باید Screenshot یا Export وضعیت فعلی و Out-of-Band Access داشته باشی. اگر بعد از تغییر ارتباط قطع شد، با مدل لایه‌ای بررسی کن: Physical Link، Uplink Assignment، VLAN، IP، Gateway و در نهایت Firewall

ساخت VM فقط انتخاب CPU و RAM نیست. Wizard ایجاد ماشین مجازی از تو نام، Compute Resource، Datastore، Compatibility یا Virtual Hardware Version، Guest OS Family، CPU، Memory، Disk، Network و گاهی Controllerها را می‌خواهد. نام VM باید استاندارد و قابل جست‌وجو باشد. تعداد vCPU را از روی «هرچه بیشتر بهتر» انتخاب نکن؛ VM با vCPU بیش از نیاز می‌تواند Scheduler را سخت‌تر کند و CPU Ready را بالا ببرد. RAM را بر اساس Workload و Minimum سیستم‌عامل تعیین کن و در Production قبل از دادن Memory بسیار زیاد، مصرف واقعی را ببین. در Disk باید تفاوت Thin و Thick را بفهمی؛ Thin Provisioning در ابتدا فقط فضای مصرف‌شده را می‌گیرد و با رشد داده بزرگ می‌شود، بنابراین Datastore باید مانیتور شود تا مجموع Provisioned Capacity تو را فریب ندهد. نوع SCSI Controller و Virtual NIC نیز بر Performance و Compatibility اثر دارند و برای بسیاری از Workloadهای جدید، PVSCSI و VMXNET3 گزینه‌های رایج‌اند، اما همیشه Guest OS و کاربرد را در نظر بگیر. Network Adapter باید به Port Group صحیح وصل شود و CD/DVD برای نصب ISO تنظیم شود. بعد از ساخت، قبل از Power On یک بار کل Summary تنظیمات را مرور کن

VM در VMware فقط یک آیکن در Inventory نیست؛ مجموعه‌ای از فایل‌ها روی Datastore است. فایل VMX پیکربندی VM را نگه می‌دارد، VMDK دیسک مجازی و Descriptorهای مربوط به آن را تشکیل می‌دهد، NVRAM تنظیمات Firmware مجازی را نگه می‌دارد، Logها تاریخچه اجرای VM را ثبت می‌کنند و Snapshotها فایل‌های Delta و Metadata مخصوص خود را دارند. Register یعنی یک فایل VMX موجود را دوباره به Inventory یک Host یا vCenter معرفی کنی. Unregister یا Remove from Inventory ثبت VM را از Inventory حذف می‌کند اما معمولاً فایل‌هایش را روی Datastore نگه می‌دارد. Delete from Disk یا Delete from Datastore داستان دیگری است و داده فیزیکی VM را حذف می‌کند. وقتی VM به حالت Orphaned یا Invalid درآمده، اولین راه‌حل نباید حذف فایل‌ها باشد؛ باید Datastore و VMX را پیدا کنی و علت قطع Registration را بفهمی. Broadcom توصیه می‌کند اگر Host توسط vCenter مدیریت می‌شود، Registration را از طریق vCenter انجام دهی تا Inventory بین Host و vCenter ناسازگار نشود. در عملیات Restore Backup یا انتقال دستی VM نیز همین مفاهیم اهمیت پیدا می‌کنند

بعد از ساخت VM و اتصال ISO، سیستم‌عامل Guest را مثل یک سرور معمولی نصب می‌کنی اما چند نکته VMware مخصوص وجود دارد. ابتدا Boot Order و اتصال CD/DVD را بررسی کن. اگر Installer دیسک یا NIC را نمی‌بیند ممکن است نوع Virtual Controller یا Driver مهم باشد. پس از نصب Guest، VMware Tools یکی از اجزای مهم است؛ Tools مجموعه Driverها و Serviceهایی است که Integration بین Guest و Hypervisor را بهتر می‌کند و قابلیت‌هایی مانند Driver مناسب کارت شبکه، هماهنگی بهتر Shutdown از vSphere، گزارش IP و Guest Information و بسیاری از عملیات Backup و مدیریت Guest را پشتیبانی می‌کند. در Windows معمولاً از Guest OS > Install/Upgrade VMware Tools، ISO مربوط به Tools به VM Mount می‌شود و Installer داخل Guest اجرا می‌شود. بعد از نصب، Version و Status ابزار را در Summary بررسی کن. Tools را رها نکن تا سال‌ها قدیمی بماند، ولی Upgrade را هم بدون بررسی Compatibility و برنامه Maintenance روی سرور حساس انجام نده. در Linuxهای جدید بخشی از Guestها از open-vm-tools استفاده می‌کنند که از Repository سیستم‌عامل مدیریت می‌شود. همچنین Time Sync را آگاهانه تنظیم کن؛ برای Domain Controllerها و محیط Active Directory باید معماری Time با دقت طراحی شود و نباید فقط به Sync تصادفی Host تکیه کرد

در vSphere چند عملیات Power شبیه دکمه‌های یک کامپیوتر واقعی داری اما رفتار آن‌ها یکسان نیست. Power Off شبیه قطع برق VM است و اگر Guest در حال نوشتن داده باشد می‌تواند باعث خرابی فایل‌سیستم یا Application شود. Shut Down Guest OS وقتی VMware Tools و Guest سالم باشند درخواست Shutdown مرتب را به سیستم‌عامل می‌فرستد و برای خاموش‌کردن عادی گزینه مناسب‌تری است. Reset مثل فشردن Reset سخت‌افزاری است و با Restart داخل Windows تفاوت دارد. Suspend وضعیت اجرای VM را نگه می‌دارد تا بعداً Resume شود و برای همه Workloadها یا سناریوهای Production گزینه معمولی نیست. در Incident واقعی باید قبل از Power Off اجباری بفهمی VM واقعاً Hang شده یا فقط Console پاسخ نمی‌دهد؛ Ping، Service، Event Log، Performance و وضعیت Storage را بررسی کن. گاهی Datastore Full یا Storage Latency باعث Freeze VM می‌شود و Power Cycle بدون حل علت فقط مشکل را بدتر می‌کند. اگر vCenter در دسترس نیست می‌توانی مستقیم به Host Client متصل شوی و وضعیت VM را ببینی، اما در محیط Managed اقدامات مستقیم را مستند کن

در یک Host مجازی‌سازی ممکن است مجموع vCPU و Memory تعریف‌شده برای VMها از منابع فیزیکی بیشتر باشد و این موضوع به خودی خود همیشه اشتباه نیست، اما Overcommit بدون Monitoring می‌تواند Performance را خراب کند. vCPU تعداد پردازنده‌های منطقی ارائه‌شده به Guest است، نه تضمین یک Core فیزیکی اختصاصی. ESXi باید زمان CPU را بین VMها Scheduler کند و اگر یک VM vCPU بسیار زیادی داشته باشد ممکن است برای اجرای هم‌زمان آن‌ها منتظر منابع بماند. شاخص‌هایی مثل CPU Ready در تحلیل Performance اهمیت دارند. در Memory نیز Guest مقدار RAM مجازی می‌بیند، اما Host تکنیک‌های مدیریت Memory دارد و اگر فشار زیاد شود Ballooning یا Swapping می‌تواند رخ دهد که روی Performance اثر جدی می‌گذارد. Reservation حداقل منبع تضمین‌شده، Limit سقف مصرف و Shares اولویت نسبی در زمان Contention را تعریف می‌کنند. تنظیم Limit بدون دلیل یکی از خطاهای رایج است چون ممکن است VM حتی در Host خلوت هم نتواند بیشتر از سقف تعیین‌شده استفاده کند. برای Serverهای حساس قبل از تغییر Resource باید Baseline مصرف واقعی را ببینی. افزودن RAM یا CPU فقط وقتی درست است که Bottleneck واقعاً همان منبع باشد

Snapshot وضعیت یک VM را در یک نقطه زمانی نگه می‌دارد تا تغییرهای بعدی در فایل‌های Delta ثبت شوند و امکان Revert فراهم شود. این قابلیت برای تغییر کوتاه‌مدت، Patch، Upgrade یا تستی که ممکن است نیاز به برگشت سریع داشته باشد مفید است، اما Snapshot Backup نیست. Broadcom صریحاً توصیه می‌کند Snapshot را به عنوان Backup استفاده نکن و Snapshot را برای مدت طولانی نگه ندار؛ در Best Practice رسمی نگهداری یک Snapshot بیش از 72 ساعت توصیه نمی‌شود و تعداد Snapshotهای زنجیره‌ای نیز باید کم نگه داشته شود. هرچه Snapshot بیشتر بماند Delta رشد می‌کند، Datastore Space بیشتری مصرف می‌شود و Consolidation زمان و فضای کاری بیشتری می‌خواهد. Snapshot با Memory اندازه بزرگ‌تری دارد و Revert آن وضعیت RAM را هم برمی‌گرداند. Quiesce نیز به Guest و VMware Tools وابسته است و برای Application Consistency مفهوم خاصی دارد. Delete Snapshot به معنی حذف داده فعلی VM نیست؛ در واقع تغییرهای Delta باید با Base Disk ادغام شوند. در VMهای بزرگ Consolidation می‌تواند Storage I/O سنگینی ایجاد کند، بنابراین زمان و فضای آزاد Datastore را قبل از عملیات بررسی کن

وقتی می‌خواهی VM جدید بسازی همیشه لازم نیست از صفر سیستم‌عامل نصب کنی. Clone یک کپی از VM موجود می‌سازد و برای ساخت سریع VM مشابه مناسب است، اما قبل از Clone باید هویت سیستم‌عامل، SID، IP، Application Identity و عضویت Domain را در نظر بگیری. Template یک Master غیرقابل اجرا برای Deploy VMهای استاندارد است و در محیط vCenter برای استانداردسازی Server Build بسیار مفید است. OVF یا OVA قالب قابل انتقالی برای بسته‌بندی Appliance یا VM است و در Import یا Export بین محیط‌ها استفاده می‌شود. Register VM وقتی کاربرد دارد که فایل‌های VM از قبل روی Datastore هستند اما Inventory آن را نمی‌شناسد. هیچ‌کدام از این‌ها جای Backup را نمی‌گیرد. اگر Clone را از VM Domain-joined و دارای IP ثابت بدون Sysprep یا Customization درست انجام دهی، Duplicate Identity و IP Conflict می‌تواند ایجاد شود. همچنین ISO یا Deviceهای متصل به VM Source را قبل از Template یا Migration بررسی کن. در محیط vCenter می‌توان Customization Specification برای تنظیم Hostname، Network و Guest Customization ساخت تا Deploy استانداردتر شود

vCenter Server وقتی ارزش واقعی خود را نشان می‌دهد که محیط از یک Host مستقل بزرگ‌تر شود. vCenter یک Appliance مجازی است که Inventory، Permission، Cluster، vMotion، HA، DRS، Lifecycle و بسیاری از عملیات متمرکز را مدیریت می‌کند. برای Deploy vCenter باید DNS، FQDN، Time، Management Network و Storage را از قبل درست داشته باشی؛ مشکلات DNS و NTP از دلایل رایج خطاهای سرویس و Certificate هستند. بعد از Deploy، وارد vSphere Client می‌شوی، Datacenter Object می‌سازی و Hostها را با Management Address یا FQDN اضافه می‌کنی. وقتی Host تحت مدیریت vCenter قرار گرفت بهتر است تغییرهای مدیریتی را تا حد امکان از vCenter انجام دهی تا Inventory و Configuration منسجم بماند. Permissionها نیز از همینجا در سطح Datacenter، Cluster، Host، VM و Folder قابل تعریف می‌شوند. Backup خود vCenter را فراموش نکن؛ Backup VM عادی از VCSA با File-based Backup داخلی تفاوت دارد و در طراحی بازیابی باید روش پشتیبانی‌شده را مشخص کنی. همچنین Database و Storage vCenter باید ظرفیت کافی داشته باشند چون Events، Tasks و Metrics با گذشت زمان رشد می‌کنند

Cluster چند Host را زیر یک مدیریت منطقی قرار می‌دهد تا بتوانی قابلیت‌هایی مثل HA و DRS را به شکل هماهنگ استفاده کنی. vSphere HA برای سناریوی خرابی Host طراحی شده و در صورت از دست رفتن یک Host می‌تواند VMهای آن را روی Hostهای دیگر Restart کند؛ این Reboot سرویس است و با Fault Tolerance یا Zero-Downtime یکی نیست. برای HA باید Capacity کافی روی Hostهای باقی‌مانده و دسترسی به Storage و Network لازم وجود داشته باشد. DRS بار CPU و Memory را بین Hostهای Cluster تحلیل می‌کند و با vMotion می‌تواند VMها را جابه‌جا کند یا پیشنهاد Migration بدهد. EVC مجموعه قابلیت‌های CPU را در Cluster به یک Baseline سازگار محدود می‌کند تا vMotion بین نسل‌های متفاوت CPU امکان‌پذیرتر شود. اگر Hostها CPU بسیار متفاوت داشته باشند و EVC از ابتدا طراحی نشده باشد، vMotion VM روشن می‌تواند Fail شود. Admission Control در HA نیز برای رزرو ظرفیت Failover اهمیت دارد. هیچ‌کدام از این قابلیت‌ها جای Backup را نمی‌گیرد و Cluster هم خرابی منطقی Application یا حذف فایل را حل نمی‌کند

vMotion برای جابه‌جایی VM روشن بین Hostها بدون خاموش‌کردن Guest طراحی شده و Storage vMotion دیسک‌ها و فایل‌های VM را بین Datastoreها منتقل می‌کند. برای vMotion موفق، Hostها باید Network مناسب VMotion، Connectivity لازم، CPU Compatibility و دسترسی به منابع مورد نیاز VM داشته باشند. اگر CD/DVD یک ISO روی Datastore محلی Host Source متصل باشد و Destination به آن دسترسی نداشته باشد Migration می‌تواند Fail شود. در vMotion Network معمولاً VMkernel Adapter مخصوص ساخته می‌شود و Bandwidth و Redundancy اهمیت دارند. Storage vMotion برای تخلیه Datastore، جابه‌جایی به Storage سریع‌تر یا Maintenance بسیار مفید است، اما I/O قابل توجه تولید می‌کند و در زمان Peak باید Performance را در نظر بگیری. Migration Wizard قبل از اجرا Compatibility Check انجام می‌دهد و Warning آن را نباید فقط Next کنی؛ متن دقیق خطا معمولاً علت واقعی را نشان می‌دهد. در محیط‌های Mixed CPU، EVC و Microcode اهمیت پیدا می‌کند. قبل و بعد از Migration باید Network، VMware Tools، Application Health و Datastore Location را بررسی کنی

محیط VMware معمولاً کنترل تعداد زیادی Server و Data را در یک نقطه جمع می‌کند، بنابراین Credential و Permission آن بسیار حساس‌اند. استفاده مشترک از root بین چند نفر باعث می‌شود Audit دقیق نداشته باشی. در vCenter بهتر است کاربران یا Groupها با Roleهای مناسب و اصل Least Privilege تعریف شوند. Administrator نباید تنها Role موجود باشد؛ برای Help Desk، Backup Operator، Monitoring یا تیم‌های مختلف می‌توان دسترسی محدودتر تعریف کرد. Authentication به Active Directory یا Identity Provider باید مطابق نسخه و طراحی سازمان پیاده‌سازی شود و نباید Credential شخصی را داخل Script یا Documentation عمومی ذخیره کنی. روی ESXi، SSH و ESXi Shell را فقط در زمان نیاز روشن کن و بعد از پایان کار خاموش کن، چون روشن‌بودن دائمی سطح حمله را افزایش می‌دهد. Lockdown Mode در محیط‌های vCenter-managed می‌تواند دسترسی مستقیم Host را محدودتر کند، اما قبل از فعال‌سازی باید Emergency Access را بشناسی. Certificate Warningها را هم عادی فرض نکن؛ در Production بهتر است Certificate Lifecycle و Expiration مانیتور شود. Password Rotation بدون مستندسازی می‌تواند هنگام بحران تیم را از Host قفل کند، بنابراین امنیت باید هم‌زمان با Availability طراحی شود

Backup در VMware چند لایه دارد و باید مشخص کنی دقیقاً چه چیزی را می‌خواهی بازیابی کنی. Backup ماشین مجازی باید بتواند VMDK و Configuration VM را به شکلی مستقل از Datastore اصلی محافظت کند و Restore آن عملاً تست شده باشد. بسیاری از محصولات Backup از APIهای vSphere و Changed Block Tracking یا CBT استفاده می‌کنند تا بعد از Full Backup فقط Blockهای تغییرکرده را بخوانند و Jobهای Incremental سریع‌تر شوند. Snapshot موقت ممکن است بخشی از فرآیند Backup باشد اما خودش Backup نیست. علاوه بر VMها، Configuration خود Host ESXi نیز قابل Backup است و Broadcom روش Backup و Restore Configuration را مستند کرده است؛ این Backup برای بازسازی تنظیمات Host مفید است اما جای Backup VMها را نمی‌گیرد. vCenter نیز File-based Backup مخصوص خود را دارد و باید جداگانه برنامه‌ریزی شود. قانون مهم این است که Backup تا وقتی Restore Test نشده قابل اعتماد نیست. RPO مشخص می‌کند حداکثر چه مقدار Data Loss قابل قبول است و RTO نشان می‌دهد سرویس باید در چه زمانی برگردد. این دو عدد باید از نیاز کسب‌وکار بیایند نه از حدس تیم IT. Backup Repository نیز نباید تنها در همان Storage و همان Failure Domain زیرساخت Production باشد

Patch کردن Hostهای VMware باید مثل یک Change رسمی انجام شود. قبل از Update باید Compatibility سخت‌افزار، Firmware، Driver، Add-on سازنده، نسخه vCenter و مسیر Upgrade بررسی شود. در محیط vCenter، Lifecycle Manager می‌تواند Image یا Baseline را مدیریت و Compliance Hostها را بررسی کند. Host معمولاً برای Remediation وارد Maintenance Mode می‌شود؛ یعنی VMهای روی آن باید خاموش یا به Host دیگر منتقل شوند. اگر Cluster و vMotion آماده باشد Migration می‌تواند بدون خاموشی Guest انجام شود، اما Host مستقل چنین امکانی ندارد و باید Downtime را برنامه‌ریزی کنی. قبل از Maintenance Mode باید VMهای Local Storage، Passthrough Deviceها، Affinity Ruleها و ظرفیت Cluster را بررسی کنی چون می‌توانند ورود به Maintenance Mode را Block کنند. بعد از Patch فقط Version را نگاه نکن؛ Network، Datastore، VMkernel، Hardware Health و Connectivity به vCenter را تست کن. اگر Vendor Custom Image استفاده می‌کنی Update عمومی بدون توجه به Add-on و Driver می‌تواند Compatibility را خراب کند. Rollback Plan و Backup Configuration باید قبل از شروع وجود داشته باشد

یک زیرساخت مجازی‌سازی بدون Monitoring فقط وقتی دیده می‌شود که کاربر شکایت کند. vSphere Performance Chartها برای CPU، Memory، Network و Storage نقطه شروع خوبی هستند، اما باید Alarm و Trend هم داشته باشی. Datastore Free Space، Host Memory Pressure، CPU Contention، NIC Link، Hardware Sensor، Snapshot Age، Backup Status و Certificate Expiration از مواردی هستند که باید پایش شوند. Events و Tasks برای بررسی تغییرات مدیریتی مهم‌اند و Logها در Incident جزئیات دقیق‌تری می‌دهند. hostd.log، vpxa.log، vmkernel.log و vmware.log هر کدام در سطح متفاوتی اطلاعات دارند و نباید بدون هدف همه Logها را بخوانی؛ ابتدا Scope مشکل را مشخص کن. Time و NTP برای Timestamp Log، Authentication و Certificate بسیار مهم‌اند. اگر Time Host و vCenter چند دقیقه اختلاف جدی داشته باشد Correlation رویدادها سخت می‌شود و بعضی سرویس‌ها ممکن است خطا بدهند. در محیط Production بهتر است Syslog مرکزی و Retention مناسب داشته باشی تا با Reboot یا چرخش Log شواهد Incident از بین نرود. Baseline Performance نیز کمک می‌کند بفهمی عدد فعلی واقعاً غیرعادی است یا همیشه همین بوده

پرشدن Datastore می‌تواند VM را متوقف یا بسیار ناپایدار کند، مخصوصاً وقتی Thin Provisioning، Snapshotهای قدیمی یا Backupهای ناقص وجود دارند. فضای آزاد داخل Guest با فضای Datastore فرق دارد و ممکن است Windows داخل VM چندصد گیگابایت Free نشان بدهد اما Datastore Host تقریباً صفر شده باشد. وقتی Snapshot فعال است فایل Delta رشد می‌کند و Consolidation نیز برای Merge کردن Blockها به فضای کاری نیاز دارد. اگر Datastore 100 درصد پر شود، عملیات نوشتن VMDK، Swap و Snapshot می‌تواند Fail شود و VM پیام No space for virtual disk نشان بدهد. اولین اقدام Reboot Host نیست چون Reboot هیچ فضایی آزاد نمی‌کند. ابتدا باید مصرف را بفهمی: VMهای بزرگ، Snapshotها، ISOها، Log Bundleهای قدیمی و فایل‌های Orphan را بررسی کن. حذف فایل ناشناخته بدون شناخت خطرناک است. اگر Backend Storage قابلیت Expansion دارد می‌توان LUN و سپس VMFS را افزایش داد، یا VM را به Datastore دیگر Storage vMotion کرد. برای Thin Provisioning باید Threshold Monitoring داشته باشی و فقط مجموع ظرفیت اسمی VMDKها را نگاه نکنی

عیب‌یابی شبکه VMware زمانی سریع می‌شود که به جای تغییرهای تصادفی یک مسیر ثابت داشته باشی. ابتدا Scope را مشخص کن: فقط یک VM مشکل دارد، همه VMهای یک Port Group، کل Host یا فقط Management Network؟ بعد Physical NIC و Link State را بررسی کن. سپس Mapping vNIC به Port Group، VLAN، vSwitch و Uplink را ببین. بعد IP، Gateway و Route در VMkernel یا Guest را بررسی کن. اگر ترافیک هنوز مبهم است، ESXi ابزارهای خط فرمان برای مشاهده Interface، Switch و Packet دارد. net-stats می‌تواند Mapping Portها را نشان دهد و pktcap-uw ابزار Packet Capture داخل Hypervisor است که Broadcom برای Capture در نقاط مختلف vSwitch و Distributed Switch مستند کرده است. Packet Capture را باید با هدف انجام دهی؛ Capture طولانی و بدون Filter می‌تواند فایل بسیار بزرگ تولید کند. Broadcom توصیه می‌کند فایل Capture را روی Datastore مناسب ذخیره کنی و از /tmp برای فایل‌های بزرگ استفاده نکنی. در Production قبل از SSH باید Scope و زمان Capture را مشخص کنی. اگر Packets در vNIC دیده می‌شوند ولی روی Uplink نه، مشکل در لایه مجازی است؛ اگر روی Uplink خارج می‌شوند ولی Reply برنمی‌گردد باید شبکه فیزیکی، VLAN، Gateway یا Firewall بیرونی را بررسی کنی

در کار واقعی همیشه مشکل‌ها دقیقاً مطابق فصل‌های کتاب ظاهر نمی‌شوند، بنابراین باید یک روش ثابت Diagnosis داشته باشی. اگر Host در vCenter Disconnected است، ابتدا بررسی کن Host خودش روشن و Host Client قابل دسترس است یا نه؛ سپس DNS، Management Network، Time، Certificate و سرویس‌های مدیریتی را بررسی کن. اگر VM Orphaned است، اول Datastore و VMX را پیدا کن و مطمئن شو Host یا Storage تغییر نکرده است. اگر VM روشن نمی‌شود، Error دقیق Task را بخوان، Datastore Space، File Lock، Snapshot State، Resource Availability و Virtual Hardware را بررسی کن. اگر Ping ندارد، قبل از تغییر Firewall Guest، Port Group و VLAN را بررسی کن. اگر Snapshot حذف نمی‌شود، Disk Chain و Free Space مهم‌اند و Delete دستی Delta فایل راه‌حل نیست. اگر NIC Host Missing است، Driver/Firmware/Hardware را بررسی کن. اگر Storage Latency زیاد است، Guest را متهم نکن؛ Adapter، Path، Array و Network Storage را هم ببین. مهم‌ترین عادت این است که قبل از تغییر Evidence جمع کنی و بعد فقط یک متغیر را تغییر بدهی تا نتیجه قابل فهم باشد

وقتی محیط VMware را راه‌اندازی یا بازطراحی می‌کنی، تحویل حرفه‌ای فقط روشن‌بودن VMها نیست. باید Inventory کامل Hostها، Serial و Model، نسخه ESXi یا ESX، Build، Firmware، Management IP، DNS، NTP، vCenter، Datastore، LUN، Storage Path، vSwitch یا Distributed Switch، Port Group، VLAN، vmnic Mapping، Backup Job، License و Credential Ownership مستند باشد. Diagram شبکه مجازی باید نشان بدهد هر vmnic به کدام Switch Port متصل است و هر Port Group چه VLANی دارد. برای هر VM نام، نقش، IP، OS، CPU، RAM، Datastore، Backup Policy و Criticality را ثبت کن. Runbook عملیات‌های حساس مثل Shutdown کامل سایت، روشن‌کردن بعد از قطعی برق، Backup Restore، ورود به Maintenance Mode و بازیابی Management Network را بنویس. Alarmها و Backup را تست کن، فقط Configure نکن. همچنین یک Change Log ساده داشته باش که تغییرهای مهم VMware در آن ثبت شوند. مستند محرمانه Credential را از مستند زیرساخت جدا نگه دار. در پایان باید فرد دیگری از تیم بتواند بدون حضور تو وضعیت محیط را بفهمد و عملیات عادی یا بحران اولیه را انجام دهد؛ اگر همه اطلاعات فقط در ذهن Admin است، زیرساخت هنوز حرفه‌ای تحویل نشده است