> 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-infrastructure-prerequisites.md).
# Infrastrukturanforderungen für Zoom Node
Nutzen Sie diese Voraussetzungen, um Ihr Unternehmen auf eine Zoom-Node-Bereitstellung vorzubereiten.
In diesem Abschnitt werden die Hardware- und Softwarevoraussetzungen für Zoom Node-Bereitstellungen einschließlich der Modulinstallation beschrieben.
### Aufbau Ihrer hybriden Kommunikationsgrundlage
Hardware- und Software-Referenzen für jedes Bereitstellungsszenario sind unten aufgeführt.
#### Unterstützte Hypervisoren
Das Verständnis der Hypervisor-Kompatibilität ermöglicht es Ihrem Unternehmen, vorhandene Virtualisierungsinvestitionen zu nutzen und gleichzeitig die vollständige Zoom Node-Funktionsunterstützung beizubehalten.
| Hypervisor-Plattform | Mindestversionsanforderung | Strategische Implementierungsüberlegungen |
| ---------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **VMware vSphere/ESXi** | 6.7 oder höher | Branchenübliche Standardwahl mit der breitesten Kompatibilität, ideal für Unternehmen mit vorhandener VMware-Infrastruktur |
| **Proxmox VE** | Proxmox 8.x oder 9.0.x (nur VM/keine LXC-Unterstützung) | Kostengünstige Open-Source-Option, die sowohl Proxmox VE- als auch virt-manager-Implementierungen unterstützt |
| **Nutanix AHV** | AOS 6.10.x oder 7.x (nur VM/keine LXC-Unterstützung) | Optimal für Unternehmen, die Hyper-Converged-Infrastrukturstrategien nutzen |
| **Microsoft Hyper-V Server** | Hyper-V Server 2019 oder höher | Nahtlose Integration für Windows-zentrierte Umgebungen |
| **AWS EC2** | Aktuelle Version | Nahtlose Integration für Windows-zentrierte Umgebungen |
{% hint style="info" %}
Kontaktieren Sie den Zoom-Support für die Validierung bestimmter Hyper-V-Versionen.
{% endhint %}
#### Hardware-Spezifikationen der virtuellen Maschine
Die folgenden Spezifikationen decken Standard- und Mindesthardwareanforderungen ab.
**Standard-Produktionskonfiguration**
Diese Konfiguration ermöglicht es Unternehmen auf Enterprise-Ebene, die Zoom Node-Funktionen zu maximieren, indem sie bis zu vier (4) gleichzeitige Service-Module pro Node unterstützt.
| Infrastrukturkomponente | Technische Spezifikation | Geschäftsauswirkungen und Implementierungsbegründung |
| ----------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| **CPU-Architektur** | 64-Bit Intel E5-2650v4 oder neuer @ 2.0 GHz+ AMD 64-Bit @ 2.0 GHz+ | Unterstützt Echtzeit-Medienverarbeitungsfunktionen, die für qualitativ hochwertige Benutzererlebnisse unerlässlich sind |
| **Zuweisung virtueller CPUs** | 8 vCPUs | Ermöglicht den gleichzeitigen Betrieb mehrerer hybrider Dienste ohne Leistungseinbußen |
| **Speicherzuweisung** | 16 GB RAM | Unterstützt speicherintensive Vorgänge einschließlich Transkodierung und Medien-Weiterleitung |
| **Speicherbereitstellung** | 200 GB HDD | Bietet Platz für das Betriebssystem, Service-Module, Protokolle und temporären Medienspeicher |
| **Netzwerkschnittstelle** | 10 GB virtuelle NIC | Verhindert Netzwerkengpässe bei Szenarien mit hoher Medienverarbeitungslast |
**Mindestkonfiguration für den praktischen Einsatz**
Diese Konfiguration eignet sich für erste Tests, Proof-of-Concepts, Laborumgebungen oder Bereitstellungen mit einem einzelnen Dienst und begrenzter gleichzeitiger Nutzung.
| Infrastrukturkomponente | Mindestspezifikation | Geeignete Anwendungsfälle und Einschränkungen |
| ----------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------- |
| **Zuweisung virtueller CPUs** | 3 vCPUs | Testumgebungen, Bereitstellungen mit einem Dienst |
| **Speicherzuweisung** | 6–8 GB RAM | Eingeschränkte Unterstützung für gleichzeitige Benutzer, möglicherweise ist Skalierung erforderlich |
| **Speicherbereitstellung** | 200 GB HDD | Basic-Speicher nur für wesentliche Vorgänge |
| **Netzwerkschnittstelle** | Virtuelle NIC mit 1 GB/s | Ausreichend für Implementierungen mit geringem Volumen |
{% hint style="warning" %}
**Kritische Leistungsüberlegung**: Organisationen müssen planen, von Mindest- auf Produktions-Standard-Spezifikationen zu skalieren, wenn die Nutzungsmuster wachsen. Der Betrieb eines Produktionssystems mit Mindest-Spezifikationen wird nicht unterstützt und führt wahrscheinlich zu Leistungs- oder Installationsproblemen.
{% endhint %}
### Netzwerkarchitektur und Voraussetzungen für die Konnektivität: Zuverlässige hybride Kommunikation sicherstellen
Dieser Abschnitt beschreibt die verbindlichen Anforderungen an Netzwerk, IP-Adressierung und DNS, die für eine nahtlose Service-Integration und zuverlässige Kommunikation mit der Cloud-Infrastruktur von Zoom erforderlich sind.
#### Grundlegende Netzwerkanforderungen
Diese unverzichtbaren Netzwerkkonfigurationen bilden die Grundlage für erfolgreiche Zoom Node-Implementierungen.
| Netzwerkanforderung | Technische Spezifikation | Kritische Auswirkungen auf die Implementierung |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **VM-Netzwerktyp** | Bridged-/direkte VM-Vernetzung erforderlich | Ermöglicht die direkte Kommunikation zwischen Client und Node, die für hybride Dienste unerlässlich ist |
| **NAT-Konfiguration** | NICHT unterstützt – die VM darf nicht hinter dem NAT des Hypervisors liegen | Verhindert Kommunikationsfehler zwischen Clients und Zoom Node-Diensten |
| **Internetverbindung** | Erforderlich für die Integration von Cloud-Diensten | Ermöglicht die Funktionalität hybrider Dienste und die Kommunikation der Management-Ebene |
| **Proxyserver-Support** | Unterstützt für die Kommunikation des Zoom Node-Betriebssystems. Der Proxy-Support variiert je nach Service-Modul-Familie; prüfen Sie die Moduldokumentation. | Ermöglicht zuverlässige Cloud-Dienstkonnektivität ohne Zwischenschicht-Komplikationen |
| **Interne Adressierung** | RFC-1918-Adressierung vollständig unterstützt | Ermöglicht eine nahtlose Integration in bestehende Enterprise-Netzwerkschemata |
#### Matrix zur IP-Adressplanung
Die strategische Zuweisung von IP-Adressen ermöglicht eine flexible Servicebereitstellung und zukünftige Erweiterung.
| Bereitstellungsarchitektur | Anforderungen an IP-Adressen | Implementierungsflexibilität und Wachstumspfad |
| --------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Standard-Multi-Service-Node** | 1 eindeutige IP-Adresse pro Service (insgesamt bis zu 4) | Maximale Flexibilität bei der Bereitstellung, unterstützt eine schrittweise Einführung von Diensten |
| **Hybride WAG-Implementierung** | 2 dedizierte IP-Adressen erforderlich | Ermöglicht redundante Web-Anwendungs-Gateway-Dienste |
| **Konsolidierte Bereitstellung** | 1 gemeinsam genutzte IP-Adresse für Node + primäres Modul | Beschränkt auf bestimmte Szenarien mit geringer Komplexität |
| **Hochverfügbarkeitsarchitektur** | Mehrere IP-Adressen über verteilte Komponenten hinweg | Unterstützt Enterprise-Anforderungen an die Überlebensfähigkeit |
#### Anforderungen an die DNS-Architektur
Eine korrekte DNS-Konfiguration gewährleistet zuverlässige Serviceerkennung und Zertifikatvalidierung.
**Kritische Anforderungen an die DNS-Implementierung**
* **Verbindliche öffentliche DNS-Auflösung**: Alle Zoom Node-Hostnamen müssen über eine öffentliche DNS-Infrastruktur aufgelöst werden
* **Split-Horizon-DNS Support**: Externe DNS-Zonen müssen Node-Hostnamen für Zoom Cloud-IP-Bereiche auflösen
* **Survivability-DNS-Architektur**: Lokale DNS-Server müssen während Internetausfällen Verfügbar bleiben
* **Namenskonsistenz-Anforderung**: Interne Benutzer und Zoom Cloud-Infrastruktur müssen auf identische Hostnamen verweisen
{% hint style="info" %}
**Implementierungs-Best Practice**: Dokumentieren und validieren Sie alle DNS-Einträge vor der Bereitstellung, um Zertifikat- und Verbindungsprobleme zu verhindern.
{% endhint %}
### Zertifikatmanagementstrategie: Absicherung Ihrer hybriden Kommunikation
Dieser Abschnitt beschreibt verfügbare Zertifikatoptionen – automatisiert oder BYOC – und bietet Planungsleitlinien, um sie an die Sicherheitsrichtlinien und Bereitstellungsarchitektur Ihres Unternehmens anzupassen.
#### Strategische Optionen für das Zertifikatmanagement
| Verwaltungsmethode | Betriebsmodell | Optimaler Anwendungsfall und Business-Vorteile |
| ------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Auto PKI (Empfohlen)** | Automatisierte Anmeldung und Erneuerung mit von Zoom verwalteten Kosten | Reduziert den operativen Aufwand, verhindert Risiken durch ablaufende Zertifikate, ideal für die meisten Bereitstellungen |
| **Bring Your Own Zertifikat (BYOC)** | Vom Unternehmen verwaltete Zertifikate öffentlicher CAs | Ermöglicht Einhaltung bestehender PKI-Richtlinien, geeignet für Unternehmen mit ausgereiftem Zertifikatsmanagement |
#### BYOC-Implementierungsanforderungen
Dieser Abschnitt beschreibt unterstützte Zertifikatmodelle und bietet eine Planungsvorlage, um sichere, skalierbare Bereitstellungen über Dienste hinweg zu gewährleisten.
**Leitfaden zur Auswahl des Zertifikattyps**
| Zertifikattyp | Technische Fähigkeit | Implementierungsbeispiel | Bereitstellungskomplexität |
| ------------------------ | -------------------------------------------- | ------------------------------------- | ------------------------------------------- |
| **Wildcard-Zertifikat** | Verschlüsselt den gesamten Subdomain-Verkehr | `*.company.com` deckt alle Dienste ab | Vereinfachte Verwaltung, empfohlener Ansatz |
| **Multi-SAN-Zertifikat** | Unterstützt bis zu 5 spezifische Hostnamen | Einzelner FQDN pro Dienst | Erfordert umfassende Vorplanung |
**Planungsvorlage für Multi-Service-Zertifikate**
Verwenden Sie diese Vorlage, um Ihre Zertifikatanforderungen vor der Bereitstellung zu planen:
| Dienstrolle | Hostname (SAN-Eintrag) | Zugewiesene IP-Adresse | Hinweise zur Zertifikatabdeckung |
| ---------------------------- | ------------------------------ | ---------------------- | ------------------------------------------------------- |
| **Zoom Node-Plattform** | `zoom-node01.company.com` | `10.1.50.100` | Basis-Plattform, die eine Zertifikatabdeckung erfordert |
| **ZPLS-Dienst** | `zpls.company.com` | `10.1.50.100` | Kann die IP mit der Node-Plattform teilen |
| **Aufzeichnungsdienst** | `zoom-recording.company.com` | `10.1.50.101` | Erfordert eine dedizierte IP-Adresse |
| **Webinar-Dienst** | `zoom-Webinar.company.com` | `10.1.50.102` | Erfordert eine dedizierte IP-Adresse |
| **Zukünftiger Service-Slot** | (Für Erweiterungen reserviert) | N/A | Erhält die Bereitstellungsflexibilität |
{% hint style="danger" %}
**Wichtiger Bereitstellungswarnhinweis**: Standard-Zertifikate für einen einzelnen Host sind nicht mit Zoom Node kompatibel, außer im speziellen Szenario einer gemeinsam genutzten IP-Adresse/Hostname zwischen Node und einem einzelnen Modul.
{% endhint %}
### Servicespezifische Voraussetzungen: Aktivierung erweiterter Hybridfunktionen
Dieser Abschnitt beschreibt die wichtigsten Voraussetzungen für die Bereitstellung von Zoom Node im AWS-Kontext.
#### AWS-Cloud-Bereitstellungsvoraussetzungen
| AWS-Anforderung | Technische Spezifikation | Implementierungszweck |
| -------------------------- | ------------------------------------------- | ----------------------------------------------------------- |
| **Arbeitsplatz-Kapazität** | Mindestens 20 GB Speicherplatz | Unterstützt die Tool-Installation und die Bildkonvertierung |
| **AWS CLI-Tools** | Neueste Version erforderlich | Ermöglicht automatisierte Bereitstellungs-Workflows |
| **QEMU-Image-Tools** | `qemu-img` Dienstprogramm | Erleichtert die Konvertierung von VMDK zu AMI |
| **IAM-Konfiguration** | `vmimport` Rolle mit geeigneten Richtlinien | Ermöglicht sichere VM-Importvorgänge |
| **S3-Infrastruktur** | Bucket mit `vmimport` Berechtigungen | Bietet Staging für VM-Images |
### Strategischer Rahmen für die Implementierungsplanung
Dieser Abschnitt bietet Bereitstellungsprofile und Skalierungsstrategien, die Ihnen bei der Planung von Leistung, Zuverlässigkeit und langfristigem Wachstum in hybriden Umgebungen helfen.
#### Matrix für Bereitstellungsgröße und Kapazitätsplanung
Wählen Sie Ihr Bereitstellungsprofil basierend auf der Unternehmensgröße und den Serviceanforderungen aus:
| Bereitstellungsprofil | Infrastrukturgröße | Strategie zur Modulverteilung | Zielanwendungsfall |
| ------------------------ | ------------------ | ---------------------------------------- | ------------------------------------- |
| **Pilot/Kleines Büro** | 1-2 Knoten | 1-2 Module pro Knoten | Proof of concept, unter 500 Benutzern |
| **Standard Enterprise** | 3-5 Knoten | 2-3 Module pro Knoten | 500-5.000 Benutzer, mehrere Standorte |
| **Großes Enterprise/HA** | 6+ Knoten | Verteilte Module, geografische Redundanz | 5.000+ Benutzer, geschäftskritisch |
#### Strategien zur Ressourcenoptimierung und Skalierung
Maximieren Sie die Infrastrukturinvestitionen durch:
* **Strategische Modulkonsolidierung**: Stellen Sie bis zu 4 Module pro Knoten mit Standard-Spezifikationen bereit
* **Stufenweiser Skalierungsansatz**: Beginnen Sie mit Mindest-Spezifikationen für Tests und skalieren Sie auf Produktions-Standard
* **Bewertung der Servicekritikalität**: Isolieren Sie geschäftskritische Dienste auf dedizierten Knoten
* **Planung der geografischen Verteilung**: Stellen Sie Knoten an verschiedenen Standorten bereit, um Ausfallsicherheit und Leistung zu gewährleisten
---
# 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-infrastructure-prerequisites.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.