Mehrere DMZ-Server können zu einem Verbund zusammengeschaltet werden, um eine höhere Ausfallsicherheit zu erreichen. Die DMZ-Server laufen dabei parallel. Einer der DMZ-Server ist als primärer DMZ-Server konfiguriert (hier "DMZ Server 1"). HINWEIS : In erster Linie ist ein DMZ-Server ein primärer DMZ-Server dadurch, dass er als DMZ-Server im inneren Integration-Server eingetragen ist. Zudem ist Punkt (3) zu beachten.
Eingehend
Die DMZ-Server geben die eingehenden Nachrichten an den inneren Integration Server weiter (1). Dabei ist es unerheblich, ob beide parallel laufen, oder nur einer der DMZ-Server aktiv ist. Beide DMZ-Server können den gleichen Message Port beim inneren Integration Server verwenden. HINWEIS : Wenn definiert, steht in der System-Variable VAR_SYS_DMZ_ID die Factory-ID des DMZ-Servers (aus./etc/factory.xml ), der eine Nachricht entgegengenommen hat.
Ausgehend
Die Aufrufe des inneren Integration Servers an den DMZ-Server werden an den primär konfigurierten DMZ-Server geleitet (2). Es kann aber unter den Kanäle für den Kanal ein explizit vorgegebener DMZ-Server eingetragen werden (siehe Abschnitt Dynamisch über alternativen DMZ-Server versenden).
Gemeinsame Verzeichnisse
Im DMZ-Verbund laufen mehrere DMZ-Server parallel hinter einem Load Balancer. Welcher DMZ-Server eine eingehende Datei entgegennimmt, steht nicht im Voraus fest. Damit jeder DMZ-Server auf die Daten zugreifen kann, benötigen Sie ein gemeinsames Dateisystem (File Share).
Folgende Ordner mit Bewegungsdaten müssen Sie auf den File Share legen:
./as2./as4./transfer
WICHTIG
Eine einfache Windows-Freigabe reicht nicht aus. Sie kann die Performance stark beeinträchtigen. Lobster empfiehlt ein leistungsstarkes Storage. Geeignet sind ein NFS-Share, ein NetApp-System oder ein vergleichbares Speichermedium.
DMZ ohne Processing
Ein DMZ-Server verarbeitet im Standardbetrieb keine Daten. Er empfängt und puffert nur. Daher genügen ihm die drei genannten Ordner ./as2, ./as4 und ./transfer.
Die übrigen Ordner aus dem internen Load-Balancing-Setup sind auf einem DMZ-Server nicht erforderlich. Auf einem reinen DMZ-System existieren sie teilweise gar nicht.
Eine vollständige Übersicht aller Ordner für den internen Cluster finden Sie unter Voraussetzungen zur Installation (Load Balancing).
Hohe Verfügbarkeit (Ausfall innerer Server)
Siehe Abschnitte Hohe Verfügbarkeit (Ausfall innerer Server) und Konfigurationsparameter subID (für DMZ-Verbund).
Hohe Verfügbarkeit (Ausfall primärer DMZ-Server)
Bei Änderungen in der Benutzerverwaltung für FTP, OFTP, etc. kopiert der primäre DMZ-Server (hier DMZ Server 1) jede Änderung des Home-Verzeichnisses auf die anderen DMZ-Server (hier DMZ Server 2), siehe (3). Dazu muss der primäre DMZ-Server eine Liste der zugehörigen DMZ-Server besitzen. Diese Liste wird in der Konfigurationsdatei ./etc/startup_dmz.xml mit folgendem Eintrag gepflegt.
<Set name="otherDMZ">host:port;host2:port2</Set>HINWEIS
Eine einfache Dateifreigabe sowie ein CSV-FS sind in diesem Szenario nicht ausreichend performant, da hierbei zusätzliche Mechanismen wie die V3-Verschlüsselung greifen. Lobster empfiehlt daher ein leistungsstarkes Storage, wie z. B. einen NFS-Share, ein NetApp-System oder ein vergleichbares Speichermedium. Eine gründliche Performance-Prüfung in Ihrer Umgebung ist unerlässlich.
Wenn der primäre DMZ-Server vom inneren Server nicht mehr erreicht werden kann, wird der nächste verfügbare DMZ-Server zum neuen primären DMZ-Server gemacht.
Hierzu muss in der Konfigurationsdatei ./etc/startup.xml des inneren Servers der folgende Eintrag vorhanden sein.
<!-- list all secondary DMZ systems here; format is <ip>:<port>; of the remote message service -->
<Set name="secondaryDMZ">10.99.133.8:8020;10.99.133.9:8020</Set>Diese beiden Einträge sind weitere DMZ-Server, die beim Ausfall des primären DMZ-Servers auf Verfügbarkeit geprüft werden. Der erste verfügbare DMZ-Server wird vorübergehend zum neuen, primären DMZ-Server. WICHTIG : Es wird die Liste der aktiven DMZ-Server überprüft.
Ist der konfigurierte primäre DMZ-Server wieder erreichbar, wird erneut auf diesen umgestellt. WICHTIG : Wird ein Load-Balancing-System verwendet und hat momentan ein Working Node die Rolle des Node Controllers, dann funktioniert das nicht automatisch (da sich der konfigurierte primäre DMZ-Server selbst aktiv beim konfigurierten inneren Server meldet und das ist bei der Verwendung eines Load-Balancing-Systems der konfigurierte Node Controller und nicht der Working Node, der momentan die Rolle des Node Controllers hat).