> 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/services-avances-pour-entreprise/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Considérations relatives au déploiement de Zoom Node Cette section contient plusieurs exemples de la manière dont Zoom Node peut prendre en charge divers modules de service comme Zoom Meetings Hybrid et Zoom Phone Local Survivability (ZPLS). Les déploiements typiques avec une adresse IP dédiée peuvent ressembler à la collection de schémas suivante. Chaque service déployé sur Zoom Node nécessite une adresse IP unique. Un Zoom Node disposera d’au plus cinq (5) adresses IP qui lui sont attribuées si le Node s’est vu attribuer une adresse spécifique pour la gestion et une pour chaque service déployé (jusqu’à quatre) sur le Node. Un Zoom Node exécutant un seul service (comme ZPLS) peut être déployé avec une seule adresse IP si le Node et le service sont configurés pour partager la même adresse IP. Plusieurs options de déploiement sont présentées ci-dessous. Notez le nombre d’adresses IP et de certificats (CN/SAN) pour les différentes options de déploiement. ### Option 1 : Zoom Meetings Hybrid déployé avec des adresses IP dédiées et des noms d’hôte
L’image ci-dessus résume les exigences de configuration des adresses IP et des certificats pour le déploiement de **Zoom Meetings Hybrid** dans des environnements sur site ou de cloud hybride. Le tableau ci-dessous détaille le Node d’exemple et inclut son proxy actif et ses modules de service MMR : | Composant | Nom d’hôte | Rôle du certificat TLS | Fonction | | ------------------------------ | -------------------- | ----------------------------- | ------------------------------------ | | SYSTÈME D'EXPLOITATION du Node | `node1.customer.com` | Nom commun (CN) | Orchestration principale | | Proxy du Connecteur Zoom | `zcp1.customer.com` | Nom alternatif du sujet (SAN) | Signalisation et contrôle de session | | Routeur de module média 1 | `mmr1.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement des médias | | Routeur de module média 2 | `mmr2.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement des médias | | Routeur de module média 3 | `mmr3.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement des médias | {% hint style="info" %} Vous devez attribuer à chaque module une adresse IP statique dédiée. Nombre total d’adresses IP requises : cinq (5) {% endhint %}
L’image ci-dessus présente la configuration minimale requise pour déployer **Résilience locale de Zoom Phone (ZPLS)**. ZPLS permet de maintenir la disponibilité du service téléphonique en cas d’interruption d’Internet ou du cloud en exécutant localement la logique de survivabilité sur une machine virtuelle Zoom Node. Les noms d’hôte suivants doivent être configurés dans le DNS et inclus dans le certificat TLS : * `node1.customer.com` * `zplsl.customer.com` **Mappage fonctionnel des noms d’hôte** | Composant | Nom d’hôte | Rôle du certificat TLS | Fonction | | ------------------------------ | -------------------- | ----------------------- | --------------------------------------------- | | SYSTÈME D'EXPLOITATION du Node | `node1.customer.com` | Nom commun (CN) | Orchestration principale | | Module ZPLS | `zplsl.customer.com` | Nom alternatif du sujet | logique de survivabilité locale de Zoom Phone | **Configuration du certificat TLS** | Champ | Valeur | | ------------------------- | -------------------- | | Nom commun (CN) | `node1.customer.com` | | Noms alternatifs du sujet | `zplsl.customer.com` | Les certificats doivent être générés ou obtenus (AC publique ou privée) afin d’inclure à la fois le CN et les SAN répertoriés ci-dessus. Cela permet une validation TLS appropriée pour une communication sécurisée entre modules. **Exigences relatives aux adresses IP** | Indicateur | Valeur / Description | | ----------------------------------- | ------------------------------------------------------------------------------- | | Nombre total d’adresses IP requises | 5 (allocation générale) | | Utilisé dans le contexte ZPLS | 2 adresses IP (1 pour le SYSTÈME D'EXPLOITATION du Node, 1 pour le module ZPLS) | Bien que cinq (5) adresses IP soient requises pour le déploiement général, **seules deux (2) adresses IP sont effectivement utilisées** dans le déploiement ZPLS : une par module, exécutée sur une **machine virtuelle Node dédiée**. {% hint style="warning" %} ZPLS n’autorise qu’un seul module par machine virtuelle Node. Vous ne pouvez pas co-localiser ZPLS avec d’autres modules Zoom sur la même VM. {% endhint %} En quoi ces schémas diffèrent-ils ? La première image montre un exemple de déploiement Zoom Meetings Hybrid. La deuxième image montre un exemple de déploiement Zoom Phone Local Survivability. Vous pouvez partager la première adresse IP/nom d’hôte entre le SYSTÈME D'EXPLOITATION et le premier module, si vous le souhaitez, afin de réduire le nombre d’adresses IP, de noms d’hôte et de Noms alternatifs du sujet (SAN) requis. ### Option 2 : Zoom Meetings Hybrid déployé avec une adresse IP partagée et un nom d’hôte partagé
Cette configuration reprend la structure du Node telle qu’elle apparaît dans le schéma Zoom Meetings Hybrid de l’option 1. Cependant, dans ce déploiement, le **SYSTÈME D'EXPLOITATION du Node partage son adresse IP avec le premier module déployé** (généralement le Proxy du Connecteur Zoom, ZCP). Cela réduit l’utilisation des adresses IP tout en respectant les exigences TLS et fonctionnelles. Les noms d’hôte suivants doivent être configurés dans le DNS et inclus dans le certificat TLS : * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Mappage fonctionnel des noms d’hôte** | Composant | Nom d’hôte | Rôle du certificat TLS | Fonction | | ------------------------------ | ------------------- | ----------------------------- | ------------------------------------ | | ZCP (Proxy du Connecteur Zoom) | `zcp1.customer.com` | Nom commun (CN) | Signalisation et contrôle de session | | Routeur de module média 1 | `mmr1.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement des médias | | Routeur de module média 2 | `mmr2.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement des médias | | Routeur de module média 3 | `mmr3.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement des médias | **Configuration du certificat TLS** | Champ | Valeur | | ------------------------- | ------------------------------------------------------------- | | Nom commun (CN) | `zcp1.customer.com` | | Noms alternatifs du sujet | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | Les certificats doivent inclure tous les SAN pour prendre en charge une communication TLS sécurisée entre Zoom Node et les modules Zoom installés. **Exigences relatives aux adresses IP** | Indicateur | Valeur / Description | | --------------------------------------- | -------------------------------------------------------------------------------- | | Nombre total d’adresses IP requises | 4 | | Stratégie de partage des adresses IP | SYSTÈME D'EXPLOITATION du Node partage l’adresse IP avec le premier module (ZCP) | | Adresses IP individuelles requises pour | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Lorsque l’adresse IP est **partagée** entre le SYSTÈME D'EXPLOITATION du Node et le premier module déployé (ZCP), seules **quatre (4) adresses IP** sont requises. Cette conception optimise l’utilisation des adresses IP tout en respectant les normes de déploiement. {% endhint %}
L’image ci-dessus montre un déploiement ZPLS minimal dans lequel le **SYSTÈME D'EXPLOITATION du Node partage son adresse IP avec le module ZPLS installé**. C’est le **seul scénario** dans le cadre Zoom Node où un **certificat TLS à hôte unique** est valide. Le nom d’hôte suivant doit être configuré dans le DNS et inclus dans le certificat TLS : * `zplsl.customer.com` **Mappage fonctionnel des noms d’hôte** | Composant | Nom d’hôte | Rôle du certificat TLS | Fonction | | ----------- | -------------------- | ---------------------- | --------------------------------------------- | | Module ZPLS | `zplsl.customer.com` | Nom commun (CN) | logique de survivabilité locale de Zoom Phone | **Configuration du certificat TLS** | Champ | Valeur | | --------------- | ------------------- | | Nom commun (CN) | `zcp1.customer.com` | | SAN | (non requis) | Dans cette configuration, un certificat à hôte unique suffit, car le système d’exploitation et le module ZPLS partagent le même nom d’hôte et la même adresse IP. **Exigences relatives aux adresses IP** | Indicateur | Valeur / Description | | ------------------------------------ | ------------------------------------------------------------------------ | | Nombre total d’adresses IP requises | 1 | | Stratégie de partage des adresses IP | Le SYSTÈME D'EXPLOITATION du Node et ZPLS partagent une seule adresse IP | | Contrainte de déploiement | Un seul module autorisé par machine virtuelle Node (ZPLS uniquement) | {% hint style="warning" %} ZPLS est le seul scénario pris en charge dans l’architecture Zoom Node où : * Un certificat à hôte unique (CN uniquement) est acceptable * Une seule adresse IP (1) est requise pour le déploiement en raison du partage d’adresse IP entre le système d’exploitation et le module * La co-localisation de modules supplémentaires sur la même VM n’est pas prise en charge {% endhint %} ### Choisissez la méthode de gestion des certificats qui convient le mieux à vos déploiements Chaque module de service déployé sur Zoom Node nécessite un certificat valide signé par une autorité de certification (AC) de confiance publique figurant dans la liste de confiance des certificats de Zoom Node. Cela inclut les autorités publiques bien connues. Zoom Node propose deux méthodes de gestion des certificats : * **Auto PKI**: Cette solution innovante automatise l’inscription sécurisée des certificats et leur renouvellement auprès d’autorités de certification (AC) de confiance publique. Zoom prend en charge les coûts associés à l’inscription et au renouvellement. * **Apportez votre propre certificat (BYOC)**: Avec cette option, vous fournissez vos propres certificats, signés par n’importe quelle grande AC de confiance publique. Vous gérez l’inscription des certificats et les renouvellements. Des considérations supplémentaires s’appliquent concernant la possibilité pour Zoom Node d’utiliser jusqu’à cinq noms d’hôte/SAN lorsque des certificats fournis par le client sont utilisés, comme détaillé plus loin ci-dessous. #### Gestion automatique des certificats avec Auto PKI Zoom Auto PKI installe automatiquement des certificats CA valides de confiance publique pour la plateforme Zoom Node, ainsi que pour tous les modules déployés dessus. Le renouvellement des certificats est également géré automatiquement. Cela simplifie la gestion des certificats pour tous les services et pour Zoom Node lui-même. #### Comprendre l’inscription et le renouvellement des certificats Auto PKI Le scénario suivant peut vous aider à comprendre comment fonctionnent l’inscription et le renouvellement des certificats. Par exemple : un administrateur a déployé une nouvelle instance de Node. Chaque instance nécessite un certificat x509 valide. **La clé privée du certificat ne doit jamais quitter cette instance**. Le processus Auto PKI effectue les étapes suivantes : 1. **Récupération du modèle**: Récupère tous les modèles de configuration pris en charge, y compris les options pour plusieurs fournisseurs d’AC, depuis le service Auto PKI dans le cloud Zoom. 2. **Collecte des adresses IP**: Regroupe toutes les adresses IP utilisées par les services exécutés sur le Node et les envoie au service Auto PKI dans le cloud Zoom. 3. **Provisionnement des noms DNS**: Le service cloud Auto PKI renvoie un ensemble de noms DNS au format `..zoomonprem.com`. Ces domaines sont configurés avec des enregistrements A/AAAA. 4. **Demande de nom DNS réservé**: Demande un nom DNS réservé au format `rsvd-..zoomonprem.com`. 5. **Génération de la demande de certificat**: Génère une demande de certificat x509, en utilisant les noms DNS de la troisième étape dans le champ SAN et le nom réservé de la quatrième étape dans le champ Nom commun (CN). 6. **Délivrance du certificat**: Envoie la demande de signature de certificat (CSR) au service Auto PKI dans le cloud Zoom. Ce service collabore ensuite avec des fournisseurs d’AC pour délivrer le certificat, qui inclut la liste SAN et le champ CN de l’étape précédente. 7. **Stockage local**: Écrit dans le stockage local le certificat x509 nouvellement délivré de l’étape précédente et sa clé privée correspondante (générée plus tôt), les rendant disponibles pour les services exécutés sur l’instance de Node. Auto PKI simplifie la gestion des certificats sur Zoom Node en surveillant automatiquement les dates d’expiration et en demandant de nouveaux certificats, ce qui élimine le besoin d’un renouvellement manuel. #### Apportez vos propres certificats (BYOC) Vous pouvez installer vos propres certificats valides, signés publiquement, sur Zoom Node à l’aide de l’interface Web locale. Vous pouvez le faire lors de l’installation initiale ou ultérieurement. Le processus sera familier à ceux qui ont l’habitude d’installer des certificats sur des applications Web. Si vous choisissez d’utiliser vos propres certificats, n’oubliez pas que le certificat se trouvera sur un serveur communiquant avec plusieurs noms d’hôte. Par conséquent, le type de certificat que vous choisissez doit prendre en charge le chiffrement du trafic provenant de plus d’un nom d’hôte (CN du certificat). Tous les noms d’hôte utilisés pour le Node et tous les services déployés doivent être résolvables publiquement par les services cloud de Zoom. Zoom recommande deux types de certificats : * **Certificat wildcard** * **Certificat Multi-SAN** (également appelé certificat multi-domaine, certificat SAN ou certificat UCC) {% hint style="danger" %} Un certificat typique à hôte unique ne fonctionnera pas avec Zoom Node, sauf dans le scénario spécifique où une seule adresse IP et un seul nom d’hôte sont partagés entre Zoom Node et un seul module. Pour plus de contexte, consultez le schéma ZPLS dans le [#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname](#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname "mention") section. {% endhint %} **Certificats wildcard : recommandés pour leur simplicité** Un certificat wildcard peut chiffrer le trafic provenant de n’importe quel nom d’hôte du domaine. Par exemple : un certificat wildcard comme \*.customer.com peut chiffrer le trafic provenant de `host1.customer.com` et `host2.customer.com` ou de n’importe quel nom dans `.customer.com`. Lorsque vous déployez Zoom Node et installez le certificat wildcard, il chiffrera automatiquement le trafic de tous les services que vous déployez sur le Node, à condition que tous les services déployés utilisent un nom de domaine pleinement qualifié (FQDN) provenant du domaine wildcard. Cela minimise l’effort nécessaire pour déployer des services sur le Node : vous n’avez pas besoin de connaître les noms des services avant de les déployer. En revanche, vous devez connaître les noms des services si vous utilisez la méthode du certificat multi-SAN. **Certificats Multi-SAN, multi-domaine, SAN ou UCC** {% hint style="warning" %} Vous devez connaître les noms d’hôte et les adresses IP que vous utiliserez pour le Node (jusqu’à un \[1]) et pour tout service que vous installerez (jusqu’à quatre \[4]). **Ces informations sont requises avant l’inscription d’un certificat**. {% endhint %} Un certificat Multi-SAN est nécessaire pour Zoom Node car il chiffre le trafic provenant de cinq (5) noms d’hôte. Une demande unique pour ce certificat nécessite de connaître à l’avance toutes les informations nécessaires, y compris les noms de Node prévus et les noms de tous les services destinés à être déployés sur le Node. Par exemple, avec un module comme ZPLS, un seul module ZPLS est déployé par Node, donc un seul SAN supplémentaire est nécessaire pour le nom d’hôte du service ZPLS. Le tableau suivant peut servir d’exemple : | Nom d’hôte (SAN) | adresse IP | | ------------------------------------------ | ------------- | | `zoom-node01.company.com` | `10.1.50.100` | | `zpls.company.com` | `10.1.50.100` | | `zoom-recording.company.com` | `10.1.50.101` | | `zoom-webinaire.company.com` | `10.1.50.102` | | (Service 4 - non utilisé dans cet exemple) | (sans objet) | Cet exemple présente une configuration typique, avec un Node hébergeant ZPLS sur la même adresse IP et deux services supplémentaires sur des adresses IP séparées. Remplacez « company.com » par votre domaine réel et utilisez les adresses IP de votre réseau. **Exigences de résolution DNS** Zoom exige que les noms d’hôte soient résolvables publiquement afin qu’une confiance mutuelle puisse être établie. Tous les noms d’hôte Zoom Node et tous les noms d’hôte des services déployés sur les Nodes doivent être inclus dans la zone DNS. Si votre organisation utilise des services ou des domaines DNS internes et externes distincts, les noms d’hôte Zoom Node doivent être hébergés dans une zone résolvable par vos serveurs DNS externes (et la résolution peut être limitée aux plages d’adresses IP Zoom). Vos utilisateurs Zoom internes et le cloud Zoom doivent communiquer en utilisant le même ensemble de noms d’hôte. --- # 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/services-avances-pour-entreprise/zoom-node/zoom-node-deployment-field-guide/zoom-node-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.