# Overwegingen voor Hardware-implementatie

Deze pagina beschrijft de implementatie van de Zoom Node ZPLS-module op een virtuele machine met behulp van ondersteunde hypervisors. Er worden gedetailleerde configuratieopties geboden die zijn afgestemd op verschillende Hardware-mogelijkheden, om optimale prestaties voor uiteenlopende operationele behoeften te garanderen.

### Ondersteunde hypervisors

#### <mark style="color:blauw;">Klanten moeten de Zoom Node-software installeren op een virtuele machine die draait op een ondersteunde hypervisor</mark>

Als Zoom Node-workload moet de ZPLS-module worden geïnstalleerd op een virtuele machine die draait op het Zoom Node Platform, op een [ondersteunde hypervisor](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Meer informatie over Zoom Node als product is te vinden [in de bijlage](#_a2lvsihjp0ek).

#### <mark style="color:blauw;">Klanten kunnen een van twee configuratieopties Kies, afhankelijk van de Hardware-mogelijkheden</mark>

De ZPLS-module ondersteunt twee configuraties, afhankelijk van de Hardware-mogelijkheden van de virtuele machine. Deze mogelijkheden worden hieronder vermeld:

|                                              | Configuratieoptie 1                          | Configuratieoptie 2                           |
| -------------------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Hardwarespecificaties**                    | <p>8 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> | <p>16 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> |
| **Totaal aantal registraties**               | 2000                                         | 5000                                          |
| **Maximaal aantal gelijktijdige gesprekken** | 240                                          | 480                                           |
| **Gesprekken per seconde**                   | 2                                            | 4                                             |
| **Registraties per seconde**                 | 60                                           | 400                                           |

{% hint style="info" %}
Als het aantal endpoints binnen een voor survivability ingeschakelde locatie de implementatiemogelijkheden van een locatie overschrijdt, verwerkt de ZPLS-module registraties op basis van wie het eerst komt, het eerst maalt. Klanten wordt geadviseerd extra modules Toevoegen, of de instelling van Zoom Phone Policy te gebruiken [**Lokale overlevingsmodus**](#_ah8xua8wdq10) om prioriteit te geven aan welke gebruikers failover voor survivability ondersteunen.
{% endhint %}

### Moduleschaling en veerkracht

#### <mark style="color:blauw;">ZPLS-modules ondersteunen clustering voor extra schaalbaarheid en/of veerkracht</mark>

Klanten kunnen ZPLS-modules groeperen met maximaal 20 modules per locatie (of 100 totale Node-apparaten per account) voor extra redundantie of schaalbaarheid.

{% hint style="info" %}
Deze Functie(s) is momenteel in bèta en vereist dat een technisch ondersteuningsticket wordt ingeschakeld.
{% endhint %}

#### <mark style="color:blauw;">Schaling vergroot de ondersteunde Apparaat-mogelijkheden van een locatie</mark>

Door het aantal ZPLS-modules uit te breiden, worden de mogelijkheden van elke locatie lineair vergroot voor elke extra module. Als bijvoorbeeld één module in totaal 5.000 registraties ondersteunt, verhoogt de implementatie van vijf modules de ondersteuning tot 25.000 registraties.

#### <mark style="color:blauw;">Redundantie voegt extra modules toe voor veerkracht, maar schaalt de Apparaat-mogelijkheden van een locatie niet</mark>

Wanneer een ZPLS-module wordt gebruikt voor redundantiedoeleinden, dragen de redundante modules niet bij aan het totale aantal ondersteunde extensies. In plaats daarvan staan de modules in 'hot standby' en worden ze alleen actief als primaire modules uitvallen. Zo ondersteunen één primaire en één redundante module in totaal 5.000 registraties, zodat de redundante module niet overbelast raakt met apparaten boven de ondersteunde limiet als een primaire module uitvalt.

#### <mark style="color:blauw;">Voorbeeld van het implementeren van ZPLS met schaling en redundantie</mark>

Voor het gemak laat het volgende voorbeeld een implementatie met extra schaling en redundantie zien.

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

Een ziekenhuis moet ondersteuning bieden voor maximaal 10.000 geregistreerde extensies voor survivability. Om dit te bereiken, implementeert het ziekenhuis vier ZPLS-modules.

De eerste twee modules kunnen elk 5.000 registraties ondersteunen, wat resulteert in een totale Capaciteit van maximaal 10.000 registraties. Het ziekenhuis erkent echter het belang van veerkracht en implementeert daarom ook twee extra modules als redundante back-ups voor de primaire modules.

In dit scenario heeft het ziekenhuis nu primaire en secundaire survivability-Hardware geïmplementeerd. Als een primaire module nu een storing ondervindt, zullen de redundante module(s) het Overnemen om ononderbroken service te behouden, terwijl ondersteuning voor maximaal 10.000 geregistreerde apparaten behouden blijft.
{% endhint %}

### Overwegingen voor locatieontwerp

#### <mark style="color:blauw;">Locaties groeperen Zoom Phone-gebruikers per Locatie voor gemeenschappelijke telefonie-Instellingen en beleidsregels</mark>

Een **locatie** is een specifieke term die binnen Zoom Phone wordt gebruikt om gebruikers met gedeelde kenmerken — zoals een gemeenschappelijke toegangscode, adres, SIP-zone, afdeling of beleidsregels — te groeperen in één beheersbare groep binnen het Zoom-webportal. Voor sommige Klanten kan één enkele locatie alle gebruikers binnen hun bedrijf vertegenwoordigen en meerdere gebouwen binnen een campus of Locatie omvatten; voor anderen kunnen Meerdere sites nodig zijn, afhankelijk van uw zakelijke behoeften. Voor meer informatie over locaties of locatiebeheer, [raadpleeg het ondersteuningscentrum van Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:blauw;">Zoom Phone ondersteunt ontwerpen met één locatie en meerdere locaties</mark>

Er zijn twee primaire ontwerpen voor het configureren van Zoom Phone-locaties binnen een account:

1. **Eén locatie**: Vertegenwoordigt alle gebruikers binnen een account, mogelijk verspreid over meerdere gebouwen of locaties, binnen één enkele Zoom Phone-locatie.
2. **Meerdere locaties**: Vertegenwoordigt segmenten van gebruikers afzonderlijk per Locatie, gebouw, afdeling of functie, elk met een eigen locatie.

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

{% hint style="info" %}
Accountbeheerders van huidige Zoom-klanten kunnen hun huidige locatieontwerp controleren via de [**Bedrijfsinformatie**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) pagina, Beschikbaar in het **Telefoonsysteembeheer** menu in het webportal.
{% endhint %}

#### <mark style="color:blauw;">Elke ZPLS-module kan slechts met één locatie tegelijk worden gekoppeld</mark>

Zoals eerder vermeld, is een ZPLS-module de [registrar met derde prioriteit](#_7itj40mx1dut) voor ondersteunde apparaten, na primaire en secundaire SIP-zones. Omdat apparaten hun SRV-lijsten ontvangen tijdens het opstartproces, en deze lijsten zijn gekoppeld aan de instelling van hun locatie, **kan elke ZPLS-module slechts met één locatie tegelijk worden gekoppeld**.

#### <mark style="color:blauw;">Elke locatie kan maximaal 20 ZPLS-modules gelijktijdig ondersteunen</mark>

Hoewel elke ZPLS-module slechts met één locatie tegelijk kan worden gekoppeld, kan een locatie maximaal 20 ZPLS-modules in één groep ondersteunen, waardoor de survivability-mogelijkheden van elke locatie worden uitgebreid.

{% hint style="info" %}
Deze Functie(s) is momenteel in bèta en vereist dat een technisch ondersteuningsticket wordt ingeschakeld.
{% endhint %}

#### <mark style="color:blauw;">ZPLS-modules ondersteunen bellen tussen locaties als de modules zijn verbonden met een gemeenschappelijk netwerk</mark>

ZPLS-modules van verschillende locaties ondersteunen tijdens een survivability-Evenement bellen tussen locaties, zolang de apparaten binnen het lokale netwerk vindbaar zijn. Als een bedrijfscampus bijvoorbeeld drie gebouwen heeft, elk met een eigen telefoonlocatie, kunnen de ZPLS-modules van elke locatie gesprekken van locatie naar locatie verbinden via het campusnetwerk.

{% hint style="info" %}
Deze Functie(s) is momenteel in bèta en vereist dat een technisch ondersteuningsticket wordt ingeschakeld.
{% endhint %}

#### <mark style="color:blauw;">Voordat ZPLS wordt geïmplementeerd, moeten accounts begrijpen welke locatieconfiguratie het best geschikt is voor hun behoeften</mark>

Omdat elke ZPLS-module slechts met één locatie tegelijk kan worden gekoppeld, is locatieontwerp een van de belangrijkste factoren bij het implementeren van de ZPLS-service binnen een account. Daarom moeten Klanten begrijpen welke locatieconfiguratie het beste voldoet aan hun praktische zakelijke behoeften en survivability-behoeften, aangezien voor elke extra locatie die voor survivability wordt ingeschakeld ten minste één extra ZPLS-module vereist is.

#### <mark style="color:blauw;">Een ontwerp met één locatie is eenvoudiger te beheren en biedt survivability met één enkele ZPLS-module, maar biedt minder flexibiliteit voor gebruikersinstellingen en beleidsregels</mark>

Een ontwerp met één locatie helpt het beheer van Zoom Phone-Instellingen en beleidsregels te stroomlijnen door alle gebruikers binnen een account samen te brengen in één enkele, uniforme groep. Deze ene gebruikersgroep biedt bedrijven eenvoudig beheer en minder complexiteit, waardoor het beheerproces wordt vereenvoudigd. Daarnaast kan een ontwerp met één locatie lokale telefonische survivability bieden met één enkele ZPLS-module, zolang de gebruikers van de locatie de [mogelijkheden van een enkele module](#_rx0i1j9xofnc).

De eenvoud van een ontwerp met één locatie brengt echter van nature beperkingen met zich mee. Concreet bieden ontwerpen met één locatie minder flexibiliteit vanwege hun 'one size fits all'-karakter, wat mogelijk niet geschikt is voor alle implementatiescenario's in meerdere afdelingen met uiteenlopende behoeften. Bovendien kunnen implementaties met één locatie kwetsbaar zijn in bepaalde survivability-scenario's als het [lokale netwerk uitvalt](#_gzpf5m70jl3i).

#### <mark style="color:blauw;">Een ontwerp met meerdere locaties biedt meer flexibiliteit voor gebruikersinstellingen en beleidsregels, maar vereist één ZPLS-module voor elke voor survivability ingeschakelde locatie en is complexer te beheren</mark>

Een ontwerp met meerdere locaties biedt bedrijven extra flexibiliteit in gebruikersinstellingen en beleidsregels door gebruikers in verschillende groepen te scheiden met gedetailleerde instellingscontroles. Dit ontwerp stelt organisaties in staat communicatieconfiguraties nauwkeurig aan te passen aan specifieke vereisten op diverse locaties, wat resulteert in een verfijndere en beter aanpasbare gebruikerservaring voor verschillende afdelingen, scenario's of behoeften. Bovendien kunnen implementaties met meerdere locaties [communicatie tussen locaties](#_a42hwaw1pfmx) ondersteunen als de locaties via een gemeenschappelijk netwerk zijn verbonden.

Het beheren van een ontwerp met meerdere locaties vereist echter zorgvuldige aandacht voor de complexiteit van de unieke vereisten van elke locatie, wat mogelijk een hoger niveau van beheersinspanning vraagt. Verder geldt dat, omdat elke ZPLS-module slechts aan één locatie tegelijk kan worden toegewezen, elke voor survivability ingeschakelde locatie één ZPLS-module en licentie vereist, wat kan bijdragen aan een meer resource-intensieve configuratie.

{% hint style="info" %}
In een ontwerp met meerdere locaties hebben Klanten de flexibiliteit om te Kies welke locaties voor survivability worden geconfigureerd. Locaties *zonder* een ZPLS-module zullen geen gesprekken kunnen voeren of ontvangen totdat de standaardconnectiviteit is hersteld.
{% endhint %}

### Netwerkstoringen

#### <mark style="color:blauw;">Survivability kan worden beïnvloed als het lokale netwerk van een locatie uitvalt</mark>

Hoewel ZPLS-modules zijn ontworpen om lokale telefonische survivability te bieden tijdens serviceverstorende gebeurtenissen, kan survivability worden beïnvloed als het lokale netwerk van een locatie uitvalt. Deze scenario's worden in de volgende twee secties beschreven.

#### <mark style="color:blauw;">Uitval van lokaal netwerk bij één locatie</mark>

In een ontwerp met één locatie zijn een of meer gebouwen via een lokaal netwerk of campusnetwerk verbonden en worden zij vertegenwoordigd door één enkele locatie binnen Zoom Phone. Deze configuratie gaat uit van een gemeenschappelijk netwerk tussen alle gebruikers en gebouwen binnen een Locatie, zonder externe netwerkafhankelijkheden (bijv. internet) voor communicatie tussen gebouwen.

Met dit locatieontwerp kan een bedrijf lokale survivability bieden aan alle gebruikers binnen één locatie of Locatie met slechts één ZPLS-module; dit ontwerp is echter kwetsbaar in het geval van een storing in een lokaal netwerk of campusnetwerk die communicatie tussen gebouwen beïnvloedt. Het volgende voorbeeld beschrijft hoe een lokale netwerkstoring gevolgen kan hebben voor een implementatie met één locatie.

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

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

Een bedrijf implementeert de ZPLS-module voor één enkele Zoom Phone-locatie, bestaande uit gebouwen A, B en C, die via een campusnetwerk met elkaar zijn verbonden. De ZPLS-module werkt in gebouw A en is **niet** verbonden met een SBC voor extern bellen via het PSTN.

In het geval van een storing van de externe internetdienst of een serviceverstorende gebeurtenis, kan elke gebruiker binnen de locatie een andere gebruiker binnen dezelfde *zelfde* locatie bellen, zolang beide gebruikers via het campusnetwerk verbinding met de ZPLS-module behouden.

In het geval van een storing in het campusnetwerk kunnen gebruikers in gebouwen B en C echter geen gesprekken voeren terwijl de ZPLS-module in gebouw A onbereikbaar is. Daardoor moeten gebruikers in gebouwen B en C wachten tot het campusnetwerk is hersteld voordat survivability-bellen mogelijk is.
{% endhint %}

De volgende tabel toont de survivability van Zoom Phone in een ontwerp met één locatie en meerdere gebouwen:

| Gesprekken afkomstig uit gebouw | Kan deze locaties bereiken tijdens een storing van extern internet | Kan deze locaties bereiken tijdens een storing in het campusnetwerk |
| ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------- |
| Gebouw A (ZPLS-host)            | ☑️Gebouwen A, B en C                                               | ☑️ Gebouw A *alleen*                                                |
| Gebouw B                        | ☑️Gebouwen A, B en C                                               | ✖️                                                                  |
| Gebouw C                        | ☑️Gebouwen A, B en C                                               | ✖️                                                                  |

#### <mark style="color:blauw;">Uitval van lokaal netwerk bij meerdere locaties zonder een SBC</mark>

In een ontwerp met meerdere locaties wordt elk gebouw of elke Locatie (bijv. verdieping, satellietkantoor enz.) onafhankelijk vertegenwoordigd door een unieke locatie binnen Zoom Phone. Deze configuratie gaat ervan uit dat elke locatie een ZPLS-module heeft en dat de locaties via een gemeenschappelijk campusnetwerk met elkaar zijn verbonden.

Met dit locatieontwerp ondersteunt elke locatie zijn eigen ZPLS-module, waardoor gebruikers binnen hetzelfde gebouw elkaar kunnen bellen wanneer de survivability-modus is ingeschakeld. Verder kunnen, wanneer meerdere locaties met een ZPLS-module via een gemeenschappelijk netwerk zijn verbonden, gebruikers andere locaties bellen, zolang het lokale netwerk operationeel blijft. Dit ontwerp is echter kwetsbaar in het geval van een storing in het campusnetwerk die communicatie tussen gebouwen beïnvloedt. Het volgende voorbeeld beschrijft hoe een storing in het campusnetwerk gevolgen kan hebben voor een implementatie met meerdere locaties.

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

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

Een bedrijf implementeert de ZPLS-module binnen zijn campus met meerdere gebouwen, bestaande uit gebouwen A, B en C. Elk gebouw is een unieke locatie binnen Zoom Phone en heeft een locatiespecifieke ZPLS-module. Alle gebouwen binnen de campus zijn verbonden via een campusnetwerk dat voor communicatie tussen gebouwen niet afhankelijk is van externe internetdienst.

In dit voorbeeld kan, in het geval van een storing van de externe internetdienst, een storing in het campusnetwerk of een serviceverstorende gebeurtenis, elke gebruiker binnen een locatie een andere gebruiker binnen dezelfde locatie bellen. Omdat elk gebouw echter een unieke locatie is en gebruikers zich registreren bij hun locatiespecifieke modules, kunnen de ZPLS-modules geen gesprekken tussen locaties transporteren als het campusnetwerk uitvalt. In plaats daarvan zijn gebruikers beperkt tot het voeren van gesprekken met andere gebruikers binnen hun lokale locatie.
{% endhint %}

De volgende tabel toont de survivability van Zoom Phone uit het bovenstaande voorbeeld in een ontwerp met meerdere locaties met een onderling verbonden campusnetwerk:

| Gesprekken afkomstig uit gebouw | Kan deze locaties bereiken tijdens een storing van extern internet | Kan deze locaties bereiken tijdens een storing in het campusnetwerk |
| ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------- |
| Gebouw A (ZPLS-host)            | ☑️ Gebouwen A, B en C                                              | ☑️ Gebouw A                                                         |
| Gebouw B (ZPLS-host)            | ☑️ Gebouw A, B en C                                                | ☑️ Gebouw B                                                         |
| Gebouw C (ZPLS-host)            | ☑️ Gebouw A, B en C                                                | ☑️ Gebouw C                                                         |

#### <mark style="color:blauw;">Als een lokaal netwerk uitvalt, wordt bellen tussen locaties ook ondersteund via het PSTN, mits elke locatie is verbonden met een SBC en doorschakelen is ingeschakeld</mark>

In het geval van een lokaal netwerkstoring kunnen Klanten met een ontwerp met meerdere locaties dat de ZPLS-module integreert met een SBC en PSTN-connectiviteit op elke locatie bellen van locatie naar locatie inschakelen als [doorschakelen is ingeschakeld](#_2v7qst7vxwaa). Wanneer dit is geconfigureerd, worden telefoongesprekken die tijdens de survivability-modus worden gevoerd gerouteerd van de client van de gebruiker naar het PSTN, naar de SBC en ZPLS-module van de tweede locatie, en komen ze uiteindelijk aan op het apparaat van de gebelde partij. Het volgende diagram geeft een overzicht van deze configuratie:

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

{% hint style="danger" %}
Deze configuratie **vereist** E.164-telefoonnummerverwerking op de geconfigureerde SBC's.
{% endhint %}

De volgende tabel toont ook de survivability van Zoom Phone in een ontwerp met meerdere locaties met onafhankelijke SBC's:

| Gesprekken afkomstig uit gebouw | Kan deze locaties bereiken tijdens een storing van extern internet | Kan deze locaties bereiken tijdens een storing in het campusnetwerk |
| ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------- |
| Gebouw A (ZPLS-host)            | ☑️Gebouwen A, B en C                                               | ☑️Gebouwen A, B en C                                                |
| Gebouw B (ZPLS-host)            | ☑️Gebouwen A, B en C                                               | ☑️Gebouwen A, B en C                                                |
| Gebouw C (ZPLS-host)            | ☑️Gebouwen A, B en C                                               | ☑️Gebouwen A, B en C                                                |

#### <mark style="color:blauw;">Nomadische gebruikers registreren zich altijd bij de ZPLS-module die is gekoppeld aan hun thuislocatie</mark>

Wanneer gebruikers of apparaten worden toegevoegd aan Zoom Phone, wordt een 'thuis'-locatie statisch gekoppeld aan de gebruiker of het apparaat totdat deze anders wordt bijgewerkt door een accountbeheerder. Dit betekent dat als een gebruiker zich verplaatst naar een fysieke Locatie buiten de gekoppelde thuislocatie, zoals een kantoorgebouw dat aan een andere locatie is gekoppeld, Zoom de aan de gebruiker gekoppelde locatie niet dynamisch zal aanpassen. Als de gebruiker daardoor de verbinding met de datacenters van Zoom Phone verliest, zal de gebruiker proberen zich te registreren bij de ZPLS-module die aan zijn of haar thuislocatie is gekoppeld, zelfs als deze zich op een andere Locatie bevindt.

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

Een gebruiker op een campus met meerdere locaties is gevestigd in gebouw A (locatie A) en verplaatst zich tijdelijk naar gebouw B (locatie B) voor een vergadering. Terwijl de gebruiker zich in gebouw B bevindt, doet zich een serviceverstorende gebeurtenis voor en wordt de survivability-modus ingeschakeld. Hoewel de gebruiker zich in gebouw B bevindt, zal de client van de gebruiker, omdat locatie A de thuislocatie is, proberen verbinding te maken met de ZPLS-module die is ingericht op de thuislocatie in gebouw A.

In dit scenario wordt de survivability-status van een gebruiker bepaald door het vermogen van het gebruikersapparaat om zich via het campusnetwerk te registreren bij de ZPLS-module binnen de thuislocatie. Als het campusnetwerk uitvalt terwijl de gebruiker niet op de thuislocatie is, kan de gebruiker geen gebruikmaken van de survivability-module.
{% endhint %}