# Considerazioni sul deployment dell’hardware

Questa pagina descrive il deployment del modulo Zoom Node ZPLS 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

#### <mark style="color:blu;">I clienti devono installare il software Zoom Node su una macchina virtuale in esecuzione su un hypervisor supportato</mark>

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).

#### <mark style="color:blu;">I clienti possono scegliere una delle due opzioni di configurazione, a seconda delle capacità hardware</mark>

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**          | <p>8 CPU</p><p>16 GB di RAM</p><p>80 GB HDD</p> | <p>16 CPU</p><p>16 GB di RAM</p><p>80 GB HDD</p> |
| **Registrazioni totali**         | 2000                                            | 5000                                             |
| **Chiamate concorrenti massime** | 240                                             | 480                                              |
| **Chiamate al secondo**          | 2                                               | 4                                                |
| **Registrazioni al secondo**     | 60                                              | 400                                              |

{% hint style="info" %}
Se il numero di endpoint all'interno di un sito con survivability abilitata supera le capacità di deployment del sito, il modulo ZPLS elaborerà le registrazioni in ordine di arrivo. Si consiglia ai clienti di aggiungere moduli aggiuntivi o di utilizzare l'impostazione di policy di Zoom Phone [**Modalità di survivability locale**](#_ah8xua8wdq10) per dare priorità agli utenti che supportano il failover di survivability.
{% endhint %}

### Scaling e resilienza del modulo

#### <mark style="color:blu;">I moduli ZPLS supportano il clustering per aumentare lo scaling e/o la resilienza</mark>

I clienti possono raggruppare moduli ZPLS fino a 20 moduli per sito (o 100 dispositivi Node totali per account) per una ridondanza o uno scaling aggiuntivi.

{% hint style="info" %}
Questa funzionalità è attualmente in beta e richiede l'apertura di un ticket di supporto tecnico per essere abilitata.
{% endhint %}

#### <mark style="color:blu;">Lo scaling aumenta le capacità di dispositivi supportate da un sito</mark>

L'aumento del numero di moduli ZPLS incrementa linearmente le capacità di ciascun sito per ogni modulo aggiuntivo. Ad esempio, se un modulo supporta un totale di 5.000 registrazioni, il deployment di cinque moduli porterà il supporto a 25.000 registrazioni.

#### <mark style="color:blu;">La ridondanza aggiunge moduli per la resilienza, ma non scala le capacità di dispositivi di un sito</mark>

Quando un modulo ZPLS è utilizzato per scopi di ridondanza, i moduli ridondanti non contribuiscono al numero totale di estensioni supportate. Invece, 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 viene sovraccaricato con dispositivi oltre il suo limite supportato.

#### <mark style="color:blu;">Esempio di deployment di ZPLS con scaling e ridondanza</mark>

Per comodità, il seguente esempio dimostra un deployment con scaling e ridondanza aggiuntivi.

{% hint style="success" %}
**Esempio**:&#x20;

Un ospedale deve supportare fino a 10.000 estensioni registrate per la survivability. Per raggiungere questo obiettivo, l'ospedale sta deployando quattro moduli ZPLS.

I primi due moduli sono in grado di supportare ciascuno 5.000 registrazioni, risultando in una capacità totale fino a 10.000 registrazioni. Tuttavia, riconoscendo l'importanza della resilienza, l'ospedale sta anche deployando due moduli aggiuntivi come backup ridondanti ai moduli primari.

In questo scenario, l'ospedale ha ora hardware di survivability primario e secondario deployato. Pertanto, se un modulo primario dovesse subire un guasto, il(i) modulo(i) ridondante(i) subentrerà(anno) per mantenere il servizio ininterrotto, continuando a supportare fino a 10.000 dispositivi registrati.
{% endhint %}

### Considerazioni sul design del sito

#### <mark style="color:blu;">I siti raggruppano gli utenti di Zoom Phone per posizione per impostazioni e policy telefoniche comuni</mark>

Un **sito** è un termine specifico usato in Zoom Phone che raggruppa utenti con caratteristiche condivise — come un codice di accesso comune, indirizzo, zona SIP, reparto o policy — in un unico gruppo gestibile nel portale web di Zoom. Per alcuni clienti, un singolo sito può rappresentare tutti gli utenti della loro azienda e può estendersi a più edifici all'interno di un campus o di una sede; per altri, possono essere necessari più siti a seconda delle esigenze aziendali. Per ulteriori informazioni sui siti o sulla gestione dei siti, [fare riferimento al centro assistenza di Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:blu;">Zoom Phone supporta design a sito singolo e a siti multipli</mark>

Esistono due design principali per la configurazione dei siti Zoom Phone all'interno di un account:

1. **Sito singolo**: Rappresenta tutti gli utenti all'interno di un account, potenzialmente estendendosi a più edifici o sedi, all'interno di un singolo sito Zoom Phone.
2. **Siti multipli**: Rappresentano segmenti di utenti per posizione, edificio, reparto o funzione separatamente, ciascuno con il proprio sito.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/oIvxHDcxrmw7DhWRyObf/Unknown%20image" alt=""></div>

{% hint style="info" %}
Gli amministratori di account dei clienti attuali di Zoom possono verificare il loro design dei siti corrente tramite la [**Informazioni 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 nel portale web.
{% endhint %}

#### <mark style="color:blu;">Ogni modulo ZPLS può essere associato a un solo sito alla volta</mark>

Come menzionato in precedenza, un modulo ZPLS è il [registrar di terza priorità](#_7itj40mx1dut) per i dispositivi supportati, dietro le zone SIP primarie e secondarie. Poiché i dispositivi ricevono le loro liste SRV durante il processo di avvio, e queste liste sono legate alle impostazioni del loro sito, **ogni modulo ZPLS può essere associato a un solo sito alla volta**.

#### <mark style="color:blu;">Ogni sito può supportare fino a 20 moduli ZPLS contemporaneamente</mark>

Sebbene ogni modulo ZPLS possa essere associato a un solo sito alla volta, un sito può supportare fino a 20 moduli ZPLS in un gruppo, espandendo le capacità di survivability di ciascun sito.

{% hint style="info" %}
Questa funzionalità è attualmente in beta e richiede l'apertura di un ticket di supporto tecnico per essere abilitata.
{% endhint %}

#### <mark style="color:blu;">I moduli ZPLS supportano le chiamate cross-site se i moduli sono connessi a una rete comune</mark>

I moduli ZPLS di siti diversi supportano le chiamate cross-site durante un evento di survivability purché i dispositivi siano rilevabili nella rete locale. Ad esempio, se un campus aziendale ha tre edifici, ciascuno con il proprio sito telefonico, i moduli ZPLS di ciascun sito possono connettere chiamate sito-a-sito attraverso la rete del campus.

{% hint style="info" %}
Questa funzionalità è attualmente in beta e richiede l'apertura di un ticket di supporto tecnico per essere abilitata.
{% endhint %}

#### <mark style="color:blu;">Prima di deployare ZPLS, gli account dovrebbero comprendere quale configurazione di sito sia più adatta alle loro esigenze</mark>

Poiché ogni modulo ZPLS può essere associato a un solo sito alla volta, il design del sito è uno dei fattori più importanti quando si deploya il servizio ZPLS all'interno di un account. Per questo motivo, i clienti dovrebbero comprendere quale configurazione del sito è migliore per soddisfare le loro esigenze pratiche aziendali e di survivability, poiché ogni sito aggiuntivo abilitato per la survivability richiederà almeno un modulo ZPLS aggiuntivo.

#### <mark style="color:blu;">Un design a sito singolo è più semplice da gestire e fornisce survivability con un singolo modulo ZPLS, ma offre meno flessibilità per impostazioni e policy utente</mark>

Un design a sito singolo 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 più diretta e una complessità ridotta, semplificando il processo di gestione. Inoltre, un design a sito singolo può offrire survivability telefonica locale con un singolo modulo ZPLS, purché gli utenti del sito non superino le [capacità di un singolo modulo](#_rx0i1j9xofnc).

Tuttavia, la semplicità di un design a sito singolo include naturalmente delle limitazioni. In particolare, i design a sito singolo offrono meno flessibilità a causa della loro natura “taglia unica”, che potrebbe non adattarsi a tutti gli scenari di deployment attraverso reparti multipli con esigenze diverse. Inoltre, i deployment a sito singolo possono essere vulnerabili in determinati scenari di sopravvivenza se la [rete locale si guasta](#_gzpf5m70jl3i).

#### <mark style="color:blu;">Un design a siti multipli offre più flessibilità per impostazioni e policy utente, ma richiede un modulo ZPLS per ogni sito abilitato alla survivability ed è più complicato da gestire</mark>

Un design a siti multipli offre alle aziende una flessibilità aggiuntiva nelle impostazioni e nelle policy utente separando gli utenti in vari gruppi con controlli di impostazione granulari. Questo design consente alle organizzazioni di regolare in modo dettagliato le configurazioni di comunicazione per soddisfare requisiti specifici in siti diversi, risultando in un'esperienza utente più raffinata e adattabile per vari reparti, scenari o necessità. Inoltre, i deployment multi-sito possono supportare [comunicazione cross-site](#_a42hwaw1pfmx) se i siti sono connessi tramite una rete comune.

Tuttavia, la gestione di un design multi-sito richiede un'attenzione accurata alle peculiarità dei requisiti unici di ciascun sito, il che può richiedere un livello più elevato di impegno amministrativo. Inoltre, poiché ogni modulo ZPLS può essere assegnato a un solo sito alla volta, ogni sito abilitato per la survivability richiederà un modulo ZPLS e una licenza, il che può contribuire a un setup più dispendioso in termini di risorse.

{% hint style="info" %}
In un design multi-sito, i clienti hanno la flessibilità di scegliere quali siti verranno configurati per la survivability. I siti *senza* un modulo ZPLS rimarrà incapace di effettuare o ricevere chiamate fino al ripristino della connettività standard.
{% endhint %}

### Guasti di rete

#### <mark style="color:blu;">La survivability può essere compromessa se la rete locale di un sito si guasta</mark>

Sebbene i moduli ZPLS siano progettati per fornire survivability telefonica locale durante eventi che impattano il servizio, la survivability può essere compromessa se la rete locale di un sito si guasta. Questi scenari sono delineati nelle due sezioni seguenti.

#### <mark style="color:blu;">Guasto della rete locale in sito singolo</mark>

In un design a sito singolo, uno o più edifici sono connessi tramite una rete locale o di campus e sono rappresentati da un unico sito all'interno di Zoom Phone. Questa configurazione presuppone una rete comune tra tutti gli utenti e gli edifici all'interno di una sede, senza dipendenze da reti esterne (ad es. Internet) per la comunicazione tra edifici.

Con questo design del sito, un'azienda può fornire survivability locale a tutti gli utenti all'interno di un singolo sito o sede con appena un modulo ZPLS; tuttavia, questo design è vulnerabile in caso di un'interruzione della rete locale o del campus che influenzi la comunicazione tra edifici. Il seguente esempio descrive come un guasto della rete locale possa influire su un deployment a sito singolo.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/Ri12tqNIQd9vtbMpNzqe/Unknown%20image" alt=""></div>

{% hint style="success" %}
**Esempio:**

Un'azienda sta deployando il modulo ZPLS per un singolo sito Zoom Phone, composto dagli edifici A, B e C, che sono connessi tramite una rete di campus. Il modulo ZPLS è operativo nell'edificio A e **non** è connesso a un SBC per le chiamate esterne attraverso la PSTN.

In caso di guasto del servizio Internet esterno o di un evento che impatta il servizio, qualsiasi utente contenuto all'interno del sito può chiamare un altro utente all'interno dello *stesso* sito, purché entrambi gli utenti mantengano la connettività al modulo ZPLS tramite la rete del campus.

Tuttavia, in caso di un'interruzione della rete di campus, gli utenti all'interno degli 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 in modalità survivability.
{% endhint %}

La tabella seguente dimostra la survivability di Zoom Phone in un design a sito singolo multi-edificio:

| Chiamate originanti dall'edificio | Possono raggiungere queste sedi durante un guasto di Internet esterno | Possono raggiungere queste sedi durante un guasto della rete del campus |
| --------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| Edificio A (Host ZPLS)            | ☑️ Edifici A, B e C                                                   | ☑️ Solo edificio A *solo*                                               |
| Edificio B                        | ☑️ Edifici A, B e C                                                   | ✖️                                                                      |
| Edificio C                        | ☑️ Edifici A, B e C                                                   | ✖️                                                                      |

#### <mark style="color:blu;">Guasto della rete locale multi-sito senza un SBC</mark>

In un design multi-sito, ogni edificio o sede (ad es. piano, ufficio satellite, ecc.) è rappresentato in modo indipendente da un sito unico all'interno di Zoom Phone. Questa configurazione presuppone che ogni sito abbia un modulo ZPLS e che i siti siano connessi tramite una rete di campus comune.

Con questo design del sito, ogni sito supporta il proprio modulo ZPLS, consentendo agli utenti all'interno dello stesso edificio di chiamarsi quando la modalità di survivability è attivata. Inoltre, quando più siti con un modulo ZPLS sono connessi tramite una rete comune, gli utenti possono chiamare utenti in \_altri\_siti, purché la rete locale rimanga operativa. Tuttavia, questo design è vulnerabile in caso di un'interruzione della rete di campus che influenzi la comunicazione tra edifici. Il seguente esempio descrive come un guasto della rete di campus possa influire su un deployment multi-sito.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/YleKIF0uXoN12c2dmNNB/Unknown%20image" alt=""></div>

{% hint style="success" %}
**Esempio:**

Un'azienda sta deployando il modulo ZPLS all'interno del suo campus multi-edificio, composto dagli edifici A, B e C. Ogni edificio è un sito unico all'interno di Zoom Phone e mantiene un modulo ZPLS specifico per il sito. Tutti gli edifici del campus sono connessi 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, interruzione della rete del campus o evento che impatta il servizio, qualsiasi utente situato all'interno di un sito può chiamare un altro utente situato nello stesso sito. Tuttavia, poiché ogni edificio è un sito unico e gli utenti si registrano ai moduli specifici del loro sito, se la rete del campus si guasta, i moduli ZPLS non possono trasportare chiamate cross-site. Di conseguenza, gli utenti saranno limitati a effettuare chiamate verso altri utenti all'interno del loro sito locale.
{% endhint %}

La tabella seguente dimostra la survivability di Zoom Phone dall'esempio sopra in un design multi-sito con una rete di campus interconnessa:

| Chiamate originanti dall'edificio | Possono raggiungere queste sedi durante un guasto di Internet esterno | Possono raggiungere queste sedi durante un guasto della rete del campus |
| --------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| Edificio A (Host ZPLS)            | ☑️ Edifici A, B e C                                                   | ☑️ Solo edificio A                                                      |
| Edificio B (Host ZPLS)            | ☑️ Edificio A, B e C                                                  | ☑️ Solo edificio B                                                      |
| Edificio C (Host ZPLS)            | ☑️ Edificio A, B e C                                                  | ☑️ Solo edificio C                                                      |

#### <mark style="color:blu;">Se una rete locale si guasta, le chiamate cross-site sono supportate anche tramite la PSTN, purché ogni sito sia connesso a un SBC e abbia l'inoltro di chiamata abilitato</mark>

In caso di guasto della rete locale, i clienti con un design multi-sito che integrano il modulo ZPLS con un SBC e connettività PSTN in ogni sito possono abilitare le chiamate sito-a-sito se [l'inoltro di chiamata è abilitato](#_2v7qst7vxwaa). Quando configurato, le chiamate telefoniche effettuate durante la modalità di survivability verranno instradate dal client dell'utente alla PSTN, allo SBC del secondo sito e al modulo ZPLS, arrivando infine al dispositivo del chiamato. Il diagramma seguente fornisce una panoramica di questa configurazione:

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/TxOX1dZyselC2SFLiXSu/Unknown%20image" alt=""></div>

{% hint style="danger" %}
Questa configurazione **richiede** l'elaborazione dei numeri telefonici E.164 sugli SBC configurati.
{% endhint %}

La tabella seguente dimostra inoltre la survivability di Zoom Phone in un design multi-sito con SBC indipendenti:

| Chiamate originanti dall'edificio | Possono raggiungere queste sedi durante un guasto di Internet esterno | Possono raggiungere queste sedi durante un guasto della rete del campus |
| --------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| Edificio A (Host ZPLS)            | ☑️ Edifici A, B e C                                                   | ☑️ Edifici A, B e C                                                     |
| Edificio B (Host ZPLS)            | ☑️ Edifici A, B e C                                                   | ☑️ Edifici A, B e C                                                     |
| Edificio C (Host ZPLS)            | ☑️ Edifici A, B e C                                                   | ☑️ Edifici A, B e C                                                     |

#### <mark style="color:blu;">Gli utenti nomadi si registrano sempre al modulo ZPLS associato al loro sito di origine</mark>

Quando utenti o dispositivi vengono aggiunti a Zoom Phone, un sito “di origine” è staticamente associato all'utente o al dispositivo fino a quando non viene aggiornato da un amministratore dell'account. Ciò significa che se un utente si sposta in una posizione fisica al di fuori del suo sito di origine associato, come un edificio d'ufficio associato a un sito diverso, Zoom non regolerà dinamicamente il sito associato all'utente. Di conseguenza, se l'utente perde la connettività ai data center di Zoom, tenterà di registrarsi al modulo ZPLS associato al suo sito di origine, anche se si trova in una posizione diversa.

{% hint style="success" %}
**Esempio:**

Un utente in un campus multi-sito ha base nell'edificio A (Sito A) e si sposta temporaneamente nell'edificio B (Sito B) per una riunione. Mentre si trova nell'edificio B, si verifica un evento che impatta il servizio e la modalità di survivability viene attivata. Sebbene l'utente si trovi nell'edificio B, poiché il Sito A è il suo sito di origine, il client dell'utente tenterà di connettersi al modulo ZPLS provisionato nel suo sito di origine nell'edificio A.

In questo scenario, lo stato di survivability di un utente è determinato dalla capacità del dispositivo utente di registrarsi al modulo ZPLS all'interno del loro sito di origine attraverso la rete del campus. Se la rete del campus è inattiva mentre l'utente è lontano dal suo sito di origine, l'utente non può beneficiare del modulo di survivability.
{% endhint %}