Grundsatzfrage: Wie vorgehen? (Netzwerk-Tool)

[Phoenix]

Hi,

ich habe ein kleines Tool auf meiner ToDo-Liste. Hintergrund ist Kostenoptimierung.

Darum gehts:
Mehre Server und drei USV's sind in einem Rack. Demnach hängen mehrere Server an einer USV. z.B. 3 Server an USV 1, zwei an USV 2 und wieder 3 an USV 3.

Jede USV hängt mittels Kabel aber nur genau an einem Server, um diesem den aktuellen Batteriezustand mitzuteilen. Will heissen: Nur einer von den zwei bis drei Servern an der USV wird im Stromausfallfall geregelt heruntergefahren. Die Software des USV-Herstellers die diese Lücke schliessen würde kostet etliche tausend Euro. Mein Tool soll das nun regeln.

Problemstellung:
Das ganze kann man auf verschiedenste Arten realisieren.

1.) Ein Dienst läuft auf dem einen Server, der unmittelbar von der USV benachrichtigt wird. Fährt er durch Signal der USV herunter, schickt der Dienst noch kurz ein UDP-Paket durchs Netz. Auf den anderen Servern läuft auch ein Dienst, die erkennen das Paket, wissen, wenn Paket von meinem 'Master' kommt muss ich auch runterfahren, und gut ist. Nur lassen sich solche UDP-Pakete leicht faken.

2.) Dienst auf Server wie in 1. Fährt der Rechner runter meldet sich der Dienst noch schnell per WMI an den abgänhgigen Rechnern an und fährt diese so herunter. Damit muss nichts auf den 'Clients' installiert werden, aber auf dem Master-Server sind die Credentials der abhängigen Server gespeichert, damit die WMI-Verbindung auch die anderen herunterfahren kann.

3.) Eine Client-/ Server Anwendung mit permanenten, auf jedem Rechner konfigurierten Verbindungen informiert sämtliche Rechner in einem Verbund jederzeit über den Energiestatus des Masters. Vor dem Runterfahren durch die USV (vor Abbauen der Verbindung) schickt der Master seinen Clients den Befehl zum runterfahren. Das hier ist großer Aufwand: Das Kommunikationsprotokoll muss geschrieben werden, das Ding muss auf Server und Client installiert und jeweils konfiguriert werden. Da wäre es wohl billiger, die Original-Software zu kaufen.

Meine Gedanken:
Eigentlich kann ausgeschlossen werden, dass jemand böswillig eine DOS-Attacke fährt. In dem Netz tummeln sich nur die zwei Chefs, ein Externer (ich), eine Mitarbeiterin und einmal in der Woche ein bestimmter Praktikant. Keiner von denen würde das Netz absichtlich sabotieren. Dennoch hätte ich ein extrem ungutes Gefühl dabei, das Unabgesichert zu programmieren. Schliesslich geht es um IT-Infrastruktur. Wenn es nicht funktioniert kann ein Rechner einfach so ohne Strom dastehen (nicht gut, insbesondere wenn viele VM's dort laufen). Wenn es zu einfach zu umgehen ist, dann kann jemand mit einfachen Mitteln den Serverraum bis auf die drei Master-Server runterfahren (auch wenn das niemand machen würde. Der Teufel ist ein Eichhörnchen).

Wie würdet ihr sowas angehen?

[Christian Seehase]

Moin Sebastian,

so spontan fällt mir da eine Ergänzung zu Idee 1 ein.
Der Masterserver meldet an die anderen im Verbund, dass er, auf Grund des USV-Status herunterfahren soll/will.
Die benachrichtigen Server fragen, über den Masterserver, den tatsächlichen Status der Stromversorgung/USV ab, um sicherzustellen, dass hier nicht gefakt wurde.

[Klaus01]

Hallo,

nur so eine Idee, da die Server ja anscheinend räumlich zusammenstehen...
Könnte man da nicht die entsprechende Kommunikation über die serielle Schnittstelle führen?
Die Einflussnahme von aussen wäre dann minimiert.

Grüße
Klaus

[alzaimar]

Wieso nicht UDP mit Port-Knocking?

[Phoenix]

Zitat:

Zitat von Klaus01

nur so eine Idee, da die Server ja anscheinend räumlich zusammenstehen...
Könnte man da nicht die entsprechende Kommunikation über die serielle Schnittstelle führen?
Die Einflussnahme von aussen wäre dann minimiert.

Erstens beinhaltet das zusätzliche Hardware die angeschafft werden müsste, und zum zweiten weiss ich nicht mal, ob die Rechner noch sowas wie serielle Schnittstellen haben. Und dann bräuchte der Master ja sogar 3 davon, um drei andere Rechner zu benachrichtigen. Das ist glaube ich nicht wirklich die perfekte Lösung ;-)

Zitat:

Zitat von alzaimar

Wieso nicht UDP mit Port-Knocking?

Prinzipiell ne gute Idee. Aber gibts da schon was fertiges für Delphi (oder .NET)? Schliesslich muss man sich unmittelbar hinter die Firewall hängen damit sowas klappt. Und sowas dann selber zu schreiben dass es den Rechner nicht noch unsicherer macht kostet wahrscheinlich doch mehr Zeit, als es das Wert ist.

Zitat:

Zitat von Christian Seehase

Der Masterserver meldet an die anderen im Verbund, dass er, auf Grund des USV-Status herunterfahren soll/will. Die benachrichtigen Server fragen, über den Masterserver, den tatsächlichen Status der Stromversorgung/USV ab, um sicherzustellen, dass hier nicht gefakt wurde.

Dann muss sichergestellt sein, dass der Master noch lang genug online bleibt, um allen Clients den USV-Status zu bestätigen. Kann ein Dienst den Shutdown eines Servers eigentlich verzögern? Aber diese Rückfrage macht die Sache schon sicherer, und treibt den Aufwand nicht zu hoch.

Danke. Noch mehr Ideen?

[Apollonius]

Zitat:

Zitat von Phoenix

Dann muss sichergestellt sein, dass der Master noch lang genug online bleibt, um allen Clients den USV-Status zu bestätigen. Kann ein Dienst den Shutdown eines Servers eigentlich verzögern?

Auf jeden Fall. Vor Windows Vista und Windows Server 2008 hat ein Service etwa 20 Sekunden Zeit für Aufräumarbeiten. Ab Vista und Server 2008 hat ein Service, der sich für den Code SERVICE_CONTROL_PRESHUTDOWN registriert, unbegrenzt Zeit, wenn das mit ChangeServiceConfig2 so konfiguriert wird.

[Phoenix]

Cool. 20 Sekunden sollten eigentlich in jedem Fall ausreichen, um mal kurz zwei, drei Pakete durchs Netz zu schicken.

[Assertor]

Hi,

Zitat:

Zitat von Phoenix

Noch mehr Ideen?

Wie wär es mit einer Named Pipe, dann kannst Du schon entsprechende Rechte vergeben und mußt das nicht auf Protokollebene aussortieren.

Gruß Assertor

:dp:

[mschaefer]

Hm würde doch noch mal darüber nachdenken ob das nicht Hardwaremässig so zu lösen ist, das jeder Server Datenverbindung zu seiner USV hat. Gestzt den Fall, das einer der Server aufgrund eines internen Defektes herunterfährt (überhitzter Prozessor mit Rechenfehlern, Virus,..) dann würden die anderen noch weiterlaufen. ImFalle eines Banalen Stromausfalles für alle geht das mit dem Netz auch nur, wenn keine Switch ohne Strom im Weg ist.

Grüße // Martin

[Michael Habbe]

Wenn auf dem Master ein Dienst läuft, der auf Nachfrage seinen Status sendet, sollte es doch für die Clients einfach sein, darauf zu reagieren. Wenn der Master "online" zurückgibt, weisst Du, sie laufen auf Power. Bei "usv" kannst vielleicht sogar die Restzeit mitsenden. Und wenn der Master "shutdown" sendet, wird er gerade heruntergefahren. Sollte der Master innerhalb einer gewissen Zeit sich nicht melden (kannst Du zur Sicherheit ja mehrfach abfragen), den Client herunterfahren.
Somit ist auch der Sicherheit genüge getan, Du musst ja nur den Master bei den Clients eintragen. Von aussen kann dann keiner mehr manipulieren.