عیبیابی پیشرفته خطای Server Not Found در اکتوسر HPE و محیط‌های مجازی‌سازی: از لایه iLO تا vSwitch
عیبیابی خطای server not found در سرورهای hpe و زیرساخت مجازی‌سازی، فرآیندی دقیق و چندلایه است که نیازمند بررسی از لایه فیزیکی تا مدیریت است. خطای Server Not Found در سرورهای HPE و اکتوسر معمولاً به دلیل قطعی لینک فیزیکی، از کار افتادن سرویس iLO، تداخل VLAN در vSwitch یا اختلال در آرایه‌های SAN/NAS رخ می‌دهد. این خطا تنها یک هشدار سطح بالا نیست، بلکه نشان‌دهنده شکست در لایه‌های پایین شبکه (L2/L3) یا ناهماهنگی در پروتکل‌های مدیریت است. در سناریوهای واقعی دیتاسنتر، زمانی که تیم‌های عملیاتی پس از یک مهاجرت شبکه یا به‌روزرسانی فیرمور سوییچ متوجه می‌شوند که هاست‌های مجازی‌سازی شده ناگهان از پنل OneView یا vCenter گم شده‌اند، ریشه مشکل اغلب در ناهماهنگی ترونک‌های فیزیکی، عدم تطابق Port Fast، یا از کار افتادن سرویس BMC است. برای رفع آن ابتدا لینک فیزیکی و پورت Switch را با معیارهای دیاگنوستیک پیشرفته بررسی کنید، سپس تنظیمات DHCP، رکوردهای DNS و گواهی‌های SSL/iLO را اعتبارسنجی نمایید، و در نهایت vSwitch، VMkernel و پورت‌های استوریج را ری‌کامپایل و مسیرهای Multipathing را بازبینی کنید. این فرآیند نیازمند درک عمیق از سینماتیک ترافیک در محیط‌های Hyperconverged و زیرساخت‌های مجازی‌سازی مقیاس‌پذیر است.
فهرست مطالب
- خطای Server Not Found چیست و چه زمانی رخ می‌دهد؟
- ناهماهنگی vSwitch در VMware و ایجاد خطا
- خرابی پورت Switch یا فیبر مسئول قطع اتصال است؟
- تأثیر تنظیمات DHCP و iLO بر گم‌شدن هاست
- نقش تأخیرهای I/O و قطعی SAN/NAS در خطا
- مقایسه علت‌های نرم‌افزاری و سختافزاری
- مراحل عملی عیبیابی خطای server not found در سرورهای hpe و زیرساخت مجازی‌سازی
- سوالات متداول متخصصان
خطای Server Not Found چیست و چه زمانی رخ می‌دهد؟
خطای Server Not Found یک خطای سطح لایه ۴ و ۵ شبکه است که زمانی تولید می‌شود که کلاینت یا سیستم مدیریت نتواند اتصال TCP/UDP لازم برای برقراری ارتباط با آدرس IP یا نام هاست سرور HPE را برقرار کند. این خطا در سطح پروتکل‌های مدیریت مانند SSH (پورت ۲۲)، HTTPS مدیریت iLO (پورت ۴۴۳) و ریموت دسکتاپ (پورت ۳۳۸۹) ظاهر می‌شود. به‌طور فنی، این خطا معمولاً به معنای عدم موفقیت در Three-Way TCP Handshake یا عدم پاسخ به پکت‌های UDP Broadcast است. در سناریوی عملی، وقتی ادمین شبکه از یک استیشن مدیریت سعی می‌کند با `curl -v https://ECONNREFUSED یا ENOTFOUND گزارش می‌دهد که دقیقاً معادل همان خطای Server Not Found است. این وضعیت می‌تواند ناشی از قطعی لایه فیزیکی، ریجکت در سطح فایروال، یا از کار افتادن کامل Stack مدیریت (BMC/iLO) باشد.
تفاوت تکنیکال این خطا با Timeout یا خطای ۴۰۴ در پروتکل‌های لایه ۷
درک تفاوت‌های سطحی این خطاها برای عیبیابی دقیق ضروری است. تصور کنید می‌خواهید با یک سرور تماس بگیرید: خطای Server Not Found مانند شنیدن صدای “شماره مورد نظر وجود ندارد” است (عدم وجود مسیریابی یا حل نام). خطای Timeout مانند تماسی است که زنگ می‌خورد اما هیچ‌کس جواب نمی‌دهد (ترافیک می‌رسد اما پاسخ نمی‌آید). خطای 404 مانند مراجعه به اتاقی است که فرد آنجا است، اما فایل مورد نظر شما در قفسه نیست. این تمایز، جهت‌دهی به ابزارهای عیبیابی را تعیین می‌کند:
| ویژگی | Server Not Found | Connection Timeout | HTTP 404 Not Found |
|---|---|---|---|
| لایه OSI | لایه ۳ و ۴ (Network/Transport) | لایه ۴ و ۵ (Transport/Session) | لایه ۷ (Application) |
| علت اصلی | عدم امکان resolve نام یا بسته بودن پورت، قطعی لینک یا ریجکت در ARP | فریم‌ها به مقصد نمی‌رسند یا پاسخ زمان‌بندی نشده (Loss率 بالا یا مسیریابی معکوس نامناسب) | سرور آنلاین است اما resource درخواستی وجود ندارد (Path exists, Object missing) |
| ابزار عیبیابی | nslookup, ping, traceroute, telnet port, arp -a | tcpdump, Wireshark, netstat -an, mtr | Browser console, Apache/Nginx/Redis logs, curl -I |
| اثر در کلستر HPE | قطعی کامل مدیریت و امکان ری‌استارت از راه دور، Break in HA fencing | تاخیر در heartbeat و احتمال failover غیرقابل کنترل، QoS degradation | تأثیر مستقیم بر وب‌اپلیکیشن‌های داخلی، عدم تاثیر بر زیرساخت مجازی‌سازی |
| دوره زمانی تشخیص | فوری (Instant) | متغیر (معمولاً ۵ تا ۳۰ ثانیه بسته به TCP Retransmission) | فوری (پس از تکمیل handshake و ارسال HTTP Request) |
دامنه اثر خطا در کلسترهای Hyperconverged
در محیط‌های Hyperconverged مانند vSAN یا Ceph، خطای Server Not Found می‌تواند منجر به split-brain یا از دست رفتن همگام‌سازی داده‌ها شود. وقتی یک نود از کلستر از دسترس خارج شود، پروتکل‌های consensus مانند Raft یا Paxos ممکن است دچار مشکل شده و کل ترافیک استوریج متوقف شود. در vSAN، مکانیزم vSAN Watchdog و Fencing بر اساس Timeout عمل می‌کنند، اما اگر خطای Not Found در لایه مدیریت رخ دهد، پلاگین‌های vSphere HA ممکن است نتوانند نود را Aborted اعلام کنند. این وضعیت منجر به Data Inconsistency می‌شود. برای مثال، در دیتاسنتری که از vSAN ۷ استفاده می‌کند، از دسترس خارج شدن ناگهانی نود سوم به دلیل پیکربندی اشتباه Port Group، باعث شد پارتیشن‌های datastore نیمه‌کاره بمانند و فرآیند Resyncing با خطای Claiming conflict متوقف شود. راهکار، استفاده از vSAN Network Teaming با Path Selection مناسب و پایش مداوم vSAN Storage Policy است.
ناهماهنگی vSwitch در VMware چگونه خطای Not Found را ایجاد می‌کند؟
شناسایی تداخل‌های Port Group و VLAN Tagging در vSphere
وقتی یک ناهماهنگی vSwitch در VMware ناشی از پیکربندی نادرست VLAN ID یا عدم Tagging مناسب رخ دهد، ترافیک VMkernel و ترافیک مدیریت از مسیر صحیح عبور نمی‌کند. این مسئله باعث می‌شود حتی اگر لینک فیزیکی فعال باشد، بسته‌های ICMP و TCP به مقصد نرسند. در vSphere، سه حالت وجود دارد: Untagged (VLAN 0)، Tagged (VLAN ID مشخص)، و Transparent/No Access. اگر سوییچ فیزیکی پورت را روی حالت trunk با VLAN مجاز تنظیم کرده باشد، اما Port Group روی VLAN اشتباه باشد، سوییچ پکت‌ها را ریجکت می‌کند. همچنین، در محیط‌های چندتenant، تداخل VLAN IDs می‌تواند باعث VLAN Hopping یا نشت ترافیک شود که خطای Not Found را به صورت intermittent ایجاد می‌کند.
| پارامتر | وضعیت صحیح | وضعیت نادرست (موجب خطا) |
|---|---|---|
| VLAN ID Port Group | مطابق با VLAN تعریف‌شده در Switch فیزیکی (Trunk Allowed) | Tagging ناهماهنگ، VLAN خالی یا تداخل با VLAN Management دیگر |
| Teaming & Failover | Active/Active یا Active/Standby صحیح بر اساس Link Speed و Latency | همه پورت‌ها در حالت Standby، Failover Order اشتباه، No Active Uplink |
| Load Balancing | Route Based on IP Hash یا Port ID (مناسب برای LACP) | Route Based on Originating Virtual Port (نادرست برای LACP و سبب Out-of-order Frames) |
| FEC/Forward Error Correction | فعال روی لینک‌های 25G/40G با نویز محیطی | غیرفعال، منجر به افزایش BER و ریست‌های مکرر لینک |
بررسی وضعیت VMkernel Adapter و مسیریابی معکوس (RPF Check)
مسیریابی معکوس یا Reverse Path Forwarding (RPF) یک مکانیزم امنیتی و پایداری است که بررسی می‌کند آیا بسته‌های ورودی از مسیری دریافت می‌شوند که در جدول مسیریابی وجود دارد. اگر RPF Check روی Switch فیزیکی (در پلتفرم‌های Juniper/Cisco) یا Kernel Linux/ESXi فعال باشد و مسیر بازگشتی از vSwitch نادرست باشد، بسته‌ها ریجکت می‌شوند و خطای Server Not Found ظاهر می‌گردد. این پدیده معمولاً در سناریوهای Asymmetric Routing رخ می‌دهد؛ جایی که ترافیک خروجی از NIC1 و پاسخ ورودی از NIC2 دریافت می‌شود.
برای رفع این مشکل:
- جدول مسیریابی هاست را با دستور
esxcli network ip route listبررسی کنید و مسیرهای Default و Static را تطبیق دهید - اطمینان حاصل کنید که default gateway برای VMkernel صحیح تنظیم شده و
Primary Gatewayدر Teaming Policy مشخص است - در صورت نیاز، Route Static برای subnetworkهای مدیریت اضافه کنید و از
esxcli network ip route addبا اولویت مناسب استفاده نمایید - بررسی کنید که
sysctlمعادل مسیریابی معکوس در ESXi به‌درستی پیکربندی شده باشد (در ESXi معمولاً به‌صورت خودکار بر اساس مسیریابی پویا اعمال می‌شود)
تست پکت‌سنتتتیک در مجاری اگزیت vSwitch و پورت‌های فیزیکی
استفاده از تحلیل پیشرفته ارتباط سرور یا ابزارهای مشابه برای ارسال پکت‌های TCP SYN به پورت‌های ۲۲ و ۴۴۳ هاست اکتوسر، سرعت عیبیابی را چندین برابر می‌کند. اگر پاسخ SYN-ACK دریافت نشود، مشکل در لایه ۲ یا ۳ است؛ اگر پاسخ Timeout شود، مشکل در فایروال یا مسیریابی است؛ و اگر RST ارسال شود، پورت بسته یا سرویس غیرفعال است. برای تحلیل عمیق‌تر، از tcpdump -i vmk0 host در ESXi استفاده کنید. فیلترهای Wireshark مانند tcp.flags.syn == 1 and tcp.flags.ack == 0 به شما کمک می‌کنند تا دقیقاً لحظه‌ای که بسته ریجکت می‌شود را شناسایی کنید. در محیط‌های پرترافیک، فعالسازی SPAN/Mirror Port روی سوییچ و رهگیری ترافیک با ابزارهایی مانند Wireshark یا Zeek، تصویر کاملی از سینماتیک اتصال ارائه می‌دهد.
آیا خرابی پورت‌های Switch یا Loopback فیبر مسئول قطع اتصال اکتوسر است؟
آنالیز خطاهای CRC و Late Collision در پورت‌های ۱۰/۲۵ گیگابیت
خطاهای CRC (Cyclic Redundancy Check) و Late Collisions نشان‌دهنده مشکلات لایه فیزیکی هستند. وقتی فیبر نوری آسیب‌دیده باشد، کانکتور SFP کثیف باشد یا کابل Cat6a بیش از حد طول کشیده باشد، این خطاها افزایش می‌یابند و در نهایت منجر به drop کامل لینک می‌شوند. در پورت‌های ۱۰ و ۲۵ گیگابیت، خطاهای CRC حتی در حد چند بسته در ساعت هم می‌توانند نشان‌دهنده فرسودگی ماژول SFP، انحنای بیش از حد Bend Radius، یا نویز الکترومغناطیسی (EMI) در کانال کابل‌کشی باشند. دستور show interfaces counters errors در Cisco و show port status در Juniper، نرخ CRC، Giants و Runts را گزارش می‌کنند. اگر نرخ CRC بالای 0.01% ترافیک باشد، باید فیبر و SFP تعویض شوند. همچنین، عدم تطابق Full/Half Duplex می‌تواند سبب Late Collision شود که در لینک‌های مدرن Gigabit/Ethernet غیرقابل قبول است.
بررسی پروتکل‌های STP/LACP و بلوکینگ پورت‌های اکتوسر
پروتکل STP (Spanning Tree Protocol) در صورت عدم پیکربندی صحیح، پورت‌های متصل به سرور اکتوسر را در حالت Blocking قرار می‌دهد. این اتفاق زمانی می‌افتد که:
- BPDU Guard فعال نباشد و پورت به‌عنوان Edge Port شناخته نشود
- PortFast روی پورت‌های متصل به سرور تنظیم نشده باشد (در Cisco) یا
edge-portدر سایر سازنده‌ها فعال نباشد - LACP با پورت‌های مختلف همگام‌سازی نشود و Hash Algorithm بین Source/Destination IP و Port ID ناهماهنگ باشد
برای جلوگیری از این مشکل، PortFast یا Edge Port را روی پورت‌های متصل به هاست‌های اکتوسر فعال کنید. همچنین، در محیط‌های HA، از BPDU Filter با احتیاط استفاده کنید زیرا ممکن است حلقه‌های پنهان را پنهان کند. برای LACP، مطمئن شوید که Channel Group روی سوییچ و vSwitch در VMware با Load Balancing: Route Based on IP Hash هماهنگ باشد.
تست فریم‌های Jumbo و تأثیر MTU بر عیبیابی iLO
تفاوت در تنظیمات MTU بین vSwitch و Switch فیزیکی یکی از دلایل پنهان خطای Server Not Found است. اگر vSwitch روی MTU 9000 (Jumbo Frame) پیکربندی شده باشد اما Switch فیزیکی روی 1500 باشد، بسته‌های بزرگ‌تر از 1500 بایت تکه‌تکه (Fragment) شده یا ریجکت می‌شوند. این پدیده به‌ویژه در ترافیک iSCSI، NFS یا vSAN مشکل‌ساز است. همچنین، پروتکل PMTUD (Path MTU Discovery) ممکن است بسته‌های ICMP Fragmentation Needed را ریجکت کند و ارتباط TCP به‌طور خاموش قطع شود.
برای iLO توصیه می‌شود MTU روی 1500 تنظیم شود. برای ترافیک vSAN یا iSCSI می‌توان از Jumbo Frame استفاده کرد، اما اطمینان حاصل کنید که تمام مسیر از هاست تا Switch و آرایه استوریج از MTU 9000 پشتیبانی می‌کند. برای تست، از ping -s 8972 -M do در لینوکس یا Test-NetConnection با پکت‌های بزرگ در PowerShell استفاده کنید. اگر پاسخ Fragmentation needed دریافت شد، MTU را کاهش دهید.
تنظیمات DHCP و سرویس iLO چگونه گم‌شدن هاست اکتوسر را شبیه‌سازی می‌کنند؟
عیبیابی تداخل‌های DHCP Scope و Reserve IP در پنل iLO
وقتی آدرس IP سرور اکتوسر از طریق DHCP اختصاص داده شود و سپس Scope تغییر کند یا Reservation از بین برود، سرور IP جدیدی دریافت می‌کند و آدرس قبلاً «Not Found» می‌شود. این پدیده در محیط‌های پویا که آدرس‌دهی متمرکز است، شایع است. چرخه DHCP شامل DORA (Discover, Offer, Request, Acknowledge) است. اگر Lease Time کوتاه باشد و سرویس DHCP دسترس‌ناپذیر شود، سرور IP قبلی را حفظ می‌کند اما سوییچ و DNS آن را نمی‌شناسند.
برای رفع این مشکل:
- یک Static Reservation در سرویس DHCP برای MAC Address NIC اکتوسر ایجاد کنید تا IP ثابت باقی بماند
- در پنل iLO، از حالت DHCP به Static IP تغییر دهید و Gateway/DNS را دستی وارد نمایید
- آدرس IP اختصاص‌یافته را در DNS به‌روز کنید (A Record و PTR Record) و از
nslookupبرای تایید Forward/Reverse lookup استفاده کنید - در محیط‌های بزرگ، از
DHCP SnoopingوIP Source Guardبرای جلوگیری از IP Spoofing استفاده کنید
ریست پارامترهای Redfish و بررسی لاگ‌های BMC
سرویس Redfish که رابط مدیریت مدرن HPE است، در صورت از کار افتادن یا ناهماهنگی، ارتباط با کنسول iLO را قطع می‌کند. لاگ‌های BMC را از طریق SSH با دستور imstrace یا از طریق کنسول Web iLO بررسی کنید. پارامترهای Redfish در فایل‌های /var/log/ilo/ ذخیره می‌شوند. خطاهایی مانند Internal Service Error یا Certificate Chain Invalid می‌توانند باعث قطع دسترسی REST API شوند.
اگر سرویس iLO از کار افتاده باشد، می‌توانید آن را از طریق iLO Reset یا دستور ipmitool mc reset cold ریست کنید. توجه داشته باشید که این عمل ترافیک استوریج و VM را تحت تاثیر قرار نمی‌دهد، زیرا BMC روی بوس مستقل (SMBus) کار می‌کند. پس از ریست، از ipmitool mc info برای بررسی سلامت ماژول و ipmitool sel list برای خواندن System Event Log استفاده کنید.
اعتبارسنجینگ گواهی‌های SSL/TLS برای ارتباط امن با کنسول مدیریت
اگر گواهی SSL/iLO منقضی شده باشد یا با نام دامنه همخوانی نداشته باشد، مرورگرها و ابزارهای مدیریت ارتباط را قطع می‌کنند و خطای Server Not Found شبیه‌سازی می‌شود. این پدیده به‌ویژه در محیط‌های Enterprise که گواهی‌ها به‌طور دوره‌ای Rotate می‌شوند، رایج است. مرورگرهای مدرن مانند Chrome و Firefox از Strict Certificate Validation و HSTS استفاده می‌کنند و در صورت عدم تطابق CN/SAN یا Trust Chain، ارتباط را مسدود می‌کنند.
- گواهی‌های SSL را در پنل iLO (Administration -> Security -> Certificates) بررسی کنید و تاریخ انقضا (Not After) را چک کنید
- از Let’s Encrypt یا CA داخلی برای صدور گواهی معتبر استفاده کنید و Subject Alternative Name (SAN) را برای آدرس‌های IPv4/IPv6 و Hostname تنظیم نمایید
- اگر از HTTP استفاده می‌کنید، حتماً به HTTPS مهاجرت نمایید و
TLS 1.2/1.3را به‌عنوان Minimum Version فعال کنید - برای خودکارسازی، از
curl -v https://برای پایش خودکار وضعیت گواهی استفاده کنید2>&1 | grep -i "SSL"
تأخیرهای I/O و قطعی SAN/NAS چه نقشی در گزارش خطای Not Found دارند؟
تحلیل تأخیرهای IOPS و قطعی‌های کوتاه‌مدت در آرایه‌های SAN
وقتی آرایه SAN دچار latency spike یا قطعی کوتاه‌مدت شود، هاست اکتوسر ممکن است در حالت Unresponsive قرار گیرد. در این حالت، حتی اگر شبکه مدیریت فعال باشد، سیستم‌عامل پاسخ نمی‌دهد و از دید مدیریت کلستر، سرور «پیدا نمی‌شود». این پدیده معمولاً ناشی از Storage Array Cache Miss، LUN Zoning Mismatch، یا Multipathing Failover Delay است. در ESXi، NMP (Native Multipathing Plugin) و PSPOD مسئول مدیریت مسیرها هستند. اگر یکی از مسیرها با تأخیر بالای 30 ثانیه پاسخ دهد، ESXi آن را به‌عنوان Failed علامت می‌زند و اگر مسیر دوم هم دیر پاسخ دهد، Host Timeout رخ می‌دهد.
بررسی پورت‌های FC و تنظیمات NPIV برای مجازی‌سازی
پروتکل NPIV (N-Port ID Virtualization) به VMها اجازه می‌دهد هر کدام پورت FC مستقل داشته باشند. اگر NPIV به درستی پیکربندی نشده باشد، ترافیک استوریج VMها مختل شده و هاست ممکن است به دلیل مشکل در مسیریابی، از دسترس خارج شود. برای فعالسازی NPIV، باید FC Host Bus Adapter روی حالت Enabled باشد، WWPN های VMها در سوییچ Fibre Channel Zoning شده باشند، و NPIV Capability در ESXi Network Stack فعال باشد. عدم تطابق Zone ID یا Soft Permanent Alias (SPA) می‌تواند باعث Loss of Path شود.
تست لینک‌های iSCSI و فعالسازی CHAP برای احراز هویت امن
در محیط‌های iSCSI، عدم تنظیم صحیح CHAP (Challenge Handshake Authentication Protocol) می‌تواند منجر به قطع ارتباط با Target استوریج شود. همیشه از CHAP دوطرفه (Mutual CHAP) برای امنیت بیشتر استفاده کنید و اطمینان حاصل کنید که Initiator و Target credentials یکسان باشند. همچنین، iSCSI Software Stack در ESXi باید با Multiple Queues پیکربندی شود تا از گلوگاه CPU جلوگیری شود. برای عیبیابی، از esxcli iscsi networkportal list و esxcli storage iscsi session list استفاده کنید و وضعیت Session State را بررسی نمایید.
مقایسه علت‌های نرم‌افزاری و سختافزاری در خطای Server Not Found اکتوسر HPE
درک تفاوت بین علل نرم‌افزاری و سختافزاری برای عیبیابی سریع ضروری است. بسیاری از ادمین‌ها بدون بررسی دقیق لایه فیزیکی، مستقیماً به سمت ریست سرویس‌ها یا تغییر پیکربندی مجازی می‌روند که منجر به Blind Changes و ایجاد خطاهای جدید می‌شود. جدول زیر الگوی تشخیصی دقیق را ارائه می‌دهد:
| دسته‌بندی | علت نرم‌افزاری | علت سختافزاری |
|---|---|---|
| شبکه | پیکربندی نادرست vSwitch، VLAN Tagging اشتباه، Rule فایروال، NAPT Conflict | خرابی ماژول SFP، کابل فیبر آسیب‌دیده، خرابی پورت NIC، Overheating ماادربرد |
| مدیریت | از کار افتادن سرویس iLO، گواهی SSL منقضی، تداخل DHCP، DNS Timeout | خرابی ماژول iLO (BMC Chip)، مشکل در ماادربرد، باتری CMOS/BMC ضعیف، Firmware Bug |
| پردازش | بار CPU بیش از ۹۵٪، Memory Leak در سرویس‌ها، Swap Overload، Zombie Processes | خطای ECC RAM، CPU Throttling به دلیل نقص حرارتی، خرابی منبع تغذیه (PSU)، نوسان ولتاژ |
| ذخیره‌سازی | پیکربندی RAID نادرست، Mount Point اشتباه، iSCSI Session Drop، Multipathing Misconfig | دیسک خراب (Predictive Failure)، خطای HBA Controller، قطعی لینک FC/iSCSI، کابل SFP-DAC کثیف |
| امنیت | بستن پورت‌های ۲۲/۴۴۳/۸۰، Rule iptables/Windows Firewall، ACL اشتباه، Brute Force Lockout | خرابی ماژول TPM، مشکل در Secure Boot، فایروال سختافزاری سوییچ ریجکت‌کننده MAC |
مراحل عملی عیبیابی خطای server not found در سرورهای hpe و زیرساخت مجازی‌سازی
برای عیبیابی سیستماتیک خطای Server Not Found، مراحل زیر را به ترتیب انجام دهید تا از تغییرات تصادفی جلوگیری شود:
- چارچوب عملیاتی عیبیابی سرور HPE ProLiant: ابتدا چراغ‌های LED پورت NIC و Switch را بررسی کنید (Active/Green برای لینک سالم). یک تست Loopback با ابزارهایی مانند
ethtool -S eth0یاipmitool sel listانجام دهید تا از سلامت فیزیکی لینک اطمینان حاصل کنید. همچنین سرعت و دو طرفه (Full/Half Duplex) را باethtool eth0بررسی نمایید. اگرduplex mismatchمشاهده شد، آن را روی Auto-Negotiation تنظیم کنید. - بررسی لاگ‌های Syslog iLO و شناسایی کدهای خطای BMC: لاگ‌های iLO را از طریق
curl -k https://ilo-ip/redfish/v1/Systems/1/LogServices/Sel/Entriesاستخراج کنید. کدهای خطای BMC مانند0x0000(هیچ خطا) یا0x0003(خطای شبکه) را بررسی و بر اساس مستندات HPE تحلیل کنید. همچنین/var/log/syslogو/var/log/dmesgرا برای خطاهای NIC Driver بررسی کنید. - پیکربندی مجدد vSwitch و تأیید مسیریابی VMkernel: از طریق
esxcli network vswitch standard listوesxcli network ip route listپیکربندی vSwitch و جدول مسیریابی را بررسی کنید. در صورت نیاز، VMkernel Adapter را باesxcli network ip interface addمجدداً ایجاد و مسیریابی را تأیید کنید.Teaming Policyرا رویRoute Based on IP Hashقرار دهید وFailover Orderرا به‌روز کنید. - تست نهایی استوریج SAN/NAS و ریستارت سرویس‌های مجازی: با
esxcli storage core adapter listوضعیت هادرهای FC و iSCSI را بررسی کنید. اگر استوریج متصل است، سرویس‌های مجازی را باservice-control --stop --allوservice-control --start --allریستارت نمایید و پایداری را تحت بار تست کنید. ازesxtopبرای پایش IOPS و Latency در حین تست استفاده کنید.
سوالات متداول متخصصان
بازبینی‌شده توسط تیم فنی HPE24 / Falnic
این مقاله در لابراتوار فنی تخصصی بررسی و با آخرین مستندات مرجع مطابقت داده شده است. برای تضمین پایداری و صحت داده‌ها، کلیه کدهای ساختاری و متدهای اجرایی این محتوا تحت نظارت مهندسین ارشد شبکه و زیرساخت ما ارزیابی شده‌اند.
