> 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-enterprise-avanzati/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Considerazioni per la distribuzione di Zoom Node Scopri di più su come vari esempi di distribuzione supportano Zoom Node e i moduli di servizio 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 distribuzioni 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) Indirizzi 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 solo servizio (come ZPLS) può essere distribuito con un solo Indirizzo IP se al Node e al servizio viene assegnato di condividere lo stesso Indirizzo IP. Di seguito sono mostrate diverse opzioni di distribuzione. Nota il numero di IP e certificati (CN/SAN) per le varie opzioni di distribuzione. ### Opzione 1: Zoom Meetings Hybrid distribuito con IP dedicati e hostname
L'immagine sopra riassume i requisiti di configurazione di IP e certificato per la distribuzione di **Zoom Meetings Hybrid** in ambienti on-premise o cloud ibridi. La tabella seguente analizza il Node di esempio e include i relativi moduli di servizio proxy attivo e MMR: | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------------- | -------------------- | ----------------------------------- | --------------------------------------- | | sistema operativo del nodo | `node1.customer.com` | Nome comune (CN) | Orchestrazione centrale | | Proxy Connettore Zoom | `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 e elaborazione dei media | | Router del modulo multimediale 2 | `mmr2.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento e elaborazione dei media | | Router del modulo multimediale 3 | `mmr3.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento e elaborazione dei media | {% hint style="info" %} Devi 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 **Zoom Phone Local Survivability (ZPLS)**. ZPLS consente la continuità del servizio telefonico in caso di Evento di interruzione di Internet o del cloud eseguendo la logica di resilienza localmente su una VM di Zoom Node. I seguenti hostname devono essere configurati nel DNS e inclusi nel certificato TLS: * `node1.customer.com` * `zplsl.customer.com` **Mappatura funzionale dell'hostname** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------- | -------------------- | ----------------------------- | ---------------------------------------- | | sistema operativo del nodo | `node1.customer.com` | Nome comune (CN) | Orchestrazione centrale | | 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 acquistati (CA pubblica o privata) per includere sia il CN sia i SAN elencati sopra. Questo consente una corretta validazione TLS per una comunicazione sicura tra i moduli. **Requisiti dell'Indirizzo IP** | Metrica | Valore / Descrizione | | ----------------------------- | -------------------------------------------------------------------------- | | Indirizzi IP totali richiesti | 5 (allocazione generale) | | Usato nel contesto ZPLS | 2 Indirizzi IP (1 per il sistema operativo del Node, 1 per il modulo ZPLS) | Sebbene per la distribuzione generale siano richiesti cinque (5) IP, **solo due (2) Indirizzi IP sono effettivamente utilizzati** nella distribuzione ZPLS: uno per modulo, in esecuzione su una **VM Node dedicata**. {% hint style="warning" %} ZPLS consente un solo modulo per VM Node. Non è possibile collocare ZPLS insieme ad altri moduli Zoom sulla stessa VM. {% endhint %} Come si confrontano questi diagrammi? La prima immagine mostra un esempio di una distribuzione ibrida di Zoom Meetings. La seconda immagine mostra un esempio di una distribuzione Zoom Phone Local Survivability. Se desiderato, puoi condividere il primo Indirizzo IP/nome organizzatore tra il sistema operativo e il primo modulo, per ridurre il numero di indirizzi IP, nomi organizzatore e Subject Alternative Names (SAN) richiesti. ### Opzione 2: Zoom Meetings Hybrid distribuito con un Indirizzo IP e un nome organizzatore condivisi
Questa configurazione ripete la struttura Node illustrata nel diagramma Zoom Meetings Hybrid dell'opzione 1. Tuttavia, in questa distribuzione, il **Il sistema operativo Node condivide il proprio Indirizzo IP con il primo modulo distribuito** (in genere Zoom Connettore Proxy, ZCP). Ciò comporta un utilizzo ridotto degli indirizzi IP, mantenendo al contempo i requisiti TLS e funzionali. I seguenti hostname devono essere configurati nel DNS e inclusi nel certificato TLS: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Mappatura funzionale dell'hostname** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------------- | ------------------- | ----------------------------------- | --------------------------------------- | | ZCP (Zoom Connettore Proxy) | `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 e elaborazione dei media | | Router del modulo multimediale 2 | `mmr2.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento e elaborazione dei media | | Router del modulo multimediale 3 | `mmr3.customer.com` | Nome alternativo del soggetto (SAN) | Instradamento e elaborazione dei media | **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 Node condivide l'IP con il primo modulo (ZCP) | | Indirizzi IP singoli richiesti per | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Quando l'Indirizzo IP è **condiviso** tra il sistema operativo Node e il primo modulo distribuito (ZCP), sono necessari solo **quattro (4) indirizzi IP** Questo progetto ottimizza l'utilizzo degli IP, pur continuando a rispettare gli standard di distribuzione. {% endhint %}
L'immagine sopra mostra una distribuzione ZPLS minima in cui il **Il sistema operativo Node condivide il proprio Indirizzo IP con il modulo ZPLS installato**. Questo è l' **unico scenario** nel framework Zoom Node in cui un **certificato TLS per singolo organizzatore** è valido. Il seguente nome organizzatore deve essere configurato nel DNS e incluso nel certificato TLS: * `zplsl.customer.com` **Mappatura funzionale dell'hostname** | 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 per singolo organizzatore 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 Node e ZPLS condividono un unico Indirizzo IP | | Vincolo di distribuzione | È consentito un solo modulo per VM Node (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 un solo (1) Indirizzo IP grazie alla condivisione dell'IP tra sistema operativo e modulo * La collocazione di moduli aggiuntivi sulla stessa VM non è supportata {% endhint %} ### Decidi quale metodo di gestione dei certificati è più adatto alle tue distribuzioni Ogni modulo di servizio distribuito su Zoom Node richiede un certificato valido firmato da un'autorità di certificazione (CA) pubblicamente attendibile nell'elenco di attendibilità dei certificati di Zoom Node. Ciò include autorità pubbliche note. Zoom Node offre due metodi di gestione dei certificati: * **PKI automatica**: questa soluzione innovativa automatizza la registrazione e il rinnovo sicuri dei certificati presso autorità di certificazione (CA) pubblicamente attendibili. Zoom copre i costi associati alla registrazione e al rinnovo. * **Porta il tuo certificato (BYOC)**: con questa opzione, fornisci i tuoi certificati, firmati da qualsiasi CA principale pubblicamente attendibile. Gestisci la registrazione e i rinnovi dei certificati. Si applicano ulteriori considerazioni relative al potenziale di Zoom Node di supportare fino a cinque nomi organizzatore/SAN quando si utilizzano certificati forniti dal cliente, 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 dei certificati viene gestito automaticamente. Ciò semplifica la gestione dei certificati per tutti i servizi e per Zoom Node stesso. #### Informazioni sulla registrazione e sul rinnovo dei certificati Auto PKI Lo scenario seguente può aiutarti a comprendere come funzionano la registrazione e il rinnovo dei certificati. Ad 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 dei modelli**: 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 dei nomi 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 poi collabora con i fornitori di CA per emettere il certificato, che include l'elenco SAN e il campo CN del passaggio precedente. 7. **Archiviazione locale**: Scrive il nuovo certificato x509 emesso nell’ultimo passaggio e la relativa chiave privata (generata in precedenza) nell’archiviazione locale, rendendoli disponibili per i servizi in esecuzione sull’istanza Node. Auto PKI semplifica la gestione del certificato 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 usando l'interfaccia web locale. Puoi farlo durante l'installazione iniziale oppure in un secondo momento. Il processo sarà familiare a chi è abituato a installare certificati nelle 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 usati 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, tranne nello specifico scenario in cui un singolo Indirizzo IP e hostname sono condivisi tra Zoom Node e un singolo modulo. Per ulteriori dettagli, vedi il diagramma ZPLS nella [#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` e `host2.customer.com` o qualsiasi nome all'interno `.customer.com`. Quando distribuisci Zoom Node e installi il certificato wildcard, crittograferà automaticamente il traffico per qualsiasi servizio che distribuisci sul Node, a condizione che tutti i Servizi distribuiti utilizzino un Fully Qualified Domain Name (FQDN) del dominio wildcard. Questo riduce al minimo lo sforzo necessario per distribuire i servizi sul Node: non è necessario conoscere i nomi dei servizi prima di distribuirli. Tuttavia, è necessario conoscere i nomi dei servizi se si utilizza il metodo del certificato multi-SAN. **Certificati Multi-SAN, Multi-Domain, SAN o UCC** {% hint style="warning" %} Devi conoscere gli hostname e gli indirizzi IP che utilizzerai per il Node (fino a uno \[1]) e gli eventuali 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é crittografa il traffico proveniente da cinque (5) hostname. 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, per ogni Node viene distribuito un solo modulo ZPLS, quindi è necessario un solo SAN aggiuntivo per l'hostname del servizio ZPLS. La tabella seguente può essere usata come esempio: | Nome host (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 usato in questo esempio) | (N/D) | Questo esempio mostra una configurazione tipica, con un Node che ospita ZPLS sullo stesso IP più due servizi aggiuntivi 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 i nomi host siano risolvibili pubblicamente, in modo che possa essere stabilita una fiducia bidirezionale. Tutti i nomi host di Zoom Node e tutti i nomi host dei servizi distribuiti sui nodi devono essere inclusi nella zona DNS. Se la tua Organizzazione utilizza 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 alla sola risoluzione per gli intervalli IP di Zoom). I tuoi utenti interni di Zoom e cloud Zoom devono comunicare usando 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, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/it/servizi-enterprise-avanzati/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.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.