Im Single Site-Bereitstellungsmodell, bei dem ein Enhanced Survivability Node (ESN) zusammen mit einem lokalen Gateway für die PSTN-Anrufweiterleitung innerhalb eines Standorts bereitgestellt wird. Während eines Ausfalls können maximal 7500 Geräte beim ESN registriert sein.

Beim Bereitstellungsmodell mit mehreren Standorten, bei dem es mehrere Standorte gibt und an jedem Standort ESN bereitgestellt werden kann, hängt dies von den geschäftlichen Anforderungen an die Überlebensfähigkeit des Standorts ab. Die Anforderungen eines lokalen Gateways und DNS sind immer erforderlich und einem Unified CM-Cluster können insgesamt 8 ESN-Knoten hinzugefügt werden.

Dieses Bereitstellungsmodell ist für einen Kunden in einer Region mit mehreren Standorten relevant, und die Überlebensfähigkeit mehrerer dieser Standorte ist eine Voraussetzung. Obwohl es möglich ist, das lokale PSTN-Gateway standortübergreifend zu nutzen, wird dies nicht empfohlen. Bei einem Netzwerkausfall kann der Standort isoliert werden und in diesem Fall kann ESN das lokale Gateway nicht erreichen, um die Anrufe an das PSTN weiterzuleiten.

Nachfolgend finden Sie zwei Bereitstellungsoptionen für eine Bereitstellung an mehreren Standorten:

• Option 1: An jedem Standort wird ein Knoten für verbesserte Überlebensfähigkeit bereitgestellt.

• Option 2 – Gemeinsamer Knoten mit verbesserter Überlebensfähigkeit, der von mehreren Standorten gemeinsam genutzt wird.

Wir überwachen und verwalten den Enhanced Survivability Node wie andere Knoten, die im Dedicated Instance-Rechenzentrum bereitgestellt werden. Wenn während eines Überlebensereignisses die Verbindung des ESN zur Cisco Cloud getrennt wird, verlieren wir den Zugriff auf den Knoten und stellen automatisch die Verbindung wieder her, wenn der Ausfall behoben und die Konnektivität wiederhergestellt ist.

Wir verwalten die UC-Anwendungszertifikate und haben während der Aktivierung des Enhanced Survivability Node das Dedicated Instance Unified CM-Clusterzertifikat mit der ESN aktualisiert.

Während des Überlebensereignisses speichert der Enhanced Survivability Node alle CDR/CMR Daten lokal. Wenn die Verbindung wiederhergestellt ist, werden die Daten wieder mit dem Dedicated Instance Unified CM Publisher synchronisiert. Die Menge der Daten, die gespeichert werden kann, hängt von der Festplattengröße des jeweiligen Enhanced Survivability Node ab. Der maximale Speicherplatz, der für CDR festgelegt werden kann, beträgt 3328 MB. Dies kann bei kleinen bis großen CDR-Dateigrößen der Fall sein, abhängig vom konfigurierten CDR-Intervall. Die Bereinigung erfolgt auf Grundlage von:

• Wenn die Festplattennutzung den zugewiesenen oder konfigurierten Speicherplatz überschreitet, werden die verarbeiteten Datensätze gelöscht. Wenn die Datenträgernutzung weiterhin höher ist, werden auch die nicht verarbeiteten Datensätze gelöscht.

• Hochwassermarke %, das in den Einstellungen „CDR-Verwaltung“ konfiguriert ist, werden die CDR-Dateien gelöscht. Wenn beispielsweise die „High Water Mark %” is configured as 80% “ erreicht ist und die Festplattennutzung 80 % beträgt, werden die CDR-Dateien gelöscht.

• CDR / Aufbewahrungsdauer (Tage) der CMR-Dateien, die in den „CDR-Verwaltung“-Einstellungen konfiguriert ist. Die CDR-Dateien werden gelöscht. Standardmäßig ist es auf 30 Tage eingestellt.

Nachfolgend sind die Warnungen in RTMT aufgeführt, die sich auf den Knoten „Enhanced Survivability“ beziehen:

• SurvivabilityEvent– der Alarm wird ausgelöst, wenn keiner der Dedicated Instance-Knoten vom Enhanced Survivability Node aus erreichbar ist.

• RemoteSurvivableNodeNotReachable – der Alarm wird ausgelöst, wenn ein Enhanced Survivability Node vom Dedicated Instance Unified CM-Publisher nicht erreichbar ist.

Während des Überlebensereignisses müssen Sie RTMT mit dem Enhanced Survivability Node verbinden, um die Leistung des ESN zu überwachen. Dasselbe ist nicht verfügbar, wenn RTMT mit den Dedicated Instance-Knoten verbunden ist, da die ESN während des Überlebensereignisses nicht von der Cloud aus erreichbar ist.

Während des Normalbetriebs ist die Datenbankreplikation zwischen allen Servern, einschließlich des Enhanced Survivability Node innerhalb des Unified CM-Clusters, vollständig vernetzt. Da die statischen Konfigurationsdaten durch Verschieben, Hinzufügen und Ändern erstellt werden, werden sie immer auf dem Herausgeber gespeichert und vom Herausgeber auf eine Weise zu jedem Abonnenten und Knoten mit verbesserter Überlebensfähigkeit im Cluster repliziert.

Während eines Überlebensereignisses werden auf den Geräten, die beim Enhanced Survivability Node registriert sind, nur die benutzerorientierten Funktionen geändert. Die benutzerorientierten Funktionen zeichnen sich normalerweise dadurch aus, dass Sie eine Funktion direkt auf Ihrem Telefon aktivieren oder deaktivieren können, indem Sie eine oder mehrere Tasten drücken, anstatt eine Funktion über eine webbasierte GUI zu ändern. Der Enhanced Survivability Node ermöglicht daher Selbstpflege und die Webadministrator-GUI als schreibgeschützte Vorgänge. Auf den bei ESN registrierten Geräten des Benutzers können während des Failovers nur Änderungen an den unten aufgeführten, benutzerorientierten Funktionen vorgenommen werden. Diese Änderungen werden jedoch nicht mit dem DI Unified CM-Publisher synchronisiert, wenn die Verbindung wiederhergestellt wird.

Benutzerorientierte Funktionen sind alle Funktionen, die durch Drücken von Tasten auf dem Telefon aktiviert oder deaktiviert werden können. Dazu gehören die folgenden:

• Alle Anrufe weiterleiten (CFA)

• Datenschutz aktivieren oder deaktivieren

• Nicht stören (DND) aktivieren oder deaktivieren

• Cisco Extension Mobility-Anmeldung

• An- und Abmelden bei Sammelanschlussgruppen

• Gerätemobilität

• CTI CAPF-Status für Endbenutzer und Anwendungsbenutzer.

Die Authentifizierung von Softclients (Cisco Jabber und Webex-Anwendung) für die Anmeldung während des Failovers zum Enhanced Survivability Node erfolgt wie folgt:

1. Lokale Authentifizierung: Wenn die Authentifizierung der Benutzer lokal innerhalb des Unified CM erfolgt, kann der Enhanced Survivability Node während des Survivability-Ereignisses die bei ihm registrierten Clients authentifizieren.

2. LDAP-Authentifizierung: In diesem Fall erfolgt die Authentifizierung der Benutzer über den lokalen LDAP-Server. Während des Survivability-Ereignisses funktioniert dann die Authentifizierung von Softclients, vorausgesetzt, der LDAP-Server ist vom Enhanced Survivability Node aus erreichbar.

   Sie sollten die Erreichbarkeit des LDAP-Verzeichnisses für ESN während des gesamten Überlebensereignisses sicherstellen.

3. Single Sign On (SSO)-Authentifizierung: Die SSO-Login-Authentifizierung der Benutzer erfolgt über den IDP-Server. Während des Überlebensereignisses funktioniert die Authentifizierung von Softclients, sofern der IDP-Server vom Enhanced Survivability Node aus erreichbar ist.

   Für die SSO-fähige Unified CM-Web-UI-Anmeldung ist die IDP-Erreichbarkeit erforderlich oder es muss die wiederherstellungsbasierte URL-Anmeldung verwendet werden.

   Bereits authentifizierte Clients bleiben weiterhin angemeldet, da die Authentifizierung auf dem Token basiert, das vor dem Überlebensereignis abgerufen wurde. Bei neuen Anmeldungen leitet die ESN den Client jedoch zur Authentifizierung an den IDP-Server weiter, wenn er nicht über ein gültiges Token aus einer vorherigen Authentifizierung verfügt. Daher muss während des gesamten Überlebensereignisses stets sichergestellt werden, dass der IDP-Server für ESN erreichbar ist.

Für grundlegende Unified CM-Funktionen wie Wartemusik, Ansagen und Konferenzbrücken (Software) sind Medienressourcen erforderlich. Die Dienste müssen auf dem ESN aktiviert sein. Wenn hardwarebasierte Medienressourcen bereitgestellt wurden, müssen Sie während des Überlebensereignisses sicherstellen, dass die Medienserver vom ESN aus erreichbar sind.

Während des normalen Betriebs des DI Unified CM-Clusters werden die Notrufe (insbesondere in der AMER-Region) über die RedSky-Cloud geleitet, wo ein SIP-Trunk vorhanden ist, der zwischen dem Dedicated Instance Unified CM-Cluster und der RedSky-Cloud konfiguriert ist.

Wenn ein Überlebensereignis eintritt, ist die RedSky-Cloud vom ESN aus nicht erreichbar. Daher müssen Sie den Wählplan für Notrufe so konfigurieren, dass die Notrufe über das an diesem Standort konfigurierte lokale PSTN-GW geleitet werden, wenn RedSky nicht verfügbar ist. Die Routengruppe muss aus dem lokalen PSTN-GW bestehen, um die Anrufweiterleitung während des Survivability-Ereignisses zu handhaben.

Konfigurieren Sie den Wählplan für die Weiterleitung von Anrufen innerhalb des Standorts, zwischen Standorten, zwischen Clustern und über das öffentliche Telefonnetz während des Survivability-Ereignisses. Im Allgemeinen kann das ESN nur Anrufe für Geräte weiterleiten, die bei ihm registriert sind. Alle anderen Anrufe müssen an das lokale PSTN-GW (an jedem Standort konfiguriert, an dem ESN bereitgestellt wird) und von dort an das PSTN weitergeleitet werden. Im Folgenden werden einige Szenarien erläutert:

• Telefon 1 und Telefon 2 sind bei derselben ESN registriert – Der Anruf wird innerhalb der ESN weitergeleitet.

• Telefon 1 ist bei ESN registriert und Telefon 2 ist beim Dedicated Instance Unified CM-Cluster registriert – Der Wählplan sollte die Anrufe von ESN zum lokalen PSTN GW und von dort über PSTN zum DI Unified CM weiterleiten. Während des Überlebensereignisses sollte der Wählplan den Anrufweiterleitungsfehler erkennen und die Anrufe über das lokale PSTN-GW umleiten. Dasselbe sollte für eingehende Anrufe an ESN von DI Unified CM-Geräten gelten.

• Telefon 1 ist bei ESN registriert und Telefon 2 ist ein PSTN-Gerät: Während eines Überlebensereignisses müssen PSTN-Anrufe an das lokale PSTN-Gateway weitergeleitet werden. Sie müssen sicherstellen, dass der Wählplan Fehler bei der Anrufweiterleitung erkennen und den Anruf über das verfügbare lokale PSTN-Gateway umleiten kann.

• Wenn während des Überlebensereignisses die Verbindung von Ihrer Site zur Dedicated Instance-Cloud unterbrochen ist (WAN- oder Konnektivitätsausfall), funktionieren die Voicemail- und automatischen Vermittlungsfunktionen für die beim ESN registrierten Geräte nicht, da der Cisco Unity Connection-Server in der Dedicated Instance-Cloud gehostet wird, zu der die Verbindung vom ESN unterbrochen ist. Wenn Ihr Gerät mit „Call Forward Unregistered (CFU)“ konfiguriert ist und der Anruf in DI Unified CM eingeht, kann der Anrufer eine Voicemail in der Dedicated Instance Unity Connection hinterlegen. Diese können abgerufen werden, wenn die Geräte auf DI Unified CM-Abonnenten zurückgreifen.

• Während eines Überlebensereignisses, wenn die Verbindung zur Dedicated Instance-Cloud verfügbar ist, der Unified CM-Cluster in DI jedoch ausgefallen ist, funktionieren in diesem Fall die Voicemail- und Auto-Attendant-Funktionen für Geräte, die beim ESN registriert sind, da das ESN über eine Verbindung zum in der DI-Cloud bereitgestellten Unity Connection-Server verfügt.

Während des Survivability-Ereignisses kann das ESN den Cisco Expressway E nicht erreichen. & C in der DI-Cloud und umgekehrt. In diesem Fall können die MRA-Benutzer den Dienst von ESN nicht erhalten und sich daher nicht registrieren. Wenn das MRA-Gerät jedoch über Internet verfügt und eine Verbindung zu den Cisco Expressways in der DI-Cloud herstellen kann, kann es sich beim DI Unified CM registrieren, sofern der Cluster in DI funktionsfähig ist.

Damit CTI-basierte Integrationen mit Enhanced Survivability Node funktionieren, müssen Sie Enhanced Survivability Node als Teil der CTI-Serverliste hinzufügen. CTI-Erweiterungen werden für Anwendungen vorgenommen, die JTAPI verwenden, um Enhanced Survivability Node als CTI-Server zuzulassen, mit dem sich die Anwendung nur dann verbinden kann, wenn der primäre oder sekundäre CTI-Server in der konfigurierten Liste nicht erreichbar ist. Während eines normalen Betriebs können CTI-Anwendungen vor Ort eine Verbindung mit den primären und sekundären CTI-Servern in der DI-Cloud herstellen und während eines Survivability-Ereignisses eine Verbindung mit dem Enhanced Survivability Node herstellen, um ein kontinuierliches CTI-Erlebnis zu gewährleisten. Anwendungen müssen sich an die neuen APIs anpassen, die über die JTAPI-Schnittstelle bereitgestellt werden, um sicherzustellen, dass beim Wiederherstellen der Konnektivität ein Fallback vom Enhanced Survivability Node erfolgt.

Weitere Informationen zu den neu hinzugefügten APIs finden Sie im Abschnitt „Redundanz“. 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

Anwendungen von Drittanbietern, die über die SIP-Trunks kommunizieren, werden mit Enhanced Survivability Node unterstützt. In den SIP-Trunk-Konfigurationen muss die Konfiguration „auf allen Knoten ausführen“ aktiviert sein.

Es werden Geräte von Drittanbietern unterstützt, die über tertiäre TFTP-Fähigkeit verfügen.