Verlässlichkeit auf Graphen
Wie im letzten Blogpost zu sehen ist ([1]), entstehen bei dem Netzwerksniffer Graphen. Beim eigentlichen Projekt soll es darum gehen diese Graphen auszuwerten und Verlässlichkeitsaussagen zu generieren. Dazu müsste ich mich erstmal auf eine Art von Graph beschränken.
Topologiegraph Zunächst ist es möglich aus den Aufzeichnungen herauszulesen, welche Verbindungen wie oft Offline waren. Das könnte bspw. passieren, wenn ein Netzwerkgerät überlastet ist oder wenn der Computer überlastet ist. Es ist also möglich aus der Information, dass PC A eine Nachricht versendet worden ist, aber am PC B nicht angekommen ist, anzunehmen, dass die Verbindung für den Moment down ist / war. Aus der Anzahl, wie viele Nachrichten nicht angekommen ist, kann eine Verlässlichkeit der Verbindung berechnet werden. Davon ausgehend kann berechnet werden, wie hoch die Wahrscheinlichkeit ist, dass ein Knoten komplett von den anderen getrennt ist. (siehe [2])
Antwortzeiten Die Zeit, die ein Server benötigt um eine Anfrage zu bearbeiten (hier die Zeit zwischen Erhalten der Anfrage und Versenden der Antwort) wird als Antwortzeit bezeichnet. Nehmen wir an, dass jede Anfrage beantwortet wird (nicht nur mit einem ACK), dann können wir aus der Differenz zwischen dem Empfangsereignis und dem Sendeereignis die Antwortzeit berechnen und entsprechend an die Kante zwischen A und B eintragen. Aus einem solchen Graphen könnte man versuchen Abhängigkeiten zwischen den Services zu erkennen. Das funktioniert allerdings nur dann, wenn wir eine nur die aktuellsten Nachrichten auswerten, dh. die Auswertung sollte zyklisch in kurzen Abständen passieren. Es ist möglich, dass später durch eine andere Anfrage ein Kreis komplettiert wird, das darf natürlich nicht mit reinspielen. Aus dem Graph kann man aber auch ablesen, wo bei einer Anfrage die meiste Zeit verloren geht. Nicht beachtet werden hier Netzwerkübertragungszeiten, sondern lediglich Antwortzeiten / Rechenzeiten der Computer.
Abhängigkeiten Aus den Nachrichten direkt könnten Abhängigkeiten zwischen Services erkannt werden. Dh. wird eine Nachricht von A nach B versendet, nehmen wir an, dass eine Abhängigkeit von A nach B herrscht. Dh. A ist von B abhängig, oder anders ausgedrückt, wenn B down ist, kann auch A seine Aufgabe nicht mehr (oder nicht mehr vollständig) erfüllen. Dazu müssen wir annehmen, dass jede Nachricht, die versendet ist, für den eigentlichen Zweck des Systems unerlässlich ist. Aus den aufgezeichneten Daten, lässt sich nicht schlussfolgern, ob Nachrichten eventuell auch wegfallen könnten, ohne dabei zu riskieren, dass das System ausfallen könnte. Aus Abhängigkeiten könnten, wie oben beschrieben, Fault-Trees erstellt werden. Es bleibt zu überlegen, was passiert, wenn Kreise entstehen.
Das sind nur die Möglichkeiten, die mir eingefallen sind, bzw. durch die Lektüre von [2] in den Kopf gekommen sind. Es geht bei dem Projekt nicht darum, Basisnachrichten zu verändern. Wäre es bspw. Möglich einen X-Trace-Header [3] in die Nachrichten beim Versenden einzubauen (versehen mit einer im gesamten System eindeutigen ID), könnte man den Weg dieser Nachricht beobachten und daraus Schlussfolgerungen über das Verhalten des Systems ziehen. Das ist in diesem Projekt aber nicht möglich.
[1] https://www.stefannaumann.de/informatik/tcp-aufzeichnung-testlauf.html [2] "A Recursive Algorithm for Directed-Graph Reliability" von J.A. Buzacott [3] "X-Trace: A Persvasive Network Tracing Framework" von R. Fonseca, G. Porter, R.H. Katz, S.Shenker und I.Stoica.
Letzte Bearbeitung: 29.06.2015 10:30