Konfugieren Sie Ihren primären und Ihren Ausweichserver für eine grundlegende Hochverfügbarkeitsumgebung.
IBM HTTP-Server- und Web-Server-Plug-ins installieren und konfigurieren
Jazz-Anwendung auf dem primären und dem Ausweichserver installieren und konfigurieren
Informationen zum Installieren und Konfigurieren von zwei Instanzen einer
Jazz-Anwendung wie
IBM Rational Team Concert oder
IBM Rational Quality Manager für WebSphere Application Server finden Sie in
WebSphere Application
Server konfigurieren.
Hinweis: Installieren Sie die Server nicht gleichzeitig. Jeder Server verweist in seiner Datei 'teamserver.properties' auf dieselbe Datenbank. Stellen Sie sicher, dass der erste Server heruntergefahren und nicht an das Repository angehängt ist, bevor Sie mit der zweiten Installation beginnen.
Hochverfügbarkeit für den primären und den Ausweichserver konfigurieren
Die Anwendung 'jazz.war' wird normalerweise mit einem einzigen Anwendungsserver als Ziel installiert. Mit der Einführung des Web-Servers muss die Anwendung 'jazz.war' geändert werden, um ein Routing über den Web-Server zuzulassen.
Gehen Sie wie folgt vor, um die Anwendung zu ändern:
- Klicken Sie in der WebSphere-Konsole auf den Link der Anwendung 'jazz.war' unter Unternehmensanwendungen.
- Wählen Sie Module verwalten aus.
- Wählen Sie das Kontrollkästchen für das Anwendungsmodul 'jazz.war' aus.
- Wählen Sie in der Liste der Cluster und Server sowohl den Web-Server als auch den Anwendungsserver aus und klicken Sie anschließend auf Anwenden.
- Klicken Sie auf OK und anschließend auf Änderungen speichern.
- Starten Sie die Anwendung 'jazz.war' erneut.
Konfigurieren Sie die Jazz-Anwendung auf dem primären Anwendungsserver erneut, um die Sicherheit für die Anwendung 'jazz.war' zu inaktivieren.
- Ändern Sie die Datei 'web.xml' aus der WAR-Datei, die auf WebSphere Application Server installiert wurde.
Tipp: Sie müssen die WAR-Datei möglicherweise in ein temporäres Verzeichnis entpacken, um auf die Datei 'web-xml' zugreifen zu können.
- Ändern Sie alle Vorkommen von "CONFIDENTIAL" in "NONE".
- Stellen Sie sicher, dass WebSphere Application Server ausgeführt wird, öffnen Sie einen Browser und rufen Sie https://localhost:9043/ibm/console/logon.jsp auf.
- Wechseln Sie auf die Seite Anwendungen -> Unternehmensanwendungen.
- Wählen Sie die Anwendung 'jazz_war' aus und klicken Sie auf Aktualisieren.
- Wählen Sie Einzelne Datei ersetzen oder hinzufügen aus.
- Geben Sie im Feld "Geben Sie den Pfad der zu ersetzenden bzw. hinzuzufügenden Datei ausgehend von der installierten Anwendungsarchivdatei an" Folgendes ein: jazz.war\WEB-INF\web.xml.
- Klicken Sie auf Durchsuchen und wählen Sie die Datei 'web.xml' aus, die Sie in Schritt 2 geändert haben.
- Klicken Sie auf Weiter und gehen Sie gemäß der Anweisungen vor, bis die Anwendung gespeichert wird.
- Wechseln Sie wieder zurück zur Seite Anwendungen -> 'Unternehmensanwendungen, stoppen Sie die Anwendung 'jazz_war' und starten Sie sie erneut.
Konfigurieren Sie den primären und den Ausweichserver von
Rational Jazz Team Server so, dass beide auf dieselbe Speicherposition für den Volltextindex verweisen. Damit der Index für den primären und den Ausweichserver
aktuell und verfügbar bleibt, aktualisieren Sie 'com.ibm.team.fulltext.indexLocation' in der Datei 'teamserver.properties' auf dem primären und dem Ausweichserver, um den Index auf einem gemeinsam genutzten Laufwerk zu installieren. Ändern Sie die folgende Eigenschaft in der Datei 'teamserver.properties' auf dem primären und dem Ausweichserver:
Asynchrone Tasks auf dem Ausweichserver ausschalten
Auf dem Ausweichserver müssen asynchrone Tasks (oder Hintergrundtasks) inaktiviert werden, um mögliche Datenkonflikte zwischen den beiden aktiven
Rational Jazz Team Server-Servern zu vermeiden.
- Fügen Sie der Datei 'teamserver.properties' auf dem Ausweichserver die folgende Zeile hinzu:
com.ibm.team.repository.scheduler.migration.mode.enabled=true
- Starten Sie die Anwendung 'jazz.war' auf dem Ausweichserver erneut.
Datei 'plugin_cfge' auf dem Web-Server für Idle-Standby bearbeiten
Jedes Mal, wenn WebSphere Application Server so konfiguriert wird, dass Anforderungen über einen Web-Server an einen Anwendungsserver weitergeleitet werden, wird die Datei 'plugin.xml' mit den Verbindungsinformationen für diesen Anwendungsserver aktualisiert. An diesem Punkt haben Sie die Datei 'plugin-cfg.xml' teilweise konfiguriert. Ersetzen und bearbeiten Sie den folgenden Abschnitt der Datei 'plugin-cfg.xml' auf dem Web-Server, um die Konfiguration abzuschließen.
Diese Datei 'plugin-cfg.xml' befindet sich im Ordner 'plugin\config\webserver1' auf dem Web-Server, (wobei 'webserver1' der Name ist, den Sie im vorherigen Abschnitt zum Installieren und Konfigurieren der IBM HTTP Server- und Web-Server-Plug-ins dem Web-Server zugeordnet haben).
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="RTC_basicHA_Cluster" RetryInterval="60" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true">
<Server LoadBalanceWeight="1" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="PrimaryNode01_server1" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="primary.hostname.company.com" Port="9080" Protocol="http"/>
</Server>
<Server LoadBalanceWeight="0" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="BackupNode01_server1" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="backup.hostname.company.com" Port="9080" Protocol="http"/>
</Server>
</ServerCluster>
<UriGroup Name="default_host_RTC_basicHA_Cluster_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/jazz/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/j_security_check"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm_security_logout"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ivt/*"/>
</UriGroup>
<Route ServerCluster="RTC_basicHA_Cluster" UriGroup="default_host_RTC_basicHA_Cluster_URIs" VirtualHostGroup="default_host"/>
Serverkonfiguration auf Möglichkeit der manuellen Funktionsübernahme prüfen
Bearbeiten Sie die Datei 'plugin-cfg.xml' auf dem Web-Server so, dass für 'PrimaryNode01 _server1' der Wert LoadBalanceWeight ="0" und 'für BackupNode01_server1' der Wert LoadBalanceWeight ="1" gilt, um die Möglichkeit der manuellen Funktionsübernahme von WebSphere Application Server zu prüfen. Speichern Sie die Datei 'plugin-cfg.xml'.
Wichtig: Da echtes Clustering und Lastausgleich noch nicht unterstützt wird, können primärer und Ausweichserver zu keinem Zeitpunkt beide einen Wert ungleich null für das Attribut 'LoadBalanceWeight' aufweisen.
- Führen Sie das Snoop-Beispielservlet in WebSphere aus, während der primäre und der Ausweichserver beide online sind, um den Namen des Servers zu ermitteln, der die Anforderung bearbeitet.
- Rufen Sie das Snoop-Servlet über einen HTML-Browser mithilfe der folgenden URL auf: https://webserver/snoop.
- In den Informationen zur Anforderung wird der Host angezeigt, der die Anforderung als lokaler Host bereitstellt - in diesem Fall wird der Server mit LoadBalanceWeight =1 angezeigt.
- Versuchen Sie, 'LoadBalanceWeight' zwischen dem primären und dem Ausweichserver weiterzugeben und beachten Sie, welcher Server die Anforderung des Snoop-Servlets bearbeitet.
Fehler auf dem primären Server erkennen
Um eine höhe Verfügbarkeit zu erreichen, müssen Sie wissen, wann Ihr primärer Server inaktiv ist. Dies ist insbesondere wichtig für diese grundlegende Hochverfügbarkeitslösung, die keine automatische Funktionsübernahme vom primären Server auf den Ausweichserver zulässt.
Der Prozess zum Erkennen eines fehlgeschlagenen Servers ist eine kritische und zeitaufwändige Aufgabe. Mehrere Faktoren können anzeigen, dass ein Server fehlgeschlagen ist, wie z. B. Netzprobleme, Konfigurationsprobleme, Anwendungsüberlastung oder ein Benutzerfehler. Unabhängig davon, welche Lösung Sie zum Ermitteln des Serverfehlers auswählen, müssen Sie sicherstellen, dass der Alert so schnell wie möglich erfolgt.