Entender o algoritmo para determinar o domínio em cenários de failover do UCCX

Introduction

Este documento descreve o algoritmo usado para determinar o domínio após o failover ou recuperação do modo ilha ser iniciado no Unified Contact Center Express (UCCX).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• UCCX
• Mecanismo de failover

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Dois cenários em que um mestre deve ser eleito são possíveis e o algoritmo usado para determinar o domínio entre os dois nós é diferente para cada cenário.

Failover de mecanismo normal

Esse cenário é encontrado quando não há um mestre (como quando um cluster é iniciado) ou há um mestre, quando os nós são failover em um ambiente HAoLAN ou HAoWAN sem o modo ilha.

As cachoeiras do algoritmo para determinar o domínio (por exemplo, Try 1, else Try 2 else Try 3, else Try 4 em caso de contenção):

Etapa 1. Determine o status do mecanismo UCCX de ambos os nós, o que estiver em melhor status - esse é o novo mestre. Se ambos forem iguais, vá para a etapa 2.

Etapa 2. Determine o modelo de hardware dos dois nós. O melhor hardware é o novo mestre. Se ambos forem iguais, vá para a etapa . Como muitas instalações do UCCX agora são virtuais, essa etapa não é usada com frequência.

Etapa 3. Determine o Nó 1, ou seja, Publisher (o primeiro nó UCCX instalado). O novo mestre é o nó Editor. O CVD é programado para tornar o Nó 1 o mestre padrão. Isso é obtido do parâmetro PrimaryEngineComputerName na configuração do cluster (ClusterSpecificConfig) no CET. Se esse valor estiver incorreto, Node2 sempre assume o domínio. Consulte: CSCuw95068.

Etapa 4. Se a Etapa 3 não puder determinar o nome de host correto do Publisher, faça do Nó 2 o mestre (Assinante).

A lógica é:

Etapa 1. Verifique o status do serviço dos nós. Se o Nó 1 for IN_SERVICE e o Nó 2 for PARAL_SERVICE, o Nó 1 se tornará o mestre. Se os estados forem os mesmos (IN_SERVICE ou PARAL_SERVICE), vá para a ETAPA 2.

Etapa 2. A especificação de hardware dos 2 nós UCCX é verificada. O servidor com melhor especificação é entregue ao domínio. Se as especificações de hardware forem as mesmas, vá para a ETAPA 3.

Etapa 3. O PUBLISHER se tornará o MASTER se o nome de host do PUBLISHER corresponder ao PrimaryEngineComputerName em CET (ClusterSpecificConfig). Se não houver CORRESPONDÊNCIA, vá para a etapa 4.

Etapa 4. Faça o Subscriber Master se a etapa acima falhar.

Recuperação do modo de ilha

Esse cenário é encontrado durante a recuperação do modo ilha quando há dois mestres. Quando isso ocorre, o algoritmo acima não é executado. Em vez disso, o nó do Editor do UCCX (o primeiro nó do UCCX instalado) mantém o domínio e o assinante abandona o domínio.

Note: Uma coisa importante a observar é que o nome de host do nó primário deve corresponder à entrada PrimaryEngineComputerNam no objeto ClusterSpecificConfig. Caso contrário, o nó secundário é escolhido como mestre. Use a ferramenta CET para se conectar ao nó primário para verificar se a entrada está correta e para alterá-la, se necessário.

Além disso, quando o sistema verifica qual nó está com melhor status de serviço, conforme mencionado na etapa 1, essa é a forma de verificar os serviços específicos verificados 

• Serviço de mecanismo
• componente Gerenciador do gerenciador no mecanismo

Se ambos os serviços forem IN_SERVICE, esse nó será considerado para domínio.

Este é um trecho dos registros em que o algoritmo é usado para explicar o cenário: Neste cenário, o Nó 1 foi instruído a ser o mestre antes da interrupção da WAN; e quando a WAN voltou, Node 2 se tornou o MASTER.

Quando o link da WAN foi desativado:

 Primeiro, ambos os nós eram Master. O nó 1 era o mestre; O nó 2 também se tornou o mestre:

O Cisco Unified CCX Engine no nó 2 altera o mestre de falso para verdadeiro

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

  Esse também é o momento em que o nó suspeita um travamento do outro nó:

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

Quando o link da WAN voltou e a CONVERGÊNCIA foi iniciada:

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

Foi quando a Convergência começou. Portanto, o algoritmo explicado anteriormente é usado para eleger o mestre. Aqui, observe os estados dos dois nós:

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

Portanto, seguindo o algoritmo, o domínio é entregue ao Nó 2 (ponto 1 do algoritmo). Isso explica por que o Nó 2 do UCCX se tornou o Mestre após a convergência.

No entanto, é necessário verificar por que o Nó 1 estava em Serviço parcial. Ele estava em serviço parcial devido ao subsistema de telefonia:

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