Comprender el algoritmo para determinar el dominio en los escenarios de recuperación ante fallos de UCCX

Introducción

Este documento describe el algoritmo utilizado para determinar el dominio después de que se inicie la recuperación o recuperación del modo de isla en Unified Contact Center Express (UCCX).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• UCCX
• Mecanismo de conmutación por fallas

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Dos escenarios donde se debe elegir un maestro son posibles y el algoritmo utilizado para determinar el dominio entre los dos nodos es diferente para cada escenario.

Conmutación por fallo del motor normal

Esta situación se produce cuando no hay ningún maestro (por ejemplo, cuando se inicia un clúster) o hay un maestro, cuando los nodos se conmutan por error en un entorno HAoLAN o HAoWAN sin el modo de isla.

El algoritmo cae para determinar el dominio (es decir, el Intento 1, o el Intento 2, Intentar 3, sino el Intento 4 en casos de contención):

Paso 1. Determine el estado del motor UCCX de ambos nodos, el que tenga mejor estado, es decir, el nuevo maestro. Si ambos son iguales, vaya al paso 2.

Paso 2. Determine el modelo de hardware de los dos nodos. El mejor hardware es el nuevo maestro. Si ambos son iguales, vaya al paso . Dado que muchas instalaciones de UCCX son ahora virtuales, este paso no se suele utilizar.

Paso 3. Determine el nodo 1, es decir, Publisher (el primer nodo UCCX instalado). El nuevo maestro es el nodo Publisher. CVD está programado para convertir el Nodo 1 en el maestro predeterminado. Esto se toma del parámetro PrimaryEngineComputerName de la configuración del clúster (ClusterSpecificConfig) en CET. Si este valor es incorrecto, el nodo 2 siempre asume el liderazgo. Consulte: CSCuw95068.

Paso 4. Si el paso 3 no puede determinar el nombre de host correcto de Publisher, convierta el nodo 2 en el principal (Suscriptor).

La lógica es:

Paso 1. Verifique el estado del servicio de los nodos. Si el Nodo 1 es IN_SERVICE y el Nodo 2 está en PARTIAL_SERVICE, el Nodo 1 se convierte en el Nodo principal. Si los estados son los mismos (IN_SERVICE o PARTIAL_SERVICE), vaya al PASO 2.

Paso 2. Se verifica la especificación de hardware de los 2 nodos UCCX. El servidor con la mejor especificación recibe el liderazgo. Si las especificaciones de hardware son las mismas, vaya al PASO 3.

Paso 3. El PUBLISHER se convierte en el MAESTRO si el nombre de host del PUBLISHER coincide con PrimaryEngineComputerName en CET (ClusterSpecificConfig). Si no hay COINCIDENCIA, vaya al paso 4.

Paso 4. Haga que el suscriptor sea maestro si el paso anterior falla.

Recuperación del modo isla

Este escenario se encuentra durante la recuperación del modo isla cuando hay dos maestros. Cuando esto ocurre, el algoritmo anterior no se ejecuta. Por el contrario, el nodo de UCCX Publisher (el primer nodo UCCX instalado) conserva el dominio y el suscriptor descarta el dominio.

Nota: Algo importante que hay que tener en cuenta es que el nombre de host del nodo primario debe coincidir con la entrada PrimaryEngineComputerNam del objeto ClusterSpecificConfig. De lo contrario, el nodo secundario se elige como maestro. Utilice la herramienta CET para conectarse al nodo principal para comprobar si la entrada es correcta y cambiarla si es necesario.

Además, cuando el sistema verifica qué nodo está en mejor estado de servicio, como se menciona en el paso 1, esta es la forma de verificar los servicios específicos comprobados 

• Servicio del motor
• componente Manager dentro del motor

Si ambos servicios son IN_SERVICE, se considera que este nodo es para el dominio.

Este es un fragmento de los registros donde se utiliza el algoritmo para explicar el escenario: En este escenario, se indicó que el nodo 1 era el maestro antes de la interrupción de la WAN; y cuando la WAN regresó, el Nodo 2 se convirtió en el MASTER.

Cuando el link WAN se desactivó:

 Primero, ambos nodos eran Master. El Nodo 1 fue el Maestro; El nodo 2 también se convirtió en el maestro:

Cisco Unified CCX Engine en el nodo 2 cambia el maestro de false a true

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

  Este es también el momento en que el Nodo sospecha una caída del otro nodo:

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

Cuando regresó el enlace WAN y comenzó la CONVERGENCIA:

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

Aquí es cuando comenzó la convergencia. Por lo tanto, el algoritmo explicado anteriormente se utiliza para elegir el maestro. Aquí, observe los estados de ambos nodos:

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

Por lo tanto, según el algoritmo, el dominio se entrega al Nodo 2 (punto 1 en el algoritmo). Esto explica por qué el Nodo 2 de UCCX se convirtió en el Maestro después de la convergencia.

Sin embargo, debe comprobar por qué el Nodo 1 se encontraba en el servicio parcial. Se encontraba en servicio parcial debido al subsistema de telefonía:

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