> 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-deployment-considerations.md).
# Överväganden för driftsättning av Zoom Node
Det här avsnittet innehåller flera exempel på hur Zoom Node kan stödja olika Service Modules, som Zoom Meetings Hybrid och Zoom Phone Local Survivability (ZPLS). Typiska implementationer med en dedikerad IP-adress kan se ut som följande samling diagram.
Varje tjänst som distribueras på Zoom Node kräver en unik IP-adress. En Zoom Node kan ha upp till fem (5) IP-adresser tilldelade om noden har tilldelats en specifik adress för hantering och en för varje distribuerad tjänst (upp till fyra) på noden. En Zoom Node som kör en enda tjänst (till exempel ZPLS) kan distribueras med en enda IP-adress om noden och tjänsten tilldelas att dela samma IP-adress.
Flera distributionsalternativ visas nedan. Observera antalet IP-adresser och certifikat (CN/SAN:er) för de olika distributionsalternativen.
### Alternativ 1: Zoom Meetings Hybrid distribuerat med dedikerade IP-adresser och värdnamn
Bilden ovan sammanfattar kraven för IP- och certifikatkonfiguration vid distribution av **Zoom Meetings Hybrid** i lokala eller hybrida molnmiljöer.
Tabellen nedan bryter ned den exempelnod som visas och inkluderar dess aktiv proxy och MMR Service Modules:
| Komponent | Värdnamn | TLS-certifikatroll | Funktion |
| ----------------------------- | -------------------- | ------------------------------ | -------------------------------- |
| Node operativsystem | `node1.customer.com` | Common Name (CN) | Kärnorkestrering |
| Zoom anslutningsprogram Proxy | `zcp1.customer.com` | Subject Alternative Name (SAN) | Signalering och sessionskontroll |
| Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Mediedirigering och bearbetning |
| Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Mediedirigering och bearbetning |
| Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Mediedirigering och bearbetning |
{% hint style="info" %}
Du måste tilldela varje modul en dedikerad statisk IP-adress. Totalt antal IP-adresser som krävs: fem (5)
{% endhint %}
Bilden ovan beskriver den minimala konfiguration som behövs för att distribuera **Zoom Phone lokal överlevnadsförmåga (ZPLS)**. ZPLS möjliggör fortsatt tillgänglighet för telefontjänsten vid internet- eller molnavbrott genom att köra överlevnadslogik lokalt på en Zoom Node VM.
Följande värdnamn måste konfigureras i DNS och ingå i TLS-certifikatet:
* `node1.customer.com`
* `zplsl.customer.com`
**Funktionsmappning av värdnamn**
| Komponent | Värdnamn | TLS-certifikatroll | Funktion |
| ------------------- | -------------------- | ------------------------ | ------------------------------------ |
| Node operativsystem | `node1.customer.com` | Common Name (CN) | Kärnorkestrering |
| ZPLS-modul | `zplsl.customer.com` | Subject Alternative Name | Zoom Phone Local Survivability-logik |
**Konfiguration av TLS-certifikat**
| Fält | Värde |
| ------------------------- | -------------------- |
| Common Name (CN) | `node1.customer.com` |
| Subject Alternative Names | `zplsl.customer.com` |
Certifikat måste genereras eller anskaffas (publik eller privat CA) så att både CN och SAN:er som listas ovan ingår. Detta möjliggör korrekt TLS-validering för säker kommunikation mellan moduler.
**Krav på IP-adress**
| Mätvärde | Värde / Beskrivning |
| ---------------------------------- | ----------------------------------------------------------- |
| Totalt antal IP-adresser som krävs | 5 (allmän allokering) |
| Används i ZPLS-kontext | 2 IP-adresser (1 för Node operativsystem, 1 för ZPLS-modul) |
Även om fem (5) IP-adresser krävs för allmän distribution, **används endast två (2) IP-adresser aktivt** i ZPLS-distributionen: en per modul, som körs på en **dedikerad Node VM**.
{% hint style="warning" %}
ZPLS tillåter endast en modul per Node VM. Du kan inte samlokalisera ZPLS med andra Zoom-moduler på samma VM.
{% endhint %}
Hur jämförs dessa diagram? Den första bilden visar ett exempel på en Zoom Meetings Hybrid-distribution. Den andra bilden visar ett exempel på en Zoom Phone Local Survivability-distribution.
Du kan dela den första IP-adressen/värdnamnet mellan operativsystemet och den första modulen, om så önskas, för att minska antalet IP-adresser, värdnamn och Subject Alternative Names (SANs) som krävs.
### Alternativ 2: Zoom Meetings Hybrid distribuerad med en delad IP-adress och ett delat värdnamn
Den här konfigurationen upprepar Node-strukturen som i Zoom Meetings Hybrid-diagrammet i alternativ 1. Men i denna distribution är **Node operativsystem delar sin IP-adress med den första distribuerade modulen** (vanligtvis Zoom anslutningsprogram Proxy, ZCP). Detta leder till minskad IP-användning samtidigt som TLS- och funktionskraven upprätthålls.
Följande värdnamn måste konfigureras i DNS och ingå i TLS-certifikatet:
* `zcp1.customer.com`
* `mmr1.customer.com`
* `mmr2.customer.com`
* `mmr3.customer.com`
**Funktionsmappning av värdnamn**
| Komponent | Värdnamn | TLS-certifikatroll | Funktion |
| ----------------------------------- | ------------------- | ------------------------------ | -------------------------------- |
| ZCP (Zoom anslutningsprogram Proxy) | `zcp1.customer.com` | Common Name (CN) | Signalering och sessionskontroll |
| Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Mediedirigering och bearbetning |
| Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Mediedirigering och bearbetning |
| Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Mediedirigering och bearbetning |
**Konfiguration av TLS-certifikat**
| Fält | Värde |
| ------------------------- | ------------------------------------------------------------- |
| Common Name (CN) | `zcp1.customer.com` |
| Subject Alternative Names | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |
Certifikat måste inkludera alla SANs för att stödja säker TLS-kommunikation mellan Zoom Node och de installerade Zoom-modulerna.
**Krav på IP-adress**
| Mätvärde | Värde / Beskrivning |
| ---------------------------------- | ----------------------------------------------------------- |
| Totalt antal IP-adresser som krävs | 4 |
| Strategi för IP-delning | Nodens operativsystem delar IP med den första modulen (ZCP) |
| Individuella IP-adresser krävs för | ZCP/MMR1, MMR2, MMR3 |
{% hint style="info" %}
När IP-adressen är **delad** mellan nodens operativsystem och den först distribuerade modulen (ZCP), endast **fyra (4) IP-adresser** krävs. Denna design optimerar användningen av IP samtidigt som den fortfarande uppfyller distributionsstandarderna.
{% endhint %}
Bilden ovan visar en minimal ZPLS-distribution där **Node operativsystem delar sin IP-adress med den installerade ZPLS-modulen**. Detta är det **enda scenariot** i Zoom Node-ramverket där ett **TLS-certifikat för en enda värd** är giltigt.
Följande värdnamn måste konfigureras i DNS och ingå i TLS-certifikatet:
* `zplsl.customer.com`
**Funktionsmappning av värdnamn**
| Komponent | Värdnamn | TLS-certifikatroll | Funktion |
| ---------- | -------------------- | ------------------ | ------------------------------------ |
| ZPLS-modul | `zplsl.customer.com` | Common Name (CN) | Zoom Phone Local Survivability-logik |
**Konfiguration av TLS-certifikat**
| Fält | Värde |
| ---------------- | ------------------- |
| Common Name (CN) | `zcp1.customer.com` |
| SAN:er | (inte krävs) |
I denna konfiguration är ett certifikat för en enda värd tillräckligt eftersom både operativsystemet och ZPLS-modulen delar samma värdnamn och IP-adress.
**Krav på IP-adress**
| Mätvärde | Värde / Beskrivning |
| ---------------------------------- | ------------------------------------------------------ |
| Totalt antal IP-adresser som krävs | 1 |
| Strategi för IP-delning | Nodens operativsystem och ZPLS delar en enda IP-adress |
| Driftsättningsbegränsning | Endast en modul tillåten per Node VM (endast ZPLS) |
{% hint style="warning" %}
ZPLS är det enda scenariot som stöds i Zoom Node-arkitekturen där:
* Ett certifikat för en enda värd (endast CN) är godtagbart
* Endast en (1 )IP-adress krävs för driftsättning på grund av IP-delning mellan operativsystem och modul
* Samlokalisering av ytterligare moduler på samma VM stöds inte
{% endhint %}
### Bestäm vilken metod för certifikathantering som fungerar bäst för dina driftsättningar
Varje tjänstemodul som driftsätts på Zoom Node kräver ett giltigt certifikat signerat av en offentligt betrodd certifikatutfärdare (CA) från Zoom Nodes lista över betrodda certifikat. Detta inkluderar välkända offentliga utfärdare.
Zoom Node erbjuder två metoder för certifikathantering:
* **Automatisk PKI**: Denna innovativa lösning automatiserar säker certifikatregistrering och förnyelse med offentligt betrodda certifikatutfärdare (CA:er). Zoom står för kostnaderna för registrering och förnyelse.
* **Ta med ditt eget certifikat (BYOC)**: Med det här alternativet tillhandahåller du dina egna certifikat, signerade av valfri större offentligt betrodd CA. Du hanterar certifikatregistrering och förnyelser. Ytterligare överväganden gäller beträffande Zoom Node:s potentiella stöd för upp till fem värdnamn/SAN:er när kundtillhandahållna certifikat används, vilket beskrivs närmare nedan.
#### Automatisk certifikathantering med Automatisk PKI
Zoom Automatisk PKI installerar giltiga offentligt betrodda CA-certifikat automatiskt för Zoom Node-plattformen, liksom för alla moduler som distribueras på den. Certifikatförnyelse hanteras också automatiskt. Detta förenklar certifikathanteringen för alla tjänster och själva Zoom Node.
#### Förstå registrering och förnyelse av certifikat med Automatisk PKI
Följande scenario kan hjälpa dig att förstå hur certifikatregistrering och förnyelse fungerar.
Till exempel: En administratör har distribuerat en ny nodinstans. Varje instans kräver ett giltigt x509-certifikat. **Certifikatets privata nyckel får aldrig lämna denna instans**.
Auto PKI-processen utför följande steg:
1. **Hämtning av mallar**: Hämtar alla konfigurationsmallar som stöds, inklusive alternativ för flera CA-leverantörer, från Auto PKI-tjänsten i Zoom-moln.
2. **Insamling av IP-adresser**: Samlar in alla IP-adresser som används av tjänster som körs på noden och skickar dem till Auto PKI-tjänsten i Zoom-moln.
3. **Provisionering av DNS-namn**: Auto PKI-molntjänsten returnerar en uppsättning DNS-namn i formatet `..zoomonprem.com`. Dessa domäner är konfigurerade med A/AAAA-poster.
4. **Begäran om reserverat DNS-namn**: Begär ett reserverat DNS-namn i formatet `rsvd-..zoomonprem.com`.
5. **Generering av certifikatbegäran**: Genererar en x509-certifikatbegäran, med DNS-namnen från det tredje steget i SAN-fältet och det reserverade namnet från det fjärde steget i fältet Common Name (CN).
6. **Utfärdande av certifikat**: Skickar certifikatssigneringsbegäran (CSR) till Auto PKI-tjänsten i Zoom-moln. Denna tjänst arbetar sedan med CA-leverantörer för att utfärda certifikatet, som inkluderar SAN-listan och CN-fältet från föregående steg.
7. **Lokal lagring**: Skriver det nyligen utfärdade x509-certifikatet från föregående steg och dess tillhörande privata nyckel (genererad tidigare) till lokalt lagringsutrymme, vilket gör dem tillgänglig för tjänster som körs på Node-instansen.
Auto PKI förenklar certifikathanteringen på Zoom Node genom att automatiskt övervaka utgångsdatum och begära nya certifikat, vilket eliminerar behovet av manuell förnyelse.
#### Ta med dina egna certifikat (BYOC)
Du kan installera dina egna giltiga, offentligt signerade certifikat på Zoom Node med hjälp av det lokala webbgränssnittet. Du kan göra detta antingen under den första installationen eller vid en senare tidpunkt. Processen kommer att vara bekant för dem som är vana vid att installera certifikat i webbaserade applikationer.
Om du väljer att använda dina egna certifikat, kom ihåg att certifikatet kommer att finnas på en server som kommunicerar med flera värdnamn. Därför måste den certifikattyp du väljer ha stöd för kryptering för trafik som kommer från mer än ett värdnamn (certifikatets CN). Alla värdnamn som används för Node och alla distribuerade tjänster måste kunna lösas upp offentligt av Zooms molntjänster.
Zoom rekommenderar två typer av certifikat:
* **Wildcard-certifikat**
* **Multi-SAN-certifikat** (även känt som Multi-Domain-certifikat, SAN-certifikat eller UCC-certifikat)
{% hint style="danger" %}
Ett typiskt certifikat för en enda värd fungerar inte med Zoom Node, förutom i det specifika scenariot där en enda IP-adress och ett värdnamn delas mellan Zoom Node och en enda modul. För ytterligare sammanhang, se ZPLS-diagrammet i [#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-certifikat: Rekommenderas för enkelhet**
Ett wildcard-certifikat kan kryptera trafik från vilket värdnamn som helst i domänen. Till exempel: Ett wildcard-certifikat som \*.customer.com kan kryptera trafik från `host1.customer.com` och `host2.customer.com` eller vilket namn som helst inom `.customer.com`.
När du distribuerar Zoom Node och installerar wildcard-certifikatet kommer det automatiskt att kryptera trafik för alla tjänster du distribuerar på noden, under förutsättning att alla distribuerade tjänster använder ett fullständigt domännamn (FQDN) från wildcard-domänen.
Detta minimerar arbetet med att distribuera tjänster på noden: du behöver inte känna till tjänsternas namn innan du distribuerar dem. Du behöver dock känna till tjänsternas namn om du använder metoden med Multi-SAN-certifikat.
**Multi-SAN, Multi-Domain, SAN eller UCC-certifikat**
{% hint style="warning" %}
Du måste känna till värdnamnen och IP-adresserna som du kommer att använda för noden (upp till ett \[1]) och alla tjänster som du kommer att installera (upp till fyra \[4]).
**Denna information krävs innan du registrerar ett certifikat**.
{% endhint %}
Ett Multi-SAN-certifikat är nödvändigt för Zoom Node eftersom det krypterar trafik från fem (5) värdnamn. En engångsbegäran för detta certifikat kräver förhandskännedom om all nödvändig information, inklusive planerade nodnamn och namnen på alla tjänster som ska distribueras på noden. Till exempel, med en modul som ZPLS, distribueras endast en ZPLS-modul per nod, så endast ett ytterligare SAN behövs för ZPLS-tjänstens värdnamn.
Följande tabell kan användas som ett exempel:
| Värdnamn (SAN) | IP-adress |
| ----------------------------------------- | ---------------- |
| `zoom-node01.company.com` | `10.1.50.100` |
| `zpls.company.com` | `10.1.50.100` |
| `zoom-recording.company.com` | `10.1.50.101` |
| `zoom-webbinarium.company.com` | `10.1.50.102` |
| (Tjänst 4 - används inte i detta exempel) | (ej tillämpligt) |
Detta exempel visar en typisk konfiguration, med en Node som värd för ZPLS på samma IP samt två ytterligare tjänster på separata IP-adresser. Ersätt “company.com” med din faktiska domän och använd din näts IP-adresser.
**Krav för DNS-upplösning**
Zoom kräver att värdnamnen kan lösas publikt så att ett ömsesidigt förtroende kan upprättas. Alla värdnamn för Zoom Node och alla tjänstvärdnamn som distribueras på Noderna måste ingå i DNS-zonen.
Om din organisation kör separata interna och externa DNS-tjänster eller domäner, måste värdnamnen för Zoom Node vara värdbelagda i en zon som kan lösas upp av dina externa DNS-servrar (kan begränsas till att endast lösas upp för Zoom IP-intervall). Dina interna Zoom-användare och Zoom-moln måste kommunicera med hjälp av samma uppsättning värdnamn.
---
# 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:
```
GET https://library.zoom.com/technical-library/sv/avancerade-enterprise-tjanster/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.