> 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/erweiterte-enterprise-services/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Überlegungen zur Bereitstellung von Zoom Node Erfahren Sie mehr darüber, wie verschiedene Bereitstellungsbeispiele Zoom Node und Zoom Node Service-Module unterstützen Dieser Abschnitt enthält mehrere Beispiele dafür, wie Zoom Node verschiedene Service-Module wie Zoom Meetings Hybrid und Zoom Phone Local Survivability (ZPLS) unterstützen kann. Typische Bereitstellungen mit einer dedizierten IP-Adresse können wie die folgende Sammlung von Diagrammen aussehen. Jeder auf Zoom Node bereitgestellte Dienst erfordert eine eindeutige IP-Adresse. Ein Zoom Node verfügt über bis zu fünf (5) IP-Adressen, die ihm zugewiesen sind, wenn dem Node eine bestimmte Adresse für die Verwaltung und eine für jeden bereitgestellten Dienst (bis zu vier) auf dem Node zugewiesen wurde. Ein Zoom Node, der einen einzelnen Dienst (z. B. ZPLS) ausführt, kann mit einer einzigen IP-Adresse bereitgestellt werden, wenn Node und Dienst so zugewiesen sind, dass sie dieselbe IP-Adresse gemeinsam nutzen. Mehrere Bereitstellungsoptionen werden unten gezeigt. Beachten Sie die Anzahl der IPs und Zertifikate (CN/SANs) für die verschiedenen Bereitstellungsoptionen. ### Option 1: Zoom Meetings Hybrid mit dedizierten IPs und Hostnamen bereitgestellt
Das obige Bild fasst die Anforderungen an die IP- und Zertifikatskonfiguration für die Bereitstellung von **Zoom Meetings Hybrid** in lokalen oder hybriden Cloud-Umgebungen. Die folgende Tabelle zerlegt den Beispiel-Node und umfasst seine aktiven Proxy- und MMR-Service-Module: | Komponente | Hostname | Rolle des TLS-Zertifikats | Funktion | | --------------------- | -------------------- | ---------------------------------- | ------------------------------------- | | Node-Betriebssystem | `node1.customer.com` | Allgemeiner Name (CN) | Kern-Orchestrierung | | Zoom Connector Proxy | `zcp1.customer.com` | Alternativer Zertifikatsname (SAN) | Signalisierung und Sitzungssteuerung | | Media Module Router 1 | `mmr1.customer.com` | Alternativer Zertifikatsname (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 2 | `mmr2.customer.com` | Alternativer Zertifikatsname (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 3 | `mmr3.customer.com` | Alternativer Zertifikatsname (SAN) | Medienweiterleitung und -verarbeitung | {% hint style="info" %} Sie müssen jedem Modul eine dedizierte statische IP-Adresse zuweisen. Insgesamt erforderliche IP-Adressen: fünf (5) {% endhint %}
Das obige Bild umreißt die Mindestkonfiguration, die für die Bereitstellung von **Lokale Ausfallsicherheit für Zoom Phone (ZPLS)**. ZPLS ermöglicht die fortgesetzte Verfügbarkeit des Telefondienstes im Falle eines Internet- oder Cloud-Events, indem die Ausfallsicherungslogik lokal auf einer Zoom Node-VM ausgeführt wird. Die folgenden Hostnamen müssen in DNS konfiguriert und im TLS-Zertifikat enthalten sein: * `node1.customer.com` * `zplsl.customer.com` **Hostname-Funktionszuordnung** | Komponente | Hostname | Rolle des TLS-Zertifikats | Funktion | | ------------------- | -------------------- | ---------------------------- | ---------------------------------------- | | Node-Betriebssystem | `node1.customer.com` | Allgemeiner Name (CN) | Kern-Orchestrierung | | ZPLS-Modul | `zplsl.customer.com` | Alternativer Zertifikatsname | Logik für Zoom Phone Local Survivability | **TLS-Zertifikatskonfiguration** | Feld | Wert | | ---------------------------- | -------------------- | | Allgemeiner Name (CN) | `node1.customer.com` | | Alternative Zertifikatsnamen | `zplsl.customer.com` | Zertifikate müssen erstellt oder beschafft werden (öffentliche oder private CA), um sowohl den oben aufgeführten CN als auch die SANs einzuschließen. Dies ermöglicht eine ordnungsgemäße TLS-Validierung für die sichere Kommunikation innerhalb des Moduls. **Anforderungen an IP-Adressen** | Metrik | Wert / Beschreibung | | ----------------------------------- | ----------------------------------------------------------- | | Insgesamt erforderliche IP-Adressen | 5 (allgemeine Zuweisung) | | Verwendet im ZPLS-Kontext | 2 IP-Adressen (1 für Node-Betriebssystem, 1 für ZPLS-Modul) | Während für die allgemeine Bereitstellung fünf (5) IPs erforderlich sind, **werden nur zwei (2) IP-Adressen aktiv verwendet** in der ZPLS-Bereitstellung: eine pro Modul, ausgeführt auf einer **dedizierte Node-VM**. {% hint style="warning" %} ZPLS erlaubt nur ein Modul pro Node-VM. Sie können ZPLS nicht mit anderen Zoom-Modulen auf derselben VM zusammen betreiben. {% endhint %} Wie vergleichen sich diese Diagramme? Das erste Bild zeigt ein Beispiel einer Zoom Meetings-Hybridbereitstellung. Das zweite Bild zeigt ein Beispiel einer Zoom Phone Local Survivability-Bereitstellung. Sie können die erste IP-Adresse/den ersten Hostnamen zwischen dem Betriebssystem und dem ersten Modul, falls gewünscht, gemeinsam verwenden, um die Anzahl der erforderlichen IP-Adressen, Hostnamen und Subject Alternative Names (SANs) zu reduzieren. ### Option 2: Zoom Meetings Hybrid mit gemeinsamer IP-Adresse und gemeinsamem Hostnamen bereitgestellt
Diese Konfiguration wiederholt die Node-Struktur, wie sie im Diagramm für Option 1 der Zoom Meetings Hybrid-Bereitstellung zu sehen ist. In dieser Bereitstellung jedoch **Das Node-Betriebssystem teilt seine IP-Adresse mit dem zuerst bereitgestellten Modul** (in der Regel der Zoom Connector Proxy, ZCP). Dies führt zu einer geringeren IP-Nutzung bei gleichzeitiger Einhaltung der TLS- und Funktionsanforderungen. Die folgenden Hostnamen müssen in DNS konfiguriert und im TLS-Zertifikat enthalten sein: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Hostname-Funktionszuordnung** | Komponente | Hostname | Rolle des TLS-Zertifikats | Funktion | | -------------------------- | ------------------- | ---------------------------------- | ------------------------------------- | | ZCP (Zoom Connector Proxy) | `zcp1.customer.com` | Allgemeiner Name (CN) | Signalisierung und Sitzungssteuerung | | Media Module Router 1 | `mmr1.customer.com` | Alternativer Zertifikatsname (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 2 | `mmr2.customer.com` | Alternativer Zertifikatsname (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 3 | `mmr3.customer.com` | Alternativer Zertifikatsname (SAN) | Medienweiterleitung und -verarbeitung | **TLS-Zertifikatskonfiguration** | Feld | Wert | | ---------------------------- | ------------------------------------------------------------- | | Allgemeiner Name (CN) | `zcp1.customer.com` | | Alternative Zertifikatsnamen | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | Zertifikate müssen alle SANs enthalten, um eine sichere TLS-Kommunikation zwischen dem Zoom Node und den installierten Zoom-Modulen zu unterstützen. **Anforderungen an IP-Adressen** | Metrik | Wert / Beschreibung | | ----------------------------------- | --------------------------------------------------------------------- | | Insgesamt erforderliche IP-Adressen | 4 | | Strategie zur IP-Freigabe | Node-Betriebssystem teilt seine IP-Adresse mit dem ersten Modul (ZCP) | | Erforderliche einzelne IPs für | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Wenn die IP-Adresse **geteilt** zwischen dem Node-Betriebssystem und dem zuerst bereitgestellten Modul (ZCP) geteilt wird, nur **vier (4) IP-Adressen** erforderlich. Dieses Design optimiert die IP-Nutzung und erfüllt dennoch die Bereitstellungsstandards. {% endhint %}
Das obige Bild zeigt eine minimale ZPLS-Bereitstellung, bei der das **Node-Betriebssystem seine IP-Adresse mit dem installierten ZPLS-Modul teilt**. Dies ist die **einzige Situation** im Zoom Node-Framework, in der ein **TLS-Zertifikat für einen einzelnen Host** gültig ist. Der folgende Hostname muss in DNS konfiguriert und in das TLS-Zertifikat aufgenommen werden: * `zplsl.customer.com` **Hostname-Funktionszuordnung** | Komponente | Hostname | Rolle des TLS-Zertifikats | Funktion | | ---------- | -------------------- | ------------------------- | ---------------------------------------- | | ZPLS-Modul | `zplsl.customer.com` | Allgemeiner Name (CN) | Logik für Zoom Phone Local Survivability | **TLS-Zertifikatskonfiguration** | Feld | Wert | | --------------------- | -------------------- | | Allgemeiner Name (CN) | `zcp1.customer.com` | | SANs | (nicht erforderlich) | In dieser Konfiguration ist ein Zertifikat für einen einzelnen Host ausreichend, da sowohl das Betriebssystem als auch das ZPLS-Modul denselben Hostnamen und dieselbe IP-Adresse verwenden. **Anforderungen an IP-Adressen** | Metrik | Wert / Beschreibung | | ----------------------------------- | ---------------------------------------------------------------- | | Insgesamt erforderliche IP-Adressen | 1 | | Strategie zur IP-Freigabe | Node-Betriebssystem und ZPLS teilen sich eine einzige IP-Adresse | | Bereitstellungsbeschränkung | Pro Node-VM ist nur ein Modul erlaubt (nur ZPLS) | {% hint style="warning" %} ZPLS ist das einzige unterstützte Szenario in der Zoom Node-Architektur, in dem: * Ein Zertifikat für einen einzelnen Host (nur CN) ist zulässig * Aufgrund der IP-Freigabe zwischen Betriebssystem und Modul ist für die Bereitstellung nur eine (1) IP-Adresse erforderlich * Die Co-Lokalisierung zusätzlicher Module auf derselben VM wird nicht unterstützt {% endhint %} ### Entscheiden Sie, welche Methode zur Zertifikatsverwaltung für Ihre Bereitstellungen am besten geeignet ist Jedes auf Zoom Node bereitgestellte Servicemodul benötigt ein gültiges Zertifikat, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle (CA) aus der Zertifikat-Vertrauensliste von Zoom Node signiert wurde. Dazu gehören bekannte öffentliche Zertifizierungsstellen. Zoom Node bietet zwei Methoden zur Zertifikatsverwaltung an: * **Auto PKI**: Diese innovative Lösung automatisiert die sichere Zertifikatsanmeldung und -erneuerung mit öffentlich vertrauenswürdigen Zertifizierungsstellen (CAs). Zoom übernimmt die mit der Anmeldung und Erneuerung verbundenen Kosten. * **BYOC**: Mit dieser Option stellen Sie Ihre eigenen Zertifikate bereit, die von einer großen öffentlich vertrauenswürdigen CA signiert wurden. Sie sind für die Zertifikatsanmeldung und -erneuerung verantwortlich. Bei kundenseitig bereitgestellten Zertifikaten gelten zusätzliche Überlegungen hinsichtlich des Potenzials von Zoom Node für bis zu fünf Hostnamen/SANs, die weiter unten ausführlicher beschrieben werden. #### Automatische Zertifikatsverwaltung mit Auto PKI Zoom Auto PKI installiert automatisch gültige, öffentlich vertrauenswürdige CA-Zertifikate für die Zoom Node-Plattform sowie für alle darauf bereitgestellten Module. Auch die Zertifikatserneuerung wird automatisch behandelt. Dies vereinfacht die Zertifikatsverwaltung für alle Dienste und für Zoom Node selbst. #### Zertifikatsanmeldung und -erneuerung mit Auto PKI verstehen Das folgende Szenario kann Ihnen helfen zu verstehen, wie die Zertifikatsanmeldung und -erneuerung funktioniert. Zum Beispiel: Ein Administrator hat eine neue Node-Instanz bereitgestellt. Jede Instanz benötigt ein gültiges x509-Zertifikat. **Der private Schlüssel des Zertifikats darf diese Instanz niemals verlassen**. Der Auto-PKI-Prozess führt die folgenden Schritte aus: 1. **Vorlagenabruf**: Ruft alle unterstützten Konfigurationsvorlagen, einschließlich Optionen für mehrere CA-Anbieter, vom Auto-PKI-Dienst in der Zoom Cloud ab. 2. **Sammlung von IP-Adressen**: Erfasst alle von Diensten verwendeten IP-Adressen, die auf dem Node ausgeführt werden, und sendet sie an den Auto-PKI-Dienst in der Zoom Cloud. 3. **Bereitstellung von DNS-Namen**: Der Auto-PKI-Cloud-Dienst gibt einen Satz von DNS-Namen im folgenden Format zurück `..zoomonprem.com`. Diese Domänen werden mit A/AAAA-Einträgen konfiguriert. 4. **Anforderung eines reservierten DNS-Namens**: Fordert einen reservierten DNS-Namen im folgenden Format an `rsvd-..zoomonprem.com`. 5. **Generierung einer Zertifikatanforderung**: Erstellt eine x509-Zertifikatanforderung und verwendet dabei die DNS-Namen aus dem dritten Schritt im SAN-Feld sowie den reservierten Namen aus dem vierten Schritt im Feld „Common Name“ (CN). 6. **Zertifikatausstellung**: Sendet die Zertifikatsignierungsanforderung (CSR) an den Auto-PKI-Dienst in der Zoom Cloud. Dieser Dienst arbeitet dann mit CA-Anbietern zusammen, um das Zertifikat auszustellen, das die SAN-Liste und das CN-Feld aus dem vorherigen Schritt enthält. 7. **Lokale Speicherung**: Schreibt das im letzten Schritt neu ausgestellte x509-Zertifikat und den zugehörigen privaten Schlüssel (zuvor generiert) in den lokalen Speicher und macht sie für die auf der Node-Instanz ausgeführten Dienste Verfügbar. Auto PKI vereinfacht die Zertifikatverwaltung auf Zoom Node, indem es Ablaufdaten automatisch überwacht und neue Zertifikate anfordert, sodass keine manuelle Erneuerung erforderlich ist. #### Eigene Zertifikate verwenden (BYOC) Sie können Ihre eigenen gültigen, öffentlich signierten Zertifikate über die lokale Weboberfläche auf Zoom Node installieren. Dies ist entweder während der Erstinstallation oder zu einem späteren Zeitpunkt möglich. Der Prozess wird Personen vertraut sein, die daran gewöhnt sind, Zertifikate in webbasierten Anwendungen zu installieren. Wenn Sie sich für die Verwendung eigener Zertifikate entscheiden, denken Sie daran, dass sich das Zertifikat auf einem Server befindet, der mit mehreren Hostnamen kommuniziert. Daher muss der von Ihnen zu Wählen Zertifikattyp die Verschlüsselung von Datenverkehr unterstützen, der von mehr als einem Hostnamen ausgeht (Zertifikat-CN). Alle für Node und bereitgestellte Dienste verwendeten Hostnamen müssen durch die Cloud-Dienste von Zoom öffentlich auflösbar sein. Zoom empfiehlt zwei Arten von Zertifikaten: * **Wildcard-Zertifikat** * **Multi-SAN-Zertifikat** (auch als Multi-Domain-Zertifikat, SAN-Zertifikat oder UCC-Zertifikat bekannt) {% hint style="danger" %} Ein typisches Einzel-Host-Zertifikat funktioniert nicht mit Zoom Node, außer in dem speziellen Szenario, in dem eine einzelne IP-Adresse und ein Hostname zwischen Zoom Node und einem einzelnen Modul gemeinsam genutzt werden. Weitere Informationen finden Sie im ZPLS-Diagramm in der [#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname](#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname "mention") Abschnitt. {% endhint %} **Wildcard-Zertifikate: Zur Vereinfachung empfohlen** Ein Wildcard-Zertifikat kann Datenverkehr von jedem Hostnamen in der Domäne verschlüsseln. Beispiel: Ein Wildcard-Zertifikat wie \*.customer.com kann Datenverkehr verschlüsseln von `host1.customer.com` und `host2.customer.com` oder einem beliebigen Namen innerhalb von `.customer.com`. Wenn Sie Zoom Node bereitstellen und das Wildcard-Zertifikat installieren, verschlüsselt es automatisch den Datenverkehr für alle Dienste, die Sie auf dem Node bereitstellen, vorausgesetzt, dass alle bereitgestellten Dienste einen Fully Qualified Domain Name (FQDN) aus der Wildcard-Domäne verwenden. Dadurch wird der Aufwand für die Bereitstellung von Diensten auf dem Node minimiert: Sie müssen die Namen der Dienste nicht kennen, bevor Sie sie bereitstellen. Wenn Sie jedoch die Multi-SAN-Zertifikatmethode verwenden, müssen Sie die Dienstnamen kennen. **Multi-SAN-, Multi-Domain-, SAN- oder UCC-Zertifikate** {% hint style="warning" %} Sie müssen die Hostnamen und IP-Adressen kennen, die Sie für den Node (bis zu einer \[1]) und für alle Dienste verwenden werden, die Sie installieren (bis zu vier \[4]). **Diese Informationen sind vor der Beantragung eines Zertifikats erforderlich**. {% endhint %} Ein Multi-SAN-Zertifikat ist für Zoom Node erforderlich, da es Datenverkehr von fünf (5) Hostnamen verschlüsselt. Eine einmalige Anforderung für dieses Zertifikat setzt voraus, dass alle notwendigen Informationen im Voraus bekannt sind, einschließlich geplanter Node-Namen und der Namen aller Dienste, die auf dem Node bereitgestellt werden sollen. Bei einem Modul wie ZPLS wird beispielsweise nur ein ZPLS-Modul pro Node bereitgestellt, sodass für den ZPLS-Dienst-Hostnamen nur ein zusätzliches SAN erforderlich ist. Die folgende Tabelle kann als Beispiel verwendet werden: | Hostname (SAN) | IP-Adresse | | ----------------------------------------------- | ------------------ | | `zoom-node01.company.com` | `10.1.50.100` | | `zpls.company.com` | `10.1.50.100` | | `zoom-recording.company.com` | `10.1.50.101` | | `zoom-webinar.company.com` | `10.1.50.102` | | (Dienst 4 – in diesem Beispiel nicht verwendet) | (Nicht zutreffend) | Dieses Beispiel zeigt eine typische Konfiguration, bei der ein Node ZPLS auf derselben IP-Adresse sowie zwei zusätzliche Dienste auf separaten IP-Adressen hostet. Ersetzen Sie „company.com“ durch Ihre tatsächliche Domäne und verwenden Sie die IP-Adressen Ihres Netzwerks. **Anforderungen an die DNS-Auflösung** Zoom erfordert, dass die Hostnamen öffentlich auflösbar sind, damit gegenseitiges Vertrauen hergestellt werden kann. Alle Zoom-Node-Hostnamen und alle auf den Nodes bereitgestellten Dienst-Hostnamen müssen in der DNS-Zone enthalten sein. Wenn Ihr Unternehmen separate interne und externe DNS-Dienste oder Domains betreibt, müssen die Hostnamen von Zoom Node in einer Zone gehostet werden, die von Ihren externen DNS-Servern aufgelöst werden kann (kann darauf beschränkt werden, nur für Zoom-IP-Bereiche aufgelöst zu werden). Ihre internen Zoom-Benutzer und die Zoom Cloud müssen mithilfe desselben Satzes von Hostnamen kommunizieren. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://library.zoom.com/technical-library/de/erweiterte-enterprise-services/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.