> 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/learn-the-platform/fr/module-7-multi-tenant/04-resource-allocation.md). # Allocation et mise à l’échelle des ressources ## Nœuds locataires : hôtes virtuels pour centres de données virtuels Chaque locataire VergeOS s’exécute sur un ou plusieurs **nœuds locataires** — des serveurs virtuels qui simulent des hôtes VergeOS physiques. Chaque nœud locataire fournit des ressources de calcul dédiées (cœurs CPU), de la mémoire (RAM) et la connectivité réseau aux charges de travail du locataire, tout en maintenant une isolation complète grâce au réseau encapsulé du locataire. Comprendre le fonctionnement des nœuds locataires est la clé pour dimensionner correctement les déploiements de locataires et les faire évoluer au fil du temps. ### Caractéristiques des nœuds locataires | Caractéristique | Description | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Hôtes simulés** | Les nœuds locataires reproduisent la fonctionnalité des nœuds VergeOS physiques à l’intérieur du centre de données virtuel du locataire | | **Communication sécurisée entre hôtes** | Les nœuds locataires communiquent via le réseau encapsulé protégé du locataire, même lorsqu’ils s’exécutent sur différents hôtes physiques | | **Mobilité** | Les nœuds locataires sont migrés à chaud entre hôtes physiques pour la maintenance, l’équilibrage de charge et le basculement automatique | | **Allocation de ressources adaptée** | Les nœuds locataires peuvent cibler différents clusters avec différents profils matériels (standard, vGPU, mémoire élevée) | | **Mise à l’échelle sans interruption** | Les cœurs et la RAM peuvent être augmentés ou diminués sur un nœud locataire en cours d’exécution sans le redémarrer | ### Limites des nœuds locataires Valeurs par défaut et maximums par nœud locataire : | Ressource | Par défaut | Maximale | | --------- | ---------- | ------------------- | | Cœurs | 4 | 1,048,576 | | RAM | 16 Go | 5 242 880 Mo (5 To) | Cluster `RAM max par machine` et `Cœurs max par machine` les paramètres peuvent encore restreindre ce qu’un nœud locataire donné peut réellement consommer. La mise en réseau a également une limite au niveau du locataire : un maximum de **28 segments réseau d’hôte** peuvent être étendus dans un seul locataire sous forme de connexions de couche 2 (types éligibles : interne, externe, BGP, VPN et ponté physique). ### Aucun calcul manuel de surcharge VergeOS prend automatiquement en compte la surcharge de l’hyperviseur et du stockage. La mémoire que vous attribuez à un nœud locataire est **entièrement disponible** pour ce locataire afin de la répartir entre ses propres charges de travail — aucun calcul manuel de surcharge n’est requis. ## Locataires à nœud unique vs multi-nœuds La première décision de planification est de savoir si un locataire a besoin d’un seul nœud ou de plusieurs. ### Locataires à nœud unique (option par défaut recommandée) Un seul nœud locataire est la configuration la plus simple et la plus courante. C’est le point de départ recommandé chaque fois que les besoins en calcul et en mémoire d’un locataire tiennent dans un seul nœud. Les locataires à nœud unique offrent toujours de la redondance grâce au mécanisme de **surveillance intégré de VergeOS**: * Si l’hôte physique exécutant le nœud locataire tombe en panne, le watchdog redémarre automatiquement le nœud locataire sur un autre hôte physique * Lors d’une maintenance planifiée, un nœud locataire temporaire est créé pour migrer les charges de travail à chaud sans interruption de service * Des nœuds locataires supplémentaires peuvent être ajoutés plus tard, sans interruption, à mesure que les besoins augmentent {% hint style="success" %} **Commencer simplement** Si les besoins en RAM et en cœurs peuvent être satisfaits avec un seul nœud locataire et qu’il n’y a pas de besoins réseau ou de périphériques nécessitant plusieurs hôtes physiques, un seul nœud est préférable pour des raisons de simplicité. {% endhint %} ### Quand des locataires multi-nœuds sont nécessaires Plusieurs nœuds locataires deviennent nécessaires dans des cas précis : 1. **Les besoins en calcul dépassent les maximums du cluster** — La quantité de cœurs et de RAM pouvant être attribuée à un seul nœud locataire est limitée par les paramètres du cluster (*RAM max par machine* et *Cœurs max par machine*). Lorsqu’un locataire a besoin de plus que ce qu’offre un seul nœud, ajoutez des nœuds supplémentaires. 2. **Applications en cluster** — Fermes web, clusters Hadoop, paires base de données primaire/réplique et autres applications distribuées qui exigent que les charges de travail s’exécutent sur différents hôtes physiques pour la haute disponibilité, l’équilibrage de charge ou le traitement parallèle. 3. **Capacités matérielles mixtes** — Lorsqu’un locataire a besoin à la fois de ressources de calcul standard et de matériel spécialisé (vGPU, passage PCI, périphériques USB), déployez des nœuds locataires sur différents clusters avec le matériel approprié. 4. **Séparation réglementaire** — Les exigences de conformité peuvent imposer que certaines charges de travail s’exécutent sur des hôtes physiquement séparés. ## Stratégie de dimensionnement Les locataires VergeOS prennent en charge **la mise à l’échelle des ressources sans interruption** — vous pouvez ajouter des cœurs, de la RAM, des nœuds et du stockage à un locataire en cours d’exécution sans affecter les charges de travail. Cela signifie que vous devriez : * **Dimensionner pour les besoins actuels et à court terme**, et non pour une croissance future spéculative * **Monter en charge progressivement** à mesure que la demande réelle augmente * **Éviter la surallocation** — les ressources inutilisées allouées à un locataire ne peuvent pas servir aux autres ```mermaid flowchart TD A["Évaluer les besoins de la charge de travail"] --> B{"Les besoins tiennent-ils\ndans un seul nœud ?"} B -- Oui --> C["Déployer un locataire à nœud unique"] B -- Non --> D{"Raison multi-nœuds ?"} D -- "Dépasse le maximum du cluster" --> E["Ajouter des nœuds au\nmême cluster"] D -- "HA / applications en cluster" --> F["Ajouter des nœuds avec\nanti-affinité de groupe HA"] D -- "Matériel mixte" --> G["Ajouter des nœuds sur\ndifférents clusters"] D -- "Réglementaire" --> H["Ajouter des nœuds sur\ndes hôtes physiques distincts"] C --> I["Surveiller et faire évoluer\nverticalement d’abord"] E --> I F --> I G --> I H --> I I --> J{"Besoin de plus de\nressources ?"} J -- "Tient dans le nœud existant" --> K["Augmenter les cœurs/RAM\nsur le nœud existant"] J -- "Dépasse la capacité du nœud" --> L["Ajouter un autre\nnœud locataire"] K --> I L --> I style A fill:#e8f5e9,stroke:#2e7d32 style C fill:#e3f2fd,stroke:#1565c0 style I fill:#fff3e0,stroke:#e65100 ``` ## Exemples de configuration Les exemples suivants illustrent des décisions réelles de planification des nœuds locataires. ### Exemple 1 : petit locataire à nœud unique **Scénario :** 3 VM, aucun besoin particulier. Le cluster d’hôtes permet une RAM max de 64 Go et 16 cœurs max. | Paramètre | Valeur | | -------------------------- | ----------------------------------------------------------------------------- | | Nœuds locataires | 1 | | Cœurs | 8 | | RAM | 16 Go | | Chemin de mise à l’échelle | Ajouter des cœurs/RAM jusqu’à 64 Go / 16 cœurs, puis ajouter un deuxième nœud | **Justification :** Un seul nœud fournit des ressources suffisantes. Le basculement par watchdog assure la redondance sans complexité supplémentaire. ### Exemple 2 : applications web HA de taille moyenne **Scénario :** Applications web destinées aux clients nécessitant une HA multi-instance. Le cluster d’hôtes permet une RAM max de 128 Go et 16 cœurs max. | Paramètre | Valeur | | ---------------- | ---------------------------------------------------------------------------------------------------------- | | Nœuds locataires | 2 | | Nœud 1 | 64 Go de RAM, 12 cœurs (2 serveurs web + base de données principale) | | Nœud 2 | 64 Go de RAM, 12 cœurs (2 serveurs web + réplique de base de données) | | Groupes HA | Les règles d’anti-affinité garantissent que les instances web/BD restent sur des hôtes physiques distincts | **Justification :** Même si un seul nœud pourrait contenir toutes les ressources, deux nœuds garantissent que les serveurs web et les composants de base de données s’exécutent sur des hôtes physiques différents pour une HA au niveau de l’application. ### Exemple 3 : charge de travail mixte avec GPU **Scénario :** Calcul standard, rendu vidéo haute performance et traitement accéléré par GPU. Trois clusters d’hôtes sont disponibles : Standard (64 Go max), vGPU (64 Go max), Premium (128 Go max). | Paramètre | Valeur | | ---------------- | --------------------------------------------------------------- | | Nœuds locataires | 4 | | Nœud 1 | 64 Go, 8 cœurs — cluster Standard (serveurs de fichiers) | | Nœud 2 | 64 Go, 8 cœurs — cluster Standard (outils de gestion) | | Nœud 3 | 64 Go, 16 cœurs — cluster vGPU (rendu vidéo) | | Nœud 4 | 48 Go, 8 cœurs — cluster Premium (postes de travail de montage) | **Justification :** Plusieurs nœuds permettent un placement sur des clusters aux capacités matérielles correspondantes. Chaque nœud locataire cible le cluster le mieux adapté à sa charge de travail. ### Exemple 4 : analytique distribuée d’entreprise **Scénario :** Plateforme d’analytique distribuée nécessitant un déploiement multi-hôte pour l’équilibrage de charge et la redondance. Le cluster d’hôtes permet une RAM max de 96 Go et 16 cœurs max. | Paramètre | Valeur | | ---------------- | ------------------------------------------------------------------------------------------------- | | Nœuds locataires | 4 | | Nœuds 1–3 | 64 Go, 12 cœurs chacun (1 serveur d’application + 1 serveur de base de données par nœud) | | Nœud 4 | 32 Go, 8 cœurs (2 serveurs de traitement des données) | | Groupes HA | L’anti-affinité garantit que les instances d’application s’étendent sur plusieurs hôtes physiques | **Justification :** Quatre nœuds locataires garantissent que les instances d’application s’exécutent sur plusieurs hôtes physiques tout en conservant la possibilité d’exécuter tous les services au sein du locataire. ## Augmenter les ressources du locataire VergeOS offre trois méthodes non perturbatrices pour ajouter des ressources à un locataire en cours d’exécution. ### Ajouter des cœurs/RAM à un nœud existant Les modifications prennent effet **immédiatement** sur le nœud locataire — aucun redémarrage requis. 1. Accédez au **tableau de bord du locataire** → **Nœuds** 2. Double-cliquez sur le nœud cible → cliquez sur **Modifier** 3. Modifiez les **Cœurs** et/ou **RAM** champs 4. Cliquez sur **Soumettre** {% hint style="info" %} **Limites du cluster** Le maximum de cœurs et de RAM par nœud locataire est déterminé par les *RAM max par machine* et *Cœurs max par machine* paramètres du cluster. Maximisez les nœuds existants avant d’en ajouter de nouveaux, sauf si l’équilibrage de la charge l’exige autrement. {% endhint %} {% hint style="info" %} **Validation des changements de ressources** Lorsque des cœurs ou de la RAM sont modifiés sur un nœud locataire, VergeOS exécute `validatecluster.gcs` sur le cluster principal (et `validateclusterfailover.gcs` sur le cluster de basculement, s’il est configuré). Les modifications qui dépasseraient les limites par machine de l’un ou l’autre cluster — ou que l’hôte en cours d’exécution ne peut pas satisfaire avec la RAM libre — sont rejetées, ce qui empêche le surengagement. {% endhint %} ### Ajouter un nouveau nœud locataire 1. Accédez au **tableau de bord du locataire** → **Nœuds** → **Nouveau** 2. Configurer **Cœurs**, **RAM**, **Cluster**, et **Cluster de basculement** 3. Sélectionnez **En cas de coupure d’alimentation** comportement (dernier état, laisser éteint ou allumer) 4. Cliquez sur **Soumettre** {% hint style="warning" %} **Nœud préféré** Définir un *nœud préféré* est **non recommandé** pour les nœuds locataires. Une configuration incorrecte peut nuire à la redondance intégrée. Consultez le support VergeOS si nécessaire. {% endhint %} ### Provisionner du stockage supplémentaire **Nouveau niveau de stockage :** 1. Tableau de bord du locataire → **Ajouter du stockage** → sélectionnez **Niveau** → saisissez **Provisionné** quantité → **Soumettre** **Étendre le niveau existant :** 1. Tableau de bord du locataire → faites défiler jusqu’à **Stockage** section → cliquez sur **Modifier** sur le niveau souhaité 2. Saisissez le nouveau **total** volume provisionné total (par exemple, passer de 50 Go à 75 Go pour ajouter 25 Go) ## Réduire les ressources du locataire ### Réduire les cœurs/RAM Les cœurs et la RAM peuvent être réduits sur un nœud locataire en cours d’exécution sans l’éteindre. Cependant, si ces ressources sont actuellement utilisées par des VM du locataire, la **récupération effective est différée** jusqu’à l’arrêt des VM. **Exemple :** Vous réduisez la RAM d’un nœud locataire de 32 Go à 28 Go, mais les VM utilisent actuellement les 32 Go. Le paramètre change immédiatement, mais la différence de 4 Go n’est pas récupérée tant que les VM n’ont pas libéré cette mémoire. ### Supprimer un nœud locataire 1. Éteignez ou migrez toutes les VM du nœud 2. Éteignez le nœud locataire 3. Accédez à **tableau de bord du locataire** → **Nœuds** → sélectionnez le nœud → **Supprimer** {% hint style="warning" %} **Exigence minimale de nœud** Un locataire doit toujours avoir au moins un nœud. Avant de supprimer un nœud locataire, assurez-vous qu’au moins un autre nœud demeure et que toutes les charges de travail ont été migrées hors du nœud en cours de suppression. {% endhint %} ## Chemins de mise à l’échelle : d’abord verticale, puis horizontale La stratégie de mise à l’échelle recommandée pour les locataires suit une progression claire : ### Étape 1 : mise à l’échelle verticale Augmentez les cœurs et la RAM sur les nœuds locataires existants jusqu’au maximum du cluster. C’est la voie la plus simple, sans aucune interruption. ### Étape 2 : mise à l’échelle horizontale Lorsque les nœuds existants sont au maximum, ajoutez de nouveaux nœuds locataires. Placez-les sur le même cluster pour une extension générale ou sur des clusters différents pour du matériel spécialisé. ### Étape 3 : ajouter du stockage Étendez le stockage provisionné indépendamment du calcul. Ajoutez de la capacité à un niveau existant ou provisionnez un nouveau niveau de stockage. ### Étape 4 : rééquilibrer Si la répartition des ressources devient inégale entre les nœuds, équilibrez la RAM et les cœurs entre les nœuds plutôt que d’en maximiser un et de provisionner le minimum pour un autre. {% hint style="info" %} **Vous venez de VMware ou de Nutanix ?** Sur VMware et Nutanix, "dimensionner un locataire" signifie généralement redimensionner un quota et faire confiance au planificateur. Dans VergeOS, vous dimensionnez directement des nœuds locataires dédiés. {% endhint %} | Plateforme | Modèle d’isolation | Action de mise à l’échelle | | ---------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | VergeOS | Chaque locataire est un VDC avec des nœuds locataires dédiés (réseau encapsulé + volumes de stockage isolés) | Modifiez à chaud les cœurs/RAM d’un nœud locataire, ou ajoutez un nœud — le système prend automatiquement en compte la surcharge | ## Bonnes pratiques | Pratique | Recommandation | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Commencez avec un nœud** | Utilisez par défaut des locataires à nœud unique ; ajoutez des nœuds uniquement lorsque c’est nécessaire | | **Dimensionnez au plus juste pour l’instant** | Provisionnez pour les besoins actuels/à court terme, et non pour une croissance future spéculative | | **Maximisez avant d’ajouter** | Augmentez les ressources des nœuds existants avant d’ajouter de nouveaux nœuds (sauf si l’équilibrage de la charge l’exige autrement) | | **Équilibrez les ressources** | Lorsque deux nœuds sont nécessaires, répartissez les ressources de manière uniforme plutôt que d’en maximiser un et de réduire l’autre au minimum | | **Utilisez des groupes HA** | Pour les locataires multi-nœuds avec des exigences de HA, configurez des règles d’anti-affinité afin que les VM se répartissent sur les hôtes physiques | | **Faites correspondre les clusters aux charges de travail** | Placez les nœuds locataires sur des clusters dont le matériel correspond à la charge de travail (GPU, mémoire élevée, standard) | | **Surveillez et ajustez** | Utilisez les tableaux de bord et les rapports d’utilisation des locataires pour déterminer quand une montée en charge est nécessaire | --- # 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/learn-the-platform/fr/module-7-multi-tenant/04-resource-allocation.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.