جهت رفع هرگونه مشکل در Esxi و vCenter با ما تماس بگیرید.

رفع ایرادات vcenter و ایرادات ESXi

در این راهنمای عملی، فرایند رفع ایرادات ESXi و vCenter  را گام‌به‌گام مرور می‌کنیم تا با کمترین وقفه سرویس‌ها را پایدار نگه دارید. ESXi هستهٔ مجازی‌سازی و vCenter مرکز مدیریت است؛ بنابراین برای رفع مشکل ESXi و vCenter باید ریشه‌یابی استاندارد، مانیتورینگ درست و مستندسازی دقیق داشته باشید.

چکیده مدیریتی: مشکل از کجاست؟

عیب‌یابی VMware می‌تواند پیچیده باشد. اگر سرورهای شما از کار افتاده‌اند و به دنبال راه‌حل سریع هستید، مشکلات معمولاً به یکی از این سه دسته تقسیم می‌شوند: ۱) مشکلات شبکه (مانند قطع شدن ارتباط هاست)، ۲) مشکلات ذخیره‌سازی (Storage) (مانند قفل شدن فایل‌ها یا قطعی SAN)، یا ۳) ناهماهنگی‌های سیستمی (مانند پر شدن دیسک vCenter یا مشکلات DNS و NTP).

این مقاله به جزئیات فنی عمیق این خطاها می‌پردازد. یکی از عمده خطاها رفع مشکل عدم شناسایی هارد در vcenter اگر برای خواندن جزئیات فنی زمان ندارید یا ترجیح می‌دهید یک متخصص فوراً مشکل را بررسی کند، می‌توانید مستقیماً با ما تماس بگیرید. هدف ما کمک به شما برای رفع مشکل vcenter در سریع‌ترین زمان ممکن است.

چک‌لیست شروع سریع (First Response)

قبل از هر اقدام پیچیده‌ای، این چک‌لیست اولیه می‌تواند ۷۰ درصد مشکلات رایج را مشخص کند.

• سلامت هاست: esxtop را باز کنید؛ CPU (%USED/%RDY)، MEM (SWAP/ZIP/BAL)، DISK و NET را بررسی کنید.
• شبکه مدیریت: vmkping <vcenter/host-ip> و برای Jumbo: vmkping -d -s 8972.
• زمان و DNS: NTP روی همهٔ هاست‌ها و vCenter همگام باشد؛ FQDN و رکوردهای A/PTR بررسی شوند.
• Datastore: esxcli storage filesystem list و /var/log/vmkernel.log را برای APD/PDL و Latency چک کنید.
• رخدادها: در vCenter به Tasks & Events و Alarms سر بزنید و الگوی خطا را پیدا کنید.

فلسفه عیب‌یابی: رویکرد لایه‌ای به رفع ایرادات ESXi و vCenter

عیب‌یابی موفق در VMware بر پایه یک رویکرد لایه‌ای و methodical (روش‌مند) استوار است. قبل از اجرای هر دستوری، باید مشخص کنید که مشکل در کدام لایه از زیرساخت رخ داده است. این رویکرد از اتلاف وقت و ایجاد مشکلات بیشتر جلوگیری می‌کند.

لایه ۱: سخت‌افزار (Physical Hardware). آیا مشکل فیزیکی است؟ این شامل خرابی RAM، مشکلات CPU، کابل‌کشی نادرست یا خرابی کارت شبکه و HBA می‌شود. خطاهای PSOD معمولاً در این لایه رخ می‌دهند.

لایه ۲: مجازی‌سازی کرنل (VMkernel). آیا مشکل در هسته ESXi است؟ این لایه مدیریت منابع، زمان‌بندی (Scheduler) و درایورهای دستگاه را بر عهده دارد. ناسازگاری درایورها یا فریمورها در این لایه مشکل‌ساز می‌شود.

لایه ۳: شبکه (Networking). آیا مشکل ارتباطی است؟ این شامل vSwitchها، Port Groupها، تنظیمات VLAN، فایروال ESXi و ارتباطات فیزیکی سوئیچ‌ها می‌شود. خطای “Host Not Responding” اغلب در این لایه است.

لایه ۴: ذخیره‌سازی (Storage). آیا مشکل در دسترسی به داده است؟ این لایه شامل Datastoreها، پروتکل‌های iSCSI/NFS/FC، تنظیمات Multipathing و خطاهای APD/PDL است.

لایه ۵: مدیریت (vCenter Server). آیا با یک مشکل vcenter مواجه هستید؟ این شامل سرویس‌های VCSA (مانند vpxd)، دیتابیس PostgreSQL، مشکلات SSO و انقضای گواهینامه‌ها می‌شود.

لایه ۶: ماشین مجازی (Virtual Machine). آیا مشکل فقط روی یک VM خاص است؟ این شامل تنظیمات VM، VMware Tools، سیستم‌عامل مهمان و خطاهای Consolidation است.

رویکرد صحیح در رفع ایرادات ESXi و vCenter این است که همیشه عیب‌یابی را از پایین‌ترین لایه محتمل شروع کنید. به عنوان مثال، اگر با یک خطای قطع ارتباط هاست مواجه هستید، قبل از شروع به رفع مشکل vcenter (لایه ۵)، ابتدا لایه ۳ (شبکه مدیریت هاست) را بررسی کنید.

رفع مشکل ESXi: خطاهای پرتکرار + راهکارهای عمیق

۱. هاست قطع شده یا پاسخ نمی‌دهد (Host Disconnected / Not Responding)

این رایج‌ترین خطا در محیط VMware است. به زبان ساده، vCenter (مدیر شما) دیگر نمی‌تواند با هاست ESXi (کارگر شما) صحبت کند. VMها ممکن است همچنان روشن باشند، اما شما دیگر کنترلی روی آن‌ها از طریق vCenter ندارید. این بخش مهمی از رفع ایرادات ESXi و vCenter است.

• VLAN یا MTU اشتباه روی مسیر مدیریت؛ کابل/سوئیچ را بررسی کنید.
• بازنشانی Agentها با احتیاط: /etc/init.d/hostd restart و /etc/init.d/vpxa restart (برای رفع ایرادات ESXi و vCenter در سطح Agent).
• کدهای مفید: esxcli network nic list ، esxcli network ip interface list

توضیح: این رایج‌ترین خطا در رفع ایرادات ESXi و vCenter است. این خطا زمانی رخ می‌دهد که سرویس vpxd در vCenter نمی‌تواند با ایجنت vpxa روی هاست ESXi ارتباط برقرار کند. ایجنت hostd نیز مسئول مدیریت مستقیم هاست (مثل اتصال با Client) است.

قبل از ریستارت کردن این ایجنت‌ها، همیشه ارتباط شبکه مدیریت (Management Network) را با vmkping چک کنید. اگر فقط یک هاست قطع است، مشکل احتمالاً روی همان هاست است. اگر چندین هاست همزمان قطع شده‌اند، مشکل به احتمال زیاد از شبکه، DNS، NTP یا خود vCenter است. ریستارت کردن ایجنت‌ها باید آخرین راه‌حل باشد، زیرا ممکن است باعث قطعی موقت VMها در صورت فعال بودن HA شود.

۲. صفحه بنفش مرگ (PSOD – Purple Screen of Death)

این ترسناک‌ترین خطا است. PSOD معادل «صفحه آبی مرگ» ویندوز برای سرور ESXi شماست. این یعنی کرنل (هسته سیستم‌عامل) با خطایی مواجه شده که قابل مدیریت نیست و کل سرور متوقف شده است. تمام VMهای روی آن هاست بلافاصله خاموش می‌شوند.

• Firmware/Driver ناسازگار یا RAM معیوب.
• راهکار: پایبندی به HCL، هم‌نسخه‌کردن Firmware/Driver و بررسی Dump در /var/core برای رفع ایرادات ESXi و vCenter در لایه سخت‌افزار/کرنل.

توضیح: PSOD نشان‌دهنده یک خطای بحرانی در سطح کرنل (VMkernel) است که سیستم قادر به مدیریت آن نبوده و مجبور به توقف کامل شده است. این خطا معمولاً به دلیل مشکلات سخت‌افزاری (مانند RAM یا CPU معیوب) یا ناسازگاری شدید درایورها (مثلاً درایور HBA یا کارت شبکه) با نسخه ESXi رخ می‌دهد.

اولین قدم پس از ریبوت هاست، بررسی پیام‌های روی صفحه PSOD (اگر عکس گرفته‌اید) یا تحلیل فایل Core Dump است. به دنبال نام ماژول یا درایوری که باعث خطا شده بگردید (مثلاً ‘nmlx’ برای Mellanox یا ‘lpfc’ برای Emulex). راه‌حل قطعی، بررسی دقیق لیست سازگاری سخت‌افزار VMware (HCL) و اطمینان از یکسان بودن نسخه فریمور سخت‌افزار با درایور نصب شده روی ESXi است.

۳. خطاهای ذخیره‌سازی (APD/PDL)

این خطاها زمانی رخ می‌دهند که هاست ESXi دسترسی خود را به حافظه ذخیره‌سازی (Storage یا Datastore) از دست می‌دهد. این وضعیت بسیار بحرانی است زیرا VMها نمی‌توانند اطلاعات خود را بخوانند یا بنویسند و عملاً “یخ می‌زنند”. این مورد یکی از پیچیده‌ترین بخش‌های رفع ایرادات ESXi و vCenter است.

• قطع مسیر یا خطای کنترلر/سوئیچ Storage.
• بررسی مسیرها: esxcli storage core path list و دستگاه‌ها: esxcli storage core device list
• Multipath را روی Round Robin/Fixed تنظیم و Queue Depth را با راهنمای Vendor هماهنگ کنید.

توضیح: درک تفاوت APD و PDL برای رفع ایرادات ESXi و vCenter در لایه استوریج حیاتی است. PDL (Permanent Device Loss) یک وضعیت مشخص است که در آن، کنترلر استوریج به هاست ESXi اطلاع می‌دهد که این LUN (دستگاه) برای همیشه از دست رفته است (مثلاً LUN Masking تغییر کرده).

اما APD (All Paths Down) یک وضعیت نامشخص و خطرناک‌تر است. هاست نمی‌داند LUN برای همیشه رفته یا ارتباط موقتاً قطع شده (مثلاً سوئیچ SAN ریبوت شده). در حالت APD، هاست به تلاش برای دسترسی به LUN ادامه می‌دهد و این می‌تواند باعث قفل شدن ایجنت hostd و قطع شدن هاست از vCenter شود. بررسی لاگ vmkernel برای یافتن این پیام‌ها و سپس بررسی دقیق مسیرهای فیزیکی (کابل‌ها، سوئیچ‌های SAN، تنظیمات Zoning) ضروری است.

۴. نیاز به یکپارچه‌سازی (Consolidation Needed) و اسنپ‌شات‌های انباشته

این خطا یعنی فایل‌های موقتی (Snapshot) که برای بکاپ‌گیری ایجاد شده‌اند، به درستی در دیسک اصلی ادغام نشده‌اند. اگر این وضعیت ادامه یابد، فضای Datastore به سرعت پر می‌شود و عملکرد VM به شدت افت می‌کند.

• باعث کندی شدید و رشد دیسک می‌شوند؛ Consolidate کنید و Policy نگهداری بگذارید تا رفع ایرادات ESXi و vCenter در سطح دیسک انجام شود.

توضیح: اسنپ‌شات‌ها (Snapshots) ذاتاً بد نیستند، اما نباید برای مدت طولانی (بیش از ۷۲ ساعت) باقی بمانند. هر اسنپ‌شات یک فایل دیسک جدید از نوع دلتا (delta.vmdk) ایجاد می‌کند و تمام تغییرات جدید VM روی آن نوشته می‌شود.

با گذشت زمان و ایجاد اسنپ‌شات‌های متعدد، زنجیره این دلتاها طولانی شده و خواندن داده‌ها نیازمند بررسی چندین فایل می‌شود که منجر به کندی شدید (High Latency) در VM می‌گردد. خطای “Consolidation Needed” زمانی رخ می‌دهد که VM در حال اجرا روی یک اسنپ‌شات است اما Snapshot Manager در vCenter آن را نشان نمی‌دهد (معمولاً به دلیل خطای نرم‌افزار بکاپ). فرآیند Consolidation یعنی ادغام این فایل‌های دلتا در دیسک اصلی. این فرآیند می‌تواند زمان‌بر باشد و نیاز به فضای خالی روی Datastore دارد.

۵. خطاهای عملکردی (CPU Ready / Ballooning)

این خطاها نشان‌دهنده کمبود منابع هستند. CPU Ready یعنی VM شما برای پردازش آماده بوده اما CPU فیزیکی در دسترس نبوده است. Ballooning و Swapping یعنی هاست شما به قدری کمبود RAM دارد که مجبور است از حافظه دیسک (که هزاران بار کندتر است) به عنوان حافظه موقت استفاده کند.

• CPU Ready بالا / NUMA mismatch: vCPU بیش از حد، Affinity نامناسب، Overcommit.
• Ballooning/Swapping: کمبود RAM در هاست؛ عملکرد VM افت می‌کند.

توضیح: CPU Ready (%RDY در esxtop) درصدی از زمان است که یک VM آماده اجرا بوده اما نتوانسته به CPU فیزیکی دسترسی پیدا کند، زیرا تمام هسته‌ها توسط VMهای دیگر اشغال بوده‌اند. مقدار بالای ۵٪ نشان‌دهنده کمبود شدید منابع CPU یا تخصیص بیش از حد vCPU به VMها است (Overcommitment). همیشه تعداد vCPU را متناسب با نیاز واقعی VM تنظیم کنید (Right-Sizing).

از طرف دیگر، Ballooning مکانیزمی است که VMkernel برای بازپس‌گیری حافظه از VMها در زمان کمبود RAM هاست استفاده می‌کند. اگر Ballooning به Swapping (انتقال حافظه به دیسک) تبدیل شود، عملکرد VM به شدت افت خواهد کرد. اینها نشانه‌هایی برای افزودن RAM فیزیکی به هاست یا توازن بار توسط DRS هستند.

رفع مشکل vcenter: مشکلات پرتکرار + راهکارهای عمیق

۱. رفع مشکل vcenter که بالا نمی‌آید (سرویس‌ها Down)

این خطا یعنی مرکز مدیریت شما (vCenter) از کار افتاده است. این معمولاً به دلیل پر شدن دیسک‌های خود vCenter یا منقضی شدن گواهینامه‌های امنیتی آن رخ می‌دهد. این بخش مهمی در رفع مشکل vcenter است.

• فضای دیسک پر، DB معلق، گواهی منقضی.
• کدها: df -h ، journalctl -xe ، رابط مدیریتی Appliance روی پورت 5480.
• راهکار: آزادسازی فضا، Repair DB طبق مستند، Replace/Regenerate گواهی‌ها — رویکرد بنیادین برای رفع ایرادات ESXi و vCenter در لایهٔ مدیریت.

توضیح: شایع‌ترین دلیل از کار افتادن vCenter Appliance (VCSA)، پر شدن یکی از پارتیشن‌های لینوکسی آن است. به خصوص پارتیشن /storage/log (به دلیل لاگ‌های زیاد) یا /storage/db (به دلیل رشد دیتابیس PostgreSQL). برای رفع این مشکل، باید از طریق SSH به VCSA متصل شوید و با دستور ‘df -h’ وضعیت را بررسی کنید.

سپس می‌توانید لاگ‌های قدیمی را پاک کنید یا طبق مستندات VMware، فضای دیسک را افزایش دهید. دلیل دوم رایج، انقضای گواهینامه‌ها (Certificates) است که باعث می‌شود سرویس‌ها نتوانند با هم ارتباط امن برقرار کنند. بررسی پورت ۵۴۸۰ (VAMI) وضعیت سلامت سرویس‌ها و گواهینامه‌ها را نشان می‌دهد. سرویس اصلی vpxd (سرویس vCenter) به این موارد به شدت وابسته است.

۲. رفع مشکل vcenter در SSO و احراز هویت

این خطا زمانی رخ می‌دهد که شما نمی‌توانید به vCenter لاگین کنید یا هاست‌ها نمی‌توانند به vCenter متصل شوند، زیرا سیستم نمی‌تواند هویت آن‌ها را تأیید کند. این مشکل تقریباً همیشه به DNS یا ناهماهنگی ساعت مربوط می‌شود.

• عدم تطابق DNS/FQDN یا Cert Chain ناقص.
• راهکار: Identity Sources را بازبینی و Cert Chain کامل اعمال کنید.

توضیح: سرویس Single Sign-On (که اکنون بخشی از vCenter است) به شدت به DNS و NTP وابسته است. اگر هاست ESXi یا کاربری که لاگین می‌کند نتواند نام FQDN مربوط به vCenter را به درستی Resolve کند، یا اگر ساعت vCenter با هاست‌ها و دامین کنترلر ناهماهنگ باشد، فرآیند احراز هویت با شکست مواجه می‌شود. در فرآیند رفع ایرادات ESXi و vCenter، همیشه اطمینان حاصل کنید که رکوردهای A (Forward) و PTR (Reverse) برای تمام اجزای VMware به درستی در DNS سرور ثبت شده باشند.

vMotion، HA و DRS — عیب‌یابی عمیق کلاستر و رفع مشکل vcenter

۱. خطای vMotion (مهاجرت زنده)

vMotion قابلیت جابجایی یک VM روشن از یک هاست به هاست دیگر بدون خاموشی است. شکست این فرآیند معمولاً به دلیل ناهماهنگی تنظیمات شبکه یا CPU بین دو هاست رخ می‌دهد. این فرآیند، هسته اصلی رفع ایرادات ESXi و vCenter در سطح کلاستر است.

• ناسازگاری EVC، MTU ناهماهنگ، مسیر vMotion مشترک با ترافیک شلوغ، دسترسی Storage ناقص.

توضیح: شکست vMotion می‌تواند دلایل متعددی داشته باشد. اولین قدم، بررسی سازگاری CPU بین دو هاست است. قابلیت EVC (Enhanced vMotion Compatibility) این مشکل را با یکسان‌سازی سطح قابلیت‌های CPU در کلاستر حل می‌کند. اگر EVC فعال نیست، VM را نمی‌توان از یک CPU نسل جدید به نسل قدیم منتقل کرد.

دلیل دوم، مشکلات شبکه vMotion است. این شبکه باید یک VMkernel جداگانه داشته باشد و توصیه می‌شود روی VLAN ایزوله باشد. اگر از Jumbo Frames (MTU 9000) برای vMotion استفاده می‌کنید، باید مطمئن شوید که vmk، vSwitch و پورت‌های سوئیچ فیزیکی همگی روی ۹۰۰۰ تنظیم شده‌اند. یک vmkping ساده با سایز بزرگ (دستور چک‌لیست بالا) این مسیر را تست می‌کند.

۲. خطای HA (High Availability)

HA قابلیتی است که در صورت خاموش شدن ناگهانی یک هاست (مثلاً به دلیل PSOD)، VMهای آن را به صورت خودکار روی هاست‌های دیگر روشن می‌کند. خطای HA معمولاً زمانی رخ می‌دهد که هاست‌ها نتوانند با هم ارتباط برقرار کنند (Split-Brain).

• HA Failover ناخواسته / Isolation: قطع شبکه مدیریت یا Split Brain. راهکار: Isolation Response مناسب (Shutdown/Power off/Disabled)، مسیر Mgmt دوم، مانیتورینگ Link-Down.

توضیح: درک معماری HA برای رفع ایرادات ESXi و vCenter ضروری است. HA از ایجنتی به نام FDM (Fault Domain Manager) استفاده می‌کند و یک هاست به عنوان Master و بقیه به عنوان Slave عمل می‌کنند. هاست‌ها از طریق شبکه مدیریت با هم در ارتباط هستند (Heartbeat).

اگر یک هاست نتواند با Master یا با Isolation Address (معمولاً Gateway) ارتباط برقرار کند، خود را “Isolated” (ایزوله) تشخیص می‌دهد و اقدام Isolation Response (مثلاً خاموش کردن VMها) را انجام می‌دهد. مشکل دیگر Split-Brain است که در آن، ارتباط شبکه بین دو گروه از هاست‌ها قطع می‌شود و هر دو گروه فکر می‌کنند Master هستند. استفاده از Datastore Heartbeat به عنوان مکانیزم بررسی ثانویه، می‌تواند از این خطاهای HA جلوگیری کند.

۳. خطای DRS (Distributed Resource Scheduler)

DRS به صورت خودکار VMها را بین هاست‌ها جابجا می‌کند تا بار کاری (CPU و RAM) به صورت مساوی توزیع شود. اگر DRS کار نمی‌کند، معمولاً به دلیل تنظیمات محدودکننده یا عدم کارکرد صحیح vMotion است.

• DRS Imbalance / عدم جابه‌جایی VM: قوانین Affinity/Anti-Affinity سخت‌گیرانه یا محدودیت Resource Pool.

توضیح: اگر DRS به درستی VMها را برای توازن بار (Load Balancing) جابجا نمی‌کند، ابتدا آستانه (Migration Threshold) آن را بررسی کنید. اگر روی سطح ۱ (Conservative) باشد، DRS فقط برای رفع مشکلات اساسی (مثلاً هاستی که ۱۰۰٪ شده) VM را جابجا می‌کند. برای توازن فعال، آن را روی سطح ۳ تنظیم کنید.

دلیل مهم‌تر، وجود قوانین Affinity (باید با هم باشند) یا Anti-Affinity (باید جدا باشند) است. ممکن است شما قانونی تنظیم کرده باشید که دو VM پرمصرف را مجبور می‌کند روی یک هاست بمانند و DRS نتواند آن‌ها را جدا کند. همچنین بررسی کنید که آیا VM به یک دستگاه خاص (مثل CD-ROM فیزیکی) متصل است یا خیر، زیرا این اتصال مانع vMotion و DRS می‌شود.

Storage & Filesystem — خطاهای پنهان

این بخش به مشکلات مربوط به فایل‌های VM (VMDK) و نحوه اتصال هاست‌ها به دیسک‌های مشترک (Datastores) می‌پردازد. این خطاها معمولاً منجر به کندی شدید یا قفل شدن VMها می‌شوند.

• Latency بالا: صف‌های ناکافی، مسیرهای کمی، یا تنظیم Multipath غلط.
• Path Thrashing / ALUA اشتباه: نوسان مسیر به‌دلیل سیاست نادرست Multipath.
• Lock فایل‌های VM: روشن نشدن VM با خطای Lock؛ مالک Lock را شناسایی و آزاد کنید.
• خرابی CBT در Backup: بکاپ Full و Reset CBT برای اصلاح Incremental — یکی از روش‌های کلیدی در رفع ایرادات ESXi و vCenter حین پشتیبان‌گیری.

توضیح: Latency (تأخیر) در استوریج، کندترین بخش زیرساخت مجازی است. در esxtop (با زدن کلید ‘d’)، مقادیر DAVG (تأخیر دستگاه) و KAVG (تأخیر کرنل) را بررسی کنید. مقدار DAVG بالا (بیش از ۱۵-۲۰ میلی‌ثانیه) نشان‌دهنده مشکل در خود استوریج یا سوئیچ SAN است.

یکی از پیچیده‌ترین بخش‌های رفع ایرادات ESXi، مبحث Multipathing (چند مسیری) است. سیاست‌های اصلی شامل MRU (Most Recently Used)، Fixed، و Round Robin (RR) است. برای اکثر SAN Storage های مدرن، استفاده از Round Robin توصیه می‌شود تا بار بین تمام مسیرها توزیع شود. اگر استوریج شما از نوع ALUA (Asymmetric Logical Unit Access) است و سیاست Multipath به درستی تنظیم نشده باشد، ممکن است هاست‌ها سعی کنند از مسیرهای غیراصلی (Non-Optimized) استفاده کنند که منجر به کندی شدید یا Path Thrashing (نوسان مداوم مسیر) می‌شود.

Best Practices برای پیشگیری از تکرار خطا

بهترین راه برای رفع ایرادات ESXi و vCenter، پیشگیری از وقوع آن‌هاست. با رعایت این اصول، پایداری زیرساخت شما تضمین می‌شود.

• استانداردسازی راه‌اندازی: جداسازی ترافیک‌های Management/vMotion/Storage روی VDS و VLAN مجزا.
• HCL و Firmware: فقط Driver/Firmware تأییدشده؛ یک نسخهٔ مرجع (Golden) تعریف کنید.
• پایش معنادار: Alarms برای CPU Ready، Ballooning/Swap، Latency Storage، Packet Loss.
• Patch & Lifecycle: آزمایش در محیط Test، انتشار مرحله‌ای (Canary)، پنجرهٔ نگهداری.
• Backup & DR واقعی: تست دوره‌ای بازیابی vCenter/VMهای حیاتی با RTO/RPO مشخص — ستون چهارم در رفع ایرادات ESXi و vCenter.

پایبندی به این موارد، تفاوت بین یک زیرساخت واکنشی (Reactive) و یک زیرساخت پیشگیرانه (Proactive) را رقم می‌زند. مستندسازی دقیق پیکربندی‌ها، استفاده از Host Profiles برای یکسان‌سازی هاست‌ها، و به‌روزرسانی منظم ابزارهای VMware Tools در داخل VMها، همگی به کاهش چشمگیر خطاها کمک می‌کنند. خدمات پشتیبانی شبکه قوی، نیازمند رعایت همین اصول است.

دستورات و مسیرهای کلیدی

این دستورات پرکاربردترین ابزارها در جعبه‌ابزار هر ادمین VMware برای عیب‌یابی مستقیم از طریق SSH روی هاست ESXi هستند. تسلط بر این دستورات برای رفع مشکل vcenter و esxi ضروری است.

• esxtop — مانیتورینگ زندهٔ CPU/MEM/DISK/NET (c/m/d/n برای تب‌ها).
• vmkping <IP> -d -s 8972 — تست Jumbo برای vMotion/Storage.
• esxcli network nic list ، esxcli network ip interface list — وضعیت NIC و vmk.
• esxcli storage core device list ، esxcli storage core path list — دیسک‌ها و مسیرها.
• لاگ‌های ESXi: /var/log/vmkernel.log (مهم‌ترین لاگ)، /var/log/vobd.log (خطاهای دیداری)، /var/log/hostd.log (لاگ ایجنت مدیریت هاست).
• vCenter (VCSA): https://<vcsa>:5480 برای مدیریت Appliance و سرویس‌ها. برای مرجع خارجی، به پایگاه دانش رسمی VMware مراجعه کنید.

جمع‌بندی و گام بعدی

برای رفع ایرادات ESXi و vCenter در محیط‌های تولید، اجرای همین چک‌لیست‌ها و درک عمیق از لایه‌های زیرساخت، اغلب مشکل را در ساعات اول حل می‌کند. پایداری یک محیط مجازی VMware به هماهنگی کامل بین سخت‌افزار، شبکه، استوریج و نرم‌افزار بستگی دارد.

اگر با خطاهای پیچیده‌ای مانند PSODهای مکرر، مشکلات عملکردی DRS یا قطعی‌های مداوم APD مواجه هستید، ممکن است نیاز به تحلیل عمیق‌تر لاگ‌ها و بازبینی کامل معماری زیرساخت خود داشته باشید. تیم ما به عنوان متخصص پشتیبانی شبکه و سرور، آماده ارائه خدمات مشاوره و اجرای عملیات رفع ایراد در پیچیده‌ترین محیط‌های VMware است.

اگر به نقشهٔ راه اختصاصی یا تیم اجرایی نیاز دارید، با ما در تماس با ما هماهنگ کنید.
مشاوره و اجرای رفع مشکل vcenter به‌صورت پروژه‌ای انجام می‌شود.