Ist das Netzwerk wirklich schuld?
Ist das Netzwerk wirklich schuld?
„Wir haben Probleme – das Netzwerk ist schuld.“ Diese Aussage ist wahrscheinlich jedem Consultant bekannt. Was aber, wenn das Netzwerk Pakete zuverlässig und ohne Verzögerung übermittelt und trotzdem Probleme bestehen? Wir führen verschiedene Ansätze aus realen Analysen auf, um einen Einblick in die Vorgehensweise der Problembehebung zu geben, nachdem ein Fehler im Netzwerk ausgeschlossen werden konnte.
Werden Probleme gemeldet, ist es zunächst erforderlich, eine genaue Beschreibung des Fehlerbildes anzufertigen. Im folgenden Fall wurden Dateien innerhalb einer Anwendung geöffnet. An den Außenstandorten benötigte dieser Prozess selbst für eine wenige Megabyte große Datei mehrere Minuten.
Durch verschiedene Tests ist zunächst zu prüfen, ob die Ursache des Problems durch Paketverlust, Latenz oder eine hohe Auslastung der Verbindung hervorgerufen wurde. Mithilfe von „manuellen“ Dateitransfer via Explorer und IPerf Bandbreitentests wurde validiert, dass die Ursache nicht im Netzwerk zu finden ist.
Der gezeigte Dateitransfer via MPLS und SMB auf einer 100 Mbit/s Strecke umfasst 535.470 Pakete und davon nur zwei Retransmissions. Somit weist dieser Transfer keine Fehler auf und ist ohne Befund hinsichtlich Window Size, Paketverlust oder Bandbreite.
Betrachtung der Anwendung und Protokolle
Daher ist es nun erforderlich, die Anwendung genauer zu betrachten. Im nächsten Schritt müssen wir uns die Vorgänge des Benutzers dokumentieren. Ebenfalls zu ermitteln sind die durch die Anwendung verwendeten Netzwerkprotokolle und, ob eine Verschlüsselung der Kommunikation stattfand.
Mit diesen Informationen haben wir das Öffnen einer 6MB großen Datei über die Anwendung in Form eines PCAPs aufgezeichnet.
Betrachtung der Anwendung und Protokolle
Daher ist es nun erforderlich, die Anwendung genauer zu betrachten. Im nächsten Schritt müssen wir uns die Vorgänge des Benutzers dokumentieren. Ebenfalls zu ermitteln sind die durch die Anwendung verwendeten Netzwerkprotokolle und, ob eine Verschlüsselung der Kommunikation stattfand.
Mit diesen Informationen haben wir das Öffnen einer 6MB großen Datei über die Anwendung in Form eines PCAPs aufgezeichnet.
Dabei wurde zunächst ersichtlich, dass die verfügbare Bandbreite der WAN-Verbindung nicht ausgenutzt wurde und der gesamte Vorgang insgesamt vier Minuten dauert. Auch dieser Test weist keine Fehler hinsichtlich der Punkte Window Size, Paketverlust und Bandbreite auf.
Somit ist bewiesen, dass sowohl das Netzwerk performant und zuverlässig Pakete übermittelt als auch Client und Server generell ausreichend dimensioniert sind und die Hardware selbst keinen Flaschenhals darstellt. An diesem Punkt kann es sinnvoll sein, die Entwickler der Anwendung in die Analyse des Problems zu involvieren.
In unserem Fall haben wir dies getan und das Problem sowie bereits durchgeführte Analyseschritte geschildert. Aus logischer Sicht haben wir die Ursache bei der Anwendung bereits vermutet, doch leider fehlten uns technische Beweise, um unsere Annahme zu untermauern.
Gegenstand der Analyse ist nun der Payload, den die Anwendung selbst generiert. Die Betrachtung ist zeitintensiv, da eventuell neue Protokolle und Variationen davon durch den analysierenden Techniker erlernt oder hergeleitet werden müssen, um zu verstehen, welche Daten oder Signale Client und Server miteinander austauschen und wie diese zu interpretieren sind.
Diesem Prozess sind wir gefolgt und haben uns mit dem Payload vertraut gemacht. So konnten wir beim Öffnen einer Datei in der Clientanwendung nachweisen, dass Client- und Serveranwendung mehrere Tausend Anfragen an das Dateisystem miteinander austauscht, bevor die entsprechende Datei an den Client übermittelt wird. Die Anfragen haben wir nun aus dem PCAP extrahiert und zu Papier gebracht, da wir nun davon ausgehen konnten, dass dies der Grund des langen Vorgangs war.
Nicht immer ist die Anwendung schuld
Wenn durch Tests festgestellt wurde, dass Pakete zuverlässig übermittelt werden, bedeutet dies natürlich nicht automatisch, dass die Anwendung Ursache des Problems ist. Weitere involvierte Protokolle oder veraltete Hardware auf Client- oder Serverseite können ebenfalls Grund des Problems sein.
Bevor Clients eine Verbindung zu einem Server aufbauen, wird häufig zunächst der Host- oder Domainname aufgelöst. Kommt es dort zu Verzögerungen, hat das Auswirkungen auf den gesamten Vorgang. (Sie finden zu diesem Thema auch einen interessanten Blogbeitrag mit dem Titel: DNS – oder auch: warum geht mein Internet nicht)
Performanceprobleme der Client- und Serverhardware können recht schnell über TCP Zero Windows ermittelt werden. Läuft der für eine Verbindung reservierte Empfangspuffer voll, wird dies dem entsprechenden Verbindungspartner über ein TCP Zero Windows signalisiert. Der sendende Partner schickt dann keine Daten mehr. Der Empfangspuffer läuft voll, da der Prozess nicht schnell genug mit dem Abholen der Daten hinterherkommt. Dies kann zum Beispiel durch einen Dateitransfer auf eine langsame mechanische Festplatte versursacht werden.
Handlungsempfehlung
Die primäre Handlungsempfehlung besteht darin, zu prüfen, ob eine Notwendigkeit besteht, mehrere Tausend Zugriffe auf das Dateisystem durchzuführen. Ist hierdurch eine Reduzierung der Zugriffe möglich, so kann die Performance damit schon verbessert werden.
Eines der Hauptprobleme im WAN ist neben der Bandbreite, die Latenz. Gerade bei „gesprächigen“ Protokollen oder Anwendungen führt dies zu einem deutlichen Performance-Verlust. Eine weitere Empfehlung wäre daher der Aufbau von WAN-Optimierungsgeräten, um die Latenz und Bandbreite zu verbessern. Der Vorteil dieser Lösung besteht zum Beispiel darin, dass nur noch geänderte Bit-Muster übertragen werden müssen. Dies führt nicht nur zu einer deutlichen Einsparung der Bandbreite, sondern auch zu einer verbesserten TCP-Übermittlung. Beide Faktoren zusammen wirken sich positiv auf die Latenz und Bandbreite aus und somit auf die gesamte Datenverbindung. Hierzu haben wir zum Beispiel bereits sehr gute Erfahrungen mit dem Technologiepartner Riverbed sammeln können. Gerne unterstützen wir Sie bei einem möglichen Testaufbau.
Fazit
Nicht bei jeder problematischen Interaktion, die über das Netzwerk abgewickelt wird, ist auch das Netzwerk schuld. Die Ursachen können vielschichtiger sein und bei anderen beteiligten Komponenten liegen. Mithilfe der Schritt-für-Schritt-Betrachtung können einzelne Fehler-Komponenten ausgeschlossen werden.
Benötigen Sie Hilfe bei der Analyse ähnlicher Fehlerbilder? Dann kontaktieren Sie uns gerne.