> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/fr/tenants/tenant-node-planning-guide.md). # Guide de planification des nœuds locataires ## Vue d’ensemble Ce guide présente les principales considérations pour déterminer le nombre optimal de nœuds locataires, l’allocation des ressources de calcul et les stratégies de placement pour les déploiements de locataires VergeOS. Une conception efficace des nœuds locataires favorise des performances et une utilisation des ressources optimales tout en conservant les avantages d’isolation et de sécurité des environnements locataires. ## Prérequis Avant d’utiliser ce guide, vous devez avoir une compréhension générale des concepts de locataire ; reportez-vous à [Vue d’ensemble des locataires](/run-the-platform/tenants/overview.md) si vous découvrez les locataires VergeOS. ## Objectif et portée Ce guide aide les administrateurs à prendre des décisions éclairées concernant : * Un nombre approprié de nœuds locataires basé sur les besoins du locataire * Les stratégies d’allocation des ressources entre les nœuds locataires * Les considérations de placement physique des nœuds locataires *** ## Que sont les nœuds locataires ? **Les nœuds locataires simulent des hôtes physiques** Les nœuds locataires sont des serveurs virtuels qui simulent des nœuds VergeOS physiques, en reproduisant de près les mêmes fonctionnalités, afin de créer un environnement locataire privé. Chaque locataire se compose d’un ou de plusieurs nœuds locataires qui fournissent collectivement l’infrastructure de calcul, de stockage et de réseau pour les charges de travail du locataire, tout en maintenant la séparation et la confidentialité grâce au réseau encapsulé du locataire. ## Caractéristiques des nœuds locataires **Communication sécurisée entre hôtes** * Le locataire peut être mis à l’échelle en toute sécurité sur plusieurs hôtes physiques * Le réseau encapsulé protégé du locataire permet à ses nœuds de communiquer entre eux de manière sécurisée **Mobilité** * Conçu pour être portable sur l’infrastructure physique * Migration entre hôtes physiques pour la maintenance ou l’équilibrage de charge * Basculement automatique vers d’autres nœuds physiques en cas de panne matérielle * Capacités de migration à chaud sans interruption de service **Allocation des ressources adaptée** * Les nœuds locataires peuvent être déployés sur des clusters ou des hôtes avec différentes configurations matérielles (y compris des équipements spécialisés comme des vGPU) afin de répondre aux exigences variées des charges de travail au sein du locataire. **Mise à l’échelle horizontale et verticale** * Les ressources d’un nœud locataire peuvent être augmentées ou réduites sans redémarrage * Des nœuds locataires peuvent être ajoutés pour faire évoluer les ressources de calcul sur plusieurs hôtes physiques * L’architecture locataire existante est étendue de manière transparente avec de nouveaux nœuds locataires *** ## Locataires à nœud unique {% hint style="info" %} **Points clés** * Les locataires à nœud unique offrent de la redondance grâce au basculement automatique * Un seul nœud locataire est préférable lorsqu’il peut satisfaire les besoins en ressources * Des nœuds locataires supplémentaires peuvent être ajoutés, sans interruption, selon les besoins pour faire évoluer les ressources d’un locataire {% endhint %} Un locataire peut fonctionner sur un seul nœud locataire tout en offrant une redondance, car le système utilise un mécanisme de « watchdog » qui redémarrera automatiquement un nœud locataire sur un nouvel hôte physique si son serveur physique venait à tomber en panne, ou si le nœud locataire virtuel ne répond pas pendant un certain temps. Pour les opérations de maintenance, un nœud locataire temporaire est automatiquement créé afin d’assurer une migration à chaud transparente des charges de travail du locataire. Si les exigences en RAM et en cœurs sont satisfaites avec un seul nœud locataire et qu’aucun besoin réseau ou matériel n’exige que les nœuds locataires soient répartis sur plusieurs hôtes, un seul nœud est souvent préférable pour plus de simplicité. ## Flexibilité de mise à l’échelle Les locataires VergeOS permettent une mise à l’échelle des ressources sans interruption ; vous pouvez ajouter des ressources à votre locataire sans perturber les charges de travail en cours d’exécution. Les nœuds locataires doivent généralement être planifiés et déployés en fonction des besoins actuels ou à court terme des charges de travail, avec augmentation des ressources au besoin. Cette approche évite de gaspiller des ressources allouées mais inutilisées. **Options de mise à l’échelle sans interruption :** * Ajouter des ressources aux nœuds locataires existants * Ajouter des nœuds locataires supplémentaires pour répartir la charge * Migrer les nœuds locataires vers d’autres hôtes physiques * Faire évoluer le stockage indépendamment des ressources de calcul Pour des procédures détaillées sur l’augmentation des ressources du locataire, reportez-vous à [Augmenter les ressources du locataire](/run-the-platform/tenants/add-tenant-resources.md) la documentation. ## Locataires à plusieurs nœuds Pour les déploiements locataires plus importants ou ceux nécessitant des spécifications matérielles variées, plus d’un nœud locataire peut être nécessaire. Les sections suivantes décrivent les conditions qui nécessitent plusieurs nœuds. **1. Besoins en ressources de calcul dépassant les maximums de charge de travail** Des nœuds locataires multiples sont nécessaires lorsqu’un locataire a besoin de plus de ressources de calcul que ce qu’un seul serveur peut fournir dans le cluster. La quantité de mémoire et le nombre de cœurs pouvant être alloués à un seul nœud locataire sont limités par les paramètres du cluster : [***RAM maximale par machine***\_ et \_***Nombre maximal de cœurs par machine***](/run-the-platform/system-administration/cluster-settings.md). **2. Exigences liées aux charges de travail du locataire** Certaines exigences applicatives nécessitent plusieurs nœuds locataires afin de permettre la répartition des charges de travail sur plusieurs serveurs physiques : * **Applications en cluster**: Les locataires utilisant des applications en cluster (par ex. fermes web, Hadoop, clusters de bases de données) ont généralement besoin d’exécuter plusieurs instances sur différents hôtes physiques pour la haute disponibilité, l’équilibrage de charge ou le traitement parallèle. * **Capacités matérielles mixtes**: Pour offrir à un locataire des profils de performance variés ou du matériel spécialisé en passthrough (vGPU, périphériques PCI, USB), il peut être nécessaire de déployer plusieurs nœuds locataires exécutés sur différents nœuds ou clusters VergeOS physiques. * **Exigences réglementaires**: Certains locataires peuvent avoir des exigences de conformité imposant une séparation matérielle entre les charges de travail. ## Détermination des besoins en ressources du locataire **Besoins en CPU** * Évaluez le nombre total de cœurs CPU nécessaires pour toutes les charges de travail prévues * Tenez compte des schémas d’utilisation de pointe et des exigences de performance * Tenez compte des différents types de charges de travail (intensives en CPU vs limitées par les E/S), pour lesquels il peut être pertinent de déployer sur différents nœuds ou clusters dotés de capacités matérielles spécialisées. **Besoins en mémoire** * Calculez la RAM totale nécessaire pour toutes les machines virtuelles prévues * Incluez la mémoire pour les services d’infrastructure locataire prévus, tels que NAS, IA, etc. * Le système gère automatiquement la surcharge de mémoire grâce à des processus intégrés. **Aucun calcul manuel de surcharge requis** Le système VergeOS prend automatiquement en compte la surcharge de l’hyperviseur et du stockage lors de l’allocation des ressources aux nœuds locataires. La mémoire que vous attribuez est entièrement disponible pour le locataire afin d’être répartie entre ses propres charges de travail. **Stratégie de dimensionnement adéquat** Il est généralement recommandé de dimensionner correctement les ressources de calcul du locataire pour qu’elles correspondent aux besoins réels des charges de travail, plutôt que d’allouer une capacité excédentaire pour une croissance future. Cette approche optimise l’utilisation des ressources et permet une montée en charge progressive à mesure que les besoins évoluent. ## Exemples de configuration Les exemples suivants illustrent différentes configurations de nœuds locataires afin de démontrer les concepts et exigences clés de planification. ### Exemple 1 - Petit locataire à nœud unique **Scénario :** * Un locataire avec seulement 3 VM, sans exigences particulières * Les paramètres du cluster d’hôtes permettent *RAM maximale par machine*: 64 Go de RAM et *Nombre maximal de cœurs par machine*: 16 * L’environnement d’hôte comprend plusieurs nœuds physiques, chacun contenant les mêmes périphériques passthrough disponibles pour les charges de travail du locataire **Exigences :** * Total de 16 Go de RAM et 8 cœurs pour les charges de travail locataires actuelles * Certaines charges de travail locataires nécessitent des périphériques vGPU **Configuration :** * Nœuds locataires : 1 * Ressources : 16 Go de RAM, 8 cœurs **Justification :** Un seul nœud fournit des ressources suffisantes pour la charge de travail tout en conservant la simplicité. Le basculement automatique des nœuds locataires garantit la redondance sans complexité supplémentaire. **Chemin de montée en charge :**\ Ajoutez davantage de RAM/cœurs au nœud locataire à mesure que les besoins en ressources augmentent (48 Go de RAM supplémentaires et 8 cœurs peuvent être ajoutés à ce nœud initial), ou ajoutez un deuxième nœud locataire si les besoins en ressources dépassent 64 Go/16 cœurs. ### Exemple 2 - Locataire de taille moyenne exécutant des applications web à haute disponibilité **Scénario :** * Un locataire de taille moyenne exécutant des applications web destinées aux clients avec une configuration multi-instances, équilibrée en charge/à haute disponibilité * Les paramètres du cluster d’hôtes permettent *RAM maximale par machine*: 128 Go de RAM et *Nombre maximal de cœurs par machine*: 16 **Exigences :** * 4 serveurs web (2 par hôte pour la HA) * 2 serveurs de base de données (principal/réplique sur des hôtes séparés) **Configuration :** * Nœuds locataires : 2 * Nœud 1 : 64 Go de RAM, 12 cœurs (héberge 2 serveurs web + la base de données principale) * Nœud 2 : 64 Go de RAM, 12 cœurs (héberge 2 serveurs web + la réplique de la base de données) * Les VM locataires utilisent les paramètres des groupes HA pour maintenir l’anti-affinité des nœuds, ce qui aide à répartir les charges de travail sur des hôtes distincts {% hint style="success" %} [**Cet article de la base de connaissances**](/knowledge-base/fr/automation-api/determine-node-where-vm-runs.md) **fournit des informations sur l’utilisation des groupes HA pour l’anti-affinité des nœuds** {% endhint %} **Justification :** Bien que les paramètres du cluster d’hôtes permettent de disposer de suffisamment de ressources dans un seul nœud locataire, plusieurs nœuds garantissent que les serveurs web et les composants de base de données du locataire s’exécutent sur différents hôtes physiques afin de répondre aux exigences HA de l’application du locataire. **Chemin de montée en charge :** Ajoutez davantage de RAM/cœurs aux nœuds existants à mesure que les besoins en calcul augmentent, ou ajoutez un ou plusieurs nœuds locataires supplémentaires si les exigences commencent à dépasser 256 Go/32 cœurs ou si une séparation physique plus poussée des charges de travail devient nécessaire. ### Exemple 3 - Locataire à charges de travail mixtes avec matériel spécialisé **Scénario :** * Le client locataire a besoin de ressources de calcul standard, de hautes performances pour le rendu vidéo et d’une accélération GPU pour les charges de travail de traitement vidéo * L’environnement d’hôte comporte plusieurs clusters avec des configurations matérielles et des profils de performance variés * Clusters d’hôtes applicables : * Standard (processeurs de milieu de gamme, ratio processeur/cœur standard) ; *RAM maximale par machine*: 64 Go de RAM et *Nombre maximal de cœurs par machine*: 16 * Cluster vGPU (processeurs haut de gamme, périphériques vGPU) ; *RAM maximale par machine*: 64 Go de RAM et *Nombre maximal de cœurs par machine*: 16 * Cluster haute performance (processeurs haut de gamme, densité mémoire élevée) *RAM maximale par machine*: 128 Go de RAM et *Nombre maximal de cœurs par machine*: 16 **Exigences :** * 128 Go/16 cœurs pour les VM standard (serveurs de fichiers et outils de gestion) * 64 Go/16 cœurs pour les VM accélérées par GPU pour le rendu vidéo * 48 Go/12 cœurs pour l’hôte haute performance des postes de travail de montage **Configuration :** * Nœuds locataires : 4 * Nœud 1 : 64 Go de RAM, 8 cœurs (cluster standard pour les serveurs de fichiers) * Nœud 2 : 64 Go de RAM, 8 cœurs (cluster standard pour les serveurs de fichiers/outils de gestion) * Nœud 3 : 64 Go de RAM, 16 cœurs (cluster vGPU pour les postes de travail de rendu de traitement vidéo) * Nœud 4 : 48 Go de RAM, 8 cœurs (cluster haut de gamme pour les postes de travail de montage) **Justification :** Plusieurs nœuds permettent un placement sur différents clusters avec des capacités matérielles différentes : standard, équipés de GPU et haute performance. Deux nœuds sont nécessaires dans le cluster Standard pour fournir les 128 Go de RAM requis pour les serveurs de fichiers et les outils de gestion. **Correspondance matérielle :** Chaque nœud locataire est placé sur une infrastructure physique qui correspond à ses besoins de charge de travail (paramètre de nœud locataire *cluster* ), optimisant à la fois les performances et les coûts. **Chemin de montée en charge :** Pour chaque nœud/cluster : ajoutez davantage de RAM/cœurs au nœud existant si les paramètres maximaux du cluster le permettent, ou ajoutez un ou plusieurs nœuds locataires supplémentaires. ### Exemple 4 - Locataire avec exigences d’applications en cluster **Scénario :** * Client locataire d’entreprise exécutant une plateforme d’analyse distribuée nécessitant un déploiement sur plusieurs hôtes pour les fonctions d’équilibrage de charge applicative et de redondance. * Les paramètres du cluster d’hôtes permettent *RAM maximale par machine*: 96 Go de RAM et *Nombre maximal de cœurs par machine*: 16 **Exigences :** * Support de 3 serveurs d’applications sur 3 hôtes physiques (48 Go de RAM/8 cœurs chacun) * Support de 3 serveurs de base de données (16 Go de RAM/4 cœurs chacun) * Support de 2 serveurs de traitement des données (16 Go de RAM/8 cœurs chacun) **Configuration :** * Nœuds locataires : 4 * Nœud 1 : 64 Go de RAM, 12 cœurs (1 serveur d’applications + 1 serveur de base de données) * Nœud 2 : 64 Go de RAM, 12 cœurs (1 serveur d’applications + 1 serveur de base de données) * Nœud 3 : 64 Go de RAM, 12 cœurs (1 serveur d’applications + 1 serveur de base de données) * Nœud 4 : 32 Go de RAM, 8 cœurs (2 serveurs de traitement des données) * Les VM locataires utilisent les paramètres des groupes HA pour maintenir l’anti-affinité des nœuds, ce qui aide à répartir les charges de travail sur des hôtes distincts {% hint style="success" %} [**Cet article de la base de connaissances**](/knowledge-base/fr/automation-api/determine-node-where-vm-runs.md) **fournit des informations sur l’utilisation des groupes HA pour l’anti-affinité des nœuds** {% endhint %} **Justification :** Quatre nœuds locataires garantissent que les instances d’application s’exécutent sur plusieurs hôtes physiques tout en conservant la capacité d’exécuter tous les services. **Chemin de montée en charge :** Ajoutez davantage de RAM/cœurs aux nœuds locataires existants dans la mesure où les paramètres maximaux du cluster le permettent ; configurez des nœuds supplémentaires lorsque les besoins en ressources ne peuvent pas être satisfaits avec les quatre nœuds d’origine. --- # 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://docs.verge.io/knowledge-base/fr/tenants/tenant-node-planning-guide.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.