Considérations pour le déploiement matériel

Trouvez des instructions pour déployer le module Zoom Node ZPLS 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 fonctionnant 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. Plus d'informations 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 HDD	16 CPU 16 Go de RAM 80 Go HDD
Inscriptions totales	2000	5000
Appels simultanés maximum	240	480
Appels par seconde	2	4
Inscriptions par seconde	45	90

Si le nombre de terminaux au sein d'un site doté de capacités de 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 survie local pour prioriser les utilisateurs qui bénéficient du basculement de survivabilité.

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

Les modules ZPLS prennent en charge le clustering pour une mise à l'échelle et/ou une résilience supplémentaires

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

Cette fonctionnalité est actuellement en version 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 d'appareils prises en charge d'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 inscriptions, le déploiement de cinq modules élèvera la prise en charge à 25 000 inscriptions.

La redondance ajoute des modules supplémentaires pour la résilience, mais n'augmente pas les capacités d'appareils 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 principaux tombent en panne. Par exemple, un module principal et un module redondant prennent en charge au total 5 000 inscriptions ; ainsi, si un module principal tombe en panne, le module redondant n'est pas surchargé par des appareils au-delà de sa limite prise en charge.

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

Par souci 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 inscriptions, ce qui donne une capacité totale allant jusqu'à 10 000 inscriptions. Cependant, reconnaissant l'importance de la résilience, l'hôpital déploie également deux modules supplémentaires comme sauvegardes redondantes des modules principaux.

Dans ce scénario, l'hôpital dispose désormais de matériel de survivabilité principal et secondaire déployé. Ainsi, si un module principal rencontre une panne, le(s) module(s) redondant(s) prendra(ont) le relais pour maintenir un service ininterrompu, tout en continuant de prendre en charge jusqu'à 10 000 appareils enregistrés.

Considérations de conception du site

Les sites regroupent les utilisateurs Zoom Phone par emplacement pour des paramètres et des 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 code d'accès partagé, une adresse, une zone SIP, un département ou des politiques — en un seul groupe gérable dans le portail Web Zoom. Pour certains clients, un site unique peut représenter tous les utilisateurs au sein 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 des besoins de l'entreprise. 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 au sein d'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 des segments d'utilisateurs par emplacement, bâtiment, département ou fonction séparément, chacun avec son propre site.

Les administrateurs de compte des clients Zoom actuels peuvent vérifier leur conception de site actuelle via la Informations sur 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 appareils pris en charge, derrière les zones SIP primaires et secondaires. Parce que les appareils reçoivent leurs listes SRV lors du processus de 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 groupe, étendant ainsi les capacités de survivabilité de chaque site.

Cette fonctionnalité est actuellement en version 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 pendant un événement de survivabilité tant que les appareils sont détectables sur le 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 acheminer des appels site à site à travers le réseau de campus.

Cette fonctionnalité est actuellement en version 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

Étant donné que chaque module ZPLS ne peut être associé qu'à un seul site à la fois, la conception du site 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 pratiques en matière d'entreprise 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 d'utilisateurs unique offre aux entreprises une administration simple et une complexité réduite, simplifiant le processus de gestion. De plus, une conception à site unique peut offrir la survivabilité téléphonique locale avec un seul module ZPLS, tant que les utilisateurs du site n'excèdent pas les capacités d'un seul module.

Cependant, la simplicité d'une conception à site unique comporte naturellement des limites. En particulier, 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 au sein de plusieurs départements aux besoins différents. De plus, les déploiements à site unique peuvent être vulnérables dans certains scénarios de survie si le réseau local tombe en panne.

Une conception multi-site offre plus de flexibilité pour les paramètres et les politiques des utilisateurs, mais exige 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 les 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 divers sites, aboutissant à une expérience utilisateur plus affinée et adaptable pour différents 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 complexités des exigences uniques de chaque site, ce qui peut nécessiter un niveau d'effort administratif plus élevé. De plus, puisque chaque module ZPLS ne peut être attribué 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 jusqu'à ce que la connectivité standard soit 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 la survivabilité téléphonique locale lors d'événements affectant 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 sur 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 inter-bâtiments.

Avec cette conception de site, une entreprise peut fournir la survivabilité locale à tous les utilisateurs d'un seul site ou emplacement avec aussi peu qu'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.

vm-111-disk-0.qcow2

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 affectant 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 tandis que le module ZPLS du bâtiment A est inaccessible. Par conséquent, les utilisateurs des bâtiments B et C doivent attendre la restauration du réseau de campus pour les appels en mode survivabilité.

Le tableau suivant illustre la survivabilité de Zoom Phone dans une conception à site unique multi-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 uniquement
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é de manière indépendante 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 lorsqu'on active le mode survivabilité. De plus, lorsque plusieurs sites disposant d'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.

vm-111-disk-0.qcow2

Une entreprise déploie le module ZPLS dans 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 du service Internet externe pour les communications inter-bâtiments.

Dans cet exemple, en cas de panne du service Internet externe, de coupure du réseau de campus ou d'événement affectant le service, tout utilisateur situé dans un site peut appeler un autre utilisateur situé dans le même site. Cependant, comme 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. À la place, les utilisateurs seront limités à appeler 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 que le renvoi d'appels soit activé

En cas de panne du réseau local, les clients disposant d'une conception multi-site intégrant le module ZPLS avec un SBC et une connectivité RTC à chaque site peuvent activer les appels site à site si le renvoi d'appels est activé. Une fois configurés, les appels téléphoniques passés en mode survivabilité seront acheminés du client de l'utilisateur vers le RTC, vers le SBC et le module ZPLS du second site, pour finalement arriver sur l'appareil du destinataire. Le schéma suivant fournit un aperçu de cette configuration :

Cette configuration exige 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 auprès du module ZPLS associé à leur site d'origine

Lorsque des utilisateurs ou des appareils sont ajoutés à Zoom Phone, un site « d'origine » est associé statiquement à l'utilisateur ou à l'appareil jusqu'à ce qu'un administrateur de compte le modifie. Cela signifie que si un utilisateur se déplace vers un emplacement physique en dehors de son site d'origine, comme un immeuble associé à un site différent, 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, il tentera de s'enregistrer auprès du module ZPLS associé à son site d'origine, même s'il se trouve à un autre emplacement.

vm-111-disk-0.qcow2

Un utilisateur d'un campus multi-site est basé au bâtiment A (site A) et se rend temporairement au bâtiment B (site B) pour une réunion. Pendant qu'il se trouve dans le bâtiment B, un événement affectant le service se produit et le mode survivabilité est activé. Bien que l'utilisateur soit situé dans le bâtiment B, puisque 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 de l'utilisateur à s'enregistrer auprès du 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 hors de son site d'origine, l'utilisateur ne peut pas bénéficier du module de survivabilité.