> 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 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 Service erfordert eine eindeutige IP-Adresse. Ein Zoom Node hat bis zu fünf (5) IP-Adressen zugewiesen, wenn dem Node eine bestimmte Adresse für die Verwaltung und je eine für jeden bereitgestellten Service (bis zu vier) auf dem Node zugewiesen wurde. Ein Zoom Node, auf dem ein einzelner Service (z. B. ZPLS) läuft, kann mit einer einzelnen IP-Adresse bereitgestellt werden, wenn Node und Service so zugewiesen sind, dass sie dieselbe IP-Adresse gemeinsam nutzen. Im Folgenden werden mehrere Bereitstellungsoptionen 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 IP- und Zertifikatskonfigurationsanforderungen für die Bereitstellung von **Zoom Meetings Hybrid** in lokalen oder hybriden Cloud-Umgebungen zusammen. Die folgende Tabelle gliedert den Beispiel-Node auf und enthält seine aktiven Proxy- und MMR-Service-Module: | Komponente | Hostname | TLS-Zertifikatsrolle | Funktion | | --------------------- | -------------------- | ------------------------------ | ------------------------------------- | | Node-Betriebssystem | `node1.customer.com` | Common Name (CN) | Kernorchestrierung | | Zoom Connector Proxy | `zcp1.customer.com` | Subject Alternative Name (SAN) | Signalgebung und Sitzungssteuerung | | Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (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 zeigt die minimale Konfiguration, die für die Bereitstellung von **Zoom Phone Local Survivability (ZPLS)**erforderlich ist. ZPLS ermöglicht die fortgesetzte Verfügbarkeit des Telefondienstes bei einer Störung des Internets oder der Cloud, indem die Survivability-Logik 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` **Funktionale Zuordnung des Hostnamens** | Komponente | Hostname | TLS-Zertifikatsrolle | Funktion | | ------------------- | -------------------- | ------------------------ | ------------------------------------ | | Node-Betriebssystem | `node1.customer.com` | Common Name (CN) | Kernorchestrierung | | ZPLS-Modul | `zplsl.customer.com` | Subject Alternative Name | Zoom Phone Local Survivability-Logik | **TLS-Zertifikatskonfiguration** | Feld | Wert | | ------------------------- | -------------------- | | Common Name (CN) | `node1.customer.com` | | Subject Alternative Names | `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 eine sichere Kommunikation zwischen den Modulen. **IP-Adressenanforderungen** | Kennzahl | Wert / Beschreibung | | ----------------------------------- | --------------------------------------------------- | | Insgesamt erforderliche IP-Adressen | 5 (allgemeine Zuweisung) | | Im ZPLS-Kontext verwendet | 2 IPs (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: jeweils eins pro Modul, ausgeführt auf einer **dedizierten 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 platzieren. {% endhint %} Wie unterscheiden sich diese Diagramme? Das erste Bild zeigt ein Beispiel einer Zoom Meetings Hybrid-Bereitstellung. Das zweite Bild zeigt ein Beispiel einer Zoom Phone Local Survivability-Bereitstellung. Bei Bedarf können Sie die erste IP/den ersten Hostnamen zwischen dem Betriebssystem und dem ersten Modul gemeinsam nutzen, um die Anzahl der erforderlichen IP-Adressen, Hostnamen und Subject Alternative Names (SANs) zu reduzieren. ### Option 2: Zoom Meetings Hybrid mit gemeinsam genutzter IP und gemeinsam genutztem Hostnamen bereitgestellt
Diese Konfiguration wiederholt die Node-Struktur, wie sie im Diagramm für Option 1 Zoom Meetings Hybrid zu sehen ist. In dieser Bereitstellung jedoch **teilt das Node-Betriebssystem seine IP-Adresse mit dem zuerst bereitgestellten Modul** (typischerweise dem Zoom Connector Proxy, ZCP). Dies führt zu einer geringeren IP-Nutzung bei gleichzeitiger Einhaltung der TLS- und funktionalen Anforderungen. 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` **Funktionale Zuordnung des Hostnamens** | Komponente | Hostname | TLS-Zertifikatsrolle | Funktion | | -------------------------- | ------------------- | ------------------------------ | ------------------------------------- | | ZCP (Zoom Connector Proxy) | `zcp1.customer.com` | Common Name (CN) | Signalgebung und Sitzungssteuerung | | Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Medienweiterleitung und -verarbeitung | | Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Medienweiterleitung und -verarbeitung | **TLS-Zertifikatskonfiguration** | Feld | Wert | | ------------------------- | ------------------------------------------------------------- | | Common Name (CN) | `zcp1.customer.com` | | Subject Alternative Names | `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. **IP-Adressenanforderungen** | Kennzahl | Wert / Beschreibung | | ------------------------------------------------ | ---------------------------------------------------------------- | | Insgesamt erforderliche IP-Adressen | 4 | | IP-Sharing-Strategie | Node-Betriebssystem teilt sich die IP mit dem ersten Modul (ZCP) | | Für Folgendes sind individuelle IPs erforderlich | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Wenn die IP-Adresse **gemeinsam genutzt wird** zwischen dem Node-Betriebssystem und dem ersten bereitgestellten Modul (ZCP), werden nur **vier (4) IP-Adressen** benötigt. Dieses Design optimiert die IP-Nutzung und entspricht dennoch den Bereitstellungsstandards. {% endhint %}
Das obige Bild zeigt eine minimale ZPLS-Bereitstellung, bei der das **Betriebssystem des Node teilt seine IP-Adresse mit dem installierten ZPLS-Modul**. Dies ist das **einzige Szenario** im Zoom Node-Framework, in dem ein **TLS-Zertifikat für einen einzelnen Host** gültig ist. Der folgende Hostname muss in DNS konfiguriert und im TLS-Zertifikat enthalten sein: * `zplsl.customer.com` **Funktionale Zuordnung des Hostnamens** | Komponente | Hostname | TLS-Zertifikatsrolle | Funktion | | ---------- | -------------------- | -------------------- | ------------------------------------ | | ZPLS-Modul | `zplsl.customer.com` | Common Name (CN) | Zoom Phone Local Survivability-Logik | **TLS-Zertifikatskonfiguration** | Feld | Wert | | ---------------- | -------------------- | | Common 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. **IP-Adressenanforderungen** | Kennzahl | Wert / Beschreibung | | ----------------------------------- | ----------------------------------------------------------------- | | Insgesamt erforderliche IP-Adressen | 1 | | IP-Sharing-Strategie | Node-Betriebssystem und ZPLS teilen sich eine einzelne IP-Adresse | | Bereitstellungsbeschränkung | Pro Node-VM ist nur ein Modul zulässig (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 akzeptabel * Aufgrund der IP-Adressfreigabe zwischen Betriebssystem und Modul ist für die Bereitstellung nur eine (1) IP-Adresse erforderlich * Die Co-Lokation zusätzlicher Module auf derselben VM wird nicht unterstützt {% endhint %} ### Entscheiden Sie, welche Zertifikatsverwaltungsmethode für Ihre Bereitstellungen am besten geeignet ist Jedes auf Zoom Node bereitgestellte Service-Modul erfordert ein gültiges Zertifikat, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle (CA) aus der Zertifikat-Vertrauensliste von Zoom Node signiert wurde. Dies umfasst bekannte öffentliche Zertifizierungsstellen. Zoom Node bietet zwei Methoden zur Zertifikatverwaltung: * **Auto PKI**: Diese innovative Lösung automatisiert die sichere Zertifikatregistrierung und -erneuerung bei öffentlich vertrauenswürdigen Zertifikat Authorities (CAs). Zoom übernimmt die mit der Registrierung und Erneuerung verbundenen Kosten. * **Bring Your Own Zertifikat (BYOC)**: Mit dieser Option stellen Sie Ihre eigenen Zertifikate bereit, die von einer großen öffentlich vertrauenswürdigen CA signiert sind. Sie kümmern sich um die Zertifikatregistrierung und -erneuerungen. Zusätzliche Überlegungen gelten in Bezug auf das Potenzial von Zoom Node für bis zu fünf Hostnamen/SANs bei der Verwendung von kundenseitig bereitgestellten Zertifikaten, die weiter unten näher erläutert werden. #### Automatische Zertifikatverwaltung 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 Zertifikaterneuerung wird automatisch durchgeführt. Dies vereinfacht die Zertifikatverwaltung für alle Dienste und für Zoom Node selbst. #### Verständnis der Auto-PKI-Zertifikatregistrierung und -erneuerung Das folgende Szenario kann Ihnen helfen zu verstehen, wie die Zertifikatregistrierung 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 ab, einschließlich Optionen für mehrere CA-Anbieter, vom Auto-PKI-Dienst in der Zoom Cloud. 2. **IP-Adressen-Sammlung**: Erfasst alle IP-Adressen, die von auf dem Node ausgeführten Diensten verwendet werden, und sendet sie an den Auto-PKI-Dienst in der Zoom Cloud. 3. **Bereitstellung von DNS-Namen**: Der Auto-PKI-Cloud-Dienst gibt eine Reihe von DNS-Namen im Format zurück `..zoomonprem.com`. Diese Domänen werden mit A/AAAA-Einträgen konfiguriert. 4. **Anfrage für reservierten DNS-Namen**: Fordert einen reservierten DNS-Namen im Format an `rsvd-..zoomonprem.com`. 5. **Generierung der Zertifikatanforderung**: Generiert eine x509-Zertifikatanforderung unter Verwendung der DNS-Namen aus dem dritten Schritt im SAN-Feld und des reservierten Namens aus dem vierten Schritt im Common Name (CN)-Feld. 6. **Zertifikatausstellung**: Sendet die Zertifikatsanforderung zur Signierung (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. **Lokaler Speicher**: Schreibt das neu ausgestellte x509-Zertifikat aus dem letzten Schritt und den dazugehörigen privaten Schlüssel (zuvor generiert) in den lokalen Speicher und macht sie für auf der Node-Instanz laufende Dienste Verfügbar. Auto PKI vereinfacht die Zertifikatverwaltung auf Zoom Node, indem es Ablaufdaten automatisch überwacht und neue Zertifikate anfordert, wodurch die manuelle Verlängerung entfällt. #### Bring Your Own Certificates (BYOC) Sie können Ihre eigenen gültigen, öffentlich signierten Zertifikate auf Zoom Node über die lokale Weboberfläche installieren. Dies können Sie entweder während der Erstinstallation oder zu einem späteren Zeitpunkt tun. Der Prozess wird denjenigen vertraut sein, die daran gewöhnt sind, Zertifikate auf webbasierten Anwendungen zu installieren. Wenn Sie sich dafür entscheiden, Ihre eigenen Zertifikate zu verwenden, denken Sie daran, dass sich das Zertifikat auf einem Server befindet, der mit mehreren Hostnamen kommuniziert. Daher muss der von Ihnen gewählte Zertifikatstyp Verschlüsselung für Traffic unterstützen, der von mehr als einem Hostnamen (Zertifikat-CN) stammt. Alle für Node und alle bereitgestellten Dienste verwendeten Hostnamen müssen von den Cloud-Diensten von Zoom öffentlich auflösbar sein. Zoom empfiehlt zwei Arten von Zertifikaten: * **Wildcard-Zertifikat** * **Multi-SAN-Zertifikat** (auch bekannt als Multi-Domain-Zertifikat, SAN-Zertifikat oder UCC-Zertifikat) {% hint style="danger" %} Ein typisches Zertifikat für einen einzelnen Host 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 geteilt werden. Für zusätzlichen Kontext siehe das 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: Aus Gründen der Einfachheit empfohlen** Ein Wildcard-Zertifikat kann Traffic von jedem Hostnamen in der Domäne verschlüsseln. Zum Beispiel: Ein Wildcard-Zertifikat wie \*.customer.com kann Traffic verschlüsseln von `host1.customer.com` und `host2.customer.com` oder jeder beliebige Name innerhalb von `.customer.com`. Wenn Sie Zoom Node bereitstellen und das Wildcard-Zertifikat installieren, wird der Datenverkehr für alle Dienste, die Sie auf dem Node bereitstellen, automatisch verschlüsselt, wobei die Voraussetzung gilt, dass alle bereitgestellten Services 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. Sie müssen die Servicenamen jedoch kennen, wenn Sie die Multi-SAN-Zertifikat-Methode verwenden. **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 verwenden werden (bis zu einem \[1]) und alle Services, die Sie installieren werden (bis zu vier \[4]). **Diese Informationen sind vor der Registrierung eines Zertifikats erforderlich**. {% endhint %} Für Zoom Node ist ein Multi-SAN-Zertifikat erforderlich, da es den Datenverkehr von fünf (5) Hostnamen verschlüsselt. Eine einmalige Anfrage für dieses Zertifikat erfordert die vorherige Kenntnis aller erforderlichen Informationen, einschließlich der geplanten Node-Namen und der Namen aller Services, die für die Bereitstellung auf dem Node vorgesehen sind. Beispielsweise wird bei einem Modul wie ZPLS nur ein einziges ZPLS-Modul pro Node bereitgestellt, sodass nur ein zusätzliches SAN für den Hostnamen des ZPLS-Services 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) | (n. z.) | Dieses Beispiel ist eine typische Konfiguration, mit einem Node, der ZPLS auf derselben IP hostet, plus zwei zusätzlichen Diensten auf separaten IPs. Ersetzen Sie „company.com“ durch Ihre tatsächliche Domain und verwenden Sie die IP-Adressen Ihres Netzwerks. **DNS-Auflösungsanforderungen** Zoom erfordert, dass die Hostnamen öffentlich auflösbar sind, damit ein wechselseitiges Vertrauen aufgebaut werden kann. Alle Zoom Node-Hostnamen und alle auf den Nodes bereitgestellten Service-Hostnamen müssen in der DNS-Zone enthalten sein. Wenn Ihr Unternehmen separate interne und externe DNS-Dienste oder Domänen betreibt, müssen die Zoom Node-Hostnamen in einer Zone gehostet werden, die von Ihren externen DNS-Servern auflösbar ist (kann darauf beschränkt werden, nur für Zoom-IP-Bereiche aufzulösen). Ihre internen Zoom-Benutzer und die Zoom Cloud müssen über denselben Satz 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 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/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 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.