In diesem Abschnitt werden weitere wichtige Informationen zu der in Anwendungsserver 8.1 enthaltenen HADB-Implementierung erläutert.
Der neue Management-Befehl hadbm setadminpassword wurde bereitgestellt, um das zur Datenbankadministration verwendete Passwort ändern zu können. Der Befehl wird mit Optionen verknüpft, die angeben, welcher Management-Agent verwendet werden soll, und die das alte und neue Passwort enthalten. Weitere Informationen finden Sie in der Online-Dokumentation ( Man Page) hadbm setadminpassword.
Der vorhandene Management-Befehl hadbm listpackages wurde geändert. Vorher war der Befehl mit keinen Operanden verknüpft und hat alle Pakete in der relevanten Management-Domäne aufgelistet. Durch die Änderung wurde ein optionaler Paketnamen-Operand eingeführt, der lediglich Pakete mit dem betreffenden Namen auflistet. Wenn der Operand nicht angegeben wird, werden alle Pakete aufgelistet. Weitere Informationen finden Sie in der Online-Dokumentation ( Man Page) hadbm listpackages.
Der vorhandene Management-Befehl hadbm createdomain wurde geändert. Der Operand hostlist wurde erweitert. Er gibt jetzt auch die Portnummer des Management-Agenten an. Auf diese Weise wird die Domäne lediglich mithilfe des Operanden hostlist vollständig spezifiziert. Das alte Verhalten wird aus Gründen der Rückwärtskompatibilität immer noch unterstützt. Weitere Informationen finden Sie in der Online-Dokumentation (manpage) hadbm createdomain.
Einige Fehlermeldungen des Managementsystems wurden geändert. Die Änderungen dienen dazu, Verständlichkeit, Einheitlichkeit und Genauigkeit der Fehlermeldungen zu verbessern. Die eigentlichen Änderungen werden in diesen Versionshinweisen nicht aufgelistet.
Das Installations- und Deinstallationsverhalten wurde geringfügig geändert. Bei der Installation bzw. Deinstallation von HADB sollte immer der Softlink /opt/SUNWhadb/4 erhalten bleiben. Dies war jedoch nicht immer der Fall:
Die Möglichkeit zur Eingabe von Passwörtern in der Befehlszeile als Befehlsoption wurde verworfen. Dies ist für alle hadbm-Befehle relevant, die Passwörter als Befehlszeilenoptionen annehmen können. Für hadbm-Befehle gab es vorher folgende Methoden, um ein Passwort einzugeben:
als Passwortdatei
als Befehlszeilenoption
als interaktive Eingabe
Da Methode 2 (die Befehlszeilenoption) als unsicher erachtet wird, wurde sie verworfen. Eine Warnmeldung wird ausgegeben, wenn ein Passwort auf diese Weise eingegeben wird. Verwenden Sie stattdessen Methode 1 (Passwortdatei) oder Methode 3 (interaktive Ausgabe). Die Verwendung eines Passworts in der Befehlszeile wird in der nächsten Version überflüssig. Dies gilt für alle hadbm-Befehle, die eine Befehlszeilen-Passwortoption annehmen.
HADB wurde aktualisiert und kann jetzt JGroups Version 2.2 verwenden. Der Quellcode des Programms wird zusammen mit HADB verteilt. Zur Unterstützung von Online-Upgrades von vorherigen HADB-Versionen sind im Lieferumfang von HADB sowohl JGroups 2.1 als auch 2.2 vorhanden. Für JGroups 2.1 wird nur der Byte-Code mitgeliefert.
Wenn Sie HADB für eines der folgenden Dateisysteme konfigurieren möchten, müssen Sie einige wichtige Informationen beachten:
ext2 und ext3– HADB unterstützt ext2- und ext3-Dateisysteme für Red Hat Application Server 3.0. Für Red Hat Application Server 2.1 unterstützt HADB nur das ext2-Dateisystem.
Veritas– Wenn Sie das Veritas-Dateisystem unter Solaris einsetzen, wird die Nachricht “WRN: Direct disk I/O mapping failed“ in die Verlaufsdatei geschrieben. Die Meldung weist darauf hin, dass HADB kein direktes I/O für Daten- und Protokollgeräte aktivieren konnte. Direktes I/O ist eine Performance-Verbesserung, die die CPU-Kosten für das Schreiben von Diskseiten verringert. Das Prinzip führt auch dazu, dass weniger Verwaltungsaufwand für unreine Datenseiten im Betriebssystem erforderlich ist.
Um direktes I/O zusammen mit dem Veritas-Dateisystem zu verwenden, wählen Sie eine der folgenden Vorgehensweisen:
Erstellen Sie die Daten- und Protokollgeräte unter einem Dateisystem, für das die Option mincache=direct gilt. Die Option wird auf alle unter diesem Dateisystem erstellten Dateien angewendet. Weitere Informationen finden Sie in der Beschreibung des Befehls mount_vxfs(1M).
Verwenden Sie Toll Veritas Quick I/O, um direktes I/O auf die Dateien des Dateisystems anzuwenden. Weitere Informationen finden Sie im VERITAS File System 4.0 Administrator's Guide for Solaris.
Diese Konfigurationen wurden nicht mit Anwendungsserver 8.1 2005Q2 Update 2 getestet.
Informationen über Installation und Konfiguration von HADB mit der Anwendungsserver-Software finden Sie im Anwendungsserver Enterprise Edition High Availability Administration Guide.
Die Benutzer müssen HADB-Verlaufsdateien, Management-Agent-Konfigurationsdateien, Protokolldateien und Repository sowie alle Datengeräte außerhalb des Installationspfads abgelegt haben. Sollte dies nicht der Fall sein, muss dies noch vor dem Upgrade erfolgen. So verschieben Sie Management-Repository- und Konfigurationsdateien:
Beenden Sie alle alten Management-Agenten und führen Sie die HADB-Knoten weiter aus.
Verschieben Sie an jedem Host das Repository-Verzeichnis an den neuen Pfad.
Kopieren Sie auf jedem Host das Verzeichnis dbconfig an den neuen Pfad.
Aktualisieren Sie auf jedem Host die Datei mgt.cfg und wählen Sie den korrekten Pfad für dbconfig und das Repository-Verzeichnis.
Starten Sie die Management-Agenten unter Verwendung der aktualisierten Datei mgt.cfg.
Zur Aufrüstung von HADB-Version 4.4.x auf Version 4.4.2-7 gehen Sie wie folgt vor:
Führen Sie die oben genannten Tasks vor dem Upgrade nach Bedarf aus.
Installieren Sie HADB-Version 4.4.2-7 auf allen HADB-Hosts (in einem anderen Pfad als Version 4.4.x, zum Beispiel unter /opt/SUNWhadb/4.4.2-7).
Installieren Sie HADB-Version 4.4.2-7 auf den hadbm-Client-Hosts, wenn diese sich von den HADB-Hosts unterscheiden.
Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.
Starten Sie die Management-Agent-Prozesse mithilfe der Software der neuen Version, jedoch mit den alten Konfigurationsdateien. Für die verbleibenden Schritte verwenden Sie den Befehl hadbm, der im bin-Verzeichnis der neuen Version zu finden ist.
Registrieren Sie das Paket in der Management-Domäne (der Standardpaketname lautet V4.4, sodass evtl. ein anderer Paketname erforderlich ist, um Konflikte mit vorhandenen Paketen zu vermeiden, die denselben Namen tragen):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7 |
Führen Sie den Befehl hadbm listpackages aus und prüfen Sie, ob das neue Paket in der Domäne registriert ist.
Starten Sie die Datenbank mit der neuen hadbm-Version 4.4.2-7 neu. Wenn es erforderlich ist, die Geräte- und Verlaufsdateien zu verschieben, führen Sie ein Online-Upgrade aus und legen dabei in einem Schritt neue Pfade für Geräte und Verlaufsdateien fest:
hadbm set packagename=V4.4.2-7,devicepath=new_devpath, historypath=new_histpath |
Wenn sich die Geräte und Verlaufsdateien anderenfalls bereits außerhalb des Installationsverzeichnisses befinden, führen Sie den folgenden Befehl aus, der lediglich einen Bilddurchlauf-Neustart der Knoten auslöst:
hadbm set packagename=V4.4.2-7 Datenbankname |
Prüfen Sie (mithilfe des Befehls hadbm status), ob der Datenbankstatus "running" lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.
Wenn alles funktioniert, kann die alte Installation später entfernt werden. Bevor Sie die Registrierung des alten Pakets aufheben, entfernen Sie alle Verweise auf das alte Paket aus der maRepository. Anderenfalls schlägt der Befehl hadbm unregisterpackage fehl und gibt die Fehlermeldung "package in use" aus.Eine Dummy-Neukonfigurationsoperation, z. B. hadbm set connectiontrace= wie voriger Wert entfernt alle Verweise auf das alte Paket. Heben Sie jetzt die Registrierung des alten Pakets auf:
hadbm unregisterpackage [--hosts=Hostliste] alter Paketname |
Entfernen Sie die alte Installation aus dem Dateisystem.
Um unter Solaris zu testen, ob das Upgrade erfolgreich war, prüfen Sie, ob das Upgrade ordnungsgemäß durchgeführt wurde:
Vergewissern Sie sich, dass die laufenden Prozesse die neuen Binärdateien verwenden. Prüfen Sie in allen HADB-Knoten Folgendes:
neuer Pfad/bin/ma -v neuer Pfad/bin/hadbm -v |
Prüfen Sie, ob die Datenbank ausgeführt wird. Der folgende Befehl sollte zeigen, dass alle HADB-Knoten den Status “running” aufweisen.
neuer Pfad/bin/hadbm status -n |
Vergewissern Sie sich, dass Produkte mit Verwendung von HADB ihre Zeiger so geändert haben, dass sie auf den neuen HADB-Pfad verweisen.
Die Produkte mit Verwendung von HADB können ihre Upgrade-Tests ausführen, um zu prüfen, dass das HADB-Upgrade ebenfalls funktioniert.
Wenn nach einem Online-Upgrade die neue Version nicht ordnungsgemäß funktioniert, wechseln Sie wieder zur Verwendung der vorherigen HADB-Version. Wenn jedoch eine Änderung am Management-Agent-Repository durchgeführt wurde, kann die HADB selbst heruntergestuft werden. Allerdings muss der neue Management-Agent weiter ausgeführt werden.
In diesem Abschnitt werden zusätzliche Informationen über HADB-Bereitstellung und Upgrade aufgeführt.
Speichern Sie Geräte-, Protokoll- und Verlaufsdateien nur auf lokalen Festplatten. Verwenden Sie keine entfernt bereitgestellten Dateisysteme.
Wenn mehrere Knoten auf einem Host platziert wurden, wird empfohlen, dass die Geräte zu allen Knoten der verschiedenen Festplatten gehören. Anderenfalls würde die Leistung durch die Konkurrenzsituation zwischen den Festplatten herabgesetzt werden. Symptome für dieses Problem sind in den Verlaufsdateien anhand von Meldungen ersichtlich wie BEWARE - last flush/fputs took too long. Wenn ein Knoten über mehrere Datengerätedateien verfügt, wird empfohlen, separate Festplatten für diese Gerätedateien zu verwenden.
Verwenden Sie lokale Festplatten (möglichst eine andere als die für Datengeräte verwendete Festplatte), um HADB-Binärdateien auf HADB-Hosts zu installieren. NFS-Verzögerungen oder Zugriffskonflikte können zu Knotenneustarts mit der Warnung "Process blocked for nnn, max block time is nnn" in den Verlaufsdateien führen.
Legen Sie die HADB-Geräte, Verlaufsdateien, Management-Agent-Verzeichnisse und agent config-Dateien nicht im HADB-Paketpfad ab. Dies führt zu Problemen beim Upgrade auf neuere Versionen sowie beim Löschen des alten Paketpfads.
Diese HADB-Version wird offiziell für maximal 28 Knoten unterstützt, und zwar für 24 aktive Datenknoten mit 4 Ersatzknoten.
Es wird empfohlen, dieselbe Version für den JDBC-Treiber und den HADB-Server zu verwenden.
IPv6 wird nicht unterstützt, sondern lediglich IPv4.
Die Länge der Befehlszeile unter Windows ist auf 2048 Byte beschränkt.
Das Netzwerk muss für UDP Multicast konfiguriert sein.
Aufgrund des übermäßigen Swappings von RedHat Enterprise Linux 3.0, Updates 1 bis 3, empfehlen wir es nicht als Bereitstellungsplattform. Das Problem wurde in RedHat Enterprise Linux 3.0, Update 4 behoben.
Möglichkeit, NSUP mit Echtzeit-Priorität auszuführen.
Die Prozesse des Knoten-Supervisors (NSUP) (clu_nsup_srv ) stellen die hohe Verfügbarkeit von HADB mithilfe des termingemäßen Austauschs von "heartbeat"-Nachrichten sicher. Die zeitliche Koordinierung wird beeinträchtigt, wenn ein NSUP mit anderen Prozessen gemeinsam untergebracht wird, da dies zu einem Ressourcenschwund führt. Die Folge sind eine falsche Netzwerkpartitionierung und Knotenneustarts (vorher wird die Warnung “Process blocked for n seconds” in den Verlaufsdateien ausgegeben), die zu abgebrochenen Transaktionen und anderen Ausnahmefehlern führen.
Um dieses Problem zu lösen, muss für clu_nsup_srv (unter Installationspfad/lib/server zu finden) das suid-Bit gesetzt sein und Eigentümer der Datei muss der Benutzer "root" sein. Dies wird manuell durch folgende Befehle erzielt:
# chown root clu_nsup_srv # chmod u+s clu_nsup_srv |
Dadurch wird der Prozess clu_nsup_srv, wenn er gestartet wird, als Benutzer root ausgeführt. Dies wiederum ermöglicht dem Prozess, sich selbst automatisch Echtzeit-Priorität nach dem Start zuzuweisen. Zur Vermeidung von Sicherheitsproblemen bei Verwendung von setuid wird die Echtzeit-Priorität ganz am Anfang festgelegt und der Prozess kehrt zur effektiven UID zurück, sobald die Priorität geändert wurde. Andere HADB-Prozesse senken ihre Priorität auf Zeitteilungspriorität ab.
Wenn NSUP die Echtzeit-Priorität nicht setzen konnte, wird der Warnhinweis “Could not set realtime priority” (Unix: Fehler-Nr. wird auf EPERM gesetzt) ausgegeben, der in der Datei ma.log dargelegt ist, und der Prozess wird ohne Echtzeit-Priorität fortgesetzt.
Es gibt Fälle, in denen es nicht möglich ist, Echtzeit-Prioritäten festzulegen; beispielsweise in folgenden Situationen:
Bei Installation in nichtglobalen Zonen von Solaris 10
Wenn die Berechtigungen PRIV_PROC_LOCK_MEMORY (Ermöglichen, dass ein Prozess Seiten im physischen Speicher sperren kann) und/oder PRIV_PROC_PRIOCNTL in Solaris 10 aufgerufen werden.
Benutzer deaktivieren die Berechtigung setuid
Benutzer installieren die Software als tar-Dateien (Installationsoption nonroot für App.server)
Der Prozess clu_nsup_srv ist nicht CPU-konsumierend und sein Ressourcenbedarf ist gering. Wenn er mit Echtzeit-Priorität ausgeführt wird, beeinflusst er nicht die Leistung.
Konfiguration von IP-Netzwerk-Multipathing für HADB für Solaris (nur unter Solaris 9 getestet).
Sun empfiehlt, dass Solaris-Hosts, auf denen HADB ausgeführt wird, mit Netzwerk-Multipathing eingerichtet werden, um die höchstmögliche Netzwerkverfügbarkeit sicherzustellen. Die Einrichtung von Network-Multipathing wird in allen Einzelheiten im IP Network Multipathing Administration Guide behandelt. Wenn Sie sich dafür entscheiden, Multipathing mit HADB zu verwenden, lesen Sie im IP Network Multipathing Administration Guide den Abschnitt "Verwaltung von Netzwerk-Multipathing", um Multipathing einzurichten, bevor Sie mit dem Anpassen des Multipathing-Setups für HADB fortfahren (siehe unten). Der IP Network Multipathing Administration Guide gehört zur System Administrator Collection von Solaris 9 und kann von der Adresse http://docs.sun.com heruntergeladen werden.
Einrichten der Netzwerkschnittstellenfehler-Erkennungszeit
Damit HADB die Multipathing-Ausfallsicherung ordnungsgemäß unterstützt, darf die Netzwerkschnittstellenfehler-Erkennungszeit gemäß Spezifikation durch den Parameter FAILURE_DETECTION_TIME in /etc/default/mpathd 1000 Millisekunden nicht übersteigen. Bearbeiten Sie die Datei und ändern Sie den Wert dieses Parameters auf 1000, wenn der Originalwert höher ist:
FAILURE_DETECTION_TIME=1000 |
Damit die Änderung wirksam ist, geben Sie den folgenden Befehl aus:
pkill -HUP in.mpathd |
Mit HADB zu verwendende IP-Adressen
Gemäß Erläuterungen im Solaris IP Network Multipathing Administration Guide umfasst das Multipathing die Gruppierung physischer Netzwerkschnittstellen in Multipath-Schnittstellengruppen. Jede physische Schnittstelle in einer derartigen Gruppe ist mit zwei IP-Adressen assoziiert: einer physischen Schnittstellenadresse und einer Testadresse. Lediglich die physische Schnittstellenadresse kann zum Übertragen von Daten verwendet werden. Die Testadresse dient nur für interne Solaris-Zwecke. Wenn hadbm create --hosts ausgeführt wird, darf jeder Host mit nur einer physischen Schnittstellenadresse der Multipath-Gruppe spezifiziert werden.
Beispiel
Angenommen, Host 1 und Host 2 verfügen jeweils beide über zwei physische Netzwerkschnittstellen. Auf jedem Host werden diese beiden Schnittstellen als Multipath-Gruppe eingerichtet und beim Ausführen von ifconfig -a erhalten Sie Folgendes:
Host 1
bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000 broadcast 129.159.115.255 |
Host 2
bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000 broadcast 129.159.115.255 |
Hier sind die physischen Netzwerkschnittstellen auf beiden Hosts, als bge0 und bge1 aufgelisteten Schnittstellen. Die als bge0:1 und bge1:1 aufgelisteten Schnittstellen sind Multipath-Testschnittstellen (sie werden daher im ifconfig-Output mit DEPRECATED gekennzeichnet). Siehe dazu auch den IP Network Multipathing Administration Guide.
Zum Einrichten von HADB in dieser Umgebung wählen Sie eine physische Schnittstellenadresse von jedem Host. In diesem Beispiel wählen wir 129.159.115.10 von Host 1 und 129.159.115.20 von Host 2. Zum Erstellen einer Datenbank mit einem Datenbankknoten pro Host verwenden Sie das folgende Argument für hadbm create:
--host 129.159.115.10,129.159.115.20 |
Zum Erstellen einer Datenbank mit zwei Datenbankknoten auf jedem Host verwenden Sie das folgende Argument:
--host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20 |
In beiden Fällen muss die Variable ma.server.mainternal.interfaces auf beiden Hosts auf 129.159.115.0/24 festgelegt werden.
Es ist nicht möglich, online von 4.2 oder 4.3 auf 4.4 upzugraden. Die Version 4.4 unterstützt jedoch Online-Upgrades für zukünftige Versionen. Zum Aufrüsten von 4.4.1 auf 4.4.2 gehen Sie wie folgt vor:
Installieren Sie 4.4.2 auf allen HADB-Hosts (in einem anderen Pfad als Version 4.4.1 – beispielsweise /opt/SUNWhadb/4.4.2-6).
Installieren Sie die neue Version auf den hadbm client-Hosts.
Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.
Starten Sie die Management-Agent-Prozesse mithilfe der Software der neuen Version, jedoch mit den alten Konfigurationsdateien. Für die verbleibenden Schritte verwenden Sie den Befehl hadbm, der im bin-Verzeichnis der neuen Version zu finden ist.
Registrieren Sie das Paket in der Management-Domäne (der Standard-Paketname lautet hier V4.4, sodass evtl. ein anderer Paketname erforderlich ist, um Konflikte mit vorhandenen Paketen zu vermeiden, die denselben Namen haben):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2 |
Starten Sie die Datenbank mit der neuen Version neu (mit dem folgenden Befehl wird ein Bildlauf-Neustart der Knoten ausgeführt):
hadbm set packagename=V4.4.2 Datenbankname |
Prüfen Sie (mithilfe des Befehls hadbm status), ob der Datenbankstatus “running” lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.
Wenn alles funktioniert, kann die alte Installation später entfernt werden:
Bevor Sie die Registrierung des alten Pakets aufheben, entfernen Sie alle Verweise auf das alte Paket aus der ma-Repository. Anderenfalls schlägt hadbm unregisterpackage fehl und gibt die Fehlermeldung "package in use" aus.Eine Dummy-Neukonfigurationsoperation, z. B. hadbm set connectiontrace=<wie voriger wert> entfernt alle Verweise auf das alte Paket. Heben Sie jetzt die Registrierung des alten Pakets auf:
hadbm unregisterpackage [--hosts=<host_list>] <old_package_name> |
Entfernen Sie die alte Installation aus dem Dateisystem (siehe HADB-Installationsanweisungen.
Es ist nicht möglich, einen sekundären Index einer Tabelle vom Typ UNIQUE zu erstellen.
Der Ausdruck (DISTINCT column) ist in einem Aggregatausdruck nicht zulässig; es sei denn, es handelt sich um den einzigen ausgewählten Ausdruck.
Alle Tabellen müssen mit einer Primärschlüssel-Spezifikation erstellt werden (d. h., Tabellen ohne Primärschlüssel werden nicht unterstützt).
FULL OUTER JOIN wird nicht unterstützt.
IN-Unterabfragen, bei denen es sich um Tabellenunterabfragen handelt, werden nicht unterstützt; beispielsweise:
SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP WHERE P#='P2') |
Andere Beschränkungen als NOT NULL und PRIMARY KEY werden nicht unterstützt.
Es besteht die Möglichkeit, einer Ressource einen neuen Eigentümer zuzuweisen. Wenn dieser Schritt durchgeführt wird, werden jedoch die dem aktuellen Eigentümer gewährten Zugriffsrechte nicht auf den neuen Eigentümer übertragen.
Zwei oder mehr verschachtelte NOT EXISTS-Unterabfragen, bei denen die einzelnen Unterabfragen nicht (direkt) mit der äußeren Ebene der Abfragen in Wechselbeziehung stehen, werden nicht unterstützt.
Spalten-Zugriffsrechte werden nicht unterstützt.
Zeilenwert-Constructors sind nur in einer VALUES-Bedingung zulässig.
Unterabfragen werden in Zeilenwert-Constructors nicht als Wertausdrücke akzeptiert.
Die folgenden Datentypen können beim Erstellen von Primärschlüsseln nicht verwendet werden:
REAL
FLOAT
DOUBLE PRECISION
DECIMAL
NUMERIC
In Application Server ist Folgendes enthalten: Lastenausgleich für HTTP-, IIOP- und JMS-Clients, Failover-Unterstützung für HTTP-Sitzungen, Unterstützung für EJB-Clustererstellung und -Failover, hochverfügbare EJB-Timer, Wiederherstellung verteilter Transaktionen, Unterstützung für parallele Anwendungsaktualisierungen sowie eine Hochverfügbarkeitsdatenbank zur Speicherung des Übergangsstatus von J2EE-Anwendungen.
Die Hochverfügbarkeit ermöglicht den Failover-Schutz für Application Server-Instanzen in einem Cluster. Wenn eine Application Server-Instanz zusammenbricht, übernimmt eine andere Application Server-Instanz die Sitzungen des nicht mehr verfügbaren Servers. Sitzungsinformationen werden in der HADB gespeichert. Die HADB unterstützt Persistenzspeicherung für HTTP-Sitzungen, Stateful Session Beans und Single Sign On-Anmeldeinformationen.