概要
このドキュメントでは、Unified Contact Center Express(UCCX)でアイランドモードからのフェールオーバーまたはリカバリが開始された後に、マスターシップを決定するために使用されるアルゴリズムについて説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Unified CCX
- フェールオーバーメカニズム
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
マスターを選択する必要がある2つのシナリオが可能であり、2つのノード間のマスターシップを決定するために使用されるアルゴリズムはシナリオごとに異なります。
通常のエンジンフェールオーバー
このシナリオは、ノードが島モードのないHAoLANまたはHAoWAN環境でフェールオーバーしている場合に、マスターがない場合（クラスタの起動時など）、または1つのマスターがある場合に発生します。
マスターシップを決定するためにアルゴリズムがウォータリングされます（つまりTry 1、else Try 2、else Try 3、または競合の場合はTry 4）。
ステップ1：両方のノードのUCCXエンジンのステータスを確認します。いずれか良好なステータスの方が、新しいマスターです。両方が同じ場合は、手順2に進みます。
ステップ 2： 2つのノードのハードウェアモデルを決定します。新しいマスターは、より良いハードウェアです。両方が同じ場合は、ステップに進みます。現在、多くのUCCXインストールは仮想であるため、この手順はあまり使用されません。
ステップ3：ノード1（パブリッシャ）を特定します（最初にインストールされたUCCXノード）。 新しいマスターはパブリッシャノードです。CVDは、ノード1をデフォルトマスターにするようにプログラムされています。これは、CETのクラスタ設定(ClusterSpecificConfig)のPrimaryEngineComputerNameパラメータから取得されます。この値が正しくない場合、Node2は常にマスターシップを取得します。WLC の:CSCuw95068
ステップ4：ステップ3でパブリッシャの正しいホスト名を判別できない場合は、ノード2をマスター（サブスクライバ）にします。
ロジックは次のとおりです。
ステップ1：ノードのサービスステータスを確認します。ノード1がIN_SERVICEで、ノード2がPARTIAL_SERVICEの場合、ノード1がマスターになります。状態が同じ（IN_SERVICEまたはPARTIAL_SERVICE）場合は、ステップ2に進みます。
ステップ2: 2つのUCCXノードのハードウェア仕様がチェックされます。仕様の良いサーバがマスターシップを渡されます。ハードウェアの仕様が同じ場合は、ステップ3に進みます。
ステップ3: PUBLISHERのホスト名がCET(ClusterSpecificConfig)のPrimaryEngineComputerNameと一致する場合、PUBLISHERがMASTERになります。 MATCHがない場合は、ステップ4に進みます。
ステップ4：上記のステップが失敗した場合は、サブスクライバマスターにします。
アイランドモードの回復
このシナリオは、2つのマスターがある場合に島モードからの復旧中に発生します。この場合、上記のアルゴリズムは実行されません。むしろ、UCCXパブリッシャノード（最初にインストールされたUCCXノード）はマスターシップを保持し、サブスクライバはマスターシップをドロップします。
注：重要な点は、プライマリノードのホスト名がClusterSpecificConfigオブジェクトのPrimaryEngineComputerNamエントリと一致する必要があることです。それ以外の場合、セカンダリノードがマスターとして選択されます。CETツールを使用してプライマリノードに接続し、エントリが正しいかどうかを確認し、必要に応じて変更します。
さらに、ステップ1で説明したように、どのノードがより良いサービス状態であるかをシステムがチェックする場合、チェックする特定のサービスをチェックする方法です
- エンジンサービス
- エンジン内のマネージャコンポーネント
両方のサービスがIN_SERVICEの場合、このノードはマスターシップと見なされます。
このシナリオを説明するためにアルゴリズムが使用されるログのスニペットを次に示します。このシナリオでは、WANが停止する前にノード1がマスターとして指示されました。WANが戻ると、ノード2がマスターになります。
WANリンクがダウンした場合：
最初に、両方のノードがマスターでした。ノード1がマスターです。ノード2もマスターになりました。
ノード2のCisco Unified CCX Engineがマスターを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
WANリンクが復旧し、コンバージェンスが開始された時点：
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
フィードバック