# Überlegungen zur Hardware-Bereitstellung
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, um eine optimale Leistung für verschiedene betriebliche Anforderungen sicherzustellen.
### 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, auf der die Zoom Node Plattform ausgeführt wird, auf einem [unterstützten Hypervisor](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Weitere Informationen über Zoom Node als Produkt finden Sie [im Anhang](#_a2lvsihjp0ek).
#### Kunden können je nach Hardware-Fähigkeiten eine von zwei Konfigurationsoptionen Wählen
Das ZPLS-Modul unterstützt je nach Hardware-Fähigkeiten der virtuellen Maschine zwei Konfigurationen. 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
|
| **Gesamtzahl der Registrierungen** | 2000 | 5000 |
| **Maximale gleichzeitige Anrufe** | 240 | 480 |
| **Anrufe pro Sekunde** | 2 | 4 |
| **Registrierungen pro Sekunde** | 60 | 400 |
{% hint style="info" %}
Wenn die Anzahl der Endpunkte innerhalb eines für Survivability aktivierten Standorts die Bereitstellungsfähigkeiten eines Standorts überschreitet, verarbeitet das ZPLS-Modul Registrierungen nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“. Kunden wird empfohlen, zusätzliche Module Hinzufügen oder die Zoom Phone Policy-Einstellung zu verwenden [**Lokaler Überlebensmodus**](#_ah8xua8wdq10) um zu priorisieren, welche Benutzer Survivability-Failover unterstützen.
{% endhint %}
### Modulskalierung und Ausfallsicherheit
#### ZPLS-Module unterstützen Clustering für zusätzliche Skalierung und/oder Ausfallsicherheit
Kunden können ZPLS-Module mit bis zu 20 Modulen pro Standort (oder insgesamt 100 Node-Geräte pro Konto) für zusätzliche Redundanz oder Skalierung zusammenfassen.
{% hint style="info" %}
Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden.
{% endhint %}
#### Die 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 Ausfallsicherheit hinzu, skaliert jedoch nicht die Gerätefähigkeiten eines Standorts
Wenn ein ZPLS-Modul für Redundanzzwecke 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. Beispielsweise unterstützen ein primäres und ein redundantes Modul insgesamt 5.000 Registrierungen. Wenn also ein primäres Modul ausfällt, ist das redundante Modul nicht mit Geräten über seine unterstützte Grenze hinaus überbelegt.
#### Beispiel für die Bereitstellung von ZPLS mit Skalierung und Redundanz
Zur Vereinfachung zeigt das folgende Beispiel eine Bereitstellung mit zusätzlicher Skalierung und Redundanz.
{% hint style="success" %}
**Beispiel**:
Ein Krankenhaus muss bis zu 10.000 registrierte Nebenstellen 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. Da die Bedeutung der Ausfallsicherheit erkannt wird, stellt das Krankenhaus außerdem zwei zusätzliche Module als redundante Backups für die primären Module bereit.
In diesem Szenario verfügt das Krankenhaus nun über bereitgestellte primäre und sekundäre Survivability-Hardware. Wenn nun ein primäres Modul auf einen Fehler trifft, werden die redundanten Module Übernehmen, um einen unterbrechungsfreien Service aufrechtzuerhalten, und dabei weiterhin bis zu 10.000 registrierte Geräte unterstützen.
{% endhint %}
### Überlegungen zum Standortdesign
#### Standorte gruppieren Zoom Phone-Benutzer nach Standort für gemeinsame Telefonie-Einstellungen und Richtlinien
Ein **Standort** ist ein spezifischer Begriff, der innerhalb von Zoom Phone verwendet wird und Benutzer mit gemeinsamen Merkmalen — wie einem gemeinsamen Access-Code, einer Adresse, SIP-Zone, Abteilung oder Richtlinien — in einer einzigen, verwaltbaren Gruppe innerhalb des 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 zur Standortverwaltung finden Sie unter [im Support-Center von Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).
#### Zoom Phone unterstützt Designs mit einem Standort und mit mehreren Standorten
Es gibt zwei primäre Designs für die Konfiguration von Zoom Phone-Standorten innerhalb eines Kontos:
1. **Einzelner Standort**: Repräsentiert alle Benutzer innerhalb eines Kontos, potenziell über mehrere Gebäude oder Standorte hinweg, innerhalb eines einzelnen Zoom Phone-Standorts.
2. **Mehrere Standorte**: Repräsentiert Benutzersegmente nach Standort, Gebäude, Abteilung oder Funktion getrennt, jeweils mit eigenem Standort.
{% hint style="info" %}
Kontoadministratoren aktueller Zoom-Kunden können ihr aktuelles Standortdesign über die [**Unternehmensinfo**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) Seite prüfen, Verfügbar im **Telefonsystem-Verwaltung** Menü im Webportal.
{% endhint %}
#### Jedes ZPLS-Modul kann jeweils nur einem Standort zugeordnet werden
Wie zuvor erwähnt, ist ein ZPLS-Modul der [Registrar mit dritter Priorität](#_7itj40mx1dut) 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 Einstellung 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.
{% hint style="info" %}
Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden.
{% endhint %}
#### ZPLS-Module unterstützen standortübergreifende Anrufe, wenn die Module mit einem gemeinsamen Netzwerk verbunden sind
ZPLS-Module von verschiedenen Standorten unterstützen während eines Survivability-Events standortübergreifende Anrufe, solange die Geräte im lokalen Netzwerk auffindbar 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 Campusnetzwerk verbinden.
{% hint style="info" %}
Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden.
{% endhint %}
#### 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 jeder zusätzliche für Survivability aktivierte Standort mindestens ein zusätzliches ZPLS-Modul erfordert.
#### Ein Design mit einem einzelnen Standort ist einfacher zu verwalten und bietet Survivability mit einem einzigen ZPLS-Modul, bietet jedoch weniger Flexibilität für Benutzer-Einstellungen und Richtlinien
Ein Design mit einem einzelnen Standort hilft, die Verwaltung von Zoom Phone-Einstellungen und -Richtlinien zu optimieren, indem alle Benutzer innerhalb eines Kontos unter einer einzigen, einheitlichen Gruppe zusammengefasst werden. Diese einzelne Benutzergruppe bietet Unternehmen eine unkomplizierte Administration und geringere Komplexität, wodurch der Verwaltungsprozess vereinfacht wird. Zusätzlich kann ein Design mit einem einzelnen Standort lokale Telefon-Survivability mit einem einzigen ZPLS-Modul bieten, solange die Benutzer des Standorts nicht die [Fähigkeiten eines einzelnen Moduls](#_rx0i1j9xofnc).
Die Einfachheit eines Designs mit einem einzelnen Standort bringt jedoch naturgemäß Einschränkungen mit sich. Insbesondere bieten Designs mit einem einzelnen Standort 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 Bereitstellungen mit einem einzelnen Standort in bestimmten Survivability-Szenarien anfällig sein, wenn das [lokale Netzwerk ausfällt](#_gzpf5m70jl3i).
#### Ein Design mit mehreren Standorten 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 Design mit mehreren Standorten bietet Unternehmen zusätzliche Flexibilität bei Benutzer-Einstellungen und Richtlinien, indem Benutzer in verschiedene Gruppen mit granularen Einstellungssteuerungen aufgeteilt werden. Dieses Design ermöglicht es Organisationen, Kommunikationskonfigurationen präzise anzupassen, um spezifische Anforderungen über unterschiedliche Standorte hinweg zu erfüllen, was zu einer verfeinerten und anpassungsfähigeren Benutzererfahrung für verschiedene Abteilungen, Szenarien oder Anforderungen führt. Zusätzlich können Bereitstellungen mit mehreren Standorten [standortübergreifende Kommunikation](#_a42hwaw1pfmx) unterstützen, wenn die Standorte über ein gemeinsames Netzwerk verbunden sind.
Die Verwaltung eines Designs mit mehreren Standorten erfordert jedoch sorgfältige Aufmerksamkeit für die Komplexität der individuellen Anforderungen jedes Standorts, was ein höheres Maß an administrativem Aufwand erfordern kann. Darüber hinaus benötigt jeder für Survivability aktivierte Standort ein ZPLS-Modul und eine Lizenz, da jedes ZPLS-Modul jeweils nur einem Standort zugewiesen werden kann, was zu einer ressourcenintensiveren Einrichtung beitragen kann.
{% hint style="info" %}
In einem Design mit mehreren Standorten haben Kunden die Flexibilität zu Wählen, welche Standorte für Survivability konfiguriert werden. Standorte *ohne* ein ZPLS-Modul bleiben außerstande, Anrufe zu tätigen oder zu empfangen, bis die Standardkonnektivität wiederhergestellt ist.
{% endhint %}
### Netzwerkausfälle
#### Die Survivability kann beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt
Obwohl ZPLS-Module darauf ausgelegt sind, bei servicebeeinträchtigenden Ereignissen lokale Telefon-Survivability bereitzustellen, kann die Survivability beeinträchtigt werden, wenn das lokale Netzwerk eines Standorts ausfällt. Diese Szenarien werden in den folgenden zwei Abschnitten beschrieben.
#### Ausfall des lokalen Netzwerks bei einem einzelnen Standort
In einem Design mit einem einzelnen Standort sind ein oder mehrere Gebäude über ein lokales Netzwerk oder Campusnetzwerk verbunden und werden innerhalb von Zoom Phone durch einen einzelnen 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 lokale Survivability für alle Benutzer innerhalb eines einzelnen Standorts oder Standorts mit nur einem ZPLS-Modul bereitstellen; dieses Design ist jedoch anfällig im Falle eines Ausfalls des lokalen Netzwerks oder Campusnetzwerks, der die Kommunikation zwischen Gebäuden beeinträchtigt. Das folgende Beispiel beschreibt, wie sich ein Ausfall des lokalen Netzwerks auf eine Bereitstellung mit einem einzelnen Standort auswirken kann.
{% hint style="success" %}
**Beispiel:**
Ein Unternehmen stellt das ZPLS-Modul für einen einzelnen Zoom Phone-Standort bereit, bestehend aus den Gebäuden A, B und C, die über ein Campusnetzwerk verbunden sind. Das ZPLS-Modul arbeitet 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 Events kann jeder Benutzer innerhalb des Standorts einen anderen Benutzer innerhalb desselben *gleichen* Standorts anrufen, solange beide Benutzer über das Campusnetzwerk die Konnektivität zum ZPLS-Modul aufrechterhalten.
Im Falle eines Ausfalls des Campusnetzwerks 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 Campusnetzwerk wiederhergestellt ist, um Survivability-Anrufe zu tätigen.
{% endhint %}
Die folgende Tabelle zeigt die Zoom Phone-Survivability in einem Ein-Standort-Design mit mehreren Gebäuden:
| Anrufe aus Gebäude | Kann diese Standorte während eines externen Internetausfalls erreichen | Kann diese Standorte während eines Ausfalls des Campusnetzwerks erreichen |
| --------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Gebäude A (ZPLS-Host) | ☑️Gebäude A, B und C | ☑️ Nur 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 in einem Design mit mehreren Standorten ohne SBC
In einem Design mit mehreren Standorten 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 setzt voraus, dass jeder Standort ein ZPLS-Modul hat und dass die Standorte über ein gemeinsames Campusnetzwerk verbunden sind.
Mit diesem Standortdesign unterstützt jeder Standort ein eigenes ZPLS-Modul, sodass Benutzer innerhalb desselben Gebäudes einander anrufen können, wenn der Survivability-Modus aktiviert ist. Wenn außerdem 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 im Falle eines Ausfalls des Campusnetzwerks, der die Kommunikation zwischen Gebäuden beeinträchtigt. Das folgende Beispiel beschreibt, wie sich ein Ausfall des Campusnetzwerks auf eine Bereitstellung mit mehreren Standorten auswirken kann.
{% hint style="success" %}
**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 Campusnetzwerk 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 Campusnetzwerks oder eines servicebeeinträchtigenden Events jeder Benutzer innerhalb eines Standorts einen anderen Benutzer innerhalb desselben Standorts anrufen. Da jedoch jedes Gebäude ein eindeutiger Standort ist und sich Benutzer bei ihren standortspezifischen Modulen registrieren, können die ZPLS-Module bei Ausfall des Campusnetzwerks keine standortübergreifenden Anrufe übertragen. Stattdessen sind Benutzer darauf beschränkt, andere Benutzer innerhalb ihres lokalen Standorts anzurufen.
{% endhint %}
Die folgende Tabelle zeigt die Zoom Phone-Survivability aus dem obigen Beispiel in einem Design mit mehreren Standorten mit einem miteinander verbundenen Campusnetzwerk:
| Anrufe aus Gebäude | Kann diese Standorte während eines externen Internetausfalls erreichen | Kann diese Standorte während eines Ausfalls des Campusnetzwerks erreichen |
| --------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Gebäude A (ZPLS-Host) | ☑️ Gebäude A, B und C | ☑️ Nur 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, vorausgesetzt, jeder Standort ist mit einem SBC verbunden und die Anrufweiterleitung ist aktiviert
Im Falle eines Ausfalls des lokalen Netzwerks können Kunden mit einem Design mit mehreren Standorten, 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](#_2v7qst7vxwaa). Wenn konfiguriert, werden Anrufe, die im Survivability-Modus getätigt werden, vom Client des Benutzers zum PSTN, dann zum SBC und ZPLS-Modul des zweiten Standorts geleitet und kommen schließlich beim Gerät des angerufenen Benutzers an. Das folgende Diagramm bietet einen Überblick über diese Konfiguration:
{% hint style="danger" %}
Diese Konfiguration **erfordert** E.164-Telefonnummernverarbeitung auf den konfigurierten SBCs.
{% endhint %}
Die folgende Tabelle zeigt ebenfalls die Zoom Phone-Survivability in einem Design mit mehreren Standorten mit unabhängigen SBCs:
| Anrufe aus Gebäude | Kann diese Standorte während eines externen Internetausfalls erreichen | Kann diese Standorte während eines Ausfalls des Campusnetzwerks 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 ihrem Heimatstandort zugeordnet ist
Wenn Benutzer oder Geräte zu Zoom Phone Hinzufügen werden, wird dem Benutzer oder Gerät statisch ein „Heimat“-Standort zugeordnet, bis dieser andernfalls von einem Kontoadministrator aktualisiert wird. Das bedeutet, dass Zoom den an den Benutzer gebundenen Standort nicht dynamisch anpasst, wenn sich ein Benutzer zu einem physischen Standort außerhalb seines zugeordneten Heimatstandorts bewegt, etwa in ein Bürogebäude, das einem anderen Standort zugeordnet ist. Folglich versucht der Benutzer, wenn er die Konnektivität zu den Zoom Phone-Rechenzentren verliert, sich bei dem ZPLS-Modul zu registrieren, das seinem Heimatstandort zugeordnet ist, auch wenn er sich an einem anderen Standort befindet.
{% hint style="success" %}
**Beispiel:**
Ein Benutzer in einem Campus mit mehreren Standorten ist in Gebäude A (Standort A) ansässig und wechselt 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 Event ein und der Survivability-Modus wird aktiviert. Obwohl sich der Benutzer in Gebäude B befindet, versucht der Client des Benutzers, da Standort A sein Heimatstandort ist, eine Verbindung zu dem ZPLS-Modul herzustellen, das an seinem Heimatstandort in Gebäude A bereitgestellt wurde.
In diesem Szenario wird der Survivability-Status eines Benutzers durch die Fähigkeit des Benutzergeräts bestimmt, sich über das Campusnetzwerk bei dem ZPLS-Modul innerhalb seines Heimatstandorts zu registrieren. Wenn das Campusnetzwerk ausfällt, während der Benutzer sich außerhalb seines Heimatstandorts befindet, kann der Benutzer nicht von dem Survivability-Modul profitieren.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://library.zoom.com/technical-library/de/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.