# Ü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 Dienst erfordert eine eindeutige IP-Adresse. Einem Zoom Node werden bis zu fünf (5) IP-Adressen zugewiesen, 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, auf dem ein einzelner Dienst (z. B. ZPLS) ausgeführt wird, kann mit einer einzigen IP-Adresse bereitgestellt werden, wenn Node und Dienst so zugewiesen sind, dass sie dieselbe IP-Adresse verwenden. 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 Anforderungen an die IP- und Zertifikatskonfiguration für die Bereitstellung zusammen **Zoom Meetings Hybrid** in lokalen oder hybriden Cloud-Umgebungen. Die folgende Tabelle gliedert den Beispiel-Node auf und umfasst seine aktiven Proxy- und MMR-Service-Module: | Komponente | Hostname | TLS-Zertifikat Rolle | Funktion | | --------------------- | -------------------- | ------------------------------ | ------------------------------------- | | Node Betriebssystem | `node1.customer.com` | Common Name (CN) | Kernorchestrierung | | Zoom Connector Proxy | `zcp1.customer.com` | Subject Alternative Name (SAN) | Signalisierung und Sitzungskontrolle | | 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. Erforderliche Gesamtzahl der IP-Adressen: fünf (5) {% endhint %}
Das obige Bild skizziert die Mindestkonfiguration, die für die Bereitstellung erforderlich ist **Lokale Ausfallsicherheit für Zoom Phone (ZPLS)**. ZPLS ermöglicht eine fortgesetzte Verfügbarkeit des Telefondienstes im Event einer Unterbrechung des Internets oder der Cloud, 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 | TLS-Zertifikat Rolle | 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), damit sowohl der oben aufgeführte CN als auch die SANs enthalten sind. Dies ermöglicht eine ordnungsgemäße TLS-Validierung für eine sichere Kommunikation zwischen den Modulen. **Anforderungen an die IP-Adresse** | Kennzahl | Wert / Beschreibung | | ---------------------------------------- | --------------------------------------------------- | | Erforderliche Gesamtzahl der 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 im ZPLS nur zwei (2) IP-Adressen aktiv verwendet** in der ZPLS-Bereitstellung: eine pro Modul, ausgeführt auf einem **dedizierte Node-VM**. {% hint style="warning" %} ZPLS erlaubt nur ein Modul pro Node-VM. Sie können ZPLS nicht zusammen mit anderen Zoom-Modulen auf derselben VM platzieren. {% 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. Bei Bedarf können Sie die erste IP/den ersten Hostnamen zwischen dem Betriebssystem und dem ersten Modul gemeinsam verwenden, um die Anzahl der erforderlichen IP-Adressen, Hostnamen und Subject Alternative Names (SANs) zu reduzieren. ### Option 2: Mit gemeinsam genutzter IP und gemeinsam genutztem Hostnamen bereitgestelltes Zoom Meetings Hybrid
Diese Konfiguration wiederholt die Node-Struktur, wie sie im Zoom Meetings-Hybriddiagramm von Option 1 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). Dadurch wird die IP-Nutzung reduziert, während die TLS- und funktionalen Anforderungen weiterhin erfüllt werden. 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 | TLS-Zertifikat Rolle | Funktion | | -------------------------- | ------------------- | ------------------------------ | ------------------------------------- | | ZCP (Zoom Connector Proxy) | `zcp1.customer.com` | Common Name (CN) | Signalisierung und Sitzungskontrolle | | 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. **Anforderungen an die IP-Adresse** | Kennzahl | Wert / Beschreibung | | ---------------------------------------- | -------------------------------------------------------------------- | | Erforderliche Gesamtzahl der IP-Adressen | 4 | | IP-Sharing-Strategie | Das Node-Betriebssystem teilt sich die IP mit dem ersten Modul (ZCP) | | Einzelne IPs erforderlich für | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Wenn die IP-Adresse **geteilt** zwischen dem Node-Betriebssystem und dem ersten bereitgestellten Modul (ZCP) nur **vier (4) IP-Adressen** erforderlich. Dieses Design optimiert die IP-Nutzung und erfüllt gleichzeitig die Bereitstellungsstandards. {% endhint %}
Das obige Bild zeigt eine minimale ZPLS-Bereitstellung, bei der die **Node Betriebssystem 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` **Hostname-Funktionszuordnung** | Komponente | Hostname | TLS-Zertifikat Rolle | 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. **Anforderungen an die IP-Adresse** | Kennzahl | Wert / Beschreibung | | ---------------------------------------- | ----------------------------------------------------------------- | | Erforderliche Gesamtzahl der IP-Adressen | 1 | | IP-Sharing-Strategie | Node-Betriebssystem und ZPLS teilen sich eine einzelne IP-Adresse | | Bereitstellungseinschränkung | Nur ein Modul pro Node-VM zulässig (nur ZPLS) | {% hint style="warning" %} ZPLS ist das einzige unterstützte Szenario in der Zoom Node-Architektur, in der: * Ein Single-Host-Zertifikat (nur CN) ist akzeptabel * Aufgrund der IP-Freigabe zwischen Betriebssystem und Modul ist für die Bereitstellung nur eine (1) IP-Adresse erforderlich * Die gemeinsame Unterbringung zusätzlicher Module auf derselben VM wird nicht unterstützt {% endhint %} ### Entscheiden Sie, welche Zertifikatverwaltungsmethode 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-Vertrauungsliste von Zoom Node signiert ist. Dies schließt bekannte öffentliche Stellen ein. Zoom Node bietet zwei Zertifikatverwaltungsmethoden: * **Auto PKI**: Diese innovative Lösung automatisiert die sichere Zertifikat-Registrierung und -Erneuerung bei öffentlich vertrauenswürdigen Zertifizierungsstellen (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, signiert von einer beliebigen großen öffentlich vertrauenswürdigen CA. Sie kümmern sich um die Zertifikat-Registrierung und -Erneuerungen. Zusätzliche Überlegungen gelten hinsichtlich des Potenzials von Zoom Node für bis zu fünf Hostnamen/SANs bei Verwendung von kundenseitig bereitgestellten Zertifikaten, die weiter unten näher erläutert werden. #### Automatische Zertifikat-Verwaltung 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. Die Zertifikat-Erneuerung wird ebenfalls automatisch durchgeführt. Dies vereinfacht die Zertifikat-Verwaltung für alle Dienste und Zoom Node selbst. #### Verständnis der Auto PKI Zertifikat-Registrierung und -Erneuerung Das folgende Szenario kann Ihnen helfen zu verstehen, wie die Zertifikat-Registrierung und -Erneuerung funktioniert. Zum Beispiel: Ein Administrator hat eine neue Node-Instanz bereitgestellt. Jede Instanz erfordert 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. **Abruf von Vorlagen**: Ruft alle unterstützten Konfigurationsvorlagen ab, einschließlich Optionen für mehrere CA-Anbieter, vom Auto-PKI-Dienst in der Zoom Cloud. 2. **Erfassung von IP-Adressen**: Sammelt 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 eine Reihe von DNS-Namen im Format `..zoomonprem.com`. Diese Domains sind mit A-/AAAA-Einträgen konfiguriert. 4. **Anforderung eines reservierten DNS-Namens**: Fordert einen reservierten DNS-Namen im Format `rsvd-..zoomonprem.com`. 5. **Erzeugung der Zertifikatsanforderung**: Erzeugt eine x509-Zertifikatsanforderung und verwendet die DNS-Namen aus dem dritten Schritt im SAN-Feld sowie den reservierten Namen aus dem vierten Schritt im Feld Common Name (CN). 6. **Zertifikatsausstellung**: Sendet die Zertifikatssignierungsanforderung (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 dazugehörigen privaten Schlüssel (der zuvor generiert wurde) in den lokalen Speicher und macht sie für Dienste verfügbar, die auf der Node-Instanz ausgeführt werden. Auto PKI vereinfacht die Zertifikatsverwaltung auf Zoom Node, indem Ablaufdaten automatisch überwacht und neue Zertifikate angefordert werden, wodurch eine manuelle Erneuerung überflüssig wird. #### 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 ist denjenigen vertraut, 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 Zertifikatstyp, den Sie Wählen, die Verschlüsselung für Datenverkehr unterstützen, der von mehr als einem Hostnamen ausgeht (Zertifikat-CN). Alle für Node und alle bereitgestellten 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 Single-Host-Zertifikat funktioniert mit Zoom Node nicht, 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. Zusätzlichen Kontext 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") . {% endhint %} **Wildcard-Zertifikate: Aus Gründen der Einfachheit empfohlen** Ein Wildcard-Zertifikat kann Datenverkehr von jedem Hostnamen in der Domain verschlüsseln. Zum Beispiel: Ein Wildcard-Zertifikat wie \*.customer.com kann Datenverkehr verschlüsseln von `host1.customer.com` als auch `host2.customer.com` oder jedem 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, wobei vorausgesetzt wird, dass alle bereitgestellten Dienste einen Fully Qualified Domain Name (FQDN) aus der Wildcard-Domain verwenden. Dies minimiert den Aufwand für die Bereitstellung von Diensten auf dem Node: Sie müssen die Namen der Dienste nicht kennen, bevor Sie sie bereitstellen. Sie müssen die Dienstnamen jedoch kennen, wenn Sie die Multi-SAN-Zertifikatmethode 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 (bis zu eine \[1]) und alle Dienste verwenden werden, die Sie installieren werden (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 erfordert die vorherige Kenntnis aller notwendigen Informationen, einschließlich geplanter Node-Namen und der Namen aller Dienste, die für die Bereitstellung auf dem Node vorgesehen sind. Zum Beispiel wird bei einem Modul wie ZPLS nur ein ZPLS-Modul pro Node bereitgestellt, sodass nur ein zusätzliches SAN für den ZPLS-Dienst-Hostnamen benötigt wird. 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/V) | Dieses Beispiel zeigt eine typische Konfiguration, bei der ein Node ZPLS auf derselben IP hostet sowie zwei zusätzliche Dienste auf separaten IPs. Ersetzen Sie „company.com“ durch Ihre tatsächliche Domain und verwenden Sie die IP-Adressen Ihres Netzwerks. **Anforderungen an die DNS-Auflösung** Zoom erfordert, dass die Hostnamen öffentlich auflösbar sind, damit eine beidseitige Vertrauensstellung hergestellt 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 verwendet, müssen die Zoom Node-Hostnamen 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 aufzulösen). Ihre internen Zoom-Benutzer und die Zoom Cloud müssen mithilfe desselben Hostnamen-Satzes kommunizieren. --- # 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/erweiterte-enterprise-services/zoom-node/zoom-node-deployment-field-guide/zoom-node-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.