Einheit 2.1: Ressourcenmodell: Verträge, VDCs und Grenzen

Einführung

Bevor eine Berechnungs- oder Netzwerkressource gezeichnet wird, muss ein Unternehmen zwei strukturelle Fragen klären: Wo verläuft die Grenze zwischen kommerzieller und auditierter Ebene, und wie ist die regionale Segmentierung darunter organisiert? In IONOS CLOUD entsprechen diese beiden Fragen zwei verschiedenen Grundelementen, dem Vertrag und dem virtuellen Rechenzentrum. Die Verwechslung beider ist einer der teuersten Fehler, die ein Architekt begehen kann, da mehrere Entscheidungen nach dem Einsatz einer Workload faktisch irreversibel sind. Diese Einheit definiert die Bedeutung jeder Grenze, zeigt, wo die Plattform es bewusst nicht zulässt, diese zu überschreiten, und schließt mit der Erstellung des ersten VDCs von FinCorp im Data Center Designer ab, wobei Region und Name als dauerhafte Auswahl festgelegt werden.

1. Die Vertragsgrenze und das VDC darunter

Der Vertrag ist die oberste kommerzielle, governancebezogene und prüfungstechnische Grenze. Er ist die Einheit, auf die eine Rechnung ausgestellt wird, der Bereich, für den ein Activity Log abgefragt wird, und das Gebiet, das ein Vertragsinhaber verwaltet. Pro Vertrag existiert genau ein Vertragsinhaber; dieses Konto wird automatisch für die Person erstellt, die sich als Erste bei IONOS CLOUD registriert hat, verfügt über vollen Zugriff auf alle Ressourcen und kann nicht widerrufen werden. Administratoren (unbegrenzt pro Vertrag) teilen den Zugriffsbereich dieses Inhabers auf alle vertraglich gebundenen Ressourcen, mit Ausnahme der Änderung der Zahlungsmethode. Alles andere, jeder Benutzer, jede Gruppe, jedes VDC, jeder IP-Block und jedes Image, befindet sich innerhalb eines einzelnen Vertrags und überschreitet diesen nicht nativ.

Das Virtuelle Rechenzentrum ist die organisierende Grenze innerhalb des Vertrags. Ein VDC ist eine Sammlung von Cloud-Ressourcen zum Aufbau einer IT-Infrastruktur auf Enterprise-Niveau, die auf eine Region beschränkt ist, und es ist der Ort, an dem Netzwerk, Compute und Storage einer Umgebung tatsächlich angesiedelt sind. Ein Vertrag kann viele VDCs enthalten; ein VDC gehört zu genau einem Vertrag und einer Region. Das mentale Modell, das man mitnehmen sollte, ist, dass der Vertrag die kommerzielle und Compliance-Grenze zieht und das VDC darunter die regionale und umgebungsbezogene Grenze zieht.

Die beiden Grenzen beantworten unterschiedliche Fragen, daher ist die Entscheidung, eine aufzuteilen, unabhängig von der Entscheidung, die andere aufzuteilen.

Neue ... aufteilen	Wenn der Treiber ist	Weil die Grenze regelt
Vertrag	Compliance-Isolation, separate Abrechnung/Eigentümerschaft, eine eigene juristische Person oder ein eigener Prüfungsbereich	Abrechnung, der Vertragsinhaber, der IAM-Bereich und der Abfragebereich des Activity Logs
VDC	Eine andere Region, eine Netzwerk- oder Umgebungstrennung (prod vs. non-prod) oder ein Projekt, das als eigener Posten abgerechnet werden muss	Regionale Platzierung, Netzwerk-Topologie und Gruppierung von Ressourcen innerhalb eines Vertrags

Ein separates VDC erzeugt bereits einen separaten Abschnitt auf der Monatsrechnung, daher rechtfertigt die Kostengetrennung allein keinen zweiten Vertrag. Greifen Sie nur dann zu einem neuen Vertrag, wenn der Treiber wirklich kommerzieller oder Compliance-natur ist: ein anderer Inhaber, eine andere juristische Person oder ein Prüfungsbereich, der die anderen Workloads nicht sehen darf. Greifen Sie zu einem neuen VDC für die Trennung nach Region, Umgebung oder Netzwerk innerhalb desselben Governance-Bereichs.

2. Boundary Stickiness: What Does Not Cross

Die Plattform setzt diese Grenzen strikt durch, und diese Durchsetzung ist selbst ein Design-Input und keine Einschränkung, die man umgehen sollte.

Mehrere Attribute sind an eine Region gebunden. Eine reservierte IPv4-Adresse kann nur in der Rechenzentrumsregion verwendet werden, in der sie reserviert wurde; es ist nicht möglich, eine bestimmte Adresse zu reservieren, sondern nur einen Block, und eine andere IP aus einem Block kann zwar ein anderes Netzwerk bedienen, jedoch nur innerhalb derselben Region. Images und Snapshots sind ebenfalls regionsspezifisch, und IONOS CLOUD bietet keine Replikation über Regionen hinweg als verwaltete Funktion an. Daher bedeutet das Verschieben eines Images in eine andere Region, es erneut hochzuladen oder Backup Service oder Object Storage als Übertragungsmedium zu verwenden. Die praktische Konsequenz ist, dass die Region, die bei der Erstellung eines VDC gewählt wird, auf alle regiongebundenen Ressourcen dieses VDC durchgreift, die er später enthält.

Die Vertragsgrenze ist ebenso fest. Es gibt keine native Ressourcenfreigabe über Verträge hinweg und keine Audit-Aggregation über Verträge hinweg: Ein Activity Log ist auf einen einzelnen Vertrag beschränkt und wird pro Vertrag abgefragt. Eine Organisation, die Workloads auf zwei Verträge aufteilt, muss die Audit-Daten daher selbst extern aggregieren. Benennung und Region sind im gleichen Sinne dauerhafte Entscheidungen. Die Region eines VDC ist bei der Erstellung festgelegt und kann danach nicht geändert werden. Da diese Region IPs und Images bindet, ist es die richtige Haltung, Name und Region als Einweg-Türen zu betrachten.

Für FinCorp formt dies die allererste Entscheidung. Die regulierten, DSGVO/BSI-umfassten Workloads befinden sich in einem einzigen Governance-Vertrag, sodass ein Activity Log und eine Abrechnungsbeziehung sie abdecken. Der erste VDC für dieses Umfeld ist an eine deutsche Region gebunden (der Residenzfilter wurde in Einheit 1.4 festgelegt) und verwendet eine Benennungskonvention, die Umgebung und Region auf einen Blick signalisiert, zum Beispiel fincorp-prod-de statt einer nicht eingegrenzten Bezeichnung. Da die Region später nicht geändert werden kann, wird diese Festlegung bewusst und nur einmal getroffen.

DCD-Implementierung: Schritt-für-Schritt-Anleitung

Sie erstellen das erste virtuelle Rechenzentrum von FinCorp und legen dabei Region und Name fest. Es handelt sich hier ausschließlich um die Struktur; es werden keine Compute-Ressourcen bereitgestellt (der Serveraufbau erfolgt in Modul 4). Das Ziel besteht darin, das regionale Segmentierungs-Grundelement zu definieren, an das jeder spätere FinCorp-Aufbau angehängt wird, wobei die beiden irreversiblen Attribute korrekt festgelegt werden.

Aufbauziel: Erstellen des ersten VDC des Szenarios mit fester Region und Benennung.

Schritte (im Data Center Designer):

Wählen Sie im DCD die Option, ein neues virtuelles Rechenzentrum zu erstellen. Im Erstellungsdialog werden die beiden dauerhaften Attribute festgelegt; behandeln Sie diesen Bildschirm daher als Entscheidungspunkt.
Geben Sie den Namen des VDC gemäß der vereinbarten Konvention ein, die Umgebung und Region kodiert (zum Beispiel fincorp-prod-de). Der Name sollte später auf der Rechnung und im Aktivitätsprotokoll gut lesbar sein.
Wählen Sie die Region / den Standort. Wählen Sie die deutsche Rechenzentrum-Region, die durch den Residency-Filter von FinCorp erforderlich ist. Diese Auswahl ist für die gesamte Lebensdauer des VDC dauerhaft und schließt die Region für jede reservierte IP und jedes Image ein, das der VDC enthalten wird. Bestätigen Sie die Auswahl, bevor Sie fortfahren.
Öffnen Sie den neuen VDC im Workspace. Er startet leer; Ressourcen werden später hinzugefügt, indem Elemente aus der Palette gezogen werden.
Klicken Sie im Inspector-Panel auf PROVISION CHANGES, um die Änderungen zu übernehmen. Der Dialog „Provision Data Center“ öffnet sich; prüfen Sie die Änderungen im Tab „Validation“ und bestätigen Sie mit Ihrem Passwort, um die Bereitstellung zu starten.

Häufige Fehler:

Die Annahme, dass die Region später geändert werden kann. Das ist nicht der Fall; die Region eines VDC wird bei der Erstellung festgelegt und schließt IPs und Images ein. Eine falsche Region bedeutet, dass der VDC neu aufgebaut werden muss.
Die Verwendung eines zweiten Vertrags zur Kostenabgrenzung. Ein separater VDC erzeugt bereits eine eigene Zeile auf der monatlichen Rechnung; reservieren Sie einen neuen Vertrag für Compliance, Eigentumsverhältnisse oder die Trennung von Rechtseinheiten.
Das VDC ohne Namen oder mit einem generischen Namen zu hinterlegen. Der Name wird auf der Rechnung und in Audit-Abfragen angezeigt; ein nicht eingegrenzter Name erschwert die Lesbarkeit beider Darstellungen im Unternehmensmaßstab.
Die Erwartung, eine reservierte IP oder ein Image über Regionen hinweg teilen zu können. Beide sind an eine Region gebunden; planen Sie die Platzierung von Anfang an pro Region.

Zusammenfassung

Der Vertrag ist die kommerzielle, governancebezogene und auditbezogene Grenze; das VDC ist die regionale Segmentierungsebene darunter, die auf einen Vertrag und eine Region beschränkt ist. Trennen Sie einen Vertrag aus Gründen der Compliance, der Eigentümerschaft oder der Abrechnungseinheit, und trennen Sie ein VDC aus Gründen der Region, der Umgebung oder der Netzwerktrennung. Da Region und Benennung dauerhaft sind und IPs, Images und der Audit-Bereich diese Grenzen nicht überschreiten, wird das erste VDC für den regulierten Bereich von FinCorp bewusst erstellt und an einer deutschen Region mit einem konventionsbasierten Namen festgelegt.

Wichtige Punkte:

Der Vertrag zieht die kommerzielle, governancebezogene und auditbezogene Linie; das VDC zieht die regionale und umgebungsbezogene Linie innerhalb dieses Rahmens. Es gibt genau einen (nicht widerrufbaren) Vertragsinhaber pro Vertrag.
Ein separates VDC wird bereits als eigener Posten abgerechnet, daher sollte ein neuer Vertrag nur aus Gründen der Compliance, der Eigentümerschaft oder der Trennung der Rechtspersönlichkeit erstellt werden, nicht nur zur Kostenübersicht.
Region und Benennung sind bei der VDC-Erstellung dauerhaft; die Region schließt reservierte IPs und Images ein, von denen keines als verwaltetes Feature über Regionen hinweg repliziert wird.
Es gibt keine native grenzüberschreitende Freigabe oder Audit-Aggregation zwischen Verträgen; ein Activity Log ist pro Vertrag, daher aggregieren Organisationen mit mehreren Verträgen Audit-Daten extern.
Das erste VDC von FinCorp ist an einer deutschen Region für die Datenresidenz festgelegt und nach Konvention benannt, damit es auf der Rechnung und in Audit-Abfragen eindeutig erkennbar ist.

Wichtige Begriffe: