O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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).
A Cisco recomenda que você tenha conhecimento destes tópicos:
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.
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.
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.
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
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