Tier Architektur

[alexdgg]

Hallo Leute,

ich habe eine Grundsatzfrage zur Planung eines neuen Projektes.

Folgende Situation:

Ich möchte ein queuing-system für unsere Firma schreiben, dass FE-Berechnungen auf unsere Berechnungsservern (Linux) in einer Queue verteilt.

Wir haben 31 Berechnungsingenieuren und 17 Berechnungsserver (Teilweise im Cluster) mit vier verschiedenen FE-Solvern. Momentan gibt es durch die Kombinatorik dieser 3 Faktoren sehr viel Chaos bei der Auslastung und Verteilung der Berechnungsserver.

Die Software soll nicht nur das queuing der Jobs übernehmen sondern auch eine Art Systeminformation zu den einzelnen Servern und Clustern für die Usern zur Verfügung stellen.

Auf den Berechnungsservern werde ich jeweils einen Java-RMI-Server aufsetzen und die Infos (CPU Auslastung ‚mpstat -P ALL’, Speicherbenutzung , alles was ‚ps –eFl’ liefert, HDD Auslastung etc..) und Befehle (Jobs der User) im Sekundentakt von/zu einem zentralen Middle-Tier (RMI) senden/empfangen. Und das möglichst im Sekundentakt. Die Nutzer bekommen eine GUI zur Steuerung der Jobs und zur Anzeige des Status der Berechnungsserver.

Jetzt die eigentliche Frage. Ich bin mich nicht sicher wie ich die Kommunikation zwischen Client und Middle-Tier ablaufen soll. Ich denke die Daten im Sekundentakt vom Middle-Tier in eine MS-SQL 2005 Server DB zu schaufeln und den Clients über SQL Abfragen auf der DB die Infos zur Verfügung zu stellen. Allerdings sind die Datenmengen sehr groß. Jeder Berechungsserver hat 8 CPUs und es sollen die letzten 400 werte pro CPU gespeichert werden. Also 8 pro Sekunde und pro Server. Das gleiche für den Speicher, die Prozesse ect… Dazu kommt, dass 31 Berechnungsingenieure diese Daten im Sekundentakt von der DB abrufen könnten. Also sehr viele Transaktionen und Abfragen auf dem SQL-Server.

Ist das zuviel für den SQL-Server und das Transaktionsprotokoll? Sollte ich besser über RMI zwischen Middle-Tier und Client die Daten verteilen (Obwohl ich die Daten letztendlich sowieso für statistische Auswertungen in der DB brauche).

Oder gibt es da noch bessere Optionen. Ich würde die SQL Variante bevorzugen, da ich über SQL Abfragen die Daten dem Clienten sehr einfach aufbereiten kann.

Da ich die Software (die Clients und die Server über RMI) eigentlich schon vor 5 Jahren geschrieben habe und diese Software seit dem auch im Einsatz ist. Hier mal ein Bild zur Veranschaulichung, was der Client Darstellt und gespeichert werden soll.

http://www.bilder-hochladen.net/files/fyn0-1-png.html

Damals vor 5 Jahren sind es 9 Berechnungsingenieure, 4 Berechnungsserver und 2 FE-Solvern gewesen. Was da fehlt ist die mittlere Schicht die ich einfügen will, um die Berechnungsserver zu entlasten, da es vorkommen kann, das 15 Berechnungsingenieuren gleichzeitig die Daten von einem Server abfragen, was sehr viel Last für den Server bedeutet.

Außerdem fehlt noch das eigentliche queuing-system wofür die mittlere Schicht auf jeden Fall erforderlich ist. Momentan ist es eine Art Remot-Task-Manager und Job Überwachung für die Berechner die dann manuell entscheiden wo der Job dann ausgeführt wird.

[hwoess]

Diese Aufgabenstellung hört sich sehr interessant an. Habe weder mit Linux noch Java etwas am Hut und kann daher keine Tipps dazu geben, aber bezüglich SQL-Sever würde ich mal mit einem Rechner mit einer SSD mit hohen I/O's (verwende selber eine Intel Postville 160 Gb), viel Hauptspeicher (hängt von eurem Datenvolumen ab) und einem möglichst schnellen Dualcore-Prozessor starten, denn ich habe schon Server gesehen, die hatten 4 langsame Quadcores drauf, aber diese waren nie ausgelastet, da aufgrund der vielen Table-Locks nur eine serielle Abarbeitung erfolgen konnte und die anderen Cores immer warten mussten. Und da ist dann die Geschwindigkeit eines einzelnen Cores wichtig.
Hardwaremäßig liesse sich weiters noch aufstocken durch zwei weitere SSD's, damit man Betriebssystem, Datenfiles und Logfile auf verschiedene Platten legen kann und ev. ein Motherboard mit zweitem Sockel für einen weiteren schnellen Dualcore.

Ist aber jetzt nur subjektiv aus meinen bisherigen Erlebnissen. Was aber gewiß ist: stimmt der Tabellenaufbau nicht, werden wichtige Indizes nicht angelegt oder Statistiken nicht gewartet und sind die SQL-Statements falls geschrieben, kann man damit auch die mächtigste Hardware in die Knie zwingen. Auf die optimale Programmierung ist also das Hauptaugenmerk zu legen - aber das ist ja sicher eh klar

bye,
Helmut

PS: mit dem Intervall lässt sich sicher auch etwas steuern - statt in jeder Sekunde nur alle zwei Sekunden updaten und man braucht nur mehr halb so viel Leistung und der Benutzer kommt damit vielleicht auch völlig aus. Würde mal mit einem 5-Sekunden-Takt starten und dann immer kürzer werden...

[alexdgg]

PS: mit dem Intervall lässt sich sicher auch etwas steuern - statt in jeder Sekunde nur alle zwei Sekunden updaten und man braucht nur mehr halb so viel Leistung und der Benutzer kommt damit vielleicht auch völlig aus. Würde mal mit einem 5-Sekunden-Takt starten und dann immer kürzer werden...

Naja… mit dem Intervall ist das so eine Sache. Die Berechner brauche ein Werkzeug um zu entscheiden, ob eine Spannungsanalyse (kann bis zu 5 Tagen rechnen) bei den Iterationen divergiert und ein infinites Iterationsverhalten zu erwarten ist. Wenn das der Fall ist, müssen diese den Job natürlich canceln. Diese Entscheidung ergibt sich auf dem Iterationslog und dem Verhalten von CPUs und vom RAM Also 2 Sekunden wäre das absolute Minimum. Wünschenswert ist auf jeden Fall eine Sekunde.

Mit der Hardwarekeule wollte ich auch erstmal nicht zuhauen. Ich suche erstmal eine Architektur, die auch die nächsten 5, 6 oder 7 Jahre (auch mit wachsender Anzahl von Nutzern und Servern) die zentrale Verteilung der Daten bewerkstelligen kann. RMI ist sicher eine Option, aber Vektoren, Arrays oder Listen lassen sich halt nicht so komfortabel sortieren, gruppieren, filtern oder kombinieren wie SQL Tabellen.

[dimitri]

Hi,

also die Datenmenge an sich ist eigentlich nicht sonderlich hoch, an der Stelle solltest Du keine Probleme haben.

Dein Problem wird eher darin liegen, dass Du etwas falsch machst, weil Du die Datenbank nicht genau kennst. Jede DB hat ihre Besonderheiten, die man kennen und nutzen muss um die optimale Performance zu bekommen. Mach nicht den Fehler vieler Entwickler, die die DB als einfachen Speicher sehen, dem es egal ist wie die Daten rein kommen und gelesen werden.

Daher solltest Du Dich genau über die DB informieren, idealerweise einige Schulungen besuchen und dich von dort ausgehend weiterbilden. Des weiteren gibt es bei jeder Datenbank eine Handvoll Choryphäen, die man in Erfahrung bringen und sich deren Bücher kaufen (und lesen) sollte.
Allerdings gibt es auch einige, die meinen sie seien Choryphäen da muss man aufpassen.

Ein guter Ablaufpunkt wäre z.B. apress.com

Dim

[alexdgg]

Hallo Dimitri,

danke für Deine Antwort! Kenne mich eigentlich schon gut mit MS-SQL aus. Finde trotzdem, dass es schon eine Art Missbrauch ist, den SQL-Server als mittlere Schicht einzusetzen.

Habe mich eigentlich schon von dem Gedanken verabschiedet den SQL als aktive Schicht einzusetzen.

Ich habe einen Test mit zwei RMI Implementierungen (Client/MiddleTier und MiddleTier/Server) die auf dem MiddleTier zusammenlaufen gemacht bei dem das MiddleTier als aktiver Proxy läuft und die Daten über Serializierte Objekte zwischen den Endpunkten cacht und verteilt. Dies funktioniert überaus gut. Habe den Test mit 15 Servern und 110 Clients gemacht und es war weder viel CPU Last noch sehr viel Netzwerklast (da ich die Daten inkrementell Synchronisiere). Den SQL nehme ich nur noch zum Speichern der statistischen Daten und der Queuing Daten. Ich denke, dass das so Zukunftssicherer ist.