AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Grundsatzfrage: Wie vorgehen? (Netzwerk-Tool)
Thema durchsuchen
Ansicht
Themen-Optionen

Grundsatzfrage: Wie vorgehen? (Netzwerk-Tool)

Ein Thema von Phoenix · begonnen am 21. Dez 2008 · letzter Beitrag vom 22. Dez 2008
 
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.643 Beiträge
 
#1

Grundsatzfrage: Wie vorgehen? (Netzwerk-Tool)

  Alt 21. Dez 2008, 12:13
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?
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:41 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz