> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/de/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md). # Ü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 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](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Weitere Informationen zu 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 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 | {% hint style="info" %} 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**](#_ah8xua8wdq10) zu verwenden, um zu priorisieren, welche Benutzer Failover für Survivability unterstützen. {% endhint %} ### 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. {% hint style="info" %} Diese Funktion befindet sich derzeit in der Beta-Phase und erfordert ein technisches Support-Ticket, um aktiviert zu werden. {% endhint %} #### 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. {% hint style="success" %} **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. {% endhint %} ### Ü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](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### 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.
{% hint style="info" %} Kontoadministratoren aktueller Zoom-Kunden können ihr aktuelles Standortdesign über die [**Unternehmensinformationen**](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 bereits 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 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. {% 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 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. {% 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 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](#_rx0i1j9xofnc). 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](#_gzpf5m70jl3i). #### 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](#_a42hwaw1pfmx) 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. {% hint style="info" %} 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. {% endhint %} ### 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.
{% hint style="success" %} **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. {% endhint %} 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.
{% 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 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. {% endhint %} 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](#_2v7qst7vxwaa). 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:
{% hint style="danger" %} Diese Konfiguration **erfordert** die Verarbeitung von E.164-Telefonnummern auf den konfigurierten SBCs. {% endhint %} 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. {% hint style="success" %} **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. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` 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=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.