Collaboration : Cisco Unified Intelligent Contact Management Enterprise

ICM et synchronisation

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Le synchroniseur est l'une des principales fonctions du système de l'Intelligent Contact Management de Cisco (missile aux performances améliorées). Deux synchroniseurs communiquent les uns avec les autres pour s'assurer que les deux côtés du système voient la même chose entrer des messages dans la même commande. Chaque synchroniseur reçoit des messages d'entrée logiquement, et en avant eux à l'autre synchroniseur. À un moment donné, un synchroniseur est activé et l'autre est désactivé.

Remarque: Dans le cas des Routeurs, vous pouvez voir un état activé appareillé. Dans le cas des passerelles d'accès aux périphériques duplexées (PAGE), vous pouvez les voir fonctionner comme pair désactivé, dans ce cas, le synchroniseur activé doit déterminer la commande des messages d'entrée.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Abc réseau

  • Missile aux performances améliorées de Cisco

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Cisco ICM 4.6.2 et ultérieures

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

États de synchroniseur

Voici les descriptions des états possibles de synchroniseur :

Se connecter

C'est l'état initial du synchroniseur. Les tentatives de synchroniseur d'établir une connexion avec le synchroniseur distant au-dessus du chemin dédié. Un temporisateur de connexion expire si les synchroniseurs ne peuvent pas établir une connexion au cours d'une période raisonnable (approximativement 30 secondes).

Test

Le synchroniseur ne peut pas communiquer avec le synchroniseur distant au-dessus du chemin dédié, et emploie la procédure de Test-Autre-Side pour décider si devenir activé ou désactivé.

Appareiller-activé

Le synchroniseur est dans la transmission avec le synchroniseur distant (appareillé), et exécute la commande des messages (activés).

Appareiller-handicapés

Le synchroniseur est dans la transmission avec le synchroniseur distant (appareillé), mais n'exécute pas la commande des messages (désactivés).

Isoler-activé

Dans cet état, le synchroniseur ne communique pas avec le synchroniseur distant (d'isolement), et exécute la commande des messages. En effet, le synchroniseur opère son côté du système en mode non-défaut-tolérant.

Isoler-handicapés

Le synchroniseur ne communique pas avec le synchroniseur distant (d'isolement), et n'exécute pas la commande des messages (désactivés). En effet, le synchroniseur empêche l'exécution de son côté du système.

Si un routeur sent cet état, un message est envoyé à tout le PGs qui ont des connexions actives avec ce côté à réaménager avec l'autre côté. Le MDS disparaît hors service, et entraîne tous les processus qui emploient le MDS de routeur (comme, le rtr, le lgr, l'agi, incrpnic) pour quitter et être redémarrés par le gestionnaire de noeud.

Scénarios possibles

Cette section répertorie les scénarios possibles que vous pouvez rencontrer.

Ce qui si mon routeur est affecté par une panne au-dessus du réseau privé ?

Toutes les fois que la transmission au-dessus du chemin dédié est perdue, les deux synchroniseurs vérifient pour voir s'ils sont connectés à une majorité des périphériques configurés. Si oui, les synchroniseurs se comportent normalement (par exemple, les restes activés de synchroniseur activés, et le synchroniseur handicapé appellent le Test-Autre-Side (TOS)).

Si un synchroniseur le découvre qu'il n'est pas connecté à une majorité des périphériques configurés, le synchroniseur décale immédiatement à l'état d'Isoler-handicapés, et le côté handicapé envoie également un message à n'importe quelle PAGE avec une connexion active pour rebrancher à l'autre côté (d'active). En ce moment le MDS va hors service sur le côté handicapé, et la reprise de processus. Après reprise, les process starts de TOS au-dessus de nouveau (une gamme de paquets de keep-alive envoyés au-dessus du réseau public par une PAGE au pair pour reconnaître l'état), ainsi un certain niveau de « tolérance aux pannes » demeure en place, bien que sévèrement limité et lent.

Si le réseau privé échoue, et le côté handicapé n'a pas une connexion à une majorité de PGs au-dessus du WAN visible, il des transitions immédiatement à l'état des Isoler-handicapés MDS. Tandis que dans cet état, le côté ne va pas l'active. Il est considéré incapable du routage, ainsi même si le côté activé descend, ce côté demeure inactif, et vote juste l'autre côté, alors qu'il attend le processus pour récupérer.

Quelques scénarios semblables peuvent se produire du côté activé également. Les tentatives activées de côté de rester ont activé après une panne, tant que elle garde la connexion de PAGE de majorité. S'il ne fait pas, il décale également aux Isoler-handicapés. Si le côté handicapé perd également la connexion avec une majorité de PGs, une double situation de panne se produit.

Le tableau 1 répertorie les résultats du TOS et des actions.

Tableau 1 ? Résultats de TOS et d'actions

Routeur Action
Le pair est activé Séjour désactivé - Le MDS disparaît hors service ; la sortie de processus de lgr et de rtr, et sont redémarrées par le gestionnaire de noeud.
Le pair est désactivé Become a activé.
Inaccessible Become a activé.
Minuterie Séjour désactivé - Le MDS disparaît hors service, lgr et sortie de processus de rtr, et est redémarré par le gestionnaire de noeud.

Ce qui si c'est une PAGE affectée par une panne autre que le réseau privé ?

Quand il y a une perte de chemin dédié au partenaire, le PGs ne peut pas communiquer les uns avec les autres si le chemin dédié entre le PGs qui composent une paire de PAGE est perdu. Dans ce cas, l'active de PAGE reste alors actif, et les autres tentatives de PAGE continuellement pour rétablir le chemin dédié au-dessus de la connexion réseau privée, et envoie une demande de TOS au routeur de vérifier l'état de pair. Les essais de PAGE active continuellement pour rétablir le chemin dédié.

Pourquoi y a-t-il traitement différent dans le cas du routeur ?

Le système est sérieusement altéré quand un réseau privé ne fonctionne pas ou quand une connexion au PGs actif est perdue. Considérez-le un système simplexed, parce qu'il n'y a plus n'importe quelle réponse synchronisée de Basculement (pulsations). Si le côté actif descend, le côté handicapé n'est pas lancé jusqu'à ce qu'il ait atteint ce point dans son recyclage dans ce qu'il vérifie les connexions de PAGE, exécute le TOS, trouve l'autre côté à désactiver, et le lance finalement. La procédure entière pourrait prendre quelques minutes avant que conduisant soit restauré.

Que se passe-t-il ?

L'architecture globale est étudiée pour empêcher une situation où deux Routeurs avec les informations de configuration différentes conduisent l'appel, parce que ceci peut envoyer une étiquette différente au réseau.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 26300