Überlegungen zur Hardware-Bereitstellung

Finden Sie Anweisungen zum Bereitstellen des Zoom Node ZPLS-Moduls auf virtuellen Maschinen unter Verwendung unterstützter Hypervisoren

Diese Seite beschreibt die Bereitstellung des Zoom Node ZPLS-Moduls auf einer virtuellen Maschine unter Verwendung unterstützter Hypervisoren. Sie bietet detaillierte Konfigurationsoptionen, die auf unterschiedliche Hardware-Fähigkeiten zugeschnitten sind und eine optimale Leistung für verschiedene betriebliche Anforderungen gewährleisten.

Unterstützte Hypervisoren

Kunden müssen die Zoom Node-Software auf einer virtuellen Maschine installieren, die auf einem unterstützten Hypervisor ausgeführt wird

Als Zoom Node-Workload muss das ZPLS-Modul auf einer virtuellen Maschine installiert werden, die auf der Zoom Node-Plattform ausgeführt wird, auf einem unterstützten Hypervisor. Weitere Informationen zu Zoom Node als Produkt finden Sie im Anhang.

Kunden können je nach Hardware-Fähigkeiten eine von zwei Konfigurationsoptionen wählen

Das ZPLS-Modul unterstützt zwei Konfigurationen, abhängig von den Hardware-Fähigkeiten der virtuellen Maschine. Diese Fähigkeiten sind unten aufgeführt:

	Konfigurationsoption 1	Konfigurationsoption 2
Hardware-Spezifikationen	8 CPU 16 GB RAM 80 GB HDD	16 CPU 16 GB RAM 80 GB HDD
Gesamtanzahl der Registrierungen	2000	5000
Maximale gleichzeitige Anrufe	240	480
Anrufe pro Sekunde	2	4
Registrierungen pro Sekunde	60	400

Wenn die Anzahl der Endpunkte innerhalb eines Standorts mit aktivierter Survivability die Bereitstellungskapazitäten des Standorts überschreitet, verarbeitet das ZPLS-Modul Registrierungen nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“. Kunden wird empfohlen, zusätzliche Module hinzuzufügen oder die Zoom Phone Richtlinieneinstellung Lokaler Survivability-Modus zu verwenden, um zu priorisieren, welche Benutzer Failover für Survivability unterstützen.

Modulskalierung und Resilienz

ZPLS-Module unterstützen Clustering für zusätzliche Skalierung und/oder Resilienz

Kunden können ZPLS-Module zusammenfassen, mit bis zu 20 Modulen pro Standort (oder insgesamt 100 Node-Geräte pro Konto), für zusätzliche Redundanz oder Skalierung.

Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden.

Skalierung erhöht die unterstützte Gerätekapazität eines Standorts

Durch die Erweiterung der Anzahl der ZPLS-Module werden die Fähigkeiten jedes Standorts linear für jedes zusätzliche Modul verbessert. Wenn beispielsweise ein Modul insgesamt 5.000 Registrierungen unterstützt, erhöht der Einsatz von fünf Modulen den Support auf 25.000 Registrierungen.

Redundanz fügt zusätzliche Module für Resilienz hinzu, skaliert jedoch nicht die Gerätekapazität eines Standorts

Wenn ein ZPLS-Modul für Redundanzzwecke eingesetzt wird, tragen die redundanten Module nicht zur Gesamtzahl der unterstützten Durchwahlen bei. Stattdessen befinden sich die Module auf „Hot Standby“ und werden nur aktiviert, wenn primäre Module ausfallen. Beispielsweise unterstützen ein primäres und ein redundantes Modul insgesamt 5.000 Registrierungen, sodass das redundante Modul im Falle eines Ausfalls des primären Moduls nicht mit Geräten über seinen unterstützten Grenzwert hinaus überlastet wird.

Beispiel für die Bereitstellung von ZPLS mit Skalierung und Redundanz

Der Einfachheit halber zeigt das folgende Beispiel die Bereitstellung mit zusätzlicher Skalierung und Redundanz.

Beispiel:

Ein Krankenhaus muss bis zu 10.000 registrierte Durchwahlen für Survivability unterstützen. Um dies zu erreichen, stellt das Krankenhaus vier ZPLS-Module bereit.

Die ersten beiden Module können jeweils 5.000 Registrierungen unterstützen, was zu einer Gesamtkapazität von bis zu 10.000 Registrierungen führt. In Anbetracht der Bedeutung der Resilienz stellt das Krankenhaus jedoch auch zwei zusätzliche Module als redundante Sicherungen für die primären Module bereit.

In diesem Szenario verfügt das Krankenhaus nun über primäre und sekundäre Survivability-Hardware. Falls nun ein primäres Modul ausfällt, übernehmen die redundanten Module, um einen unterbrechungsfreien Dienst aufrechtzuerhalten, während sie weiterhin bis zu 10.000 registrierte Geräte unterstützen.

Überlegungen zum Standortdesign

Standorte gruppieren Zoom Phone-Benutzer nach Standort für gemeinsame Telefonie-Einstellungen und Richtlinien

A Standort ist ein spezifischer Begriff, der innerhalb von Zoom Phone verwendet wird und Benutzer mit gemeinsamen Eigenschaften – wie ein gemeinsamer Zugangscode, eine Adresse, SIP-Zone, Abteilung oder Richtlinien – in einer einzigen, verwaltbaren Gruppe im Zoom-Webportal zusammenfasst. Für einige Kunden kann ein einzelner Standort alle Benutzer innerhalb ihres Business repräsentieren und sich über mehrere Gebäude innerhalb eines Campus oder Standorts erstrecken; für andere können je nach Business-Anforderungen mehrere Standorte erforderlich sein. Weitere Informationen zu Standorten oder Standortverwaltung finden Sie im Support-Center von Zoom.

Zoom Phone unterstützt Einzelstandort- und Mehrere Standorte-Designs

Es gibt zwei primäre Designs für die Konfiguration von Zoom Phone Standorten innerhalb eines Kontos:

1. Einzelstandort: Repräsentiert alle Benutzer innerhalb eines Kontos, potenziell über mehrere Gebäude oder Standorte hinweg, innerhalb eines einzigen Zoom Phone-Standorts.

2. Mehrere Standorte: Repräsentiert Benutzersegmente nach Standort, Gebäude, Abteilung oder Funktion getrennt, jeweils mit eigenem Standort.

Kontoadministratoren aktueller Zoom-Kunden können ihr aktuelles Standortdesign über die Unternehmensinformationen Seite prüfen, verfügbar im Telefonsystem-Verwaltung Menü im Webportal.

Jedes ZPLS-Modul kann jeweils nur einem Standort zugeordnet werden

Wie bereits erwähnt, ist ein ZPLS-Modul der Registrar mit dritter Priorität für unterstützte Geräte, hinter primären und sekundären SIP-Zonen. Da Geräte ihre SRV-Listen während des Startvorgangs erhalten und diese Listen an die Einstellungen ihres Standorts gebunden sind, kann jedes ZPLS-Modul jeweils nur einem Standort zugeordnet werden.

Jeder Standort kann gleichzeitig bis zu 20 ZPLS-Module unterstützen

Obwohl jedes ZPLS-Modul jeweils nur einem Standort zugeordnet werden kann, kann ein Standort bis zu 20 ZPLS-Module in einer Gruppe unterstützen, wodurch die Survivability-Fähigkeiten jedes Standorts erweitert werden.

Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden.

ZPLS-Module unterstützen standortübergreifende Anrufe, wenn die Module mit einem gemeinsamen Netzwerk verbunden sind

ZPLS-Module aus verschiedenen Standorten unterstützen während eines Survivability-Ereignisses standortübergreifende Anrufe, solange die Geräte im lokalen Netzwerk erkennbar sind. Wenn beispielsweise ein Business-Campus drei Gebäude hat, jedes mit eigenem Telefonie-Standort, können die ZPLS-Module jedes Standorts Standort-zu-Standort-Anrufe über das Campus-Netzwerk herstellen.

Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden.

Vor der Bereitstellung von ZPLS sollten Konten verstehen, welche Standortkonfiguration am besten für ihre Anforderungen geeignet ist

Da jedes ZPLS-Modul jeweils nur einem Standort zugeordnet werden kann, ist das Standortdesign einer der wichtigsten Faktoren bei der Bereitstellung des ZPLS-Dienstes innerhalb eines Kontos. Aus diesem Grund sollten Kunden verstehen, welche Standortkonfiguration am besten geeignet ist, um ihre praktischen Business- und Survivability-Anforderungen zu erfüllen, da für jeden zusätzlichen für Survivability aktivierten Standort mindestens ein zusätzliches ZPLS-Modul erforderlich ist.

Ein Einzelstandort-Design ist einfacher zu verwalten und bietet Survivability mit einem einzigen ZPLS-Modul, bietet jedoch weniger Flexibilität für Benutzereinstellungen und Richtlinien

Ein Einzelstandort-Design trägt dazu bei, die Verwaltung von Zoom Phone-Einstellungen und Richtlinien zu vereinfachen, indem alle Benutzer innerhalb eines Kontos in einer einzigen, einheitlichen Gruppe zusammengefasst werden. Diese einzelne Benutzergruppe bietet Unternehmen eine unkomplizierte Verwaltung und geringere Komplexität, wodurch der Verwaltungsprozess vereinfacht wird. Darüber hinaus kann ein Einzelstandort-Design lokale Telefonie-Survivability mit einem einzigen ZPLS-Modul bieten, solange die Benutzer des Standorts die Fähigkeiten eines Einzelmoduls.

nicht überschreiten. Allerdings bringt die Einfachheit eines Einzelstandort-Designs naturgemäß auch Einschränkungen mit sich. Insbesondere bieten Einzelstandort-Designs aufgrund ihres „One-Size-Fits-All“-Charakters weniger Flexibilität, was möglicherweise nicht für alle Bereitstellungsszenarien über mehrere Abteilungen mit unterschiedlichen Anforderungen hinweg geeignet ist. Darüber hinaus können Einzelstandort-Bereitstellungen in bestimmten Survivability-Szenarien anfällig sein, wenn das lokale Netzwerk ausfällt.

Ein Mehrere Standorte-Design bietet mehr Flexibilität für Benutzereinstellungen und Richtlinien, erfordert jedoch ein ZPLS-Modul für jeden für Survivability aktivierten Standort und ist komplizierter zu verwalten

Ein Mehrere Standorte-Design bietet Unternehmen zusätzliche Flexibilität bei Benutzereinstellungen und Richtlinien, indem Benutzer in verschiedene Gruppen mit granularen Einstellungssteuerungen unterteilt werden. Dieses Design ermöglicht es Organisationen, Kommunikationskonfigurationen detailliert an spezifische Anforderungen über verschiedene Standorte hinweg anzupassen, was zu einer feineren und anpassungsfähigeren Benutzererfahrung für verschiedene Abteilungen, Szenarien oder Anforderungen führt. Darüber hinaus können Mehrere Standorte-Bereitstellungen standortübergreifende Kommunikation unterstützen, wenn die Standorte über ein gemeinsames Netzwerk verbunden sind.

Die Verwaltung eines Mehrere Standorte-Designs erfordert jedoch sorgfältige Aufmerksamkeit für die Besonderheiten der einzelnen Standortanforderungen, was einen höheren administrativen Aufwand erfordern kann. Darüber hinaus benötigt jeder für Survivability aktivierte Standort, da jedes ZPLS-Modul jeweils nur einem Standort zugewiesen werden kann, ein ZPLS-Modul und eine Lizenz, was zu einem ressourcenintensiveren Setup beitragen kann.

In einem Mehrere Standorte-Design haben Kunden die Flexibilität zu wählen, welche Standorte für Survivability konfiguriert werden. Standorte ohne ein ZPLS-Modul können weiterhin keine Anrufe tätigen oder empfangen, bis die Standardkonnektivität wiederhergestellt ist.

Netzwerkausfälle

Survivability kann beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt

Obwohl ZPLS-Module darauf ausgelegt sind, lokale Telefonie-Survivability während dienstbeeinträchtigender Ereignisse bereitzustellen, kann Survivability beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt. Diese Szenarien werden in den folgenden zwei Abschnitten beschrieben.

Lokaler Netzwerkausfall an einem Einzelstandort

In einem Einzelstandort-Design sind ein oder mehrere Gebäude über ein lokales oder Campus-Netzwerk verbunden und werden innerhalb von Zoom Phone durch einen einzigen Standort repräsentiert. Diese Konfiguration setzt ein gemeinsames Netzwerk zwischen allen Benutzern und Gebäuden innerhalb eines Standorts voraus, ohne externe Netzwerkabhängigkeiten (z. B. das Internet) für die Kommunikation zwischen Gebäuden.

Mit diesem Standortdesign kann ein Business allen Benutzern innerhalb eines einzelnen Standorts oder Standorts lokale Survivability mit nur einem ZPLS-Modul bereitstellen; dieses Design ist jedoch anfällig bei einem lokalen oder Campus-Netzwerkausfall, der die Kommunikation zwischen Gebäuden beeinträchtigt. Das folgende Beispiel beschreibt, wie sich ein lokaler Netzausfall auf eine Einzelstandort-Bereitstellung auswirken kann.

Beispiel:

Ein Unternehmen stellt das ZPLS-Modul für einen einzelnen Zoom Phone-Standort bereit, der aus den Gebäuden A, B und C besteht, die über ein Campus-Netzwerk verbunden sind. Das ZPLS-Modul läuft in Gebäude A und ist nicht mit einem SBC für externe Anrufe über das PSTN verbunden.

Im Falle eines Ausfalls des externen Internetdienstes oder eines dienstbeeinträchtigenden Ereignisses kann jeder Benutzer innerhalb des Standorts einen anderen Benutzer innerhalb desselben gleichen Standorts anrufen, solange beide Benutzer über das Campus-Netzwerk eine Verbindung zum ZPLS-Modul aufrechterhalten.

Im Falle eines Ausfalls des Campus-Netzwerks können Benutzer in den Gebäuden B und C jedoch keine Anrufe tätigen, während das ZPLS-Modul in Gebäude A nicht erreichbar ist. Folglich müssen Benutzer in den Gebäuden B und C warten, bis das Campus-Netzwerk für Survivability-Anrufe wiederhergestellt ist.

Die folgende Tabelle zeigt die Survivability von Zoom Phone in einem Einzelstandort-Design mit mehreren Gebäuden:

Anrufe, die von Gebäude ausgehen	Können diese Standorte während eines Ausfalls des externen Internets erreichen	Können diese Standorte während eines Ausfalls des Campus-Netzwerks erreichen
Gebäude A (ZPLS-Host)	☑️Gebäude A, B und C	☑️ Gebäude A nur
Gebäude B	☑️Gebäude A, B und C	✖️
Gebäude C	☑️Gebäude A, B und C	✖️

Lokaler Netzausfall an mehreren Standorten ohne SBC

In einem Mehrere Standorte-Design wird jedes Gebäude oder jeder Standort (z. B. Etage, Außenstelle usw.) unabhängig durch einen eindeutigen Standort innerhalb von Zoom Phone dargestellt. Diese Konfiguration setzt voraus, dass jeder Standort über ein ZPLS-Modul verfügt und dass die Standorte über ein gemeinsames Campus-Netzwerk verbunden sind.

Mit diesem Standortdesign unterstützt jeder Standort sein eigenes ZPLS-Modul, sodass Benutzer innerhalb desselben Gebäudes sich gegenseitig anrufen können, wenn der Survivability-Modus aktiviert ist. Wenn darüber hinaus mehrere Standorte mit einem ZPLS-Modul über ein gemeinsames Netzwerk verbunden sind, können Benutzer Benutzer an _anderen_ Standorten anrufen, solange das lokale Netzwerk betriebsbereit bleibt. Dieses Design ist jedoch anfällig bei einem Ausfall des Campus-Netzwerks, der die Kommunikation zwischen Gebäuden beeinträchtigt. Das folgende Beispiel beschreibt, wie sich ein Ausfall des Campus-Netzwerks auf eine Mehrere Standorte-Bereitstellung auswirken kann.

Beispiel:

Ein Unternehmen stellt das ZPLS-Modul innerhalb seines Campus mit mehreren Gebäuden bereit, bestehend aus den Gebäuden A, B und C. Jedes Gebäude ist ein eindeutiger Standort innerhalb von Zoom Phone und verfügt über ein standortspezifisches ZPLS-Modul. Alle Gebäude innerhalb des Campus sind über ein Campus-Netzwerk verbunden, das für die Kommunikation zwischen Gebäuden nicht von externem Internetdienst abhängt.

In diesem Beispiel kann im Falle eines Ausfalls des externen Internetdienstes, eines Ausfalls des Campus-Netzwerks oder eines dienstbeeinträchtigenden Ereignisses jeder Benutzer innerhalb eines Standorts einen anderen Benutzer innerhalb desselben Standorts anrufen. Da jedoch jedes Gebäude ein eindeutiger Standort ist und Benutzer sich bei ihren standortspezifischen Modulen registrieren, können die ZPLS-Module bei einem Ausfall des Campus-Netzwerks keine standortübergreifenden Anrufe transportieren. Stattdessen können Benutzer nur Anrufe an andere Benutzer innerhalb ihres lokalen Standorts tätigen.

Die folgende Tabelle zeigt die Survivability von Zoom Phone aus dem obigen Beispiel in einem Mehrere Standorte-Design mit einem verbundenen Campus-Netzwerk:

Anrufe, die von Gebäude ausgehen	Können diese Standorte während eines Ausfalls des externen Internets erreichen	Können diese Standorte während eines Ausfalls des Campus-Netzwerks erreichen
Gebäude A (ZPLS-Host)	☑️ Gebäude A, B und C	☑️ Gebäude A
Gebäude B (ZPLS-Host)	☑️ Gebäude A, B und C	☑️ Gebäude B
Gebäude C (ZPLS-Host)	☑️ Gebäude A, B und C	☑️ Gebäude C

Wenn ein lokales Netzwerk ausfällt, werden standortübergreifende Anrufe auch über das PSTN unterstützt, sofern jeder Standort mit einem SBC verbunden ist und die Anrufweiterleitung aktiviert ist

Im Falle eines lokalen Netzwerkausfalls können Kunden mit einem Mehrere Standorte-Design, das das ZPLS-Modul mit einem SBC und PSTN-Konnektivität an jedem Standort integriert, Standort-zu-Standort-Anrufe aktivieren, wenn die Anrufweiterleitung aktiviert ist. Wenn konfiguriert, werden während des Survivability-Modus getätigte Anrufe vom Client des Benutzers an das PSTN, zum SBC und ZPLS-Modul des zweiten Standorts weitergeleitet und erreichen schließlich das Gerät des Anrufempfängers. Das folgende Diagramm bietet einen Überblick über diese Konfiguration:

Diese Konfiguration erfordert die Verarbeitung von E.164-Telefonnummern auf den konfigurierten SBCs.

Die folgende Tabelle zeigt außerdem die Survivability von Zoom Phone in einem Mehrere Standorte-Design mit unabhängigen SBCs:

Anrufe, die von Gebäude ausgehen	Können diese Standorte während eines Ausfalls des externen Internets erreichen	Können diese Standorte während eines Ausfalls des Campus-Netzwerks erreichen
Gebäude A (ZPLS-Host)	☑️Gebäude A, B und C	☑️Gebäude A, B und C
Gebäude B (ZPLS-Host)	☑️Gebäude A, B und C	☑️Gebäude A, B und C
Gebäude C (ZPLS-Host)	☑️Gebäude A, B und C	☑️Gebäude A, B und C

Mobile Benutzer registrieren sich immer bei dem ZPLS-Modul, das ihrem Heimatstandort zugeordnet ist

Wenn Benutzer oder Geräte zu Zoom Phone hinzugefügt werden, wird ein „Heimat“-Standort statisch mit dem Benutzer oder Gerät verknüpft, bis dies von einem Kontoadministrator aktualisiert wird. Das bedeutet, dass Zoom den an den Benutzer gebundenen Standort nicht dynamisch anpasst, wenn sich ein Benutzer an einen physischen Standort außerhalb seines zugeordneten Heimatstandorts bewegt, z. B. in ein Bürogebäude, das mit einem anderen Standort verbunden ist. Folglich versucht der Benutzer, sich beim ZPLS-Modul zu registrieren, das mit seinem Heimatstandort verbunden ist, selbst wenn er sich an einem anderen Ort befindet, falls die Verbindung zu den Zoom Phone-Rechenzentren verloren geht.

Beispiel:

Ein Benutzer in einem Mehrere Standorte-Campus befindet sich in Gebäude A (Standort A) und wechselt vorübergehend für ein Meeting nach Gebäude B (Standort B). Während er sich in Gebäude B befindet, tritt ein dienstbeeinträchtigendes Ereignis ein, und der Survivability-Modus wird aktiviert. Obwohl sich der Benutzer in Gebäude B befindet, versucht der Client des Benutzers, da Standort A der Heimatstandort ist, eine Verbindung zu dem am Heimatstandort im Gebäude A bereitgestellten ZPLS-Modul herzustellen.

In diesem Szenario wird der Survivability-Status eines Benutzers durch die Fähigkeit des Benutzergeräts bestimmt, sich über das Campus-Netzwerk beim ZPLS-Modul innerhalb seines Heimatstandorts zu registrieren. Wenn das Campus-Netzwerk ausfällt, während sich der Benutzer außerhalb seines Heimatstandorts befindet, kann der Benutzer nicht vom Survivability-Modul profitieren.