> 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/sv/avancerade-enterprise-tjanster/zoom-node/zoom-node-deployment-field-guide/zoom-node-infrastructure-prerequisites.md).
# Förutsättningar för Zoom Node-infrastrukturen
Detta avsnitt beskriver förutsättningar för hårdvara och programvara för Zoom Node-utrullningar, inklusive modulinstallation.
### Bygg grunden för din hybrida kommunikation
Referenser för hårdvara och programvara för varje distributionsscenario finns nedan.
#### Stödda hypervisors
Genom att förstå hypervisor-kompatibilitet kan din organisation dra nytta av befintliga virtualiseringsinvesteringar samtidigt som fullständigt stöd för Zoom Node-funktioner bibehålls.
| Hypervisorplattform | Krav på minsta version | Strategiska överväganden för implementering |
| ---------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| **VMware vSphere/ESXi** | 6.7 eller högre | Branschstandardval som erbjuder bredast kompatibilitet, idealiskt för Enterprise med befintlig VMware-infrastruktur |
| **Proxmox VE** | Proxmox 8.x eller 9.0.x (endast VM/inget stöd för LXC) | Kostnadseffektivt alternativ med öppen källkod som stöder både Proxmox VE- och virt-manager-implementeringar |
| **Nutanix AHV** | AOS 6.10.x eller 7.x (endast VM/inget stöd för LXC) | Optimalt för organisationer som utnyttjar strategier för hyperkonvergerad infrastruktur |
| **Microsoft Hyper-V Server** | Hyper-V Server 2019 eller högre | Sömlösa integreringar för Windows-centrerade miljöer |
| **AWS EC2** | Aktuell version | Sömlösa integreringar för Windows-centrerade miljöer |
{% hint style="info" %}
Kontakta Zoom Support för validering av specifik Hyper-V-version.
{% endhint %}
#### Hårdvaruspecifikationer för virtuella datorer
Följande specifikationer omfattar standard- och minimikrav för hårdvara.
**Standardkonfiguration för produktion**
Denna konfiguration gör det möjligt för Enterprise-organisationer att maximera Zoom Node-funktionerna genom att stödja upp till fyra (4) samtidiga servicemoduler per Node.
| Infrastrukturkomponent | Teknisk specifikation | Affärspåverkan och implementeringsmotivering |
| ------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **CPU-arkitektur** | 64-bitars Intel E5-2650v4 eller nyare @ 2,0 GHz+ AMD 64-bitars @ 2,0 GHz+ | Stöder funktioner för bearbetning av media i realtid som är avgörande för bra användarupplevelser |
| **Tilldelning av virtuell CPU** | 8 vCPU:er | Möjliggör samtidig drift av flera hybrida tjänster utan prestandaförsämring |
| **Minnestilldelning** | 16 GB RAM | Stöder minnesintensiva åtgärder, inklusive transkodning och mediadirigering |
| **Lagringstilldelning** | 200 GB HDD | Rymmer operativsystem, Service Modules, loggar och tillfällig medielagring |
| **Nätverksgränssnitt** | 10 GB virtuell NIC | Förhindrar nätverksflaskhalsar under scenarier med högvolymmediebehandling |
**Minsta genomförbara konfiguration**
Denna konfiguration är lämplig för initial testning, proof of concept, labbmiljöer eller utrullningar med en enda tjänst och begränsad samtidig användning.
| Infrastrukturkomponent | Minimispecifikation | Lämpliga användningsfall och begränsningar |
| ------------------------------- | ------------------- | ---------------------------------------------------------- |
| **Tilldelning av virtuell CPU** | 3 vCPU:er | Testmiljöer, utrullningar med en enda tjänst |
| **Minnestilldelning** | 6–8 GB RAM | Begränsat stöd för samtidiga användare, kan kräva skalning |
| **Lagringstilldelning** | 200 GB HDD | Grundläggande lagring endast för nödvändiga åtgärder |
| **Nätverksgränssnitt** | 1 GB/s virtuell NIC | Tillräckligt för implementeringar med låg volym |
{% hint style="warning" %}
**Kritisk prestandaaspekt**: Organisationer måste planera att skala från minimispecifikationer till standardspecifikationer för produktion i takt med att användningsmönstren växer. Att köra ett produktionssystem med minimispecifikationer stöds inte och kommer sannolikt att orsaka prestanda- eller installationsproblem.
{% endhint %}
### Förutsättningar för nätverksarkitektur och anslutning: Säkerställer tillförlitlig hybridkommunikation
Detta avsnitt beskriver de obligatoriska kraven på nätverk, IP-adressering och DNS som behövs för sömlösa serviceintegreringar och tillförlitlig kommunikation med Zooms molninfrastruktur.
#### Grundläggande nätverkskrav
Dessa icke förhandlingsbara nätverkskonfigurationer utgör grunden för framgångsrika Zoom Node-implementeringar.
| Nätverkskrav | Teknisk specifikation | Kritisk implementeringspåverkan |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- |
| **VM-nätverkstyp** | Bryggad/direkt VM-nätverk är obligatoriskt | Möjliggör direkt kommunikation från klient till Node, vilket är avgörande för hybrida tjänster |
| **NAT-konfiguration** | stöds INTE - VM kan inte ligga bakom hypervisor-NAT | Förhindrar kommunikationsfel mellan klienter och Zoom Node-tjänster |
| **Internetanslutning** | Krävs för integreringar av molntjänster | Möjliggör funktionalitet för hybrida tjänster och kommunikation i hanteringsplanet |
| **Stöd för proxyserver** | Stöds för kommunikation i Zoom Node-operativsystemet. Proxy-stöd varierar beroende på Service Module-familj; kontrollera modulens dokumentation. | Möjliggör tillförlitlig anslutning till molntjänster utan mellanliggande komplikationer |
| **Intern adressering** | RFC 1918-adressering stöds fullt ut | Möjliggör sömlösa integreringar med befintliga företagsnätverksscheman |
#### Planeringsmatris för IP-adress
Strategisk tilldelning av IP-adress möjliggör flexibel tjänstutrullning och framtida expansion.
| Arkitektur för utrullning | Krav på IP-adress | Implementeringsflexibilitet och tillväxtväg |
| ------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------- |
| **Standard Node med flera tjänster** | 1 unik IP-adress per tjänst (upp till 4 totalt) | Maximal flexibilitet vid utrullning, stöder stegvis tjänsteutrullning |
| **Hybrid WAG-implementering** | 2 dedikerade IP-adresser krävs | Möjliggör redundanta Web applikation Gateway-tjänster |
| **Konsoliderad utrullning** | 1 delad IP-adress för Node + primär modul | Begränsad till specifika scenarier med låg komplexitet |
| **Arkitektur för hög tillgänglighet** | Flera IP-adresser över distribuerade komponenter | Stöder Enterprise-krav på överlevnadsförmåga |
#### Krav på DNS-arkitektur
Korrekt DNS-konfiguration säkerställer tillförlitlig tjänstidentifiering och certifikatvalidering.
**Kritiska implementeringskrav för DNS**
* **Krav på offentlig DNS-uppslagning**: Alla Zoom Node-värdnamn måste lösas via offentlig DNS-infrastruktur
* **Stöd för split-horizon-DNS**: Externa DNS-zoner måste lösa upp Node-värdnamn för Zoom-molnets IP-intervall
* **DNS-arkitektur för överlevnadsförmåga**: Lokala DNS-servrar måste förbli tillgängliga under internetavbrott
* **Krav på namnkonsistens**: Interna användare och Zoom-molnets infrastruktur måste använda identiska värdnamn
{% hint style="info" %}
**Bästa praxis för implementering**: Dokumentera och validera alla DNS-poster före utrullning för att förhindra certifikat- och anslutningsproblem.
{% endhint %}
### Strategi för certifikathantering: Skydda din hybrida kommunikation
Detta avsnitt beskriver tillgängliga certifikatalternativ—automatiserade eller BYOC—och ger planeringsvägledning för att anpassa efter din organisations säkerhetspolicyer och arkitektur för utrullning.
#### Strategiska alternativ för certifikathantering
| Hanteringsmetod | Driftsmodell | Optimalt användningsfall och affärsfördelar |
| -------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Auto PKI (rekommenderas)** | Automatiserad registrering och förnyelse med kostnader som hanteras av Zoom | Minskar det operativa arbetet, eliminerar risker för att certifikat går ut, idealiskt för de flesta utrullningar |
| **Ta med ditt eget certifikat (BYOC)** | Av organisationen hanterade certifikat från offentliga certifikatutfärdare | Möjliggör efterlevnad av befintliga PKI-policyer, lämpligt för Enterprise med mogen certifikathantering |
#### Implementeringskrav för BYOC
Detta avsnitt beskriver stödda certifikatmodeller och tillhandahåller en planeringsmall för att säkerställa säkra, skalbara utrullningar över tjänster.
**Guide för val av certifikattyp**
| Certifikattyp | Teknisk kapacitet | Implementeringsexempel | Komplexitet för utrullning |
| ------------------------ | ------------------------------------- | ------------------------------------ | ---------------------------------------- |
| **Wildcard-certifikat** | Krypterar all trafik för underdomäner | `*.company.com` täcker alla tjänster | Förenklad hantering, rekommenderad metod |
| **Multi-SAN-certifikat** | Stöder upp till 5 specifika värdnamn | Separat FQDN per tjänst | Kräver omfattande förhandsplanering |
**Planeringsmall för certifikat med flera tjänster**
Använd denna mall för att planera dina certifikatkrav före utrullning:
| Tjänsteroll | Värdnamn (SAN-post) | Tilldelad IP-adress | Anteckningar om certifikatets täckning |
| ------------------------ | ------------------------------ | ------------------- | --------------------------------------------- |
| **Zoom Node-plattform** | `zoom-node01.company.com` | `10.1.50.100` | Grundplattform som kräver certifikatstäckning |
| **ZPLS-tjänst** | `zpls.company.com` | `10.1.50.100` | Kan dela IP-adress med Node-plattformen |
| **Inspelningsservice** | `zoom-recording.company.com` | `10.1.50.101` | Kräver dedikerad IP-adress |
| **Webbinariumtjänst** | `zoom-webbinarium.company.com` | `10.1.50.102` | Kräver dedikerad IP-adress |
| **Framtida tjänstplats** | (Reserverad för expansion) | Ej tillämpligt | Bibehåller flexibilitet i utrullningen |
{% hint style="danger" %}
**Kritisk varning inför utrullning**: Standardcertifikat för en enskild värd är inkompatibla med Zoom Node, utom i det specifika scenariot med en delad IP-adress/värdnamn mellan Node och en enda modul.
{% endhint %}
### Tjänstespecifika förutsättningar: Möjliggör avancerade hybrida funktioner
Detta avsnitt beskriver viktiga förutsättningar för att distribuera Zoom Node i ett AWS-sammanhang.
#### Förutsättningar för molnutrullning i AWS
| AWS-krav | Teknisk specifikation | Implementeringssyfte |
| --------------------------- | ------------------------------------- | ---------------------------------------------------- |
| **Arbetsstationskapacitet** | Minst 20 GB lagring | Stöder installation av verktyg och bildkonvertering |
| **AWS CLI-verktyg** | Senaste version krävs | Möjliggör automatiserade arbetsflöden för utrullning |
| **QEMU-bildverktyg** | `qemu-img` verktyg | Underlättar konvertering från VMDK till AMI |
| **IAM-konfiguration** | `vmimport` roll med lämpliga policyer | Möjliggör säkra VM-importåtgärder |
| **S3-infrastruktur** | Bucket med `vmimport` behörigheter | Tillhandahåller staging för VM-avbilder |
### Strategiskt ramverk för implementeringsplanering
Detta avsnitt tillhandahåller distributionsprofiler och skalningsstrategier för att hjälpa dig planera för prestanda, tillförlitlighet och långsiktig tillväxt i hybrida miljöer.
#### Matris för dimensionering av utrullning och kapacitetsplanering
Markera din distributionsprofil baserat på organisationens storlek och tjänstkrav:
| Distributionsprofil | Infrastrukturens skala | Strategi för modulfördelning | Avsett användningsfall |
| ----------------------- | ---------------------- | ------------------------------------------- | ------------------------------------- |
| **Pilot/Litet kontor** | 1–2 noder | 1–2 moduler per Node | Proof of concept, under 500 användare |
| **Standard Enterprise** | 3–5 noder | 2–3 moduler per Node | 500–5 000 användare, flera platser |
| **Stor Enterprise/HA** | 6+ noder | Distribuerade moduler, geografisk redundans | 5 000+ användare, verksamhetskritisk |
#### Resursoptimering och skalningsstrategier
Maximera infrastruktuinvesteringen genom:
* **Strategisk konsolidering av moduler**: Distribuera upp till 4 moduler per Node med standardspecifikationer
* **Stegvis skalningsmetod**: Börja med minimispecifikationer för testning och skala upp till produktionsstandard
* **Bedömning av tjänstekritikalitet**: Isolera verksamhetskritiska tjänster på dedikerade noder
* **Planering av geografisk distribution**: Distribuera noder över olika platser för överlevnadsförmåga och prestanda
---
# 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/sv/avancerade-enterprise-tjanster/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 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.