Overwegingen bij Hardware-implementatie

Vind instructies voor het implementeren van de Zoom Node ZPLS-module op virtuele machines met ondersteunde hypervisors

Deze pagina schetst de implementatie van de Zoom Node ZPLS-module op een virtuele machine met ondersteunde hypervisors. Het biedt gedetailleerde configuratieopties die zijn afgestemd op verschillende Hardware-capaciteiten, zodat optimale prestaties worden gegarandeerd voor uiteenlopende operationele behoeften.

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 waarop het Zoom Node-platform draait, op een ondersteunde hypervisor. Meer informatie over Zoom Node als product is te vinden in de bijlage.

Klanten kunnen een van twee configuratieopties kiezen, afhankelijk van de Hardware-capaciteiten

De ZPLS-module ondersteunt twee configuraties, afhankelijk van de Hardware-capaciteiten van de virtuele machine. Deze capaciteiten staan 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
Maximaal aantal gelijktijdige gesprekken	240	480
Gesprekken per seconde	2	4
Registraties per seconde	60	400

Als het aantal eindpunten binnen een locatie met ingeschakelde survivability de implementatiecapaciteiten van die Locatie overschrijdt, verwerkt de ZPLS-module registraties op volgorde van binnenkomst. Klanten wordt geadviseerd extra modules Toevoegen, of de Zoom Phone Policy-instelling Lokale survivabilitymodus om te prioriteren welke gebruikers survivability-failover ondersteunen.

Schaalbaarheid en veerkracht van modules

ZPLS-modules ondersteunen clustering voor extra schaalbaarheid en/of veerkracht

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

Deze Functie(s) bevindt zich momenteel in bèta en vereist een ondersteuningsticket om te worden Ingeschakeld.

Schaalbaarheid vergroot de ondersteunde apparaatcapaciteiten van een Locatie

Het uitbreiden van het aantal ZPLS-modules vergroot de capaciteiten van elke Locatie lineair voor elke extra module. Als bijvoorbeeld één module in totaal 5.000 registraties ondersteunt, verhoogt het implementeren van vijf modules de ondersteuning tot 25.000 registraties.

Redundantie voegt extra modules toe voor veerkracht, maar schaalt de apparaatcapaciteiten van een Locatie niet op

Wanneer een ZPLS-module wordt gebruikt voor redundante doeleinden, dragen de redundante modules niet bij aan het totale aantal ondersteunde extensies. In plaats daarvan staan de modules op ‘hot standby’ en worden ze alleen ingeschakeld als primaire modules uitvallen. Bijvoorbeeld: één primaire en één redundante module ondersteunen in totaal 5.000 registraties, dus als een primaire module uitvalt, wordt de redundante module niet met apparaten boven de ondersteunde limiet overbelast.

Voorbeeld van ZPLS-implementatie met schaalbaarheid en redundantie

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

Voorbeeld:

Een ziekenhuis moet voor survivability tot 10.000 geregistreerde extensies ondersteunen. 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. Omdat het ziekenhuis het belang van veerkracht erkent, implementeert het 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 nu een primaire module een storing ondervindt, nemen de redundante module(s) de rol Overnemen om ononderbroken service te behouden, terwijl ze ondersteuning blijven bieden aan maximaal 10.000 geregistreerde apparaten.

Overwegingen voor locatieontwerp

Locaties groeperen Zoom Phone-gebruikers per locatie voor gedeelde telefonie-instellingen en -beleidsregels

Een locatie is een specifieke term die binnen Zoom Phone wordt gebruikt om gebruikers met gedeelde kenmerken — zoals een gemeenschappelijke Accesscode, adres, SIP Zone, afdeling of beleid — samen te brengen in één beheersbare groep binnen de Zoom-webportal. Voor sommige klanten kan één Locatie alle gebruikers binnen hun Zakelijk vertegenwoordigen en meerdere gebouwen binnen een campus of Locatie omvatten; voor anderen kunnen Meerdere sites nodig zijn, afhankelijk van uw Zakelijk behoeften. Voor meer informatie over Locaties of locatiebeheer, raadpleeg het Ondersteuningscentrum van Zoom.

Zoom Phone ondersteunt ontwerpen voor één locatie en Meerdere sites

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 gebruikerssegmenten afzonderlijk per locatie, gebouw, afdeling of functie, elk met een eigen locatie.

Accountbeheerders van huidige Zoom-klanten kunnen hun huidige locatieontwerp controleren via de Bedrijfsinformatie pagina, Beschikbaar in het Telefoonsysteembeheer menu in de Zoom-webportal.

Elke ZPLS-module kan slechts aan één locatie tegelijk worden gekoppeld

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

Elke locatie kan gelijktijdig maximaal 20 ZPLS-modules ondersteunen

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

Deze Functie(s) bevindt zich momenteel in bèta en vereist een ondersteuningsticket om te worden Ingeschakeld.

ZPLS-modules ondersteunen bellen tussen locaties als de modules zijn verbonden met een gemeenschappelijk netwerk

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

Deze Functie(s) bevindt zich momenteel in bèta en vereist een ondersteuningsticket om te worden Ingeschakeld.

Voordat ZPLS wordt geïmplementeerd, moeten accounts begrijpen welke locatieconfiguratie het best aansluit op hun behoeften

Omdat elke ZPLS-module slechts aan éé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 is om aan hun praktische zakelijke en survivabilitybehoeften te voldoen, aangezien voor elke extra locatie waarvoor survivability is ingeschakeld, ten minste één extra ZPLS-module nodig is.

Een ontwerp met één locatie is eenvoudiger te beheren en biedt survivability met één ZPLS-module, maar biedt minder flexibiliteit voor gebruikersinstellingen en -beleid

Een ontwerp met één locatie helpt het beheer van Zoom Phone-Instellingen en -beleid te stroomlijnen door alle gebruikers binnen een account onder één uniforme groep samen te brengen. Deze ene gebruikersgroep biedt bedrijven eenvoudige administratie en minder complexiteit, waardoor het beheerproces wordt vereenvoudigd. Bovendien kan een ontwerp met één locatie lokale telefonie-survivability bieden met één ZPLS-module, zolang de gebruikers van de Locatie de capaciteiten van één module.

De eenvoud van een ontwerp met één locatie kent echter van nature ook beperkingen. Met name 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. Verder kunnen implementaties met één locatie kwetsbaar zijn in bepaalde survivabilityscenario's als het lokale netwerk uitvalt.

Een ontwerp met meerdere locaties biedt meer flexibiliteit voor gebruikersinstellingen en -beleid, maar vereist één ZPLS-module voor elke locatie waarvoor survivability is ingeschakeld en is ingewikkelder te beheren

Een ontwerp met meerdere locaties biedt bedrijven extra flexibiliteit in gebruikersinstellingen en -beleid door gebruikers te scheiden in verschillende groepen met fijnmazige instellingsregelingen. Dit ontwerp stelt organisaties in staat communicatieconfiguraties nauwkeurig aan te passen om aan specifieke vereisten te voldoen op uiteenlopende Locaties, wat resulteert in een verfijndere en meer aanpasbare gebruikerservaring voor verschillende afdelingen, scenario's of behoeften. Daarnaast kunnen implementaties met meerdere locaties communicatie tussen locaties als de Locaties zijn verbonden via een gemeenschappelijk netwerk.

Het beheren van een ontwerp met meerdere locaties vereist echter nauwkeurige aandacht voor de bijzonderheden van de unieke vereisten van elke locatie, wat een hoger niveau van administratieve inspanning kan vergen. Verder vereist elke locatie waarvoor survivability is ingeschakeld één ZPLS-module en één licentie, omdat elke ZPLS-module slechts aan één locatie tegelijk kan worden toegewezen, wat kan bijdragen aan een meer hulpbronnenintensieve opzet.

In een ontwerp met meerdere locaties hebben klanten de flexibiliteit om te kiezen welke locaties voor survivability worden geconfigureerd. Locaties zonder een ZPLS-module kan geen gesprekken plaatsen of ontvangen totdat de standaardverbinding is hersteld.

Netwerkstoringen

Survivability kan worden beïnvloed als het lokale netwerk van een locatie uitvalt

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

Lokale netwerkstoring bij één locatie

In een ontwerp met één locatie zijn een of meer gebouwen verbonden via een lokaal netwerk of campusnetwerk, en worden ze vertegenwoordigd door één 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 met slechts één ZPLS-module; dit ontwerp is echter kwetsbaar bij een storing in het lokale netwerk of campusnetwerk die communicatie tussen gebouwen beïnvloedt. Het volgende voorbeeld beschrijft hoe een lokale netwerkstoring een implementatie met één locatie kan beïnvloeden.

Voorbeeld:

Een bedrijf implementeert de ZPLS-module voor één 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 in de externe internetdienst of een gebeurtenis die de service beïnvloedt, kan elke gebruiker binnen de locatie een andere gebruiker binnen dezelfde zelfde locatie bellen, zolang beide gebruikers via het campusnetwerk verbonden blijven met de ZPLS-module.

Bij een storing van het campusnetwerk kunnen gebruikers in gebouwen B en C echter geen gesprekken plaatsen zolang de ZPLS-module in gebouw A onbereikbaar is. Bijgevolg moeten gebruikers in gebouwen B en C wachten tot het campusnetwerk is hersteld voor survivability-bellen.

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

Gesprekken afkomstig uit gebouw	Kunnen deze locaties bereiken tijdens een storing van internet van buitenaf	Kunnen deze locaties bereiken tijdens een campusnetwerkstoring
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	✖️

Lokale netwerkstoring bij meerdere locaties zonder SBC

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 verbonden zijn via een gemeenschappelijk campusnetwerk.

Met dit locatieontwerp ondersteunt elke locatie een eigen ZPLS-module, waardoor gebruikers binnen hetzelfde gebouw elkaar kunnen bellen wanneer survivability mode 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 bij een storing van het campusnetwerk die communicatie tussen gebouwen beïnvloedt. Het volgende voorbeeld beschrijft hoe een campusnetwerkstoring een implementatie met meerdere locaties kan beïnvloeden.

Voorbeeld:

Een bedrijf implementeert de ZPLS-module op hun 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 niet afhankelijk is van externe internetdienst voor communicatie tussen gebouwen.

In dit voorbeeld kan bij een storing in de externe internetdienst, een campusnetwerkstoring of een gebeurtenis die de service beïnvloedt, 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 doorgeven. In plaats daarvan kunnen gebruikers alleen gesprekken plaatsen naar andere gebruikers binnen hun lokale locatie.

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

Gesprekken afkomstig uit gebouw	Kunnen deze locaties bereiken tijdens een storing van internet van buitenaf	Kunnen deze locaties bereiken tijdens een campusnetwerkstoring
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

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

Bij een lokale netwerkstoring kunnen klanten met een ontwerp met meerdere locaties waarin de ZPLS-module is geïntegreerd met een SBC en PSTN-connectiviteit op elke locatie, bellen tussen locaties inschakelen als doorschakelen is ingeschakeld. Wanneer dit is geconfigureerd, worden telefoongesprekken die tijdens survivability mode worden geplaatst, gerouteerd van de client van de gebruiker naar het PSTN, vervolgens naar de SBC en ZPLS-module van de tweede locatie, en uiteindelijk naar het apparaat van de gebelde persoon. Het volgende diagram geeft een overzicht van deze configuratie:

Deze configuratie vereist E.164-verwerking van telefoonnummers op de geconfigureerde SBC's.

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

Gesprekken afkomstig uit gebouw	Kunnen deze locaties bereiken tijdens een storing van internet van buitenaf	Kunnen deze locaties bereiken tijdens een campusnetwerkstoring
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 apparaten aan Zoom Phone worden toegevoegd, wordt een 'thuis'-locatie statisch aan de gebruiker of het apparaat gekoppeld totdat deze anders wordt bijgewerkt door een accountbeheerder. Dit betekent dat als een gebruiker verhuist 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 aanpast. Als de gebruiker daardoor de connectiviteit met de datacenters van Zoom Phone verliest, probeert de gebruiker zich te registreren bij de ZPLS-module die aan de thuislocatie is gekoppeld, zelfs als die zich op een andere locatie bevindt.

Voorbeeld:

Een gebruiker op een campus met meerdere locaties werkt vanuit Gebouw A (Locatie A) en verplaatst zich tijdelijk naar Gebouw B (Locatie B) voor een vergadering. Terwijl diegene in Gebouw B is, doet zich een gebeurtenis voor die de service beïnvloedt en wordt survivability mode 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 op de thuislocatie in gebouw A is geconfigureerd.

In dit scenario wordt de survivabilitystatus 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 zich niet op zijn thuislocatie bevindt, kan de gebruiker niet profiteren van de survivability-module.