Considérations relatives au déploiement du matériel
Trouvez des instructions pour déployer le module ZPLS 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 à l'aide d'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. Vous trouverez plus d'informations sur Zoom Node en tant que produit dans l'annexe.
Les Clients peuvent choisir l'une des deux options de configuration, selon les 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 répertoriées ci-dessous :
Spécifications matérielles
8 CPU
16 Go de RAM
80 Go de disque dur
16 CPU
16 Go de RAM
80 Go de disque dur
Nombre total d'enregistrements
2000
5000
Nombre maximal d'appels simultanés
240
480
Appels par seconde
2
4
Enregistrements par seconde
60
400
Mise à l'échelle et résilience des modules
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.
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 un total de 5 000 enregistrements, le déploiement de cinq modules portera la prise en charge à 25 000 enregistrements.
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 active » et ne s'activeront qu'en cas de défaillance des modules principaux. Par exemple, un module principal et un module redondant prennent en charge un total de 5 000 enregistrements ; 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 montre 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 assurer la survivabilité. Pour y parvenir, l'hôpital déploie quatre modules ZPLS.
Les deux premiers modules sont capables de prendre en charge 5 000 enregistrements chacun, soit une capacité totale allant jusqu'à 10 000 enregistrements. Cependant, conscient de 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é. Désormais, si un module principal rencontre une défaillance, le ou les modules redondants prendront le relais pour maintenir un service ininterrompu, tout en continuant à prendre en charge jusqu'à 10 000 appareils enregistrés.
Considérations relatives à la conception des sites
Les sites regroupent les utilisateurs de Zoom Phone par emplacement pour des paramètres et politiques communs de téléphonie
Un site est un terme spécifique utilisé dans Zoom Phone qui regroupe les utilisateurs partageant des caractéristiques communes — comme un code d'accès commun, 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 seul site peut représenter tous les utilisateurs de leur entreprise et peut s'étendre sur plusieurs bâtiments au sein d'un campus ou d'un Emplacement ; pour d'autres, plusieurs sites peuvent être nécessaires selon les besoins de leur 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 à plusieurs sites
Il existe deux conceptions principales pour configurer les sites Zoom Phone dans un compte :
Site unique: Représentant tous les utilisateurs d'un compte, potentiellement répartis sur plusieurs bâtiments ou Emplacements, au sein d'un seul site Zoom Phone.
Multi-site: Représentant séparément des segments d'utilisateurs par emplacement, bâtiment, département ou fonction, chacun avec son propre site.
Chaque module ZPLS ne peut être associé qu'à un seul site à la fois
Comme mentionné précédemment, un module ZPLS est le serveur d'enregistrement de troisième priorité pour les appareils pris en charge, derrière les zones SIP principales et secondaires. Comme les appareils reçoivent leurs listes SRV pendant le processus de démarrage, et que ces listes sont liées au paramètre 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, ce qui étend les capacités de survivabilité de chaque site.
Les modules ZPLS prennent en charge les appels intersites si les modules sont connectés à un réseau commun
Les modules ZPLS de différents sites prennent en charge les appels intersites lors d'un événement de survivabilité tant que les appareils sont détectables sur le réseau local. Par exemple, si le campus d'une 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 sur le réseau du campus.
Avant de déployer ZPLS, les comptes doivent comprendre quelle configuration de site est la mieux adaptée à leurs besoins
Comme 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 meilleure 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 offre 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 permet de rationaliser la gestion des paramètres et des politiques de Zoom Phone en regroupant tous les utilisateurs d'un compte dans un seul groupe unifié. Ce groupe d'utilisateurs unique offre aux entreprises une administration simple et une complexité réduite, simplifiant ainsi le processus de gestion. De plus, une conception à site unique peut offrir la survivabilité téléphonique locale avec un seul module ZPLS, à condition que les utilisateurs du site ne dépassent pas les capacités d'un seul module.
Cependant, la simplicité d'une conception à site unique implique naturellement des limites. Plus précisément, les conceptions à site unique offrent moins de flexibilité en raison de leur caractère « taille unique », qui peut ne pas convenir à tous les scénarios de déploiement sur plusieurs départements ayant des besoins variables. En outre, les déploiements à site unique peuvent être vulnérables dans certains scénarios de survivabilité 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 nécessite un module ZPLS pour chaque site activé pour la survivabilité et est plus complexe à gérer
Une conception multi-site offre aux entreprises une flexibilité supplémentaire pour 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 de manière fine les configurations de communication afin de répondre à des exigences spécifiques sur divers sites, offrant ainsi une expérience utilisateur plus raffiné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 intersites 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 subtilités des exigences propres à chaque site, ce qui peut nécessiter un niveau d'effort administratif plus élevé. De plus, comme chaque module ZPLS ne peut être attribué qu'à un seul site à la fois, chaque site activé pour la survivabilité nécessitera un module ZPLS et une licence, ce qui peut contribuer à une configuration plus gourmande en ressources.
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 offrir une survivabilité téléphonique locale lors d'événements ayant un impact sur le service, la survivabilité peut être affectée si le réseau local d'un site tombe en panne. Ces scénarios sont détaillés dans les deux sections suivantes.
Panne du réseau local sur 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épendance à un réseau externe (par exemple, Internet) pour la communication entre bâtiments.
Avec cette conception de site, une entreprise peut offrir une survivabilité locale à tous les utilisateurs d'un seul site ou Emplacement 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 affectant la communication entre bâtiments. L'exemple suivant décrit comment une panne du 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 reliés par 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'un événement ayant un impact sur le service, tout utilisateur du site peut appeler un autre utilisateur 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 situé dans le 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 multi-bâtiments :
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, ce qui permet aux utilisateurs du même bâtiment de s'appeler lorsque le mode de survivabilité est activé. De plus, lorsque plusieurs sites dotés d'un module ZPLS sont connectés via un réseau commun, les utilisateurs peuvent appeler les utilisateurs des _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 affectant la communication entre 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 conserve 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 entre bâtiments.
Dans cet exemple, en cas de panne du service Internet externe, de panne du réseau de campus ou d'un événement ayant un impact sur 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 acheminer les appels intersites. Les utilisateurs seront alors limités à passer des appels aux autres utilisateurs 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é :
Bâtiment A (hôte ZPLS)
☑️ Bâtiments A, B et C
☑️ Bâtiment A
Bâtiment B (hôte ZPLS)
☑️ Bâtiments A, B et C
☑️ Bâtiment B
Bâtiment C (hôte ZPLS)
☑️ Bâtiments A, B et C
☑️ Bâtiment C
Si un réseau local tombe en panne, les appels intersites sont également pris en charge via le RTC, à condition que chaque site soit connecté à un SBC et que le renvoi d'appel soit activé
En cas de panne du réseau local, les Clients ayant une conception multi-site qui intègre le module ZPLS à un SBC et une connectivité RTC sur chaque site peuvent activer les appels de site à site si le renvoi d'appel est activé. Lorsqu'elle est configurée, les appels téléphoniques passés en mode survivabilité seront acheminés du client de l'utilisateur vers le RTC, puis vers le SBC et le module ZPLS du second site, pour finalement parvenir à l'appareil du destinataire. Le schéma suivant donne un aperçu de cette configuration :
Cette configuration nécessite 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 :
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 mette à jour autrement. Cela signifie que si un utilisateur se déplace vers un Emplacement physique en dehors de son site d'origine associé, comme un immeuble de bureaux associé à un site différent, Zoom n'ajustera pas dynamiquement le site lié à l'utilisateur. Par conséquent, si l'utilisateur perd la connectivité avec les centres de données Zoom Phone, il tentera de s'enregistrer auprès du module ZPLS associé à son site d'origine, même s'il se trouve dans un autre Emplacement.
Exemple :
Un utilisateur d'un campus multi-site est basé dans le bâtiment A (site A) et se déplace temporairement vers le bâtiment B (site B) pour une réunion. Alors qu'il se trouve dans le bâtiment B, un événement ayant un impact sur le service se produit et le mode de survivabilité est activé. Bien que l'utilisateur se trouve 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 son appareil 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 en panne pendant que l'utilisateur se trouve loin de son site d'origine, l'utilisateur ne peut pas bénéficier du module de survivabilité.
Mis à jour
Ce contenu vous a-t-il été utile ?