Entienda el algoritmo para determinar el dominio en los escenarios de falla UCCX

Introducción

Este documento describe el algoritmo usado para determinar el dominio después de que la Conmutación por falla o la recuperación del modo de la isla se inicie en el Centro de contacto unificado expreso (UCCX).

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• UCCX
• Mecanismo de la Conmutación por falla

Componentes Utilizados

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

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Dos decorados donde un master debe ser elegido son posibles y el algoritmo usado para determinar el dominio entre los dos Nodos son diferentes para cada decorado.

Conmutación por falla normal del motor

Se encuentra este decorado cuando no hay o master (por ejemplo cuando se comienza un racimo) o hay uno principal, cuando los Nodos han Conmutación por falla terminado en un entorno de HAoLAN o de HAoWAN sin el modo de la isla.

Las cascadas del algoritmo para determinar el dominio (es decir intento 1, intento otro 3 del intento 2, intento otro 4 en casos de la contención):

Paso 1. Determine el Estado del motor UCCX de ambos Nodos. Cualquiera está en un mejor estatus – que sea el nuevo master. Si ambos son semejantes, después muévase al paso 2.

Paso 2. Determine el modelo de hardware de los dos Nodos. La mejor dotación física es el nuevo master. Si ambos son semejantes, muévase para caminar. Puesto que muchas instalaciones UCCX son virtuales ahora, este paso no es de uso frecuente.

Paso 3. Determine al editor del nodo 1 es decir (el primer nodo UCCX instalado). El nuevo master es el nodo del editor. El CVD se programa para hacer el nodo 1 como el master del valor por defecto. Esto se toma del parámetro de PrimaryEngineComputerName en los config del racimo (ClusterSpecificConfig) en el CET. Si este valor es incorrecto, Node2 toman siempre el dominio. Refiérase: CSCuw95068.

Paso 4. Si el paso 3 no puede determinar el hostname correcto del editor, haga el nodo 2 como el master (suscriptor).

La lógica es:

Paso 1. Controle el estatus del servicio de los Nodos. Si el nodo 1 es IN_SERVICE y el nodo 2 está en PARTIAL_SERVICE, el nodo 1 siente bien al master. Si los estados son lo mismo (IN_SERVICE o PARTIAL_SERVICE), vaya al PASO 2.

Paso 2. La especificación de hardware de los 2 Nodos UCCX se controla. El servidor con la mejor especificación se da el dominio. Si las especificaciones de hardware son lo mismo, vaya al PASO 3.

Paso 3. El EDITOR hace el MASTER si el hostname del EDITOR hace juego el PrimaryEngineComputerName en CET (ClusterSpecificConfig). Si no hay COINCIDENCIA vaya al paso 4.

Paso 4. Haga al master del suscriptor si sobre el paso falla.

Recuperación del modo de la isla

Este decorado se encuentra durante la recuperación del modo de la isla cuando hay dos masters. Cuando ocurre esto, el algoritmo antedicho no se ejecuta. Bastante, el nodo del editor UCCX (el primer nodo UCCX instalado) conserva el dominio y el dominio de los descensos de suscriptor.

Nota: Un asunto importante a observar es que el hostname del Nodo primario debe hacer juego la entrada de PrimaryEngineComputerNam en el objeto de ClusterSpecificConfig. Si no, el nodo secundario se elige como master. Utilice la herramienta CET para conectar con el Nodo primario para controlar si la entrada está correcta y para cambiarlo en caso necesario.

Además, cuando son las revisiones del sistema que el nodo es en un mejor estatus del servicio, como se menciona en el paso 1, los servicios específicos controlados como sigue:

 1. Servicio del motor

 2. Componente del encargado del encargado dentro del motor

Si ambos servicios son IN_SERVICE, después este nodo se considera para el dominio.

Esto es un recorte de los registros donde el algoritmo se utiliza para explicar el decorado: En este decorado el nodo 1 fue dicho ser el master antes de Interrupción WAN; y cuando se volvió WAN, el nodo 2 sintió bien al MASTER.

Cuando fue el link PÁLIDO abajo:

•    Primero, ambos los Nodos eran master. El nodo 1 era el master; El nodo 2 también sintió bien al master:

Cisco unificó el motor CCX en el master del cambio del nodo 2 de falso para verdad

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

•    Éste es también el tiempo 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 se volvió el link PÁLIDO y CONVERGENCIA comenzado:

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

Esto es cuando la convergencia comenzó. Por lo tanto, el algoritmo explicado anterior se utiliza para elegir al master. Aquí, note 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, yendo por el algoritmo, el dominio se da al nodo 2 (punta 1 en el algoritmo). Esto explica porqué el nodo 2 UCCX sintió bien al master después de la convergencia.

• Sin embargo, usted tiene que controlar porqué el nodo 1 estaba en el servicio parcial. Estaba en el servicio parcial debido al subsistema de la telefonía:

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