Hohe Verfügbarkeit (Ausfall innerer Server)

Der DMZ-Server ist in der Lage, eingelieferte Daten auch dann zu übernehmen, wenn der innere Server vorübergehend nicht erreicht werden kann. Die Ursache kann ein Ausfall des Netzwerkes zwischen DMZ-Server und innerem Integration Server sein, Wartungsarbeiten im Netz oder ein Neustart des inneren Servers. Per Default wird angenommen, dass die Dauer der Wartung bzw. des Ausfalls in der Größenordnung von zwei Stunden bleibt. Die Standardeinstellung kann allerdings auch durch entsprechende Konfiguration verändert werden. Siehe Parameter lifeTime in Datei ./etc/commlog_dmz.xml in Abschnitt “Verfügbarkeit des Communication Log Service (Offline-Mode)‌”.

Durch einen DMZ-Verbund mit wenigstens zwei DMZ-Servern kann die ununterbrochene Verfügbarkeit der DMZ-Seite garantiert werden.

Die Verfügbarkeits-Strategien von AuthenticationService und CommunicationLogService unterscheiden sich, bedingt durch die unterschiedliche Zielstellung. Für den AuthenticationService wird eine Caching-Strategie eingesetzt, während beim CommunicationLogService die Kommunikation zwischen DMZ-Server und innerem Server durch persistente Messages übernommen wird, falls synchrone Messages scheitern.

Verfügbarkeit des MessageAuthenticationServices durch Caching‌

Der MessageAuthenticationService (Konfigurationsdatei ./etc/auth_dmz.xml, bzw. wie in ./etc/factory_dmz.xml eingetragen) in einem DMZ-Szenario beantwortet die Anfragen, die er von Kommunikationsdiensten erhält, indem er sie per synchroner Message an den AuthenticationService des inneren Servers weiterleitet. Wenn der innere Server nicht erreichbar ist, muss der MessageAuthenticationService Anfragen trotzdem bearbeiten können. Er greift dazu auf eine Kopie der Datenbank-Tabellen des AuthenticationService zu, die er lokal hält. Diese lokale Datenbank-Kopie wird als Cache-Datenbank - oder einfach Cache – bezeichnet. Um das Risiko gering zu halten, dass der DMZ-Server mit veralteten Daten aus dem Cache arbeitet, sind folgende Caching-Regeln implementiert.

Caching-Regeln

1. Wenn der innere Server antwortet, wird diese Antwort verwendet (Online-Modus).

2. Wenn der innere Server nicht antwortet, wird der Cache ausgewertet (Offline-Modus).

3. Beim Neustart des DMZ-Servers werden die Daten in den Cache gefüllt, indem vollständig alle Partner, Partner-Kanäle und Zertifikate im Cache gespeichert werden. Dieser Vorgang heißt Initial-Update. Er entspricht einem vollständigen Update, siehe (7).

4. Scheitert ein Initial-Update, wird es in Abständen von jeweils 2 Minuten wiederholt, bis eine konfigurierbare Anzahl an Versuchen (maxInitAttempts, Default: 12) erreicht ist.

5. Während des Betriebes wird in regelmäßiger Periode (updatePeriod, Default: 900000 ms = 15 min) der Cache-Inhalt durch ein partielles Update aktualisiert. Dabei werden nur die Datensätze erfasst, die sich geändert haben. Datensätze, die als "deleted" gekennzeichnet sind, werden dadurch auch im Cache nach einem Update als "deleted" gekennzeichnet. Datensätze, die physisch gelöscht wurden, bleiben aber im Cache erhalten. Deshalb ist in größeren Abständen zur Datenbankbereinigung ein vollständiges Update erforderlich. Veränderungen von Datensätzen werden vom inneren Integration Server sofort an alle DMZ-MessageAuthenticationService(s) durchgereicht (push).

6. Sobald der MessageAuthenticationService des DMZs erfolgreich per Message auf den inneren AuthenticationService zugegriffen hat, wird in der Antwort-Message ein Kennzeichen "syncRequired" gesetzt, falls der innere AuthenticationService modifizierte Daten hat, die der DMZ-Server noch nicht repliziert hat. Der DMZ-Server wird daraufhin eine sofortige Replikation starten. Die Update-Periode beginnt danach wieder neu. Durch den Parameter ignoreNotification kann diese Funktion abgeschaltet werden.

7. Bei einem vollständigen Update (siehe unten) wird erst geprüft, ob der innere Server erreichbar ist. Falls nicht, bleiben die Cache-Daten unverändert. Wenn der innere Server erreichbar war, wird der Cache vollständig gelöscht und danach alle Partner, Partner-Kanäle und Zertifikate wieder gespeichert. Bei konfiguriertem Einschränken des Cachings nach Channel Types (cachedChannelTypes), werden nur die erlaubten Typen übernommen. Partner, die keinen Kanal eines erlaubten Typs haben, werden nicht übernommen.

In der Zeit zwischen dem Löschen der alten Daten und dem vollständigen Speichern der neuen Daten, ist der Cache ungültig. Anfragen der Kommunikationsdienste, die in dieser Phase eintreffen und nicht online vom inneren Server beantwortet werden können, werden zeitweilig zurückgestellt (verzögert). Nach einem konfigurierbaren Timeout (cacheUpdateTimeout, Default=8000 ms) scheitern diese Anfragen dann mit einer Exception, wenn nicht inzwischen das Update fertiggestellt ist. Diese Situation kann nur eintreten, wenn während eines vollständigen Updates das Netz ausfällt und gleichzeitig eine Anfrage eines Kommunikationsdienstes eintrifft.

Im Online-Modus (bei erreichbarem innerem Server) eintreffende Anfragen werden immer vom inneren Server bearbeitet, selbst dann, wenn gleichzeitig ein vollständiges Cache-Update läuft.

Im Offline-Modus wird das vollständige Update nicht ausgeführt, so dass Anfragen aus dem unveränderten Cache beantwortet werden können. Lediglich die Situation, wenn das Netz nach dem Start eines vollständigen Update längere Zeit ausfällt, ist kritisch. Ausfälle, die kürzer als der cacheUpdateTimeout sind, werden aber auch in dieser Situation überbrückt.

8. In folgenden Fällen wird das nächste Update als vollständiges Update ausgeführt:

• Wenn der DMZ-Server gestartet wurde (initiales Update, d. h. vollständig mit Wiederholversuch).

• Wenn zwischenzeitlich der innere AuthenticationService neu gestartet wurde.

• Wenn seit dem letzten vollständigen Update die fullUpdatePeriod vergangen ist.

• Das erste Update eines Tages (nach Datumswechsel) ist immer vollständig.

9. Wenn das nächste Update (wegen einer der Regeln in Punkt 8) vollständig sein soll, aber in dieser Zeit der innere Server nicht erreichbar war, erfolgt kein unmittelbarer Wiederholversuch (außer beim Initial-Update). Stattdessen wird das Update nicht durchgeführt. Das nächste Update wird dann aber wieder als vollständiges Update eingeplant.

10. Wenn in einem DMZ-Verbund der innere Server neu gestartet wird (oder auch nur dessen AuthenticationService) werden alle DMZ-Server ihr nächstes Update vollständig einplanen.

11. Wenn in einem DMZ-Verbund ein DMZ-Server neu gestartet wird, wird nur dessen Cache vollständig aktualisiert. Die anderen DMZ-Server haben eigene Regeln.

Periodische Cache-Replikation‌

Die Daten im Cache können periodisch aktualisiert werden. Die Periode wird mit dem Konfigurationsparameter updatePeriod eingestellt. In diesen Abständen fragt jeder DMZ-Server eigenständig seinen inneren Server ab, ob es Änderungen gab. Üblicherweise wird dann ein partielles Update gestartet. Falls seit dem letzten vollständigen Update mehr Zeit vergangen ist, als die ebenfalls konfigurierte fullUpdatePeriod, wird anstelle des partiellen ein vollständiges Update gestartet. Wenn zu Beginn eines partiellen Updates erkannt wird, dass seit dem letzten Update der innere Server oder sein AuthenticationService neu gestartet wurde, wird das partielle Update in ein vollständiges umgewandelt.

In einem partiellen Update wird mit Hilfe von Versionsnummern entschieden, welche Daten aktualisiert werden müssen. Dazu wird zuerst ermittelt, welche Partner-IDs betroffen sind und danach, ob die Änderung den Datensatz des Partners, der Kanäle oder der Zertifikate betrifft. Dadurch ist das Datenaufkommen minimal und auch die Update-Dauer sehr gering, so dass auch Perioden im Bereich etwa einer Minute möglich sind. Eine Periode unter drei Sekunden oder mit negativem Wert wird ignoriert und stattdessen der Defaultwert verwendet.

Im Message-Log (./logs/services/message.log) werden die Zeitpunkte des partiellen Updates eingetragen.

Falls die ID-Liste leer ist, wurden keine Daten kopiert, sondern nur die Version aktualisiert.

Wenn updatePeriod den Wert 0 hat, wird im laufenden Betrieb keine Aktualisierung erfolgen, auch kein vollständiges Update nach Erreichen der fullUpdatePeriod und auch nicht nach Neustart des inneren Servers oder bei einem Datumswechsel. Das unverzügliche Update nach einer “sync required”-Nachricht vom inneren Server wird ebenfalls nicht durchgeführt. Der DMZ-Cache wird dann nach dem Initial-Update bei DMZ-Start nicht mehr verändert.

Wenn updatePeriod auf einen sehr großen Wert eingestellt ist, wird diese Periode praktisch niemals erreicht, aber das unverzügliche Update nach “sync required” wird ausgeführt, falls nicht gleichzeitig ignoreNotification auf true gesetzt ist. In diesem Fall wird ein Update nur dann ausgeführt, wenn der DMZ-Server Anfragen an den inneren Server sendet und in der Datenbank relevante Änderungen existieren, eventuell gefiltert über die Channel-Types entsprechend Abschnitt “Einschränken des Cachings nach Kanal-Typ (cachedChannelTypes). Wenn auf diese Weise ein Update gestartet wird, wird es dann als vollständiges Update ausgeführt, falls zwischenzeitlich das Datum gewechselt hat, der innere Server neu gestartet wurde oder die fullUpdatePeriod erreicht war.

Wenn fullUpdatePeriod den Wert 0 hat (Defaultwert), werden vollständige Updates nur dann ausgeführt, wenn überhaupt Updates erfolgen (siehe oben) und wenn entweder das Datum gewechselt hat oder der innere Server gestartet wurde.

Wenn fullUpdatePeriod einen sehr kleinen positiven Wert hat, z. B. 1, werden alle Updates als vollständiges Update ausgeführt. Das wird aber nicht empfohlen. Wann die Updates erfolgen, richtet sich jedoch nicht nach diesem Parameter, sondern nach den weiter oben beschriebenen Regeln.

Konfigurationsparameter subID

Der innere Server sendet das Flag "sync required" nur solange an einen DMZ-Server, bis dieser auf die aktuelle Cache-Version aktualisiert ist. In einem DMZ-Verbund muss der innere Server daher die einzelnen DMZ-Server unterscheiden. Dazu wird die subID verwendet. Bei DMZ-Start wird ein Wert der subID aus Hostname und den IP-Adressen des Servers berechnet. Der Wert liegt im Bereich 0...31, daher ist es nicht ausgeschlossen, dass zwei DMZ-Server die gleiche subID erhalten, allerdings auch nicht sehr wahrscheinlich. Bei einem unverzüglichen Update würde dann jeweils nur einer der DMZ-Server aktualisiert (welcher ist zufällig). In diesem Fall muss eine eindeutige subID für jeden DMZ-Server durch explizite Konfiguration garantiert werden.

Verkürzung der Zugriffszeit im Offline Mode (maxWait)‌

Ob eine Anfrage an den inneren Server scheitert, weil dieser nicht erreichbar ist, kann der DMZ-Server nur daran erkennen, dass innerhalb einer Timeout-Wartezeit keine Antwort kommt. Diese Dauer kann durch den Parameter maxWait konfiguriert werden. Der Default-Wert beträgt 8000 ms (= 8 Sekunden). Die Anfrage wird dann aus dem Cache beantwortet. Für nachfolgende Anfragen wird die Wartezeit für synchrone Messages verkürzt. Sobald wieder eine Anfrage an den inneren Server erfolgreich war, wird die Wartezeit wieder auf maxWait gesetzt. Die verkürzte Wartezeit in Millisekunden ergibt sich aus der Formel (maxWait / 10) + 200.

Persistenter Cache oder temporärer Cache (localDbFile)‌

Die lokale Cache-Datenbank des DMZ-Servers kann wahlweise temporär im Arbeitsspeicher gehalten werden (Default). Dann gehen die Cache-Daten bei jedem Neustart des DMZ-Servers verloren. Wird der DMZ-Server in diesem Szenario neu gestartet, während der innere Server nicht erreichbar ist, kann er nicht selbständig Daten entgegennehmen.

Die lokale Cache-Datenbank kann aber auch im Dateisystem des DMZ-Servers persistent gespeichert werden. Das kann man mit dem Konfigurationsparameter localDbFile erreichen, der einen relativen oder absoluten Pfad zur Tablespace-Datei angibt. Die Datei wird unter dem definierten Pfad erzeugt. Wenn das Verzeichnis noch nicht existiert, wird es erzeugt.

Bei persistentem Cache kann der DMZ-Server nach einem Neustart auf den letzten gültigen Cache vor dem Stop wieder zugreifen. In dieser Situation wird zwar umgehend versucht, den Cache durch ein Initial-Update zu aktualisieren, aber wenn der innere Server nicht erreichbar ist, bleibt der alte Cache-Inhalt gültig, selbst dann, wenn die Update-Versuche nach Erreichen der maximalen Anzahl aufgegeben werden.

Achtung: Wenn der DMZ-Server eigenständig Daten entgegennimmt, gelten sie zwar als empfangen, sind aber nicht verarbeitet. Es liegt in der Verantwortung des Anwenders, dass der innere Server kurzfristig wieder einsatzfähig wird! Die eingelieferten Daten werden als persistente Message gehalten, bis sie der innere Server übernommen hat. Wenn die lifeTime der persistenten Message überschritten ist, gehen die bereits entgegengenommenen Daten verloren. Die Fähigkeit des DMZ-Servers, eigenständig Daten entgegenzunehmen, ist daher nur zur Überbrückung von kurzen Netzausfällen oder Wartungsintervallen geeignet.

Achtung: Bei persistentem Cache werden die Kommunikationsparameter im Dateisystem des DMZ-Servers gespeichert. Bei temporärem Cache sind sie daher deutlich besser vor unberechtigtem Zugriff geschützt. Die Passwörter werden aber in jedem Fall verschlüsselt gespeichert.

Einschränken des Cachings nach Kanal-Typ (cachedChannelTypes)‌

Wenn der DMZ-Server nur einzelne Kommunikationsprotokolle unterstützt, kann man die Caching-Funktion auf die entsprechenden Typen der Partner-Kanäle einschränken. Dazu wird der Parameter cachedChannelTypes als Liste der Typen definiert. Die Liste wird durch Komma, Leerzeichen oder Tabulator getrennt. Jeder Kanal-Typ wird durch einen numerischen Wert angegeben. Wenn die Liste leer ist (Default), werden alle Typen in die Cache-Datenbank kopiert. Eine Einschränkung gilt für alle Cache-Update-Arten (initial, vollständig, partiell).

Folgend die Bedeutung der numerischen Werte.

Ausschalten des Cachings (noCaching)‌

Wenn der Konfigurationsparameter noCaching beim Start des MessageAuthenticationService den Wert true hat, wird die lokale Cache-Datenbank nicht angelegt und die Update-Tasks werden nicht gestartet. Alle Anfragen müssen daher an den inneren Server weitergegeben werden. Falls der nicht erreichbar ist, scheitert die Anfrage mit einer Exception.

Zusammenfassung‌ und Parameter-Liste

Die mitgelieferte Datei ./etc/auth_dmz.xml enthält als Kommentarblöcke bereits die wichtigsten Konfigurationsparameter für den Service (siehe Tabelle am Ende der Seite). Alle Parameter befinden sich innerhalb des Configure-Elements.

<Configure class="com.ebd.hub.services.auth.MessageAuthenticationService">
...
</Configure>

Jeder einzelne Parameter wird in der folgenden Form definiert (hier abstrakt).

<Set name="Parametername">Parameterwert</Set>

Parameter

Verfügbarkeit des CommunicationLogServices (Offline-Mode)‌

Der CommunicationLogService zeichnet Kommunikationsvorgänge im Communication Log auf, wie z. B. die Einlieferung einer Datei per FTP, mit Zeitstempel, Jobnummer, usw. Die Datenbank-Tabelle wird vom inneren Server verwaltet. Auf dem DMZ-Server wird der CommunicationLogService durch folgende Klasse bereitgestellt: com.ebd.hub.services.commlog.MessageCommunicationLogService. In der mitgelieferten Datei ./etc/commlog_dmz.xml wird der Service konfiguriert (siehe Tabelle unten).

Im Online Mode (Normalfall) werden Zugriffe der Kommunikationsdienste auf dem DMZ-Server auf diesen Service sofort an den inneren Server weitergeleitet. Der MessageCommunicationLogService sendet dazu synchrone Messages an den inneren Server. Wenn die synchrone Message nicht zugestellt werden kann, weil z. B. der innere Server down ist, bzw. wenn die Antwort nicht innerhalb der maximalen Wartezeit maxWait zurück kommt, wird eine persistente Message erzeugt (Offline-Mode).

Im Offline Mode versucht der MessageService eigenständig, innerhalb der lifeTime dieser persistenten Message, sie an den inneren Server weiterzuleiten. Sobald dieser wieder erreichbar ist, wird das Kommunikations-Ereignis nachträglich geloggt. Wenn allerdings die lifeTime dieser Message überschritten ist, bevor der innere Server wieder erreichbar wird, geht dieser Log-Eintrag verloren. Hinweis: Der MessageCommunicationLogService kann im Offline-Mode keine Jobnummer loggen, weil die Daten noch nicht verarbeitet werden. Diese Einträge haben keine Jobnummer.

Der MessageCommunicationLogService greift auf seinen lokalen MessageService zu, über einen Service-Namen, der mit dem Parameter messageServiceName konfiguriert werden kann. Er muss zusätzlich Zugriff auf seinen lokalen AuthenticationService über den Service-Namen haben, der durch den Parameter authenticationServiceName konfiguriert werden kann. Gültige Default-Werte sind bereits vordefiniert. Eine explizite Konfiguration ist nur in Spezialfällen erforderlich.

Analog zum MessageAuthenticationService kann die Message Queue, die für die Kommunikation mit dem inneren Server verwendet wird, durch die Parameter messageContext, messageQueue und defTargetService konfiguriert werden. Es sind bereits gültige Default-Werte definiert, eine Änderung wäre nur im Ausnahmefall erforderlich und dann nur zusammen mit dem inneren Server.

Das defaultTarget definiert die Message-Route zum inneren Server und muss hier nicht konfiguriert werden, wenn sie bereits beim MessageAuthenticationService konfiguriert wurde.

Der Parameter maxWait gibt die maximale Wartezeit in Millisekunden für die Antwort auf eine synchrone Message an. Der Default-Wert von 8000 ms dürfte in allen Einsatzfällen ausreichen. Der Wert sollte ausreichend groß gewählt werden, sodass Antworten, die nach dieser Zeit eintreffen, praktisch nicht auftreten können.

Der Parameter lifeTime sollte explizit konfiguriert werden, wenn Ausfallzeiten überbrückt werden müssen, die länger dauern als der Default-Wert von zwei Stunden. Bei längeren Ausfällen des inneren Servers oder der Netzverbindung zwischen DMZ-Server und innerem Server, gehen die Log-Einträge, deren lifeTime überschritten ist, verloren.

Die Datei ./etc/commlog_dmz.xml enthält als Kommentarblöcke bereits die wichtigsten Konfigurationsparameter für den Service. Alle Parameter befinden sich im Configure-Element.

<Configure class="com.ebd.hub.services.commlog.MessageCommunicationLogService">
...
</Configure>

Jeder einzelne Parameter wird in der folgenden Form definiert (hier abstrakt).

<Set name="Parametername">Parameterwert</Set>

Parameter in Datei ./etc/commlog_dmz.xml