دعم VMware vSphere على Catalyst 9800

المقدمة

يصف هذا المستند الاختبارات التي تم إجراؤها للتحقق من دعم vMotion ل C9800-CL التي تعمل على vSphere ESXi.

المتطلبات الأساسية

C9800-CL هو عامل شكل الجهاز الظاهري لوحدة التحكم في الشبكة المحلية (LAN) اللاسلكية Catalyst 9800. يمكنك إستخدام vSphere vMotion من VMware لإجراء ترحيل مباشر بدون وقت توقف عن العمل ل Catalyst 9800-CL من خادم مضيف إلى آخر. ويمكن إستخدام هذه الإمكانية عبر تقنية vSwitches والمجموعات. الهدف هو أنه أثناء الترحيل المباشر للطراز C9800-CL، تظل الشبكة اللاسلكية نشطة ويستمر المستخدمون اللاسلكيون في التمتع بإمكانية الاتصال التي يحتاجون إليها.

يمكن تنفيذ vMotion يدويا أو كجزء من تكوين أداة vSphere لجدول الموارد الموزعة (DRS) من VMware. تقوم خدمة إسترداد بيانات الأجهزة الافتراضية (DRS) بنشر أحمال عمل الأجهزة الافتراضية عبر أجهزة vSphere المضيفة داخل نظام مجموعة، كما تعمل على مراقبة الموارد المتوفرة لك. بناء على مستوى التشغيل التلقائي، تقوم DRS بترحيل الأجهزة الافتراضية إلى الأجهزة المضيفة الأخرى داخل المجموعة لزيادة الأداء إلى الحد الأقصى.

يتم دعم وظائف VMware، مثل تطبيق vMotion و Snapshot و Distributed Resource Scheduler (DRS) و vNIC Teaming وأوضاع SR-IOV. ومع ذلك، فإن النسخ من اللقطات غير مدعوم.

كما أن تقنية vMotion و DRS و Snapshot و VNIC Teaming غير مدعومة عند تمكين وضع SR-IOV.

لمزيد من المعلومات، راجع وحدة التحكم اللاسلكية Cisco Catalyst 9800-CL لورقة بيانات السحابة.

المتطلبات

• إستخدام إصدارات البرامج المختبرة الموصى بها: 
  • ESXi vCenter 6.7 أو لاحقا
    
  • برنامج C9800-CL: 17.9.2 والإصدارات اللاحقة
    
• يجب أن يكون زمن الوصول (RTT) بين وحدة التخزين عن بعد والخادم حيث يتم تشغيل C9800-CL < 60 مللي ثانية
• يجب ألا يحتوي الطراز C9800-CL VM على أي مراسلات ESXi لاستضافة مراسلات محددة مثل CD/DVD واتصال منفذ وحدة التحكم التسلسلية وما إلى ذلك.
• قم بتكوين vMotion وفقا لإرشادات VMware للمضيف ووحدات التخزين المشتركة عن بعد والشبكات هنا
• التوافق مع متطلبات شبكة VMware ل vMotion هنا .

المخطط

لإجراء إختبارات التحقق هذه، تم إستخدام مخطط بسيط مع ثلاثة أجهزة مضيفة مختلفة للخوادم ووحدات تخزين عن بعد عبر بروتوكول iSCSI (يمكن إستخدام وحدة التخزين عبر بروتوكول نظام ملفات الشبكة (NFS) كذلك). تعمل وحدة التخزين عن بعد على زيادة فعالية الاتصال بالخوادم بسرعة 10 جيجابت في الثانية. على مضيف ESXi، يتم إنشاء جهاز فيديو من الفئة C9800-CL في الوضع المستقل وأجهزة افتراضية من الفئة C9800-CL أخرى تم تكوينها للتحويل ذو الحالة المستقيمة عبر التوفر العالي (SSO HA). يتم إنشاء زوج HA عبر خادمين مختلفين للتكرار المادي وحتى يتمكن من ترحيل كل من عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) النشط والاستعداد بشكل منفصل. يتم توصيل كل جهاز افتراضي من الطراز C9800-CL بالمحول الظاهري باستخدام ثلاثة منافذ: 

• G1 > منفذ SP (إختياري)
• G2 > منفذ خط الاتصال لواجهة الإدارة اللاسلكية (WMI) VLAN وشبكات VLAN العميل إن وجدت
• G3 > منفذ RP. هذا خاص بإنشاء مجموعة SSO. غير متصل بالوضع المستقل

يحتوي كل خادم مضيف على منفذ فعلي مخصص ومحول مخصص (المحول#1) لتوصيل منافذ RP معا من خلال إرتباط من المستوى الثاني، عبر الخوادم. يتم توصيل المنفذين الفعليين الآخرين بمحول توصيل منفصل (switch#2). رسم بياني يمثل طبولوجيا الاختبار:

نتائج الاختبار

بالنسبة لهذه الاختبارات، تم وضع سيناريوهين للهجرة في الاعتبار:

1. يتم ترحيل C9800-CL المستقلة بين الخادم #1 والخادم #2
2. زوج من C9800-CL تم تكوينه كما في درجة التوافر العالية SSO. في هذه الحالة أولا يتم ترحيل النشط بين الخادم رقم 1 والخادم رقم 3 ثم يتم ترحيل عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) الاحتياطي من الخادم رقم 2 إلى الخادم رقم 3

وفي كلتا الحالتين، تم إختبار كافة الأنواع الثلاثة المختلفة من الانتقال عبر تقنية vMotion: احسب المورد فقط، تخزين فقط، كلا من الكمبيوتر والتخزين.

لتشغيل vMotion، انقر بزر الماوس الأيمن فقط على الجهاز الظاهري (VM) وانقر فوق ترحيل:

حدد نوع الترحيل وانتقل عبر الخطوات:

هنا نتيجة كل إختبار:

كما هو موضح في هذا الجدول، يفشل vMotion في السيناريو الأول والثالث (الاختبار رقم 1 ورقم 3) مع الوضع المستقل C9800-CL، حيث إنه يقوم بتنفيذ عمليات حوسبة وترحيل وحدات تخزين؛ في هذه الحالة ينتقل عنوان MAC و IP الخاص ب C9800-CL WMI إلى المضيف الجديد وبالتالي إلى منفذ محول مختلف. يتعذر على vMotion إرسال بروتوكول تحليل العنوان العكسي (RARP) للشبكة المحلية الظاهرية (VLAN) اللاسلكية طراز C9800-CL نظرا لأن مضيف ESXi لا يمكنه تحديد شبكة VLAN قيد الاستخدام بواسطة نظام التشغيل الضيف الذي يتم تشغيله في الجهاز الظاهري. لدعم هذا السيناريو، تحتاج إلى تنفيذ حل بديل: بدء إختبار اتصال مستمر من C9800-CL إلى أي مضيف سلكي قبل إجراء الترحيل؛ وهذا يؤدي إلى تشغيل شبكة المحول للتعرف على الموقع الجديد (المنفذ) الخاص بالجهاز الظاهري (VM) وبالتالي التقارب بشكل أسرع.

في حالة الترحيل التناظرية مع HA SSO (الاختبار #4، على سبيل المثال)، يتم الاستفادة من واجهة إدارة التكرار (RMI) للتحقق من إمكانية الوصول إلى البوابة وبين "نشط" و"الاستعداد"، ومن ثم فهي تولد حركة مرور البيانات التي تحافظ على تحديث جدول عنوان MAC على المحول ولا تحدث المشكلة.

التوصية: لأفضل النتائج، من المستحسن أن يشكل RP ميناء keepalives إلى على الأقل ضعف التقصير 100 مللي ثانية keepalive (ثبته إلى 200 مللي ثانية). إذا كان من الممكن أن تصبح الشبكة بين وحدات التخزين والأجهزة المضيفة مشغولة وأن تزيد من زمن الوصول، فعليك بتعيين مؤقت رسائل تنشيط الاتصال على 300 مللي ثانية. لتكوين مؤقت keepalive على واجهة المستخدم الرسومية، انتقل إلى الإدارة > الجهاز > التكرار:

على واجهة سطر الأوامر (CLI) أستخدم هذا الأمر في وضع EXEC (ليس في وضع التكوين!)

C9800-SSO#chassis redundancy keep-alive timer 3 

للتحقق، أستخدم الأمر show هذا:

C9800-SSO#sh chassis ha-status active  

 

                      My state = ACTIVE 

                    Peer state = STANDBY HOT 

        Last switchover reason = none 

          Last switchover time = none 

                 Image Version = 17.9.1 

 

Chassis-HA   Local-IP         Remote-IP        MASK             HA-Interface 

----------------------------------------------------------------------------- 

This Boot: 169.254.201.23   169.254.201.24   255.255.255.0                       

 

Next Boot: 169.254.201.23   169.254.201.24   255.255.255.0                       

 

 

Chassis-HA   Chassis#    Priority        IFMac Address         Peer-timeout(ms)*Max-retry 

Shape----------------------------------------------------------------------------------------- 

This Boot:    1             1                                      300*5 

 

Next Boot:    1             1                                      300*5 

المحاذير التي تم حلها:

هذه هي المحاذير التي تم إصلاحها في 17.9.2:

معرف تصحيح الأخطاء من Cisco CSCwd17349 - الطراز C9800: يمكن تثبيت الهيكل النشط أثناء تجاوز فشل SSO في 17.9

ملخص

يمكن الاستفادة من ميزة vSphere vMotion من VMware لترحيل ميزة VM طراز C9800-CL من مضيف واحد إلى آخر دون التأثير على عمليات الشبكة اللاسلكية.  تم دعم vMotion رسميا على C9800-CL اعتبارا من الإصدار 17.9.2.