Unité 2.1 : Modèle de ressources : contrats, VDC et limites

Introduction

Avant tout schéma de calcul ou de réseau, une entreprise doit trancher deux questions structurelles : où se situe la frontière commerciale et d'audit, et comment le cloisonnement régional est organisé en dessous. Sur IONOS CLOUD, ces deux questions correspondent à deux primitives distinctes, le contrat et le centre de données virtuel, et les confondre est l'une des erreurs les plus coûteuses qu'un architecte puisse commettre, car plusieurs décisions deviennent en pratique irréversibles dès qu'une charge de travail est déployée. Cette unité définit la portée de chaque frontière, montre où la plateforme empêche délibérément de la franchir, et se termine par la création du premier VDC de FinCorp dans Data Center Designer, avec la région et le nom définis comme choix définitifs.

1. La frontière du contrat et le VDC qui s'y trouve

Le contrat constitue la frontière commerciale, de gouvernance et d'audit de plus haut niveau. C'est l'unité à laquelle une facture est établie, le périmètre pour lequel un journal d'activité (Activity Log) est interrogé, et le domaine que le propriétaire du contrat administre. Il existe exactement un seul propriétaire de contrat par contrat ; ce compte est créé automatiquement pour la première personne qui s'est inscrite sur IONOS CLOUD, dispose d'un accès complet à toutes les ressources et ne peut pas être révoqué. Les administrateurs (sans limite par contrat) partagent la portée de ce propriétaire sur toutes les ressources sous contrat, à l'exception de la modification du moyen de paiement. Tout le reste, chaque utilisateur, groupe, VDC, bloc IP et image, se trouve à l'intérieur d'un seul contrat et ne le traverse pas nativement.

Le centre de données virtuel est la frontière d'organisation à l'intérieur du contrat. Un VDC est un ensemble de ressources cloud destiné à construire une infrastructure informatique de niveau entreprise, limité à une région, et c'est là que se trouvent réellement le réseau, le calcul et le stockage d'un environnement. Un contrat peut contenir de nombreux VDC ; un VDC appartient à exactement un contrat et à une région. Le modèle mental à retenir est que le contrat trace la ligne commerciale et de conformité, tandis que le VDC trace la ligne régionale et environnementale en dessous.

Les deux frontières répondent à des questions différentes, si bien que la décision de diviser l'une est indépendante de la décision de diviser l'autre.

Diviser un nouveau ...	Lorsque le facteur est	Parce que la frontière régit
Contrat	Isolation de conformité, facturation/propriété distincte, une entité juridique ou un périmètre d'audit distinct	Facturation, le propriétaire du contrat, le domaine IAM et le périmètre d'interrogation du journal d'activité
VDC	Une région différente, une séparation réseau/environnement (production vs non-production), ou un projet qui doit être facturé comme une ligne distincte	Emplacement régional, topologie réseau et regroupement des ressources au sein d'un même contrat

Un VDC distinct génère déjà une section distincte sur la facture mensuelle, si bien que la séparation des coûts seule ne justifie pas un second contrat. N'optez pour un nouveau contrat que lorsque le facteur est véritablement de niveau commercial ou de conformité : un propriétaire différent, une entité juridique différente, ou un périmètre d'audit qui ne doit pas voir les autres charges de travail. Optez pour un nouveau VDC pour la séparation par région, par environnement ou par réseau au sein du même domaine de gouvernance.

2. Collation des limites : ce qui ne traverse pas

La plateforme applique strictement ces limites, et cette application constitue en soi un élément de conception plutôt qu'une contrainte à contourner.

Plusieurs attributs sont liés à une région. Une adresse IPv4 réservée ne peut être utilisée que dans la région du centre de données où elle a été réservée ; il n'est pas possible de réserver une adresse spécifique, uniquement un bloc, et une IP différente d'un même bloc peut servir un réseau différent, mais uniquement au sein de cette même région. Les images et les instantanés sont également locaux à la région, et IONOS CLOUD ne propose pas la réplication inter-régions comme fonctionnalité managée. Par conséquent, déplacer une image vers une autre région implique de la réimporter ou d'utiliser Backup Service ou Object Storage comme support de transfert. La conséquence pratique est que la région choisie pour un VDC lors de sa création se propage à toutes les ressources liées à la région que ce VDC contiendra ensuite.

La limite contractuelle est tout aussi ferme. Il n'existe aucun partage natif de ressources entre contrats et aucune agrégation d'audit inter-contrats : un Activity Log est limité à un seul contrat et interrogé par contrat, si bien qu'une organisation qui répartit ses charges de travail sur deux contrats doit elle-même agréger les données d'audit, de manière externe. La désignation et la région sont des décisions permanentes, dans le même esprit. La région d'un VDC est fixée à la création et ne peut pas être modifiée par la suite, et comme cette région verrouille les IP et les images, il est correct de considérer le nom et la région comme des décisions irréversibles.

Pour FinCorp, cela façonne la toute première décision. Les charges de travail réglementées, dans le périmètre RGPD/BSI, sont situées dans un contrat de gouvernance unique afin qu'un seul Activity Log et une seule relation de facturation les couvrent, et le premier VDC pour ce domaine est ancré dans une région allemande (le filtre de résidence défini dans l'Unité 1.4) avec une convention de nommage qui signale l'environnement et la région d'un coup d'œil, par exemple fincorp-prod-de plutôt qu'une étiquette non qualifiée. Étant donné que la région ne peut pas être modifiée ultérieurement, cet ancrage est effectué de manière délibérée et unique.

Déroulement de la mise en œuvre de DCD

Vous allez créer le premier centre de données virtuel de FinCorp, en définissant sa région et son nom. Il s'agit uniquement de la structure ; aucun calcul n'est provisionné ici (la construction du serveur se trouve dans le Module 4). L'objectif est de poser la primitive de segmentation régionale à laquelle chaque construction ultérieure de FinCorp se rattachera, avec ses deux attributs irréversibles correctement définis.

Objectif de construction : Créer le premier VDC du scénario, en fixant la région et la nomenclature.

Étapes (dans Data Center Designer) :

Dans DCD, choisissez de créer un nouveau centre de données virtuel. La boîte de dialogue de création est l'endroit où les deux attributs permanents sont définis, il convient donc de considérer cet écran comme le point de décision.
Saisissez le Nom du VDC en utilisant la convention convenue qui encode l'environnement et la région (par exemple fincorp-prod-de). Le nom doit être lisible sur la facture et dans le journal d'activité ultérieurement.
Sélectionnez la Région / Emplacement. Choisissez la région du centre de données allemande requise par le filtre de résidence de FinCorp. Cette sélection est permanente pour la durée de vie du VDC et verrouille la région pour chaque IP réservée et chaque image que le VDC contiendra, confirmez-la donc avant de poursuivre.
Ouvrez le nouveau VDC dans l'Espace de travail. Il démarre vide ; les ressources sont ajoutées ultérieurement en faisant glisser des éléments depuis la Palette.
Cliquez sur PROVISION CHANGES dans le volet Inspecteur pour valider. La boîte de dialogue Provision Data Center s'ouvre ; examinez les modifications dans l'onglet Validation et confirmez avec votre mot de passe pour lancer le provisionnement.

Erreurs courantes :

Considérer la région comme modifiable ultérieurement. Ce n'est pas le cas ; la région d'un VDC est fixée à la création, et elle verrouille les IP et les images, une région erronée implique donc de reconstruire le VDC.
Utiliser un second contrat pour séparer les coûts. Un VDC distinct génère déjà sa propre ligne sur la facture mensuelle ; réservez un nouveau contrat pour la conformité, la propriété ou la séparation d'entité juridique.
Laisser le VDC sans nom ou avec un nom générique. Le nom apparaît sur la facture et dans les requêtes d'audit ; un nom non qualifié rend les deux plus difficiles à lire à l'échelle d'entreprise.
S'attendre à partager une IP réservée ou une image entre plusieurs régions. Les deux sont liées à une région ; planifiez le placement par région dès le départ.

Résumé

Le contrat constitue la frontière commerciale, de gouvernance et d'audit ; le centre de données virtuel (VDC) est la primitive de segmentation régionale qui se situe en dessous, limitée à un contrat et à une région. Divisez un contrat pour des raisons de conformité, de propriété ou d'entité de facturation, et divisez un VDC pour des raisons de région, d'environnement ou de séparation réseau. Étant donné que la région et la nomenclature sont permanentes, et que les adresses IP, les images et le périmètre d'audit ne traversent pas ces frontières, le premier VDC pour le parc réglementé de FinCorp est créé délibérément, ancré dans une région allemande avec un nom basé sur une convention.

Points clés :

Le contrat trace la ligne commerciale, de gouvernance et d'audit ; le VDC trace la ligne régionale et environnementale à l'intérieur de celle-ci. Il existe exactement un (et unique) propriétaire de contrat non révocable par contrat.
Un VDC distinct est déjà facturé comme une ligne de coût indépendante ; créez donc un nouveau contrat uniquement pour la conformité, la propriété ou la séparation d'entité juridique, et non simplement pour la visibilité des coûts.
La région et la nomenclature sont permanentes à la création du VDC ; la région verrouille les adresses IP réservées et les images, aucune de ces ressources ne se répliquant entre les régions en tant que fonctionnalité gérée.
Il n'existe ni partage natif entre contrats ni agrégation d'audit ; un journal d'activité est propre à chaque contrat, si bien que les organisations multi-contrats agrègent les données d'audit en externe.
Le premier VDC de FinCorp est ancré dans une région allemande pour la résidence des données et nommé selon une convention afin qu'il soit lisible sur la facture et dans les requêtes d'audit.

Terminologie importante :