Virtuelle Interfaces im LAN

Performance-Killer im Netzwerk, Teil 2



Bodo Wolter schreibt als Experte zum Thema System- und Netzwerk-Analyse in Computer-Netzwerken. Mit einem Erfahrungsschatz von über elf Jahren bewertet und optimiert er mit seinen Empfehlungen als unabhängiger, freiberuflicher Analyst, Troubleshooter und Trainer die Kommunikationsabläufe in größeren Netzwerk-Umgebungen.
Im ersten Teil der Serie "Performance-Killer im Netzwerk" ging es um Fehler in den allgemeinen Einstellungen. Teil 2 behandelt die Port- und Interface-Einstellungen im Netzwerk.

Bandbreitenengpässe im Netzwerk können viele Ursachen haben (wir berichteten), unter anderem können auch Virtuelle Interfaces zu einem Mismatch im Netzwerk führen.

Virtuelle Interfaces können für sehr reale Probleme im LAN sorgen

Wenn Netzwerkkarten ein Teaming bilden, Maschinen in einem Cluster betrieben werden oder es um die virtuellen Adapter in VmWare-, Hyper-V- oder XEN-Umgebung geht, kann die Performance schnell auf der Strecke bleiben.

Switch-Port- und Interface-Einstellungen passen nicht zueinander

Die Ursache dafür ist rein menschlicher Natur, wenn die Kollegen der Abteilungen "Netzwerk" und "Systeme" nicht ausreichend über den zu realisierenden Anschluss und die einzusetzenden Konfigurationsparameter kommunizieren. Dann liegt an dieser Stelle mit hoher Wahrscheinlichkeit ein "Mismatch" vor, der zu einer gravierend herabgesetzten Performance der beteiligten Systeme führen kann.

Viel öfter kommt es dagegen in der Praxis dagegen vor, dass sich die passenden Einstellungen auf beiden Seiten nicht eindeutig identifizieren lassen, weil

  • der gewünschte, gleiche Modus herstellerbedingt nicht zueinander passt

  • sich die Komponenten nicht genau genug einstellen lassen oder Einstellungsmöglichkeiten fehlen

  • wieder einmal Zeitdruck bestand.

Virtuell im LAN
Virtuell im LAN
Foto: ra2 studio - Fotolia.com

Es mag noch weitere Gründe geben, warum sich später im Betrieb ein unbefriedigender Zustand einstellen kann. Validieren Sie die Qualität der Einstellungen durch einen Praxistest. Das gilt auch für den Datendurchsatz zwischen virtualisierten Servern.

Verifizieren Sie den Datendurchsatz

Überprüfen Sie in jedem Fall die Anbindung zeitnah und praktisch auf ihre Tauglichkeit, bevor Sie das System produktiv verwenden. Unter Windows eignet sich dazu zum Beispiel das Command Line Tool "iperf", das im Download von jperf im Ordner "bin" enthalten ist. Damit sollten Sie den Datendurchsatz zwischen einem Client und dem angeschlossenen Server in beide Richtungen testen. Die erreichten Datendurchsätze sollten entsprechend dem Anschluss realistisch und in beiden Richtungen etwa gleich gut sein. Starke Abweichungen weisen auf einen "Mismatch" in der Konfiguration hin.

Untersuchung durch Paketdatennahmen

Es kann zusätzlich sinnvoll sein den Traffic der beteiligten Systeme mitzuschneiden und auszuwerten. Eine kurze Anleitung dazu finden Sie hier. Das Command Line Capture ist dabei zu bevorzugen, da das mitschneidende System geringer belastet wird.

Systematische Paketverdoppelungen

Wenn Sie dabei auf Layer-2 Probleme stoßen, können Sie davon ausgehen, dass sich das in die darüber liegenden Layer fortpflanzt und für eine schlechte Performance sorgt. Ein Beispiel zu systematischen Paketverdoppelungen finden Sie unter Paket-Analyse. Der nutzbare Datendurchsatz sinkt dabei auf unter die Hälfte des Möglichen.

Multicast-MAC Adressen

Viele Konstrukte verwenden Multicast-MAC Adressen um sich als einheitliches System mit einem Interface im Netzwerk darzustellen. Das gilt zum Beispiel für ein Server Clustering. Kein Switch merkt sich Broadcast- oder Multicast-Adressen, sofern das nicht konfiguriert ist. Das führt dann dazu, dass die Kommunikation vom Server zum Client von Switch-Port zu Switch-Port verläuft, die Kommunikation vom Client zum Server allerdings über alle aktiven Ports der Switch Umgebung geflutet wird, da die Multicast MAC Adresse nicht lokalisierbar ist.

Ein sicheres Anzeichen dafür ist, wenn die Aufnahme weiterer Clusterknoten allen Erwartungen entgegen zu einer schlechteren Gesamt Performance führt. Validieren können Sie das mit einer Broadcast- / Multicast-Paketdatennahme. Was hier auf jeden Fall nicht zu sehen sein darf ist TCP-Traffic.

Die Zeit der Mismatches ist nicht vorbei

Gerade in größeren Umgebungen trifft man historisch gewachsen bezüglich der eingesetzten Hard- und Soft-Ware oft auf eine erstaunliche Vielfalt. Schon allein aufgrund der unterschiedlichen Entwicklungsstände ist nicht anzunehmen, dass hier immer Alles optimal zusammen passt. Ein aktuelleres Beispiel, dass das auch für Software gilt, finden Sie unter hier. Klemmen kann es an vielen Stellen im Netzwerk. Dagegen helfen nur beständige Qualtitätsprozesse. (rw)

Zur Startseite