مقایسه vSphere Standard Switch و Distributed Switch؛ قابلیت‌ها و معیار انتخاب

مقدمه

هر دو Switch، VM و VMkernel را به شبکه متصل می‌کنند؛ تفاوت اصلی در محل مدیریت Configuration و قابلیت‌های شبکه است. در Cluster، یکسان نبودن VLAN یا Policy بین Hostها هنگام جابه‌جایی VM مشکل ایجاد می‌کند. این مقاله ابتدا vSS و vDS را مقایسه می‌کند و سپس روش انتخاب، بررسی Configuration و ملاحظات مهاجرت را توضیح می‌دهد.

vSS و vDS چگونه کار می‌کنند؟

vSS روی هر ESXi Host Configuration مستقل دارد. Port Group، VLAN و Policy باید روی Hostهای مقصد یکسان تعریف شوند؛ یکسان بودن نام Port Group به‌تنهایی یکسان بودن تنظیمات را ثابت نمی‌کند.

vDS در vCenter مدیریت می‌شود و Hostهای عضو، بخش اجرایی شبکه را نگه می‌دارند. Distributed Port Group سیاست مشترک پورت‌ها را تعریف می‌کند. قطع vCenter معمولاً Forwarding موجود را متوقف نمی‌کند، اما تغییر Configuration و بعضی عملیات بازیابی را محدود می‌کند.

جدول مقایسه vSS و vDS

این جدول قابلیت فنی را مقایسه می‌کند؛ دسترسی به Featureها، نسخه vDS و Entitlement باید برای Build و قرارداد واقعی بررسی شود. وجود NIC Teaming به معنی پشتیبانی LACP در هر دو Switch نیست؛ طراحی LACP باید جداگانه بررسی شود.

Port Group، Uplink و VMkernel

Port Group سیاست اتصال VMها یا VMkernel را مشخص می‌کند؛ Uplink اتصال Switch مجازی به NIC فیزیکی است. vmnic نام NIC فیزیکی و vmk نام VMkernel Adapter است. نام vmk0 به‌تنهایی نوع سرویس را تعیین نمی‌کند؛ برچسب Management، vMotion یا Storage را در Configuration همان Host بررسی کنید.

چه زمانی vSS یا vDS انتخاب کنیم؟

vSS برای Host مستقل، محیط کوچک با Policy ساده یا طراحی بدون vCenter مناسب است؛ مشروط به اینکه تیم بتواند Consistency را کنترل کند. vDS زمانی ارزش دارد که مدیریت متمرکز، Policy مشترک یا قابلیت‌هایی مانند LLDP، Private VLAN و Shaping ورودی نیاز واقعی باشند. پیچیدگی عملیات، Entitlement و مسیر Recovery نیز بخشی از تصمیم‌اند.

اگر نتیجه مقایسه به نفع vDS بود، مراحل Configuration و مهاجرت پایین را روی Host آزمایشی اجرا کنید. مهاجرت، پیامد انتخاب معماری است؛ شرط لازم برای استفاده از VLAN یا vMotion نیست.

مثال عملی

در یک محیط نمونه با شش ESXi Host، VLAN برنامه‌ها مشترک است اما Policy بعضی Port Groupها بین Hostها تفاوت دارد. برای این Cluster مدیریت متمرکز vDS بررسی می‌شود. در مقابل، یک ESXi مستقل برای سایت کوچک با VLAN و NIC Teaming معمولی می‌تواند روی vSS بماند؛ تعداد Host به‌تنهایی دلیل مهاجرت نیست.

پیش‌نیازها

vSphere/ESXi 8.x؛ build سازگار vCenter و entitlement لازم برای vDS/featureها پیش از طراحی تأیید شود.

سخت‌افزار و ظرفیت: دو uplink مستقل برای نمونه migration؛ switch فیزیکی trunk و MTU یکسان. یک uplink مدیریت تا validation روی vSS باقی بماند.

نرم‌افزار و دسترسی: مجوز Network configuration در vCenter و OOB console هر host. LACP فقط با support و طراحی switch فیزیکی و vDS مناسب.

Architecture / Design

vSS: config محلی هر host؛ vDS: control plane مدیریت‌شده در vCenter و dataplane روی host. نبود vCenter لزوماً forwarding موجود را قطع نمی‌کند، اما تغییر و recovery محدود می‌شود.

Installation / Configuration

۱. vSS، port group، VLAN، MTU، vmk و uplink هر host را inventory کنید. در ESXi Shell read-only:

esxcli network vswitch standard list
esxcli network vswitch standard portgroup list
esxcli network ip interface list
esxcli network nic list

۲. در vCenter، vDS با نسخه سازگار کمترین host بسازید. distributed port groupهای مدیریت، VM و vMotion با VLAN/MTU دقیق ایجاد شوند؛ security policy و teaming با baseline تطبیق داده شوند.

۳. فقط uplink دوم host canary را به vDS وصل کنید؛ یک VM test روی port group مقصد قرار دهید. VLAN، DNS و دسترسی برنامه را بررسی کنید.

۴. با OOB آماده، vmk مدیریت را از wizard Add and Manage Hosts انتقال دهید؛ uplink vSS اولیه را تا تأیید management نگه دارید. gateway با vmk واقعی آزموده شود.

vmkping -I vmk0 -c 3 10.20.30.1

vmk0 و gateway placeholder طراحی هستند. MTU بزرگ فقط وقتی end-to-end تعریف شده با probe مناسب و DF آزمایش شود. پس از پایداری host و دسترسی vCenter، uplink باقی‌مانده را منتقل کنید. میزبان دوم قبل پذیرش canary تغییر نکند.

Security Hardening

Promiscuous mode، MAC changes و forged transmits بدون نیاز workload فعال نشوند. نقش شبکه از Administrator عمومی تفکیک شود؛ backup vDS و credential console امن نگهداری شوند.

Monitoring

vCenter برای host disconnect، uplink down، VLAN/MTU drift و packet drop alarm داشته باشد. LACP state و خطای switch فیزیکی از تیم شبکه جمع‌آوری شود؛ LLDP/CDP به policy اطلاعات توپولوژی وابسته است.

Troubleshooting

VM disconnected ولی vmk سالم: VLAN، dvPort و policy VM. host disconnect: mapping uplink و management VLAN از OOB. فقط یک host مشکل دارد: physical trunk و drift baseline. MTU mismatch می‌تواند packet کوچک را عبور دهد و storage/vMotion را خراب کند.

Backup / Recovery

پیش از migration، export vDS و config host و نسخه vCenter backup شوند. اگر management قطع شد، از DCUI/OOB مطابق KB سازنده recovery networking انجام و vmk به vSS/port group شناخته‌شده برگردانده شود. نام uplink و VLAN قبلی برای operator محلی در runbook موجود باشد؛ vCenter تنها مسیر recovery نباشد.

Best Practices

یک host و یک uplink در هر مرحله؛ rollback پیش از حذف آخرین uplink vSS اثبات شود. LACP به‌تنهایی redundancy application را تضمین نمی‌کند.

نسخه‌های قدیمی و Compatibility

vSS VLAN و NIC teaming دارد، اما vDS featureهای متمرکز ارائه می‌دهد. availability و licensing featureهایی مانند LACP/NIOC با edition و قرارداد فعلی بررسی شوند.

پرسش‌های متداول

آیا vSS از VLAN و NIC Teaming پشتیبانی می‌کند؟

بله؛ این دو قابلیت در هر دو Switch وجود دارند. تفاوت‌های مهم vDS شامل مدیریت متمرکز، LLDP، Private VLAN و Traffic Shaping ورودی است.

آیا برای هر Cluster باید vDS انتخاب شود؟

خیر؛ نیاز به قابلیت، کنترل Consistency، Entitlement و مسیر Recovery تصمیم را تعیین می‌کنند. vSS با Configuration هماهنگ نیز در Cluster قابل استفاده است.

آیا قطع vCenter ترافیک موجود vDS را متوقف می‌کند؟

معمولاً Forwarding موجود روی Host ادامه دارد؛ تغییر Configuration و بعضی عملیات بازیابی محدود می‌شوند. دسترسی OOB و مسیر بازیابی مستقل باید آماده باشد.