> 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).

# Infrastrukturvoraussetzungen für Zoom Node

Dieser Abschnitt beschreibt die Hardware- und Softwarevoraussetzungen für Zoom Node-Bereitstellungen, einschließlich der Modulinstallation.

### <mark style="color:blau;">Aufbau Ihrer hybriden Kommunikationsgrundlage</mark>

Hardware- und Software-Referenzen für jedes Bereitstellungsszenario werden unten bereitgestellt.

#### Unterstützte Hypervisoren

Das Verständnis der Hypervisor-Kompatibilität ermöglicht es Ihrem Unternehmen, bestehende Virtualisierungsinvestitionen zu nutzen und gleichzeitig die vollständige Unterstützung der Zoom Node-Funktion aufrechtzuerhalten.

| Hypervisor-Plattform         | Anforderung an die Mindestversion                       | Strategische Überlegungen zur Implementierung                                                                                 |
| ---------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **VMware vSphere/ESXi**      | 6.7 oder höher                                          | Branchenübliche Wahl mit der breitesten Kompatibilität, ideal für Enterprise-Unternehmen mit bestehender VMware-Infrastruktur |
| **Proxmox VE**               | Proxmox 8.x oder 9.0.x (nur VM/keine LXC-Unterstützung) | Kostengünstige Open-Source-Option mit Unterstützung für Implementierungen mit Proxmox VE und virt-manager                     |
| **Nutanix AHV**              | AOS 6.10.x oder 7.x (nur VM/keine LXC-Unterstützung)    | Optimal für Unternehmen, die hyperkonvergente 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 der spezifischen Hyper-V-Version.
{% endhint %}

#### Hardware-Spezifikationen für virtuelle Maschinen

Die folgenden Spezifikationen decken Standard- und Mindestanforderungen an die Hardware ab.

**Standard-Produktionskonfiguration**

Diese Konfiguration ermöglicht es Enterprise-Unternehmen, die Fähigkeiten von Zoom Node zu maximieren, indem bis zu vier (4) gleichzeitige Servicemodule pro Node unterstützt werden.

| Infrastrukturkomponente       | Technische Spezifikation                                         | Business-Auswirkungen und Begründung der Implementierung                                                    |
| ----------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **CPU-Architektur**           | 64-Bit Intel E5-2650v4 oder neuer @ 2.0GHz+ AMD 64-Bit @ 2.0GHz+ | Unterstützt Echtzeit-Medienverarbeitungsfunktionen, die für hochwertige Benutzererfahrungen wesentlich 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 Betriebssystem, Servicemodule, Protokolle und temporären Medienspeicher                    |
| **Netzwerkschnittstelle**     | 10 GB virtuelle NIC                                              | verhindern Netzwerkengpässe bei Szenarien mit hohem Medienverarbeitungsvolumen                              |

**Minimale tragfähige Konfiguration**

Diese Konfiguration eignet sich für erste Tests, Machbarkeitsnachweise, Laborumgebungen oder Einzelservice-Bereitstellungen mit begrenzter gleichzeitiger Nutzung.

| Infrastrukturkomponente       | Mindestspezifikation | Geeignete Anwendungsfälle und Einschränkungen                                               |
| ----------------------------- | -------------------- | ------------------------------------------------------------------------------------------- |
| **Zuweisung virtueller CPUs** | 3 vCPUs              | Testumgebungen, Einzelservice-Bereitstellungen                                              |
| **Speicherzuweisung**         | 6-8 GB RAM           | Begrenzte Unterstützung gleichzeitiger Benutzer, möglicherweise ist Skalierung erforderlich |
| **Speicherbereitstellung**    | 200 GB HDD           | Basic-Speicher nur für wesentliche Vorgänge                                                 |
| **Netzwerkschnittstelle**     | 1 GB/s virtuelle NIC | Ausreichend für Implementierungen mit geringem Volumen                                      |

{% hint style="warning" %}
**Kritische Leistungsüberlegung**: Unternehmen müssen planen, von den Mindest- auf die Produktions-Standard-Spezifikationen zu skalieren, wenn die Nutzungsmuster wachsen. Der Betrieb eines Produktionssystems mit Mindestspezifikationen wird nicht unterstützt und führt wahrscheinlich zu Leistungs- oder Installationsproblemen.
{% endhint %}

### <mark style="color:blau;">Voraussetzungen für Netzwerkarchitektur und Konnektivität: Sicherstellung zuverlässiger hybrider Kommunikation</mark>

Dieser Abschnitt beschreibt die erforderlichen Anforderungen an Netzwerk, IP-Adressierung und DNS, die für eine nahtlose Service-Integration und zuverlässige Kommunikation mit der Cloud-Infrastruktur von Zoom benötigt werden.

#### Grundlegende Netzwerkanforderungen

Diese nicht verhandelbaren Netzwerkkonfigurationen bilden die Grundlage erfolgreicher Zoom Node-Implementierungen.

| Netzwerkanforderung               | Technische Spezifikation                                                                                                                                                | Kritische Auswirkungen auf die Implementierung                                                      |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **VM-Netzwerktyp**                | Überbrücktes/direktes VM-Netzwerk zwingend erforderlich                                                                                                                 | Ermöglicht die direkte Client-zu-Node-Kommunikation, die für hybride Dienste wesentlich ist         |
| **NAT-Konfiguration**             | NICHT unterstützt - VM kann sich nicht hinter Hypervisor-NAT befinden                                                                                                   | verhindern Kommunikationsausfälle zwischen Clients und Zoom Node-Diensten                           |
| **Internetverbindung**            | Erforderlich für die Integration von Cloud-Diensten                                                                                                                     | Ermöglicht hybride Servicefunktionalität und Kommunikation mit der Verwaltungsebene                 |
| **Unterstützung für Proxyserver** | Unterstützt für die Kommunikation des Zoom Node-Betriebssystems. Die Proxy-Unterstützung variiert je nach Familie des Servicemoduls; prüfen Sie die Moduldokumentation. | Ermöglicht zuverlässige Konnektivität zu Cloud-Diensten ohne Komplikationen durch Zwischeninstanzen |
| **Interne Adressierung**          | RFC 1918-Adressierung vollständig unterstützt                                                                                                                           | Ermöglicht die nahtlose Integration in bestehende Enterprise-Netzwerkschemata                       |

#### IP-Adresse-Planungsmatrix

Die strategische Zuweisung von IP-Adresse ermöglicht eine flexible Servicebereitstellung und zukünftige Erweiterung.

| Bereitstellungsarchitektur              | IP-Adressenanforderungen                        | Implementierungsflexibilität und Wachstumspfad                                             |
| --------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Standard-Multiservice-Node**          | 1 eindeutige IP pro Dienst (bis zu 4 insgesamt) | Maximale Bereitstellungsflexibilität, unterstützt eine stufenweise Einführung von Diensten |
| **Hybride WAG-Implementierung**         | 2 dedizierte IP-Adressen erforderlich           | Ermöglicht redundante Web Anwendung Gateway-Dienste                                        |
| **Konsolidierte Bereitstellung**        | 1 gemeinsame IP für Node + primäres Modul       | Auf bestimmte Szenarien mit geringer Komplexität beschränkt                                |
| **Architektur mit hoher Verfügbarkeit** | Mehrere IPs über verteilte Komponenten hinweg   | Unterstützt Anforderungen an die Enterprise-Ausfallsicherheit                              |

#### Anforderungen an die DNS-Architektur

Eine ordnungsgemäße DNS-Konfiguration gewährleistet eine zuverlässige Diensterkennung und Zertifikatvalidierung.

**Kritische Anforderungen an die DNS-Implementierung**

* **Vorgabe zur öffentlichen DNS-Auflösung**: Alle Zoom Node-Hostnamen müssen über öffentliche DNS-Infrastruktur aufgelöst werden
* **Unterstützung für Split-Horizon-DNS**: Externe DNS-Zonen müssen Node-Hostnamen für IP-Bereiche der Zoom Cloud auflösen
* **DNS-Architektur für Ausfallsicherheit**: Lokale DNS-Server müssen bei Internetausfällen Verfügbar bleiben
* **Anforderung an die Namenskonsistenz**: Interne Benutzer und die Infrastruktur der Zoom Cloud müssen auf identische Hostnamen verweisen

{% hint style="info" %}
**Implementierungs-Best Practice**: Dokumentieren und validieren Sie alle DNS-Einträge vor der Bereitstellung, um Probleme mit Zertifikat und Konnektivität zu verhindern.
{% endhint %}

### <mark style="color:blau;">Strategie für das Zertifikatmanagement: Absicherung Ihrer hybriden Kommunikation</mark>

Dieser Abschnitt beschreibt Verfügbar Zertifikatoptionen — automatisiert oder BYOC — und bietet Planungshinweise, 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 Registrierung und Erneuerung mit von Zoom verwalteten Kosten | Reduziert den betrieblichen Aufwand, beseitigt Risiken durch ablaufende Zertifikat, ideal für die meisten Bereitstellungen       |
| **Bring Your Own Zertifikat (BYOC)** | Vom Unternehmen verwaltete Zertifikate von öffentlichen CAs                 | Ermöglicht die Einhaltung bestehender PKI-Richtlinien, geeignet für Enterprise-Unternehmen mit ausgereiftem Zertifikatmanagement |

#### BYOC-Implementierungsanforderungen

Dieser Abschnitt beschreibt unterstützte Zertifikatmodelle und bietet eine Planungsvorlage, um sichere, skalierbare Bereitstellungen über Dienste hinweg sicherzustellen.

**Leitfaden zur Auswahl des Zertifikattyps**

| Zertifikattyp            | Technische Fähigkeit                          | Implementierungsbeispiel              | Bereitstellungskomplexität                  |
| ------------------------ | --------------------------------------------- | ------------------------------------- | ------------------------------------------- |
| **Wildcard-Zertifikat**  | Verschlüsselt gesamten Subdomain-Datenverkehr | `*.company.com` deckt alle Dienste ab | Vereinfachte Verwaltung, empfohlener Ansatz |
| **Multi-SAN-Zertifikat** | Unterstützt bis zu 5 spezifische Hostnamen    | Individueller FQDN pro Dienst         | Erfordert umfassende Vorausplanung          |

**Planungsvorlage für Multiservice-Zertifikate**

Verwenden Sie diese Vorlage, um Ihre Zertifikatanforderungen vor der Bereitstellung zu planen:

| Servicerolle                 | 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 IP mit der Node-Plattform teilen                   |
| **Aufzeichnungsdienst**      | `zoom-recording.company.com` | `10.1.50.101`          | Erfordert dedizierte IP-Adresse                         |
| **Webinar-Dienst**           | `zoom-webinar.company.com`   | `10.1.50.102`          | Erfordert dedizierte IP-Adresse                         |
| **Zukünftiger Service-Slot** | (Für Erweiterung reserviert) | N/V                    | Bewahrt die Bereitstellungsflexibilität                 |

{% hint style="danger" %}
**Kritische Bereitstellungswarnung**: Standard-Einzelhost-Zertifikate sind mit Zoom Node nicht kompatibel, außer im spezifischen Szenario einer gemeinsamen IP/eines gemeinsamen Hostnamens zwischen Node und einem einzelnen Modul.
{% endhint %}

### <mark style="color:blau;">Servicespezifische Voraussetzungen: Aktivierung erweiterter hybrider Fähigkeiten</mark>

Dieser Abschnitt beschreibt die wichtigsten Voraussetzungen für die Bereitstellung von Zoom Node in einem AWS-Kontext.

#### Voraussetzungen für die AWS Cloud-Bereitstellung

| AWS-Anforderung            | Technische Spezifikation                    | Zweck der Implementierung                             |
| -------------------------- | ------------------------------------------- | ----------------------------------------------------- |
| **Arbeitsplatz-Kapazität** | Mindestens 20 GB Speicher                   | Unterstützt Tool-Installation und Image-Konvertierung |
| **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                          |

### <mark style="color:blau;">Strategischer Rahmen für die Implementierungsplanung</mark>

Dieser Abschnitt bietet Bereitstellungsprofile und Skalierungsstrategien, die Ihnen helfen, Leistung, Zuverlässigkeit und langfristiges Wachstum in hybriden Umgebungen zu planen.

#### Matrix für Bereitstellungsdimensionierung und Kapazitätsplanung

Wählen Sie Ihr Bereitstellungsprofil basierend auf Unternehmensgröße und Serviceanforderungen aus:

| Bereitstellungsprofil    | Infrastrukturskala | Strategie zur Modulverteilung            | Ziel-Anwendungsfall                      |
| ------------------------ | ------------------ | ---------------------------------------- | ---------------------------------------- |
| **Pilot/Kleines Büro**   | 1-2 Nodes          | 1-2 Module pro Node                      | Machbarkeitsnachweis, unter 500 Benutzer |
| **Standard Enterprise**  | 3-5 Nodes          | 2-3 Module pro Node                      | 500-5.000 Benutzer, mehrere Standorte    |
| **Großes Enterprise/HA** | 6+ Nodes           | Verteilte Module, geografische Redundanz | 5.000+ Benutzer, geschäftskritisch       |

#### Strategien zur Ressourcenoptimierung und Skalierung

Maximieren Sie die Infrastrukturinvestition durch:

* **Strategische Modulkonsolidierung**: Stellen Sie bis zu 4 Module pro Node mit Standard-Spezifikationen bereit
* **Stufenweiser Skalierungsansatz**: Beginnen Sie zu Testzwecken mit Mindestspezifikationen, skalieren Sie dann auf Produktionsstandards
* **Bewertung der Servicekritikalität**: Isolieren Sie geschäftskritische Dienste auf dedizierten Knoten
* **Planung der geografischen Verteilung**: Knoten über Standorte hinweg bereitstellen für Überlebensfähigkeit und Leistung


---

# 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-infrastructure-prerequisites.md?ask=<question>&goal=<endgoal>
```

`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.
