تعرف على الخوارزمية لتحديد قابلية الإدارة في سيناريوهات تجاوز فشل UCCX

المقدمة

يصف هذا المستند الخوارزمية المستخدمة لتحديد السريان بعد بدء تجاوز الفشل أو الاسترداد من وضع الجزيرة في Unified Contact Center Express (UCCX).

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

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• UCCX
• آلية تجاوز الفشل

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

معلومات أساسية

من الممكن إستخدام سيناريوهين حيث يجب إختيار مدير، بينما تختلف الخوارزمية المستخدمة لتحديد القدرة على الإدارة بين العقدتين بالنسبة لكل سيناريو.

تجاوز فشل المحرك العادي

يتم مصادفة هذا السيناريو عند عدم وجود عنصر رئيسي (كما هو الحال عند بدء تشغيل نظام مجموعة) أو عند وجود عنصر رئيسي واحد، عندما يتم تجاوز فشل العقد في بيئة HAoLAN أو HAoWAN بدون وضع الجزيرة.

شلالات الخوارزمية لتحديد الموقع الرئيسي (أي محاولة 1، وإلا جرب 2 أخرى جرب 3، وإلا جرب 4 في حالات النزاع):

الخطوة 1. حدد حالة محرك UCCX لكلا العقدتين، أيهما في وضع أفضل - وهذا هو الأساسي الجديد. إذا كانا متماثلين، فانتقل إلى الخطوة 2.

الخطوة 2. تحديد طراز الأجهزة للعقدتين. العتاد الأفضل هو المدير الجديد. إذا كانا متشابهين، فانتقل إلى الخطوة . ونظرا لأن العديد من عمليات تثبيت UCCX أصبحت الآن افتراضية، فلا يتم إستخدام هذه الخطوة غالبا.

الخطوة 3. حدد العقدة 1 أي الناشر (أول عقدة UCCX مثبتة). إن الأساسي الجديد هو عقدة Publisher. تمت برمجة CVD لجعل العقدة 1 كمدير افتراضي. يتم أخذ هذا من المعلمة PrimaryEngineComputerName في تكوين نظام المجموعة (ClusterSpecificConfig) على CET. إذا كانت هذه القيمة غير صحيحة، تأخذ العقدة 2 دائما صفة المستخدم. راجع: CSCuw95068.

الخطوة 4. إذا تعذر على الخطوة 3 تحديد اسم المضيف الصحيح للناشر، فقم بجعل العقدة 2 هي الأساسي (المشترك).

المنطق هو:

الخطوة 1. تحقق من حالة الخدمة للعقد. إذا كانت العقدة 1 في_SERVICE والعقدة 2 في PARTIAL_SERVICE، تصبح العقدة 1 هي الرئيسية. إذا كانت الحالات هي نفسها (in_service أو partial_service)، فانتقل إلى الخطوة 2.

الخطوة 2. يتم التحقق من مواصفات الأجهزة لعقد UCCX 2. يتم تسليم الخادم ذو المواصفات الأفضل إلى الإدارة. إذا كانت مواصفات الأجهزة متماثلة، فانتقل إلى الخطوة 3.

الخطوة 3. يصبح الناشر هو المدير إذا كان اسم المضيف الخاص بالنشر مطابق لاسم PrimaryEngineComputerName على CET (ClusterSpecificConfig). في حالة عدم وجود تطابق انتقل إلى الخطوة 4.

الخطوة 4. أجعل مدير المشترك إذا فشلت الخطوة الأعلى.

Island Mode Recovery

ويصادف هذا السيناريو أثناء الاسترداد من وضع الجزيرة عندما يكون هناك إثنان من الأساسيات. عند حدوث ذلك، لا يتم تنفيذ الخوارزمية الواردة أعلاه. وبدلا من ذلك، تحافظ عقدة ناشر UCCX (أول عقدة UCCX المثبتة) على وضع الإدارة بينما يقوم المشترك بإسقاط النظام.

ملاحظة: من المهم ملاحظة أن اسم المضيف للعقدة الأساسية يجب أن يطابق إدخال PrimaryEngineComputerNam في كائن ClusterSpecificConfig. وإلا، فإنه يتم إختيار العقدة الثانوية كمدير. أستخدم أداة CET للاتصال بالعقدة الأساسية للتحقق من صحة الإدخال وتغييره إذا لزم الأمر.

بالإضافة إلى ذلك، عندما يتحقق النظام من العقدة التي في حالة خدمة أفضل، كما هو موضح في الخطوة 1، فهذه هي الطريقة للتحقق من الخدمات المحددة التي تم فحصها 

• خدمة المحرك
• مكون مدير الإدارة داخل المحرك

إذا كان كلا هاتين الخدمتين IN_SERVICE، فسيتم إعتبار هذه العقدة هي العقدة الرئيسية.

هذه قصاصة من السجلات التي يتم فيها إستخدام الخوارزمية لشرح السيناريو: في هذا السيناريو، قيل أن العقدة 1 هي الأساس قبل انقطاع التيار بشبكة WAN؛ وعندما عاد الاتصال، أصبحت العقدة 2 هي الأساس.

عند تعطل إرتباط شبكة WAN:

 اولا، كانت العقدتان كلتيهما بارزتين. كانت العقدة 1 هي الأساس، والعقدة 2 هي الأخرى أصبحت الرئيسية:

يقوم محرك CCX الموحد من Cisco على العقدة 2 بتغيير الأساسي من false إلى true

3162: Dec 15 12:41:17.607 IST %MCVD-CLUSTER_MGR-7-UNK:JavaService167

  وهذا هو أيضا الوقت الذي تشتبه فيه العقدة في حدوث عطل للعقدة الأخرى:

3111: Dec 15 12:41:17.481 IST %MCVD-CVD-4-HEARTBEAT_SUSPECT_NODE_CRASH:CVD suspects node crash: state=Heartbeat State,nodeInfo=Node id=1 ip=172.30.72.2 convId=69 cmd=16 viewLen=1,dt=1022

عندما عاد إرتباط شبكة الاتصال واسعة النطاق وبدأ التقارب:

9777: Dec 15 12:42:28.859 IST %MCVD-CVD-4-MASTER_DETECTS_NODE_JOIN:More than one master detected, when processing node join: name=Cisco Unified CCX Database,nodeId=2,masterCnt=1
9778: Dec 15 12:42:28.859 IST %MCVD-CVD-7-UNK:Split after network partition is detected, new nodeId=2

Node id=002, addresses=[172.30.83.2], MAC addresses=[279f2d5ba86d], compName=UCCXSUB, state=IN SERVICE, en=true, rmiPort=6999, masterPort=1994
       VersionInfo: [ Version=8.5.1.11003-32, crsRelease=8.5.1.11003-32, crsServiceRelease=, crsEngineeringSpecial=, dbEdition=IDS, dbVersion=V11, installTime=1348139852000, upgradeTime=1348139852000, jtapiClientVersion=8.6(2.10000)-2 ]
       cT=969, uT=969, rT=528, serVer=3, cvdVer=3, points=0
  Component201: type=CRS Historical Datastore, state=IN SERVICE, en=true, prim=false, node=002, activationTime=1348141153000, parent=null, uT=492, rT=193, rootDir /opt/cisco/uccx, version=8.5.1.11003-32, serVer=1
    Service163: name=Cisco Unified CCX Database, Feature Service, isActivationSupported=false, node=002, state=IN SERVICE, master, parent=null, type=DB Services, logDir: /common/informix/crs/???, en=true, uT=928, rT=0, version=8.5.1.11003-32, serVer=4
  Component202: type=Cisco Recording, state=IN SERVICE, en=true, prim=false, node=002, activationTime=1348140987000, parent=null, uT=439, rT=198, rootDir /opt/cisco/uccx, version=8.5.1.11003-32, serVer=1
 
9823: Dec 15 12:42:38.866 IST %MCVD-CLUSTER_MGR-7-UNK:Post Convergence Event: CONVERGENCE_STARTED, name=Cisco Unified CCX Engine
9824: Dec 15 12:42:38.866 IST %MCVD-CLUSTER_MGR-7-UNK:Cl Mgr: Cisco Unified CCX Engine Convergence Started
9825: Dec 15 12:42:38.866 IST %MCVD-CLUSTER_MGR-7-UNK:try to process MasterConvergenceCompletedCmdImpl: name Cisco Unified CCX Engine, nodeId=1, type=MASTER_DROPPED, uniqueId=66, master=false, updateTick=3101, baseTick=3100, nodeCurrentTick=3101
9826: Dec 15 12:42:38.866 IST %MCVD-CLUSTER_MGR-7-UNK:process MasterConvergenceCompletedCmdImpl: name Cisco Unified CCX Engine, nodeId=1, type=MASTER_DROPPED, uniqueId=66, master=false, updateTick=3101, baseTick=3100, nodeCurrentTick=3101
9827: Dec 15 12:42:38.866 IST %MCVD-CLUSTER_MGR-7-UNK:JavaService66: Cisco Unified CCX Engine on node 1 change master from true to false

هذا هو الوقت الذي بدأ فيه التقارب. لذلك، يتم إستخدام الخوارزمية الموضحة مسبقا لاختيار المدير. هنا، لاحظ حالات كلا العقد:

Node id=001, addresses=[172.30.72.2], MAC addresses=[95eab6e4c4cb], compName=UCCXPUB, state=PARTIAL SERVICE, en=true, rmiPort=6999, masterPort=1994
       VersionInfo: [ Version=8.5.1.11003-32, crsRelease=8.5.1.11003-32, crsServiceRelease=, crsEngineeringSpecial=, dbEdition=IDS, dbVersion=V11, installTime=1348064353000, upgradeTime=1348064353000, jtapiClientVersion=8.6(2.10000)-2 ]
       cT=3275, uT=3275, rT=534, serVer=3, cvdVer=3, points=0

Node id=002, addresses=[172.30.83.2], MAC addresses=[279f2d5ba86d], compName=UCCXSUB, state=IN SERVICE, en=true, rmiPort=6999, masterPort=1994
       VersionInfo: [ Version=8.5.1.11003-32, crsRelease=8.5.1.11003-32, crsServiceRelease=, crsEngineeringSpecial=, dbEdition=IDS, dbVersion=V11, installTime=1348139852000, upgradeTime=1348139852000, jtapiClientVersion=8.6(2.10000)-2 ]
       cT=969, uT=969, rT=528, serVer=3, cvdVer=3, points=0

لذلك، باستخدام الخوارزمية، يتم تسليم الوجهة إلى العقدة 2 (النقطة 1 في الخوارزمية). وهذا يفسر لماذا أصبحت عقدة UCCX رقم 2 هي الأساس بعد التقارب.

ومع ذلك، يجب التحقق من سبب وجود العقدة 1 في الخدمة الجزئية. كان في الخدمة الجزئية بسبب النظام الفرعي للهاتف:

name=Unified CM Telephony Subsystem, Feature Service, isActivationSupported=false, node=001, state=PARTIAL SERVICE