Version: GSB 7Systemarchitekturen

Contents 1 System-Architektur-Vorschläge für unterschiedliche Szenarien 1.1 Single-Server-System mit lokaler Datenbank 1.1.1 Single-Server-System mit separater Datenbank 2 Produktionsumgebungen 3 Produktionsumgebung - default (redundant / 3-Tier) 3.1 Skalierungsoptionen 4 Produktionsumgebung - minimal (redundant / 2-Tier) 5 Produktionsumgebung - strikte Komponenten-Trennung (redundant / 3-Tier)

1 System-Architektur-Vorschläge für unterschiedliche Szenarien

Die grundlegenden Systemarchitekturen des GSB 7.2 bleiben auch für den GSB 7.5 gültig.

Der konkrete Entwurf einer Systemarchitektur ist von vielen Faktoren abhängig und im Kontext der konkreten Hosting-Umgebung abzustimmen.

Exemplarische Einflussfaktoren für produktive Umgebungen

• Wird ein vollständig SAGA und BSI-konformer DMZ-Aufbau (3-Tier-Architektur) verfolgt? Dann ist eine Trennung von Delivery und CAE eventuell notwendig.
• Existieren Loadbalancer, die SSL-terminieren? Werden diese als Teil der Plattform verstanden und stellen diese dann die Web-Tier dar? Dann können die übrigen Komponenten in die App und DB-Tier installiert werden. Entsprechend können CAE und Delivery zusammengefasst werden. Genügt eine einfache Redundanz mit zwei Strängen in der Live-Umgebung? Dann genügt evt. neben dem content-server-master ein einzelner content-server-replication. Möchte den content-server-master nicht in die Live-Auslieferung integrieren, muss ein zweiter content-serverreplication bereitgestellt werden.
• Werden die Datenbanken als "echtes Cluster" betrieben, können mehrere Content-Server-DBs in diesem Cluster angelegt werden, dann sind die DB-Konfigurationen der content-server anzupassen. Möchte man auch auf DB-Ebene Redundanzen, z.B. weil die Wartungskonzepte der Datenbanken keinen unterbrechungsfreien Betrieb des Clusters ermöglichen, sind Single-Instance-Datenbanken zu bevorzugen.
• Wird auch an die Redaktionsumgebung ein erhöhter Verfügbarkeitsanspruch gestellt, sollte auch in der Redaktion über eine Trennung der Komponenten auf mehrere Server und eine redundante Auslegung nachgedacht werden.

1.1 Single-Server-System mit lokaler Datenbank

Für Entwicklungs- und interne Testsysteme bietet sich die Installation aller Komponenten inklusive Datenbanken auf einem einzelnen Server an. Je nach Testszenario kann ggf. auf Live-Komponenten verzichtet werden. Eine exemplarische Aufstellung der Komponenten findet sich in
/gsb-cm/infrastructure/src/main/dist/install/config/ref/instances .

Die Datenbankinstallation und Bereitstellung eines LDAP-Servers sollte idealerweise im Vorfeld erfolgen.

1.1.1 Single-Server-System mit separater Datenbank

In den Rechenzentren des Bundes ist in der Regel eine strikte Trennung der Datenbanken auf dedizierten Systemen gewünscht. In diesem Fall können analog zum vorherigen Beispiel alle GSB-Komponenten auf einem Applikationsserver betrieben werden und die notwendigen Datenbanken werden auf einem separaten System bereitgestellt.

Dieser Ansatz bietet sich für Staging-/Abnahme-/Referenzumgebungen in der Infrastruktur des Hosters an. Auch hier kann je nach Testszenario ggf. auf Live-Komponenten verzichtet werden. Eine exemplarische Aufstellung der Komponenten findet sich in

/gsb-cm/infrastructure/src/main/dist/install/config/ref/instances

2 Produktionsumgebungen

Die Verteilung der Komponenten auf mehrere Server erfolgt nach Vorgaben des jeweiligen Hosters. Je nach internen Prozessen und Vorgaben kann entweder die Anzahl der Systeme reduziert werden, z.B. um die Zahl der zu verwaltenden Systeme zu beschränken und vorhandene Systeme möglichst gut auszulasten oder die Komponenten werden auf verschiedene Systeme verteilt um Wartungsprozesse zu vereinfachen und Ausfallzeiten zu reduzieren.

3 Produktionsumgebung - default (redundant / 3-Tier)

Eine exemplarische Verteilung von Komponenten auf Server findet sich in

/gsb-cm/infrastructure/src/main/dist/install/config/prod/instances

Diese Architektur berücksichtigt folgende Überlegungen:

• Die Redaktion (preview) beherbergt alle Dienste die zur Pflege des Contents benötigt werden (vgl. instances.preview)
• Der Administrationsserver (admin) beherbergt die Komponenten der GSB-Administration und ergänzende Services für z.B. den Newsletter- Versand und die Anbindung von CMIS (vlg. instances.admin)
• In der Liveumgebung beherbergt der Master lediglich den content-server-master, solr-master und indexer-master, es werden keine CAEs an
  den Master verbunden (vgl. instances.master)
• An den Master werden Replikationsserver verbunden, die sowohl den content-server-replication als auch den solr-replication anbieten (vgl.instances.replication)
• Die CAEs verbinden sich ausschließlich mit Replikationsseervern (vgl. instances.cae)
• Master, Replication und CAE sind in der App-Tier verortet, da diese Dienste Datenbankzugriff benötigen.
• Die Deliveries werden in der Web-Tier verortet und beherbergen lediglich den Webserver der Anfragen an die CAEs weiterleitet (vgl. instances.delivery)
• Wenn die Plattform einen eigenen CMIS-Server betreibt ist die Verortung dieser Instanz zu entscheiden (Erreichbarkeit im Internet oder nur innerhalb der eigenen Infrastruktur) und davon abhängig zu überlegen, ob ein dedizierter Server notwendig ist, oder ob die Instanz auf einem bestehenden System installiert werden soll.
• Zur Herstellung der notwendigen Redundanz sind mindestens folgende Systeme zu betreiben
• 2x Delivery - jeder Delivery leitet dediziert an eine CAE-weiter
• 2x CAE - jede CAE hängt an einem "eigenen" Replication
• 2x Replication
• 1x Master
• 1x Admin
• 1x Preview

3.1 Skalierungsoptionen

Um eine höhere Redundanz und Lastverteilung zu erreichen bietet sich insbesondere die Komponente CAE an. Je nach System-Ressourcen und Konfiguration der Deliveries, CAEs und Replication-Server kann das Verhältnis dieser 3 Servertypen zueinander variieren. Unter "default"- Parametern und mit konservativem Sizing der Komponenten sollten folgende Verhältnisse ein Ausgangspunkt für weitere Überlegegungen sein könnnen.

• Aus Überlegungen der Symetrie werden nur ganzzahlige Vielfache betrachtet
• Deliveries leiten in der Regel nur Anfragen an die CAEs weiter, Deliveries können in der Regel eine höhere Zahl an Anfragen verwalten, als diese von den CAEs verarbeitet werden können. Daher sollten einem Delivery 2-4 CAEs zugeordnet werden können, d.h. 4-8 Instanzen verteilt auf 2-4 Server.
• Da sowohl die CAEs als auch die Replication-Server über Caches verfügen, können 2-4 Server/4-8 CAE-Instanzen pro Replication-Server betrieben werden. D.h. folgende Architektur ist auch unter konservativen Rahmenbedingungen möglich
• 2x Delivery - jeder Delivery leitet dediziert an eine CAE-weiter
• 4x CAE - jede CAE hängt an einem "eigenen" Replication (je 2 CAE-Instanzen je Server)
• 2x Replication
• Die Zahl der Apaches sollte nicht geringer sein als die Zahl der Replikationserver, damit Wartungsarbeiten z.B. an den dahinterliegenden Datenbanken gezielt steuern zu können.
• Bei Bedarf können natürlich auch weitere Apaches vorgeschaltet werden.
• Auch eine weitere horizontale Skalierung der CAEs ist möglich, hier sollten dann die Betriebsparameter im produktiven Betrieb ausgwertet werden um zu ermitteln an welchen Stellen Engpässe entstehen. Je nach Charakteristik der konkreten Plattform sind unterschiedliche Lösungsstrategien zu wählen.
• Viele Anfragen auf eine Seite/einen Mandanten erzeugen viele separate Sessions am Delivery und an der CAE, werden dort aber in der Regel durch die Caches effizient bedient
• Anfragen auf viele unterschiedliche Seiten/SubSites/Mandanten auf einer "shared" Plattform verursachen tendenziell eher Cache-Misses und schlagen daher häufiger auf Replication-Server und Datenbanken durch

4 Produktionsumgebung - minimal (redundant / 2-Tier)

Sollten die Infrastrukturkomponenten der Hostingumgebung (Loadbalancer/WAF) der Web-Tier der Plattform zugerechnet werden, kann auf eine Trennung von Delivery und CAE verzichtet werden. In der Web-Tier werden dann keine GSB-Komponenten betrieben und die Architektur lässt sich auf App-Tier und DB-Tier begrenzen. In diesem Fall bleiben die Architekturvorschläge des vorherigen Kapitels weiterhin gültig und es kann z.B. weiterhin ein Apache vor 2 CAE-Instanzen betrieben werden. Für dedizierte Plattformen mit minimaler Anforderungen besteht die Möglichkeit, die Dienste weiter zusammenzulegen. Denkbar wäre dann eine Architektur mit nur zwei Servern in der App-Tier (zzgl. Datenbanken)

• Master - mit folgenden Instanzen
• content-server-master
• indexer-master
• solr-master
• maildistributor-live
• cae-live1
• cae-live2
• Apache2
• Replication - mit folgenden Instanzen
• content-server-replication
• solr-replication
• maildistributor-live
• cae-live1
• cae-live2
• Apache2

5 Produktionsumgebung - strikte Komponenten-Trennung (redundant / 3-Tier)

Sollte aus betrieblichen Überlegungen eine weitere Aufgliederung der einzelnen Komponenten und Instanzen auf mehrere Server notwendig sein, so ist dies mit dem vorliegenden Ansatz durchaus möglich. Solange die Kommunikationsbeziehungen der Komponenten gewährleistet sind (vgl. Kommunikationsmatrix), können alle Komponenten auf isolierten Servern betrieben werden.