Zusammenfassung der Probleme Dieses Problem tritt auf, wenn die ursprüngliche Platte eine Root-Verkapselung aufweist und ein Live-Upgrade von VxVM 3.5 unter Solaris 9 8/03 OS auf VxVM 5.0 unter Solaris 10 6/06 OS versucht wird. Das Skript vxlufinish schlägt fehl und es wird folgende Fehlermeldung ausgegeben:
#./vslufinish -u 5.10 VERITAS Volume Manager VxVM 5.0 Live Upgrade finish on the Solaris release <5.10> Enter the name of the alternate root diskgroup: altrootdg ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory Killed ld.so.1: ugettxt: fatal: libvxscsi.so: open failed: No such file or directory ERROR:vxlufinish Failed: /altroot.5.10/usr/lib/vxvm/bin/vxencap -d -C 10176 -c -p 5555 -g -g altrootdg rootdisk=c0t1d0s2 Please install, if 5.0 or higher version of VxVM is not installed on alternate bootdisk. |
Problemumgehung: Verwenden Sie stattdessen zur Aufrüstung die Standardaktualisierungsmethode oder die Aktualisierungsmethode mit Dual-Partition.
Wenden Sie sich an den Sun-Support oder Ihren Sun-Partner, um zu erfahren, ob eine Unterstützung für Sun Cluster 3.2 Live Upgrade für VxVM 5.0 zu einem späteren Zeitpunkt zur Verfügung steht.
Zusammenfassung der Probleme Beim Live Upgrade schlagen die Befehle lucreate und luupgrade fehl, mit denen DID-Namen in der alternativen Boot-Umgebung, die dem Eintrag /global/.devices/node@N entspricht, geändert werden.
Problemumgehung: Bevor Sie das Live Upgrade starten, führen Sie folgende Schritte auf allen Cluster-Knoten durch.
Melden Sie sich als Superuser an.
Sichern Sie die Datei /etc/vfstab.
# cp /etc/vfstab /etc/vfstab.old |
Öffnen Sie die Datei /etc/vfstab zur Bearbeitung.
Suchen Sie die Zeile, die /global/.device/node@N entspricht.
Bearbeiten Sie den Eintrag für das globale Gerät.
Ändern Sie die DID-Namen in physische Namen.
Ändern Sie /dev/did/{r}dsk/dYsZ in /dev/{r}dsk/cNtXdYs Z.
Entfernen Sie global aus dem Eintrag.
Das folgende Beispiel zeigt den Namen des DID-Geräts d3s3, das /global/.devices/node@s entspricht, wobei der Name in den physischen Gerätenamen geändert und global aus dem Eintrag entfernt wurde:
Original: /dev/did/dsk/d3s3 /dev/did/rdsk/d3s3 /global/.devices/node@2 ufs 2 no global Changed: dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /global/.devices/node@2 ufs 2 no - |
Nachdem Sie die Datei /etc/vfstab auf allen Cluster-Knoten geändert haben, führen Sie das Live Upgrade des Clusters durch. Unterbrechen Sie den Vorgang jedoch, bevor Sie einen Neustart in der aktualisierten alternativen Boot-Umgebung durchführen.
Stellen Sie auf allen Knoten der aktuellen, nicht aktualisierten Boot-Umgebung die ursprüngliche Datei /etc/vfstab wieder her.
# cp /etc/vstab.old /etc/vfstab |
Öffnen Sie in der alternativen Boot-Umgebung die Datei /etc/vfstab zur Bearbeitung.
Suchen Sie die Zeile, die /global/.devices/node@N entspricht und ersetzen Sie den Strich (-) am Ende des Eintrags durch das Wort global.
/dev/dsk/cNtXdYsZ /dev/rdsk/cNtXdYsZ /global/.devices/node@N ufs 2 no global |
Starten Sie den Knoten in der aktualisierten alternativen Boot-Umgebung neu.
Die DID-Namen werden in der Datei /etc/vfstab automatisch ersetzt.
Zusammenfassung der Probleme Dieses Problem tritt beim Aufrüsten von VERITAS Volume Manager (VxVM) während eines Sun Cluster Live Upgrade-Vorgangs auf. Das Skript vxlustart dient zur Aufrüstung von Solaris OS und VxVM von der Vorgängerversion. Das Skript schlägt fehl und es wird in etwa folgende Fehlermeldung ausgegeben:
# ./vxlustart -u 5.10 -d c0t1d0 -s OSimage VERITAS Volume Manager VxVM 5.0. Live Upgrade is now upgrading from 5.9 to <5.10> … ERROR: Unable to copy file systems from boot environment <sorce.8876> to BE <dest.8876>. ERROR: Unable to populate file systems on boot environment <dest.8876>. ERROR: Cannot make file systems for boot environment <dest.8876>. ERROR: vxlustart: Failed: lucreate -c sorce.8876 -C /dev/dsk/c0t0d0s2 -m -:/dev/dsk/c0t1d0s1:swap -m /:/dev/dsk/c0t1d0s0:ufs -m /globaldevices:/dev/dsk/c0t1d0s3:ufs -m /mc_metadb:/dev/dsk/c0t1d0s7:ufs -m /space:/dev/dsk/c0t1d0s4:ufs -n dest.8876 |
Problemumgehung: Verwenden Sie zur Aufrüstung des Clusters auf VxVM 5.0 die Standardaktualisierungsmethode oder die Aktualisierungsmethode mit Dual-Partition.
Wenden Sie sich an den Sun-Support oder Ihren Sun-Partner, um zu erfahren, ob eine Unterstützung für Sun Cluster 3.2 Live Upgrade für VxVM 5.0 zu einem späteren Zeitpunkt zur Verfügung steht.
Zusammenfassung der Probleme Bei Clustern, auf denen VERITAS Volume Manager (VxVM) ausgeführt wird, schlägt die Standardaktualisierungsmethode bzw. die Aktualisierungsmethode mit Dual-Partition fehl, wenn die Root-Platte verkapselt ist:
Aufrüsten von Solaris OS auf eine andere Version
Aufrüsten von VxVM
Aufrüsten der Sun Cluster-Software
Der Cluster-Knoten stürzt nach der Aufrüstung ab und lässt sich nicht mehr booten. Dies liegt an den Änderungen an der Geräteklasse bzw. Gerätenummer, die von VxVM während der Aufrüstung vorgenommen wurden.
Problemumgehung: Heben Sie die Verkapselung der Root-Platte auf, bevor sie mit der Aufrüstung beginnen.
Wenn das oben angegebene Verfahren nicht richtig befolgt wird, können ernsthafte unerwartete Probleme auf allen Knoten auftreten, die gerade aufgerüstet werden. Außerdem führt das Aufheben der Verkapselung bzw. die Verkapselung der Root-Platte (jedes Mal) zu einem zusätzlichen automatischen Neustart des Knotens, wodurch sich die Anzahl der erforderlichen Boot-Vorgänge während des Aufrüstens erhöht.
Zusammenfassung der Probleme Nach einem Live Upgrade von Sun Cluster-Version 3.1 unter Solaris 9 auf Version 3.2 unter Solaris 10 können Zonen mit der Cluster-Software nicht ordnungsgemäß verwendet werden. Die Ursache des Problems liegt darin, dass die pspool-Daten für die Sun Cluster-Pakete nicht erstellt werden. Das heißt, diese Pakete, die an die nicht globalen Zonen weitergegeben werden müssen (z. B. SUNWsczu), werden nicht ordnungsgemäß weitergegeben.
Problemumgehung: Führen Sie nach der Aktualisierung der Sun Cluster-Pakete mit dem Befehl scinstall -R jedoch vor dem Starten des Knotens im Cluster-Modus folgendes Skript zweimal aus:
einmal für die Sun Cluster-Framework-Pakete,
einmal für die Sun Cluster-Datendienstpakete.
Bereiten Sie das Skript auf eine der folgenden Arten vor und führen Sie es aus:
Legen Sie die Variablen für die Sun Cluster-Framework-Pakete fest und führen Sie das Skript aus. Bearbeiten Sie anschließend die Variable PATHNAME für die Datendienstpakete und führen Sie das Skript erneut aus.
Erstellen Sie zwei Skripte, ein Skript mit den Variableneinstellungen für die Framework-Pakete und ein Skript mit den Variableneinstellungen für die Datendienstpakete. Führen Sie anschließend beide Skripte aus.
Melden Sie sich als Superuser an.
Erstellen Sie ein Skript mit folgendem Inhalt.
#!/bin/ksh typeset PLATFORM=${PLATFORM:-`uname -p`} typeset PATHNAME=${PATHNAME:-/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages} typeset BASEDIR=${BASEDIR:-/} cd $PATHNAME for i in * do if pkginfo -R ${BASEDIR} $i >/dev/null 2>&1 then mkdir -p ${BASEDIR}/var/sadm/pkg/$i/save/pspool pkgadd -d . -R ${BASEDIR} -s ${BASEDIR}/var/sadm/pkg/$i/save/pspool $i fi done
Legen Sie die Variablen PLATFORM, PATHNAME und BASEDIR fest.
Legen Sie diese Variablen entweder als Umgebungsvariablen fest oder bearbeiten Sie die Werte direkt im Skript.
Der Name der Plattform Zum Beispiel sparc oder x86. Der Standardwert der Variable PLATFORM ist die Ausgabe des Befehls uname -p.
Ein Pfad zu dem Gerät, von dem die Sun Cluster-Framework-Pakete bzw. -Datendienstpakete installiert werden können. Dieser Wert entspricht der Option -d im Befehl pkgadd.
Für Sun Cluster-Framework-Pakete hat dieser Wert beispielsweise folgendes Format:
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages |
Für Datendienstpakete hat dieser Wert beispielsweise folgendes Format:
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster_agents/Solaris_10/Packages |
Der vollständige Pfadname des Verzeichnisses, das als Root-Pfad verwendet werden soll und mit der Option -R des Befehls pkgadd übereinstimmt. Legen Sie für ein Live Upgrade diesen Wert mit dem Root-Pfad fest, der mit der Option -R des Befehls scinstall verwendet wird. Der Standardwert der Variable BASEDIR ist das Root-(/-)Dateisystem.
Führen Sie das Skript einmal für die Sun Cluster-Framework-Pakete und einmal für die Datendienstpakte aus.
Nach Ausführung des Skripts wird für jedes Paket folgende Meldung in der Befehlseingabeaufforderung angezeigt:
Transferring pkgname package instance |
Wenn das Verzeichnis pspool bereits für ein Paket vorhanden ist oder das Skript zweimal für denselben Paketsatz ausgeführt wird, wird folgender Fehler in der Befehlseingabeaufforderung angezeigt:
Transferring pkgname package instance pkgadd: ERROR: unable to complete package transfer - identical version of pkgname already exists on destination device |
Diese Meldung ist harmlos und kann ignoriert werden.
Nachdem Sie das Skript sowohl für die Framework-Pakete als auch für die Datendienstpakete ausgeführt haben, starten Sie die Knoten im Cluster-Modus.
Zusammenfassung der Probleme Wenn Sie einen neuen Cluster-Knoten hinzufügen, der nicht über dieselben Patches wie die bestehenden Cluster-Knoten verfügt, kann es zu einem Ausfall der Cluster-Knoten kommen.
Problemumgehung: Stellen Sie vor dem Hinzufügen eines Knotens zum Cluster sicher, dass der neue Knoten über dieselben Patch-Versionen wie die bestehenden Cluster-Knoten verfügt. Wenn Sie diese Überprüfung nicht durchführen, kann es zu einem Ausfall der Knoten kommen.