# 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 diagrammes 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 seront 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 de l'IP et du certificat pour le déploiement de **Zoom Meetings Hybrid** dans des environnements sur site ou de cloud hybride. 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 centrale | | Proxy Zoom Connecteur | `zcp1.customer.com` | Nom alternatif du sujet (SAN) | Signalisation et contrôle de session | | Routeur de module multimédia 1 | `mmr1.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement multimédias | | Routeur de module multimédia 2 | `mmr2.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement multimédias | | Routeur de module multimédia 3 | `mmr3.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement multimé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 **Zoom Phone Local Survivability (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 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 centrale | | 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 appropriée 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 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, **seulement deux (2) adresses IP sont utilisées activement** dans le déploiement ZPLS : une par module, fonctionnant sur une **VM Node dédiée**. {% hint style="warning" %} ZPLS ne permet qu’un seul module par VM Node. Vous ne pouvez pas co-localiser ZPLS avec d’autres modules Zoom sur la même VM. {% endhint %} Comment ces schémas 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 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 Hybride déployé avec une IP partagée et un nom d’hôte partagé
Cette configuration répète la structure Node telle qu’elle apparaît dans le schéma Zoom Meetings Hybride de l’Option 1. Cependant, dans ce déploiement, le **Le SYSTÈME D'EXPLOITATION du Node partage son adresse IP avec le premier module déployé** (généralement le Proxy Connecteur Zoom, ZCP). Cela permet de réduire l’utilisation des IP tout en maintenant 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 Connecteur Zoom) | `zcp1.customer.com` | Nom commun (CN) | Signalisation et contrôle de session | | Routeur de module multimédia 1 | `mmr1.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement multimédias | | Routeur de module multimédia 2 | `mmr2.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement multimédias | | Routeur de module multimédia 3 | `mmr3.customer.com` | Nom alternatif du sujet (SAN) | Routage et traitement multimé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), seulement **quatre (4) adresses IP** sont requises. Cette conception optimise l’utilisation de l’adresse IP tout en restant conforme aux normes de déploiement. {% endhint %}
L’image ci-dessus montre un déploiement ZPLS minimal où 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 cadre Zoom Node où un **certificat TLS à hôte unique** est valide. Le nom d’hôte suivant doit être configuré dans 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 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 nœud et ZPLS partagent une seule adresse IP | | Contrainte de déploiement | Un seul module autorisé par VM de nœud (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) publique de confiance 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 : * **PKI automatique**: Cette solution innovante automatise l’inscription et le renouvellement sécurisés des certificats 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 toute autorité de certification majeure approuvée publiquement. Vous gérez l’inscription et le renouvellement des certificats. Des considérations supplémentaires s’appliquent concernant la possibilité pour Zoom Node d’avoir jusqu’à cinq noms d’hôte/SAN lors de l’utilisation de certificats fournis par le client, lesquelles sont détaillées plus loin ci-dessous. #### Gestion automatique du certificat avec Auto PKI Zoom Auto PKI installe automatiquement des certificats d’AC publics valides et dignes de confiance 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 du certificat Auto PKI Le scénario suivant peut vous aider à comprendre comment fonctionne l’inscription et le renouvellement des certificats. Par exemple : un administrateur a déployé une nouvelle instance 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 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 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 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. **Émission du certificat**: Envoie la demande de signature de certificat (CSR) au service Auto PKI dans le cloud Zoom. Ce service travaille ensuite avec des autorités de certification pour émettre 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 émis lors de la dernière étape et sa clé privée correspondante (générée précédemment) dans le stockage local, les rendant disponibles pour les services s'exécutant 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, ce qui élimine le besoin d’un renouvellement manuel. #### Bring Your Own Certificates (BYOC) Vous pouvez installer vos propres certificats valides et 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, rappelez-vous 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ésolubles publiquement par les services cloud de Zoom. Zoom recommande deux types de certificats : * **Certificat Wildcard** * **Certificat Multi-SAN** (également connu sous le nom de certificat Multi-Domain, 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 diagramme ZPLS dans la [#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 dans le 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 réduit 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. Cependant, 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 nœud (jusqu’à un \[1]) et tous les services que vous installerez (jusqu’à quatre \[4]). **Ces informations sont requises avant d’inscrire un certificat**. {% endhint %} Un certificat Multi-SAN est nécessaire pour Zoom Node, car il chiffre le trafic de cinq (5) noms d’hôte. Une demande unique pour ce certificat nécessite une connaissance préalable de toutes les informations nécessaires, y compris les noms de nœud prévus et les noms de tous les services destinés à être déployés sur le nœud. Par exemple, avec un module comme ZPLS, un seul module ZPLS est déployé par nœud ; un seul SAN supplémentaire est donc 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 Node hébergeant ZPLS sur la même IP, plus deux services supplémentaires sur des 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 puissent être résolus publiquement afin qu’une 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 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 pouvant être résolue 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 en utilisant le même ensemble de noms d’hôte. --- # 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/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.