المقدمة
يصف هذا المستند الاختبارات التي تم إجراؤها للتحقق من دعم 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 بترحيل الأجهزة الافتراضية إلى الأجهزة المضيفة الأخرى داخل المجموعة لزيادة الأداء إلى الحد الأقصى. وعلى الرغم من أن دائرة الاستعلام والأمن تعمل فوق موقع VMotion، ومن ثم تعمل الهجرة الحية بنفس الطريقة، فإن سيناريوهات محددة لإدارة الاستعلام والأمن لم يتم إختبارها في الوقت الحالي، وبالتالي لم يتم دعمها رسميا.
المتطلبات
- إستخدام إصدارات البرامج المختبرة الموصى بها:
- 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). رسم بياني يمثل طبولوجيا الاختبار:

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

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

هنا نتيجة كل إختبار:
إختبار
|
C9800-CL مستقل
|
نوع vMotion
|
الملاحظات/التعليقات
|
1
|
|
حساب المورد فقط
|
غير مدعومة: تسقط نقاط الوصول والعملاء من الشاشة، والتي يتم إستردادها بعد مرور بعض الوقت، بسبب مشكلة في وضع علامة الضيف الظاهرية (شبكة 802.1q VLAN): مقالة قاعدة المعارف الحل: بدء إختبار الاتصال المستمر من وحدة التحكم إلى أي جهاز شبكة سلكية
|
2
|
|
وحدة التخزين فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار التام، كما تظهر نقطة إختبار واحدة
|
3
|
|
حساب الموارد والتخزين
|
غير مدعومة: تسقط نقاط الوصول والعملاء من الشاشة، والتي يتم إستردادها بعد مرور بعض الوقت، بسبب مشكلة في وضع علامة الضيف الظاهرية (شبكة 802.1q VLAN): مقالة قاعدة المعارف الحل: بدء إختبار الاتصال المستمر من وحدة التحكم إلى أي جهاز شبكة سلكية
|
إختبار
|
سو أكتيف
إيه كي بالف: 100 مللي ثانية
|
نوع vMotion
|
|
4
|
|
حساب المورد فقط
|
مدعوم: حركة المرور مستقرة على إعادة تحميل دمج المكدس الاحتياطي النشط الذي شوهد بسبب انتهاء صلاحية رسائل تنشيط HA RP
|
5
|
|
وحدة التخزين فقط
|
مدعوم: حركة المرور مستقرة، في معظم الوقت الذي يأتي RP فيه قبل انتهاء صلاحية مؤقت رسائل تنشيط الاتصال RP حتى لا يظهر أي دمج للمكدس
|
6
|
|
حساب الموارد والتخزين
|
مدعوم: انتقل الاستعداد إلى حالة الاسترداد الاحتياطية وإعادة التحميل بسبب دمج المكدس.
|
إختبار
|
سو أكتيف
إيه كي بالف: 200 مللي ثانية
|
نوع vMotion
|
|
7
|
|
حساب المورد فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار التام، كما تظهر نقطة إختبار اتصال واحدة في وضع الاستعداد النشط، كما تتميز حالة الاستعداد بالاستقرار
|
8
|
|
وحدة التخزين فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار التام، كما تظهر نقطة إختبار واحدة على الحامل النشط والحامل الثابت أيضا
|
9
|
|
حساب الموارد والتخزين
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار التام، كما تظهر نقطة إختبار واحدة على الحامل النشط والحامل الثابت أيضا
|
إختبار
|
إحتياطي SSO
HA keepalive - 100 مللي ثانية
|
نوع vMotion
|
|
10
|
|
حساب المورد فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار عند التشغيل والحامل أيضا بعد تشغيل vMotion؛ في بعض الأحيان، تتم رؤية عمليات إعادة تحميل دمج المكدس الاحتياطية.
|
11
|
|
وحدة التخزين فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار عند التشغيل والحامل أيضا بعد تشغيل vMotion؛ في بعض الأحيان، تتم رؤية عمليات إعادة تحميل دمج المكدس الاحتياطية.
|
12
|
|
حساب الموارد والتخزين
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار عند التشغيل والحامل أيضا بعد تشغيل vMotion؛ في بعض الأحيان، تتم رؤية عمليات إعادة تحميل دمج المكدس الاحتياطية.
|
إختبار
|
HA على إستعداد
إيه كيه باليف-200 مللي ثانية
|
|
|
13
|
|
حساب المورد فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار عند التشغيل والحامل أيضا بعد تشغيل vMotion
|
14
|
|
وحدة التخزين فقط
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار عند التشغيل والحامل أيضا بعد تشغيل vMotion
|
15
|
|
حساب الموارد والتخزين
|
مدعوم: تتميز نقاط الوصول (AP) والعملاء بالاستقرار عند التشغيل والحامل أيضا بعد تشغيل vMotion
|
كما هو موضح في هذا الجدول، يفشل 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.