Zielgruppe BetriebVersion: GSB10.1Betriebsmodell

• 1 Prinzipieller Aufbau
  • 1.1 GSB Tomcat-Instanz
  • 1.2 GSB HTTPD-Webserver
  • 1.3 Service-Typ
• 2 Exemplarische GSB Basisarchitekturen
  • 2.1 Redaktionsumgebung
  • 2.2 Liveumgebung
  • 2.3 Minimale Liveumgebung
  • 2.4 Ausfallsichere Auslieferung
  • 2.4 Multi-Server Auslieferung
  • 2.6 Redundante Auslieferung
• 3 Betriebsprozesse
  • 3.1 Starten und Stoppen
  • 3.2 Monitoring und Logging
  • 3.3 Datensicherung

1 Prinzipieller Aufbau

Darüber hinaus wird noch ein Apache Webserver benötigt, der die http-Requests der Nutzer an das auf Tomcat-Server basierten Auslieferungssystem des GSB weiterleitet. 

Der GSB und das GSB Release umfasst die eigentlichen GSB Applikationen und Komponenten. Diese stützen sich auf Basiskomponenten, die als Installations- und Betriebsvoraussetzung durch den jeweiligen System- und Applikationsbetrieb bereitgestellt werden müssen. Hierzu zählen insbesondere

• Java
• Tomcat-Server inklusiver der benötigten Datenbanktreiber
• Apache-Webserver
• OpenLDAP
• Tools zur Bildoptimierung (imagemagick, optipng, jpegtran) 

Durch die Entkopplung der Beistellungen vom eigentlichen GSB Release soll insbesondere sichergestellt werden, dass Updates der beigestellten Komponenten einfacher und unabhängig vom eingesetzten GSB Release durchgeführt werden können. 

Der GSB trennt strikt zwischen dem Build-Prozess und dem anschließenden Deployment des erzeugten GSB Builds. Im Rahmen des Build-Prozesses wird ein GSB Kernrelease mit den GSB Mandantenreleases zu einem sogenannten Platformbundle paketiert, welches dann durch das anschließende Deployment auf den GSB Servern installiert werden kann. 

Die Laufzeitkonfiguration der der einzelnen GSB Komponenten wird in Form von Runtime-Properties bereitgestellt. Die Runtime-Properties enthalten insbesondere plattformspezifische Informationen wie bspw. Servernamen, -ports, Datenbank-Connect-Strings, so dass die Erstellung und Bereitstellung der Laufzeitkonfiguration in die Zuständigkeit und Verantwortlichkeit des jeweiligen System- bzw. Applikationsbetriebs fällt.

1.1 GSB Tomcat-Instanz

Eine GSB Tomcat-Instanz basiert auf dem zugrundeliegenden Tomcat-Server und Basisbibliotheken wie bspw. dem jeweiligen Datenbankreiber der zu verwendenden Datenbank. Weiterhin werden in der Tomcat-Instanz eine Reihe von GSB Webapplikationen betrieben deren umgebungsspezifische Konfiguration in der Laufzeitkonfiguration ausgelagert ist. 

Eine Tomcat-Instanz ist damit grundsätzlich wie in der folgenden graphischen Darstellung aufgebaut:

Abbildung 1: GSB Tomcat-Instanz

Bei den blau eingefärbten Komponenten handelt es sich um die in der Einleitung zum Abschnitt „Prinzipieller Aufbau“ skizzierten Komponenten und Konfigurationen die als Beistellung des System- bzw. Applikationsbetriebs bereitzustellen sind. 

Die eigentliche GSB Applikation wird durch den GSB und das GSB Deployment bereitgestellt.

1.2 GSB HTTPD-Webserver

Der Aufbau des HTTPD-Webservers ist im Wesentlichen ähnlich zum Aufbau der Tomcat-Instanzen angelegt. Der eigentliche Webserver wird durch den Systembetrieb bereitgestellt und die durch den System- bzw. Applikationsbetrieb bereitzustellende Laufzeitkonfiguration entspricht der zentralen Konfigurationsdatei (httpd.conf) des Webservers sowie der benötigten Balancer-Definitionen für die Anbindung der Tomcat-Instanzen. 

Die applikationsspezifische Konfiguration umfasst die Virtual-Host-Definitionen der einzelnen Mandanten sowie der bereitgestellten Basiskonfigurationen (Macro-Definitionen). 

Damit ergibt sich der folgende schematische Aufbau für eine HTTPD-Instanz:

Abbildung 2: HTTPD-Instanz

Bei den blau eingefärbten Komponenten handelt es sich um die in der Einleitung zum Kapitel „Prinzipieller Aufbau“ skizzierten Komponenten und Konfigurationen die als Beistellung des System- bzw. Applikationsbetriebs bereitzustellen sind.

1.3 Service-Typ

Die applikationsspezifischen Anteile einer GSB Instanz umfassen wie skizziert nur die eigentliche Software der betreffenden Applikationen. Jegliche Laufzeitkonfiguration ist ausgelagert und wird der Instanz außerhalb des GSB in Form von Laufzeitkonfigurationen zur Verfügung gestellt. 

Dies hat zur Konsequenz, dass sich bspw. die GSB Anteile mehrerer Delivery-Tomcat-Instanzen nicht voneinander unterscheiden. Diese Instanzen enthalten in dem Fall

• Die GSB Kernapplikation site zur Auslieferung des GSB sowie
• Die mandantenspezifischen Implementationen der site-Applikation (d.h. die individuellen JSP-Templates und Darstellungslogiken) 

Da wie skizziert die zugrundeliegende GSB Software der Delivery-Tomcats identisch ist werden diese zu sogenannten Service-Typen zusammengefasst werden. Ein Service-Typ ist damit eine Art Vorlage oder Klasse für die Erzeugung einer Service-Instanz (d.h. eines laufenden GSB Prozesses). Auf einem GSB Server können damit dann alle Instanzen eines Delivery-Tomcats ein und dieselbe Installation des Service-Typen delivery nutzen. 

Der GSB unterstützt standardmäßig folgende Service-Typen: 

Tomcat-Server basierte Service-Typen:

• repository: Der Repository-Tomcat ist für den Import und die Speicherung der redaktionellen Inhalte im Content-Repository verantwortlich. Das Content-Repository der Replication-Liveserver basiert ebenfalls auf diesem Service-Typen
• repository-master: publizierte Inhalte werden in der Live-Umgebung in das Master-Repository publiziert. Zusätzlich werden die publizierten Inhalte noch an die Replication-Liveserver weitergeleitet, so dass das Master-Repository eine Erweiterung des Service-Typs repository darstellt.
• delivery: Der Service-Typ ist für die Generierung der GSB Webseiten zuständig.
• solr: Die GSB Suche wird im Service-Typen solr bereitgestellt.
• workflow: Die Workflow-Engine des GSB zur Publikation redaktioneller Inhalte wird durch den workflow-Service-Typen definiert.
• editor: Der GSB Editor wird im Service-Typen editor bereitgestellt
• service-preview: In der Redaktionsumgebung werden Indexer und Eventdispatcher im Service-Typen service-preview zusammengefasst.
• service-master: In der Live-Umgebung wird der Indexer im Service-Typen service-master zusammengefasst.
• adminportal: Das Adminportal steht im Service-Typen adminportal zur Verfügung
• cas: Das CAS basierte Single-Sign-On wird in diesem Service-Typen zur Verfügung gestellt.
• maildistributor: Der Maildistributor wird in diesem Service-Typen zur Verfügung gestellt

 HTTPD-Server basierte Service-Typen:

• httpd: Die GSB Webserver-Konfiguration wird in dem Service-Typen httpd gekapselt.

2 Exemplarische GSB Basisarchitekturen

Die in den folgenden Abschnitten vorgestellten Basisarchitekturen beschreiben verschiedene Infrastrukturen, die Grundlage und Ausgangspunkt für den Aufbau und Betrieb einer GSB-Infrastruktur sein können. Die skizzierten Basisarchitekturen sollen somit Plattformbetreiber und Selbsthoster in die Lage versetzen ihre konkreten Anforderungen an eine individuelle Hostinginfrastruktur mit den produktseitigen Empfehlungen abgleichen und konkrete Infrastrukturen entwickeln zu können. 

An dieser Stelle werden keine Empfehlungen zum Resourcenbedarf (CPU, Memory, Disc) einzelner GSB Komponenten ausgesprochen, da benötigten Resourcen stark vom jeweiligen Einsatzszenario abhängen und somit individuell unter Berücksichtigung der auf der jeweiligen Plattform zu betreibenden Mandanten geplant und plattformspezifisch angepasst werden müssen. 

Insofern sind die in den folgenden Kapiteln skizzierten Umgebungen als Schablone zu verstehen, d.h. sie stellen keinen Anspruch auf eine produktionstaugliche Infrastruktur, sondern geben nur Empfehlungen für eine entsprechen Basiskonfiguration. 

Grundsätzlich gilt, dass der GSB und die jeweiligen Komponenten auf linuxbasierten Servern installiert und betrieben werden. Hierbei kann es sich sowohl um virtuelle Server oder Bare-Metal-Server handeln. Die Bereitstellung und Einbindung der Server in die Infrastruktur ist nicht Bestandteil der folgenden Betrachtungen, so dass im weiteren Verlauf unter Server eine laufende Linux-Instanz zu verstehen ist, auf der GSB Komponenten betrieben werden. 

Die Einbindung der GSB Infrastruktur und –komponenten in die Netzwerkinfrastruktur und Betriebsinfrastruktur des Hostingplattformbetreibers wird in diesem Dokument nicht konkretisiert, da die entsprechenden Prozesse, Tools und eingesetzten Komponenten stark auf die individuellen Anforderungen des jeweiligen Hostingplattformbetreibers zugeschnitten sind und somit an dieser Stelle keine pauschalen Empfehlungen ausgesprochen werden können.

2.1 Redaktionsumgebung

Die Redaktionsumgebung wird zentral auf einem Server bereitgestellt und umfasst alle GSB Komponenten, die für die Durchführung der redaktionellen Arbeiten benötigt werden. Im Einzelnen handelt es sich um die folgenden Komponenten: 

• Content-Server beinhaltet das Content-Repository und ist für die Verwaltung und Speicherung des redaktionellen Contents aller GSB-Mandanten zuständig. Darüber hinaus stellt das Content-Repository auch Content-Im- und Exportfunktionen zur Verfügung, die durch den Applikationsbetrieb für administrative Zwecke genutzt werden können.
• Workflow-Server stellt die redaktionellen Publikations-Workflows für die Publikation von Inhalten der GSB-Mandanten zur Verfügung
• Preview-Server ist für die Erzeugung der Vorschau der Webauftritte der GSB-Mandanten zuständig
• GSB Editor-Server stellt den GSB Editor-Service für alle GSB-Mandanten zur Verfügung
• Web-Server ermöglicht den Redakteuren der einzelnen Mandanten den Zugriff auf den GSBEditor/web sowie auf die Preview der Mandanten
• Solr-Server stellt die Solr-Suche für den GSBEditor sowie die Preview der Mandanten zur Verfügung
• Service-Server stellt Service-Funktionalitäten der Redaktionsumgebung zur Verfügung. Im Service-Server wird der Indexer sowie EventDispatcher betrieben.

Abbildung 3: Logische Architektur (Redaktionsumgebung)

Die einzelnen Komponenten der Redaktionsumgebung stehen als dedizierte Single-Tomcat-Instanzen zur Verfügung. D.h. aktuell können die entsprechenden GSB Komponenten nicht redundant ausgelegt werden. 

Eine Skalierung der Redaktionsumgebung unter dem Gesichtspunkt der Lastverteilung bzw. zur Erhöhung der Ausfallsicherheit ist derzeit nicht durch möglich. Eine Redaktionsumgebung mit einer erhöhten Ausfallsicherheit kann durch einen Cold-Standby Ansatz bereitgestellt werden. Hierbei wird auf einem dedizierten Server ein Spiegel der aktuellen Redaktionsumgebung installiert und konfiguriert. Der Spiegelserver wird anschließend gestoppt. Bei Ausfall der aktiven Redaktionsumgebung wird der gestoppte Spiegelserver gestartet und kann so die Dienste des ausgefallenen Servers mit einer geringen Verzögerung übernehmen.

2.1.1 Datenbanken

Die Komponenten der Redaktionsumgebung nutzen verschiedene Datenbanken, die ebenfalls installiert und betrieben werden müssen. Diese Datenbanken können je nach Anforderungen des Plattformbetreibers in einer dedizierten Datenbank-Zone und somit dedizierten Datenbankservern ausgelagert werden. Alternativ können die Datenbanken auch auf der Redaktionsumgebung mit installiert werden, um diese lokal auf den Umgebungen zu betreiben. 

Hinweis:
Insbesondere unter Berücksichtigung der BSI-Grundschutzanforderungen empfiehlt sich der Aufbau einer dedizierten Datenbank-Zone, so dass die Applikations- und Datenbankserver in verschiedenen Netzwerkzonen angesiedelt sind.

Insofern vermittelt das folgende Schaubild nur einen Überblick über die in der Redaktionsumgebung benötigten Datenbanken indem diese logisch den jeweiligen Komponenten zugeordnet sind. Die Datenbanken können wie skizziert entweder lokal auf dem Server der Redaktionsumgebung oder auf einem dedizierten Datenbankserver (in einer Datenbank-Zone) betrieben werden.

Abbildung 4: Datenbanken der Redaktionsumgebung

2.2 Liveumgebung

Die GSB Komponenten der Liveumgebung sind für die Erzeugung der HTML-Webseiten der auf der Umgebung gehosteten Mandanten zuständig. Im Einzelnen handelt es sich um die folgenden Komponenten: 

• Master-Repository-Server beinhaltet das Content-Repository in dem der publizierte Content der GSB-Mandanten verwaltet wird. Bei der Publikation redaktioneller Inhalte werden diese in das Master-Repository publiziert. Der Master repliziert die publizierten Inhalte dann an alle angeschlossenen Replication-Repositories, so dass üblicherweise alle Repositories der Liveumgebung denselben Contentstand haben
• Replication-Repository-Server beinhalten einen Spiegel des Master-Repositories. Die Replication-Repository-Server können für den Aufbau einer sklierbaren und ausfallsicheren Infrastruktur genutzt werden.
• Delivery-Server ist für die Erzeugung der Webauftritte der GSB-Mandanten zuständig.
• Web-Server stellt den Internetnutzern der Webauftritte der einzelnen Mandanten den Zugriff auf die entsprechenden Websites zur Verfügung
• Solr-Server stellt die Solr-Suche für die Webauftritte der GSB-Mandanten zur Verfügung
• Service-Server stellt Service-Funktionalitäten der Liveumgebung zur Verfügung. Im Service-Server der Liveumgebung wird der Indexer betrieben. 

In der Liveumgebung werden wie oben skizziert alle Webauftritte der gehosteten GSB-Mandanten ausgeliefert und betrieben. Je nach Anzahl der gehosteten GSB-Mandanten und deren Webauftritte sowie der Komplexität der jeweiligen Webauftritte (Anteil dynamischer bzw. statischer Inhalte, Umfang) und dem Zugriffs- und Nutzungsverhalten der Internetnutzer werden an die Liveumgebung unterschiedliche Anforderungen an die Skalierung und Ausfallsicherheit gestellt. In den folgenden Kapiteln werden ausgehend von einer einfachen minimalen Liveumgebung verschiedene Ansätze zur Bereitstellung einer skalierbaren und ausfallsicheren Umgebung skizziert.

2.3 Minimale Liveumgebung

Eine minimale Liveumgebung enthält jeweils nur eine Instanz der oben aufgeführten GSB Komponenten der Liveumgebung. Eine minimale Liveumgebung kann ggf. für Selbsthoster mit kleinen Webauftritten und sehr wenig Zugriffen interessant sein, wenn keine gesonderten Ansprüche an eine ausfallsichere Auslieferung gestellt werden. 

Weiterhin kann eine minimale Liveumgebung auch für Test- bzw. Staging-Infrastrukturen eingesetzt werden, wenn diese ausschließlich einen Test bzw. Qualitätssicherung der GSB Komponenten und der gehosteten GSB-Mandanten unter fachlichen Aspekten unterstützen soll. D.h. in einer solchen Umgebung können keine vergleichenden Last- oder Performance-Tests sowie sonstige Infrastrukturtests durchgeführt werden, wenn die produktive Liveumgebung mit einer anderen Dimensionierung aufgebaut und betrieben wird.

Abbildung 5: Minimale Liveumgebung

Die Zugriffe der Internetnutzer auf die GSB Delivery-Infrastruktur erfolgen über den zentralen Web-Server, der die Anfragen an den angebundenen Delivery-Server weiterleitet und für die Generierung der GSB basierten Webseiten zuständig ist. Die Inhalte der Webseiten werden aus dem Master-Repository gelesen und Suchen der Internetnutzer oder dynamische Listen werden mit Hilfe des angebundenen Solr-Servers umgesetzt. 

Wie der grafischen Skizze entnommen werden kann, ist die gesamte Auslieferungsinfrastruktur bei Ausfall einer GSB Komponente in Mitleidenschaft gezogen. D.h. bei Ausfall einer Komponente ist keine Auslieferung von GSB Webseiten mehr möglich.

2.4 Ausfallsichere Auslieferung

Durch Erweiterung der im vorherigen Abschnitt skizzierten Infrastruktur kann eine ausfallsicherere Auslieferung bereitgestellt werden. In diesem Kapitel wird zunächst eine Erhöhung der Ausfallsicherheit durch redundante Komponenten auf einem Server vorgestellt Im nachfolgenden Kapitel wird dann eine Infrastruktur mit mehreren Servern vorgestellt. Die Verteilung der GSB Auslieferungskomponenten auf mehrere unabhängige Server an verteilten Standorten ist zwingende Voraussetzung für den Aufbau und Betrieb einer ausfallsicheren Infrastruktur. 

Durch Aufbau redundanter GSB Komponenten innerhalb des Servers der Liveumgebung wird die Redundanz der einzelnen GSB Komponenten erhöht, so dass damit eine ausfallsichere Auslieferung bereitgestellt werden kann. Gleichzeitig können die auf dem Server zur Verfügung stehenden Resourcen (CPU, Hauptspeicher) durch die zusätzlichen Komponenten besser genutzt werden, so dass insgesamt eine bessere Auslastung der beteiligten Server erzielt werden kann.

Abbildung 6: Ausfallsichere Liveumgebung

Die skizzierte ausfallsichere Liveumgebung wird wie skizziert auf einem Server betrieben und stellt redundante Komponenten zur Verfügung. Auf dem Server existiert allerdings mit dem zentralen Webserver ein Single-Point-of-Failure. D.h. bei Ausfall des Webservers ist die Auslieferung der GSB Webseiten dieser Infrastruktur nicht mehr möglich. Bei Ausfall des gesamten Servers ist die Auslieferung ebenfalls gestört. Insofern bietet diese Infrastruktur durch den Aufbau redundanter GSB Komponenten eine erhöhte Ausfallsicherheit ist aber durch die beiden Single-Point-of-Failures (Webserver und der zugrundeliegende Server) noch nicht komplett redundant und ausfallsicher ausgelegt.

2.4 Multi-Server Auslieferung

Durch Duplizierung der Auslieferungsserver der ausfallsichereren Auslieferung kann eine komplett ausfallsichere GSB Infrastruktur aufgebaut werden. Diese Infrastruktur besteht somit aus zwei oder mehr Servern, die für die Auslieferung der GSB-Mandanten zuständig sind. Die Infrastruktur mit zwei Servern ist somit wie folgt aufgebaut.

Abbildung 7: Multi-Server Auslieferung

Das Routing der http-Anfragen der Internetnutzer auf den Server 1 bzw. Server 2 wird durch einen der GSB Infrastruktur vorgeschalteten Loadbalancer übernommen. Dieser sorgt dafür, dass alle eingehenden Anfragen gemäß der zugrundeliegenden Loadbalancer Konfiguration auf beide Server verteilt werden. 

Zusätzlich prüft der Loadbalancer zyklisch die Erreichbarkeit der Webserver auf beiden Servern. Bei Ausfall einer GSB Komponenten auf einem der Server bzw. dem Ausfall des gesamten Servers wird dieser aus dem Loadbalancing rausgenommen. In diesem Fall werden alle Anfragen auf den verbliebenen Server weitergeleitet. 

Sobald der ausgefallene Server wieder zur Verfügung steht, wird dies vom Loadbalancer erkannt und der Server wird wieder in das Loadbalancing integriert. 

Durch Bereitstellung zusätzlicher Auslieferungsserver kann die Redundanz weiter erhöht werden, so dass die Ausfallsicherheit der gesamten Infrastruktur damit ebenfalls weiter erhöht werden kann. 

Hinweis:
Bei diesem Ansatz ist zu beachten, dass der Loadbalancer sowie die vorgeschaltete Netzwerkinfrastruktur ebenfalls redundant und ausfallsicher ausgelegt werden muss. Ansonsten besteht die Gefahr, dass bei Ausfall einer Komponente der Netzwerkinfrastruktur die Auslieferung beeinträchtigt wird und somit die Ausfallsicherheit nicht gewährleistet werden kann.

2.6 Redundante Auslieferung

Die einzelnen Auslieferungsstränge (Master und Replikation) auf dem Server können mit redundanten Delivery-Servern konfiguriert werden. Die Delivery-Server sind für die Generierung der HTML-Seiten zuständig, wobei die redaktionellen Inhalte aus dem angebundenen Repository gelesen werden. 

Der Aufbau einer GSB-Infrastruktur mit redundanter Auslieferung ist insbesondere unter dem Gesichtspunkt der Lastverteilung und Skalierbarkeit interessant. Die Delivery-Tomcats erzeugen in Relation zu den angebundenen Repository-Tomcats aller Voraussicht nach deutlich weniger Last auf dem Server, so dass die zur Verfügung stehenden Resourcen des Servers durch zusätzliche Delivery-Tomcats besser ausgenutzt werden können. Durch die Installations zusätzlicher Delivery-Tomcats auf einem Server ergibt sich somit die folgende Architektur.

Abbildung 8: Redundante Auslieferung

3 Betriebsprozesse

3.1 Starten und Stoppen

Die GSB Service-Instanzen sollen unter die Kontrolle des Systemd (s.a. https://www.freedesktop.org/wiki/Software/systemd/) gestellt werden, da Systemd mittlerweile das alte Init-System abgelöst hat und von allen Linux-Distributionen unterstützt wird. 

Systemd nutzt für die Konfiguration sogenannte Units, die über eine deklarative Beschreibung definiert werden (s.a. https://www.freedesktop.org/software/systemd/man/systemd.unit.html). Eine gute Einführung in den Themenkomplex findet sich auf der Heise-Webseite (s.a. https://www.heise.de/ct/artikel/Das-Init-System-Systemd-Teil-1-1563259.html ) 

Der wesentliche Vorteil gegenüber den bisher im GSB/CM genutzten Start- und Stoppskripten liegt darin, dass durch Systemd sichergestellt werden kann, dass die GSB Instanzen mit dem richtigen User gestartet und betrieben werden, dass Abhängigkeiten zwischen den einzelnen Instanzen einfacher berücksichtigt werden sowie der Start und Stopp einfacher durchgeführt werden kann.

Hinweis: Der GSBstützt sich auf eine Reihe von Beistellungen, die durch den System- bzw. Applikationsbetrieb auf den GSB Servern installiert und konfiguriert werden müssen. Hierzu zählen auch die dem GSB zugrundeliegenden Server (Tomcat- und HTTPD-Server). 

Die Systemd-Einbindung der GSB Prozessinstanzen fällt damit auch in die Zuständigkeit und Verantwortlichkeit des Systembetriebs. Der GSB Kern beinhaltet exemplarische Vorlagen für die Systemd-Integration des GSB. Diese Vorlagen dienen dem Systembetrieb als Grundlage und Ausgangspunkt für den Aufbau der an die individuellen Belange und Anforderungen anzupassenden Betriebsprozesse. 

3.1.1 GSB Units

Die durch Systemd verwalteten Ressourcen werden wie skizziert durch sogenannte Units definiert. Für die Kontrolle der Der GSB Instanzen werden nur zwei Varianten der Units genutzt.

Service-Units (s.a. https://www.freedesktop.org/software/systemd/man/systemd.service.html) werden verwendet, um die einzelnen Prozessinstanzen starten und stoppen zu können.

Target-Units (s.a. https://www.freedesktop.org/software/systemd/man/systemd.target.html) werden genutzt, um mehrere Prozessinstanzen zu Gruppen zusammenzufassen. Über Targets können somit mehrere Prozesse gestartet oder gestoppt werden.

gsbos Target-Unit

Dieses Target fasst alle GSB Komponenten auf einem Server zusammen, so dass mit Hilfe dieses Targets alle GSB Prozessinstanzen gestartet bzw. gestoppt werden können.

Service-Typ Target-Unit

Das Target fasst als Instanzen eines Service-Typs zusammen. Mithilfe dieses Target können alle Instanzen des Typs gestartet oder gestoppt werden. So können bspw. alle auf einem Server konfigurierten Delivery-Tomcats mit einem Aufruf gestartet oder gestoppt werden.

Service-Instance Service-Unit

Eine konkrete GSB Prozessinstanz (Service-Instance) wird als Systemd Service-Unit registriert. 

Die oben skizzierten GSB Systemd-Units stehen wie auf der folgenden Grafik exemplarisch am Beispiel der Delivery-Server skizziert zueinander wie folgt in Abhängigkeit:

Abbildung 9: GSB Systemd Unit-Abhängigkeiten

3.2 Monitoring und Logging

Die einzelnen GSB Prozessinstanzen protokollieren ihren Status in Form von Logdateien. Alle GSB Service-Instanzen eines Servers nutzen das zentrale Verzeichnis /space/gsbos/data für die Speicherung der Bewegungsdaten der Komponenten. Jede Service-Instanz verfügt über ein dediziertes Verzeichnis, welches dem Namen der Instanz entspricht. D.h. die Instanz delivery1-master loggt bspw. in das Verzeichnis /space/gsbos/data/delivery1-master/logs. Alle Logdateien einer Instanz liegen wie skizziert im entsprechenden logs-Unterordner und die Logdateien der einzelnen GSB Webapplikation genügen dem Namensschema „webapp-<WEBAPPNAME>.log“ wobei das Token <WEBAPPNAME> durch den jeweiligen Namen einer GSB Webapplikation ersetzt werden muss. 

Ein Monitoring der GSB Webapplikationen stützt sich idealerweise auf der stetigen Analyse der Log-Dateien der einzelnen GSB Webapplikationen ab. Die Log-Dateien können mit Hilfe etablierter Applikationen für Logfileanalyse und –auswertung wie bspw. Incinga, o.ä. automatisiert gelesen werden.

3.3 Datensicherung

Den Aufbau und die Erarbeitung eines Datensicherungskonzeptes für eine Hostingplattform werden durch die Informationen dieses Kapitels unterstützt indem hier die Einstiegspunkte der einzelnen GSB Komponenten definiert sind, die für eine Datensicherung relevant sind. Parallel zu diesem Dokument sollen noch Best-Practices erarbeitet werden, die auf konkrete Aspekte der Sicherung einzelner GSB Komponenten eingehen und konkrete Empfehlungen für den Aufbau eines Datensicherungskonzeptes bzw. Ansätze einer Datensicherung aussprechen. 

Der GSB und die einzelnen GSB Komponenten erzeugen im Betrieb dynamische Daten, die ggf. gesichert werden sollen, um diese bei einem Systemausfall bzw. Ausfall einzelner Komponenten wiederherstellen zu können. Zu den dynamischen Daten zählen insbesondere

• die Contentrepositories des Redaktions- und Livesystem,
• die Applikationsdatenbank,
• die Datenbank des Adminportals und Maildistributors,
• die Solr-Suchindices,
• die Statusinformationen der Servicekomponenten wie Indexer und Eventdispatcher sowie
• die Logdateien der einzelnen GSB Applikationen

 An dieser Stelle werden nur allgemeine Hinweise zur Datensicherung gegeben, die genaue Ausgestaltung eines Datensicherungskonzeptes bzw. Empfehlungen für ein Datensicherungskonzept bleibt der Best-Practise Dokumentation vorbehalten.

Die Content-Repositories der einzelnen GSB Contentserver (Redaktion, Master- Replication-Liveserver) werden jeweils in einer relationalen Datenbank gespeichert, die mit Hilfe der Sicherungslösungen des zugrundeliegenden Datenbankservers gesichert werden können. Die Sicherung der Repository-Datenbanken muss mit Hilfe der entsprechenden Sicherungstools der Datenbankhersteller erfolgen, um eine konsistente und recoveryfähige Sicherung der Repositories durchzuführen. An dieser Stelle sei erwähnt, dass das JCR-Repository neben den eigentlichen redaktionellen Inhalten in der Repository-Datenbank noch einen internen Lucene-Index verwaltet, der ebenfalls gesichert werden muss. Die Sicherung der Repository-Datenbank und des zugehörigen Lucene-Index müssen konsistent erfolgen und zeitlich zusammenpassen, um diese im Recoveryfall auch konsistent wieder zurückspielen zu können. 

Die weiteren GSB Datenbanken wie Applikations-DB, Adminportal-DB, Maildistributor-DB müssen ebenfalls mit den Sicherungstools der jeweiligen Datenbankhersteller gesichert werden. Diese Datenbanken können unabhängig von anderen Datenbanken und Komponenten gesichert werden, da keine zusätzlichen Bewegungsdaten benötigt werden. 

Die Bewegungsdaten der GSB Komponenten liegen auf den Servern unterhalb des zentralen Verzeichnisses /space/gsbos/data. Unterhalb dieses Verzeichnisses befinden sich für jede Service-Instanz dedizierte Unterordner, die mit dem Namen der Instanz bezeichnet sind (bspw. service-master). 

Die GSB Indexer- und Eventdispatcher-Webapplikationen sind Bestandteil eines Service-Tomcats (Service-Preview oder Service-Master) und protokollieren den Fortschritt der Eventverarbeitung in einer sogenannten Timestamp-Datei im Verzeichnis var/indexer/timestamps (Indexer-Applikation) und var/eventdispatcher/timestamps (Eventdispatcher-Applikation). Konkret bedeutet dies, dass auf dem Service-Tomcat der Redaktionsumgebung es sich bei den betreffenden Dateien um /space/gsbos/data/service-preview/var/indexer/timestamps sowie /space/gsbos/data/service-preview/var/eventdispatcher/timestamps handelt. 

Die Solr-Suchindices werden unterhalb des Solr-Verzeichnis solr-data gespeichert. Konkret nutzen in einer GSB Umgebung die Solr-Instanzen die folgenden Verzeichnisse für die Solr-Indices:

• Solr Redaktionsumgebung: /space/gsbos/data/solr-preview/solr-data
• Solr-Master Liverumgebung: /space/gsbos/data/solr-master/solr-data
• Solr-Replication Liveumgebung: /space/gsbos/data/solr-replication/solr-data

Die Verzeichnisse entsprechen denen des GSB/CM, so dass die vorhandenen individuellen Sicherungskonzepte der jeweiligen Hostingplattformbetreiber übernommen bzw. geringfügig adaptiert werden können. 

An dieser Stelle muss wie oben schon skizziert beachtet werden, dass das JCR-Repository zusätzlich noch einen Lucene basierten Suchindex für Repository interne Suchen benötigt. Dieser Suchindex kann bei Inkonsistenzen o.ä. neu aufgebaut werden bzw. wird durch Jackrabbit neu aufgebaut. Der Aufbau des Index wird je nach Größe des zugrundeliegenden Repositories aller Voraussicht nach relativ zeitaufwändig sein, so dass sich eine konsistente Sicherung des Lucene-Index zusammen mit der jeweiligen Content-Datenbank anbietet.