Skip to content

Sun's Try and Buy Programm (Part 8): DOT

Ich habe gerade beim Testen das "stabile" Solaris gecrashed: bei der Installtion einiger JES Komponenten habe ich auch den Sun Cluster ausgewählt. Ich habe es fertig bekommen den Cluster als eine Single Node Komponente zu installieren, jedoch war hinterher meine LAN Connectivity weg, weil das routing zerschossen war.

Meine Vermutung war, dass der scinstall des cluster nicht richtig auf die Settings mittels DHCP vorbereitet war, und er hat dann bei der Konfiguration von zusätzlichen internen Addressen und virtuellen Interfaces das Gateway und die Netzmaske vermasselt. Dank ALOM nicht weiter schlimm, ich komme ja über das Netz an die Console, aber wie löst man das Problem? Wie stellt man bei einer Solaris Kiste die Konfiguration auf statische Addressen um?

Ich hab keine bessere Lösung gefunden als die Initialkonfiguration noch einmal durchzuführen. Dazu ruft man "sys-uninstall" auf, und rebootet.

Nun gut, der Ansatz war prinzipiell nicht schlecht, das Setup hat mich tatsächlich nach den neuen Netzwerk Settings gefragt. Es hätte nur die Finger von dem neuen virtuellen Netzwerk interconnect Interface lassen sollen, das der Sun Cluster installiert hat. Denn plötzlich brach der Kernel mit einem Stacktrace weg, in dem die Komponente vorkam:
# mdb unix.0 vmcore.0
:Loading modules: [ unix krtld genunix specfs ufs sd: ip sctp random fcp fctl em
lxs nca ]
> ::status
debugging crash dump vmcore.0 (64-bit) from
operating system: 5.10 Generic_118822-26 (sun4v)
panic message: BAD TRAP: type=9 rp=2a100236a80 addr=0 mmu_fsr=0
dump content: kernel pages only
> ::stack
  *clprivnet*_wput+0x10c(60001859308, 600019b0740, 2a100232000, 600019bc3b0, e, 600019bc340)
  putnext+0x218(60001859400, 60001859308, 600019b0740, 100, 6000195e8d8, 0)
  ill_fastpath_probe+0xd4(0, 0, 1, 600019bc3b0, 600019b0780, 600019b0740)
  ire_fastpath+0x54(600019d16e8, 600019b0780, 20, 6000195e8d8, 600019d16e8, 60001856fa8)
  ire_add_v4+0xb20(2a1002371b0, 1, ffffffff, 1, 0, 0)
  ire_add+0x36c(2a1002371b0, 0, 0, 0, 4, 0)
  ipif_up_done+0x60c(6000194b748, 7005d800, 6000194b748, 2a1002371c0, 0, 6000194b764)
  ip_arp_done+0x130(0, 600019b1d40, 600015a1380, 60001856fa8, 8, 60001721060)
  qwriter_ip+0x68(60001721060, 60001856fa8, 6000195e8d8, 600015a1380, 12f1548, 0)
  ip_wput_nondata+0x440(0, 6000195e8d8, 600015a1380, c, 4000, 60001859308)
  putnext+0x218(6000195e9d0, 6000195e8d8, 600015a1380, 100, 6000195e648, 0) 
  ar_rput_dlpi+0x1d0(600019b0ac0, 600019b0ac0, 600019bcb30, 806000000000000, 20, 6000190f0d0)
  putnext+0x218(60001541e08, 600019a22c8, 600019b0ac0, 0, 600019a2558, 0)
  clprivnet_breq+0xd8(600019a2650, 600019b0ac0, 3, 806000000000000, 0, 14)
  clprivnet_proto+0x90(60001835e78, 600019b0ac0, 158, 60001835e40, 1, 600019bcb30)
  clprivnet_wsrv+0xd0(600019a2650, 2a100237cc0, 0, 600019b0ac0, 1, 600019bcac0)
  runservice+0x40(600019a26b8, 2a100237cc0, 2000, 600019a26b8, 600019a2650, 20000)
  stream_service+0x5c(600018a2150, 300005c4a00, 600014109a0, 0, 600018a2010, 600019a2650)
  taskq_d_thread+0x88(600014109a0, 300005c4a00, 6000140b298, 0, 1b85fea3b8, 600014109d0)
  thread_start+4(600014109a0, 0, 0, 0, 0, 0)

OOps, das ist nicht gut! Zumal das Problem auch beim Reboot im Single User Mode auftrat. Hier sollte das Sun Engeneering dringend mal Ihre treiber zum Thema HA ansehen. Es kann ja nicht sein dass man so einfach nen Kernel töten kann? (Früher reichte es schon eine unbekannte Netzwerkkarte in den Rechner zu stecken, das ist anscheinend immer noch nicht besser geworden. Das erinnert an Microsoft Bluescreens von vor 5 Jahren).

Nun ja, die Lösung war einfach (habe ich aber erst später herausgefunden): man kann mit "OK> boot disk -x" in einem Stand-Alone non-cluster mode booten und dann mittels "scinstall -r" den cluster tilgen.

Was ich aber dabei gelernt habe: das neue boot-rc Framework von Solaris 10 (SMF) kann mittels -m argumente auf der boot command line gesteuert werden. Das Problem war nämlich, nachdem ich es geschafft hatte in den Single-User mode zu booten, gab es immer noch Kerneldumps. Zum Beispiel "-m verbose" oder aber "-m milestone=none". Letzteres ist vergleichbar mit dem emergency boot mode unter Linux. Um mit ALOM sicher ins OpenBootPROM zu gelangen bietet sich (in meiner Version der Sun Fire T1000) der Befehl "reset -c" an.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Joerg Moellenkamp am :

Du weisst aber schon, das der Cluster unter bestimmten Bedingungen absichtlich die Maschine panikt, um Split-Brain zu vermeiden ?

Bernd Eckenfels am :

Ja ist bekannt, aber das müßte dann im Crash-Dump stehen. Zumal ein Single Node Cluster ja sich selbst als Vote hat und damit imemr die Majoritaet.... anyway, läuft ja jetzt wieder.

M Held am :

Hallo Bernd, leider hast du die Berichte über Suns Try&Buy-Programm nicht mehr fortgeführt. Besonders hätte mich (und vielleicht auch andere) interessiert, ob die Rücknahme bei dir ähnlich komplikationslos verlaufen ist wie bei mir. Hier von mir noch ein großes Lob an Sun für die absolut unkomplizierte und immer freundliche Abwicklung!

Bernd Eckenfels am :

Ja hast recht, muss ich noch machen, aber nur so viel: war absolut problemlos das Gerät wieder zurückzugeben. Gruss Bernd

Kommentar schreiben

BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Um einen Kommentar hinterlassen zu können, erhalten Sie nach dem Kommentieren eine E-Mail mit Aktivierungslink an ihre angegebene Adresse.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA