Considérations sur le 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 à l’aide d’hyperviseurs pris en charge. Elle fournit des options de configuration détaillées adaptées aux 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, en fonction des capacités matérielles

Le module ZPLS prend en charge deux configurations, en fonction des capacités matérielles de la machine virtuelle. Ces capacités sont indiqué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	16 CPU 16 Go de RAM 80 Go de disque dur
Nombre total d’inscriptions	2000	5000
Nombre maximal d’appels simultanés	240	480
Appels par seconde	2	4
Inscriptions par seconde	60	400

Si le nombre de terminaux dans un site avec survivabilité activée dépasse les capacités de déploiement d’un site, le module ZPLS traitera les inscriptions 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 politique Zoom Phone Mode de survivabilité locale 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 mise à l’échelle et/ou une résilience supplémentaires

Les clients peuvent regrouper les modules ZPLS avec 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 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 un total de 5 000 inscriptions, le déploiement de cinq modules portera 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’activeront que si les modules principaux tombent en panne. Par exemple, un module principal et un module redondant prennent en charge un total de 5 000 inscriptions, donc 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

Pour plus 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 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, soit 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 d’un matériel de survivabilité principal et secondaire déployé. Désormais, si un module principal subit une panne, 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 Zoom Phone par emplacement pour les paramètres et stratégies de téléphonie 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, une adresse, une zone SIP, un département ou des stratégies communes — 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 couvrir plusieurs bâtiments dans un campus ou un emplacement ; pour d’autres, plusieurs sites peuvent être nécessaires selon les 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 les conceptions à site unique et multi-sites

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

1. Site unique: Représente 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-sites: Représente 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 la conception de leur site actuelle via la page Infos sur l’entreprise , disponible dans le menu Gestion du système téléphonique 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 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 seul groupe, ce qui étend les capacités de survivabilité de chaque site.

Cette fonctionnalité est actuellement en version bêta et nécessite 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 établir des appels d’un site à l’autre sur le réseau de zone du campus.

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

Avant de déployer ZPLS, les comptes doivent comprendre quelle configuration de site est la mieux adaptée à 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 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 stratégies des utilisateurs

Une conception à site unique aide à rationaliser la gestion des paramètres et stratégies Zoom Phone en regroupant tous les utilisateurs d’un compte au sein d’un groupe unique et unifié. Ce groupe unique d’utilisateurs 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, tant que les utilisateurs du site ne dépassent pas les capacités d’un seul module.

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 dans plusieurs départements aux besoins variés. 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-sites offre plus de flexibilité pour les paramètres et stratégies des utilisateurs, mais nécessite un module ZPLS pour chaque site avec survivabilité activée et est plus complexe à gérer

Une conception multi-sites offre aux entreprises une flexibilité supplémentaire dans les paramètres et stratégies des utilisateurs en séparant les utilisateurs en plusieurs groupes avec des contrôles de paramètres granulaires. Cette conception permet aux organisations d’ajuster de manière détaillée les configurations de communication pour répondre à des exigences spécifiques sur divers sites, ce qui se traduit par une expérience utilisateur plus raffinée et adaptable pour divers départements, scénarios ou besoins. De plus, les déploiements multi-sites 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-sites exige une attention particulière aux spécificité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 avec survivabilité activée nécessitera un module ZPLS et une licence, ce qui peut contribuer à une configuration plus gourmande en ressources.

Dans une conception multi-sites, les clients ont la flexibilité de choisir quels sites seront configurés pour la survivabilité. Les sites sans module ZPLS resteront incapables de passer 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 offrir la 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écrits dans les deux sections suivantes.

Panne du réseau local à site unique

Dans une conception à site unique, un ou plusieurs bâtiments sont connectés via un réseau local ou un réseau de zone 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 de réseau externe (par exemple, Internet) pour la communication entre les bâtiments.

Avec cette conception de site, une entreprise peut fournir une survivabilité locale à tous les utilisateurs d’un seul site ou emplacement avec aussi peu qu’un seul 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 les 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 par un réseau de zone de campus. Le module ZPLS fonctionne dans le bâtiment A et n’est pas connecté à un SBC pour les appels externes via le RTC.

En cas de défaillance du service Internet externe ou d’un événement ayant un impact sur le service, tout utilisateur inclus dans le site peut appeler un autre utilisateur du même site, tant que les deux utilisateurs maintiennent la connectivité avec le module ZPLS via le réseau de zone du campus.

Cependant, en cas de panne du réseau de zone du 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 que le réseau de zone du campus soit rétabli pour les appels de survivabilité.

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

Appels provenant du bâtiment	Peuvent joindre ces emplacements lors d’une panne Internet externe	Peuvent joindre ces emplacements lors d’une panne du réseau du 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-sites sans SBC

Dans une conception multi-sites, 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 zone 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 entre eux 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 dans 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 zone du campus affectant la communication entre les bâtiments. L’exemple suivant décrit comment une panne du réseau du campus peut affecter un déploiement multi-sites.

Exemple :

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

Dans cet exemple, en cas de défaillance du service Internet externe, de panne du réseau du 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 du campus tombe en panne, les modules ZPLS ne peuvent pas transporter les appels inter-sites. À la place, les utilisateurs seront limités à passer des appels à d’autres utilisateurs de leur site local.

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

Appels provenant du bâtiment	Peuvent joindre ces emplacements lors d’une panne Internet externe	Peuvent joindre ces emplacements lors d’une panne du réseau du campus
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 inter-sites sont également pris en charge via le RTC, à condition que chaque site soit connecté à un SBC et que le transfert d’appel soit activé

En cas de panne du réseau local, les clients disposant d’une conception multi-sites qui intègre le module ZPLS à un SBC et une connectivité RTC à chaque site peuvent activer les appels de site à site si le transfert d’appel est activé. Une fois configurés, les appels téléphoniques passés pendant le mode de survivabilité seront acheminés du client de l’utilisateur vers le RTC, puis vers le SBC du deuxième site et le module ZPLS, 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 montre également la survivabilité Zoom Phone dans une conception multi-sites avec des SBC indépendants :

Appels provenant du bâtiment	Peuvent joindre ces emplacements lors d’une panne Internet externe	Peuvent joindre ces emplacements lors d’une panne du réseau du 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é de manière statique à l’utilisateur ou à l’appareil jusqu’à ce qu’un administrateur de compte le mette à jour. 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 autre site, 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-sites 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. Pendant 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 l’appareil de l’utilisateur à s’enregistrer auprès du module ZPLS de son site d’origine à travers le réseau de zone du campus. Si le réseau de zone du campus est en panne pendant que l’utilisateur est absent de son site d’origine, l’utilisateur ne peut pas bénéficier du module de survivabilité.