Netzwerk-Performance-Analyse: Grundlagen
Netzwerk-Performance ist ein weites Feld, das nicht immer intuitiv ist. Insbesondere die Interaktion von unterschiedlicher Hardware, Software und Protokollen kann die Suche nach der Ursache von Performance-Problemen schnell zur Suche nach der Nadel im Heuhaufen machen.
Etwas Grundlagenwissen kann helfen, das Suchgebiet zu verkleinern, so dass man schneller zu den wichtigen Details vordringen kann.
Grundsätzlich muss ich bei der Analyse von Rechnernetzwerken drei Dinge beachten, die die Performance beeinflussen:
Physikalische Grenzen legen den oberen Grenzwert fest, der nicht überschritten werden kann.
Strukturelle Einflüsse kommen aus der Netzwerk-Architektur und können dafür sorgen, dass ein Netzwerk nicht in vollem Umfang für einen Nutzer zur Verfügung steht.
Störungen schaden der Performance des Netzwerks unmittelbar und in größeren Ausmaß als strukturelle Einflüsse.
Obwohl die Suche nach den Ursachen von Störungen vermutlich den größten Teil bei der Performance-Analyse ausmacht, ist es wichtig, sich zumindest ein Bild von den durch die Physik und die Struktur des Netzwerks bestimmten Grenzen zu machen, um einschätzen zu können, ob überhaupt eine Störung vorliegt.
Physikalische Grenzen
Es gibt zwei Kennzahlen, die ich bei der Betrachtung der Performance eines Netzwerks betrachten muss.
Die Bandbreite sagt aus, welche Datenmenge in einem bestimmten Zeitraum über ein Medium übertragen werden kann.
Die Latenz oder Verzögerungszeit gibt die Dauer an, bis ein vom Sender abgeschicktes Signal beim Empfänger ankommt.
Dabei gilt, dass die Zeit für die vollständige Übertragung einer Nachricht - also eines Datagramms - sich zusammensetzt aus der Latenz und dem Quotient aus der Länge der Nachricht geteilt durch die Bandbreite.
Die Latenz in einem Medium wird nach oben durch die Lichtgeschwindigkeit beziehungsweise die Ausbreitungsgeschwindigkeit elektromagnetischer Wellen begrenzt. Diese beträgt im Vakuum 300.000 Kilometer pro Sekunde (km/s), in Kupfer noch 230.000 km/s und in Glasfasern noch 200.000 km/s. Da für längere Strecken sehr oft Glasfaser eingesetzt wird, kann ich bei Schätzungen deren Wert für WAN-Netze einsetzen. Für die etwa 600 km von Hamburg nach München kommt da eine Latenz von mindestens 3 ms zustande. Um ein Signal einmal in Glasfaser um die die Erde zu senden, muss ich mit 200 ms rechnen.
Die physikalischen Grenzen gelten für jeweils ein Segment eines Netzwerks. Betrachte ich ein Netzwerk aus mehreren Segmenten, so ist die Gesamtbandbreite nicht größer als die kleinste Bandbreite aller beteiligten Segmente und Netzwerkknoten. Netzwerkknoten sind Switche, Gateways, Router oder Firewalls, die die Segmente miteinander verbinden. Die Segmente selbst hingegen werden Kanten genannt.
Die Latenz der Gesamtstrecke ist gleich der Summe der Latenzen auf allen Segmenten zuzüglich der Summe aller Verzögerungen auf den beteiligten Netzwerkknoten. In der Praxis wird statt mit der Latenz oft mit der Paketumlaufzeit (Round-Trip-Time, RTT) gearbeitet, die der zweifachen Latenz plus der Bearbeitungszeit am entfernten Knoten entspricht. Bei ICMP, wie zum Beispiel Ping, kann die Bearbeitungszeit meist vernachlässigt werden, weil die Antwort direkt vom Betriebssystem gesendet wird.
Sowohl Bandbreite als auch Latenz lassen sich experimentell zumindest näherungsweise mit den Bordmitteln nahezu jeden Rechners bestimmen.
Strukturelle Einflüsse
Es gibt mehrere strukturelle Eigenheiten, die sich auf die Performance eines Netzwerks oder einer Netzwerkverbindung auswirken:
Medien, die empfindlich gegenüber Störeinflüssen sind, können auf Grund unvermeidbarer Störungen in ihrer Leistungsfähigkeit eingeschränkt sein.
Ein geteiltes Medium bietet einem einzelnen Nutzer gegenüber einem exklusiven Medium weniger Performance.
Die im Netzwerk verwendeten Protokolle können einen erheblichen Einfluss auf die Performance der Datenübertragung ausüben.
Funkverbindungen, wie WLAN oder Richtfunk, aber auch optische Verbindungen, die direkt durch die Luft anstelle über ein LWL-Kabel laufen, sind Beispiele für Medien, die empfindlich gegenüber Störeinflüssen sind.
Geteilte Medien haben, schon aufgrund der Tatsache, dass das Medium mit anderen Nutzern geteilt wird, eine geringere Performance weil die Gesamtbandbreite des Mediums nicht größer wird wenn es mehrere Nutzer verwenden.
Beispiele für geteilte Medien sind WLAN, 10Base2-Netze oder Ethernet mit Hubs. Aber auch einen Switch, der wegen Überlaufs der MAC-Adresstabelle Datagramme an allen Anschlüssen sendet kann man als geteiltes Medium betrachten.
Der Einfluss der Protokolle auf die Performance eines Netzwerks wird deutlich, wenn man zum Beispiel die Protokolle UDP und TCP vergleicht.
Eine UDP-Verbindung ist ungeregelt und gibt keine Garantie, dass die Datagramme ankommen. Damit ist es möglich, Datagramme mit der Geschwindigkeit der Schnittstelle zu senden. Wenn über die gesamte Strecke die gleiche Bandbreite zur Verfügung steht, werden die Daten mit voller Bandbreite vom Sender zum Empfänger übertragen, wobei das eine oder andere Datagramm vielleicht verloren geht.
TCP hingegen ist ein geregeltes Protokoll, das Garantien bezüglich der Vollständigkeit und der Reihenfolge der übertragenen Daten gibt. Dafür ist es auf regelmäßige Rückmeldung vom Peer angewiesen, um verlorene Datagramme rechtzeitig erneut zu senden. Die Ankunft dieser Rückmeldungen vom Peer ist aber von der RTT abhängig. Bei einem Netz mit großer RTT wartet der Sender nach einer Anzahl gesendeter Datagramme auf die Bestätigung durch den Peer bevor er weitere Datagramme sendet. Durch diese Wartezeit kann ein Endpunkt mit einer TCP-Verbindung eine Leitung nicht vollständig auslasten und erreicht eine niedrigere Bandbreite, auch wenn das Netzwerk mehr erlauben würde.
Der Sender könnte die Leitung besser ausfüllen, wenn er mehr Datagramme senden würde, bevor er auf eine Bestätigung wartet. Die Menge an Daten, die ein Endpunkt mit TCP ohne Bestätigung sendet, hängt vom TCP-Parameter Receive-Window ab. Das ist die Anzahl Bytes (Oktetts), die der Empfänger zu empfangen bereit ist. Das heißt, der Empfänger steuert damit wie viele Daten der Sender ohne Bestätigung sendet. Das Receive-Window kann mit jedem einzelnen Bestätigungsdatagramm variiert werden. In der Praxis bleibt dieser Wert sehr oft fest bei 64 kByte.
Mit einem Receive-Window von 64 KByte sind folgende Bandbreiten bei einer einzelnen TCP-Verbindung erreichbar:
- Bei einer RTT von 1 ms: etwa 500 Mbit/s
- Bei einer RTT von 10 ms: etwa 50 Mbit/s
- Bei einer RTT von 100 ms: etwa 5 Mbit/s
Das bedeutet, wenn die Performance einer einzelnen TCP-Verbindung in dieser Größenordnung liegt, brauche ich nicht nach Netzwerkproblemen zu suchen, auch wenn die verfügbare Bandbreite sehr viel höher sein sollte als die erreichte Bandbreite. In diesem Fall hilft nur ein Peformance-Tuning an den Endgeräten.
Störungen
Nachdem ich mich überzeugt habe, dass die Performance einer Netzverbindung wesentlich unter der physikalisch möglichen liegt und auch nicht durch strukturelle Eigenheiten des Netzes oder der Protokolle erklärt werden kann, stufe ich das Problem als Störung ein und mache mich auf die Suche nach möglichen Ursachen.
Dabei kann mir die USE-Methode von Brendan Gregg helfen. Bei dieser Methode kontrolliere ich einige wenige Systemparameter an allen in Frage kommenden Stellen. Die in Frage kommenden Stellen sind hier alle Netzwerkknoten und -kanten zwischen Sender und Empfänger.
Die interessanten Parameter sind hierbei:
- Usage, die Auslastung
- Saturation, die Sättigung
- Errors, Fehler
Die Auslastung gibt bei einer Netzwerk-Komponente an, wie viel von der maximal möglichen Bandbreite gerade benutzt wird. Da die Auslastung im Monitoring meist über einen größeren Zeitraum, etwa eine Minute, gemittelt wird, kann innerhalb dieses Zeitraums auch kurzzeitig eine Sättigung eintreten. Diese wird durch die Warteschlangenpuffer der Netzwerkknoten kompensiert.
Bei einer voll ausgelasteten Netzwerk-Komponente gibt die Sättigung an, wieviele Datagramme oder Bytes in einer Warteschlange auf den Versand warten. Läuft ein Netzwerkabschnitt oder ein Knoten längere Zeit in der Sättigung, wird die Anzahl der Datagramme in der Sendewarteschlange im Laufe der Zeit meist größer, bis Datagramme verworfen werden. Im Netzwerk tritt eine Sättigung eines Abschnitts häufig auf, wenn Daten auf einer oder mehreren schnellen Datenleitungen an einem Knoten ankommen und durch eine Leitung mit geringerer Kapazität weitergeleitet werden.
Fehler kann ich als Zählerwert so wie die Auslastung oder Sättigung bekommen oder als Text aus den Logs. Die Zählerwerte lassen sich schneller interpretieren, die Lognachrichten können einen Hinweis auf die Ursache enthalten.
Damit habe ich die Grundlagen. Für eine erfolgreiche Fehlersuche bei Performance-Problemen muss ich jedoch in die Details gehen: Details der verwendeten Netzwerk-Architektur, der Hardware, der Protokolle und der verwendeten Software.
Posted 2021-01-26