> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/fr/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md). # Considérations relatives au 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 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](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 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 : | | 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'enregistrements** | 2000 | 5000 | | **Nombre maximal d'appels simultanés** | 240 | 480 | | **Appels par seconde** | 2 | 4 | | **Enregistrements par seconde** | 60 | 400 | {% hint style="info" %} Si le nombre de terminaux dans un site activé pour la survivabilité dépasse les capacités de déploiement du site, le module ZPLS traitera les enregistrements selon le principe du premier arrivé, premier servi. Les Clients sont invités à ajouter des modules supplémentaires ou à 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 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. {% hint style="info" %} Cette fonctionnalité est actuellement en bêta et nécessite un ticket d'assistance technique pour être activée. {% endhint %} #### 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. {% hint style="success" %} **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. {% endhint %} ### 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](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### 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 : 1. **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. 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.
{% hint style="info" %} Les administrateurs de compte des Clients Zoom actuels peuvent vérifier leur conception de site actuelle 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 [serveur d'enregistrement de troisième priorité](#_7itj40mx1dut) 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. {% hint style="info" %} Cette fonctionnalité est actuellement en bêta et nécessite un ticket d'assistance technique pour être activée. {% endhint %} #### 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. {% hint style="info" %} Cette fonctionnalité est actuellement en bêta et nécessite un ticket d'assistance technique pour être activée. {% endhint %} #### 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](#_rx0i1j9xofnc). 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](#_gzpf5m70jl3i). #### 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](#_a42hwaw1pfmx) 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. {% hint style="info" %} 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 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 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.
{% 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, 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é. {% endhint %} Le tableau suivant illustre la survivabilité de Zoom Phone dans une conception à site unique multi-bâtiments : | Appels provenant du bâtiment | Peut atteindre ces emplacements lors d'une panne d'Internet externe | Peut 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, 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.
{% hint style="success" %} **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. {% endhint %} 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 | Peut atteindre ces emplacements lors d'une panne d'Internet externe | Peut 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â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é](#_2v7qst7vxwaa). 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 :
{% 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 illustre également la survivabilité de Zoom Phone dans une conception multi-site avec des SBC indépendants : | Appels provenant du bâtiment | Peut atteindre ces emplacements lors d'une panne d'Internet externe | Peut 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 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. {% hint style="success" %} **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é. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` 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=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.