Dans le modèle de déploiement de site unique, où un nœud de survie améliorée (ESN) est déployé au sein d'un site avec une passerelle locale pour le routage des appels PSTN. Un maximum de 7 500 appareils peuvent être enregistrés sur l'ESN lors d'une panne.

Dans le modèle de déploiement multi-sites, où il existe plusieurs sites et où l'ESN peut être déployé sur chaque site, cela dépend des besoins de l'entreprise en matière de survie 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 CM unifié.

Ce modèle de déploiement est pertinent pour un client dans une région comportant plusieurs sites et la capacité de survie est une exigence pour plusieurs de ces sites. Bien qu'il soit possible de partager la passerelle locale PSTN entre plusieurs sites, cela n'est pas recommandé. En cas de panne de réseau, le site peut devenir isolé et dans ce cas, ESN ne pourra pas atteindre la passerelle locale pour acheminer les appels vers le PSTN.

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

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

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

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

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

Pendant l'événement de survie, le nœud de survie améliorée stocke tous les CDR/CMR données localement. Une fois la connectivité rétablie, les données seront resynchronisées avec l'instance dédiée Unified CM Publisher. La quantité de données pouvant être stockée est basée sur la taille du disque du nœud de survie améliorée. L'espace d'allocation de disque maximal pouvant être défini pour CDR est 3328 Mo. Cela peut être avec une taille de fichier CDR petite à grande en fonction de l'intervalle CDR configuré. La purge se produit en fonction de :

• 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, les enregistrements non traités sont également purgés.

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

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

Voici les alertes dans RTMT liées au nœud de survie améliorée :

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

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

Pendant l'événement de survie, vous devez connecter RTMT au nœud de survie amélioré pour surveiller les performances de l'ESN. La même chose ne sera pas disponible si RTMT est connecté aux nœuds d'instance dédiée, car l'ESN ne sera pas accessible depuis le cloud pendant l'événement de survie.

En 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 survie améliorée au sein du cluster Unified CM. Les données de configuration statiques, car elles sont créées via des déplacements, des ajouts et des modifications, sont toujours stockées sur l'éditeur et répliquées dans un sens depuis l'éditeur vers chaque abonné et nœud de survie amélioré du cluster.

Lors d'un événement de survie, seules les fonctionnalités destinées à l'utilisateur sont modifiées sur les appareils enregistrés auprès du nœud de survie amélioré et les fonctionnalités destinées à l'utilisateur sont généralement caractérisées par 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 survie amélioré permet l'auto-assistance et l'interface utilisateur graphique d'administration Web en tant qu'opérations en lecture seule. Les appareils des utilisateurs enregistrés auprès d'ESN peuvent apporter des modifications uniquement aux fonctionnalités destinées aux utilisateurs répertoriées ci-dessous lors du basculement. Cependant, ces modifications ne seront pas synchronisées avec l'éditeur DI Unified CM lorsque la connectivité sera rétablie.

Les fonctionnalités destinées à 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 d'appel (CFA)

• Confidentialité Activer ou désactiver

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

• Connexion à Cisco Extension Mobility

• Connexion ou déconnexion du groupe de recherche

• Mobilité des appareils

• Statut CTI CAPF pour les utilisateurs finaux et les utilisateurs d'applications.

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

1. Authentification locale: Lorsque l'authentification des utilisateurs est effectuée localement au sein du CM unifié, pendant l'événement de survie, le nœud de survie amélioré sera en mesure d'authentifier les clients qui y sont enregistrés.

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

   Vous devez garantir l'accessibilité de l'annuaire LDAP à ESN tout au long de l'événement de survie.

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

   Pour la connexion à l'interface utilisateur Web Unified CM activée par SSO, l'accessibilité IDP est requise ou la connexion par 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 survie. Cependant, pour les nouvelles connexions lorsque le client ne dispose pas d'un jeton valide issu de l'authentification précédente, l'ESN redirigera vers le serveur IDP pour l'authentification. Il est donc toujours nécessaire de garantir l'accessibilité du serveur IDP à l'ESN tout au long de l'événement de survie.

Des ressources multimédias sont nécessaires pour les fonctionnalités de base d'Unified CM, telles que la musique d'attente, l'annonce et les services de pont de conférence (logiciel) qui doivent être activés sur l'ESN. Si des ressources multimédias basées sur le matériel ont été déployées, vous devez vous assurer, pendant l'événement de survie, que les serveurs multimédias sont accessibles depuis l'ESN.

Pendant les opérations normales du cluster CM unifié DI, les appels d'urgence (en particulier dans la région AMER) sont acheminés via le cloud RedSky où se trouve une liaison SIP configurée entre le cluster CM unifié d'instance dédiée et le cloud RedSky.

En cas d'événement de survie, le cloud RedSky ne sera pas accessible depuis l'ESN et il est donc nécessaire que vous configuriez le plan de numérotation des appels d'urgence de telle sorte que, si RedSky n'est pas disponible, acheminez les appels d'urgence via le PSTN GW local configuré sur ce site. Le groupe de routage doit être composé de la passerelle PSTN locale pour gérer le routage des appels pendant l'événement de survie.

Configurez le plan de numérotation pour le routage des appels intrasite, intersite, inter-cluster et PSTN pendant l'événement de survie. En général, l'ESN peut acheminer les appels uniquement vers les appareils qui y sont enregistrés. Tous les autres appels doivent être acheminés vers la passerelle PSTN locale (configurée sur chaque site où ESN est déployé) et de là vers le PSTN. Voici quelques scénarios expliqués :

• Téléphone 1 et téléphone 2 enregistrés sur le même ESN – L'appel est acheminé au sein de l'ESN.

• Téléphone 1 enregistré sur ESN et téléphone 2 enregistré sur le cluster Unified CM d'instance dédiée – Le plan de numérotation doit acheminer les appels d'ESN vers la passerelle PSTN locale, de là vers le DI Unified CM via PSTN. Lors de l'événement de survie, le plan de numérotation doit détecter l'échec du routage des appels et réacheminer les appels via la passerelle PSTN locale. La même chose devrait s’appliquer aux appels entrants vers ESN à partir des appareils DI Unified CM.

• Le téléphone 1 est enregistré sur ESN et le téléphone 2 est un appareil PSTN : En cas d'événement de survie, les appels PSTN doivent être acheminés vers la passerelle PSTN locale. Vous devez vous assurer que le plan de numérotation a la capacité de détecter les échecs de routage des appels et de rediriger l'appel via la passerelle PSTN locale disponible.

• Pendant l'événement de survie, lorsque la connectivité de votre site au cloud de l'instance dédiée est interrompue (panne WAN ou de connectivité), les fonctionnalités de messagerie vocale et de standard automatique ne fonctionneront pas pour les appareils qui s'enregistrent sur l'ESN, car le serveur Cisco Unity Connection est hébergé dans le cloud de l'instance dédiée vers lequel la connectivité de l'ESN est interrompue. Si votre appareil est configuré avec « Renvoi d'appel non enregistré (CFU) » et que l'appel est reçu dans DI Unified CM, l'appelant peut alors déposer un message vocal dans l'instance dédiée Unity Connection. Ce qui peut être récupéré lorsque les appareils reviennent aux abonnés DI unified CM.

• Cependant, lors d'un événement de survie lorsque la connectivité au cloud d'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 appareils enregistrés sur l'ESN, car l'ESN aura une connectivité au serveur Unity Connection déployé dans le cloud DI.

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

Pour que les intégrations basées sur CTI fonctionnent avec le nœud de survie amélioré, vous devez ajouter le nœud de survie amélioré dans la liste des serveurs de CTI. Des améliorations CTI sont apportées aux applications qui utilisent JTAPI pour autoriser le nœud de survie amélioré 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. Lors d'un fonctionnement normal, les applications CTI sur site peuvent se connecter aux serveurs CTI principaux et secondaires dans le cloud DI et lors d'un événement de survie, elles peuvent se connecter au nœud de survie amélioré pour une expérience CTI continue. Les applications doivent s'adapter aux nouvelles API exposées sur l'interface JTAPI pour garantir que le repli du nœud de survie amélioré 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

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

Les appareils tiers dotés de la capacité TFTP tertiaire sont pris en charge.