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.

[RWarnecke]

Ich würde statt der seriellen Schnittstelle vielleicht die USB-Schnittstelle verwenden. Damit wäre Dein Hardwareaufwand ziemlich niedrig, denn USB sollten Deine Server doch haben oder ?

Die andere Variante wäre noch, die Messages oder Befehle, die die USV an den Master gibt, jeweils an die anderen Rechner im Verbund weiterzuleiten. Ich würde das über eine ganz einfache Client-Server Anwendung realisieren. Dabei schickt der Server an seine Clients (die jeweils anderen Server im Verbund) die jeweiliges Message von der USV + einem Schlüssel. Wenn die Message/Befehl zum herunterfahren kommt, dann wird das an den Client weitergeleitet. Der Client überprüft den mitgeliferten Schlüssel, stimmt dieser überein, dann wird der Server heruntergefahren.

[alzaimar]

Ehrlich gesagt, ich würde mir einen kleinen Service (Web, COM, TCP-generisch.. egal) schreiben, über den ich mich mit einem SecurityManager anmelde, meine Dinge, die ich zu sagen habe, abliefere und dann in die ewigen Jagdgründe terminiere.

Dieser Service läuft auf allen Servern und derjenige, der zuerst etwas zu sagen hat ('ähhrrgl...bin getroffen.... Billy "The Kid" Gates und Steven "Animal" Ballmer haben mich erlegt.....fump-plumps') sagt eben was und dann kann der Service eben auch kontrolliert und im Rahmen der normalen kollegialen Souveränität suizidale Routinen aufrufen, die eben den letzten Willen auf Festplatte manifestieren. Oder sonst irgendwelche kongenialen Dinge anstellen. Großartig torpedieren kann man diese Services nicht, außer man hebelt eben den SecurityManager aus, was -je nach Implementierung- Spaß macht oder nicht.

Dann ist es eben ziemlich schnurz, wer gerade die USV-LifeLine besitzt. Wer auch immer stirbt, schreit. Wer denn nun diesen Service implementiert, kann dann durch ein knappes UDP-Broadcast "Wo ist die Sterbehilfe" präventiv nachgefragt werden.

[Phoenix]

Zitat:

Zitat von 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.

Ginge schon. Nur ist das dann die Lösung vom USV-Anbieter, und die kostet halt richtig viel Geld. Und zwar so viel, dass mein Kunde eigentlich ne günstigere, dafür aber nicht 100%-Lösung haben will.

Nur ich persönlich hätte halt Bauchschmerzen ein Tool abzuliefern, dass den halben Serverraum runterfährt, ohne dass dafür Bedarf besteht.

Ich hab grad ne andere Idee:
Die Server-Applikation benutzt eine Datenbank (z.B. Blackfish) und schreibt den Status der USV da rein. Die Clients Connecten sich auf die Datenbank und pollen z.B. von sich aus alle 10 Sekunden den Status. Der Server hat über die Datenbank die Möglichkeit, alle verbundenen Clients zu finden, und bei Bedarf (Strom geht auf USV) schickt er einen UDP Broadcast. Die Clients setzen daraufhin das Polling-Intervall für eine bestimmte Zeitspanne hoch. Geht der Status des Servers auf Shutdown fahren alle Clients herunter. Sind alle Clients von der DB abgemeldet (keine externen Connections mehr) fährt auch der Master runter.

Was ich nicht will ist, dass alle Clients runterfahren, wenn der Master absichtlich heruntergefahren wird.

[Volle]

Hoi,

warum nimmst du nicht den ansatz mit dem seriellen anschluss?
Kann nicht wirklich gefaket werden und dürfte relativ simpel zu implementieren sein.
Ja, du weist nicht ob deine rechner noch nen seriellen anschluss haben aber hau doch einfach nen usb HUB an deinen master ran und kauf dir so viele usb->seriell adapter wie du brauchst und koppel die dinger damit. Oder machs gleich wie RWarnecke meinte mittels usb.

[Phoenix]

Nochmal: Eine wie auch immer geartete Hardware-Lösung kommt nicht in Frage.

Eine Hardware-Kommunikation zu implementieren (sei es jetzt Seriell oder über USB) ist ein Aufwand, der die ganze Aktion dann nicht mehr rechtfertigt. Insbesondere, wenn noch Kosten für die Hardware bzw. Verkabelung dazu kommt. Ich hab mit seriellen Protokollen schonmal gearbeitet und USB ist nicht so einfach wie man es mal kurz hinsagt.

Dann ist es billiger, die paar Tausend Euro für die original-USV Lösung hinzulegen und eine rundum-100% Lösung zu haben.

[turboPASCAL]

Ich würde wie Beschrieben einen Service schreiben der den/die Clients benachrichtigt wenn er über die USV herunter fährt.
Vorteil ist das das Programm dann leicht erweiterbar ist. Eine Datenbankfummelei ist wieder so ein Ding bei der die
unter Vista eh schon gestresste HD noch ein wenig mehr davon bekommt. Kommt mir jetzt nicht mit dem Festplattencahe, der hat auch noch was anderes zu tun.
Was das Faken der Shutdownnachricht angeht kann man doch mit IP-Adressen oder MAC-Adresse das Vorgaukenl von falschen Nachrichten
begrenzen, denk ich mal so.