Zielgruppe BetriebVersion: GSB10.1Beispielhafte Konfiguration

• Benutzer
• Verzeichnisse
  • Bewegungsdaten- und Datenverzeichnisse
• Domainnamen und Zonen
• Service- und Servernamen
• Ports
• Kommunikationsmatrix

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.

Benutzer

Die Installation des GSB und der GSB Komponenten erfolgt durch einen gsbos-Benutzer der auf den Servern eingerichtet werden muss. Der Nutzer ist wie folgt anzulegen:

Tabelle 1: gsbos-Benutzer

Parameter	Wert
LOGIN	gsbos
GROUP	gsbos
HOME_DIR	/home/gsbos
SHELL	/bin/bash

Verzeichnisse

Die folgende Beschreibung geht davon aus, dass die GSB Komponenten als Benutzer „gsbos“ installiert werden. Für die Vorbereitung und Durchführung der Installation werden die folgenden Verzeichnisse benötigt:

Tabelle 2. Benötigte Verzeichnisse

Verzeichnis	Inhalt
/home/gsbos/config	Enthält die zu verwendende Konfiguration für die Installation des GSB. Da der Standard-Benutzer für die Installation „gsbos“ ist, ist der Default-Pfad somit „/home/gsbos/config“
/home/gsbos/releases/core	Basisverzeichnis für die Ablage der GSB Kernreleases. Unterhalb dieses Verzeichnisses muss für jedes auf der Plattform vorhandene Kernrelease ein (Versions-)Unterverzeichnis angelegt werden in dem das jeweilige Kernrelease abgelegt wird.
/home/gsbos/releases/customers	Basisverzeichnis für die auf der Plattform gehosteten GSB-Mandanten. Jeder Mandant wird in einem dedizierten Unterverzeichnis verwaltet. Unterschiedliche Mandantenversionen werden in einem entsprechenden Versionsordner abgelegt. Der Unterordner …/customers/standardlsg/1.0.0 beinhaltet bspw. die Version 1.0.0 der Standardlösung.
/home/gsbos/platformBundle	Die auf der Hostingplattform erstellten und benötigten Platform-Bundles werden in diesem Verzeichnis abgelegt.
/opt/gsbos	Installationsverzeichnis der GSB Komponenten.
/opt/gsbos/runtime	Runtime-Konfigurationen der einzelnen GSB Komponenten werden in diesem Verzeichnis bereitgestellt.

Die Vorlagendateien und Beispielkonfigurationen gehen davon aus, dass der Tomcat-Server unter /opt/software/tomcat/default installiert ist. Ist dies nicht der Fall, dann sollte durch den Systembetrieb ein entsprechender symbolischer Link angelegt werden.

Das für die Installation zu verwende Release wird nach der oben definierten Struktur somit in /home/gsbos/releases/core/10.1.0-rc4 und /home/gsbos/releases/customers abgelegt werden.

Bewegungsdaten- und Datenverzeichnisse

Der GSB 10 speichert einige Daten im Dateisystem des zugrundeliegenden Servers. Hierbei handelt es sich um persistente Daten wie bpsw. das Contentrepository der CMS-Servers sowie Bewegungsdaten wie Logfiles und temporäre Daten, die nur zur Laufzeit einer Komponente erzeugt und benötigt werden. Diese Daten werden jeweils in dedizierten Basisverzeichnissen gespeichert und sind aus Sicht des System- bzw. Applikationsbetriebs jeweils unterschiedlich zu behandeln.

Die exemplarische Konfiguration geht davon aus, dass alle Datenverzeichnisse unterhalb des Basisverzeichnisses /space/gsbos abgelegt werden. Die unterschiedlichen Datenarten des GSB 10 werden jeweils in dedizierten Unterverzeichnissen in dem skizzierten Basisverzeichnis abgelegt, die in der folgenden Tabelle vorgestellt werden.

Verzeichnis	Inhalt
/space/gsbos/data	Im Data-Verzeichis werden alle persistenten Daten der GSB Komponenten abgelegt. Dieses Verzeichnis beinhaltet somit alle zu sichernden Dateien. +
/space/gsbos/logs	Log-Dateien der GSB Komponenten werden in dem Logs-Verzeichnis abgelegt.
/space/gsbos/temp	Temporäre Dateien werden unterhalb des Temp-Ordners abgelegt.

Hinweis:

Das Data-Verzeichnis (/space/gsbos/data) beinhaltet alle persistenten Dateien einer GSB Infrastruktur. Hierbei handelt es sich insbesondere um das Content-Repository und die zugeordneten Solr-Indices. Es empfiehlt sich daher in einer produktiven Infrastruktur dieses Verzeichnis in ein dediziertes Filesystem auszulagern. Das Filesystem muss hinreichend groß dimensioniert sein, um sowohl den aktuellen Informationsbestand speichern zu können als auch zusätzliche Daten bpsw. durch redaktionelle Tätigkeiten, automatische Importe oder neue Mandanten speichern zu können. Darüber hinaus sollte sichergestellt werden, dass keine anderen Serverkomponenten schreibend auf dieses Filesystem zugreifen, um so ein unbeabsichtigtes Volllaufen des Filesystems verhindern zu können. Um bei sich ankündigenden Engpässen schnell reagieren zu können empfiehlt sich ein dediziertes Monitoring des Füllstandes des Data-Verzeichnisses mit hinreichend konservativ gewählten Alarmierungspaarametern, um frühzeitig reagieren und zusätzlichen Speicherplatz im Data-Verzeichnis bereitstellen zu können.

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).
• site.master.example.com entspricht den Site-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 Site-Server jeweils nur einmal vorhanden, so dass für jeden Service ein eindeutiger „Service-Name“ verwendet wird. Die in einer Zone redundant ausgelegten Site-Server der Beispielkonfiguration werden unter dem Namen site.<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
• Site: 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 Site-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 Site-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.