VERANSTALTUNGEN

Panda Security: IT Security Breakfast
26.10.18 - 26.10.18
In Spanischen Botschaft in Berlin

Transformation World 2018
07.11.18 - 08.11.18
In Print Media Academy, Heidelberg

DIGITAL FUTUREcongress
08.11.18 - 08.11.18
In Congress Center Essen

Data Driven Business Konferenz
13.11.18 - 14.11.18
In Berlin

OMX 2018
22.11.18 - 22.11.18
In Salzburg, Österreich

SERIE
Elefant

Um die in Teil 1 angesprochene, während der Pressekonferenz eingetretene, Verlangsamung nachzustellen, wurden die als ursächlich verantwortlich identifizierten Netzwerkstrecken durch konfigurative Anpassungen und geschickte Auswahl der Standorte der Lastgeneratoren und des Zielservers unter Last gesetzt. 

Die für die Störung verantwortliche Netzwerkstrecke sei in diesem Testaufbau die Verbindung zwischen zwei Breitbandroutern. Sie verbinden das Teilnetzwerk, in dem sich die Anwender befinden, mit dem Teilnetzwerk, in dem sich die Videostream-Server befinden. Da die Anwender bei ihrer täglichen Arbeit eine hohe Datenlast auf dieser Schnittstelle erzeugen, wurde auch in Bild 2 eine leistungsfähige Anbindung berücksichtigt. Im konkreten Testfall sorgen vier Glasfaserleitungen mit einem maximalen Datendurchsatz von jeweils 10 GBit/s für einen reibungslosen Datenaustausch. Voraussetzung für die simple Addition der Einzelleitung hin zum Gesamtdatendurch-satz dieser Anbindung ist eine gleichmäßige Verteilung der einzelnen Anfragen auf alle vier zur Verfügung stehenden Glasfaserlei-tungen. Die Systematik im aktuellen Fall lässt es nicht zu, die Kommunikation einer einzelnen Quelle auf mehrere Glasfaserleitungen aufzuteilen, daher werden mehrere Lastquellen verwendet, um den Datenstrom zu erzeugen.

Die Überwachung der Netzwerkparameter ergibt, dass die Übertragung der einzelnen Netzwerkpakete immer länger dauert, obwohl das theoretisch erwartete Limit von 40 GBit/s nicht vollständig ausgelastet ist. Diese Netzwerkstrecke soll daher gezielt und kontrolliert auf ihre Leistungsparameter hin überprüft werden.


Lesen Sie auch den anderen Beitrag der Serie „Netzwerktest mittels Lasttestwerkzeug:“:

Teil 1: Definierte Netzwerklast bewusst herbeiführen
Teil 2: Systematischer Testaufbau und Testdurchführung


 

Vereinfachte Routingstruktur innerhalb eines Netzwerkes unter Verwendung der Cisco-Darstellung. These materials have been reproduced by Sogeti Deutschland GmbH with the permission of Cisco Systems Inc. © CISCO SYSTEMS, INC. ALL RIGHTS RESERVED.

Bild 2: Vereinfachte Routingstruktur innerhalb eines Netzwerkes unter Verwendung der Cisco-Darstellung. These materials have been reproduced by Sogeti Deutschland GmbH with the permission of Cisco Systems Inc. © CISCO SYSTEMS, INC. ALL RIGHTS RESERVED.

Lasttransport

Die einzelnen Teilnetzwerke, die in der vorliegenden Situation betroffen sind, werden in Bild 2 auf die relevanten Teile „Anwenderlandschaft“ und „Serverlandschaft“ reduziert. Die Topologie und die damit verbundenen Routingmöglichkeiten werden in der Realität wesentlich komplexer sein und in jedem Fall eine detaillierte Analyse durch die Fachabteilung notwendig machen. Bedingung für einen verwertbaren Test ist es, wie im abstrakten Beispiel mit technischen Mitteln dafür zu sorgen, dass die von den Lastgeneratoren gesendeten Daten vollständig über die zu testende Netzwerkstrecke abgewickelt werden. Die Verwendung der in Bild 2 blau dargestellten Netzwerkstrecke würde das Testergebnis verfälschen.

An dieser Stelle sei nur grundlegend darauf hingewiesen, dass die Berücksichtigung der verfügbaren Netzwerkstrecken eine größere Herausforderung darstellt, als deren Deaktivierung. Der Netzwerkabteilung ste-hen hierfür Routingtabellen, physikalisches Trennen sowie die Nutzung von Firewalls zur Verfügung.

Lastziel

Essenziell für dieses Verfahren ist ein Lastziel (Server), welches beliebig häufig parallel und über variable Zeit hinweg auf die Anfrage eines Clients reagieren und diese beantworten kann. Bedingung ist es natürlich auch, dass dieses System die Anfragen so schnell beantwortet, dass der gewünschte Gesamtdatendurchsatz erreicht wird. Ein Webserver, dessen primäre Aufgabe es ist, Webseiten zu liefern, wird so eingerichtet, dass er ein zuvor definiertes Bild an den Anfragenden zurücksendet.

Die Arbeitslast kann mittels Loadbalancing-Technologie auf mehrere Webserver aufgeteilt werden, sodass das „Lastziel“ theoretisch mehr Daten liefern könnte, als das Netzwerk physikalisch übertragen kann.
 

Beispielhaftes C-Skript für eine Netzwerkanfrage an einen Webserver. Erstellt mit HP Virtual User Generator (siehe [HPLR]).

Listing 1: Beispielhaftes C-Skript für eine Netzwerkanfrage an einen Webserver. Erstellt mit HP Virtual User Generator (siehe [HPLR]).

Lastquelle

Der Begriff „Lastquelle“ wird hierbei im übertragenen Sinn für den Client verwendet, der das vom „Lastziel“ angebotene Bild abruft. Hat dieses Bild eine definierte Größe und wird festgelegt, wie oft es parallel abgerufen wird, so kann einfach berechnet werden, wie viel Last auf der Schnittstelle zwischen den Netzwerken abgewickelt werden muss. Ein kleiner Aufschlag von 5 Prozent sollte für die Anfrage des Bildes selbst und Randeffekte mit eingerechnet werden. Dieser Wert dient aber nur für die grobe Konzeptionierung des Tests. Die Anzahl der virtuellen Anwender, beziehungsweise in Folge die erzeugte Gesamtlast, kann im Lasttesttool überwacht und gegebenenfalls durch den Start weiterer Instanzen der Lastgeneratoren nachgesteuert werden.

Die Infrastruktur der Lastgeneratoren und ihrer Randsysteme wurde im konkreten Fall mit Produkten aus dem HP Application Lifecycle Management erstellt. Es gibt am Markt jedoch einige Konkurrenzprodukte, die vergleichbare Anforderungen erfüllen. Listing 1 zeigt die Einfachheit eines für die-se Zwecke notwendigen Lasttestskriptes. 

Stagnierender Datendurchsatz trotz steigender Anzahl simulierter Benutzer.

Bild 3: Stagnierender Datendurchsatz trotz steigender Anzahl simulierter Benutzer.

Einbindung in den regulären Testprozess

Gerade dann, wenn wie im vorliegenden Fall bereits der Fehlerfall eingetreten ist, lässt sich dieses Verfahren natürlich nicht mehr in den regulären Testbetrieb einbinden, sondern muss in einer der wenigen Phasen von geringer Netzwerkauslastung durchgeführt werden. Die Risiken von Ausfällen in der Nacht oder an Wochenenden müssen individuell ermittelt und berücksichtigt werden.

Um dieser Zeitnot nicht ausgesetzt sein zu müssen, kann dieses Verfahren auch vorbeugend während eventuell bereits geplanter Wartungszeiträume innerhalb der Serverlandschaft durchgeführt werden.

Testdurchführung

Über die Steuerung des Lasttesttools kann ein Szenario erstellt werden, welches die Anzahl der User, die das in Listing 1 beschriebene Skript parallel ausführen, kontinuierlich erhöht. Es empfiehlt sich, die Anzahl bis zu einem unkritischen Niveau per Szenario zu regeln und dann gegebenenfalls während der Testlaufzeit manuell nachzusteuern. Der durch den Prozess erzeugte Gesamtdatendurchsatz wird von der Mehrheit der Lasttesttools in einem Livemonitor dargestellt. Parallel hierzu kann das Netzwerkteam die Monitore überwachen, die auch während der Pressekonferenz eine Verlangsamung des Paketdurchsatzes angezeigt haben.

Stagniert der Datendurchsatz trotz zunehmender Anzahl von simulierten Anwendern (siehe Bild 3), so wurde der aktuell angezeigte Wert als maximaler Datendurchsatz bestimmt. Liegt dieser unter dem erwarteten Wert, kann mittels Ausschlussverfahren die Ursache für das unerwartete Bottleneck ermittelt werden.

Ursachen für eine Differenz zwischen gemessenem und berechnetem Datendurchsatz können sein:

  • Ziel unterdimensioniert: kann mittels Monitoring von Werten wie CPU, Speicher, Netzwerkdurchsatz usw. nachgewiesen werden. Eine Erweiterung des Zielsystems schafft Abhilfe
  • Quelle unterdimensioniert: die Systemparameter werden von einigen Lasttesttools automatisch überwacht. Sollte dies nicht der Fall sein, so kann diese Überwachung mit Betriebssystem- Bordmitteln selbst eingerichtet werden. Eine Zuschaltung von weiteren Lastgeneratoren schafft auch hier schnelle Abhilfe.
  • Ein realer Fehler im Netzwerk konnte nachgewiesen werden: Da der Test beliebig wiederholbar ist, hat das Netzwerkteam nun die Möglichkeit, den Fehler einzugrenzen und zu beheben. Während des Tests nach der Pressekonferenz wurden die ersten Punkte ausgeschlossen und das Phänomen wurde auch in den Monitoren des Netzwerkteams erneut sichtbar. Eine gezieltere Analyse der Datenströme auf allen verfügbaren Glasfaserleitungen führte letztlich zu der Erkenntnis, dass ein kleiner Fehler in der Konfiguration dazu geführt hat, dass nur zwei der vier Glasfaserleitungen genutzt wurden. Dieser Fehler hätte ohne das vorgestellte Verfahren, wenn überhaupt, nur mit höherem Aufwand nachgewiesen werden können, da er erst ab einem gewissen Datendurchsatz sichtbar wird. Erst die Pressekonferenz und schließlich der erstellte Test konnten die Voraussetzung schaffen, um diesen Fehler zu reproduzieren.

Fazit

Wie in vielen Bereichen der Qualitätssicherung bekannt, muss natürlich auch für diese Vorgehensweise eine umfassende Kosten/Nutzen-Abschätzung erstellt werden, die letztlich vom Risiko eines Ausfalls und der drohenden Beeinträchtigung des Netzwerkes beziehungsweise der resultierenden Auswirkungen abhängig ist. Dem Ausfall der Übertragung des Streams zum Server des TV-Senders, der die Pressekonferenz überträgt, wäre sicherlich eine größere Auswirkung zuzuschreiben als einem leichten Ruckeln des Videostreams an den Arbeitsplätzen der Mitarbeiter.

Spätestens im Fehlerfall kann ein guter Kontakt zwischen Experten aus dem Last- und Performanzumfeld und dem für das Netzwerk zuständigen Fachbereich nur Vorteile bringen. 

Marcel Jodorf

Marcel Jodorf ist als Consultant bei der Sogeti Deutschland GmbH im Bereich Softwarequalitätssicherung für einen norddeutschen Großkonzern tätig. Seine Aufgabenbereiche umfassen Beratung, Konzeptionierung, Durchführung sowie Auswertung von Last- und Performanztests für verschiedene Softwareprojekte.   

 

Literatur & Links

[HPLR] Hewlett Packard, LoadRunner
[Kle13] B. Klemm, Application Performance Testing: A Universal Performance Testing Metho- dology, Kindle E-Book, 2013
[Koo08] T. Koomen, L. van der Aalst, B. Broekman, M. Vroon, TMap Next, dpunkt.verlag, 2008
[LTUe] International Testing-Board, Lasttest Tools Übersicht
[Wiki-a] Wikipedia, Lasttest
[Wiki-b] Wikipedia, Rechnernetz
 

 
 
Netzwerkautomatisierung
Nov 10, 2017

Die Phasen der Netzwerkautomatisierung

Im Bereich Networking wird mit Automatisierung der Grundstein für eine Denkweise und ein…
Best Practice
Okt 27, 2017

Netzwerk-Redesign & Implementierung eines Monitoring-Tools

Höchste Qualität basiert auf einer sicheren und stabilen Infrastruktur. Um diese weiter…
IT-Infrastruktur
Aug 24, 2017

Mangelnde Tests sind Risiko für IT-Infrastrukturen

IT-Teams gefährden ihre IT-Infrastrukturen und damit ihre Unternehmen, indem sie weder…
GRID LIST
Interview Ralf Strassberger CenturyLink

Ihr Netzwerk neu gedacht

CenturyLink hat im vergangen Jahr Level3 Communications übernommen. Entstanden ist ein…
Edge Data Center von Rittal

Praktische Tipps für 5G, Blockchain und Industrial Analytics

Die IoT-Veranstaltungsreihe von Cloud Ecosystem und Rittal findet im September in Berlin,…
Wolfgang Sowarsch

Stiefkind Sekundärspeicher: ROI einer Scale-out-Infrastruktur

Wolfgang Sowarsch von Commvault hat sich in einer ruhigen Minute mal überlegt, was das…
15

Apple aktualisiert MacBook Pro – schneller und mit neuen Funktionen für Profis

Apple hat das MacBook Pro mit höherer Leistung und neuen Profi-Funktionen aktualisiert,…
Tb W190 H80 Crop Int 775ac528c7968761631ff816c092b592

Unterscheidungskriterium RZ-Zertifizierung

Zertifizierungen von Rechenzentrumsbetreibern sind nicht „nice to have“, sondern bieten…
Rechenzentrum Alarm

Warum der Bedarf nach RZ-Risikoanalysen steigt

Die Nachfrage nach Risikoanalysen für Rechenzentren steigt. Nach Angaben von Michael…
Smarte News aus der IT-Welt