Dans le modèle de déploiement de site unique, où un nœud de survivabilité améliorée (ESN) est déployé dans un site avec une passerelle locale pour le routage des appels RTCP. Un maximum de 7500 périphériques peuvent être enregistrés auprès de l’ESN pendant une panne.

Dans le modèle de déploiement sur plusieurs sites, lorsqu’il y a plusieurs sites et qu’ESN peut être déployé sur chaque site dépend des exigences commerciales en matière de survivabilité du site. Les exigences d’une passerelle locale et d’un DNS sont toujours une nécessité et un total de 8 nœuds ESN peuvent être ajoutés à un cluster Unified CM.

Ce modèle de déploiement est pertinent pour un client dans une région avec plusieurs sites et la survivabilité est une exigence pour plusieurs de ces sites. Bien qu’il soit possible de partager la passerelle locale RTCP entre les sites, ce n’est pas recommandé. s’il y a une panne réseau, le site peut être isolé et dans ce cas, ESN ne pourra pas joindre la passerelle locale pour acheminer les appels vers le RTCP.

Vous trouverez ci-dessous 2 options de déploiement pour un déploiement sur plusieurs sites :

• Option 1 : Nœud de survivabilité amélioré déployé sur chaque site.

• Option 2 – Nœud de survivabilité amélioré commun partagé entre plusieurs sites.

Nous surveillons et gérons le nœud de survivabilité améliorée comme les autres nœuds qui sont déployés dans le centre de données d'instance dédiée. Au cours d'un événement de survivabilité, lorsque l'ESN est déconnecté du Cloud Cisco, c'est lorsque nous perdons l'accès au nœud et nous nous reconnectons automatiquement lorsque la panne est résolue et que la connectivité est restaurée.

Nous gérons les certificats d’application UC et lors de l’activation du nœud de survivabilité améliorée, nous avons mis à jour le certificat du cluster Unified CM d’instance dédiée est mis à jour avec l’ESN.

Au cours de l'événement de survivabilité, le nœud de survivabilité améliorée stocke toutes les données CDR/CMR localement. Lorsque la connectivité est restaurée, les données sont resynchronisées vers le serveur de publication Unified CM de l’instance dédiée. La quantité de données pouvant être stockées est basée sur la taille du disque du nœud de survivabilité amélioré. L'espace d'allocation disque maximum pouvant être défini pour CDR est de 3328 Mo. Cela peut être avec une taille de fichier CDR petite à grande en fonction de l'intervalle CDR qui est configuré. La purge se fait sur la base :

• Lorsque l'utilisation du disque dépasse l'espace disque alloué ou configuré, les enregistrements traités sont supprimés. Si l'utilisation du disque reste supérieure, c'est lorsque les enregistrements non traités sont également purgés.

• High Water Mark % qui est configuré dans les paramètres « CDR Management », les fichiers CDR seront purgés. Par exemple, si le « High Water Mark %” is configured as 80% et l'utilisation du disque est de 80 % alors les fichiers CDR seront purgés.

• Durée de conservation des fichiers CDR / CMR (jours) qui est configurée dans les paramètres « Gestion CDR », les fichiers CDR seront purgés. Par défaut, il est défini sur 30 jours.

Voici les alertes dans RTMT relatives au nœud de survivabilité améliorée :

• SurvivabilityEvent- l'alarme est déclenchée lorsque tous les nœuds d'instance dédiée ne sont pas accessibles à partir du nœud de survivabilité améliorée.

• RemoteSurvivableNodeNotReachable - l'alarme est déclenchée lorsqu'un nœud de survivabilité améliorée n'est pas accessible à partir de l'éditeur Unified CM d'instance dédiée.

Au cours de l'événement de survivabilité, vous devez connecter RTMT au nœud de survivabilité améliorée pour surveiller les performances de l'ESN. Le même ne sera pas disponible, si RTMT est connecté aux nœuds d’instance dédiée car l’ESN ne sera pas accessible à partir du Cloud pendant l’événement de survivabilité.

Pendant le fonctionnement normal, la réplication de la base de données est entièrement maillée entre tous les serveurs, y compris le nœud de survivabilité améliorée au sein du cluster Unified CM. Les données de configuration statiques, parce qu'elles sont créées par des mouvements, des ajouts et des modifications, sont toujours stockées sur l'éditeur et répliquées d'une manière allant de l'éditeur à chaque abonné et à chaque noeud de survivabilité améliorée dans le cluster.

Au cours d'un événement de survivabilité, seules les fonctionnalités destinées à l'utilisateur sont modifiées sur les périphériques enregistrés auprès du nœud de survivabilité améliorée et les fonctionnalités destinées à l'utilisateur sont généralement caractérisées en utilisant le fait que vous pouvez activer ou désactiver une fonctionnalité directement sur leur téléphone en appuyant sur un ou plusieurs boutons, par opposition à la modification d'une fonctionnalité via une interface graphique web. Ainsi, le nœud de survivabilité améliorée permet le self-care et l'interface graphique d'administration Web en tant qu'opérations en lecture seule. Les périphériques de l’utilisateur enregistrés auprès d’ESN peuvent apporter des modifications uniquement aux fonctionnalités en contact avec l’utilisateur listées ci-dessous pendant le basculement. Cependant, ces modifications ne seront pas resynchronisées avec le serveur de publication DI Unified CM lorsque la connectivité sera rétablie.

Les fonctionnalités orientées vers l'utilisateur sont toutes les fonctionnalités qui peuvent être activées ou désactivées en appuyant sur les boutons du téléphone et incluent les éléments suivants :

• Renvoi de tous les appels (CFA)

• Activer ou désactiver la confidentialité

• Activer ou désactiver la fonction Ne pas déranger (NPD)

• Connexion à Cisco Extension Mobility

• Connexion ou déconnexion du groupe de recherche

• Mobilité des périphériques

• Statut CTI CAPF pour les utilisateurs finaux et les utilisateurs de l’application.

L'authentification des clients logiciels (Cisco Jabber et application Webex) pour la connexion pendant le basculement vers le nœud de survivabilité améliorée est la suivante :

1. Authentification locale : Lorsque l’authentification des utilisateurs est effectuée localement dans Unified CM, au cours de l’événement de survivabilité, le nœud de survivabilité améliorée sera en mesure d’authentifier les clients qui y sont enregistrés.

2. Authentification LDAP : Dans ce cas, l'authentification des utilisateurs est effectuée à l'aide du serveur LDAP local. Ensuite, pendant l'événement de survivabilité, l'authentification des clients logiciels fonctionnera à condition que le serveur LDAP soit accessible à partir du nœud de survivabilité améliorée.

   Vous devez vous assurer de l'accessibilité de l'annuaire LDAP à ESN tout au long de l'événement de survivabilité.

3. Authentification unique (SSO) : L'authentification de connexion SSO des utilisateurs est effectuée à l'aide du serveur IDP. Puis, pendant l'événement de survivabilité, l'authentification des clients logiciels fonctionne à condition que le serveur IDP soit accessible à partir du nœud de survivabilité améliorée.

   Pour la connexion à l’interface utilisateur web d’Unified CM avec SSO, l’accessibilité IDP est requise ou la connexion à l’URL basée sur la récupération doit être utilisée.

   Les clients déjà authentifiés continuent d'être connectés car l'authentification est basée sur le jeton obtenu avant l'événement de survivabilité. Cependant, pour les nouvelles connexions lorsque le client ne dispose pas d'un jeton valide de l'authentification précédente, l'ESN redirige vers le serveur IDP pour authentification. Par conséquent, il est toujours nécessaire de garantir l'accessibilité du serveur IDP à ESN tout au long de l'événement de survivabilité.

Les ressources média sont nécessaires pour les fonctionnalités de base d’Unified CM, telles que la musique d’attente, les services d’annonce, de pont de conférence (logiciel) doivent être activés sur l’ESN. Si des ressources média matérielles ont été déployées, au cours de l'événement de survivabilité, vous devez vous assurer que les serveurs média sont accessibles à partir de l'ESN.

Pendant le fonctionnement normal du cluster DI Unified CM, les appels d’urgence (en particulier dans la région AMER) sont acheminés via le Cloud RedSky où il y a un trunk SIP qui est configuré entre le cluster Dedicated Instnace unified CM et le Cloud RedSky.

S’il y a un événement de survivabilité, le Cloud RedSky ne sera pas accessible à partir de l’ESN et il vous est donc nécessaire de configurer le plan de numérotation d’appel d’urgence de sorte que, si RedSky n’est pas disponible, acheminer les appels d’urgence via le GW RTCP local configuré sur ce site. Le groupe de routage doit être composé du GW RTCP local pour gérer le routage des appels au cours de l’événement de survivabilité.

Configurez le plan de numérotation pour le routage des appels intrasite, intersite, inter-cluster et RTCP au cours de l’événement de survivabilité. En général, l’ESN ne peut router les appels que pour les périphériques qui y sont enregistrés. Tous les autres appels doivent être acheminés vers le GW RTCP local (configuré dans chaque site où ESN est déployé) et de là vers le RTCP. Voici quelques scénarios expliqués :

• Téléphone 1 et téléphone 2 enregistrés auprès du même ESN : L'appel est acheminé dans l'ESN.

• Téléphone 1 enregistré auprès d’ESN et téléphone 2 enregistré auprès du cluster Unified CM d’instance dédiée – Le plan de numérotation doit acheminer les appels de l’ESN vers le GW RTCP local, de là vers le DI Unified CM via le RTCP. Au cours de l’événement de survivabilité, le plan de numérotation doit détecter l’échec de routage des appels et réacheminer les appels via le GW RTCP local. Il en va de même pour les appels entrants vers ESN à partir des périphériques DI Unified CM.

• Le téléphone 1 enregistré auprès d’ESN et le téléphone 2 est un périphérique RTCP : Au cours de l’événement de survivabilité, les appels RTCP doivent être acheminés vers la passerelle RTCP locale. Vous devez vous assurer que le plan de numérotation a la capacité de détecter les échecs de routage d’appel et de rediriger l’appel via la passerelle RTCP locale disponible.

• Au cours de l'événement de survivabilité, lorsque la connectivité de votre site vers le Cloud Instance dédiée est en panne (WAN ou panne de connectivité), les fonctionnalités de messagerie vocale et de standard automatique ne fonctionneront pas pour les périphériques qui s'enregistrent auprès de l'ESN, car le serveur Cisco Unity Connection est hébergé dans le Cloud Instance dédiée sur lequel la connectivité de l'ESN est en panne. Si votre périphérique est configuré avec « Transfert d'appel non enregistré (CFU) » et que l'appel est reçu dans DI Unified CM, l'appelant peut déposer une messagerie vocale dans la connexion Unity Instance dédiée. qui peut être récupéré lorsque les périphériques reviennent aux abonnés DI unified CM.

• Cependant, au cours d’un événement de survivabilité lorsque la connectivité au Cloud Instance dédiée est disponible mais que le cluster Unified CM dans DI est en panne, dans ce cas les fonctionnalités de messagerie vocale et de standard automatique fonctionnent pour les périphériques qui sont enregistrés auprès de l’ESN, car ESN disposera d’une connectivité au serveur Unity Connection déployé dans le Cloud DI.

Au cours de l'événement de survivabilité, l'ESN ne pourra pas atteindre Cisco Expressway E & C dans le Cloud DI et vice versa. Ainsi, dans ce cas, les utilisateurs MRA ne peuvent pas obtenir le service d’ESN et ne pourront donc pas s’inscrire. Cependant, si le périphérique MRA a Internet et peut se connecter à Cisco Expressways dans le Cloud DI, alors il peut s'enregistrer auprès de DI Unified CM à condition que le cluster dans DI soit fonctionnel.

Pour que les extensions basées sur CTI fonctionnent avec le nœud de survivabilité amélioré, vous devez ajouter le nœud de survivabilité amélioré dans le cadre de la liste des serveurs CTI. Des améliorations CTI sont effectuées pour les applications qui utilisent JTAPI pour autoriser le nœud de survivabilité améliorée en tant que serveur CTI auquel l'application peut se connecter uniquement dans le cas où les serveurs CTI principaux ou secondaires de la liste configurée ne sont pas accessibles. Pendant un fonctionnement normal, les applications CTI sur site peuvent se connecter aux serveurs CTI principaux et secondaires dans le Cloud DI et pendant l'événement de survivabilité, elles peuvent se connecter avec le nœud de survivabilité améliorée pour une expérience CTI continue. Les applications doivent s'adapter aux nouvelles API exposées sur l'interface JTAPI pour s'assurer que le basculement à partir du nœud de survivabilité améliorée a lieu lorsque la connectivité est restaurée.

Pour plus d’informations sur les nouvelles API ajoutées, reportez-vous à la section redondance, https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/jtapi_dev/14_0_1/cucm_b_cisco-unified-jtapi-developers-guide-14/cucm_b_cisco-unified-jtapi-developers-guide-1251_chapter_00.html

Le service Web AXL est activé dans le nœud de survivabilité améliorée avec les privilèges d'administration en lecture seule. Nous recommandons que toutes les applications tierces telles que le serveur de mise à disposition ne s'interfacent qu'avec le serveur de publication DI Unified CM pour toutes les mises à jour liées à la base de données. Cependant, il est possible pour ces applications de lire uniquement lorsqu'elles sont connectées au nœud de survivabilité améliorée.

Les applications tierces qui s'interfacent via les troncs SIP prennent en charge le nœud de survivabilité améliorée. Dans les configurations du tronc SIP, la configuration « exécuter sur tous les nœuds » doit être activée.

Les périphériques 3e partie sont pris en charge et disposent de la fonctionnalité TFTP tertiaire.