# Considérations sur le déploiement du matériel 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, afin de garantir 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](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Vous trouverez plus d’informations sur Zoom Node en tant que produit [dans l’annexe](#_a2lvsihjp0ek). #### Les Clients peuvent choisir l’une des deux options de configuration, selon les capacités du matériel 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 : | | 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

| | **Nombre total d’inscriptions** | 2000 | 5000 | | **Nombre maximal d’appels simultanés** | 240 | 480 | | **Appels par seconde** | 2 | 4 | | **Inscriptions par seconde** | 60 | 400 | {% hint style="info" %} 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 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**](#_ah8xua8wdq10) pour prioriser les utilisateurs qui prennent en charge le basculement de survivabilité. {% endhint %} ### 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 des 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. {% hint style="info" %} Cette Fonctionnalités est actuellement en version bêta et nécessite un ticket d’assistance pour être activée. {% endhint %} #### La mise à l’échelle augmente les capacités des appareils pris 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 ne met pas à l’échelle les capacités des 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 « hot standby » et ne s’activeront que si les modules principaux échouent. Par exemple, un module principal et un module redondant prennent en charge un total de 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 Pour plus de commodité, l’exemple suivant montre un déploiement avec mise à l’échelle et redondance supplémentaires. {% hint style="success" %} **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 5 000 inscriptions chacun, ce qui donne une capacité totale pouvant atteindre 10 000 inscriptions. 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 d’un matériel de survivabilité principal et secondaire déployé. Désormais, si un module principal tombe en 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. {% endhint %} ### Considérations relatives à la conception du site #### Les sites regroupent les utilisateurs Zoom Phone par emplacement pour les Paramètres et politiques de téléphonie communs Un **site** est un terme spécifique utilisé dans Zoom Phone qui regroupe les utilisateurs présentant des caractéristiques communes — comme un code d’accès, une adresse, une zone SIP, un département ou des politiques communs — au sein d’un groupe unique et 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 au sein d’un campus ou d’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](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### Zoom Phone prend en charge des 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 potentiellement couvrir 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.
{% hint style="info" %} Les administrateur de compte des clients Zoom actuels peuvent vérifier la conception actuelle de leur site via la [**Informations sur l’entreprise**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) page, disponible dans le **Gestion du système de téléphonie** menu du portail Web. {% endhint %} #### 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é](#_7itj40mx1dut) pour les appareils pris en charge, derrière les zones SIP principale et secondaire. Étant donné que les appareils reçoivent leurs listes SRV pendant le processus de démarrage, et que ces listes sont liées au 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 seul groupe, ce qui étend les capacités de survivabilité de chaque site. {% hint style="info" %} Cette Fonctionnalités est actuellement en version bêta et nécessite un ticket d’assistance pour être activée. {% endhint %} #### Les modules ZPLS prennent en charge les appels entre sites si les modules sont connectés à un réseau commun Les modules ZPLS de différents sites prennent en charge les appels entre sites pendant un événement de survivabilité, à condition que les appareils soient 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 connecter des appels de site à site sur le réseau du campus. {% hint style="info" %} Cette Fonctionnalités est actuellement en version bêta et nécessite un ticket d’assistance pour être activée. {% endhint %} #### Avant de déployer ZPLS, les comptes doivent déterminer 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 professionnels 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 contribue à rationaliser la gestion des Paramètres et politiques 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, ce qui simplifie 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 seul module](#_rx0i1j9xofnc). 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 survie si le [réseau local tombe en panne](#_gzpf5m70jl3i). #### Une conception multi-sites 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 complexe à gérer Une conception multi-sites 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 de manière détaillée les configurations de communication afin de répondre à des exigences spécifiques sur divers sites, ce qui se traduit par une expérience utilisateur plus raffinée et adaptable pour différents départements, scénarios ou besoins. De plus, les déploiements multi-sites peuvent prendre en charge [la communication entre sites](#_a42hwaw1pfmx) si les sites sont connectés par un réseau commun. Cependant, la gestion d’une conception multi-sites exige une attention particulière aux subtilités des besoins 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. {% hint style="info" %} Dans une conception multi-sites, les Clients ont la flexibilité de choisir quels sites seront configurés pour la survivabilité. Les sites *sans* un module ZPLS restera incapable de passer ou de recevoir des appels jusqu’à ce que la connectivité standard soit rétablie. {% endhint %} ### 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 assurer 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 relié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 ex., 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 aussi peu qu’un seul module ZPLS ; toutefois, cette conception est vulnérable en cas de panne du réseau local ou de campus qui affecte la communication entre bâtiments. L’exemple suivant décrit comment une panne du réseau local peut affecter un déploiement à site unique.
{% hint style="success" %} **Exemple :** Une entreprise déploie le module ZPLS pour un seul site Zoom Phone, composé des bâtiments A, B et C, 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’événement ayant un impact sur le service, tout utilisateur situé dans le site peut appeler un autre utilisateur du *même* site, tant que les deux utilisateurs conservent la connectivité au module ZPLS via le réseau du 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 du campus soit rétabli pour pouvoir appeler en mode survivabilité. {% endhint %} Le tableau suivant montre la survivabilité Zoom Phone dans une conception à site unique multi-bâtiments : | Les appels provenant du bâtiment | Peuvent atteindre ces emplacements lors d’une panne Internet externe | Peuvent atteindre 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é 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 par 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 les uns les autres lorsque le mode de survivabilité est activé. De plus, lorsque plusieurs sites équipés 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 entre bâtiments. L’exemple suivant décrit comment une panne du réseau de campus peut affecter un déploiement multi-sites.
{% hint style="success" %} **Exemple :** Une entreprise déploie le module ZPLS sur 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 entre bâtiments. Dans cet exemple, en cas de panne du service Internet externe, de panne du réseau du campus ou d’é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 sur les modules spécifiques à leur site, si le réseau du campus tombe en panne, les modules ZPLS ne peuvent pas acheminer les appels inter-sites. À la place, les utilisateurs seront limités à passer des appels à d’autres utilisateurs de leur site local. {% endhint %} Le tableau suivant montre la survivabilité Zoom Phone de l’exemple ci-dessus dans une conception multi-sites avec un réseau de campus interconnecté : | Les appels provenant du bâtiment | Peuvent atteindre ces emplacements lors d’une panne Internet externe | Peuvent atteindre 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 entre sites 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 disposant d’une conception multi-sites 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é](#_2v7qst7vxwaa). Lorsqu’elle est configurée, la route des appels téléphoniques passés en mode survivabilité va du client de l’utilisateur au RTC, puis au SBC et au module ZPLS du deuxième site, pour finalement aboutir à l’appareil du destinataire. Le schéma suivant fournit un aperçu de cette configuration :
{% hint style="danger" %} Cette configuration **nécessite** le traitement des numéros de téléphone E.164 sur les SBC configurés. {% endhint %} Le tableau suivant montre également la survivabilité Zoom Phone dans une conception multi-sites avec des SBC indépendants : | Les appels provenant du bâtiment | Peuvent atteindre ces emplacements lors d’une panne Internet externe | Peuvent atteindre 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 sur le 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 sur le module ZPLS associé à son site d’origine, même s’il se trouve à un autre endroit. {% hint style="success" %} **Exemple :** Un utilisateur dans 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 sur le module ZPLS de son site d’origine à travers le réseau du campus. Si le réseau du campus est en panne alors que l’utilisateur est éloigné de son site d’origine, l’utilisateur ne peut pas bénéficier du module de survivabilité. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://library.zoom.com/technical-library/fr/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.