> 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/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).
# Considerazioni sull'implementazione dell'hardware
Questa pagina illustra la distribuzione del modulo ZPLS di Zoom Node su una macchina virtuale utilizzando hypervisor supportati. Fornisce opzioni di configurazione dettagliate, studiate per adattarsi a diverse capacità hardware, garantendo prestazioni ottimali per varie esigenze operative.
### Hypervisor supportati
#### I Clienti devono installare il software Zoom Node su una macchina virtuale eseguita su un hypervisor supportato
Come workload di Zoom Node, il modulo ZPLS deve essere installato su una macchina virtuale che esegue la piattaforma Zoom Node, su un [hypervisor supportato](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Ulteriori informazioni su Zoom Node come prodotto sono disponibili [nell'Appendice](#_a2lvsihjp0ek).
#### I Clienti possono scegliere una delle due opzioni di configurazione, a seconda delle capacità hardware
Il modulo ZPLS supporta due configurazioni, a seconda delle capacità hardware della macchina virtuale. Queste capacità sono elencate di seguito:
| | Opzione di configurazione 1 | Opzione di configurazione 2 |
| ------------------------------- | -------------------------------------------------- | --------------------------------------------------- |
| **Specifiche hardware** | 8 CPU
16 GB di RAM
80 GB di HDD
| 16 CPU
16 GB di RAM
80 GB di HDD
|
| **Registrazioni totali** | 2000 | 5000 |
| **Chiamate simultanee massime** | 240 | 480 |
| **Chiamate al secondo** | 2 | 4 |
| **Registrazioni al secondo** | 60 | 400 |
{% hint style="info" %}
Se il numero di endpoint all'interno di una sede abilitata per la sopravvivenza supera le capacità di distribuzione della sede, il modulo ZPLS elaborerà le registrazioni in base all'ordine di arrivo. I Clienti sono invitati ad aggiungere moduli aggiuntivi o a utilizzare l'impostazione Zoom Phone Policy [**Modalità di sopravvivenza locale**](#_ah8xua8wdq10) per stabilire la priorità degli utenti che supportano il failover di sopravvivenza.
{% endhint %}
### Scalabilità e resilienza del modulo
#### I moduli ZPLS supportano il clustering per una scalabilità e/o resilienza aggiuntiva
I Clienti possono raggruppare i moduli ZPLS fino a 20 moduli per sede (o 100 dispositivi Node totali per account) per ulteriore ridondanza o scalabilità.
{% hint style="info" %}
Questa Funzionalità è attualmente in beta e richiede un ticket di assistenza tecnica per essere abilitata.
{% endhint %}
#### La scalabilità aumenta le capacità dei dispositivi supportati di una sede
L'aumento del numero di moduli ZPLS accresce linearmente le capacità di ogni sede per ogni modulo aggiuntivo. Ad esempio, se un modulo supporta un totale di 5.000 registrazioni, la distribuzione di cinque moduli porterà il supporto a 25.000 registrazioni.
#### La ridondanza aggiunge moduli aggiuntivi per la resilienza, ma non scala le capacità dei dispositivi di una sede
Quando un modulo ZPLS viene utilizzato per finalità di ridondanza, i moduli ridondanti non contribuiscono al numero totale di interni supportati. Invece, i moduli sono in “hot standby” e si attivano solo in caso di guasto dei moduli primari. Ad esempio, un modulo primario e uno ridondante supportano un totale di 5.000 registrazioni, quindi se un modulo primario si guasta, il modulo ridondante non viene sovraccaricato di dispositivi oltre il proprio limite supportato.
#### Esempio di distribuzione di ZPLS con scalabilità e ridondanza
Per comodità, l'esempio seguente mostra una distribuzione con scalabilità e ridondanza aggiuntive.
{% hint style="success" %}
**Esempio**:
Un ospedale deve supportare fino a 10.000 interni registrati per la sopravvivenza. Per raggiungere questo obiettivo, l'ospedale sta distribuendo quattro moduli ZPLS.
I primi due moduli sono in grado di supportare 5.000 registrazioni ciascuno, con una capacità totale fino a 10.000 registrazioni. Tuttavia, riconoscendo l'importanza della resilienza, l'ospedale sta inoltre distribuendo due moduli aggiuntivi come backup ridondanti dei moduli primari.
In questo scenario, l'ospedale dispone ora di hardware primario e secondario per la sopravvivenza distribuito. Ora, se un modulo primario subisce un guasto, i moduli ridondanti subentra per mantenere il servizio ininterrotto, continuando a supportare fino a 10.000 dispositivi registrati.
{% endhint %}
### Considerazioni sulla progettazione della sede
#### Le sedi raggruppano gli utenti di Zoom Phone per Posizione per Impostazioni e policy comuni di telefonia
Un **sede** è un termine specifico utilizzato all'interno di Zoom Phone che raggruppa gli utenti con caratteristiche condivise — come un comune codice di accesso, indirizzo, SIP Zone, dipartimento o policy — in un unico gruppo gestibile all'interno del Zoom web portal. Per alcuni Clienti, una singola sede può rappresentare tutti gli utenti all'interno della loro Business e può estendersi su più edifici all'interno di un campus o di una Posizione; per altri, possono essere necessari Siti multipli a seconda delle esigenze aziendali. Per ulteriori informazioni sulle sedi o sulla gestione delle sedi, [fare riferimento al Centro assistenza di Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).
#### Zoom Phone supporta design a sede singola e multi-sede
Esistono due design principali per configurare le sedi di Zoom Phone in un account:
1. **Sede singola**: Rappresenta tutti gli utenti all'interno di un account, potenzialmente distribuiti in più edifici o Posizioni, all'interno di una singola sede di Zoom Phone.
2. **Siti multipli**: Rappresenta separatamente segmenti di utenti per Posizione, edificio, dipartimento o funzione, ciascuno con la propria sede.
{% hint style="info" %}
Gli amministratori dell'account degli attuali Clienti Zoom possono verificare il loro attuale design della sede tramite la [**Informazioni sull'azienda**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) pagina, Disponibile nel menu del portale web. **Gestione del sistema telefonico** menu del portale web.
{% endhint %}
#### Ogni modulo ZPLS può essere associato solo a una sede alla volta
Come già menzionato, un modulo ZPLS è il [registrar di terza priorità](#_7itj40mx1dut) per i dispositivi supportati, dietro le zone SIP primaria e secondaria. Poiché i dispositivi ricevono i propri elenchi SRV durante il processo di avvio e questi elenchi sono collegati all'impostazione della loro sede, **ogni modulo ZPLS può essere associato solo a una sede alla volta**.
#### Ogni sede può supportare fino a 20 moduli ZPLS contemporaneamente
Sebbene ogni modulo ZPLS possa essere associato solo a una sede alla volta, una sede può supportare fino a 20 moduli ZPLS in un unico gruppo, espandendo le capacità di sopravvivenza di ciascuna sede.
{% hint style="info" %}
Questa Funzionalità è attualmente in beta e richiede un ticket di assistenza tecnica per essere abilitata.
{% endhint %}
#### I moduli ZPLS supportano le chiamate tra sedi se i moduli sono connessi a una rete comune
I moduli ZPLS di sedi diverse supportano le chiamate tra sedi durante un evento di sopravvivenza, purché i dispositivi siano individuabili all'interno della rete locale. Ad esempio, se un campus aziendale ha tre edifici, ciascuno con la propria sede telefonica, i moduli ZPLS di ciascuna sede possono collegare chiamate tra sedi attraverso la rete dell'area del campus.
{% hint style="info" %}
Questa Funzionalità è attualmente in beta e richiede un ticket di assistenza tecnica per essere abilitata.
{% endhint %}
#### Prima di distribuire ZPLS, gli account dovrebbero comprendere quale configurazione della sede sia più adatta alle loro esigenze
Poiché ogni modulo ZPLS può essere associato solo a una sede alla volta, la progettazione della sede è uno dei fattori più importanti durante la distribuzione del servizio ZPLS in un account. Per questo motivo, i Clienti dovrebbero capire quale configurazione della sede è la migliore per soddisfare le loro esigenze pratiche di Business e di sopravvivenza, poiché ogni sede aggiuntiva abilitata per la sopravvivenza richiederà almeno un modulo ZPLS aggiuntivo.
#### Una progettazione a sede singola è più facile da gestire e offre sopravvivenza con un singolo modulo ZPLS, ma offre meno flessibilità per Impostazioni utente e policy
Una progettazione a sede singola aiuta a semplificare la gestione delle Impostazioni e delle policy di Zoom Phone consolidando tutti gli utenti di un account in un unico gruppo unificato. Questo singolo gruppo di utenti offre alle Business un'amministrazione semplice e una complessità ridotta, semplificando il processo di gestione. Inoltre, una progettazione a sede singola può offrire la sopravvivenza telefonica locale con un singolo modulo ZPLS, purché gli utenti della sede non superino le [capacità di un singolo modulo](#_rx0i1j9xofnc).
Tuttavia, la semplicità di una progettazione a sede singola include naturalmente dei limiti. In particolare, le progettazioni a sede singola offrono meno flessibilità a causa della loro natura “one size fits all”, che potrebbe non essere adatta a tutti gli scenari di distribuzione in più dipartimenti con esigenze diverse. Inoltre, le distribuzioni a sede singola possono essere vulnerabili in determinati scenari di sopravvivenza se la [rete locale si guasta](#_gzpf5m70jl3i).
#### Una progettazione multi-sede offre maggiore flessibilità per Impostazioni utente e policy, ma richiede un modulo ZPLS per ogni sede abilitata alla sopravvivenza ed è più complicata da gestire
Una progettazione multi-sede offre alle Business ulteriore flessibilità nelle Impostazioni utente e nelle policy, separando gli utenti in vari gruppi con controlli granulari sulle Impostazioni. Questa progettazione consente alle organizzazioni di regolare in modo dettagliato le configurazioni di comunicazione per soddisfare requisiti specifici in diverse sedi, offrendo un'esperienza utente più raffinata e adattabile per vari dipartimenti, scenari o esigenze. Inoltre, le distribuzioni multi-sede possono supportare [comunicazione tra sedi](#_a42hwaw1pfmx) se le sedi sono collegate tramite una rete comune.
Tuttavia, la gestione di una progettazione multi-sede richiede una particolare attenzione alle complessità dei requisiti unici di ciascuna sede, che possono richiedere un livello più elevato di impegno amministrativo. Inoltre, poiché ogni modulo ZPLS può essere assegnato solo a una sede alla volta, ogni sede abilitata alla sopravvivenza richiederà un modulo ZPLS e una licenza, il che può contribuire a una configurazione più intensiva in termini di risorse.
{% hint style="info" %}
In una progettazione multi-sede, i Clienti hanno la flessibilità di scegliere quali sedi saranno configurate per la sopravvivenza. Le sedi *senza* un modulo ZPLS rimarrà impossibilitato a effettuare o ricevere chiamate fino al ripristino della connettività standard.
{% endhint %}
### Guasti di rete
#### La sopravvivenza può essere compromessa se la rete locale di una sede si guasta
Sebbene i moduli ZPLS siano progettati per fornire sopravvivenza telefonica locale durante eventi che impattano il servizio, la sopravvivenza può essere compromessa se la rete locale di una sede si guasta. Questi scenari sono illustrati nelle due sezioni seguenti.
#### Guasto della rete locale a sede singola
In una progettazione a sede singola, uno o più edifici sono collegati tramite una rete locale o di area campus e sono rappresentati da una singola sede all'interno di Zoom Phone. Questa configurazione presuppone una rete comune tra tutti gli utenti e gli edifici all'interno di una Posizione, senza dipendenze da reti esterne (ad es. Internet) per la comunicazione tra edifici.
Con questa progettazione della sede, una Business può fornire sopravvivenza locale a tutti gli utenti all'interno di una singola sede o Posizione con appena un modulo ZPLS; tuttavia, questa progettazione è vulnerabile in caso di un'interruzione della rete locale o del campus che comprometta la comunicazione tra edifici. L'esempio seguente descrive come un guasto della rete locale possa influire su una distribuzione a sede singola.
{% hint style="success" %}
**Esempio:**
Un'azienda sta distribuendo il modulo ZPLS per una singola sede di Zoom Phone, composta dagli edifici A, B e C, collegati tramite una rete di area campus. Il modulo ZPLS è operativo nell'Edificio A ed è **non** collegato a un SBC per le chiamate esterne attraverso il PSTN.
In caso di guasto di un servizio Internet esterno o di un evento che impatta il servizio, qualsiasi utente contenuto nella sede può chiamare un altro utente nella *stessa* sede, purché entrambi gli utenti mantengano la connettività con il modulo ZPLS attraverso la rete di area campus.
Tuttavia, in caso di un'interruzione della rete di area campus, gli utenti all'interno degli edifici B e C non possono effettuare chiamate mentre il modulo ZPLS all'interno dell'Edificio A è irraggiungibile. Di conseguenza, gli utenti all'interno degli edifici B e C devono attendere il ripristino della rete di area campus per le chiamate di sopravvivenza.
{% endhint %}
La tabella seguente dimostra la sopravvivenza di Zoom Phone in una progettazione a sede singola con più edifici:
| Chiamate originate dall'edificio | Possono raggiungere queste Posizioni durante un guasto di Internet esterno | Possono raggiungere queste Posizioni durante un guasto della rete di campus |
| -------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Edificio A (organizzatore ZPLS) | ☑️Edifici A, B e C | ☑️ Edificio A *solo* |
| Edificio B | ☑️Edifici A, B e C | ✖️ |
| Edificio C | ☑️Edifici A, B e C | ✖️ |
#### Guasto della rete locale multi-sede senza un SBC
In una progettazione multi-sede, ciascun edificio o Posizione (ad es. piano, ufficio satellite, ecc.) è rappresentato in modo indipendente da una sede univoca all'interno di Zoom Phone. Questa configurazione presuppone che ogni sede disponga di un modulo ZPLS e che le sedi siano collegate tramite una rete di area campus comune.
Con questa progettazione della sede, ogni sede supporta il proprio modulo ZPLS, consentendo agli utenti all'interno dello stesso edificio di chiamarsi a vicenda quando la modalità di sopravvivenza è attiva. Inoltre, quando Siti multipli con un modulo ZPLS sono collegati tramite una rete comune, gli utenti possono chiamare gli utenti di \_altre\_sedi, purché la rete locale rimanga operativa. Tuttavia, questa progettazione è vulnerabile in caso di un'interruzione della rete di area campus che comprometta la comunicazione tra edifici. L'esempio seguente descrive come un guasto della rete di campus possa influire su una distribuzione multi-sede.
{% hint style="success" %}
**Esempio:**
Un'azienda sta distribuendo il modulo ZPLS nel proprio campus con più edifici, composto dagli edifici A, B e C. Ogni edificio è una sede univoca all'interno di Zoom Phone e mantiene un modulo ZPLS specifico per la sede. Tutti gli edifici all'interno del campus sono collegati tramite una rete di area campus che non dipende da un servizio Internet esterno per le comunicazioni tra edifici.
In questo esempio, in caso di guasto di un servizio Internet esterno, di un'interruzione della rete di campus o di un evento che impatta il servizio, qualsiasi utente presente in una sede può chiamare un altro utente presente nella stessa sede. Tuttavia, poiché ogni edificio è una sede univoca e gli utenti si registrano ai moduli specifici della loro sede, se la rete di campus si guasta, i moduli ZPLS non possono instradare le chiamate tra sedi. Invece, gli utenti saranno limitati a effettuare chiamate verso altri utenti all'interno della loro sede locale.
{% endhint %}
La tabella seguente dimostra la sopravvivenza di Zoom Phone dell'esempio precedente in una progettazione multi-sede con una rete di campus interconnessa:
| Chiamate originate dall'edificio | Possono raggiungere queste Posizioni durante un guasto di Internet esterno | Possono raggiungere queste Posizioni durante un guasto della rete di campus |
| -------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Edificio A (organizzatore ZPLS) | ☑️ Edifici A, B e C | ☑️ Edificio A |
| Edificio B (organizzatore ZPLS) | ☑️ Edifici A, B e C | ☑️ Edificio B |
| Edificio C (organizzatore ZPLS) | ☑️ Edifici A, B e C | ☑️ Edificio C |
#### Se la rete locale si guasta, le chiamate tra sedi sono supportate anche tramite il PSTN, a condizione che ogni sede sia collegata a un SBC e abbia il trasferimento di chiamata abilitato
In caso di guasto della rete locale, i Clienti con una progettazione multi-sede che integra il modulo ZPLS con un SBC e connettività PSTN in ogni sede possono abilitare le chiamate da sede a sede se [il trasferimento di chiamata è abilitato](#_2v7qst7vxwaa) . Quando configurato, le chiamate telefoniche effettuate durante la modalità di sopravvivenza verranno instradate dal client dell'utente al PSTN, quindi all'SBC e al modulo ZPLS della seconda sede, arrivando infine al Dispositivo del destinatario. Il diagramma seguente fornisce una panoramica di questa configurazione:
{% hint style="danger" %}
Questa configurazione **richiede** l'elaborazione dei numeri di telefono E.164 sugli SBC configurati.
{% endhint %}
La tabella seguente dimostra inoltre la sopravvivenza di Zoom Phone in una progettazione multi-sede con SBC indipendenti:
| Chiamate originate dall'edificio | Possono raggiungere queste Posizioni durante un guasto di Internet esterno | Possono raggiungere queste Posizioni durante un guasto della rete di campus |
| -------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Edificio A (organizzatore ZPLS) | ☑️Edifici A, B e C | ☑️Edifici A, B e C |
| Edificio B (organizzatore ZPLS) | ☑️Edifici A, B e C | ☑️Edifici A, B e C |
| Edificio C (organizzatore ZPLS) | ☑️Edifici A, B e C | ☑️Edifici A, B e C |
#### Gli utenti nomadi si registrano sempre al modulo ZPLS associato alla loro sede principale
Quando utenti o Dispositivo vengono aggiunti a Zoom Phone, una sede “home” viene associata staticamente all'utente o al Dispositivo fino a quando non viene aggiornata da un amministratore dell'account. Ciò significa che se un utente si sposta in una Posizione fisica al di fuori della propria sede principale associata, ad esempio in un edificio per uffici associato a una sede diversa, Zoom non modificherà dinamicamente la sede associata all'utente. Di conseguenza, se l'utente perde la connettività con i data center di Zoom Phone, tenterà di registrarsi al modulo ZPLS associato alla propria sede principale, anche se si trova in una Posizione diversa.
{% hint style="success" %}
**Esempio:**
Un utente in un campus multi-sede è basato nell'Edificio A (Sede A) e si sposta temporaneamente nell'Edificio B (Sede B) per una riunione. Mentre si trova nell'Edificio B, si verifica un evento che impatta il servizio e viene attivata la modalità di sopravvivenza. Sebbene l'utente si trovi nell'Edificio B, poiché la Sede A è la sua sede principale, il client dell'utente tenterà di connettersi al modulo ZPLS provisionato nella propria sede principale all'interno dell'Edificio A.
In questo scenario, lo stato di sopravvivenza di un utente è determinato dalla capacità del Dispositivo dell'utente di registrarsi al modulo ZPLS all'interno della propria sede principale attraverso la rete di area campus. Se la rete di area campus non funziona mentre l'utente è lontano dalla propria sede principale, l'utente non può beneficiare del modulo di sopravvivenza.
{% endhint %}
---
# 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/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-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.