Zielgruppe BetriebVersion: GSB10.0Beispielhafte Konfiguration

Diese Beispielkonfiguration ist so angelegt, dass

• Ein Betrieb aller Komponenten auf einem Server grundsätzlich möglich ist sowie
• Eine ausfallsichere und redundante Auslieferung der Live-Auftritte unterstützt wird.

D.h. die benötigten GSB Services sind von Ihren Servernamen und benötigten Ports überlappungsfrei definiert, so dass ein gleichzeitiger Betrieb auf einem Server möglich ist. Weiterhin sind die Komponenten der Live-Auslieferung mehrfach vorhanden, so dass auf dieser Basis einfach der Aufbau einer skalierbaren und redundanten Hosting Plattform abgeleitet werden kann.

Der Aufbau der exemplarischen Beispielkonfiguration wird in den folgenden Kapiteln näher beschrieben.

Domainnamen und Zonen

Die exemplarische Beispielkonfiguration nutzt die Domain example.com, d.h. alle Domain und auch Servernamen sind Bestandteil der für Testzwecke zu verwendenden Domain example.com.

Für die weitere Strukturierung und Verteilung der einzelnen GSB Services in unterschiedliche Zonen werden Subdomains verwendet. Im Einzelnen werden für die Beispielkonfiguration die folgenden Subdomains genutzt:

• preview.example.com enthält alle GSB Services des Redaktionssystems wie Content-, Workflowserver, Editor, Preview, Solr
• master.example.com ist Bestandteil der Live-Umgebung und enthält alle Services der Liveauslieferung. Das Master-Contentrepository nimmt hierbei die zentrale Rolle ein, da publizierte Inhalte in dieses Repository publiziert werden.
• replication.example.com ist ebenfalls Bestandteil der Live-Umgebung und ermöglicht den Aufbau einer redundanten u. ausfallsicheren Liveumgebung.
• service.example.com enthält GSB Services, die Basisdienste und Services bereitstellen und aus der Live- bzw. der Preview-Umgebung genutzt werden.
• database.example.com enthält die für den Betrieb der GSB Infrastruktur benötigten Datenbanken.
• extern.example.com enthält externe Systeme, die kein essentieller Bestandteil der GSB Infrastruktur sind. Hierzu zählt bspw. ein externer Mailserver

Die oben skizzierten Zonen bzw. Domainnamen dienen lediglich der logischen Strukturierung und Gruppierung der GSB Services und ermöglichen eine einfache Identifikation von aus fachlicher Sicht zusammengehörigen Komponenten.

Für den Aufbau einer konkreten Hosting-Infrastruktur und Verteilung der GSB Services auf Server und Zonierung der Server können die Zonen der Beispielkonfiguration als Grundlage und Ausgangspunkt genommen werden.

Die folgende Grafik verdeutlicht die logische Struktur der Domänen und Zonen. Die in der Grafik mit Webserver verzeichnete Zone ist in der Beispielkonfiguration nicht als explizite Zone definiert, da diese Zone nur den Webserver enthält, der über die dort definierten VirtualHost-Definitionen für den Zugriff von außen (Redakteure, SiteAdministratoren, Internetnutzer) zuständig ist.

Service- und Servernamen

Die einzelnen GSB Services, die als identifizierbare Komponente in Form eines Prozesses gestartet und betrieben werden, werden in der Beispielkonfiguration jeweils über einen dedizierten Servernamen angesprochen.

Das zugrundeliegende Namensschema für die Benennung der Service- und Servernamen entspricht dem Schema <SERVICE>.<ZONE>.example.com und wird anhand der folgenden Beispiele verdeutlicht:

• repository.preview.example.com entspricht dem Content-Repository der Redaktionsumgebung (Service=repository, Zone=Preview),
• repository.replication.example.com entspricht dem Replication Content-Repository (Zone Replication).
• delivery.master.example.com entspricht den Delivery-Servern der Master-Zone
• preview.database.example.com entspricht dem DB-Server unter dem die Preview Content-Repository Datenbank angesprochen wird.

Die GSB Services innerhalb einer Zone sind bis auf die Delivery-Server jeweils nur einmal vorhanden, so dass für jeden Service ein eindeutiger „Service-Name“ verwendet wird. Die in einer Zone redundant ausgelegten Delivery-Server der Beispielkonfiguration werden unter dem Namen delivery.<ZONE>.example.com angesprochen.

Hinweis:

Die Verwendung der dedizierten Servicenamen in der Beispielkonfiguration soll wie angedeutet eine einfache Identifikation der anzupassenden Properties ermöglichen, wenn Servicenamen auf konkrete Hostnamen geändert werden sollen. Für den Aufbau einer konkreten Hostingplattform können die Servicenamen der Beispielkonfiguration auf den Hostnamen auf dem die Services betrieben werden sollen umgeschrieben werden.

Ports

Die einzelnen GSB Service-Instanzen nutzen jeweils individuelle Ports die folgenden Anforderungen erfüllen:

• Eine Portdefinition für alle Service-Instanzen der Beispielkonfiguration ohne Überlappungen verwendet wird. So wird sichergestellt, dass alle Service-Instanzen grundsätzlich auf einem Server betrieben werden können.
• Die genutzten Ports eine einfache Identifikation der Zone (s.a. Abschnitt "Domainname und Zonen") sowie des zugrundeliegenden Service-Typs ermöglichen.

Um eine möglichst homogene Konfiguration für die genutzten Ports bereitzustellen sieht die exemplarische Beispielkonfiguration das dem folgenden Schema folgt:

Die einzelnen Zonen verwenden dedizierte und überlappungsfreie Portranges für die GSB Tomcat-Service-Instanzen. So wird sichergestellt, dass alle GSB Komponenten konfliktfrei auf einem Server betrieben werden können. Für jede Zone ist ein 1000er Block vorgesehen. Die folgenden Blöcke werden in der Beispielkonfiguration genutzt:

• Preview-Zone: 6xxxx
• Master-Live-Zone: 7xxxx
• Replication-Live-Zone: 8xxxx
• Service-Live-Zone: 9xxxx

Die einzelnen Tomcat-Service-Instanzen werden je nach Service-Typ mit den folgenden Subranges konfiguriert (100er Block):

• Repository: x0xx
• Delivery: x1xx-x3xx
• Solr: x4xx
• Service: x5xx
• Adminportal: x6xx
• CAS: x7xx
• Maildistributor: x8xx

Wie dem skizzierten Schema zu entnehmen ist steht für jeden Typ ein 100er-Block zur Verfügung. Die Delivery-Tomcats nutzen einen 300er-Block. Jede Tomcat-Instanz nutzt einen 10er-Block, so dass in einer Zone grundsätzlich 10 Instanzen eines Typs bzw. 30 Delivery-Instanzen betrieben werden können.

Hinweis:
Das in der Beispielkonfiguration verwendete Schema für die Definition der Ports der einzelnen Service-Instanzen dient der einfachen Strukturierung der Definitionen der Beispielkonfiguration und kann beim Aufbau einer konkreten Hostingplattformen bei Bedarf an die individuellen Belange der Hostingplattform angepasst werden.

Kommunikationsmatrix

Die in der Beispielkonfiguration genutzten Kommunikationsbeziehungen sind in der Kommunikationsmatrix (Dokument „GSBOS-Beispielkonfiguration-Kommunikationsmatrix.xlsx“) zusammengestellt. Das Excel Sheet definiert für jede einzelne Service-Instanz der Beispielkonfiguration (Quellsystem) die benötigten Kommunikationsendpunkte (Zielsystem).

Die Quellsysteme können mit Hilfe der vorhandenen Excel-Filter einfach auf Servicename, Service-Typ bzw. Service-Instanz gefiltert werden. Die gleichen Filtermöglichkeiten stehen auch für die Zielsysteme zur Verfügung.