Considérations relatives au déploiement du matériel

Trouvez des instructions pour déployer le module ZPLS de Zoom Node sur des machines virtuelles à l'aide d'hyperviseurs pris en charge

Cette page décrit le déploiement du module Zoom Node ZPLS sur une machine virtuelle utilisant des hyperviseurs pris en charge. Elle fournit des options de configuration détaillées adaptées pour tenir compte des différentes capacités matérielles, garantissant des performances optimales pour divers besoins opérationnels.

Hyperviseurs pris en charge

Les clients doivent installer le logiciel Zoom Node sur une machine virtuelle exécutée sur un hyperviseur pris en charge

En tant que charge de travail Zoom Node, le module ZPLS doit être installé sur une machine virtuelle exécutant la plateforme Zoom Node, sur un hyperviseur pris en charge. Des informations supplémentaires sur Zoom Node en tant que produit peuvent être trouvées dans l'annexe.

Les clients peuvent choisir l'une des deux options de configuration, en fonction des capacités matérielles

Le module ZPLS prend en charge deux configurations, selon les capacités matérielles de la machine virtuelle. Ces capacités sont listées ci-dessous :

	Option de configuration 1	Option de configuration 2
Spécifications matérielles	8 CPU 16 Go de RAM 80 Go de disque dur (HDD)	16 CPU 16 Go de RAM 80 Go de disque dur (HDD)
Total des enregistrements	2000	5000
Appels simultanés maximum	240	480
Appels par seconde	2	4
Enregistrements par seconde	60	400

Si le nombre de terminaux au sein d'un site activé pour la survivabilité dépasse les capacités de déploiement d'un site, le module ZPLS traitera les enregistrements selon le principe du premier arrivé, premier servi. Il est conseillé aux clients d'ajouter des modules supplémentaires, ou d'utiliser le paramètre de stratégie Zoom Phone Mode de survivabilité local pour prioriser les utilisateurs qui prennent en charge le basculement de survivabilité.

Mise à l'échelle et résilience du module

Les modules ZPLS prennent en charge le clustering pour une montée en charge et/ou une résilience supplémentaires

Les clients peuvent regrouper des modules ZPLS avec jusqu'à 20 modules par site (ou 100 dispositifs Node au total par compte) pour une redondance ou une mise à l'échelle supplémentaires.

Cette fonctionnalité est actuellement en bêta et nécessite l'ouverture d'un ticket d'assistance technique pour être activée.

La mise à l'échelle augmente les capacités de dispositifs prises en charge par un site

L'augmentation du nombre de modules ZPLS améliore linéairement les capacités de chaque site pour chaque module supplémentaire. Par exemple, si un module prend en charge au total 5 000 enregistrements, le déploiement de cinq modules portera la capacité à 25 000 enregistrements.

La redondance ajoute des modules supplémentaires pour la résilience, mais n'augmente pas les capacités de dispositifs d'un site

Lorsqu'un module ZPLS est utilisé à des fins de redondance, les modules redondants ne contribuent pas au nombre total d'extensions prises en charge. Au lieu de cela, les modules sont en "veille chaude" et ne s'engagent que si les modules primaires échouent. Par exemple, un module primaire et un module redondant prennent en charge au total 5 000 enregistrements ; ainsi, si un module primaire tombe en panne, le module redondant n'est pas surchargé par des dispositifs au-delà de sa limite prise en charge.

Exemple de déploiement de ZPLS avec mise à l'échelle et redondance

Pour plus de commodité, l'exemple suivant illustre un déploiement avec mise à l'échelle et redondance supplémentaires.

Exemple:

Un hôpital doit prendre en charge jusqu'à 10 000 extensions enregistrées pour la survivabilité. Pour y parvenir, l'hôpital déploie quatre modules ZPLS.

Les deux premiers modules sont capables de prendre en charge chacun 5 000 enregistrements, ce qui donne une capacité totale pouvant atteindre 10 000 enregistrements. Cependant, reconnaissant l'importance de la résilience, l'hôpital déploie également deux modules supplémentaires en tant que sauvegardes redondantes des modules primaires.

Dans ce scénario, l'hôpital dispose désormais de matériels de survivabilité primaires et secondaires déployés. Ainsi, si un module primaire rencontre une panne, le(s) module(s) redondant(s) prendront le relais pour maintenir un service ininterrompu, tout en continuant à prendre en charge jusqu'à 10 000 dispositifs enregistrés.

Considérations de conception du site

Les sites regroupent les utilisateurs Zoom Phone par emplacement pour des paramètres et politiques téléphoniques communs

Un site est un terme spécifique utilisé dans Zoom Phone qui regroupe des utilisateurs ayant des caractéristiques communes — comme un même code d'accès, adresse, zone SIP, département ou politiques — en un seul groupe gérable dans le portail web Zoom. Pour certains clients, un site unique peut représenter tous les utilisateurs de leur entreprise et peut s'étendre sur plusieurs bâtiments d'un campus ou d'un emplacement ; pour d'autres, plusieurs sites peuvent être nécessaires en fonction de vos besoins commerciaux. Pour plus d'informations sur les sites ou la gestion des sites, consultez le centre d'assistance de Zoom.

Zoom Phone prend en charge des conceptions à site unique et multi-site

Il existe deux conceptions principales pour configurer les sites Zoom Phone dans un compte :

1. Site unique: Représentant tous les utilisateurs d'un compte, pouvant s'étendre sur plusieurs bâtiments ou emplacements, au sein d'un seul site Zoom Phone.

2. Multi-site: Représentant séparément des segments d'utilisateurs par emplacement, bâtiment, département ou fonction, chacun avec son propre site.

Les administrateurs de compte des clients Zoom actuels peuvent vérifier leur conception de site actuelle via la informations de l'entreprise page, disponible dans le gestion du système téléphonique menu du portail web.

Chaque module ZPLS ne peut être associé qu'à un seul site à la fois

Comme mentionné précédemment, un module ZPLS est le registreur de troisième priorité pour les dispositifs pris en charge, derrière les zones SIP primaires et secondaires. Parce que les dispositifs reçoivent leurs listes SRV lors du démarrage et que ces listes sont liées aux paramètres de leur site, chaque module ZPLS ne peut être associé qu'à un seul site à la fois.

Chaque site peut prendre en charge jusqu'à 20 modules ZPLS simultanément

Bien que chaque module ZPLS ne puisse être associé qu'à un seul site à la fois, un site peut prendre en charge jusqu'à 20 modules ZPLS dans un même groupe, élargissant ainsi les capacités de survivabilité de chaque site.

Cette fonctionnalité est actuellement en bêta et nécessite l'ouverture d'un ticket d'assistance technique pour être activée.

Les modules ZPLS prennent en charge les appels inter-sites si les modules sont connectés à un réseau commun

Les modules ZPLS de différents sites prennent en charge les appels inter-sites lors d'un événement de survivabilité tant que les dispositifs sont découvrables au sein du réseau local. Par exemple, si un campus d'entreprise comporte trois bâtiments, chacun avec son propre site téléphonique, les modules ZPLS de chaque site peuvent établir des appels site à site via le réseau de campus.

Cette fonctionnalité est actuellement en bêta et nécessite l'ouverture d'un ticket d'assistance technique pour être activée.

Avant de déployer ZPLS, les comptes doivent comprendre quelle configuration de site convient le mieux à leurs besoins

Parce que chaque module ZPLS ne peut être associé qu'à un seul site à la fois, la conception des sites est l'un des facteurs les plus importants lors du déploiement du service ZPLS dans un compte. Pour cette raison, les clients doivent comprendre quelle configuration de site est la mieux adaptée pour répondre à leurs besoins opérationnels et de survivabilité, car chaque site supplémentaire activé pour la survivabilité nécessitera au moins un module ZPLS supplémentaire.

Une conception à site unique est plus facile à gérer et fournit la survivabilité avec un seul module ZPLS, mais offre moins de flexibilité pour les paramètres et les politiques des utilisateurs

Une conception à site unique aide à rationaliser la gestion des paramètres et des politiques de Zoom Phone en consolidant tous les utilisateurs d'un compte sous un seul groupe unifié. Ce groupe unique d'utilisateurs offre aux entreprises une administration simple et une complexité réduite, simplifiant le processus de gestion. De plus, une conception à site unique peut offrir une survivabilité téléphonique locale avec un seul module ZPLS, tant que les utilisateurs du site ne dépassent pas les capacités d'un module unique.

Cependant, la simplicité d'une conception à site unique comporte naturellement des limites. Plus précisément, les conceptions à site unique offrent moins de flexibilité en raison de leur nature "taille unique", ce qui peut ne pas convenir à tous les scénarios de déploiement répartis entre plusieurs départements ayant des besoins différents. En outre, les déploiements à site unique peuvent être vulnérables dans certains scénarios de survie si le réseau local échoue.

Une conception multi-site offre plus de flexibilité pour les paramètres et politiques des utilisateurs, mais nécessite un module ZPLS pour chaque site activé pour la survivabilité et est plus compliquée à gérer

Une conception multi-site offre aux entreprises une flexibilité supplémentaire dans les paramètres et politiques des utilisateurs en séparant les utilisateurs en divers groupes avec des contrôles de paramètres granulaires. Cette conception permet aux organisations d'ajuster finement les configurations de communication pour répondre à des exigences spécifiques sur différents sites, aboutissant à une expérience utilisateur plus raffinée et adaptable pour divers départements, scénarios ou besoins. De plus, les déploiements multi-site peuvent prendre en charge la communication inter-sites si les sites sont connectés via un réseau commun.

Cependant, la gestion d'une conception multi-site exige une attention particulière aux spécificités des exigences uniques de chaque site, ce qui peut nécessiter un niveau d'effort administratif plus élevé. De plus, comme chaque module ZPLS ne peut être assigné qu'à un seul site à la fois, chaque site activé pour la survivabilité nécessitera un module et une licence ZPLS, ce qui peut contribuer à une configuration plus gourmande en ressources.

Dans une conception multi-site, les clients ont la flexibilité de choisir quels sites seront configurés pour la survivabilité. Les sites sans un module ZPLS restera incapable d'émettre ou de recevoir des appels tant que la connectivité standard ne sera pas rétablie.

Pannes réseau

La survivabilité peut être affectée si le réseau local d'un site tombe en panne

Bien que les modules ZPLS soient conçus pour fournir une survivabilité téléphonique locale lors d'événements impactant le service, la survivabilité peut être affectée si le réseau local d'un site tombe en panne. Ces scénarios sont décrits dans les deux sections suivantes.

Panne du réseau local dans un site unique

Dans une conception à site unique, un ou plusieurs bâtiments sont connectés via un réseau local ou de campus et sont représentés par un seul site dans Zoom Phone. Cette configuration suppose un réseau commun entre tous les utilisateurs et bâtiments d'un emplacement, sans dépendances réseau externes (par exemple, Internet) pour la communication entre bâtiments.

Avec cette conception de site, une entreprise peut fournir une survivabilité locale à tous les utilisateurs d'un site ou d'un emplacement unique avec seulement un module ZPLS ; cependant, cette conception est vulnérable en cas de panne du réseau local ou du réseau de campus qui affecte la communication inter-bâtiments. L'exemple suivant décrit comment une panne de réseau local peut affecter un déploiement à site unique.

Exemple :

Une entreprise déploie le module ZPLS pour un seul site Zoom Phone, composé des bâtiments A, B et C, qui sont connectés via un réseau de campus. Le module ZPLS fonctionne dans le bâtiment A et est pas connecté à un SBC pour les appels externes via le RTC.

En cas de panne du service Internet externe ou d'événement impactant le service, tout utilisateur contenu dans le site peut appeler un autre utilisateur au sein du même site, tant que les deux utilisateurs maintiennent la connectivité au module ZPLS via le réseau de campus.

Cependant, en cas de panne du réseau de campus, les utilisateurs des bâtiments B et C ne peuvent pas passer d'appels tant que le module ZPLS du bâtiment A est inaccessible. Par conséquent, les utilisateurs des bâtiments B et C doivent attendre que le réseau de campus soit rétabli pour les appels de survivabilité.

Le tableau suivant illustre la survivabilité de Zoom Phone dans une conception à site unique sur plusieurs bâtiments :

Appels provenant du bâtiment	Peuvent atteindre ces emplacements lors d'une panne d'Internet externe	Peuvent atteindre ces emplacements lors d'une panne du réseau de campus
Bâtiment A (hôte ZPLS)	☑️ Bâtiments A, B et C	☑️ Bâtiment A seulement
Bâtiment B	☑️ Bâtiments A, B et C	✖️
Bâtiment C	☑️ Bâtiments A, B et C	✖️

Panne du réseau local multi-site sans SBC

Dans une conception multi-site, chaque bâtiment ou emplacement (par exemple, étage, bureau satellite, etc.) est représenté indépendamment par un site unique dans Zoom Phone. Cette configuration suppose que chaque site dispose d'un module ZPLS et que les sites sont connectés via un réseau de campus commun.

Avec cette conception de site, chaque site prend en charge son propre module ZPLS, permettant aux utilisateurs du même bâtiment de s'appeler lorsque le mode de survivabilité est activé. De plus, lorsque plusieurs sites avec un module ZPLS sont connectés via un réseau commun, les utilisateurs peuvent appeler des utilisateurs d'autres_sites, tant que le réseau local reste opérationnel. Cependant, cette conception est vulnérable en cas de panne du réseau de campus qui affecte la communication inter-bâtiments. L'exemple suivant décrit comment une panne du réseau de campus peut affecter un déploiement multi-site.

Exemple :

Une entreprise déploie le module ZPLS au sein de son campus multi-bâtiments, composé des bâtiments A, B et C. Chaque bâtiment est un site unique dans Zoom Phone et dispose d'un module ZPLS spécifique au site. Tous les bâtiments du campus sont connectés via un réseau de campus qui ne dépend pas d'un service Internet externe pour les communications inter-bâtiments.

Dans cet exemple, en cas de panne du service Internet externe, de panne du réseau de campus ou d'événement impactant le service, tout utilisateur situé au sein d'un site peut appeler un autre utilisateur situé dans le même site. Cependant, parce que chaque bâtiment est un site unique et que les utilisateurs s'enregistrent auprès de leurs modules spécifiques au site, si le réseau de campus tombe en panne, les modules ZPLS ne peuvent pas transporter les appels inter-sites. Au lieu de cela, les utilisateurs seront limités à passer des appels vers d'autres utilisateurs au sein de leur site local.

Le tableau suivant illustre la survivabilité de Zoom Phone à partir de l'exemple ci-dessus dans une conception multi-site avec un réseau de campus interconnecté :

Appels provenant du bâtiment	Peuvent atteindre ces emplacements lors d'une panne d'Internet externe	Peuvent atteindre ces emplacements lors d'une panne du réseau de campus
Bâtiment A (hôte ZPLS)	☑️ Bâtiments A, B et C	☑️ Bâtiment A
Bâtiment B (hôte ZPLS)	☑️ Bâtiment A, B et C	☑️ Bâtiment B
Bâtiment C (hôte ZPLS)	☑️ Bâtiment A, B et C	☑️ Bâtiment C

Si un réseau local tombe en panne, les appels inter-sites sont également pris en charge via le RTC, à condition que chaque site soit connecté à un SBC et dispose du renvoi d'appel activé

En cas de panne de réseau local, les clients disposant d'une conception multi-site qui intègrent le module ZPLS avec un SBC et une connectivité RTC à chaque site peuvent activer les appels site à site si le renvoi d'appel est activé. Une fois configurés, les appels téléphoniques passés en mode de survivabilité seront routés depuis le client de l'utilisateur vers le RTC, vers le SBC du deuxième site et le module ZPLS, pour finalement arriver sur l'appareil du destinataire. Le diagramme suivant offre une vue d'ensemble de cette configuration :

Cette configuration requiert le traitement des numéros de téléphone E.164 sur les SBC configurés.

Le tableau suivant illustre également la survivabilité de Zoom Phone dans une conception multi-site avec des SBC indépendants :

Appels provenant du bâtiment	Peuvent atteindre ces emplacements lors d'une panne d'Internet externe	Peuvent atteindre ces emplacements lors d'une panne du réseau de campus
Bâtiment A (hôte ZPLS)	☑️ Bâtiments A, B et C	☑️ Bâtiments A, B et C
Bâtiment B (hôte ZPLS)	☑️ Bâtiments A, B et C	☑️ Bâtiments A, B et C
Bâtiment C (hôte ZPLS)	☑️ Bâtiments A, B et C	☑️ Bâtiments A, B et C

Les utilisateurs nomades s'enregistrent toujours sur le module ZPLS associé à leur site d'origine

Lorsque des utilisateurs ou des dispositifs sont ajoutés à Zoom Phone, un site "d'origine" est associé statiquement à l'utilisateur ou au dispositif jusqu'à mise à jour par un administrateur de compte. Cela signifie que si un utilisateur déménage physiquement en dehors de son site d'origine, par exemple dans un bâtiment associé à un autre site, Zoom n'ajustera pas dynamiquement le site lié à l'utilisateur. Par conséquent, si l'utilisateur perd la connectivité aux centres de données Zoom, l'utilisateur tentera de s'enregistrer sur le module ZPLS associé à son site d'origine, même s'il se trouve à un autre emplacement.

Exemple :

Un utilisateur dans un campus multi-site est basé dans le bâtiment A (site A) et se déplace temporairement dans le bâtiment B (site B) pour une réunion. Pendant qu'il se trouve dans le bâtiment B, un événement impactant le service se produit et le mode de survivabilité est activé. Bien que l'utilisateur soit situé dans le bâtiment B, comme le site A est son site d'origine, le client de l'utilisateur tentera de se connecter au module ZPLS provisionné sur son site d'origine dans le bâtiment A.

Dans ce scénario, l'état de survivabilité d'un utilisateur est déterminé par la capacité de l'appareil utilisateur à s'enregistrer sur le module ZPLS de son site d'origine via le réseau de campus. Si le réseau de campus est hors service pendant que l'utilisateur est éloigné de son site d'origine, l'utilisateur ne pourra pas bénéficier du module de survivabilité.