Überlegungen zur Hardwarebereitstellung

Anleitungen zur Bereitstellung des Zoom Node ZPLS-Moduls auf virtuellen Maschinen mit unterstützten Hypervisoren finden Sie hier

Diese Seite beschreibt die Bereitstellung des Zoom Node ZPLS-Moduls auf einer virtuellen Maschine mithilfe unterstützter Hypervisoren. Sie bietet detaillierte Konfigurationsoptionen, die auf unterschiedliche Hardwarefähigkeiten zugeschnitten sind, um für verschiedene Betriebsanforderungen eine optimale Leistung sicherzustellen.

Unterstützte Hypervisor

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 die Zoom Node-Plattform ausführt, auf einem unterstützten Hypervisor. Weitere Informationen zum Produkt Zoom Node finden Sie im Anhang.

Kunden können je nach Hardwarefähigkeiten eine von zwei Konfigurationsoptionen wählen

Das ZPLS-Modul unterstützt zwei Konfigurationen, abhängig von den Hardwarefä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
Gesamtregistrierungen	2000	5000
Maximale gleichzeitige Anrufe	240	480
Anrufe pro Sekunde	2	4
Registrierungen pro Sekunde	45	90

Wenn die Anzahl der Endpunkte an einem für Survivability aktivierten Standort die Bereitstellungsfähigkeiten eines Standorts überschreitet, verarbeitet das ZPLS-Modul Registrierungen nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“. Es wird empfohlen, zusätzliche Module hinzuzufügen oder die Zoom Phone-Richtlinieneinstellung Lokalen Überlebensmodus zu verwenden, um festzulegen, welche Benutzer bei einem Survivability-Failover priorisiert werden sollen.

Modulskalierung und Ausfallsicherheit

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

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

Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket zur Aktivierung.

Skalierung erhöht die unterstützten Gerätefähigkeiten eines Standorts

Die Erweiterung der Anzahl der ZPLS-Module erhöht die Fähigkeiten jedes Standorts linear für jedes zusätzliche Modul. Wenn beispielsweise ein Modul insgesamt 5.000 Registrierungen unterstützt, erweitert die Bereitstellung von fünf Modulen die Unterstützung auf 25.000 Registrierungen.

Redundanz fügt zusätzliche Module zur Ausfallsicherheit hinzu, skaliert jedoch nicht die Gerätefähigkeiten eines Standorts

Wenn ein ZPLS-Modul zu Redundanzzwecken verwendet wird, tragen die redundanten Module nicht zur Gesamtzahl der unterstützten Nebenstellen bei. Stattdessen befinden sich die Module im „Hot-Standby“ und werden nur aktiv, wenn primäre Module ausfallen. Zum Beispiel unterstützen ein primäres und ein redundantes Modul zusammen insgesamt 5.000 Registrierungen; fällt ein primäres Modul aus, wird das redundante Modul nicht mit Geräten über seine unterstützte Grenze hinaus überlastet.

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

Der folgende Beispielvorgang zeigt der Übersicht halber eine Bereitstellung mit zusätzlicher Skalierung und Redundanz.

Beispiel:

Ein Krankenhaus muss bis zu 10.000 registrierte Nebenstellen für die Survivability unterstützen. Um dies zu erreichen, setzt das Krankenhaus vier ZPLS-Module ein.

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. Da jedoch die Ausfallsicherheit wichtig ist, setzt das Krankenhaus außerdem zwei zusätzliche Module als redundante Backups zu den primären Modulen ein.

In diesem Szenario verfügt das Krankenhaus nun über primäre und sekundäre Survivability-Hardware. Tritt ein Ausfall eines primären Moduls auf, übernehmen die redundanten Module, um einen unterbrechungsfreien Dienst aufrechtzuerhalten, während weiterhin bis zu 10.000 registrierte Geräte unterstützt werden.

Überlegungen zum Standortdesign

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

A Standorts ist ein spezifischer Begriff innerhalb von Zoom Phone, der Benutzer mit gemeinsamen Merkmalen – wie einem gemeinsamen Zugangscode, 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 ihres Unternehmens repräsentieren und mehrere Gebäude innerhalb eines Campus oder Standorts umfassen; bei anderen sind je nach Geschäftsanforderungen mehrere Standorte erforderlich. Weitere Informationen zu Standorten oder Standortverwaltung finden Sie im Support-Center von Zoom.

Zoom Phone unterstützt Single-Site- und Multi-Site-Designs

Es gibt zwei Hauptdesigns zur Konfiguration von Zoom Phone-Standorten innerhalb eines Kontos:

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

2. Mehrere Standorte: Repräsentiert Segmente von Benutzern nach Standort, Gebäude, Abteilung oder Funktion getrennt, jeweils mit einem eigenen Standort.

Kontoadministratoren aktueller Zoom-Kunden können ihr aktuelles Standortdesign über die Company Info Seite einsehen, verfügbar im Phone System Management Menü des Webportals.

Jedes ZPLS-Modul kann immer nur einem Standort zugeordnet sein

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 immer nur einem Standort zugeordnet sein.

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

Obwohl jedes ZPLS-Modul immer nur einem Standort zugeordnet sein 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 zur Aktivierung.

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

ZPLS-Module aus verschiedenen Standorten unterstützen standortübergreifende Anrufe während eines Survivability-Ereignisses, sofern die Geräte im lokalen Netzwerk auffindbar sind. Wenn ein Firmencampus beispielsweise drei Gebäude hat, jeweils mit eigenem Telefonstandort, können die ZPLS-Module der einzelnen Standorte standortübergreifende Anrufe über das Campus-Area-Network (CAN) verbinden.

Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket zur Aktivierung.

Vor der Bereitstellung von ZPLS sollten Konten verstehen, welche Standortkonfiguration am besten zu ihren Bedürfnissen passt

Da jedes ZPLS-Modul immer nur einem Standort zugeordnet werden kann, ist das Standortdesign einer der wichtigsten Faktoren bei der Bereitstellung des ZPLS-Dienstes in einem Konto. Aus diesem Grund sollten Kunden verstehen, welches Standortkonfigurationsmodell am besten geeignet ist, um ihre praktischen Geschäfts- und Survivability-Anforderungen zu erfüllen, da jeder zusätzliche Standort, der für Survivability aktiviert wird, mindestens ein zusätzliches ZPLS-Modul erfordert.

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

Ein Einzelstandort-Design hilft, die Verwaltung der Zoom Phone-Einstellungen und -Richtlinien zu vereinfachen, indem alle Benutzer innerhalb eines Kontos unter einer einzigen, einheitlichen Gruppe zusammengefasst werden. Diese einzelne Benutzergruppe bietet Unternehmen eine direkte Verwaltung und reduzierte Komplexität, wodurch der Verwaltungsprozess vereinfacht wird. Zusätzlich kann ein Einzelstandort-Design lokale Telefon-Survivability mit einem einzelnen ZPLS-Modul bieten, sofern die Benutzer des Standorts die Fähigkeiten eines Einzelmoduls nicht überschreiten.

Die Einfachheit eines Einzelstandort-Designs bringt jedoch naturgemäß Einschränkungen mit sich. Insbesondere bieten Einzelstandort-Designs aufgrund ihres „One-Size-Fits-All“-Charakters weniger Flexibilität, was nicht für alle Bereitstellungsszenarien über mehrere Abteilungen mit unterschiedlichen Anforderungen geeignet sein kann. Darüber hinaus können Einzelstandort-Bereitstellungen in bestimmten Überlebensszenarien verwundbar sein, wenn das lokale Netzwerk ausfällt.

Ein Multi-Site-Design bietet mehr Flexibilität bei Benutzereinstellungen und Richtlinien, erfordert jedoch für jeden survivability-aktivierten Standort ein ZPLS-Modul und ist in der Verwaltung komplizierter

Ein Multi-Site-Design bietet Unternehmen zusätzliche Flexibilität bei Benutzereinstellungen und Richtlinien, indem Benutzer in verschiedene Gruppen mit granulären Einstellungskontrollen aufgeteilt werden. Dieses Design ermöglicht es Organisationen, Kommunikationskonfigurationen fein abzustimmen, um spezifische Anforderungen über verschiedene Standorte hinweg zu erfüllen, was zu einer differenzierteren und anpassungsfähigeren Benutzererfahrung für verschiedene Abteilungen, Szenarien oder Anforderungen führt. Darüber hinaus können Multi-Site-Bereitstellungen standortübergreifende Kommunikation unterstützen sofern die Standorte über ein gemeinsames Netzwerk verbunden sind.

Die Verwaltung eines Multi-Site-Designs erfordert jedoch sorgfältige Beachtung der Besonderheiten der Anforderungen jedes Standorts, was einen höheren administrativen Aufwand erforderlich machen kann. Da jedes ZPLS-Modul nur einem Standort zugewiesen werden kann, benötigt jeder für Survivability aktivierte Standort außerdem ein ZPLS-Modul und eine Lizenz, was zu einem ressourcenintensiveren Setup beitragen kann.

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

Netzwerkausfälle

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

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

Lokaler Netzwerkausfall bei 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 einzelnen Standort repräsentiert. Diese Konfiguration geht von einem gemeinsamen Netzwerk zwischen allen Benutzern und Gebäuden an einem Standort aus, ohne externe Netzwerkabhängigkeiten (z. B. das Internet) für die gebäudeübergreifende Kommunikation.

Mit diesem Standortdesign kann ein Unternehmen allen Benutzern innerhalb eines einzelnen Standorts oder Standorts mit nur einem ZPLS-Modul lokale Survivability bieten; dieses Design ist jedoch anfällig für Ausfälle des lokalen oder Campus-Netzwerks, die die gebäudeübergreifende Kommunikation beeinträchtigen. Das folgende Beispiel beschreibt, wie ein lokaler Netzwerkausfall eine Einzelstandort-Bereitstellung beeinflussen kann.

Beispiel:

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

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

Bei einem Ausfall des Campus-Netzwerks können Benutzer in den Gebäuden B und C jedoch keine Anrufe tätigen, solange 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 aus Gebäude	Können diese Standorte während eines externen Internetausfalls 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 Netzwerkausfall in Multi-Site ohne SBC

In einem Multi-Site-Design wird jedes Gebäude oder jeder Standort (z. B. Etage, Satellitenbüro usw.) innerhalb von Zoom Phone unabhängig durch einen eindeutigen Standort repräsentiert. Diese Konfiguration geht davon aus, dass jeder Standort ein ZPLS-Modul hat 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. Darüber hinaus können Benutzer, wenn mehrere Standorte mit einem ZPLS-Modul über ein gemeinsames Netzwerk verbunden sind, Benutzer an _andere_ Standorte anrufen, sofern das lokale Netzwerk funktionsfähig bleibt. Dieses Design ist jedoch anfällig für Ausfälle des Campus-Netzwerks, die die gebäudeübergreifende Kommunikation beeinträchtigen. Das folgende Beispiel beschreibt, wie ein Campus-Netzwerkausfall eine Multi-Site-Bereitstellung beeinflussen kann.

Beispiel:

Ein Unternehmen setzt das ZPLS-Modul in seinem Multi-Gebäude-Campus ein, der aus den Gebäuden A, B und C besteht. Jedes Gebäude ist ein eindeutiger Standort innerhalb von Zoom Phone und verfügt über ein standortspezifisches ZPLS-Modul. Alle Gebäude auf dem Campus sind über ein Campus-Netzwerk verbunden, das für die gebäudeübergreifende Kommunikation nicht vom externen Internetdienst abhängt.

In diesem Beispiel kann im Falle eines Ausfalls des externen Internetdienstes, eines Campus-Netzwerkausfalls oder eines servicebeeinträchtigenden Ereignisses jeder Benutzer innerhalb eines Standorts einen anderen Benutzer innerhalb desselben Standorts anrufen. Da jedoch jedes Gebäude ein eigener 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. Die Benutzer sind stattdessen darauf beschränkt, Anrufe an andere Benutzer innerhalb ihres lokalen Standorts zu tätigen.

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

Anrufe aus Gebäude	Können diese Standorte während eines externen Internetausfalls 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, wird standortübergreifendes Anrufen auch über das PSTN unterstützt, sofern jeder Standort mit einem SBC verbunden ist und die Rufumleitung aktiviert ist

Im Falle eines lokalen Netzwerkausfalls können Kunden mit einem Multi-Site-Design, das das ZPLS-Modul in jeden Standort mit einem SBC und PSTN-Konnektivität integriert, standortübergreifende Anrufe aktivieren, wenn Rufumleitung aktiviert ist. Wenn dies konfiguriert ist, werden Anrufe, die während des Survivability-Modus getätigt werden, vom Client des Anrufenden zum PSTN, zum SBC und ZPLS-Modul des zweiten Standorts und schließlich zum Gerät des Angerufenen geleitet. Das folgende Diagramm gibt einen Überblick über diese Konfiguration:

Diese Konfiguration mindestens E.164-Nummernverarbeitung auf den konfigurierten SBCs.

Die folgende Tabelle zeigt ebenfalls die Survivability von Zoom Phone in einem Multi-Site-Design mit unabhängigen SBCs:

Anrufe aus Gebäude	Können diese Standorte während eines externen Internetausfalls 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

NOMADISCHE Benutzer registrieren sich immer bei dem ZPLS-Modul, das mit ihrem Heimatstandort verknüpft ist

Wenn Benutzer oder Geräte zu Zoom Phone hinzugefügt werden, wird dem Benutzer oder Gerät statisch ein „Heimat“-Standort zugewiesen, bis ein Kontoadministrator diesen ändert. Das bedeutet, dass sich Zoom nicht dynamisch anpasst, wenn ein Benutzer an einen physischen Standort außerhalb seines zugewiesenen Heimatstandorts zieht, z. B. in ein Büro, das einem anderen Standort zugeordnet ist. Folglich versucht sich ein Benutzer, der die Verbindung zu den Zoom Phone-Rechenzentren verliert, beim ZPLS-Modul seines Heimatstandorts zu registrieren, selbst wenn er sich an einem anderen Ort befindet.

Beispiel:

Ein Benutzer in einem Multi-Site-Campus hat seinen Sitz in Gebäude A (Standort A) und bewegt sich vorübergehend für ein Meeting in Gebäude B (Standort B). Während er sich in Gebäude B befindet, tritt ein servicebeeinträchtigendes Ereignis auf und der Survivability-Modus wird aktiviert. Obwohl sich der Benutzer in Gebäude B befindet, versucht der Client des Benutzers, sich mit dem ZPLS-Modul zu verbinden, das an seinem Heimatstandort in Gebäude A bereitgestellt ist.

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 seines Heimatstandorts zu registrieren. Ist das Campus-Netzwerk ausgefallen, während sich der Benutzer außerhalb seines Heimatstandorts befindet, kann der Benutzer nicht von dem Survivability-Modul profitieren.