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

Introduction

Avant de dessiner tout calcul ou réseau, une entreprise doit régler deux questions structurelles : où se situe la limite commerciale et d'audit, et comment la segmentation régionale est organisée en dessous. Sur IONOS, 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 peut commettre, car plusieurs des décisions sont effectivement irréversibles une fois que la charge de travail est lancée. Cette unité fixe le sens de chaque limite, montre où la plateforme refuse délibérément de vous laisser la traverser, et se termine par la création du premier centre de données virtuel de FinCorp dans le Data Center Designer avec la région et le nom définis comme des choix permanents.

1. La limite du contrat et le centre de données virtuel en dessous

Le contrat est la limite commerciale, de gouvernance et d'audit de niveau supérieur. Il s'agit de l'unité contre laquelle une facture est établie, de la portée pour laquelle un journal d'activité est interrogé, et du domaine que le propriétaire du contrat gouverne. Un seul propriétaire de contrat existe par contrat ; ce compte est créé automatiquement pour la personne qui s'est enregistrée pour la première fois avec IONOS Cloud, a un accès complet à toutes les ressources, et ne peut pas être révoqué. Les administrateurs (illimités par contrat) partagent la portée de ce propriétaire sur toutes les ressources contractuelles, à l'exception de la modification du mode de paiement. Tout le reste, chaque utilisateur, groupe, centre de données virtuel, bloc IP et image, vit à l'intérieur d'un seul contrat et ne franchit pas naturellement ses limites.

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

Les deux limites répondent à des questions différentes, donc la décision de diviser l'une est indépendante de la décision de diviser l'autre.

Diviser un nouveau ...	Lorsque le facteur de motivation est	Parce que la limite régit
Contrat	Isolement de conformité, facturation/propriété séparée, une entité juridique distincte ou une portée d'audit	Facturation, le propriétaire du contrat, le domaine IAM, et la portée de requête du journal d'activité
Centre de données virtuel	Une région différente, une séparation de réseau/environnement (prod vs non-prod), ou un projet qui doit être facturé comme un élément de ligne distinct	Placement régional, topologie de réseau, et regroupement de ressources à l'intérieur d'un contrat

Un centre de données virtuel distinct produit déjà une section distincte sur la facture mensuelle, donc la séparation des coûts à elle seule ne justifie pas un second contrat. Créez un nouveau contrat uniquement lorsque le facteur de motivation est réellement commercial ou de niveau de conformité : un propriétaire différent, une entité juridique différente, ou une portée d'audit qui ne doit pas voir les autres charges de travail. Créez un nouveau centre de données virtuel pour la séparation de région, d'environnement ou de réseau dans le même domaine de gouvernance.

2. Collage de limite : ce qui ne franchit pas les frontières

La plateforme impose ces limites de manière stricte, et cette imposition est en soi une entrée de conception plutôt qu'une limitation à contourner.

Plusieurs attributs sont verrouillés à la région. Une adresse IPv4 réservée ne peut être utilisée que dans la région de centre de données où elle a été réservée ; vous ne pouvez pas réserver une adresse spécifique, mais uniquement un bloc, et un IP différent d'un bloc peut servir un réseau différent mais uniquement dans la même région. Les Images & Snapshots sont également locaux à la région, et IONOS ne propose pas de réplication inter-régions comme fonction gérée, donc déplacer une image vers une autre région signifie la réuploader ou utiliser Backup Service ou Object Storage comme support de transfert. La conséquence pratique est que la région que vous choisissez pour un centre de données virtuel lors de sa création se propage dans chaque ressource liée à la région que ce centre de données virtuel possède par la suite.

La limite de contrat est tout aussi ferme. Il n'y a pas de partage de ressources inter-contrat natif et pas d'agrégation d'audits inter-contrat : un journal d'activité est limité à un seul contrat et interrogé par contrat, donc une organisation qui répartit les charges de travail sur deux contrats doit agréger les données d'audit elle-même, à l'extérieur. Le nom et la région sont des décisions permanentes dans le même esprit. La région d'un centre de données virtuel est fixée lors de sa création et ne peut pas être modifiée par la suite, et comme cette région verrouille les adresses IP et les images, traiter le nom et la région comme des portes à sens unique est la bonne posture.

Pour FinCorp, cela donne forme à la toute première décision. Les charges de travail réglementées, GDPR/BSI, sont situées dans un seul contrat de gouvernance afin qu'un seul journal d'activité et une seule relation de facturation les couvrent, et le premier centre de données virtuel pour cet ensemble est fixé à une région allemande (le filtre de résidence réglé dans l'unité 1.4) avec une convention d'appellation qui signale l'environnement et la région d'un seul coup d'œil, par exemple fincorp-prod-de plutôt qu'un libellé non limité. Puisque la région ne peut pas être modifiée plus tard, cette fixation est faite délibérément et une seule fois.

DCD Déploiement étape par étape

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

Objectif de construction : Créer le premier centre de données virtuel de la scénario, en fixant la région et le nom.

Étapes (dans le Data Center Designer) :

Dans le DCD, choisissez de créer un nouveau centre de données virtuel. La boîte de dialogue de création est où les deux attributs permanents sont réglés, donc traitez cet écran comme le point de décision.
Entrez le nom du centre de données virtuel 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é plus tard.
Sélectionnez la région / emplacement. Choisissez la région du centre de données allemand requise par le filtre de résidence de FinCorp. Ce choix est permanent pour la durée de vie du centre de données virtuel et verrouille la région pour chaque IP réservé et image que le centre de données virtuel contiendra, donc confirmez-le avant de poursuivre.
Ouvrez le nouveau centre de données virtuel dans l’espace de travail. Il commence vide ; les ressources sont ajoutées plus tard en faisant glisser des éléments de la palette.
Cliquez sur PROVISIONNER LES MODIFICATIONS dans le volet Inspector pour valider. La boîte de dialogue de provisionnement du centre de données s’ouvre ; examinez les modifications dans l’onglet de validation et confirmez avec votre mot de passe pour commencer le provisionnement.

Erreurs courantes :

Traiter la région comme modifiable plus tard. Ce n’est pas le cas ; la région d’un centre de données virtuel est fixée lors de sa création, et elle verrouille les adresses IP et les images, donc une région incorrecte signifie reconstruire le centre de données virtuel.
Utiliser un deuxième contrat pour séparer les coûts. Un centre de données virtuel distinct produit 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 centre de données virtuel 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 étendu rend les deux plus difficiles à lire à l’échelle de l’entreprise.
S’attendre à partager un IP réservé ou une image à travers les régions. Les deux sont liés à la région ; planifiez le placement par région dès le départ.

Résumé

Le contrat constitue la limite commerciale, de gouvernance et d'audit ; le centre de données virtuel (VDC) est la primitive de segmentation régionale 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 de réseau. Puisque la région et le nommage sont permanents et que les adresses IP, les images et la portée d'audit ne franchissent pas ces limites, le premier VDC pour le patrimoine réglementé de FinCorp est créé délibérément, fixé à une région allemande avec un nom guidé par une convention.

Points clés :

Le contrat définit la limite commerciale, de gouvernance et d'audit ; le VDC définit la limite régionale et environnementale à l'intérieur. Il n'y a qu'un seul propriétaire de contrat (non révocable) par contrat.
Un VDC distinct facture déjà comme un élément de ligne distinct, donc divisez un nouveau contrat uniquement pour des raisons de conformité, de propriété ou de séparation d'entité juridique, et non simplement pour la visibilité des coûts.
La région et le nommage sont permanents lors de la création du VDC ; la région verrouille les adresses IP et les images réservées, aucune desquelles ne se réplique entre les régions en tant que fonctionnalité gérée.
Il n'y a pas de partage natif entre contrats ou d'agrégation d'audit ; un journal d'activité est par contrat, donc les organisations multi-contrats agrègent les données d'audit à l'extérieur.
Le premier VDC de FinCorp est fixé à une région allemande pour la résidence et nommé par convention afin qu'il soit lisible sur la facture et dans les requêtes d'audit.

Terminologie importante :