> 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-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). Des 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 aura jusqu’à cinq (5) adresses IP qui lui sont attribuées si le nœud s’est vu attribuer une adresse spécifique pour la gestion et une pour chaque service déployé (jusqu’à quatre) sur le nœud. Un Zoom Node exécutant un seul service (tel que ZPLS) peut être déployé avec une seule adresse IP si le nœud 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’IP et de certificats (CN/SAN) pour les différentes options de déploiement. ### Option 1 : Zoom Meetings Hybrid déployé avec des IP et des noms d’hôte dédiés
L’image ci-dessus résume les exigences de configuration IP et de certificat pour le déploiement de **Zoom Meetings Hybrid** dans des environnements sur site ou cloud hybrides. Le tableau ci-dessous détaille l’exemple de nœud et inclut ses modules de service proxy actif et MMR : | Composant | Nom d’hôte | Rôle du certificat TLS | Fonction | | ------------------------------ | -------------------- | ----------------------------- | ------------------------------------ | | SYSTÈME D'EXPLOITATION du nœud | `node1.customer.com` | Nom commun (CN) | Orchestration principale | | Proxy 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 nécessaire 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 la logique de survivabilité localement sur une VM 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 nœud | `node1.customer.com` | Nom commun (CN) | Orchestration principale | | Module ZPLS | `zplsl.customer.com` | Nom alternatif du sujet | Logique de Zoom Phone Local Survivability | **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 correcte pour une communication intra-module sécurisée. **Exigences relatives aux adresses IP** | Métrique | 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 nœud, 1 pour le module ZPLS) | Bien que cinq (5) IP soient requises pour le déploiement général, **seules deux (2) adresses IP sont activement utilisées** dans le déploiement ZPLS : une par module, s’exécutant sur une **VM de nœud dédiée**. {% hint style="warning" %} ZPLS n’autorise qu’un seul module par VM de nœud. Vous ne pouvez pas co-localiser ZPLS avec d’autres modules Zoom sur la même VM. {% endhint %} Comment ces diagrammes se comparent-ils ? La première image montre un exemple de déploiement hybride Zoom Meetings. 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 de 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 répète la structure du nœud telle qu’elle apparaît dans le diagramme Zoom Meetings Hybrid de l’option 1. Cependant, dans ce déploiement, le **Le SYSTÈME D'EXPLOITATION du nœud partage son adresse IP avec le premier module déployé** (généralement le Zoom Connecteur Proxy, ZCP). Cela permet de réduire l’utilisation des adresses IP tout en conservant 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 (Zoom Connecteur Proxy) | `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 afin de prendre en charge une communication TLS sécurisée entre le Zoom Node et les modules Zoom installés. **Exigences relatives aux adresses IP** | Métrique | Valeur / Description | | --------------------------------------- | ----------------------------------------------------------------------------------- | | Nombre total d’adresses IP requises | 4 | | Stratégie de partage d'adresse IP | Le SYSTÈME D'EXPLOITATION du nœud 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 nœud 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 **Le SYSTÈME D'EXPLOITATION du nœud partage son adresse IP avec le module ZPLS installé**. Il s'agit du **seul scénario** dans le framework 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 Zoom Phone Local Survivability | **Configuration du certificat TLS** | Champ | Valeur | | --------------- | ------------------- | | Nom commun (CN) | `zcp1.customer.com` | | SANs | (non requis) | Dans cette configuration, un certificat à hôte unique est suffisant puisque le SYSTÈME D'EXPLOITATION et le module ZPLS partagent tous deux le même nom d'hôte et la même adresse IP. **Exigences relatives aux adresses IP** | Métrique | Valeur / Description | | ----------------------------------- | ------------------------------------------------------------------------ | | Nombre total d’adresses IP requises | 1 | | Stratégie de partage d'adresse IP | Le SYSTÈME D'EXPLOITATION du Node et ZPLS partagent une seule adresse IP | | Contrainte de déploiement | Un seul module autorisé par VM 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 de l’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 %} ### Décidez quelle méthode de gestion des certificats 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 (CA) de confiance publique figurant dans la liste de confiance des certificats de Zoom Node. Cela inclut des autorités publiques bien connues. Zoom Node propose deux méthodes de gestion des certificats : * **PKI automatique**: Cette solution innovante automatise l’inscription et le renouvellement sécurisés des certificat auprès d’autorités de certification (CA) reconnues par le public. Zoom couvre 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 toute grande CA reconnue par le public. Vous gérez l’inscription et les renouvellements des certificat. Des considérations supplémentaires s’appliquent concernant le potentiel de Zoom Node pour jusqu’à cinq noms d’hôte/SAN lors de l’utilisation de certificats fournis par le client, qui sont décrites plus en détail ci-dessous. #### Gestion automatique des certificat avec PKI automatique Zoom Auto PKI installe automatiquement des certificats CA valides et reconnus par le public pour la plateforme Zoom Node, ainsi que pour tous les modules qui y sont déployés. Le renouvellement des certificat est également géré automatiquement. Cela simplifie la gestion des certificat pour tous les services ainsi que pour Zoom Node lui-même. #### Comprendre l’inscription et le renouvellement des certificat Auto PKI Le scénario suivant peut vous aider à comprendre comment fonctionnent l’inscription et le renouvellement des certificat. Par exemple : un administrateur a déployé une nouvelle instance de nœud. 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**: extrait tous les modèles de configuration pris en charge, y compris les options pour plusieurs fournisseurs de CA, depuis le service Auto PKI dans le cloud Zoom. 2. **Collecte des adresses IP**: collecte toutes les adresses IP utilisées par les services exécutés sur le nœud et les envoie au service Auto PKI dans le cloud Zoom. 3. **Provisionnement des noms DNS**: le service Auto PKI cloud 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 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 travaille ensuite avec les fournisseurs de CA pour délivrer le certificat, qui inclut la liste SAN et le champ CN de l’étape précédente. 7. **Stockage local**: Écrit le nouveau certificat x509 délivré à l’étape précédente et sa clé privée correspondante (générée plus tôt) dans le stockage local, les rendant disponibles pour les services exécutés sur l’instance Node. Auto PKI simplifie la gestion des certificats sur Zoom Node en surveillant automatiquement les dates d’expiration et en demandant de nouveaux certificats, éliminant ainsi le besoin de 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 soit pendant l’installation initiale, soit 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 Node et tous les services déployés doivent être résolus publiquement par les services cloud de Zoom. Zoom recommande deux types de certificats : * **Certificat wildcard** * **Certificat Multi-SAN** (également appelé certificat Multi-Domain, certificat SAN ou certificat UCC) {% hint style="danger" %} Un certificat classique pour un seul hôte ne fonctionnera pas avec Zoom Node, sauf dans le cas 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 diagramme 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") . {% 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 tout autre nom dans `.customer.com`. Lorsque vous déployez Zoom Node et installez le certificat générique, il chiffrera automatiquement le trafic pour 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) issu du domaine générique. Cela նվազimise 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. Toutefois, vous devez connaître les noms des services si vous utilisez la méthode de 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]) ainsi que tous les Services que vous installerez (jusqu'à quatre \[4]). **Ces informations sont requises avant l'enregistrement 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 au déploiement 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 être utilisé comme 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) | (N/A) | Cet exemple est une configuration typique, avec un nœud hébergeant ZPLS sur la même adresse IP, plus deux services supplémentaires sur des adresses IP distinctes. 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 relation de confiance bidirectionnelle 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 nœuds 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 de Zoom Node doivent être hébergés dans une zone résoluble par vos serveurs DNS externes (cela peut être limité à la résolution uniquement pour les plages d’adresses IP Zoom). Vos utilisateurs internes Zoom et cloud Zoom doivent communiquer à l’aide du 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: ``` GET https://library.zoom.com/technical-library/fr/services-avances-entreprise/zoom-node/zoom-node-deployment-field-guide/zoom-node-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.