> 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 sulla distribuzione dell'hardware
Questa pagina descrive l'implementazione del modulo ZPLS di Zoom Node su una macchina virtuale utilizzando hypervisor supportati. Fornisce opzioni di configurazione dettagliate pensate 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 in esecuzione su un hypervisor supportato
Come carico di lavoro 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, in base alle capacità hardware
Il modulo ZPLS supporta due configurazioni, in base alle 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 HDD
| 16 CPU
16 GB di RAM
80 GB HDD
|
| **Registrazioni totali** | 2000 | 5000 |
| **Numero massimo di chiamate simultanee** | 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 con survivability Abilita supera le capacità di implementazione della sede, il modulo ZPLS elaborerà le registrazioni in base all'ordine di arrivo. Si consiglia ai Clienti di Aggiungere moduli aggiuntivi oppure di utilizzare l'impostazione della policy Zoom Phone [**Modalità di survivability locale**](#_ah8xua8wdq10) per stabilire la priorità degli utenti che supportano il failover di survivability.
{% endhint %}
### Scalabilità e resilienza del modulo
#### I moduli ZPLS supportano il clustering per una scalabilità e/o resilienza aggiuntive
I Clienti possono raggruppare i moduli ZPLS insieme con un massimo di 20 moduli per sede (o 100 Dispositivo Node totali per account) per una ridondanza o una scalabilità aggiuntive.
{% hint style="info" %}
Questa Funzionalità è attualmente in beta e richiede l'abilitazione tramite un ticket di assistenza tecnico.
{% endhint %}
#### La scalabilità aumenta le capacità dei Dispositivo supportati di una sede
L'espansione del numero di moduli ZPLS migliora linearmente le capacità di ogni sede per ogni modulo aggiuntivo. Ad esempio, se un modulo supporta un totale di 5.000 registrazioni, l'implementazione di cinque moduli porterà il supporto a 25.000 registrazioni.
#### La ridondanza aggiunge moduli aggiuntivi per la resilienza, ma non aumenta le capacità dei Dispositivo di una sede
Quando un modulo ZPLS viene utilizzato a scopo di ridondanza, i moduli ridondanti non contribuiscono al numero totale di interni supportati. Al contrario, i moduli sono in "hot standby" e si attiveranno 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 sarà sovraccaricato con dispositivi oltre il limite supportato.
#### Esempio di implementazione di ZPLS con scalabilità e ridondanza
Per comodità, l'esempio seguente dimostra un'implementazione con scalabilità e ridondanza aggiuntive.
{% hint style="success" %}
**Esempio**:
Un ospedale deve supportare fino a 10.000 interni registrati per la survivability. Per raggiungere questo obiettivo, l'ospedale sta implementando quattro moduli ZPLS.
I primi due moduli sono in grado di supportare 5.000 registrazioni ciascuno, per una capacità totale fino a 10.000 registrazioni. Tuttavia, riconoscendo l'importanza della resilienza, l'ospedale sta anche implementando due moduli aggiuntivi come backup ridondanti dei moduli primari.
In questo scenario, l'ospedale ora dispone di hardware di survivability primario e secondario implementato. Se un modulo primario subisce un guasto, i moduli ridondanti Subentraranno per mantenere il servizio senza interruzioni, continuando a supportare fino a 10.000 dispositivi registrati.
{% endhint %}
### Considerazioni sulla progettazione delle sedi
#### Le sedi raggruppano gli utenti Zoom Phone in base alla Posizione per Impostazioni e policy di telefonia comuni
A **sede** è un termine specifico utilizzato all'interno di Zoom Phone che raggruppa gli utenti con caratteristiche condivise — come un codice di accesso comune, un indirizzo, una zona SIP, un reparto o delle policy — in un unico gruppo gestibile all'interno di Zoom web portal. Per alcuni Clienti, una singola sede può rappresentare tutti gli utenti all'interno della propria Business e può estendersi su più edifici all'interno di un campus o di una Posizione; per altri, possono essere necessari Siti multipli in base alle esigenze della propria Business. 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 progettazioni a sede singola e multi-sede
Esistono due progettazioni principali per configurare le sedi Zoom Phone all'interno di 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 Zoom Phone.
2. **Multi-sede**: rappresenta separatamente segmenti di utenti per Posizione, edificio, reparto o funzione, ciascuno con la propria sede.
{% hint style="info" %}
Gli amministratore dell'account degli attuali Clienti Zoom possono verificare la progettazione corrente delle proprie sedi 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 **Gestione del sistema telefonico** menu sul web portal.
{% endhint %}
#### Ogni modulo ZPLS può essere associato a una sola sede alla volta
Come accennato in precedenza, un modulo ZPLS è il [registrar di terza priorità](#_7itj40mx1dut) per i dispositivi supportati, dopo le zone SIP primarie e secondarie. Poiché i dispositivi ricevono i propri elenchi SRV durante il processo di avvio, e tali elenchi sono collegati all'impostazione della loro sede, **ogni modulo ZPLS può essere associato a una sola sede alla volta**.
#### Ogni sede può supportare fino a 20 moduli ZPLS contemporaneamente
Sebbene ogni modulo ZPLS possa essere associato a una sola sede alla volta, una sede può supportare fino a 20 moduli ZPLS in un gruppo, ampliando le capacità di survivability di ogni sede.
{% hint style="info" %}
Questa Funzionalità è attualmente in beta e richiede l'abilitazione tramite un ticket di assistenza tecnico.
{% endhint %}
#### I moduli ZPLS supportano le chiamate tra sedi se i moduli sono collegati a una rete comune
I moduli ZPLS di sedi diverse supportano le chiamate tra sedi durante un Evento di survivability 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 le chiamate da sede a sede attraverso la rete del campus.
{% hint style="info" %}
Questa Funzionalità è attualmente in beta e richiede l'abilitazione tramite un ticket di assistenza tecnico.
{% endhint %}
#### Prima di implementare ZPLS, gli account devono comprendere quale configurazione della sede sia più adatta alle proprie esigenze
Poiché ogni modulo ZPLS può essere associato a una sola sede alla volta, la progettazione della sede è uno dei fattori più importanti quando si implementa il servizio ZPLS all'interno di un account. Per questo motivo, i Clienti dovrebbero capire quale configurazione della sede sia migliore per soddisfare le proprie esigenze pratiche di Business e di survivability, poiché ogni sede aggiuntiva abilitata per la survivability richiederà almeno un modulo ZPLS aggiuntivo.
#### Una progettazione a sede singola è più facile da gestire e fornisce survivability con un solo modulo ZPLS, ma offre meno flessibilità per le Impostazioni e le policy degli utenti
Una progettazione a sede singola aiuta a semplificare la gestione delle Impostazioni e delle policy di Zoom Phone consolidando tutti gli utenti all'interno di un account in un unico gruppo unificato. Questo singolo gruppo di utenti offre alle aziende un'amministrazione semplice e una minore complessità, semplificando il processo di gestione. Inoltre, una progettazione a sede singola può offrire survivability telefonica locale con un solo 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 comporta naturalmente delle limitazioni. In particolare, le progettazioni a sede singola offrono meno flessibilità a causa della loro natura "taglia unica", che potrebbe non adattarsi a tutti gli scenari di implementazione in più reparti con esigenze diverse. Inoltre, le implementazioni a sede singola possono essere vulnerabili in alcuni scenari di sopravvivenza se la [rete locale si guasta](#_gzpf5m70jl3i).
#### Una progettazione multi-sede offre maggiore flessibilità per le Impostazioni e le policy degli utenti, ma richiede un modulo ZPLS per ogni sede con survivability Abilita ed è più complicata da gestire
Una progettazione multi-sede offre alle aziende una flessibilità aggiuntiva nelle Impostazioni e nelle policy degli utenti separando gli utenti in vari gruppi con controlli granulari delle Impostazioni. Questa progettazione consente alle organizzazioni di regolare in modo dettagliato le configurazioni di comunicazione per soddisfare requisiti specifici in sedi diverse, offrendo un'esperienza utente più raffinata e adattabile per vari reparti, scenari o esigenze. Inoltre, le implementazioni multi-sede possono supportare [comunicazioni tra sedi](#_a42hwaw1pfmx) se le sedi sono collegate tramite una rete comune.
Tuttavia, la gestione di una progettazione multi-sede richiede un'attenzione accurata alle complessità dei requisiti unici di ogni sede, il che può richiedere un livello maggiore di impegno amministrativo. Inoltre, poiché ogni modulo ZPLS può essere assegnato a una sola sede alla volta, ogni sede con survivability Abilita 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 verranno configurate per la survivability. Le sedi *senza* un modulo ZPLS rimarranno impossibilitate a effettuare o ricevere chiamate fino al ripristino della connettività Standard.
{% endhint %}
### Guasti di rete
#### La survivability può essere compromessa se la rete locale di una sede si guasta
Sebbene i moduli ZPLS siano progettati per fornire survivability telefonica locale durante Eventi che incidono sul servizio, la survivability può essere compromessa se la rete locale di una sede si guasta. Questi scenari sono descritti nelle due sezioni seguenti.
#### Guasto della rete locale in una sede singola
In una progettazione a sede singola, uno o più edifici sono collegati tramite una rete locale o di 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, un'azienda può fornire survivability locale a tutti gli utenti all'interno di una singola sede o Posizione con anche un solo modulo ZPLS; tuttavia, questa progettazione è vulnerabile in caso di interruzione della rete locale o di campus che influisce sulla comunicazione tra edifici. L'esempio seguente descrive come un guasto della rete locale possa influire su un'implementazione a sede singola.
{% hint style="success" %}
**Esempio:**
Un'azienda sta implementando il modulo ZPLS per una singola sede Zoom Phone, composta dagli edifici A, B e C, collegati tramite una rete di campus. Il modulo ZPLS è in funzione nell'edificio A ed è **non** collegato a un SBC per chiamate esterne attraverso la PSTN.
In caso di guasto del servizio Internet esterno o di Evento che incide sul servizio, qualsiasi utente contenuto nella sede può chiamare un altro utente all'interno della *stessa* sede, purché entrambi gli utenti mantengano la connettività al modulo ZPLS tramite la rete del campus.
Tuttavia, in caso di interruzione della rete del campus, gli utenti negli edifici B e C non possono effettuare chiamate mentre il modulo ZPLS nell'edificio A è irraggiungibile. Di conseguenza, gli utenti negli edifici B e C devono attendere il ripristino della rete del campus per le chiamate di survivability.
{% endhint %}
La tabella seguente dimostra la survivability di Zoom Phone in una progettazione a sede singola con più edifici:
| Chiamate originate dall'edificio | Può raggiungere queste Posizioni durante un guasto di Internet esterno | Può raggiungere queste Posizioni durante un guasto della rete del 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, ogni 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 abbia un modulo ZPLS e che le sedi siano collegate tramite una rete di 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à survivability è attiva. Inoltre, quando più sedi con un modulo ZPLS sono collegate tramite una rete comune, gli utenti possono chiamare utenti di \_other\_sites, purché la rete locale rimanga operativa. Tuttavia, questa progettazione è vulnerabile in caso di interruzione della rete del campus che influisce sulla comunicazione tra edifici. L'esempio seguente descrive come un guasto della rete del campus possa influire su un'implementazione multi-sede.
{% hint style="success" %}
**Esempio:**
Un'azienda sta implementando il modulo ZPLS all'interno del 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 della sede. Tutti gli edifici all'interno del campus sono collegati tramite una rete di campus che non dipende dal servizio Internet esterno per le comunicazioni tra edifici.
In questo esempio, in caso di guasto del servizio Internet esterno, di interruzione della rete del campus o di Evento che incide sul servizio, qualsiasi utente situato all'interno di una sede può chiamare un altro utente situato all'interno della stessa sede. Tuttavia, poiché ogni edificio è una sede univoca e gli utenti si registrano ai moduli specifici della propria sede, se la rete del campus si guasta, i moduli ZPLS non possono instradare le chiamate tra sedi. Al contrario, gli utenti saranno limitati a effettuare chiamate ad altri utenti all'interno della propria sede locale.
{% endhint %}
La tabella seguente dimostra la survivability di Zoom Phone dall'esempio sopra in una progettazione multi-sede con una rete di campus interconnessa:
| Chiamate originate dall'edificio | Può raggiungere queste Posizioni durante un guasto di Internet esterno | Può raggiungere queste Posizioni durante un guasto della rete del campus |
| -------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Edificio A (organizzatore ZPLS) | ☑️ Edifici A, B e C | ☑️ Edificio A |
| Edificio B (organizzatore ZPLS) | ☑️ Edificio A, B e C | ☑️ Edificio B |
| Edificio C (organizzatore ZPLS) | ☑️ Edificio A, B e C | ☑️ Edificio C |
#### Se una rete locale si guasta, le chiamate tra sedi sono supportate anche tramite la PSTN, a condizione che ogni sede sia collegata a un SBC e abbia l'inoltro di chiamata Abilita
In caso di guasto della rete locale, i Clienti con una progettazione multi-sede che integra il modulo ZPLS con un SBC e la connettività PSTN in ogni sede possono Abilitare le chiamate da sede a sede se [l'inoltro di chiamata è Abilita](#_2v7qst7vxwaa). Una volta configurate, le chiamate telefoniche effettuate durante la modalità survivability verranno instradate dal client dell'utente alla PSTN, al SBC e al modulo ZPLS della seconda sede, arrivando infine al dispositivo del chiamato. Il diagramma seguente fornisce una panoramica di questa configurazione:
{% hint style="danger" %}
Questa configurazione **richiede** l'elaborazione del numero di telefono E.164 sugli SBC configurati.
{% endhint %}
La tabella seguente dimostra inoltre la survivability di Zoom Phone in una progettazione multi-sede con SBC indipendenti:
| Chiamate originate dall'edificio | Può raggiungere queste Posizioni durante un guasto di Internet esterno | Può raggiungere queste Posizioni durante un guasto della rete del 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 dispositivi vengono Aggiunti a Zoom Phone, una sede "principale" viene associata in modo statico all'utente o al dispositivo fino a quando non viene aggiornata diversamente 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, come un edificio per uffici associato a una sede diversa, Zoom non adatterà dinamicamente la sede associata all'utente. Di conseguenza, se l'utente perde la connettività ai 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 ha come base l'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 incide sul servizio e viene attivata la modalità survivability. 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 predisposto nella sua sede principale all'interno dell'Edificio A.
In questo scenario, lo stato di survivability di un utente è determinato dalla capacità del dispositivo dell'utente di registrarsi al modulo ZPLS all'interno della propria sede principale attraverso la rete del campus. Se la rete del campus è inattiva mentre l'utente è lontano dalla propria sede principale, l'utente non può beneficiare del modulo di survivability.
{% 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.