Tenant-Staging: Konto, Umgebungen und Zugriffsstatus
In wessen Cloud-Konto die Bereitstellung läuft, der separate Vault-Tenant, welche Umgebungen in welchem Jahr existieren und ob der Tenant über das öffentliche Internet oder nur privat erreichbar ist.
Die Begriffe „privater Tenant“ und „öffentlicher Tenant“ werden oft synonym verwendet und meinen unterschiedliche Dinge. In der TRANXACT Private Cloud lassen sich daraus drei klare Entscheidungen ableiten, für die es sinnvoll ist, folgende Begriffe zu verwenden:
| Entscheidung | Optionen | Entschieden |
|---|---|---|
| Isolation – wird irgendetwas mit einem anderen Kunden geteilt? | Nein. Jede Bereitstellung ist mandantenfähig: ein dedizierter VPC/VNet, Cluster und Datenbank pro Kunde, und kein gemeinsam genutztes Ledger oder Datenbank. | Keine Frage der Wahl; es ist immer so. |
| Kontoinhaberschaft – wessen Cloud-Konto ist es? | Von TRANXACT gehostet: Ein dediziertes Konto oder Abonnement, das von TRANXACT bereitgestellt wird. Im Besitz des Kunden: Das eigene Konto des Kunden, das von TRANXACT über eine delegierte Automatisierungsrolle verwaltet wird. | Vor der Unterzeichnung; wird in den Vertragsanhang aufgenommen. |
| Zugangsposition – wie wird sie erreicht? | Öffentlich: Benutzer erreichen die Seite über HTTPS im Internet (Standardeinstellung). Nur privat: Der öffentliche Listener ist geschlossen und nur über VPN, private Verbindung oder Peering erreichbar. | Vor der Unterzeichnung, mit der Verbindungsoption. |
Es gibt keine mandantenfähige, gemeinsam genutzte „öffentliche Mandanten“-Edition von TRANXACT Private Cloud. Wenn ein Kunde von einem öffentlichen Mandanten spricht, meint er fast immer eine Bereitstellung, die über das Internet erreichbar ist – was der Standardzustand eines dedizierten Mandanten ist und nicht ein anderes Produkt darstellt.
Kontoinhaberschaft
| TRANXACT-gehostet | Kundeneigentum | |
|---|---|---|
| Wer erstellt das Konto? | TRANXACT (INFRA_2.1.01) | Der Kunde: erstellt es, richtet die Abrechnung ein, wendet Landing-Zone-Richtlinien an und gewährt die Automatisierungsrolle TRANXACT (INFRA_2.1.02, Ausgeschlossen) |
| Wer bezahlt die Cloud-Rechnung? | Gemäß dem Bestellformular | Dem Kunden werden die Gebühren direkt vom Anbieter zu dessen Listenpreisen in Rechnung gestellt. |
| Reservierte Kapazität | TRANXACT empfiehlt (INFRA_2.1.05) | TRANXACT empfiehlt; der Kunde kauft (INFRA_2.1.06, Ausgeschlossen) |
| Leitplanken, Kennzeichnung, Budgetwarnungen | TRANXACT (INFRA_2.1.04) | TRANXACT wendet sie innerhalb der Landing-Zone-Richtlinien des Kunden an. |
| RACI | Kundenforderungen für Konto, Landing Zone und Abrechnung in beiden Fällen; TRANXACT wurde konsultiert. |
In jedem Fall stellt TRANXACT ein separates Tresorkonto bzw. einen Mandanten mit eigenen Identitäten, MFA und Schlüsseln bereit (INFRA_2.1.03). Dieses Konto befindet sich niemals im selben Konto wie die Produktionsumgebung – siehe Verfügbarkeit, Live DR, Backup und Tresor.
Reservierte Kapazität senkt die Rechenkosten typischerweise um 30–40 %. Bei einem Kundenkonto ist der Kunde für die Beschaffung verantwortlich, daher sollte die Empfehlung nicht nur der IT-Abteilung, sondern auch der Finanzabteilung vorgelegt werden.
Umgebungen
Eine Umgebung ist eine isolierte TRANXACT-Instanz – Produktion, Test/QA, Schulung oder Sandbox. Die Nutzungsebene umfasst mehrere davon:
| Stufe | Umgebungen umfassten |
|---|---|
| S | Produktion + 1 Nicht-Produktion |
| M | Produktion + 2 Nicht-Produktion |
| L | Produktion + 3 Nicht-Produktion |
| XL | Pro Landschaft |
- Nicht-Produktionsdatenbanken werden ohne HA-Standby-Datenbank betrieben.
- Live DR fügt in der zweiten Region eine vollständige Kopie der Produktionszeile hinzu.
- Weitere Nicht-Produktionsumgebungen sind optional (TO_4.1.04) und werden nach Nutzungsstufe dimensioniert.
- Eine Migrationsumgebung für das erste Jahr ist optional (MIG_8.1.03) und wird nach der Umstellung außer Betrieb genommen (TO_4.1.05, eine Standard-Serviceanfrage).
- Die Verfügbarkeit außerhalb der Produktion beträgt 95 %, gemessen auf monatlicher Basis.
Eine Übersicht nach Vertragsjahr (Beispiel, Stufe M)
| Umfeld | Zweck | Knoten | Verwaltete Datenbank | Jahr 1 | Jahrgänge 2–5 |
|---|---|---|---|---|---|
| PRD | Produktion | 3 × 8 vCPUs / 32 GB | 8 vCPUs / 64 GB HA, 1 TB | Ja | Ja |
| DR | Live DR von PRD | 3 × 8 vCPUs / 32 GB | Replikat, 1 TB | Ja | Ja |
| QAS | Test / Regression | 3 × 4 vCPUs / 16 GB | 4 vCPUs / 32 GB, 1 TB | Ja | Ja |
| TRN | Training / Sandbox | Geteilt mit QAS | 2 vCPUs / 16 GB, 500 GB | Ja | Ja, verkleinert |
| MIG | Migrations-Testlasten | 3 × 8 vCPUs / 32 GB | 8 vCPUs / 64 GB, 1 TB | Ja | Nein – außer Dienst gestellt |
| Gewölbe | Air-Gap-Backups | — | Nur Lagerung | Ja | Ja |
Planen Sie das erste Jahr mit den zusätzlich benötigten Migrations- und Schulungskapazitäten und reduzieren Sie diese anschließend schrittweise. Jede Änderung stellt einen Änderungsantrag dar; daher sollte die schrittweise Reduzierung jetzt im Angebot festgehalten werden, anstatt sie im zweiten Jahr zu verhandeln.
Reihenfolge der Etappen
- Vor der Unterzeichnung müssen Kontoinhaberschaft, Region und Live DR Region festgelegt werden. Region, Adressbereiche, FQDN und Datenbank-Engine können nach dem Start des Builds nicht mehr ohne erneuten Build und Änderungsantrag geändert werden.
- Bei kundeneigenen Accounts erstellt der Kunde das Konto, wendet seine Landing-Zone-Richtlinien an und vergibt die Automatisierungsrolle – parallel zum Vertragsabschluss.
- TRANXACT richtet das Tresorkonto ein und wendet Schutzmechanismen, Kennzeichnungen und Budgetwarnungen an.
- Das Netzwerk wird pro Region aufgebaut: eine dedizierte VPC/VNet mit ihren Subnetzen (siehe Netzwerktopologien).
- Aufbau von Umgebungen aus Infrastructure-as-Code (TO_4.1.01): der Cluster, die HA-Datenbank, der Objektspeicher und die Live DR Region, falls vertraglich vereinbart.
- Kopieren Sie die Infrastruktur als Code und die Konfiguration in den Vault (TO_4.1.06). Die Laufzeitumgebung wird neu erstellt, nicht wiederhergestellt.
- Die Zugangsdaten werden ausschließlich an den benannten technischen Ansprechpartner gesendet (TO_4.1.02); der Kunde überprüft die Konnektivität und SSO (TO_4.1.03).
Zugangshaltung
| Öffentlich (Standard) | Nur für Privat | |
|---|---|---|
| Wie Benutzer ankommen | Öffentliches DNS → globaler Traffic-Manager → Load Balancer + WAF über TLS 1.2+ | Kunden-DNS-Privatzone → VPN / private Verbindung → interner Load Balancer |
| Was es braucht | Ein FQDN, ein öffentlicher DNS-Eintrag, ein Zertifikat einer öffentlichen Zertifizierungsstelle | All das, plus private Konnektivität, eine private DNS-Zone oder bedingte Weiterleitung |
| Eingrenzen | Optionale IP-Zulassungsliste für den öffentlichen Listener (INFRA_2.6.04, Standard) | Der öffentliche Zuhörer wurde geschlossen (INFRA_2.6.05, Optional) |
| Remote-Benutzer | Direkter Zugriff, SSO und MFA über den Kunden-IdP | Für den privaten Pfad wird ein VPN- oder Zero-Trust-Zugriff benötigt. |
| Zeit, live zu gehen | Am schnellsten – kein Netzwerkaufbau erforderlich | Länger – Adressplanung, Routing, Firewall und DNS arbeiten auf dem kritischen Pfad |
Entscheiden Sie frühzeitig, ob ein reiner HTTPS-Zugriff ausreicht. Private Verbindungen bedeuten zusätzlichen Aufwand, der den kritischen Pfad für die Inbetriebnahme beeinträchtigt, und die Bestellung privater Verbindungen beim Netzbetreiber dauert oft Wochen.
Die als Standardvorschlag gekennzeichneten Werte sind die im Bereitstellungsleitfaden empfohlenen Ausgangspunkte. Bitte bestätigen Sie jeden Wert für jeden Kunden einzeln. Vertrag, Bestellformular, SLA und DPA haben Vorrang vor den Angaben auf dieser Seite.
Machen Sie dazu den Kurs, mit Diagrammen und einer Überprüfung.