Ein Design für alle Kunden. Cloud-spezifische Unterschiede – das Verbindungsprodukt, der Schlüsseldienst, die Datenbank-Engine – sind Konfigurationsoptionen, keine grundlegenden Neuentwicklungen. Dadurch lässt sich eine Umgebung innerhalb von fünf Arbeitstagen per Code erstellen.
Das Bild von oben betrachten
- Benutzer und Integrationen greifen über den Namen erp.<Kundendomäne> auf einen Load Balancer mit WAF über HTTPS, TLS 1.2 oder höher zu. Dies ist der einzige öffentliche Zugangsweg.
- Mindestens drei Worker-Knoten, einer pro Verfügbarkeitszone, betreiben Web- und API-Dienste, die Posting-Engine, den ASK-Operator sowie Worker und Jobs. Fällt ein Knoten oder eine ganze Zone aus, steht den Nutzern weiterhin Kapazität zur Verfügung.
- Die verwaltete Datenbank – Engine und Größe nach Wahl des Kunden – verfügt über einen synchronen Standby-Server in einer anderen Zone. Bei einem Zonenausfall entstehen keine Datenverluste: RPO ≈ 0.
- Dokumente und Anhänge werden in einem versionierten Objektspeicher und nicht in der Datenbank gespeichert.
- Ausgehender Datenverkehr wird über NAT an eine Zulassungsliste weitergeleitet: Banken, Steuer- und E-Rechnungswesen, Gehaltsabrechnung, E-Mail, KI-Engine. Sonst nichts.
- Die Backups werden unidirektional in einen vom Internet getrennten Datenspeicher auf einem separaten Konto übertragen.
Der private Endpunkt und der interne Load Balancer sind gestrichelt dargestellt, da sie nur bei Verwendung des privaten Zugriffs existieren. Bei reinem HTTPS-Zugriff werden sie nicht erstellt.
Fünf Knöpfe, sonst nichts.
Knotengröße; Knotenanzahl (mindestens drei); Datenbank-Engine und -Größe; die Live DR Region; die Anzahl der Umgebungen. Alles andere entspricht der Referenzarchitektur.
Konfigurieren, integrieren und erst dann programmieren
Anforderungen, die über den Standard hinausgehen, werden durch Konfiguration erfüllt, sofern sie mit der Plattform aktualisiert werden können. Andernfalls erfolgt die Integration über TRANXACT-APIs, die außerhalb des Clusters ausgeführt werden. Erst dann wird Code oder ein Agent innerhalb des Clusters nach einer Sicherheits- und technischen Prüfung in Betracht gezogen. Bei Genehmigung wird er toleriert und vom Kunden unterstützt, andernfalls wird er außerhalb ausgeführt.
Für den Kunden besteht kein direkter Datenbankzugriff – dieser ist als „nicht angeboten“ gekennzeichnet (DB_3.1.09). Reporting und Integration erfolgen über TRANXACT-APIs und -Extraktionen. Aus diesem Grund wird ein BI-Tool auch per API oder geplanter Extraktion angebunden, niemals über eine Datenbankanmeldung.
Das BI-Team von Calderwood benötigt einen Datenbankbenutzer mit Lesezugriff für ihr Data Warehouse. Die Antwort lautet: ein geplanter Datenextrakt über eine private Verbindung – die entsprechende Zeile in ihrer Schnittstellenliste lautet: „Beibehalten, geplanter Datenextrakt, private Verbindung“.
Probier es aus Ein Worker-Knoten in Zone 2 fällt während des Monatsendes von Calderwood aus. Was passiert mit den Benutzern, und wirkt sich das auf die Service-Level-Vereinbarung (SLA) aus?
Die Pods werden auf die Knoten in den Zonen 1 und 3 umgeplant, die für die Last ausgelegt sind; die Datenbank bleibt unberührt, es sei denn, Zone 2 ist der primäre Server; in diesem Fall erfolgt ein Failover auf den synchronen Standby-Server mit RPO ≈ 0. Die Verfügbarkeit wird nur dann auf die SLA angerechnet, wenn das monatliche Verfügbarkeitsziel verfehlt wird.