Hallo Sysadmins,

ab Veritas Cluster 5.0 MP3 gibt es eine Service Gruppe Namens VCShmg. Komischerweise ist sie immer offline und es gibt nichts zu konfigurieren daran.  Die darin einzige Rescource VCShm ist allerdings online auf allen Systemen im Cluster.

Das Ding ist mir erst gar nicht aufgefallen, weil ich es nur mit Clustern zu tun hatte die von Version 4.1 upgegradet waren. Dort taucht dann diese Gruppe nicht auf.

Auch sieht man die Gruppe mit hastatus -sum nicht …

Also: Was’n'das?

Der Cluster überwacht die Auslastung von CPU und Swap Space auf der Maschine mit Hilfe eines Daemons Namens HostMonitor. Dieser Daemon ist neu seit Version 5.0 MP3. Auch bei den System die durch Upgrade auf diesen Stand gebracht worden sind, läuft er im Hintergrund.

Bei neu aufgesetzten Clustern wird nun eine extra Service Group für den HostMonitor angelegt. Um zu dokumentieren, das man den Status der Gruppe nicht konfigurieren kann, wird sie immer als Offline angezeigt.

Wie schon gesagt, nur in der GUI.  Weder die Resource noch die Gruppe taucht in der main.cf auf! Bei hastatus werden die Resourcen pro Maschine gelistet, aber bei hastatus -sum bleibt die Gruppe unerwähnt.

Und wozu ist das nun gut?

Nun …..

Es soll ja “Spezialisten” geben, die geclusterte Maschinen bei 95% CPU Auslastung betreiben. Kommt dann mal ein bisschen mehr Last auf die Maschine, kommt es zu einer System Panic, weil GAB glaubt das wäre sinnvoll …

Ich vermute mal, das Symantec die Nase voll von solchen “Spezialisten” und ihren Service Calls hatte. Der HostMonitor protokolliert die Auslastung von CPU und Swap in der VCS Engine und im Syslog der Maschine. Und somit ist die Ursache der Panic schnell gefunden.

Fragt sich, warum die Leute Geld und Zeit investieren um ihre Anwendungen hochverfügbar zu gestalten, um dann kein Geld für angemessene Hardware übrig zu haben?

Viele Grüße

Michael

Hallo Sysadmins,

hier ein kleines Beispiel wie man Solaris 10 mit ZFS als Root Filesystem patchen und upgraden kann:

Wenn Zonen auf dem System sind, sollten sie installiert und gebootet sein. Überprüfen kann man das mit

zoneadm list -cv

Da wir auf dem System die Zonen mit VCS schwenken und die Root Filesysteme der Zonen mit VxFS realisiert sind, habe ich die Zonen zunächst deportiert und dann für das Update des OS auskommentiert:

zoneadm -z <zönchen> detach

in /etc/zones/index mit führendem # auskommentieren

Bei Solaris 10 5/09 gibt es einen Bug bei luactivate. Als Workaround sollte folgende Variable in der Shell exportiert sein:

export BOOT_MENU_FILE=”menu.lst”

Und los geht es:

1. lucreate -n Solaris_10_10-09
2. luupgrade -u -n Solaris_10_10-09 -s /cdrom/…
3. luupgrade -t -n Solaris_10_10-09 -s /…/10_Recommended/
4. lustatus
5. luactivate Solaris_10_10-09
6. init 6

Die dann noch fehlenden Zonen wieder einkommentieren und mit

zoneadm -z <zönchen> attach -u

auf den neusten Stand bringen.

Wenn dann alles OK gelaufen ist, kann man noch die ZFS Pools updaten:

zpool upgrade <rootpool>

und die alte BE löschen:

ludelete Solaris_old-BE

aber auch hier muss die Shell Variable wie oben beschrieben gesetzt sein.

Viele Grüße

Michael

Sind wir Stimmvieh wirklich so dumm, wie wir verkauft werden? Man erringt also innerhalb von ein paar Jährchen in der Politik, vor allem mit der “genialen” Idee Kinderpornographie nicht zu bekämpfen, sondern das Hinsehen zu verbieten, so viel Reputation das es zum höchsten repräsentativen Amt im Staate reicht?