Last-Messungen in Daten-Netzen sind einerseits leicht und schnell zu erstellen (da nur Statistik), andererseits sehr schwer zu deuten und zu validieren.
Einfache Fragen:
Ist die Netzwerk-Last, die statistisch erfasst wird, denn überhaupt zulässig?
Sind Teile der Netzwerk-Last unzulässig, etwa dadurch, dass Clients ständig in Endlos-Schleifen die selben Abfragen an die Server richten?
Ist Netzwerk-Last künstlich erzeugt durch Fehler im Routing-Design, etwa derart, dass Daten-Pakete vermeidbar über Strecken geschickt werden, die für diesen Verkehr gar nicht gedacht waren/sind?
etc, etc, ...
Das Bestätigen von Gültigkeit (Validieren) im Nachgang von Last-Messungen ist nur dann möglich, wenn zugleich auch eine genaue inhaltliche Untersuchung der Messdaten stattfindet.
Oft wird das Wort "Bandbreiten-Messung" verwendet. Abgesehen davon, dass häufig Bandbreite mit Bit-Rate bzw. Durchsatz verwechselt wird, wäre es gleichbedeutend mit "Last-Messung".
Ein Unternehmen will das Rechenzentrum (RZ) des Standorts A auflösen und nach dem zentralen Standort Z verlagern.
Die Folge ist, dass die Clients von Standort A über WAN-Leitungen auf die verlagerten Server in Standort Z werden zugreifen müssen.
Frage nun: Werden die WAN-Leitungen ausreichend Volumen je Sekunde übertragen können? Reicht die Kapazität?
Die Herausforderung im aktuellen Fall: Es reicht nicht, den Datenverkehr vor den Servern, die verlagert werden sollen, zu messen und statistisch aufzubereiten. Denn im RZ von Standort A laufen auch die Client-Zugriffe der Standorte B,C,D,E auf - die künftig ebenfalls direkt mit Standort Z verbunden werden sollen. Da die Aufgabenstellung aber lautet, nur den vorhersehbaren WAN-Traffic von Standort A nach Standort Z zu erfassen bzw. vorher zu sagen, müssen die Daten-Dialoge der Standorte B,C,D,E heraus gerechnet werden.
Nun könnten normalerweise Stastistiken angefertigt werden mittels LAN-Analyzer, die an den Server-Switches via Mirror Port den Datenverkehr der Server mitlesen und über einen Paket-Filter bzw. Adress-Filter die IP-Pakete der Standorte B,C,D,E ausgrenzen bzw. übergehen.
Nicht so im aktuellen Fall: Die Server sind in einer topographisch sehr verteilten Umgebung angeschlossen; die messtechnische Erfassung über LAN-Analyzer würde erhebliche Probleme aufwerfen. Erschwert würde eine "klassische" Herangehensweise zudem, da alle Server mit Adapter Teaming arbeiten, wobei jeweils beide "Beinchen" des LAN-Adapters "offen" sind und mit Load Balancing arbeiten - was besagt, dass es nur mit enormem Einsatz zusätzlicher Hardware möglich wäre, den dergestalt aufgespaltenen Server-Traffic messtechnisch wieder zu vereinigen, ohne den Datenverkehr durch den Eingriff zu beeinträchtigen (oder den Aufbau insgesamt zu verändern).
Also wird entschieden, auf den Unix-Servern (es handelt sich ausnahmslos um Unix-Server) den Daten-Verkehr mittels TcpDump intern aufzuzeichen; auf diese Weise wird auch der messtechnische Nachteil des Adapter Teamings umgangen, da die getrennten Rx/Tx-Ströme im Capture File wieder vereint auftreten würden.
Diese Herangehensweise verlangt jedoch, extreme Datenmengen im hohen GigaByte-Bereich automatisch und nachträglich auswerten zu können unter Einschluss von IP-Adress-Filtern, welche wahlweise die Auswertungen fokussieren auf die Pakete der IP-Subnetze der Standorte A,B,C,D oder E.
Es wurde mit TraceMagic gearbeitet und der HostMagic-Funktion "TrafficStats".
Die Statistiken bzw. Last-Profile von "TrafficStats" werden in verschiedenen Intervallen geführt:
Diese Aufteilung ist nötig, da es wegen eines logisch-physikalischen Problems (im Sinne der Aufgabenstellung) nur zu Näherungen führen kann, und zwar wie folgt:
Es können die Ergebnisse "pro 1 Sekunde" nicht 1:1 von LAN auf WAN übertragen werden.
Da die Paket-Laufzeiten und Quittungs-Zeiten zwingend via WAN etwas länger sind als im LAN (was sich im Laufe der Zeit zu spürbaren Verzögerungen im Applikations-Verlauf akkumuliert und folglich für den Anwender bemerkbar macht), verteilen sich Packet-Bursts via WAN etwas mehr über die Zeit, während sie im LAN sehr gedrängt verlaufen (also zeitlich schneller, kürzer).
Heißt: Alle Dialoge verteilen sich via WAN etwas mehr über die Zeit. Daher sind Statistiken "pro 15 Sekunden" etc als Vorhersage künftiger Last-Profile im WAN wesentlich näher am Ergebnis als Statistiken "pro 1 Sekunde", sind also besser übertragbar.
Allgemein sind bei solchen Studien nicht nur die Volumen-Nachweise für bestimmte IP-Subnetze (bzw. das Campus-Netz, ohne Niederlassungen) gewünscht, sondern auch den Einzel-Nachweis je IP-Adresse.
Diese Statistiken können mittels TraceMagic ebenfalls erzeugt werden über die HostMagic-Funktionen "SingleHosts" und "HostPairs".
SingleHosts -> Einzel-Nachweis für IP-Hosts
HostPairs -> Paar-Matrix für Hosts und Subnetze
Damit verbunden ist i.d.R. zugleich auch eine Auswertung der Namensdienste und Adress-Auflösungen.
.(graph).jpg)
.(graph).(2).jpg)
.(table).jpg)
