> 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/it/servizi-avanzati-enterprise/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Considerazioni sul deployment di Zoom Node Questa sezione contiene diversi esempi di come Zoom Node può supportare vari moduli di servizio come Zoom Meetings Hybrid e Zoom Phone Local Survivability (ZPLS). Le implementazioni tipiche con un Indirizzo IP dedicato possono apparire come la seguente raccolta di diagrammi. Ogni servizio distribuito su Zoom Node richiede un Indirizzo IP univoco. Un Zoom Node avrà fino a cinque (5) Indirizzo IP assegnati se al Node è stato assegnato un indirizzo specifico per la gestione e uno per ciascun servizio distribuito (fino a quattro) sul Node. Un Zoom Node che esegue un singolo servizio (come ZPLS) può essere distribuito con un singolo Indirizzo IP se al Node e al servizio viene assegnato di condividere lo stesso Indirizzo IP. Di seguito sono mostrate diverse opzioni di distribuzione. Si noti il numero di IP e certificati (CN/SAN) per le varie opzioni di distribuzione. ### Opzione 1: Zoom Meetings Hybrid distribuito con IP e nomi host dedicati
L'immagine sopra riassume i requisiti di configurazione dell'IP e del certificato per la distribuzione di **Zoom Meetings Hybrid** in ambienti on-premises o cloud ibrido. La tabella seguente suddivide il Node di esempio e include i suoi moduli di servizio proxy attiva e MMR: | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------------- | -------------------- | ----------------------------------- | -------------------------------------------------------- | | sistema operativo del Node | `node1.customer.com` | Nome comune (CN) | Orchestrazione principale | | Connettore Zoom Proxy | `zcp1.customer.com` | Nome alternativo del soggetto (SAN) | Segnalazione e controllo della sessione | | Router del modulo multimediale 1 | `mmr1.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento ed elaborazione dei contenuti multimediali | | Router del modulo multimediale 2 | `mmr2.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento ed elaborazione dei contenuti multimediali | | Router del modulo multimediale 3 | `mmr3.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento ed elaborazione dei contenuti multimediali | {% hint style="info" %} È necessario assegnare a ciascun modulo un Indirizzo IP statico dedicato. Indirizzi IP totali richiesti: cinque (5) {% endhint %}
L'immagine sopra delinea la configurazione minima necessaria per distribuire **Sopravvivenza locale di Zoom Phone (ZPLS)**. ZPLS consente di mantenere la disponibilità del servizio telefonico in caso di interruzione di internet o del cloud eseguendo la logica di survivability localmente su una VM Zoom Node. I seguenti nomi host devono essere configurati nel DNS e inclusi nel certificato TLS: * `node1.customer.com` * `zplsl.customer.com` **Mappatura funzionale del nome host** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------- | -------------------- | ----------------------------- | ---------------------------------------- | | sistema operativo del Node | `node1.customer.com` | Nome comune (CN) | Orchestrazione principale | | Modulo ZPLS | `zplsl.customer.com` | Nome alternativo del soggetto | Logica di Zoom Phone Local Survivability | **Configurazione del certificato TLS** | Campo | Valore | | ----------------------------- | -------------------- | | Nome comune (CN) | `node1.customer.com` | | Nomi alternativi del soggetto | `zplsl.customer.com` | I certificati devono essere generati o procurati (CA pubblica o privata) per includere sia il CN sia i SAN elencati sopra. Ciò consente una corretta convalida TLS per una comunicazione sicura tra moduli. **Requisiti dell'Indirizzo IP** | Metrica | Valore / Descrizione | | ----------------------------- | ---------------------------------------------------------------- | | Indirizzi IP totali richiesti | 5 (allocazione generale) | | Usato nel contesto ZPLS | 2 IP (1 per il sistema operativo del Node, 1 per il modulo ZPLS) | Sebbene siano richiesti cinque (5) IP per la distribuzione generale, **vengono utilizzati attivamente solo due (2) Indirizzo IP** nella distribuzione ZPLS: uno per modulo, in esecuzione su un **VM Node dedicata**. {% hint style="warning" %} ZPLS consente un solo modulo per VM Node. Non puoi co-localizzare ZPLS con altri moduli Zoom sulla stessa VM. {% endhint %} In che modo questi diagrammi si confrontano? La prima immagine mostra un esempio di distribuzione ibrida di Zoom Meetings. La seconda immagine mostra un esempio di distribuzione di Zoom Phone Local Survivability. Se desiderato, puoi condividere il primo Indirizzo IP/hostname tra il sistema operativo e il primo modulo, per ridurre il numero di Indirizzi IP, hostname e Subject Alternative Names (SAN) richiesti. ### Opzione 2: Zoom Meetings Hybrid distribuito con un IP condiviso e un hostname condiviso
Questa configurazione ripete la struttura Node come mostrato nel diagramma di Zoom Meetings Hybrid dell'Opzione 1. Tuttavia, in questa distribuzione, il **Il sistema operativo del Node condivide il proprio Indirizzo IP con il primo modulo distribuito** (in genere il Proxy Connettore Zoom, ZCP). Ciò comporta una riduzione dell'utilizzo degli IP mantenendo i requisiti TLS e funzionali. I seguenti nomi host devono essere configurati nel DNS e inclusi nel certificato TLS: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Mappatura funzionale del nome host** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------------- | ------------------- | ----------------------------------- | -------------------------------------------------------- | | ZCP (Proxy Connettore Zoom) | `zcp1.customer.com` | Nome comune (CN) | Segnalazione e controllo della sessione | | Router del modulo multimediale 1 | `mmr1.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento ed elaborazione dei contenuti multimediali | | Router del modulo multimediale 2 | `mmr2.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento ed elaborazione dei contenuti multimediali | | Router del modulo multimediale 3 | `mmr3.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento ed elaborazione dei contenuti multimediali | **Configurazione del certificato TLS** | Campo | Valore | | ----------------------------- | ------------------------------------------------------------- | | Nome comune (CN) | `zcp1.customer.com` | | Nomi alternativi del soggetto | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | I certificati devono includere tutti i SAN per supportare la comunicazione TLS sicura tra Zoom Node e i moduli Zoom installati. **Requisiti dell'Indirizzo IP** | Metrica | Valore / Descrizione | | -------------------------------------- | ---------------------------------------------------------------------- | | Indirizzi IP totali richiesti | 4 | | Strategia di condivisione IP | Il sistema operativo del nodo condivide l'IP con il primo modulo (ZCP) | | Indirizzi IP individuali richiesti per | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Quando l'Indirizzo IP è **condiviso** tra il sistema operativo del nodo e il primo modulo distribuito (ZCP), solo **quattro (4) Indirizzi IP** sono richiesti. Questo design ottimizza l'uso degli IP pur rispettando gli standard di distribuzione. {% endhint %}
L'immagine sopra mostra una distribuzione ZPLS minima in cui il **Il sistema operativo del nodo condivide il proprio Indirizzo IP con il modulo ZPLS installato**. Questo è il **solo scenario** nel framework Zoom Node in cui un **certificato TLS per singolo organizzatore** è valido. Il seguente hostname deve essere configurato nel DNS e incluso nel certificato TLS: * `zplsl.customer.com` **Mappatura funzionale del nome host** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | ----------- | -------------------- | ------------------------- | ---------------------------------------- | | Modulo ZPLS | `zplsl.customer.com` | Nome comune (CN) | Logica di Zoom Phone Local Survivability | **Configurazione del certificato TLS** | Campo | Valore | | ---------------- | ------------------- | | Nome comune (CN) | `zcp1.customer.com` | | SAN | (non richiesto) | In questa configurazione, è sufficiente un certificato a organizzatore singolo poiché sia il sistema operativo sia il modulo ZPLS condividono lo stesso nome organizzatore e Indirizzo IP. **Requisiti dell'Indirizzo IP** | Metrica | Valore / Descrizione | | ----------------------------- | ------------------------------------------------------------------------ | | Indirizzi IP totali richiesti | 1 | | Strategia di condivisione IP | Il sistema operativo del Nodo e ZPLS condividono un singolo Indirizzo IP | | Vincolo di distribuzione | È consentito un solo modulo per VM del Nodo (solo ZPLS) | {% hint style="warning" %} ZPLS è l'unico scenario supportato nell'architettura Zoom Node in cui: * È accettabile un certificato per singolo organizzatore (solo CN) * Per la distribuzione è richiesto solo un (1) Indirizzo IP grazie alla condivisione dell'IP tra sistema operativo e modulo * La co-locazione di moduli aggiuntivi sulla stessa VM non è supportata {% endhint %} ### Decidi quale metodo di gestione dei certificati funziona meglio per le tue distribuzioni Ogni modulo di servizio distribuito su Zoom Node richiede un certificato valido firmato da un'autorità di certificazione (CA) pubblicamente attendibile presente nell'elenco di attendibilità del certificato di Zoom Node. Ciò include autorità pubbliche ben note. Zoom Node offre due metodi di gestione dei certificati: * **PKI automatica**: Questa soluzione innovativa automatizza l'iscrizione e il rinnovo sicuri dei certificati con Autorità di certificazione (CA) pubblicamente attendibili. Zoom copre i costi associati all'iscrizione e al rinnovo. * **Porta il tuo certificato (BYOC)**: Con questa opzione, fornisci i tuoi certificati, firmati da qualsiasi CA principale pubblicamente attendibile. Ti occupi dell'iscrizione e dei rinnovi dei certificati. Si applicano ulteriori considerazioni riguardo al potenziale di Zoom Node per un massimo di cinque nomi host/SAN quando si utilizzano certificati forniti dal cliente, che sono descritte più dettagliatamente di seguito. #### Gestione automatica dei certificati con PKI automatica Zoom Auto PKI installa automaticamente certificati CA validi e pubblicamente attendibili per la piattaforma Zoom Node, nonché per tutti i moduli distribuiti su di essa. Anche il rinnovo del certificato viene gestito automaticamente. Questo semplifica la gestione dei certificati per tutti i servizi e per lo stesso Zoom Node. #### Comprendere l'iscrizione e il rinnovo del certificato Auto PKI Lo scenario seguente può aiutarti a capire come funzionano l'iscrizione e il rinnovo del certificato. Per esempio: un amministratore ha distribuito una nuova istanza Node. Ogni istanza richiede un certificato x509 valido. **La chiave privata del certificato non deve mai lasciare questa istanza**. Il processo Auto PKI esegue i seguenti passaggi: 1. **Recupero del modello**: Recupera tutti i modelli di configurazione supportati, incluse le opzioni per più provider CA, dal servizio Auto PKI nel cloud Zoom. 2. **Raccolta degli Indirizzi IP**: Raccoglie tutti gli indirizzi IP utilizzati dai servizi in esecuzione sul Node e li invia al servizio Auto PKI nel cloud Zoom. 3. **Provisioning del nome DNS**: Il servizio cloud Auto PKI restituisce un insieme di nomi DNS nel formato `..zoomonprem.com`. Questi domini sono configurati con record A/AAAA. 4. **Richiesta di nome DNS riservato**: Richiede un nome DNS riservato nel formato `rsvd-..zoomonprem.com`. 5. **Generazione della richiesta di certificato**: Genera una richiesta di certificato x509, utilizzando i nomi DNS del terzo passaggio nel campo SAN e il nome riservato del quarto passaggio nel campo Common Name (CN). 6. **Emissione del certificato**: Invia la richiesta di firma del certificato (CSR) al servizio Auto PKI nel cloud Zoom. Questo servizio collabora quindi con i fornitori CA per emettere il certificato, che include l'elenco SAN e il campo CN del passaggio precedente. 7. **Archiviazione locale**: Scrive il certificato x509 appena emesso dall'ultimo passaggio e la chiave privata corrispondente (generata in precedenza) nell'archiviazione locale, rendendoli disponibili per i servizi in esecuzione sull'istanza Node. Auto PKI semplifica la gestione dei certificati su Zoom Node monitorando automaticamente le date di scadenza e richiedendo nuovi certificati, eliminando la necessità di rinnovo manuale. #### Porta i tuoi certificati (BYOC) Puoi installare i tuoi certificati validi e firmati pubblicamente su Zoom Node utilizzando l'interfaccia web locale. Puoi farlo durante l'installazione iniziale o in un secondo momento. Il processo sarà familiare a chi è abituato a installare certificati su applicazioni basate sul web. Se scegli di usare i tuoi certificati, ricorda che il certificato si troverà su un server che comunica con più hostname. Pertanto, il tipo di certificato che Scegli deve supportare la crittografia per il traffico proveniente da più di un hostname (CN del certificato). Tutti gli hostname utilizzati per Node e per tutti i servizi distribuiti devono essere risolvibili pubblicamente dai servizi cloud di Zoom. Zoom consiglia due tipi di certificati: * **Certificato wildcard** * **Certificato Multi-SAN** (noto anche come certificato Multi-Domain, certificato SAN o certificato UCC) {% hint style="danger" %} Un tipico certificato per singolo-organizzatore non funzionerà con Zoom Node, ad eccezione dello scenario specifico in cui un singolo Indirizzo IP e nome organizzatore sono condivisi tra Zoom Node e un singolo modulo. Per ulteriore contesto, vedere il diagramma ZPLS nel [#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") sezione. {% endhint %} **Certificati wildcard: consigliati per semplicità** Un certificato wildcard può crittografare il traffico proveniente da qualsiasi hostname nel dominio. Ad esempio: un certificato wildcard come \*.customer.com può crittografare il traffico proveniente da `host1.customer.com` sia `host2.customer.com` o qualsiasi nome all'interno di `.customer.com`. Quando distribuisci Zoom Node e installi il certificato wildcard, questo cifrerà automaticamente il traffico per qualsiasi servizio che distribuisci sul Node, con il requisito che tutti i servizi distribuiti utilizzino un Nome di Dominio Completamente Qualificato (FQDN) dal dominio wildcard. Questo riduce al minimo lo sforzo per distribuire servizi sul Node: non devi conoscere i nomi dei servizi prima di distribuirli. Tuttavia, devi conoscere i nomi dei servizi se usi il metodo di certificato multi-SAN. **Certificati Multi-SAN, Multi-Dominio, SAN o UCC** {% hint style="warning" %} Devi conoscere i nomi host e gli indirizzi IP che utilizzerai per il Node (fino a uno \[1]) e tutti i Servizi che installerai (fino a quattro \[4]). **Queste informazioni sono richieste prima di registrare un certificato**. {% endhint %} Un certificato Multi-SAN è necessario per Zoom Node perché cifra il traffico proveniente da cinque (5) nomi host. Una richiesta una tantum per questo certificato richiede la conoscenza preventiva di tutte le informazioni necessarie, inclusi i nomi pianificati del Node e i nomi di tutti i servizi previsti per la distribuzione sul Node. Ad esempio, con un modulo come ZPLS, viene distribuito un solo modulo ZPLS per Node, quindi è necessario un solo SAN aggiuntivo per il nome host del servizio ZPLS. La seguente tabella può essere usata come esempio: | Hostname (SAN) | Indirizzo IP | | ----------------------------------------------- | ------------- | | `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` | | (Servizio 4 - non utilizzato in questo esempio) | (N/D) | Questo esempio mostra una configurazione tipica, con un solo Node che ospita ZPLS sullo stesso IP più altri due servizi su IP separati. Sostituisci “company.com” con il tuo dominio effettivo e usa gli indirizzi IP della tua rete. **Requisiti di risoluzione DNS** Zoom richiede che gli hostname siano risolvibili pubblicamente in modo che possa essere stabilita una fiducia bidirezionale. Tutti gli hostname di Zoom Node e tutti gli hostname dei servizi distribuiti sui Node devono essere inclusi nella zona DNS. Se la tua Organizzazione gestisce servizi o domini DNS interni ed esterni separati, i nomi host di Zoom Node devono essere ospitati in una zona risolvibile dai tuoi server DNS esterni (può essere limitata a risolvere solo per intervalli IP Zoom). I tuoi utenti Zoom interni e il cloud Zoom devono comunicare utilizzando lo stesso insieme di nomi host. --- # 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/it/servizi-avanzati-enterprise/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.