[SAGE-MUC] Sun Cluster: SUNW.gds
Armin Kunaschik
armin.kunaschik at gmx.de
Sa Jul 5 00:52:56 CEST 2008
Moin, moin,
Urs Schürer - sitb - wrote:
> nur falls ein total Fan vom Solaris Cluster (ja,ja,die Marketing Leute)
> unter Euch sein sollte (Wolfgang?):
Ich dachte, dass Solaris Cluster jetzt frei verfuegbar ist... da sollte doch kein
Marketing mehr Geld damit verdienen!? Und nachdem, was ich so gehoert habe,
ist die neue Version sogar richtig gut, sodass man sich die Investition in den
Veritas-Tausend-Schrauben-Cluster sparen kann..
Um es gleich klar zu stellen, ich habe noch nie was mit SunCluster gemacht,
kenne aber ein paar andere recht gut. Die folgenden Zeilen sind also purer Verdacht...
> Ich versuche gerade in meiner Unfähigkeit eine SUNW.gds Resource zu
> konfigurieren, in der Art:
>
> # clrs create -g sctest2_failover -t SUNW.gds \
>> -p Start_command="..." \
>> -p Stop_command="..." \
>> -p Probe_command="..." \
>> -p Stop_signal=9 \
>> -p Network_aware=false \
>> -p Failover_enabled=false \
>> -p ....
> ...
> Wobei die Start/Stop/Probe Commands alle wunderbar funktionieren, wenn
> ich sie von Hand auf dem jeweiligen Node aufrufe, auf dem sie dann ggf.
> dran wären.
Das klingt doch schon mal nicht schlecht. Kannst Du die Scripte auch vom
anderen Cluster-Knoten via ssh node2 "start_command" aufrufen?
Falls nicht, wird wohl irgendwas in Deinem Environment fehlen. Gerne
fehlen hier $PATH, $ORACLE_HOME etc. Zum Testen kannst Du ja mal Dein
.profile (.cshlogin, .bash_profile etc.) in den Cluster-Scripts sourcen.
> Versuche ich aber dann die Resource zu enablen, dann geht deren State
> ziemlich schnell auf "UNKNOWN", der RGM faselt noch ein bisschen was von
> wegen:
>
> Cluster.RGM.rgmd: resource sctest2_apps state on node atlantic:sctest2
> change to R_STARTING
> Cluster.RGM.rgmd: resource sctest2_apps status on node atlantic:sctest2
> change to R_FM_UNKNOWN
> Cluster.RGM.rgmd: resource sctest2_apps status msg on node
> atlantic:sctest2 change to <Starting>
> Cluster.RGM.rgmd: Method <gds_svc_start> failed on resource
> <sctest2_apps> in resource group <sctest2_failover> [exit code <1>, time
> used: 100% of timeout <300 seconds>]
> Cluster.RGM.rgmd: resource sctest2_apps state on node atlantic:sctest2
> change to R_START_FAILED
> Cluster.RGM.rgmd: resource sctest2_apps status on node atlantic:sctest2
> change to R_FM_FAULTED
>
> ... und dann steht sie im State "Start failed" und das wars. Irgendwer
> der mir einen Tip in die richtige Richtung geben könnte?
Hier waere interessant, ob die Applikation danach laeuft oder nicht (oder recht
schnell beendet wird)? Das koennte ein Indiz dafuer sein, dass Du einfach
das Falsche an den Cluster zurueck gibst (Return Code, String etc).
Beispiel bei Veritas Cluster: Das Monitor-Script MUSS die Return-Codes
100-110 zurueckgeben. Andere fuehren zu einem aehnlichen Zustand und koennen
den Cluster ziemlich durcheinander bringen (obwohl die Applikation laeuft).
Ausserdem sollten sich Deine Start- und Stop-Scripte komplett beenden, also
keine Child-Prozesse starten oder File Deskriptoren offen lassen. Bei der
Timeout-Zeile koennte man sowas vermuten. Deine Applikation sollte sich
komplett daemonisieren (fork...), notfalls mit "nohup app >/dev/null 2>&1 &".
Sollte das jetzt nicht weiterhelfen, dann hilft wahrscheinlich nur, intensives
Logfile-Studium, das Loglevel zu erhoehen und die Start-, Probe- und Stop-Scripte
viel Debug-Output generieren zu lassen.
Den ueblichen Rat mit dem "friggin manual" hast Du ja bestimmt schon beherzigt? :-)
Ciao,
Armin