Erste Schritte mit verbesserter Survivability

Im Bereitstellungsmodell für einen Standort, bei dem ein erweiterter Survivability-Knoten (ESN) innerhalb eines Standorts zusammen mit einem lokalen Gateway für die PSTN-Anrufverteilung bereitgestellt wird. Bei einem Ausfall können maximal 7500 Geräte bei der ESN registriert werden.

Im Bereitstellungsmodell für mehrere Standorte hängt es von den Geschäftsanforderungen für die Survivability der Site ab, ob mehrere Standorte vorhanden sind und ESN an jedem Standort bereitgestellt werden kann. Die Anforderungen eines lokalen Gateways und DNS sind immer erforderlich, und es können insgesamt 8 ESN-Knoten zu einem Unified CM-Cluster hinzugefügt werden.

Dieses Bereitstellungsmodell ist für einen Kunden in einer Region mit mehreren Standorten relevant, und die Survivability ist für mehrere dieser Standorte erforderlich. Obwohl es möglich ist, das lokale PSTN-Gateway standortübergreifend zu teilen, wird es nicht empfohlen. Wenn ein Netzwerkausfall vorliegt, kann der Standort isoliert werden, und in diesem Fall kann ESN das lokale Gateway für die Weiterleitung der Anrufe an das PSTN nicht erreichen.

Im Folgenden finden Sie 2 Bereitstellungsoptionen für eine Bereitstellung mit mehreren Standorten:

• Option 1 – : Verbesserter Survivability-Knoten, der an jedem Standort bereitgestellt wird.

• Option 2 – Allgemeiner verbesserter Survivability-Knoten, der zwischen mehreren Sites gemeinsam genutzt wird.

Wir überwachen und verwalten den verbesserten Survivability-Knoten wie andere Knoten, die im Rechenzentrum der dedizierten Instanz bereitgestellt werden. Wenn die ESN während eines Survivability-Ereignisses von der Cisco Cloud getrennt wird, geht der Zugriff auf den Knoten verloren und die Verbindung wird automatisch wieder hergestellt, wenn der Ausfall behoben wird und die Konnektivität wiederhergestellt wird.

Wir verwalten die UC-Anwendungszertifikate und während der Aktivierung des erweiterten Survivability-Knotens wurde das Unified CM-Clusterzertifikat der dedizierten Instanz mit dem ESN aktualisiert.

Während des Survivability-Ereignisses speichert der verbesserte Survivability-Knoten alle CDR-/CMR-Daten lokal. Wenn die Konnektivität wiederhergestellt ist, werden die Daten wieder mit dem Unified CM Publisher der dedizierten Instanz synchronisiert. Die Menge der Daten, die gespeichert werden können, basiert auf der Festplattengröße des erweiterten Survivability-Knotens. Der maximale Festplattenzuweisungsspeicher, der für CDR festgelegt werden kann, beträgt 3328 MB . Dies kann bei kleiner bis großer CDR-Dateigröße basierend auf dem konfigurierten CDR-Intervall sein. Die Bereinigung erfolgt basierend auf:

• Wenn die Festplattennutzung den zugewiesenen oder konfigurierten Festplattenspeicher überschreitet, werden die verarbeiteten Datensätze gelöscht. Wenn die Datenträgerauslastung länger bleiben soll, dann werden auch die unverarbeiteten Datensätze gelöscht.

• High Water Mark % , das in den „CDR Management“-Einstellungen konfiguriert ist, werden die CDR-Dateien gelöscht. Zum Beispiel, wenn die "High Water Mark %” is configured as 80% und die Festplattennutzung 80% dann die CDR-Dateien gelöscht werden.

• Dauer der Aufbewahrung von CDR-/CMR-Dateien (Tage) , die in den „CDR Management“-Einstellungen konfiguriert ist, werden die CDR-Dateien gelöscht. Standardmäßig ist er auf 30 Tage festgelegt.

Im Folgenden finden Sie die Warnungen in RTMT im Zusammenhang mit dem verbesserten Survivability-Knoten:

• SurvivabilityEvent – Der Alarm wird ausgelöst, wenn alle Knoten der dedizierten Instanz über den erweiterten Survivability-Knoten nicht erreichbar sind.

• RemoteSurvivableNodeNotReachable – der Alarm wird ausgelöst, wenn ein verbesserter Survivability-Knoten vom Unified CM Publisher der dedizierten Instanz nicht erreichbar ist.

Während des Survivability-Ereignisses müssen Sie RTMT mit dem verbesserten Survivability-Knoten verbinden, um die Leistung des ESN zu überwachen. Dasselbe ist nicht verfügbar, wenn RTMT mit den Knoten der dedizierten Instanz verbunden ist, da ESN während des Survivability-Ereignisses nicht von der Cloud aus erreichbar ist.

Während des normalen Betriebs ist die Datenbankreplikation vollständig zwischen allen Servern vernetzt, einschließlich des erweiterten Survivability-Knotens innerhalb des Unified CM-Clusters. Die statischen Konfigurationsdaten, da sie durch Verschiebungen, Hinzufügen und Änderungen erstellt werden, werden immer im Publisher gespeichert und auf eine Weise vom Publisher zu jedem Subscriber und erweiterten Survivability-Knoten im Cluster repliziert.

Während eines Survivability-Ereignisses werden nur die benutzerseitigen Funktionen auf den Geräten geändert, die im erweiterten Survivability-Knoten registriert sind. Die benutzerseitigen Funktionen werden normalerweise dadurch gekennzeichnet, dass Sie eine Funktion direkt auf dem Telefon aktivieren oder deaktivieren können, indem Sie eine oder mehrere Tasten drücken, anstatt eine Funktion über eine webbasierte GUI zu ändern. Der verbesserte Survivability-Knoten ermöglicht also Self-Care und Web-Admin-GUI als schreibgeschützte Vorgänge. Die Geräte des Benutzers, die bei ESN registriert sind, können nur Änderungen an den Benutzerfunktionen vornehmen, die unten während des Failovers aufgeführt sind. Diese Änderungen werden jedoch nicht wieder mit dem DI Unified CM Publisher synchronisiert, wenn die Konnektivität wiederhergestellt wird.

Benutzerseitige Funktionen sind alle Funktionen, die durch Drücken von Tasten am Telefon aktiviert oder deaktiviert werden können. Sie umfassen Folgendes:

• Rufumleitung Alle Anrufe (CFA)

• Privatfunktion aktivieren oder deaktivieren

• „Bitte nicht stören“ (Ruhefunktion) aktivieren oder deaktivieren

• Anmeldung zur Cisco Anschlussmobilität

• Anmeldung oder Abmeldung bei Sammelanschlüssen

• Gerätemobilität

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

Die Authentifizierung von Soft Clients (Cisco Jabber und Webex-Anwendung) für die Anmeldung während des Failovers an den Knoten für die verbesserte Survivability erfolgt wie folgt:

1. Lokale Authentifizierung : Wenn die Authentifizierung von Benutzern lokal in Unified CM erfolgt, kann der verbesserte Survivability-Knoten während des Survivability-Ereignisses die dort 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 Soft-Clients, sofern der LDAP-Server über den erweiterten Survivability-Knoten erreichbar ist.

   Sie sollten die Erreichbarkeit des LDAP-Verzeichnisses zu ESN während des gesamten Survivability-Ereignisses sicherstellen.

3. SSO-Authentifizierung (Single Sign On) : Die SSO-Login-Authentifizierung der Benutzer erfolgt über den IDP-Server. Während des Survivability-Ereignisses funktioniert dann die Authentifizierung von Soft-Clients, sofern der IDP-Server über den erweiterten Survivability-Knoten erreichbar ist.

   Für die SSO-aktivierte Unified CM-Webbenutzeroberfläche ist die IDP-Erreichbarkeit erforderlich oder die wiederherstellungsbasierte URL-Anmeldung muss verwendet werden.

   Bereits authentifizierte Clients werden weiterhin angemeldet, da die Authentifizierung auf dem Token basiert, das vor dem Survivability-Ereignis abgerufen wurde. Bei neuen Anmeldungen jedoch, wenn der Client kein gültiges Token aus der vorherigen Authentifizierung hat, leitet das ESN zur Authentifizierung an den IDP-Server weiter. Daher ist es immer notwendig, die Erreichbarkeit des IDP-Servers zu ESN während des gesamten Survivability-Ereignisses sicherzustellen.

Medienressourcen sind für grundlegende Unified CM-Funktionen erforderlich, z. B. Warteschleifenmusik, Ansage, Konferenzbrücke (Software) müssen auf dem ESN aktiviert sein. Wenn Hardwarebasierte Medienressourcen bereitgestellt wurden, müssen Sie während des Survivability-Ereignisses sicherstellen, dass die Medienserver vom ESN aus erreichbar sind.

Bei normalen Vorgängen des DI Unified CM-Clusters werden die Notrufe (insbesondere in der AMER-Region) durch die RedSky-Cloud geleitet, wo ein SIP-Übertragungsweg zwischen dem Unified CM-Cluster der dedizierten Instanz und der RedSky-Cloud konfiguriert ist.

Wenn ein Survivability-Ereignis vorliegt, ist die RedSky-Cloud vom ESN nicht erreichbar. Daher müssen Sie den Wählplan für Notrufe so konfigurieren, dass Notrufe über das an diesem Standort konfigurierte lokale PSTN-GW weitergeleitet werden, wenn RedSky nicht verfügbar ist. Die Routen-Gruppe muss aus dem lokalen PSTN GW bestehen, um das Anruf-Routing während des Survivability-Ereignisses zu verarbeiten.

Konfigurieren Sie den Wählplan für das Routing von Intrasite-, Intersite-, Inter-Cluster- und PSTN-Anrufen während des Survivability-Ereignisses. Im Allgemeinen kann ESN Anrufe nur für Geräte weiterleiten, die dafür registriert sind. Alle anderen Anrufe müssen an das lokale PSTN-GW (konfiguriert an jedem Standort, 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, die bei derselben ESN registriert sind – Der Anruf wird innerhalb der ESN weitergeleitet.

• Telefon 1, das bei ESN registriert ist, und Telefon 2, das beim Unified CM-Cluster der dedizierten Instanz registriert ist – Der Wählplan sollte die Anrufe von ESN an das lokale PSTN GW und von dort über PSTN an das DI Unified CM weiterleiten. Während des Survivability-Ereignisses sollte der Wählplan den Fehler bei der Anrufweiterleitung erkennen und die Anrufe erneut über das lokale PSTN-GW weiterleiten. Das gleiche gilt für eingehende Anrufe an ESN von DI Unified CM-Geräten.

• Telefon 1, das bei ESN registriert ist und Telefon 2 ist ein PSTN-Gerät: Während des Survivability-Ereignisses müssen PSTN-Anrufe an das lokale PSTN-Gateway weitergeleitet werden. Sie müssen sicherstellen, dass der Rufnummernplan über die Möglichkeit verfügt, Anrufweiterleitungsfehler zu erkennen und den Anruf über das verfügbare lokale PSTN-Gateway umzuleiten.

• Wenn während des Survivability-Ereignisses die Konnektivität von Ihrem Standort zur Cloud der dedizierten Instanz ausgefallen ist (WAN oder Konnektivitätsausfall), funktionieren die Voicemail- und Auto Attendant-Funktionen nicht für die Geräte, die beim ESN registriert sind, da der Cisco Unity Connection-Server in der Cloud der dedizierten Instanz gehostet wird, mit der die Konnektivität von ESN ausgefallen ist. Wenn Ihr Gerät mit „Call Forward Unregistered (CFU)“ konfiguriert ist und der Anruf in DI Unified CM empfangen wird, kann der Anrufer eine Voicemail in Dedicated Instance Unity Connection hinterlegen. Die abgerufen werden kann, wenn die Geräte auf DI Unified CM-Subscriber zurückgreifen.

• Während eines Survivability-Ereignisses, wenn die Konnektivität zur Cloud der dedizierten Instanz verfügbar ist, aber der Unified CM-Cluster in DI ausgefallen ist, funktionieren die Voicemail- und Auto Attendant-Funktionen für Geräte, die beim ESN registriert sind, da ESN über eine Konnektivität zum Unity Connection-Server verfügt, der in der DI-Cloud bereitgestellt wird.

Während des Survivability-Ereignisses kann das ESN das Cisco Expressway E & C nicht in der DI-Cloud erreichen und umgekehrt. In diesem Fall können die MRA-Benutzer den Dienst nicht von ESN erhalten und können 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 bei DI Unified CM registrieren, vorausgesetzt, der Cluster in DI ist funktionsfähig.

Damit CTI-basierte Integrationen mit dem verbesserten Survivability-Knoten funktionieren, müssen Sie den verbesserten Survivability-Knoten als Teil der CTI-Serverliste hinzufügen. CTI-Verbesserungen werden für Anwendungen vorgenommen, die JTAPI verwenden, um den verbesserten Survivability-Knoten als CTI-Server zuzulassen, mit dem die Anwendung nur dann eine Verbindung herstellen kann, wenn der primäre oder sekundäre CTI-Server in der konfigurierten Liste nicht erreichbar ist. Während eines normalen Betriebs können sich CTI-Anwendungen vor Ort mit den primären und sekundären CTI-Servern in der DI-Cloud verbinden, und während des Survivability-Ereignisses können sie eine Verbindung mit dem Enhanced Survivability Node herstellen, um eine kontinuierliche CTI-Erfahrung zu ermöglichen. Anwendungen müssen sich an die neuen APIs anpassen, die über die JTAPI-Schnittstelle freigelegt werden, um sicherzustellen, dass der Fallback vom verbesserten Survivability-Knoten stattfindet, wenn die Konnektivität wiederhergestellt wird.

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

AXL Web Service wird im Enhanced Survivability Node mit schreibgeschützten Administratorrechten aktiviert. Wir empfehlen, dass Anwendungen von Drittanbietern, z. B. Bereitstellungsserver, bei datenbankbezogenen Aktualisierungen nur mit dem DI Unified CM Publisher verbunden sind. Es ist jedoch möglich, dass diese Anwendungen schreibgeschützt sind, wenn sie mit dem erweiterten Survivability-Knoten verbunden sind.

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

Geräte von Drittanbietern mit Tertiärer TFTP-Funktion werden unterstützt.