Überlegungen zur Hardwarebereitstellung

Hier finden Sie Anweisungen zur Bereitstellung des Zoom Node-ZPLS-Moduls auf virtuellen Maschinen mit unterstützten 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 Hardwarefähigkeiten zugeschnitten sind, um eine optimale Leistung für verschiedene betriebliche Anforderungen zu 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-Arbeitslast 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	60	400

Wenn die Anzahl der Endpunkte innerhalb eines für Survivability aktivierten Standorts die Bereitstellungskapazitäten eines 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 die Survivability-Failover unterstützen.

Modulskalierung und Resilienz

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

Kunden können ZPLS-Module mit bis zu 20 Modulen pro Standort (bzw. 100 Node-Geräten pro Konto insgesamt) gruppieren, um zusätzliche Redundanz oder Skalierung zu erreichen.

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

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

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

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

Wenn ein ZPLS-Modul zum Zwecke der Redundanz verwendet wird, tragen die redundanten Module nicht zur Gesamtzahl der unterstützten Nebenstellen bei. Stattdessen befinden sich die Module im „Hot-Standby“ und greifen nur dann ein, wenn primäre Module ausfallen. Wenn beispielsweise ein primäres und ein redundantes Modul zusammen insgesamt 5.000 Registrierungen unterstützen, wird das redundante Modul im Falle eines Ausfalls des primären Moduls nicht mit Geräten über seine unterstützte Grenze hinaus überlastet.

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

Der folgende Beispiel dient der Veranschaulichung einer Bereitstellung mit zusätzlicher Skalierung und Redundanz.

Beispiel:

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

Die ersten beiden Module sind jeweils in der Lage, 5.000 Registrierungen zu unterstützen, was zu einer Gesamtkapazität von bis zu 10.000 Registrierungen führt. Da jedoch die Resilienz wichtig ist, setzt das Krankenhaus zusätzlich zwei Module als redundante Backups für die primären Module ein.

In diesem Szenario sind nun primäre und sekundäre Survivability-Hardware bereitgestellt. Wenn ein primäres Modul ausfällt, übernehmen die redundanten Module, um einen unterbrechungsfreien Dienst aufrechtzuerhalten, und unterstützen weiterhin bis zu 10.000 registrierte Geräte.

Überlegungen zum Standortdesign

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

Ein Standorts ist ein spezifischer Begriff innerhalb von Zoom Phone, der Benutzer mit gemeinsamen Merkmalen – wie einer gemeinsamen Zugriffscode, Adresse, SIP-Zone, Abteilung oder Richtlinien – in einer einzigen verwaltbaren Gruppe innerhalb des Zoom-Webportals zusammenfasst. Für einige Kunden kann ein einzelner Standort alle Benutzer ihres Unternehmens repräsentieren und sich über mehrere Gebäude auf einem Campus oder an einem Standort erstrecken; für andere können je nach Geschäftsanforderungen mehrere Standorte erforderlich sein. Weitere Informationen zu Standorten oder zur Verwaltung von Standorten finden Sie im Zoom Support-Center.

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, die sich möglicherweise über mehrere Gebäude oder Standorte erstrecken, innerhalb eines einzelnen Zoom Phone-Standorts.

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

Kontoadministratoren bestehender Zoom-Kunden können ihr aktuelles Standortdesign über die Firmeninformationen Seite prüfen, die im Untermenü Telefonanlagenverwaltung Menü im Webportal verfügbar ist.

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 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 und damit die Survivability-Fähigkeiten des Standorts erweitern.

Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein Ticket beim technischen Support, 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 standortübergreifende Anrufe während eines Survivability-Ereignisses, sofern die Geräte im lokalen Netzwerk auffindbar sind. Wenn ein Firmen-Campus beispielsweise drei Gebäude mit jeweils eigenem Telefonstandort hat, können die ZPLS-Module der einzelnen Standorte standortübergreifende Anrufe über das Campus-Area-Netzwerk verbinden.

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

Vor der Bereitstellung von ZPLS sollten Konten verstehen, welche Standortkonfiguration am besten 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 Geschäfts- und Survivability-Anforderungen zu erfüllen, da jeder zusätzliche Standort, der für Survivability aktiviert ist, mindestens ein zusätzliches ZPLS-Modul erfordert.

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

Ein Einzelstandort-Design hilft dabei, 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 übersichtliche Administration und reduzierte Komplexität, wodurch der Verwaltungsprozess vereinfacht wird. Außerdem kann ein Einzelstandort-Design lokale Telefon-Survivability mit nur einem ZPLS-Modul bieten, sofern die Benutzer des Standorts nicht die Fähigkeiten eines Einzelmoduls.

überschreiten. Allerdings bringt die Einfachheit eines Einzelstandort-Designs 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 in verschiedenen Abteilungen mit unterschiedlichen Anforderungen geeignet sein kann. Außerdem können Einzelstandort-Bereitstellungen in bestimmten Überlebensszenarien verwundbar sein, wenn das lokale Netzwerk ausfällt.

Ein Multi-Site-Design bietet mehr Flexibilität für Benutzer-Einstellungen und -Richtlinien, erfordert jedoch ein ZPLS-Modul für jeden für Survivability aktivierten Standort und ist komplizierter zu verwalten

Ein Multi-Site-Design bietet Unternehmen zusätzliche Flexibilität bei Benutzer-Einstellungen und -Richtlinien, indem Benutzer in verschiedene Gruppen mit granularem Einstellungsmanagement aufgeteilt werden. Dieses Design ermöglicht es Organisationen, Kommunikationskonfigurationen fein abzustimmen, um spezifische Anforderungen an verschiedenen Standorten zu erfüllen, und führt zu einer differenzierteren und anpassbareren Benutzererfahrung für verschiedene Abteilungen, Szenarien oder Bedürfnisse. Darüber hinaus können Multi-Site-Bereitstellungen standortübergreifende Kommunikation unterstützen, sofern die Standorte durch ein gemeinsames Netzwerk verbunden sind.

Die Verwaltung eines Multi-Site-Designs erfordert jedoch sorgfältige Beachtung der Besonderheiten jedes Standorts, was einen höheren Verwaltungsaufwand erfordern kann. Darüber hinaus benötigt jeder für Survivability aktivierte Standort aufgrund der Zuweisung eines ZPLS-Moduls pro Standort eine eigene ZPLS-Modul- und Lizenz, was zu einer ressourcenintensiveren Einrichtung beitragen kann.

In einem Multi-Site-Design haben Kunden die Flexibilität zu wählen, welche Standorte für Survivability konfiguriert werden. Standorte ohne ein ZPLS-Modul bleibt nicht in der Lage, Anrufe zu tätigen oder zu 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 so konzipiert sind, dass sie lokale Telefonsurvivability während servicebeeinträchtigender Ereignisse bieten, kann die Survivability beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt. Diese Szenarien sind in den folgenden beiden Abschnitten dargestellt.

Ausfall des lokalen Netzwerks bei Einzelstandort

Bei einem Einzelstandort-Design sind ein oder mehrere Gebäude über ein lokales oder Campus-Area-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 standortübergreifende Kommunikation.

Mit diesem Standortdesign kann ein Unternehmen allen Benutzern innerhalb eines einzelnen Standorts oder Ortes bereits mit nur einem ZPLS-Modul lokale Survivability bieten; dieses Design ist jedoch anfällig bei einem lokalen oder Campus-Netzwerkausfall, der die standortübergreifende Kommunikation beeinträchtigt. Das folgende Beispiel beschreibt, wie sich ein lokaler Netzwerkausfall auf eine Einzelstandort-Bereitstellung auswirken kann.

Beispiel:

Ein Unternehmen setzt das ZPLS-Modul für einen einzelnen Zoom Phone-Standort ein, der sich aus den Gebäuden A, B und C zusammensetzt und über ein Campus-Area-Netzwerk verbunden ist. Das ZPLS-Modul befindet sich 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 servicebeeinträchtigenden Ereignisses kann jeder Benutzer innerhalb des Standorts einen anderen Benutzer innerhalb des gleichen Standorts anrufen, sofern beide Benutzer Konnektivität zum ZPLS-Modul über das Campus-Area-Netzwerk aufrechterhalten.

Bei einem Ausfall des Campus-Area-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-Area-Netzwerk für Survivability-Anrufe wiederhergestellt ist.

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

Anrufe, die aus dem Gebäude stammen	Können diese Standorte bei einem Ausfall des externen Internets erreichen	Können diese Standorte bei einem Ausfall 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	✖️

Ausfall des lokalen Netzwerks bei Multi-Site ohne SBC

Bei einem Multi-Site-Design wird jedes Gebäude oder jeder Standort (z. B. Etage, Satellitenbüro usw.) innerhalb von Zoom Phone durch einen eigenen Standort dargestellt. Diese Konfiguration geht davon aus, dass jeder Standort ein ZPLS-Modul hat und dass die Standorte durch ein gemeinsames Campus-Area-Netzwerk verbunden sind.

Mit diesem Standortdesign unterstützt jeder Standort sein eigenes ZPLS-Modul, sodass Benutzer im selben Gebäude sich gegenseitig anrufen können, wenn der Survivability-Modus aktiv ist. Weiterhin 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 betriebsfähig bleibt. Dieses Design ist jedoch anfällig bei einem Ausfall des Campus-Area-Netzwerks, der die standortübergreifende Kommunikation beeinträchtigt. 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 eigener Standort innerhalb von Zoom Phone und verfügt über ein standortspezifisches ZPLS-Modul. Alle Gebäude auf dem Campus sind über ein Campus-Area-Netzwerk verbunden, das für die standortübergreifende Kommunikation nicht vom externen Internetdienst abhängig ist.

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 im selben Standort anrufen. Da jedoch jedes Gebäude ein eigener Standort ist und sich Benutzer bei ihren standortspezifischen Modulen registrieren, können die ZPLS-Module bei Ausfall des Campus-Netzwerks keine standortübergreifenden Anrufe transportieren. Stattdessen sind Benutzer darauf beschränkt, Anrufe an andere Benutzer innerhalb ihres lokalen Standorts zu tätigen.

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

Anrufe, die aus dem Gebäude stammen	Können diese Standorte bei einem Ausfall des externen Internets erreichen	Können diese Standorte bei einem Ausfall 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 an ein SBC angeschlossen ist und Anrufweiterleitung aktiviert ist

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

Diese Konfiguration erfordert E.164-Telefonnummernverarbeitung auf den konfigurierten SBCs.

Die folgende Tabelle veranschaulicht außerdem die Survivability von Zoom Phone in einem Multi-Site-Design mit unabhängigen SBCs:

Anrufe, die aus dem Gebäude stammen	Können diese Standorte bei einem Ausfall des externen Internets erreichen	Können diese Standorte bei einem Ausfall 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 beim ZPLS-Modul ihres Heimstandorts

Wenn Benutzer oder Geräte zu Zoom Phone hinzugefügt werden, wird dem Benutzer oder Gerät statisch ein „Heim“-Standort zugewiesen, bis ein Kontoadministrator eine Aktualisierung vornimmt. Das bedeutet, dass Zoom die an einen Benutzer gebundene Standortzuweisung nicht dynamisch anpasst, wenn sich ein Benutzer an einen physischen Ort außerhalb seines zugewiesenen Heimstandorts, z. B. in ein anderes Bürogebäude, bewegt. Folglich versucht sich der Benutzer im Falle eines Verbindungsverlusts zu den Zoom Phone-Rechenzentren beim ZPLS-Modul seines Heimstandorts zu registrieren, selbst wenn er sich an einem anderen Standort befindet.

Beispiel:

Ein Benutzer auf einem Multi-Site-Campus hat seinen Arbeitsplatz in Gebäude A (Standort A) und begibt sich vorübergehend zu einem Meeting nach 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, eine Verbindung zu dem ZPLS-Modul herzustellen, das an seinem Heimstandort in Gebäude A bereitgestellt ist.

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