Spezielle Bereitstellungs- und Upgrade-Informationen

In diesem Abschnitt werden zusätzliche Informationen über HADB-Bereitstellung und Upgrade aufgeführt.

• Bereitstellung

• Online-Upgrade von 4.4.1 auf 4.4.2

Bereitstellung

• 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.

Online-Upgrade von 4.4.1 auf 4.4.2

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:

1. 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).

2. Installieren Sie die neue Version auf den hadbm client-Hosts.

3. Beenden Sie alle Management-Agenten, die auf den HADB-Hosts ausgeführt werden.

4. 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.

5. 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

6. 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

7. Prüfen Sie (mithilfe des Befehls hadbm status), ob der Datenbankstatus “running” lautet und ob die Datenbank normal funktioniert und die Client-Transaktionen übermittelt.

8. 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.