Der Vorteil: der Kollege in der Nachbarschaft ist Miteigentümer und hat keine Oma.
Daher keine zusätzlichen Kosten und wenig Ablenkung

Meine Strategie ist ja, die Server automatisch bis aufs absolute Minimum (Router/Web) runterzufahren, wenn nicht innerhalb einer bestimmten Zeit korrigierend eingegriffen wurde.

Die Scripte zum Runterfahren sind weniger aufwendig als die Software für den AVR. Wenn ich auf Python hinweisen darf...

Grüße
Malte

Geändert von hybrid am 02. Dezember 2005 um 21:22

*gelöscht gem. BDSG*

Nach der Abwatsche (danke dafür) nochmal zum Problem:

Zugegeben, die Haustechnik für unseren Serverraum gehört dem Kunden, für den wir das RZ betreiben. Ergo haben die selber ein Interesse daran, dass die Klimatisierung stimmt. Zusätzlich haben wir (IT) einen eigenen sog. Steuerplatz, an dem 24/7 mehrere Leute die Server über Konsolen überwachen - macht Sinn, speziell, wenn man Drei-Buchstaben-Hardware einsetzt

Da hängen also ca 30 Monitore and er Wand, und, damit man den Überblich nicht verliert, gibt es einen Beamer, der den Status der Systemsmanagement-Konsole darstellt. Da sind alle Systeme in Gruppen zusammengefasst, damit es eine übersichtliche Darstellung ist. Das sind dann farbige "Buttons", die hoffentlich alle grün sind. Wird einer davon gelb (warning) oder gar rot (critical), geht eine Tröte los und die Jungs werden aktiv. Können sie es nicht selber, gibt's ne Rufbereitschaft.

Klingt gut, gell?
Hilft aber nur in ca. 50% der Fälle. Wenn Klima nämlich ausfällt, müssen die Server (~400 auf Windows oder Linux, einige AIX und SUN/Solaris, eine Z-Serie mit 4 CPUs, plus Hicom und Bond-ACD-Anlage) runter, bevor die Temperatur zu hoch wird, und die Teile von selber runterfallen. Das ist fast nicht zu schaffen.

Folgendes hatten wir schon:
Temperatursensor schlägt nicht an
SysMgmt reagiert nicht/falsch auf Temperaturwarnung
Temperaturwarnung war ausgeschaltet (Wartung) und vergessen worden...

Ich hab noch so ein paar, die sich auf volle Volumes, defekte Lüfter, abgeschaltete Cisco-Router usw. beziehen.

Je komplexer die Kette, desto leichter ist es, da einen Defekt zu haben, der die gesamte Kette ad absurdum führt.

Ich rate daher zu einer KISS-Geschichte, z.B. GSM-Telemetriemodul, ggfs. redundant ausgelegt, das SMS an mehrere Leute schickt, die aktiv werden können. Wer Dienst hat und weiter weg wohnt, kann sich per PC (bei uns gibts dafür Bereitschaftsnotebooks, Bereitschaftshändis, einen Abteilungsleiter vom Dienst - ALDI genannt und eine Doppelbereitschaft) einwählen und ggfs. nach Abschaltplan die Serverlandschaft runterfahren.

100% sicher funktioniert das aber auch nicht

*gelöscht gem. BDSG*

Ich sag ja, selbst mit High-Tech und 4-Augen-Prinzip und das 24/7e der Fälle.

Zum Glück haben wir das Thema vertraglich geregelt. Wenn Eure Klimaanlage das nicht packt, dann unsere Server auch nicht, und damit eure Applikationen ebenfalls nicht.



Seit dem geht das, die Haustechnik hat zumindest das Klima und den Strom im Griff.
Aber mit den Schwarzblechen gibts auch ohne Environment genug Probleme.

So,

die Hardware ist fertig:

Ist ein Crumb8. Links das serielle Kabel (aus einer Maus gerippt). Oben der Spannungsteiler aus NTC und 10k Widerstand (ich hasse es, Anschlussbeinchen abzuknipsen) zw. ARef und AGnd. Quer darüber die Leitungen zur Spannungsversorgung. Wenn ich die 5V Zenerdiode habe, were ich versuchen ihn aus der Seriellen zu speisen.
Rechts der sechspolige ISP-Adapter. Habe jetzt beide Kabel gleichzeitig am AVRISP

Software ist aber noch zu schmuddelig, um sie zu veröffentlichen

Ich benutze die Module uart.c buffer.c a2d.c und timer.c aus der Procyon AVRlib.
Flashgröße ~3k.

Grüße
Malte

Geändert von hybrid am 06. Dezember 2005 um 22:46

Als wir noch lokale USVen in den 19"-Schränken hatten, hatten die eine RS232-Verbindung zum Server (leider immer nur einer pro Rack bzw. USV), der bei Stromausfall einen Trapp bekam. Die Weichware auf dem Server hat dann nach dem Trigger einen Shutdown gefahren (war wichtig, um die externen LanRes-Platten in der SAN zu unmounten - Server-down ohne vorher die Volumes abzuhängen war eine böse Sache).

Könnte man nicht das Signal der Temperaturüberwachung auf so einen Trap ummünzen - dem Server sollte es egal sein, warum er herrunterfahren soll...
Jedenfalls wäre die Software, die dann auf den trap reagiert schon vorhanden. Im Eventlog steht dann zwar "External command trap due to power failure", aber man weiß ja, dass es von dem Temperaturmodul kam.

Jedenfalls konnte diese Software alles mögliche machen - email schicken, shutdown einleiten, scripte starten...

würde das nicht helfen?

Ich habe gar kein Problem mit der Software, die die Server runterfährt...

Als Pseudocode würde das so aussehen:

####################

forever:

__Temperatur = leseTemperaturVonSerieller()

__if Temperatur > SCHWELLWERT:
____DauerDerUeberschreitung += 1

____if DauerDerUeberschreitung == ZEIT_FUER_MELDUNGEN:
______SchickeMeldungenAnAdmins()

____if DauerDerUeberschreitung == ZEIT_FUER_UNWICHTIGE_SERVER:
______shellcommand( "ssh server1 'powerdown'" )
______shellcommand( "ssh server2 'powerdown'" )

____if DauerDerUeberschreitung == ZEIT_FUER_WICHTIGERE_SERVER:
______shellcommand( "ssh server3 'powerdown'" )
______shellcommand( "ssh server4 'powerdown'" )

__else:
____if leseTemperaturVonSerieller() <= SCHWELLWERT: // Wirklich??
______DauerDerUeberschreitung = 0

__sleep( WARTEZEIT )

####################



Grüße,
Malte

Geändert von hybrid am 07. Dezember 2005 um 19:04

*gelöscht gem. BDSG*

Oopsie, mein else-Teil hatte wohl 'ne Macke
Hysterese ist eine sehr gute Idee, und natürlich müssen die Shell-Kommandos in den Hintergrund. Wäre ja noch schöner, wenn das herunterfahren wegen eines hängenden Servers nicht klappen würde...

Danke und Grüße
Malte