Wenn eine Messaging-Engine für die Verwendung eines Datenspeichers konfiguriert ist und keine Verbindung
zu ihrem Datenspeicher herstellen kann, weil beispielsweise die Datenbank, die den Datenspeicher enthält, nicht aktiv ist,
wird die Messaging-Engine nicht gestartet.
Sie können Ihr System optimieren, um die Wahrscheinlichkeit eines erfolgreichen Starts der Messaging-Engine
zu erhöhen.
Informationen zu diesem Vorgang
Wenn Sie den Anwendungsserver in einer Einzelserverumgebung starten, wird versucht, die Messaging-Engine
zu starten. Ist die Datenbank mehr als 15 Minuten nicht verfügbar, nimmt die Messaging-Engine unter Umständen
den Status "Gestoppt" an und muss manuell erneut gestartet werden.
In einer Hochverfügbarkeitsumgebung
wird eine Messaging-Engine beim Start des Servers bzw. Clusters oder im Rahmen des Failoverprozesses gestartet.
Während des Starts der Messaging-Engine versucht die Messaging-Engine standardmäßig bis zu 15 Minuten,
eine Verbindung zum Datenspeicher herzustellen. Wenn eine der folgenden Aussagen während dieser Zeit wahr bleibt,
kann die Messaging-Engine im Server nicht gestartet werden, und der Server wird für hohe Verfügbarkeit
inaktiviert:
- Die Datenbank ist nicht verfügbar oder nicht aktiv.
- Die Datenbank erkennt in einer Failoversituation den Verlust der Netzverbindung zum ursprünglichen Anwendungsserver
nicht und gibt deshalb die Sperren im Datenspeicher nicht frei.
Dieser inaktivierte Status kann an alle Member des Clusters weitergegeben werden.
Sie müssen die Server manuell erneut aktivieren, um Ihre Hochverfügbarkeitsumgebung
beizubehalten.
Sie können die Wahrscheinlichkeit eines erfolgreichen Starts der
Messaging-Engine erhöhen, indem Sie verschiedene Parameter, wie z. B.
das Standardzeitlimit von 15 Minuten, auf dem Datenbankserver oder im Anwendungsserver konfigurieren.
Vorgehensweise
- Konfigurieren Sie auf dem Datenbankserver das Betriebssystem so, dass die Zeit für die Erkennung
einer Netzverbindung zu einem Anwendungsserver minimiert wird. Nähere Einzelheiten finden Sie in der Dokumentation zu Ihrem Betriebssystem.
In der folgenden Tabelle sind beispielsweise die relevanten Parameter für
die Betriebssysteme Windows und
AIX aufgelistet:
Tabelle 1. TCP/IP-Parameter. Die erste Spalte
der Tabelle enthält eine Liste mit den TCP/IP-Parametern für Windows-Betriebssysteme.
Die zweite Spalte
der Tabelle enthält eine Liste mit den TCP/IP-Parametern für AIX-Betriebssysteme.
Die dritte Spalte enthält die Beschreibungen der Parameter.Parametername unter Windows-Betriebssystemen |
Parametername unter AIX-Betriebssystemen |
Beschreibung |
KeepAliveTime |
tcp_keepidle |
Wartezeit (in Millisekunden unter Windows-Betriebssystemen
und in Inkrementen von 0,5-Sekunden unter AIX-Betriebssystemen), bevor eine
keepalive-Anforderung für eine inaktive Verbindung gesendet wird. |
KeepAliveInterval |
tcp_keepintvl |
Wartezeit (in Millisekunden unter Windows-Betriebssystemen
und in Inkrementen von 0,5-Sekunden unter AIX-Betriebssystemen) auf eine Antwort. |
TCPMaxDataRetransmissions |
tcp_keepcnt |
Die Anzahl der Anforderungen, die gesendet werden sollen, bevor die Verbindung beendet wird. |
Sie können das Gesamtzeitlimit des Datenbankservers
für die Erkennung des Verlusts der Verbindung zum Anwendungsserver mit der folgenden Formel berechnen:
Zeit für Erkennung des Verbindungsfehlers = Keepalive-Zeitlimit + (Keepalive-Intervall x Anforderungsanzahl)
Bei einem Windows-System, dessen Parameter gemäß
der folgenden Tabelle definiert sind, beträgt das Gesamtzeitlimit des Datenbankservers für die Erkennung des Verlusts der
Verbindung zum Anwendungsserver 350 Sekunden.
Tabelle 2. Beispielparameterwerte. Die erste Spalte enthält die Parameternamen.
Die zweite Spalte enthält Beispielwerte für die Parameter.Parameter |
Wert |
KeepAlive |
300000 Millisekunden |
KeepAliveInterval |
10000 Millisekunden |
TCPMaxDataRetransmissions |
5 |
Ihr Datenbankprodukt kann auch relevante Parameter
haben, die Sie konfigurieren können, z. B. den Parameter
IDLE THREAD TIMEOUT in DB2 for z/OS. Wenn der Datenbankserver den Verlust der Verbindung zum Anwendungsserver erkennt, gibt die Datenbank die Datenspeichersperren frei.
Die Messaging-Engine kann jetzt auf den Datenspeicher zugreifen und deshalb erfolgreich gestartet werden.
- Im Anwendungsserver optimieren Sie die Messaging-Engine so, dass sie eine angemessene
Zeit auf die Wiederverfügbarkeit des Datenspeichers wartet. Standardmäßig versucht die Messaging-Engine, 15 Minuten lang alle 2 Sekunden die Verbindung zum Datenspeicher
herzustellen. Führen Sie den restlichen Teil dieses Schritts aus, wenn Sie diese Zeitvorgaben anpassen möchten.
- Klicken Sie auf , um zu der Anzeige mit den angepassten Eigenschaften für die Messaging-Engine
zu navigieren.
- Klicken Sie auf Neu.
- Geben Sie sib.msgstore.jdbcInitialDatasourceWaitTimeout im
Feld "Name" und einen entsprechenden Wert im Feld "Wert" ein. Diese Eigenschaft gibt die Zeit (in Millisekunden) an, die auf die Verfügbarkeit des Datenspeichers
gewartet werden soll.
Der Standardwert ist 900000 (15 Minuten). Diese Zeit umfasst die Zeit, die erforderlich ist, um eine Verbindung zur Datenbank herzustellen und um die erforderlichen Tabellensperren anzufordern.
Stellen Sie sicher, dass der Wert dieser Eigenschaft größer ist als das Gesamtzeitlimit des Datenbankservers
für die Erkennung des Verlusts einer Netzverbindung, das in Schritt 1 konfiguriert wurde.
- Klicken Sie auf OK.
- Klicken Sie auf Neu.
- Geben Sie sib.msgstore.jdbcStaleConnectionRetryDelay im
Feld "Name" und einen entsprechenden Wert im Feld "Wert" ein. Diese Eigenschaft gibt an, wie lange (in Millisekunden) zwischen den einzelnen Versuchen für die Verbindungsherstellung
zum Datenspeicher gewartet wird.
Der Standardwert ist 2000 (2 Sekunden). Wenn Sie die Eigenschaft "sib.msgstore.jdbcInitialDatasourceWaitTimeout" beispielsweise
auf "600000" und die Eigenschaft "sib.msgstore.jdbcStaleConnectionRetryDelay" auf
"3000" setzen, versucht die Messaging-Engine, 10 Minuten lang alle 3 Sekunden eine Verbindung herzustellen.
- Klicken Sie auf OK.
- Speichern Sie Ihre Änderungen in der Masterkonfiguration.
- Starten Sie den Anwendungsserver erneut.
- Wenn Sie einen Cluster haben, wiederholen Sie die vorherigen Schritte, um diese Eigenschaften für jede
Messaging-Engine im Cluster hinzuzufügen.
Ergebnisse
Durch die Konfiguration dieser Parameter und angepassten Eigenschaften minimieren Sie
das Zeitlimit des Datenbankservers für die Erkennung des Verlusts einer Netzverbindung und
stellen sicher, dass die Messaging-Engine vor einem Startversuch eine angemessene Zeit auf die Wiederherstellung
der Datenbankverbindung wartet.
Nächste Schritte
Sie können den Neustart der Messaging-Engine und des Servers
beim Verlust einer Datenbankverbindung konfigurieren. Dieses Verhalten verringert das Risiko eines
inkonsistenten Status der Messaging-Engine nach der Wiederherstellung der Datenbankverbindung.