> 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/nl/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).
# Overwegingen voor Hardware-implementatie
Deze pagina beschrijft de implementatie van de Zoom Node ZPLS-module op een virtuele machine met ondersteunde hypervisors. Er worden gedetailleerde configuratieopties geboden die zijn afgestemd op verschillende Hardware-mogelijkheden, zodat optimale prestaties voor uiteenlopende operationele behoeften worden gewaarborgd.
### Ondersteunde hypervisors
#### Klanten moeten de Zoom Node-software installeren op een virtuele machine die draait op een ondersteunde hypervisor
Als een 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).
#### Klanten kunnen een van twee configuratieopties Kies, afhankelijk van de Hardware-mogelijkheden
De ZPLS-module ondersteunt twee configuraties, afhankelijk van de Hardware-mogelijkheden van de virtuele machine. Deze mogelijkheden worden hieronder vermeld:
| | Configuratieoptie 1 | Configuratieoptie 2 |
| ------------------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Hardware-specificaties** | 8 CPU
16 GB RAM
80 GB HDD
| 16 CPU
16 GB RAM
80 GB HDD
|
| **Totaal aantal registraties** | 2000 | 5000 |
| **Maximum aantal gelijktijdige gesprekken** | 240 | 480 |
| **Gesprekken per seconde** | 2 | 4 |
| **Registraties per seconde** | 60 | 400 |
{% hint style="info" %}
Als het aantal eindpunten 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 aangeraden extra modules Toevoegen, of de Zoom Phone-beleidsinstelling te gebruiken [**Lokale survivabilitymodus**](#_ah8xua8wdq10) om prioriteit te geven aan welke gebruikers survivability-failover ondersteunen.
{% endhint %}
### Moduleschaling en veerkracht
#### ZPLS-modules ondersteunen clustering voor extra schaling en/of veerkracht
Klanten kunnen ZPLS-modules groeperen met maximaal 20 modules per locatie (of 100 totale Node-Apparaaten per account) voor extra redundantie of schaling.
{% hint style="info" %}
Deze Functie(s) bevindt zich momenteel in bèta en vereist dat een technisch ondersteuningsticket wordt ingeschakeld.
{% endhint %}
#### Schaling vergroot de ondersteunde Apparaatmogelijkheden van een locatie
Het uitbreiden van het aantal ZPLS-modules vergroot de mogelijkheden van elke locatie lineair voor elke extra module. Als bijvoorbeeld één module in totaal 5.000 registraties ondersteunt, zal de implementatie van vijf modules de ondersteuning verhogen naar 25.000 registraties.
#### Redundantie voegt extra modules toe voor veerkracht, maar schaalt de Apparaatmogelijkheden van een locatie niet
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. Bijvoorbeeld: één primaire en één redundante module ondersteunen in totaal 5.000 registraties, zodat, als een primaire module uitvalt, de redundante module niet overtekend wordt met Apparaaten boven de ondersteunde limiet.
#### Voorbeeld van het implementeren van ZPLS met schaling en redundantie
Voor het gemak demonstreert het volgende voorbeeld implementatie met extra schaling en redundantie.
{% 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 zijn elk in staat om 5.000 registraties te ondersteunen, wat resulteert in een totale Capaciteit van maximaal 10.000 registraties. Gezien het belang van veerkracht implementeert het ziekenhuis echter 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) Overnemen om ononderbroken service te behouden, terwijl tot 10.000 geregistreerde Apparaaten ondersteund blijven.
{% endhint %}
### Overwegingen voor locatieontwerp
#### Locaties groeperen Zoom Phone-gebruikers op Locatie voor gemeenschappelijke telefonie-Instellingen en beleidsregels
A **locatie** is een specifieke term die binnen Zoom Phone wordt gebruikt en die gebruikers met gedeelde kenmerken — zoals een gemeenschappelijke toegangscode, adres, SIP-zone, afdeling of beleidsregels — groepeert in één enkele, beheersbare Groep binnen het Zoom-webportal. Voor sommige Klanten kan één enkele locatie alle gebruikers binnen hun bedrijf vertegenwoordigen en zich uitstrekken over meerdere gebouwen binnen een campus of Locatie; voor anderen kunnen Meerdere sites vereist 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).
#### Zoom Phone ondersteunt ontwerpen met één locatie en meerdere locaties
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 per Locatie, gebouw, afdeling of functie afzonderlijk, elk met een eigen locatie.
{% 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 %}
#### Elke ZPLS-module kan slechts met één locatie tegelijk worden gekoppeld
Zoals eerder vermeld, is een ZPLS-module de [registrar met derde prioriteit](#_7itj40mx1dut) voor ondersteunde Apparaaten, na primaire en secundaire SIP-zones. Omdat Apparaaten hun SRV-lijsten ontvangen tijdens het opstartproces, en deze lijsten gekoppeld zijn aan de instelling van hun locatie, **kan elke ZPLS-module slechts met één locatie tegelijk worden gekoppeld**.
#### Elke locatie kan gelijktijdig maximaal 20 ZPLS-modules ondersteunen
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) bevindt zich momenteel in bèta en vereist dat een technisch ondersteuningsticket wordt ingeschakeld.
{% endhint %}
#### ZPLS-modules ondersteunen bellen tussen locaties als de modules verbonden zijn met een gemeenschappelijk netwerk
ZPLS-modules van verschillende locaties ondersteunen bellen tussen locaties tijdens een survivability-Evenement zolang de Apparaaten vindbaar zijn binnen het lokale netwerk. Als bijvoorbeeld een zakelijke campus drie gebouwen heeft, elk met een eigen telefoonlocatie, kunnen de ZPLS-modules van elke locatie locatie-naar-locatiegesprekken verbinden via het campusnetwerk.
{% hint style="info" %}
Deze Functie(s) bevindt zich momenteel in bèta en vereist dat een technisch ondersteuningsticket wordt ingeschakeld.
{% endhint %}
#### Voordat ZPLS wordt geïmplementeerd, moeten accounts begrijpen welke locatieconfiguratie het best past bij hun behoeften
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 past bij hun praktische zakelijke behoeften en survivability-behoeften, aangezien voor elke extra voor survivability ingeschakelde locatie ten minste één extra ZPLS-module vereist is.
#### Een ontwerp met één locatie is eenvoudiger te beheren en biedt survivability met één enkele ZPLS-module, maar biedt minder flexibiliteit voor gebruikers-Instellingen en beleidsregels
Een ontwerp met één locatie helpt het beheer van Zoom Phone-Instellingen en beleidsregels te stroomlijnen door alle gebruikers binnen een account te consolideren onder één enkele, uniforme Groep. Deze enkele gebruikersgroep biedt bedrijven eenvoudig beheer en minder complexiteit, wat het beheerproces vereenvoudigt. Daarnaast kan een ontwerp met één locatie lokale telefonische survivability bieden met één enkele ZPLS-module, zolang de gebruikers van de locatie niet groter zijn dan de [mogelijkheden van één enkele module](#_rx0i1j9xofnc).
De eenvoud van een ontwerp met één locatie brengt echter van nature beperkingen met zich mee. Specifiek 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 verschillende behoeften. Verder kunnen implementaties met één locatie kwetsbaar zijn in bepaalde survivalscenario's als het [lokale netwerk uitvalt](#_gzpf5m70jl3i).
#### Een ontwerp met meerdere locaties biedt meer flexibiliteit voor gebruikers-Instellingen en beleidsregels, maar vereist één ZPLS-module voor elke voor survivability ingeschakelde locatie en is ingewikkelder te beheren
Een ontwerp met meerdere locaties biedt bedrijven extra flexibiliteit in gebruikers-Instellingen en beleidsregels door gebruikers op te splitsen in verschillende groepen met gedetailleerde instellingscontroles. Dit ontwerp stelt organisaties in staat communicatieconfiguraties nauwkeurig aan te passen om aan specifieke vereisten op diverse locaties te voldoen, wat resulteert in een verfijndere en beter aanpasbare gebruikerservaring voor verschillende afdelingen, scenario's of behoeften. Daarnaast 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 een hoger niveau van beheersinspanning kan vereisen. 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 opzet.
{% 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 kunnen geen gesprekken voeren of ontvangen totdat de standaardconnectiviteit is hersteld.
{% endhint %}
### Netwerkstoringen
#### Survivability kan worden beïnvloed als het lokale netwerk van een locatie uitvalt
Hoewel ZPLS-modules ontworpen zijn 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.
#### Storing van lokaal netwerk bij één locatie
In een ontwerp met één locatie zijn één of meer gebouwen verbonden via een lokaal netwerk of campusnetwerk en worden ze weergegeven 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 enkele 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 de communicatie tussen gebouwen beïnvloedt. Het volgende voorbeeld beschrijft hoe een storing in het lokale netwerk een implementatie met één locatie kan beïnvloeden.
{% 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 zijn verbonden. De ZPLS-module werkt in gebouw A en is **niet** verbonden met een SBC voor extern bellen via de PSTN.
In het geval van een storing van een externe internetdienst of een serviceverstorende gebeurtenis kan elke gebruiker binnen de locatie een andere gebruiker binnen dezelfde *dezelfde* locatie bellen, zolang beide gebruikers verbonden blijven met de ZPLS-module via het campusnetwerk.
Bij een storing van 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 totdat het campusnetwerk is hersteld voor survivability-bellen.
{% endhint %}
De volgende tabel toont Zoom Phone-survivability 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 van het campusnetwerk |
| ------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------- |
| Gebouw A (ZPLS-host) | ☑️Gebouwen A, B en C | ☑️ Alleen gebouw A *alleen* |
| Gebouw B | ☑️Gebouwen A, B en C | ✖️ |
| Gebouw C | ☑️Gebouwen A, B en C | ✖️ |
#### Storing van lokaal netwerk bij meerdere locaties zonder een SBC
In een ontwerp met meerdere locaties wordt elk gebouw of elke Locatie (bijv. verdieping, satellietkantoor enz.) onafhankelijk weergegeven 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 zijn verbonden.
Met dit locatieontwerp ondersteunt elke locatie zijn eigen ZPLS-module, waardoor gebruikers binnen hetzelfde gebouw elkaar kunnen bellen wanneer de survivabilitymodus is ingeschakeld. Verder kunnen gebruikers, wanneer meerdere locaties met een ZPLS-module via een gemeenschappelijk netwerk zijn verbonden, gebruikers op andere locaties bellen, zolang het lokale netwerk operationeel blijft. Dit ontwerp is echter kwetsbaar in het geval van een storing van het campusnetwerk die de communicatie tussen gebouwen beïnvloedt. Het volgende voorbeeld beschrijft hoe een storing van het campusnetwerk een implementatie met meerdere locaties kan beïnvloeden.
{% 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 een externe internetdienst.
In dit voorbeeld kan, in het geval van een storing van een externe internetdienst, een storing van 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, als het campusnetwerk uitvalt, geen gesprekken tussen locaties transporteren. In plaats daarvan zijn gebruikers beperkt tot het bellen van andere gebruikers binnen hun lokale locatie.
{% endhint %}
De volgende tabel toont Zoom Phone-survivability 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 van het campusnetwerk |
| ------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------- |
| Gebouw A (ZPLS-host) | ☑️ Gebouwen A, B en C | ☑️ Alleen gebouw A |
| Gebouw B (ZPLS-host) | ☑️ Gebouw A, B en C | ☑️ Gebouw B |
| Gebouw C (ZPLS-host) | ☑️ Gebouw A, B en C | ☑️ Gebouw C |
#### Als een lokaal netwerk uitvalt, wordt bellen tussen locaties ook ondersteund via de PSTN, op voorwaarde dat elke locatie is verbonden met een SBC en doorschakelen van gesprekken is ingeschakeld
In het geval van een storing van een lokaal netwerk kunnen Klanten met een ontwerp met meerdere locaties dat de ZPLS-module integreert met een SBC en PSTN-connectiviteit op elke locatie locatie-naar-locatiegesprekken inschakelen als [doorschakelen van gesprekken is ingeschakeld](#_2v7qst7vxwaa). Wanneer dit is geconfigureerd, worden telefoongesprekken die tijdens de survivabilitymodus worden geplaatst, gerouteerd van de client van de gebruiker naar de PSTN, naar de SBC en ZPLS-module van de tweede locatie, en komen uiteindelijk aan op het Apparaat van de gebelde partij. Het volgende diagram geeft een overzicht van deze configuratie:
{% hint style="danger" %}
Deze configuratie **vereist** E.164-verwerking van telefoonnummers op de geconfigureerde SBC's.
{% endhint %}
De volgende tabel toont ook Zoom Phone-survivability in een ontwerp met meerdere locaties en onafhankelijke SBC's:
| Gesprekken afkomstig uit gebouw | Kan deze locaties bereiken tijdens een storing van extern internet | Kan deze locaties bereiken tijdens een storing van 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 |
#### Nomadische gebruikers registreren zich altijd bij de ZPLS-module die aan hun thuislocatie is gekoppeld
Wanneer gebruikers of Apparaaten worden toegevoegd aan Zoom Phone, wordt een “thuis”-locatie statisch gekoppeld aan de gebruiker of het Apparaat totdat dit 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 gebonden locatie niet dynamisch zal aanpassen. Als gevolg daarvan zal de gebruiker, als die de connectiviteit met Zoom Phone-datacenters verliest, proberen zich te registreren bij de ZPLS-module die aan de thuislocatie is gekoppeld, zelfs als die 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 deze zich in gebouw B bevindt, vindt er een serviceverstorende gebeurtenis plaats en wordt de survivabilitymodus 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 survivabilitystatus van een gebruiker bepaald door het vermogen van het gebruikers-Apparaat om zich via het campusnetwerk te registreren bij de ZPLS-module binnen de thuislocatie. Als het campusnetwerk uitvalt terwijl de gebruiker weg is van de thuislocatie, kan de gebruiker geen voordeel halen uit de survivability-module.
{% 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/nl/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.