abonnieren verfolgen erleben

Häufig erfahren die IT-Administratoren erst durch ihre Anwender von Performance-Problemen und leider nicht von den eigenen Monitoring-Tools. Allerdings erschweren die typisch vagen Aussagen, wie z.B. „es dauert ewig“, die zielorientierte Ursachenanalyse. Und die hohe Komplexität in den stark virtualisierten Rechenzentren macht eine Analyse auch nicht einfacher. 

Hier fehlt es meist an einer integrierten, korrelierten Ende-zu-Ende-Sicht über alle Ebenen. Wir empfehlen hier unseren Kunden den Einsatz einer Full-Stack-Monitoring-Lösung von der Firma Uila. Diese Software bietet:

  • Das Monitoring von den physikalischen und virtuellen Systemen
  • Die Überwachung aller Teile der Datacenter-Infrastruktur, von Netzwerk-, Storage- bis zur Applikationsebene
  • Eine Beurteilung der gesamten Kette, angefangen bei der Infrastruktur über die Anwendung bis zu der aktuellen End-User-Experience
  • Eine Korrelation der unterschiedlichen Ebenen inkl. Visualisierung der Rechenzentrumtopologie und den Abhängigkeiten
  • Eine Root-Cause-Analyse für eine effiziente Analyse von Performanceproblemen

 

Im Bericht des IT-Analysten Edwin Yuen von der Enterprise Strategy Group werden die Vorzüge des Full-Stack-Monitorings für Performance-Monitoring in Rechenzentren beschrieben. Das besondere an der Uila Software ist die Deep-Packet-Inspection-Funktion und die Visualisierung der Performance-Daten. Das agentenlose Virtual Smart Tap (VST) scannt den Netzwerkdatenverkehr an den virtuellen Switchen und mittels der integrierten Datenbank von über 4.000 Protokollen und Applikationen werden wichtige Applikations- und Netzwerkmetadaten berechnet. Für sogenannte „Text-on-Wire“-Anwendungen findet sogar eine Transaktionsanalyse statt. Und gemäß „ein Bild sagt mehr als tausend Worte“, liefert die Uila Benutzeroberfläche „einen Roman“ aus. Das intuitive GUI vereinfacht erheblich den Workflow bei der Analyse von Performanceengpässen. 

Am besten überzeugen Sie sich von der 360-Grad Cockpitansicht der Uila Software indem Sie eine
kostenfreie Teststellung bei uns anfordern.

Welcher IT-Administrator kennt das nicht: Ein Anruf eines Anwenders, der anfängt mit „warum ist alles so langsam?“. Diese oder ähnliche Fragestellungen hat jeder schon mal für die unterschiedlichsten Performanceprobleme auf den Schreibtisch bekommen. Wenn der Anrufer dann noch zum Management gehört, fängt jeder hektisch an, im eigenen Fachbereich das gemeldete Problem zu analysieren. Niemand möchte den „Schwarzen Peter“ zugeschoben bekommen und versucht, seine Unschuld - mit den ihm verfügbaren Informationen - zu belegen.
Selbst wenn das Problem von alleine wieder verschwindet, tickt da eine Zeitbombe, die irgendwann mal wieder hochgehen kann.

Gerade bei dieser Art von sporadischen Performancestörungen kann nur mittels einer schrittweisen, strukturierten Vorgehensweise nach dem Ausschlussverfahren dem Problem auf den Grund gegangen werden. Leider gibt es (noch) nicht das ultimative Werkzeug, das leicht bedienbar ist, alles kann, proaktiv Fehler erkennt und sogar Lösungsvorschläge anbietet. Wunschdenken und Wirklichkeit liegen hier weit auseinander. 

Also was ist bei der Fehlersuche von sporadischen Problemen zu beachten:

  • Genaue Fehlerbeschreibungen erstellen. Erst soll das Problem verstanden werden bevor man mit der Analyse beginnt.
  • Versuchen, die sporadischen Probleme auf Teile der IT-Infrastruktur, welche eine Ursache darstellen können, zu reduzieren. Hierfür können dann Daten mit maximaler Detailtiefe erhoben werden.
  • Fokus der Performance-Kennzahlen aus dem Bereich Qualität. Typischerweise erheben die gängigen Monitoring-Systeme Kennzahlen aus dem Bereich Quantität (z.B. CPU- und Leitungsauslastung) aber häufig fehlt es an Qualitätskennzahlen wie z.B. Paketverluste und Applikationsantwortzeit.
  • Eingesetzte Analysetools sind vom „Problem“ abhängig zu machen und nicht umgekehrt.
  • Nach Eingrenzung des Problembereichs sind Experten aus dem jeweiligen Bereich hinzuziehen.

Ohne ausreichend Zeit, die richtigen Werkzeuge und die notwendigen Kenntnisse lassen sich in den heutigen, komplexen und redundanten IT-Infrastrukturen sporadische Performanceprobleme nur schwer analysieren und lösen.

Wenn Sie in dieser Situation eine „unabhängige“ Unterstützung benötigen, dann sind Sie bei uns gut aufgehoben. Gerne übernehmen wir auch das „Management“ von Eitelkeiten der Beteiligten.
Mit unserem langjährigen & fokussierten Wissen, garniert mit unserem umfangreichen Fuhrpark an Analysetools, bietet unsere GeNiAnalyze Dienstleistung eine schnelle und flexible Unterstützung bei der Analyse von Performanceproblemen.

Willkommen zurück zu unserer Blog-Serie über GeNiEnd2End Skripting!

Als letzten Teil der Serie stelle ich ein paar unserer Skripte, die wir selbst in Betrieb haben, vor.

Viele der Skripte sind zum Kennenlernen der Skriptingsprachen erstellt worden und dann später für den produktiven Einsatz überarbeitet worden. Die Skripte Beisner Solar und Temperatur Erfassung dienen ausschließlich dazu, Messwerte für unsere Demosysteme zu sammeln.

Die Darstellung der Messwerte gibt es natürlich nicht nur für einen Tag, sondern auch Wochen, Monat, Jahr -  ganz nach Wunsch dann im GeNiEnd2End.

Ab GeNiEnd2End Version 5.2 (Geplant für Ende des Jahres) ist auch wieder die Aggregierung von Messwerten enthalten.

Beisner Solar:

Beisner Druck ist ein Nachbarn in Sichtweite unserer Hauptniederlassung und seitdem deren Standort eine moderne Solaranlage installiert hat, zeigen sie die dadurch gewonnenen Kilowatt auf ihrer Website an. Ein Skript holt die Messwerte von der Website ab und liefert diese in GeNiEnd2End. Die Chart zeigt ausschließlich die aktuelle Leistung der Solaranlage an.

 http://www.beisner-druck.de/

Temperaturerfassung:

Seit einigen Jahren zeichnen wir die Temperaturwerte einiger Büroräume auf und nutzen es auch zur Notifikation wenn Schwellwerte überschritten werden.

Sofern die Temperatur des Serverraums einen Schwellwert überschreitet wird ebenfalls eine eMail verschickt, direkt durch das Skript.

Ja, der Serverraum ist zu warm, die große Klimaanlage ist defekt und der vorrübergehende Ersatz schafft leider keine ausreichende Luftzirkulation im Raum. Die blaue Linie ist die Aussentemperatur, in Anbetrachtet dessen, hat sich die kleine Aushilfsklimaanlage doch ganz gut gehalten (Serverraum ist die gelbe Linie).
Am Ort der Messung staut sich die Hitze, die Position wurde mit Absicht gewählt :), und zeigt somit immer den schlechtesten Wert im ganzen Raum an.

 

IBM Notes:
Entstanden ist das Skript, um zu zeigen, dass die Bilderfassung stabil und schnell funktioniert. Inzwischen ist das Skript seit 5 Jahren durchgängig als Liefrant für Messwerte aktiv.

Es hat uns auch schon geholfen, Performanceveränderungen aufzuzeigen und den Verursacher ausfindig zu machen. (Siehe Link unten)

Der inzwischen benutzte Roboter hat einen großen Nachteil: Er verfügt über keine richtige Grafikkarte und das spürt man bei dem Benutzen des Notes Clients bzw. das spiegeln auch die Messwerte wieder. Die kurzen Ausfälle sind gewollt, um auch Fehlerstände zu zeigen.

Von 22:00 bis 06:00 ist eine Primetime aktiv, also wird in dieser Zeit keine Messung durchgeführt.

Link zum alten Blog Eintrag (Alte Messwerte):  Blog Eintrag zu Notes und CNS

 

DHCP + DNS + Traceroute:

Aus Kundenwünschen bzw. durch Bedarfserkennung entstanden und inzwischen Standard Skripte von GeNiEnd2End Application. DHCP zeigt die DHCP Offers an und wie viele Server auf die Anfrage geantwortet haben und in welcher Zeit.

DNS zeigt an, wie lange die DNS-Abfrage gedauert hat und der Traceroute-Test zeigt Veränderungen an der Anzahl der Hops auf.

 

DHCP Messdaten nur Messwerte DNS Messdaten nur Messwerte Traceroute Messdaten nur Messwerte
 DHCP  DNS  Traceroute

File Transfer (SMB/CIFS Dateiübertragung):

Probleme mit dem SAN bzw NAS erkennen? Kein Problem! Die SMB Skripte führen einen Dateitransfer oder Transfer mehrerer Dateien durch. Die Größe der Datei/en ist angebbar, Messwerte sind jeweils die Dauer und Geschwindigkeit von Up- und Download.

SMB Messdaten Eine Datei SMB Messdaten 100 Dateien
 Eine Datei 10MB  100 Dateien je 20KB

Anderes:

Skripte für Kunden, um Verfügbarkeit bzw. Performance für interne Websites, Online Banking, Zimmerreservierungen, Messungen in und rund um Citrix aufzuzeigen. Sogar LTE-Verbindungsmessungen haben wir bereits durchgeführt. Natürlich alles mit Alarmierung durch GeNiEnd2End bei Nichtverfügbarkeit oder unter- bzw. überschreiten von Schwellwerten.

Natürlich gibt es auch vieles, was nur internen Bedarf oder Spielereien abdeckte.
Darunter verschiedene Skripte die Commandos per SSH ausführen und deren Durchführung + benötigte Laufzeit dann aufgezeichnen. Erkennung, ob Backups liefen, wie groß diese Anwuchsen pro Tag, SNMP-Abfragen usw., ...

Auch hier bleibt die Devise "The sky is the limit".

Das war nun allerdings der letzte Teil dieser Blogbeitrag-Serie. Hoffentlich konnten wir Ihnen bei Ihrem Skript behilflich seien.

Anderesfalls kontaktieren Sie uns!

 

Willkommen zurück zu unserer Blog Serie über GeNiEnd2End Skripting!

Heute behandeln wir das Back-End Skripting und was dort beachtet werden sollte.

Was sind Back-End Skripte?
Back-End Skripte interagieren normalerweise nicht mit dem Desktop in irgendeiner Art. 
Sie laufen im Hintergrund und behindern keinen an dem System arbeitenden Benutzer.

Es gibt keine Grenzen was gemessen werden kann, von Router Verbindungsstatistiken hin zu wie lange dauern SQL-Abfragen. 
Was immer Sie messen wollen, Sie können es sich selber bauen.

Aber fangen Sie nicht einfach Hals über Kopf damit an, erfinden Sie das Rad nicht neu! Vielleicht gibt es bereits etwas da draußen, das Ihnen die Messwerte liefert, die Sie haben wollen.

Die AutoIt und Python Communities haben bereits viele Module / Libraries, die oft genau das tun / können was man möchte oder Ihnen dabei behilflich sein können, schneller an das Ziel zu kommen. Also schauen Sie zuerst in den Communities.

Wenn es bereits ein anderes Programm gibt, was Ihnen die Messwerte liefert die Sie gerne in GeNiEnd2End haben möchten, dann ist das gar kein Problem! Unsere AutoIt / Python Skripte benutzen manchmal auch im Betriebssystem enthaltene Tools (Ping, tracert, nslookup) oder andere herunterladbare Programme (z.B. PuTTY) um die Messwerte zu bekommen und diese Daten werden dann verarbeite, um nur die gewünschten Daten zu erhalten.

Sie müssen sich nur an die Regeln halten wie der GeNiAgent die Resultate bekommen möchte.

Best practices:
  1. Schreiben Sie ein Log, vielleicht mit einer "Debug" Einstellung, das ein erweitertes Logging aktiviert wenn Sie es benötigen. Dieses kann sehr hilfreich sein, um schnell Probleme zu identifizieren, aufzuzeigen, wo es hängt bzw. welche Unterschiede es zwischen Programmierumgebung und der kompilierten Version gibt. Der GeNiAgent sucht ausserdem nach einem "error.log" und "detail.log" im Skript Ordner und lädt diese auf den GeNiEnd2End Server hoch. Diese sind dann direkt in der Weboberfläche einsehbar.
     
  2. Wenn Sie ein Programm benutzen müssen was auf dem Desktop erscheint, sollten Sie es versteckt starten.
    In AutoIt ShellExecute gibt es eine Option namens showflag, diese kann auf "@SW_HIDE" gesetzt werden.
    In Python können Sie eine hidden flag an den Subprozess anhängen, siehe Hilfe für Informationen.
     
  3. Seien Sie sich bewusst, das wenn ein Skript im Hintergrund über den GeNiAgenten gestartet wird, es andere Rechte haben kann als wenn Sie es manuell starten. Somit könnten andere Probleme auftreten. Normalerweise beeinflusst das die meisten Skripte nicht. Wenn Sie wirklich Admin Rechte benötigen, können Sie AutoIt anweisen, diese mit der "#RequireAdmin" Flag am Beginn des Skripts anzufragen - aber dann sollte der GeNiAgent ebenso mit administrativen Berechtigungen gestartet werden.
     
  4. Wenn Sie viele Transaktionen nacheinander durchführen oder Sie die Packet Trace / CNS Option benutzen, sollten Sie darauf achten, nach jeder Transaktion 5 Sekunden Pause einzuhalten bevor die nächste Transaktion gestartet wird.
     
  5. Wenn Sie ein externes Programm zum Erhalt von Messwerten nutzen, überprüfen Sie diese auf Plausibilität und wie sich der Messwert zusammensetzt.

Nun können Sie durch die GeNiEnd2End Hilfe-Sektion der Skripting Sprache gehen, die Sie benutzen wollen. Diese können Ihnen bei weiteren Vorgehensweisen helfen. 

Im letzten Blogbeitrag dieser Serie zeigen wir Ihnen einige unserer Skripte und auch welche, die es inzwischen in die Standardskripte geschafft haben.

Willkommen zurück zu unserer Blog Serie über GeNiEnd2End Skripting!

Heute behandeln wir das GUI basierte Front-End Skripting und was dort beachtet werden sollte.

Skripte, die mit dem Desktop interagieren, sind einfacher in AutoIt zu erstellen, dadurch aber nur auf der Windows-Platform lauffähig.

Die Hardware des Roboters sollte der von normalen Benutzern entsprechen, ansonsten werden die Messergebnisse von denen der normalen Benutzer abweichen. Es sollte eine physikalische Hardware genommen werden und keine virtuelle Maschine. Schliesslich geht es darum, Probleme zu finden, die ein Benutzer haben könnte und Messwerte zu bekommen, wie lange eine Transaktion für einen Benutzer dauert.

Jede Messung, die wie ein Benutzer agieren soll, sollte mit einer Klickstrecke starten. Diese enthält alle Schritte die das Skript durchführen soll, und man setzt dort die Messpunkte bzw. kann sie dadurch herausfinden. Diese hilft später beim Auffinden von Problemursachen, wenn das Skript an einer spezifischen Stelle hängen bleibt.

 

Beispiel Klickstrecke von einem unserer Produktionsskripte:

 PDF Klickstrecken Dokumentation

Best Practices

  1. Schreiben Sie ein Log, vielleicht mit einer "Debug" Einstellung, das ein erweitertes Logging aktiviert wenn Sie es benötigen. Dieses kann sehr hilfreich sein, um schnell Probleme zu identifizieren, aufzuzeigen, wo es hängt bzw. welche Unterschiede es zwischen Programmierumgebung und der kompilierten Version gibt. Der GeNiAgent sucht ausserdem nach einem "error.log" und "detail.log" im Skript Ordner und lädt diese auf den GeNiEnd2End Server hoch. Diese sind dann direkt in der Weboberfläche einsehbar.
     
  2. Hat die Applikation eine sich schnell verändernde Oberfläche (viele Änderungen am GUI)? Wenn das so ist, sollten Sie versuchen, Fenstertexte (Titel / Inhalt) für die Messungen zu nehmen, so dass Ihr Skript nicht so einfach von GUI-Änderungen beeinflusst wird.
     
  3. Wenn Sie die Bildersuche (Image search) benutzen müssen:
    Dann sollten Sie versuchen, die Bildausschnitte so neutral wie möglich zu machen. Das heisst: Nehmen Sie Bildausschnitte von GUI-Elementen, die sich so wenig wie möglich verändern können oder einfach zu finden sind, auch wenn sich die Lokation etwas verändert hat. Die Größe des Bildausschnitts der gesucht wird, sollte so klein wie möglich sein. Dadurch ist die Chance höher, dass er auch nach Änderungen gefunden wird. Die Screenshots sollten auf einen Roboter erstellt werden, so das keine Farbunterschiede oder andere Eigenheiten vorhanden sind.
     
  4. Wird die Applikation anzeigen, wenn etwas fehlschlägt - z.B. Fehlermeldungen \ Fehlerbehandlung?
    Sie sollten überprüfen, ob nach einer fehlgeschlagenen Messung Fehlermeldungen bestätigt werden müssen oder was passiert, wenn die Applikation sich nicht richtig geschlossen hat. Behalten Sie das im Hinterkopf und skripten Sie für diese Fälle. Schreiben Sie ein "error.log" und "detail.log".
     
  5. Können Sie die Schritte nur mit Mausklicks vornehmen oder auch mit Tastaturkürzeln?
    Sie können Tastatureingaben senden, das ist meistens der bessere Weg, um mit dem Desktop zu interagieren. Dies gelingt natürlich nur, wenn es die selbe Funktion ist wie bei einem Mausklick.
    Wenn Sie einen Mausklick machen müssen und die Lokation des Klicks sich möglicherweise ändert, machen Sie eine Bildersuche (Image search). Dazu suchen Sie nach einem Stück des Buttons und klicken dann darauf, so das Sie nicht den falschen Button anklicken, weil er sich eventuell leicht bewegt hat.
    Wenn Ihre Applikation keine IDs / Namen der Designelemente vergibt, können Sie diese auch direkt ansprechen. (Überprüfen Sie das mit dem AutoIt Window Info Programm)
     
  6. Wenn Sie viele Transaktionen nacheinander durchführen oder Sie die Packet Trace / CNS Option benutzen, sollten Sie darauf achten, nach jeder Transaktion 5 Sekunden Pause einzuhalten bevor die nächste Transaktion gestartet wird.
 

Dieses Beispiel Skript läuft auf einem Roboter, es ist ein AutoIT Skript was mit dem IBM Notes Client 8.5 und 9.0 ohne größere Änderrungen agiert.

 
 

Nächstes Mal befassem Wir uns mit Back-End Skripting.

 

Willkommen zu dieser kurzen Blog Serie über  GeNiEnd2End Application - HowTo / Best Practices Scripting!

Diese Blog Serie soll Ihnen zeigen, worauf Sie beim Erstellen eines Skripts achten müssen und welche Skript- / Programmiersprache zu welchem Nutzen passt. Die Best Practices sollen Ihnen helfen, einige Standardprobleme und Fehler zu vermeiden.

In diesem Blogeintrag behandeln wir die generellen Skripting Richtlinien und welche Skript- / Programmiersprache am besten zu was passt.
Zuerst sollten Sie sich folgende Fragen stellen:

  • Was wollen Sie mit dieser Messung erreichen?
  • Was ist die Platform der Applikation?
    • Windows
    • GeNiJack
    • Beides
  • Was für ein Typ ist die Applikation?
    • Webseite
    • Selbst angepasstes GUI
    • GUI vom Hersteller
    • Anderes
  • Was für Messpunkte soll das Skript haben?
  • Gibt es schon ein Default Skript was Sie bearbeiten könnten?

Welche Default Skripts es in  GeNiEnd2End Application gibt finden Sie in der Hilfe unter Sektion "Application Measurement -> Default Scripts".

Featurevergleich AutoIt und Python:

  AutoIt Python
Plattform Windows Windows / GeNiJack
GUI Testing Ja und es ist einfach Möglich aber nicht empfohlen / Nicht auf GeNiJack
Webseiten Testing Ja, komplett Ja aber nur Downloadzeit und Änderungen
Empfohlen für Anfänger / Professionals Professionals
Messgenauigkeit Gut Am besten
Feature Scope Gut / viele Module verfügbar Am besten / volle Programmiersprache

 


Wenn Ihnen Skripting / Programmierung noch neu ist, können Sie am einfachsten mit AutoIt und einem einfachen Skript starten.
Wenn Sie bereits in einer professionellen Programmiersprache erfahren sind, hat Python einen grösseren Funktionsumfang und wird Ihnen eher zusagen.

Die "Tu es nicht" Aussagen:

  • Vergessen Sie nicht die CNS Option, die Ihre Messzeiten aufbrechen kann in Client / Network / Server Zeit.
  • Unterschätzen Sie nicht die Power von AutoIt, es bietet viele Features, ist einfach zu benutzen und stabil.

 

Wenn Sie bereits eine spezielle Sprache für GUI basierte Tests benutzen oder Sie einfach eine andere Sprache nutzen wollen, dann können Sie diese benutzen und die Ergebnisse an den GeNiAgent übergeben. In diesem Falle kontaktieren Sie uns für Hilfe: support@netcor.de

Bei dem nächsten Mal gehen wir die GUI basierten Front-End Skripting Tests an und was man dabei beachten sollte.

GeNiEnd2End Application
GeNiJack
GeNiEducate

Alles neu macht der Mai, das trifft dieses Jahr auch auf dem NetScout AirCheck zu.

Endlich gibt es das neue AirCheck G2 Modell mit 802.11ac WLAN-Adapter und weiteren Neuheiten.

Neuerungen:

  • 802.11ac 3x3 WLAN-Adapter
  • 5 Zoll Touchscreen
  • Ethernet Tests (PoE, DHCP, CDP, Ping, TCP Port)
  • Kann durchgeführte Verbindungstests automatisch auf Ihren Link-Live Cloud Service hochladen

Das Beste von dem Vorgängermodell wurde übernommen, dazu gehört:

  • Start von 0 auf 100 in unter 10 Sekunden (Startzeit bis voll funktionstüchtig)
  • Auto Test Funktion
  • Externe Antenne anschliessbar
  • Umfangreiche WLAN-Ansichten
  • Lokalisierung von WLAN-Geräten
AirCheck G2 mit Tasche

Sie können sich den AirCheck G2 hier in einer virtuellen Tour ansehen:  Virtuelle Tour

 AirCheck G2     Teststellung anfordern

Unqualifizierte Anwenderbeschwerden wie „bei mir ist alles langsam“, gehören sprichwörtlich zu der berühmten Spitze des Eisbergs. Sichtbar ist lediglich der kleinere Teil eines Eisbergs, während der wesentlich größerer Teil, der Verursacher des Performanceproblems, unter der Wasseroberfläche verborgen ist.
Gründe von schlechten Antwortzeiten können vielseitig sein. Es kann die Infrastruktur sein, wie z.B. ein Engpass bei CPU/Speicher der VM/Hosts, die Netzwerkbandbreite/Latenz und oder Engpass im Storage. Es kann aber durchaus bei komplexen Multi-Tier-Anwendungen an den Abhängigkeiten zwischen Anwendungen und/oder nicht optimal designte Applikationen liegen.

Hinzu kommt noch, dass der erhöhte Komplexitätsgrad innerhalb von virtualisierten Umgebungen die strukturierte und schnelle Ursachenanalyse bei Performanceengpässen erschwert. Die große Herausforderung für den IT-Betrieb liegt darin, für den Zeitraum der Beschwerde, eine Beziehung herstellen zu können zwischen der

  • Anwendungsebene und der virtuellen Infrastruktur wie z.B. VMware, Hyper-V und KVM und anschließend zwischen
  • der virtuellen Infrastruktur und der physikalischen Infrastruktur bestehend aus Host-Hardware und die Netzwerk- und Storage-Infrastruktur.

Ein wesentlicher Ausgangspunkt für eine effiziente Ursachenanalyse ist die Anwenderbeschwerde bezüglich der Applikationsantwortzeit. Allerdings liefern die klassischen Systemmonitoringtools volumenbasierte Performancedaten, wie z.B. Auslastung der CPU/Speicher/Storage, sodass hier der objektive Bezug zum gemeldeten Performanceproblem fehlt. Nur Performancemetriken, wie z.B. Applikationsantwortzeit, Transaktions-volumen, TCP-Session-Metriken liefern die notwendigen Informationen für eine Ende-zu-Ende Performanceanalyse.

Uila AA-IPM Application Performance Ansich

Uila AA-IPM Application Performance Ansicht

Eine Möglichkeit diese Metadaten zu erheben ist Packet-Capturing. Einen ausgesprochen interessanten Ansatz geht hier die Firma Uila mit dem Produkt AA-IPM. Mittels eines Virtual Smart Taps – eine „lightweight VM“, die sich am virtuellen Switch andockt – wird der Datenverkehr in den Richtungen Nord-Süd und Ost-West mittels DPI-Technologie analysiert. Dieser „agentenlose“ Ansatz ermöglicht eine Performance-Analyse aller virtualisierten Anwendungen - auch der VMs die am gleichen virtuellen Switch angeschlossen sind. Dadurch, dass das Virtual Smart Tap die Datenpakete direkt vom virtuellen Switch abgreift, erhält man einen tiefen Einblick in das Kommunikationsmuster und die Netzwerk- und Applikationsmetriken.

Eine weitere Besonderheit der Uila Software ist das integrierte Analytik Modul, das die Applikationsperformance mit der Performance von der virtuellen und physikalischen Infrastruktur korreliert, wodurch die Fehler- Ursachen-Analyse wesentlich vereinfacht wird. Oder anders ausgedrückt, Ihnen den Teil des Eisbergs der unter der Wasseroberfläche liegt, sichtbar macht.

Fehleinschätzungen und Kollisionen wie der Untergang der Titanic können somit vermieden werden. Ahoi!

Analysen von Performance-Engpässen in virtuellen Infrastrukturen ist oft eine knifflige Aufgabe. Es fängt schon damit an, subjektive Beschwerden der Anwender sinngebend mit den Performance-Metriken von VMware zu verknüpfen. Unabhängig von der Objektivität der Wahrnehmung des Anwenders geht es darum, eine Brücke zu bauen zwischen

  • der Maßeinheit Sekunde, die vom Anwender als Applikationsantwortzeit wahrgenommen wird und
  • die Maßeinheiten %, Mbyte, IOPS, Millisekunde usw. die im vCenter abgerufen werden können.

Für eine strukturierte Performanceanalyse ist es aber wichtig, dass eine Beziehung zwischen den unterschiedlichen Messgrößen hergestellt werden kann; wobei das Ganze noch mit dem Zeitraum der Beschwerde zu korrelieren ist. Diese unverbundene Ansammlung von Informationen erschwert die Ursachenbestimmung des Performanceengpasses erheblich. Außerdem fehlt uns oft hierfür die notwendige Zeit und Ruhe zur Durchführung einer effizienten Performanceanalyse.

Damit kommen wir dann zu der tatsächlichen Herausforderung: Wie kann aus dieser Informationsmenge zwischen trivial und bedeutenden Informationen unterschieden werden, sodass daraus Wissen für die Ursachenanalyse entsteht?

Ein interessanter Ansatz für VMware liefert hier die Firma Uila (spricht sich „wee-lah“). Mittels Uila AA-IPM (Application-Aware – Infrastructure Performance Management) wird die unverbundene Ansammlung von Informationen organisiert und es werden Abhängigkeiten zwischen Applikationsantwortzeiten und der Infrastrukturauslastung aufgezeigt. Mit dieser Vernetzung der Informationen verliert das Performance-Troubleshooting von virtuellen Infrastrukturen endlich ihren Schrecken.

Beobachtete, subjektive Performanceengpässe eines Anwenders können mit Uila jetzt objektiv bewertet bzw. die Grundursache(n) schnell ermittelt werden. In der Praxis bedeutet das, dass bei einer Anwenderbeschwerde über lange Applikationsantwortzeiten für eine Oracle Datenbank, die Ursachenanalyse in der Zukunft wie folgt laufen könnte:

Vorgehensweise mit Uila AA-IPM

Vorgehensweise mit Uila AA-IPM

  1. Zeitraum der Beschwerde auswählen
  2. In der Alarmübersicht gibt es tatsächlich einen Eintrag über lange Antwortzeiten der Oracle 11g-n2 Datenbank
  3. In der Ursachenanalyse wird u.a. ersichtlich, dass wegen hoher IOPS-Werte des Storagesystems, hohe Antwortzeiten in der Datenbank entstehen
  4. In der detaillierten Storageanalyse wird der wahre Verursacher der hohen IOPS-Werte des Datastore1 (4) aufgeführt, es ist die Oracle Datenbank 11g-n1

Nicht strukturierte Informationen gewinnen erst an Aussagekraft, wenn sie ins Verhältnis zu anderen gesetzt werden. Genau hier unterstützt das Analytikmodul von Uila AA-IPM den IT-Verantwortlichen bei der Behebung von Performanceproblemen.

Ohne Uila AA-IPM ist die Performanceanalyse in VMware wie das Suchen der Nadel im Heuhaufen.

Bei der Netzwerkanalyse in 1G/10G-Netzen werden für die Bewältigung von großen Datenvolumina immer häufiger sogenannten Network Packet Broker eingesetzt. Diese Switches können unterschiedlichen Datenströmen u.a. aggregieren, regenerieren und/oder filtern. Um bei komplexeren Switch-Konfigurationen nicht den Überblick zu verlieren, sagt ein Bild mehr als tausend Worte.

 

Infinicore Domain Designer

Infinicore Domain Designer

 

Mit dem neuen, web-basierten Flow Domain Designer des FlowDirector-640 von Infinicore können Sie jetzt per Drag und Drop die gewünschte Konfiguration einfach „zeichnen“. Mittels unterschiedlichen Shapes wie z.B. Ingress-Ports, Egress-Ports, Aggregator, Replicator oder Filter kann die benötigte Switch-Konfiguration per Drag und Drop im Flow Domain Designer erstellt werden. Somit können komplexe Konfigurationen in übersichtlichen Netzwerkdiagrammen visualisiert und für Dokumentationszwecke können diese Netzwerkdiagramme sogar exportiert werden (PDF).

Der FlowDirector-640 verfügt über 48 x 1G/10G SFP/SFP+ und 4 x 40G QSFP Ports und ist mit der aktuellsten Generation von Prozessoren und Switch-Technologien ausgestattet und macht es einfach, Datenströme von Span-Ports und Taps zu aggregieren, zu kopieren, zu filtern und diesen gezielt zu den Monitoring-Tools weiterzuleiten.

Bei Interesse, zögern Sie nicht, uns für eine Produktevaluierung zu kontaktieren.

Es gibt eine Vielzahl von Tools für die virtuelle Performance- und Kapazitätsanalyse. Sie überwachen die CPU-, Speicher-, Storage- und Netzwerkleistung indem sie das vCenter hierfür anzapfen. Mit den Performancemetriken Bytes in/out, Pakete in/out und Fehlerzähler für die physikalischen und virtuellen Interfaces liefern diese Informationen nur einen eingeschränkten Nutzen beim Troubleshooting von Fehlersituationen. Zum Beispiel wenn auf einem Hostadapter eine erhöhte ausgehende Netzwerklast zu verzeichnen ist; ist das jetzt ein Problem?

Sofern ein System-Monitoring zum Einsatz kommt, kann hiermit dargestellt werden, dass die Netzwerklast ungewöhnlich hoch ist, allerdings auch nicht mehr.

Man weiß nicht:

  • was das für ein Datenverkehr ist
  • wer ist/sind der/die Verursacher(n)
  • welche Auswirkung diese zusätzliche Last auf die Latenz für den anderen Datenverkehr auf diesem Host hat

Mit anderen Worten: Für eine effiziente Fehlererkennung und Behebung fehlen wichtige Informationen.

Was müssen Sie wirklich wissen über Ihr virtuelles Netzwerk?
Reine Auslastungsinformationen bei der Analyse von Performanceproblemen in virtuellen Netzwerken reichen nicht mehr aus. Es werden netflow-ähnliche Daten benötigt, wie z.B.:

  • wer kommuniziert mit wem?
  • welche Ports/Protokolle werden genutzt?
  • wann hat die Kommunikation stattgefunden?
  • wie groß war das Datenvolumen?

Weitere wichtige Informationen sind:

  • welche Abhängigkeiten bestehen zwischen Applikationsantwortzeiten und der Auslastung der Infrastruktur (Host, Netzwerk, Storage)?
  • welche VMs erleiden ungewöhnlichen hohen virtuellen Netzwerklaufzeiten?
  • wer verursacht die hohe Laufzeiten?
    • physikalischer Switch
    • Netzwerkkarte des Hosts
    • virtueller Switch
    • virtuelle Netzwerkkarte

Mittels dieser Detailinformationen können schnell und einfach Performanceengpässen in virtuellen Netzen diagnostiziert und proaktiv Applikationsperformanceproblemen verhindert werden.

Und wie erhält man diese Daten? Mit Uila AA-IPM.

Ursachenanalyse mit Uila AA-IPM
Mit der Uila Software können Performanceschwachstellen in der vSphere-Infrastruktur in Echtzeit oder auch historisch aufgezeigt werden. Uila liefert eine direkte Korrelation zwischen der Applikationsantwortzeit und der Auslastung der Infrastruktur. Mittels einer Virtual Smart Tap (vST) Gast-VM wird der Datenverkehr zwischen den VMs analysiert - in dem es die Daten am vSwitch analysiert. Es werden nur Metadaten, wie z.B. Applikationsantwortzeit und Kommunikationsbeziehungen, erhoben.

Uila AA-IPM Sankey-Diagramm

Uila AA-IPM Sankey-Diagramm

Über die zentrale Managementsoftware können die virtuellen Switche ausgewählt werden, an dem das Virtual Smart Tap die Deep Packet Inspection durchführen soll. Diese Informationen werden mit den Auslastungsdaten die vom Virtual Information Manager (vIM) eingesammelt werden im Uila Portal korreliert. Der vIM sammelt Performancedaten der Infrastruktur (Host, Netzwerk, und Storage), die vom vCenter verwaltet werden, und speichert diese für die forensische Analyse in einer Hadoop Analytik Plattform ab.

Mit den Sankey-Diagrammen zur Visualisierung der Datenflüssen und der Applikationstopologiemap erhält der System- und Netzwerkadministrator einen globalen Einblick in möglichen Performanceengpäßen, was zu einer effizienteren Fehler- und Ursachenanalyse führt.

Interessiert? Dann zeigen wir Ihnen gerne per Websession die Uila Aplication-Aware Infrastructure Performance Management Software.

Auch im Jahre 2015 hält sich dieser Mythos hartnäckig. Jeder Netzwerker kennt die weit verbreitete Aussage: Der Netzwerkdurchsatz ist schlecht, wir brauchen mehr Bandbreite!
In einer kürzlich durchgeführten  Performanceanalyse bei einem Kunden, durfte einer unserer Consultants wieder als Mythbuster auftreten, um die Mythen des IT-Alltags zu entzaubern.
In diesem konkreten Fall gab es Beschwerden bei einer NAS-Synchronisierung über eine WAN-Strecke (300 Mbps Bandbreite und eine RTT um die 11 ms).

Die IO-Graphen in Wireshark sind ein effektives Hilfsmittel bei der Performanceanalyse. In der IO-Durchsatzgrafik ist erkennbar, dass für eine Session der maximale Durchsatz in Empfangsrichtung ca. 70 Mbps und für die Senderichtung ca. 12 Mbps beträgt.



Mittels der IO-Window-Size-Grafik ist schnell der Grund für den Performanceengpass ersichtlich: Die Receive-Window-Size, also die maximale Menge an Puffer, die das NAS für eine Session/Socket/Verbindung zur Verfügung stellt, ist hier der Performancebremser.
Bei einer Window-Size von ca. 17kB beträgt der hier maximal erreichte Durchsatz in Senderichtung ca. 12 Mbps. Um das zu verifizieren, kann einfach mit dem Bandwidth-Delay-Produkt (BWDP) die max. mögliche Bandbreite berechnet werden:

Window-Size / RTT = 17kB / 11 ms<= 12,4 Mbps.


Fazit dieser Dienstleistung ist:

  • Die Performancebremse ist die Receive-Window-Size von 17 kByte des NAS und nicht die verfügbare Bandbreite von 300 Mbps
  • Eine Erhöhung der Bandbreite würde in diesem Fall nicht zu einem höheren Durchsatz führen. Eine (im Vergleich zum LAN) hohe Laufzeit, eine hohe Bandbreite, kombiniert mit einer kleinen Window-Size passen einfach nicht zusammen
  • Lediglich die Erhöhung der Window-Size würde den Durchsatz erhöhen
  • Neben der Bandbreite gibt es zwei wichtige Faktoren, die den maximal möglichen Durchsatz beeinflussen:
    • Laufzeit
    • Receive-Window-Size
  • Sind diese beiden Faktoren bekannt, kann mit dem BWDP – ohne viel Aufwand – der maximal mögliche Durchsatz einer Session berechnet werden




Mit diesen beiden Ergebnissen würde man bei den Mythbusters den Mythos als „busted“ deklarieren oder in unserer Sprache: Es ist weiterhin NICHT das Netzwerk!

Seit mit den Best Practice Ansätzen von ITIL das Servicedenken in der IT implementiert worden ist, haben sich viele Unternehmen schrittweise mit IT-Service-Management beschäftigt.
Viele unserer Kunden haben mit dem Incidents und Problem Management angefangen, Change und Release Management waren der nächste Schritt. In der dritten Phase folgte die Festlegung und Überwachung von Service Levels.

In dieser Phase lag der Fokus auf rein technisch orientierten KPIs, wie z.B. die Verfügbarkeit und Auslastung von Systemen & Applikationen, die Anzahl von Incidents und die Zeit der Fehlerbehebung.
Womit sich viele Unternehmen schwer tun, ist das Implementieren von End-User-Experience SLAs.
Bei diesen End-User-Experience SLAs stehen für Anwender relevante und nachvollziehbare Kennzahlen im Mittelpunkt.

Meist geht es darum, zu quantifizieren, wie viel Zeit bestimmte Business-kritische Aktivitäten benötigen, wie z.B. das Aufrufen einer Kundenakte, das Speichern einer Bestelländerung oder das Herunterladen von Dokumenten.

Viele Unternehmen hätten diese Kennzahlen zwar gerne aber nur wenige haben sie tatsächlich implementiert. Wie kann es sein, dass im Jahre 2015 nur eine geringe Anzahl von IT-Abteilungen Kennzahlen rund um die Anwenderzufriedenheit für die Kommunikation zwischen Business und IT nutzt?

Barrieren bei der Umsetzung
Wenn wir das Argument „kein Handlungsbedarf“ ausschließen, gibt es nach unserer Erfahrung folgende Hürden für End-User-Experience SLAs:

  1. Silo-Mentalität
    Der Anwender ist nicht im Fokus, es wird nicht über die Grenzen der eigenen Abteilung oder gar die IT hinaus gedacht.
     
  2. Verliebt in Technik
    Die IT sieht sich immer noch als Technologie-Lieferant, nicht als Erbringer eines Services.
     
  3. Ressourcen
    Es fehlt an Personal und Zeit.
     
  4. Know-How
    Es ist nicht genügend Wissen über methodische Ansätze und den Umgang mit passenden Tools vorhanden.

Bei den organisatorischen Herausforderungen (Punkt 1 und 2) können wir den Kunden nur eingeschränkt unterstützen. Für die Punkte 3 und 4 haben wir allerdings bewährte Methoden und Tools im Portfolio, um objektive Service Level Kennzahlen aus Anwendersicht erheben zu können.

Vor dem Einführen von SLAs für die Business-Aktivitäten der Endwender, ist es notwendig, zuerst die „normale“ Performance der Geschäftstransaktionen zu ermitteln.
Ein Ansatz, um diese Baseline-Informationen zu bekommen, ist ein synthetisches Monitoring.

Hierbei simuliert ein Skript periodisch Business-Aktivitäten und ermittelt dadurch die Transaktionszeiten. Allerdings liefert dieser Ansatz meist nur Antwortzeiten für lesende Geschäftstransaktionen, wie z.B. das Suchen einer Patientenakte. Ausführende Transaktionen, wie z.B. das Anlegen einer Bestellung, sind in der Praxis nur aufwendig zu realisieren.
Ein weiterer, gravierender Nachteil ist dabei auch das Fehlen von tatsächlichen End-User-Experience Messwerten. Diese sind elementar für die Fehlerbehebung individueller Performanceprobleme.

Ohne objektive und anwenderbezogene Leistungsinformationen auf Endgeräte- und Transaktionsebene sind Incidents zu Performance-Engpässe oft nur mühsam oder gar nicht zu analysieren und zu beheben.

Zwei wichtige Schritte
Zusammengefasst bedeutet das, dass folgende Funktionen benötigt werden:

  1. Baselining
    Es müssen im ersten Schritt Business-Aktivitäten aus Anwendersicht für das Performance-Baselining gemessen werden. Dies ist die Basis für begründete Service-Levels.
     
  2. Festlegung der Service-Levels
    Auf Basis der Baseline-Informationen werden die Service-Levels aller Business-Interakationen festgelegt. Nun werden Abweichungen vom Normalverhalten automatisch sichtbar gemacht.

Mit dem einzigartigen Business-Aktivitäten-Analytics Verfahren von  Aternity können die Anwendungsperformance-Erfahrungen für jeden End-User überwacht werden.

Zusätzlich zu Applikationsantwortzeiten werden unter anderem weitere Performance-Metriken in Echtzeit gemessen:

  • CPU-Auslastung des Desktops
  • Speicherauslastung des Desktops
  • Aktive Prozesse
  • Anwendungsabstürze

Durch Korrelation dieser Metriken und Ereignisse zu den Anwendern, Anwendungen und IT-Komponenten ist schnell ersichtlich, welche Lokationen, Abteilungen, Server, Hardware-Konfigurationen und Business-Aktivitäten von den Performance-Engpässen betroffen sind.

 

Aternity Workforce APM

 

In einem übergeordneten Analysebericht wird für jede Business-Aktivität der Durchschnittswert der Applikationsantwortzeit aus Anwendersicht (1) dargestellt. Dies ist die Grundlage für Service-Levels aus Anwendersicht.

Darauf basierend können Schwellwerte (2) für die End-User-Experience SLAs festgelegt werden. Jede Business-Interaktion der Endanwender wird mit den dazugehörigen SLA-Schwellwerten verglichen, sodass Unternehmen Applikationsperformanceprobleme proaktiv erkennen und lösen können. Ebenso ist die Häufigkeit der Schwellwertüberschreitungen (3) ersichtlich.

Für die Root-Cause-Analyse kann der Detailgrad schrittweise erhöht werden.

SLAs für in-house und outsourced Applikationen
Bemerkenswert an der End-User-Experience Monitoringlösung von Aternity ist, dass Unternehmen sie sehr flexibel einsetzen können. Sie können die Performance aus Endanwendersicht von Anwendungen messen, die im hauseigenen Rechenzentrum, von einem Cloud-Provider, einem SAAS-Anbieter oder einem Outsourcing-Dienstleister gehostet werden.

Mit der automatischen Problemerkennung kann schnell die Ursache erkannt und behoben werden.
Diskussionen ohne Grundlage zwischen den IT-Fachabteilungen entfallen und es gibt keine falschen Zuweisungen mehr - jedoch eine bessere End-User-Experience.

Den Umgang mit neuen Produkten zu lernen oder zu vermitteln, kann schwierig sein. Vorallem, wenn ein Kollege an einem anderen Standort die eigene Softwarelizenz nutzt und man ihm das "mal eben schnell" erklären soll.

Dank Internet ist heute fast alles an Lernmaterial mit wenigen Klicks direkt verfügbar.

Fluke networks bietet zu seinen Produkten umfangreiches Lernmaterial und Schulungskurse, die kostenfrei genutzt werden können, an.
Hier finden Sie eine Zusammenfassung des verfügbaren Lern- bzw. Schulungsmaterials zu den AirMagnet Produkten.

 

 AirMagnet Survey:

 

 AirMagnet Planner (in Survey Pro enthalten):

 

 AirMagnet WiFi Analyzer:

 

AirMagnet Spectrum XT:

 

Weitere Videos zu den Fluke-Produkten gibt es auf dem  Fluke Networks Youtube Video Kanal.

Natürlich bieten wir auch umfangreiche  Schulungen zu jedem AirMagnet Produkt an, die mit gesammeltem Wissen aus realen Projekten gefüllt sind.

Eine der beliebtesten und wohl auch am weitesten verbreiteten Protokollanalyse Tools ist Wireshark. Leistungsstark und dazu auch noch kostenfrei! Eine Kombination, die nahezu perfekt scheint.

Für die bisher dominierenden 1G-Netze passte das meist auch sehr gut. Doch die Entwicklung ging in den letzten Jahren rasant voran, so dass wir heute an zentralen Punkten 10 oder gar 40G-Anbindungen vorfinden.

Doch wie messe ich hier nun mit meinem lieb gewonnenen Wireshark Analyzer?

Die Trace-Performance der Notebooks reicht nicht mehr aus und auch leistungsfähige Server-Hardware bietet nicht wirklich eine praktikable Lösung, wenn ich 100% der möglichen Last zur Fehleranalyse mitschneiden und später auswerten will.
Hier kommt häufig die kostspielige, proprietäre Messhardware namhafter Anbieter ins Spiel. Diese ist aber für viele Unternehmen meist nicht finanzierbar.

Um diese entstandene Lücke zu schließen empfehlen wir unseren Kunden die Lösung  FlowMagic von der Firma Infinicore. Dabei handelt es sich um eine leistungsstarke Appliance, die in den letzten Jahren u.a. durch einen intensiven Austausch mit dem Hersteller und unseren technischen Consultants „deutsche“ Marktreife erlangt hat und durch ihr einmaliges Preis-/Leistungsverhältnis besticht.

Überzeugen Sie sich gern einmal in Form einer kostenfreien  Teststellung davon.

Wir haben folgenden Fall: Microsoft veröffentlicht ein Update für seine Software SharePoint. Vielleicht steht im Changelog etwas im Sinne von: „Open Item: Now 50% faster!“

Das klingt an sich schon einmal gut, aber: Ist Open Item nun wirklich schneller geworden?

Lösungsvorschlag 1: Subjektives Empfinden.

  • Person 1 hat es eilig und sagt wahrscheinlich: „Nein! Vor dem Update war es eindeutig schneller!“
  • Person 2 hat Zeit und sagt: „Ja. Auf jeden Fall!“

Vergessen wir diese unpräzise "Analyse" besser ganz schnell wieder. 

 

Lösungsvorschlag 2: Wir nutzen Aternity. 

Hier kommt es ausschließlich auf die Messdaten an. In einer praktischen Übersicht wird Ihnen gezeigt, wann und wie viel sich getan hat. Alles was Sie tun müssen, ist nur, dass Sie eine Anwendung, Zeitpunkt der Änderung, Zeitrahmen und eine Aktivität auswählen.

Aternity Workforce APM Trends

Aternity Workforce APM Trends

 

Nachdem die Messdaten geladen sind, können Sie sofort sehen: „Aha, es sind zwar keine 50%, aber Open Item benötigt nur noch 4 statt 6,4 Sekunden!
Toll, jetzt benötigt Open Dialog allerdings 6,5 statt 4 Sekunden…
 

Aternity Workforce APM Activities

Aternity Workforce APM Activities

Ein Update kann die Arbeitsgeschwindigkeit einer Software verbessern aber auch verschlechtern.
Mit  Aternity Workforce APM haben Sie diese Veränderung genau im Blick.

Das nun schon dritte Gerät der GeNiJack-Reihe ist seit Anfang des Jahres bei uns erhältlich - der GeNiJack 301. Neben dem neuen Aussehen hat sich auch innerlich einiges getan. Aber zunächst ein wenig über das Testmodell vor dem  GeNiJack 301.

Hauptaugenmerk lag bei der Auswahl eines neuen Geräts auf der Netzwerkperformance. Der neue GeNiJack sollte auch auf Gigabitstrecken genaue Performancewerte ermitteln können und noch genügend Leistung haben, um nebenbei einen Paketmitschnitt auszuführen.
Zunächst fiel ein Gerät mit einem Cortex A9 Quad-Core und zwei Gigabit-Ethernet-(GbE) Ports auf, welches ich auch kurz darauf auf meinem Tisch hatte. Leider wurden bei Messungen mit Laborbedingungen nur etwa 250 Mbit/s auf dem ersten und 500 Mbit/s auf dem zweiten GbE-Port festgestellt. Eingesetzt wurde IxChariot 7.30 und als Referenz Iperf. Das schlechte Abschneiden auf dem ersten Port ließ sich auf die Anbindung über USB 2.0 auf der Platine zurückführen. Der zweite Port ist zwar über eine PCI-Lane angebunden, jedoch haben wohl Treiberprobleme zu dem schlechten Durchsatz geführt. Leider konnte hier keine Lösung gefunden werden.

Nach weiterer Recherche tat sich eine stärkere Hardware auf: Verbaut ist ein Intel Atom E3845 Quad-Core und wieder zwei GbE-Ports, zusätzlich sind drei USB 3.0 Ports vorhanden.
Nach den ersten Tests des Geräts war schnell klar, dass die gesuchte Leistung vorhanden ist. Ein TCP Duplex Test wurde mit ca. 940 MBit/s pro Richtung durchgeführt. Auch bei einem TCP Duplex Test über beide GbE-Ports gab es keine Einbrüche. Es wurden also vier Pairs mit einer Gesamtbandreite von ca. 3.8 GBit/s problemlos gemessen.

 

Durchsatztest vom GeNiJack 301

Durchsatztest vom GeNiJack 301

Nach kleinen Verfeinerungen am System (Debian 7) und dem Einspielen der  GeNiEnd2End Software, sowie dem vom GeNiJack bekannten GeNiJackManager, konnten erste, zufriedenstellende Kundentests durchgeführt werden.

Der GeNiJack 301 steht nun mit 4 GByte Arbeitsspeicher und 500 GB Festplatte seit Januar bei uns zur Verfügung.

Diese Woche gab es zum o.g. Thema wieder eine intensive Diskussion in einer meiner LinkedIn Gruppen. Es erinnerte mich an die Zeit, in der Token Ring Befürworter sich mit den Ethernet Gegnern darüber stritten, wer die bessere Technologie habe. Oder wer kennt noch den Formatkrieg bei den Videorekordern: VHS vs. Betamax vs. Video 2000?

Tja, was ist jetzt besser: Ein End-User-Experience Monitoring auf Basis von Agenten oder mit Appliances? Wie immer gibt es Pro und Cons bei beiden Ansätzen. Was ich aber bei diesen Diskussionen immer vermisse, ist, dass der Reifegrad der IT-Organisation, resp. das Know-How, bei der Auswahl des Monitoringansatzes vergessen wird.

Vielleicht erinnern Sie sich noch an das Gartner IT Infrastructure and Operations Model. Hier wird sehr übersichtlich dargestellt, dass neben der Technologie auch die Entwicklungsstufe der Prozesse und der IT-Mitarbeiter eine wichtige Rolle spielen; oder wie wir sagen: Die richtige Technologie, mit den richtigen Informationen für die richtige Person zur richtigen Zeit.

Deshalb führen wir in unserem Produktportfolio sowohl agentenbasierende Systeme, wie z.B. GeNiEnd2End oder, jetzt ganz neu,  Aternity als auch agentenlose Systeme, wie z.B. SecurActive APS oder Fluke Networks TruView.

Bei einigen Projekten haben wir sogar beide Ansätze miteinander gemischt. Wir kennen uns hier aus, da wir täglich bei unseren Troubleshooting-Dienstleistungen genau die Tools einsetzen, die am schnellsten die Verursacher der Performanceprobleme aufdecken.

Und wer ist jetzt technisch besser? Wie auch in den Zeiten des Formatkrieges bei den Videorekordern, entscheiden andere Dinge über Wohl und Wehe einer Technologie.

Immer wieder erlebe ich die Situation, dass vom Kunden, nach der Vorstellung einer für ihn sowohl technisch als auch preislich passenden Lösung, die Frage nach Referenzkunden kommt.

Dies ist absolut nachvollziehbar, denn es geht doch nichts über „Gleichgesinnte“, die mit ihren guten Erfahrungen im Umgang mit dem Produkt Rede und Antwort stehen.
Enttäuschung kommt dann gern mal auf, wenn es „nur“ einen offiziellen Referenzkunden gibt und dieser dann zusätzlich noch am anderen Ende der Republik beheimatet ist.

Da wird dann gern mal nachgehakt: „Haben Sie denn keinen weiteren Referenzkunden?“ Und damit verbunden kleine Zweifel ausgedrückt, ob das vorgestellte Produkt die richtige Wahl ist.
Meine Antwort ist dann wahrheitsgemäß, wie auch ernüchternd: „Nein, wir haben viele zufriedene Kunden, die gerade diese Lösung einsetzen, die aber nicht als Referenzkunde genannt werden wollen.“

Die Ursache dafür ergibt sich dann aus meiner nachfolgenden Frage an den Kunden: „Könnten wir SIE als Referenzkunden aufführen, wenn sie das Preis-/Leistungsverhältnis überzeugt und sie sich für einen Kauf entscheiden sollten?“
Meist folgt dann eine kleine Pause und der Kunde beginnt seine Antwort mit: „Von mir aus gern, aber bei uns ist das nicht so einfach...“ oder schlicht „Das machen wir grundsätzlich nicht.“

Zum Glück gibt es dann doch Kunden, die so überzeugt von unserer Lösung sind, dass sie den meist steinigen und langwierigen Weg in ihrem Unternehmen gehen und die Genehmigung erhalten, um als Referenzkunde zur Verfügung zu stehen.

In diesem Zusammenhang sind über die Jahre einige interessante Projektberichte entstanden, die wir auf unserer Webseite zum Download zur Verfügung stellen.

Grundsätzlich ist meiner Ansicht nach eine Teststellung des Produktes im Hause des Kunden viel aussagefähiger für ihn in Punkto Nutzen und Bedienbarkeit, als ein Referenzkunde, von dem man nicht weiß, wie viel Aufwand getrieben werden musste, um die Lösung in einen vorzeigbaren Zustand zu bringen.

Langsam kommt der 802.11ac WLAN-Standard in Schwung und immer mehr Kunden wollen eine 802.11ac konforme Ausleuchtung durchführen. Somit ist es an der Zeit, das Thema mal genauer unter die Lupe zu nehmen und ein paar Hinweise zu geben.

 AirMagnet Survey unterstützt folgende 802.11ac WLAN-Adapter:

Verwenden Sie bei dem Netgear A6200 WLAN-Adapter den aktuellsten Beta-Treiber, damit Sie auch alle Kanäle in Deutschland benutzen können. Dieser funktioniert auch unter Windows 7 (Treiber unterstützt DFS) :  Link zur Netgear Seite

Einschränkungen und Hinweise:

Es kann nur ein 802.11ac Adapter gleichzeitig genutzt werden. Alle Unterstützten 802.11ac Adapter können aktuell keine Noise Werte aufzeichnen!

Windows XP wird in Zusammenhang mit 802.11ac Adaptern nicht unterstützt.
Verfügbare Adapter unterstützen WLAN-Verbindungsgeschwindigkeiten bis maximal 867Mbits.

Wenn ein 802.11ac Adapter genutzt wird, sind ein paar Funktionen nicht nutzbar:

  • VoFi Survey, Roaming Control für Aktive Surveys / Aktive IPERF Surveys
  • Anzeige des aktuell gescannten Kanals

 

Empfohlene AP-Einstellungen bei Active Surveys in Zusammenhang mit AP on a Stick:

  • AP konfiguriert als DHCP Server und Gateway. WLAN Adapter konfiguriert auf DHCP
  • AP konfiguriert als DHCP Server und Gateway nicht konfiguriert. WLAN-Adapter konfiguriert auf DHCP
  • AP konfiguriert nicht als DHCP Server, statische IP Adresse, Gateway nicht konfiguriert. WLAN-Adapter konfiguriert mit statischer IP Adresse in dem selben Bereich wie der AP

 

Hinweise zu den Systemanforderungen:  AirMagnet Systemanforderungen

Bitte lesen Sie sich für ausführliche Informationen die aktuellen Release Notes durch: 

 AirMagnet Survey 8.6
 AirMagnet Survey 8.7

Ich nutze ihn sehr gerne für die Analyse von Problemen jeglicher Art und ich gebe das Wissen ausgesprochen gerne in unseren Wireshark Schulungen Wireshark Schulungen weiter. Aber wie jedes Produkt hat auch Wireshark Grenzen. An diese bin ich in einer der jüngsten Dienstleistungen von NETCOR Analysen gestoßen. Ein Kunde brauchte eine Auswertung zur Belastung einer WAN-Leitung für ausgewählte Citrix-Transaktionen, um ermitteln zu können, wie viel Last bestimmte Transaktionen tatsächlich erzeugen und wie hoch dann die Last bei einer bestimmten Anzahl an Anwendern ist.

Wireshark I/O Graph

Nun, Wireshark kann hier nur sehr begrenzt mit dem I/O Graphen punkten und speziell bei dieser Aufgabenstellung ist er das falsche Werkzeug. Somit habe ich Omni Peak WildPackets OmniPeak getestet, der in dieser Disziplin mit deutlich mehr Informationen daherkommt und auch eine sehr hohe Messauflösung bereitstellt. Die zusätzlichen Informationen wie Top Talker, Listener und Applikationen waren mehr als hilfreich.

Wildpackets OmniPeek Compass

Dadurch konnte ich die Analyse schneller und mit einer höheren Informationsdichte als geplant erstellen. Ich bin mir sicher, dass OmniPeak noch viel mehr kann, ich bin offen für neues, wie auch NETCOR. Wir schauen immer über den Tellerrand, um die beste Lösungen für unsere Kunden zu suchen, zu testen, in der echten Praxis zu erproben und auch empfehlen zu können.
Somit bieten wir immer die richtige Lösung für die Anforderungen unserer Kunden. Und meinen Wireshark, den werde ich immer lieben, er ist in vielen Bereichen einfach das richtige Werkzeug.

Analyse von Datenpaketen mit Wireshark & Co. gehört zu der Königsdisziplin bei den Netzwerkspezialisten. Gerade bei Netzwerkfehlern und Performanceproblemen ist es häufig das letzte Mittel der Fehleranalyse. Oder wie der Netzwerker sagt: Die Wahrheit steckt in den Datenpaketen.

Für solche Fälle ist die Open-Source Analysesoftware Wireshark aufgrund der vielseitigen Einsatzmöglichkeiten das bevorzugte Tool. Allerdings - wie ist das in 10G Netzwerken mit hoher Netzwerklast und bei sporadischen Problemen? Eine Lösungsmöglichkeit wäre hier eine Streaming-to-Disk Appliance. Meistens übersteigen die Kosten und die Komplexität von 10G Datenrekordern die Anforderungen der Anwender und die einzige Alternative ist eine Capture-Appliance selber zu bauen. Allerdings ist der Eigenbau eines Hochleistungsdatenrekorders nicht jedermanns Sache.

Abhilfe schafft hier die FlowMagic Streaming-to-Disk Appliance von InfiniCore. Nach dem Motto „do more with less“ liefert InfiniCore mit FlowMagic einen hochperformanten, modularen Netzwerkdatenrekorder inkl. eines skalierbaren Speicherkonzepts mit einem ausgezeichneten Preis-/Leistungsverhältnis. Die intuitive, web-basierende Benutzeroberfläche unterstützt den Netzwerkspezialisten bei der forensischen Analyse von Performanceanomalien.

Vorselektion (z.B. nach Zeitraum, IP-Adressen) der Datenpakete für den anschliessenden Datenexport in einer Pcap-Datei

Vorselektion (z.B. nach Zeitraum, IP-Adressen) der Datenpakete für den anschließenden Datenexport in eine Pcap-Datei

Die nachträgliche Detailanalyse erfolgt dann mit dem integrierten WireShark Packet Viewer. Alternativ können die Datenpakete für eine Analyse exportiert werden.
Für eine bessere Handhabung können die Datenpaketen nach Kriterien, wie z.B. Zeitraum oder IP-Adressen, mittels des integrierten Analytic Tools vorselektiert werden.

 

FlowMagic, ist es Magie? Finden Sie es raus indem Sie FlowMagic testen.

Seit GeNiEnd2End 4.6 wird nun Python als Skriptsprache für das Application-Testing unterstützt. Python ist eine syntaktisch einfach zu erlernende, aber mächtige Programmiersprache. Warum es dennoch "Light" ist und was Sie alles damit machen können, werde ich Ihnen jetzt erklären.

Einer der Hauptpunkte der für Application Light, also Python als Programmiersprache, spricht, ist wohl, dass diese Skripte meist ohne weitere Anpassungen sowohl auf Windows PC als auch auf unseren hauseigenen GeNiJacks laufen. Um dies zu realisieren, wird unter Windows ein eigens mitgelieferter Python Interpreter verwendet. Auf den GeNiJacks ist dieser sogar schon vorinstalliert und wird durch die Update-Funktionalität der GeNiJacks immer aktuell gehalten. Dadurch, dass Python "interpretiert" wird, müssen die Skripte auch nicht für das jeweilige System kompiliert werden, sondern können einfach über den Interpreter ausgeführt werden.

Code für einen DNS Resolve Test

AutoIT hat eine, für uns, ungeschlagene Mechanik, um grafische Benutzeroberflächen (GUI)-Abläufe zu automatisieren. Wenn es jedoch darum geht außerhalb einer GUI zu agieren, ist Python eine gute Wahl. Dies kommt auch durch die sehr aktive Python-Community, die viele ihrer Skripte und Bibliotheken freigibt und für andere verfügbar macht. Das "DNS resolve" Skript, welches mit GeNiEnd2End 4.6 ausgeliefert wird, basiert auf einer solchen freien Bibliothek und ist in etwas mehr als zwanzig Zeilen Quellcode realisiert worden.

In dem "traceroute" Skript, welches auch mit GeNiEnd2End 4.6 mitgeliefert wird, wird hingegen auf das Betriebssystem eigene Traceroute Programm (tracert) zugegriffen. So lässt sich Programmierarbeit durch 3rd Party Anwendungen sparen, lediglich die Rückgabe des Programms muss ausgewertet werden.
Mit Application Light, lassen sich also in kürzester Zeit Testszenarien erstellen.

Messergebnisse in GeNiEnd2End Application

Dinge wie Website-Tests lassen sich nicht nur mit GeNiEnd2End Application sondern auch mit Application Light erstellen. Hier müssen aber Abstriche gemacht werden.

Zum einen wird bei Website Tests nur die Seite heruntergeladen und nicht wie bei GeNiEnd2End Application in einem Browser geöffnet. Dies hat zur Folge, dass zum Beispiel clientseitige Ereignisse, wie Javascript-Funktionen oder CSS-Renderzeiten nicht zum Tragen kommen und nicht in Gesamtzeit einfließen. Außerdem sind CNS-Zeiten für Application Light nicht verfügbar.

Die Sicht der Anwender auf eine Applikationsgeschwindigkeit wird oft nur als vage Aussage aufgenommen und somit nicht als Messwert akzeptiert. Aussagen wie z.B "es ist / war langsam" oder "es dauert/e ewig" sind oft an der Tagesordnung, aber auch nicht immer glaubwürdig oder nachweisbar.

Wenn nun also die nicht ganz so aussagekräftigen "Messwerte", in klare und zuverlässige Messwerte verwandelt werden können und dabei die Messdaten auch noch aufgeteilt werden können in "Client / Netzwerk / Server" ist das doch fantastisch, oder?

Wir haben schon viele Jahre Erfahrungen mit dem Thema Applikationsperformance und haben nicht nur bei Kunden eben die oben genannten Problembeschreibungen erhalten, sondern auch schon bei uns selbst. Aus diesem Grund überwachen wir selbst auch seit längerem die Applikationsperformance von z.B. Lotus Notes (IBM Notes) und unsere darauf aufbauenden Datenbanken.  

Anhand dessen möchte Ich Ihnen heute zeigen, wie Sie zu Messdaten kommen können, die Ihnen dabei helfen die Probleme aufzuzeigen und einzugrenzen.

Jede Messung, die den gleichen Ablauf wie ein Anwender durchführen soll, beginnt mit einer Klickstrecke:

 PDF Beispiel Klickstrecke

Jetzt benötigen wir einen  GeNiEnd2End Application Server und einen Client PC. Der Client PC sollte dieselbe Hardware / Software / Netzwerkanbindung und Beschränkungen wie andere Client PC haben.

Nun wird der ganze Ablauf der Klickstrecke mithilfe eines Skriptes (AutoIT oder Python) auf dem Client PC nachgebildet und dann in GeNiEnd2End als Skripting Test hochgeladen. Dieser Test wird dann in einem konfigurierten Intervall durchgeführt und die Messdaten werden mit Hilfe des GeNi Agenten, der auf dem Client PC installiert ist, an den Server gesendet.

 Konfiguration des Scripts in GeNiEnd2End

 Ablauf des Scripts als animiertes Gif

Sobald das Script erstellt (in diesem Fall ca. 4-6 Std. mit Tests) und in GeNiEnd2End eingeplant wurde, werden die Messdaten aufgezeichnet und zur Analyse bereitgestellt. Sie können auch Schwellwerte zu den einzelnen Transaktionen hinterlegen, so dass Sie dann einen Alarm bekommen, wenn dieser über- bzw. unterschritten wurde.

Auszug aus GeNiEnd2End 4.6 (Übersicht der Messdaten Lotus Notes Script)

Beispiel: Unterschied nach unseren Änderungen und 1 Jahres - Übersicht der Messdaten

      Legende: Blau ist die Clientzeit / Gelb die Netzwerkzeit / Rot die Serverzeit      

 

Unterschied der Messdaten Vor und Nach den Änderungen Unterschied der Messdaten Vor und Nach den Änderungen Unterschied der Messdaten Vor und Nach den Änderungen
 Transaktion Akte    Transaktion Searcher Open   Transaktion Kontakt

 Alle Transaktionen 1 Jahr

Wie man sieht, haben wir einige Änderungen durchgeführt, um die Zeiten zu verringern. Die Änderungen haben wir auch mit demselben Script in einer Testdatenbank zuvor erarbeitet bzw. überprüft.

Dass der Weg keine Einbahnstraße in Richtung "schneller" ist, sieht man an der Kontakt-Transaktion: Allerdings sind dort auch viele neue Funktionen eingeflossen.

(Akte von 1,6 Sek auf unter 1,0 Sek reduziert, Searcher Open von 6,4 Sek auf unter 4 Sekunden, Kontakt von 1 Sek auf 1,5 Sekunden erhöht und dann wieder auf 1,2 verringert) 

Leider können wir die Netzwerkzeit bei der Searcher Open Transaktion nicht beeinflussen, da diese durch die Funktion im IBM Notes Client entsteht, aber wir konnten den Client zumindest so konfigurieren, dass das Öffnen des Searchers parallel weiter läuft und der Anwender währenddessen schon arbeiten kann.

Der Pflegeaufwand für solch ein Script hängt natürlich davon ab, wie sehr sich Ihre Applikation ändert, bzw. ob viele Probleme auftreten (Fehlermeldungen usw.). Bei diesem Script waren es im letzten Jahr vielleicht 4-8 Stunden Pflegeaufwand, da wir sehr viel am Aussehen und am Umgang mit unseren Datenbanken geändert haben.

Von IBM Notes über Webseiten zu Citrix Applikationen, alles kann zur Erhebung von Messdaten genutzt werden. Fragen Sie uns doch einfach, wie wir Ihnen dabei behilflich sein können.

Natürlich können wir das Erstellen der Messungen / Analysieren oder Schulen, wie man Skripte erstellt, für Sie übernehmen:

 GeNiManage 
 GeNiEducate

In diesem Blog möchte ich einen Blick auf Paketverluste werfen, die üblicherweise Netzwerkprobleme bei der Performance der Applikationen darstellen. Warum ist also der Paketverlust solch ein Performance-Killer für die Applikation? Dies beruht vor allem auf der Art, wie TCP diese Paketverluste behandelt. Bestätigt innerhalb einer bestimmten Zeit (TCP-Timeout) der Empfänger die gesendeten Datenpakete nicht, so werden diese erneut vom Sender verschickt. Durch diese Timeouts können schwerwiegende Verzögerungen auftreten, da der Timeout-Wert sich bei jeder neuen Paketwiederholung verdoppelt.

Wir haben herausgefunden, dass viele IT-Administratoren der Meinung sind, ein Paketverlust-Wert von 1-2% sei sehr gering und sollte kaum Auswirkungen auf die Anwendungsperformance haben.
Leider hat bereits ein geringer Wert einen hohen Einfluss auf den TCP-Durchsatz, was wiederum die Applikationsperformance beeinträchtigt. Wir empfehlen bei einem Paketverlust-Wert von über 0,01% die Ursache zu ermitteln.
Der Aufwand, Paketverluste mit  GeNiEnd2End Network zu bestimmen, ist ein Klacks. Sie können entweder den kostenlosen Software-Endpunkt auf bereits vorhandene PC / Server installieren oder positionieren die kostengünstigen  GeNiJacks an die Abgrenzungspunkte.
GeNiEnd2End Network berichtet neben Paketverlust auch über One-Way-Latency, Jitter und andere wichtige Parameter der Netzwerkqualität.

GeNiEnd2End Network ist die perfekte Ergänzung für bereits bestehende, netzwerkbasierte APM-Lösungen wie SuperAgent von CA, Application Xpert von Opnet oder TruView von Fluke Networks. Es vereinfacht die Diagnose von Netzwerk Performance Problemen erheblich.
Mit GeNiEnd2End ist es eine Kleinigkeit zu beweisen, dass es "nicht das Netzwerk“ ist.

Lassen Sie mich also erklären, warum eine aktive endpunktbasierte Lösung wie GeNiEnd2End Network der beste „Gefährte“ für eine netzwerkbasierte APM-Lösung ist:
Innerhalb einer netzwerkbasierten APM Lösung wird der Paketverlust mit Hilfe von den Metriken Client- und Server-Retransmissions dargestellt. Jedoch kann durch diese beiden Metriken der Verursacher (Netzwerk, Client oder Server) und die Richtung (rückwärts, vorwärts) der Paketverluste nicht eindeutig bestimmt werden.

   


Bitte werfen Sie einen Blick auf die o.a. Bounce-Diagramme.

Mit GeNiEnd2End Network können Sie jedoch schnell bestimmen, ob das Netz die Paketverluste verursacht oder nicht.

Das Erfassen der Paketverluste ist für das Netzwerk-Team hinsichtlich der Diagnose von Performanceproblemen der Applikation und deren Ursache im Netzwerk der erste Schritt.

GeNiEnd2End Network rationalisiert den Workflow der Fehlerbehebung und ermöglicht es dem Netzwerk-Team, den Problembereich zu isolieren.

GeNiEnd2End Network – the real Troubleshooting tool for the Network Engineer!

Situation: Eine Anwendung braucht länger als regulär, um die Daten zu laden.

Reaktion: Die Aussage „das Netzwerk ist (schon wieder…) langsam.“

Aber ist es das wirklich? In den meisten Fällen ist das Netzwerk nicht schuld. Aber wie soll man das nachweisen? Sie als Netzwerkadministrator werden, wenn Sie darauf angesprochen werden, wahrscheinlich erst später angesprochen. Wenn Sie angesprochen werden, dann nach dem Muster: "Heute Morgen war das Netzwerk schon wieder langsam!" Präziser wird es wahrscheinlich nicht sein.

Was wäre, wenn man den Nutzern ein Tool an die Hand geben würde, mit dem der Nutzer selbst prüfen kann, ob das Netzwerk, zu dem Zeitpunkt zu dem es langsam gewesen sein soll, wirklich langsam war?

Hierfür gibt es FirstAid Multichoice.

Das FirstAid Tool spricht die API von GeNiEnd2End an. Sie konfigurieren was der Nutzer testen kann und zu welchen Endpunkten er dies darf.
Die Messung startet der Nutzer in 4 einfachen Schritten:

  1. Auswahl des Testtyps
  2. Auswahl des/der Endpunkte/s
  3. Eingabe eines optionalen Kommentars (Ticketnummer oder SAP langsam)
  4. Starten

 


Innerhalb von einer Minute bekommt der Nutzer eine Rückmeldung über die Verbindung. Sie bekommen eine eMail mit den Messergebnissen und sehen in GeNi2End2End wie die Messergebnisse sind.
 

 

Detaillierte Messergebnisse


Somit können Sie sich bereits während des Anrufes des Nutzers die Messwerte anschauen und müssen nicht erst selbstständig messen.

Für Sie als Netzwerkadministrator gibt es dazu noch FirstAid Remote. Hier können Sie zu den Einstellungen von FirstAid Multichoice zusätzlich auswählen, welcher Endpunkt als 1. Endpunkt der Messung genutzt werden soll. Alternativ können Sie hier auch einen eigenen Endpunkt eingeben.

Sollte FirstAid nicht genau das sein was Sie benötigen, so können Sie FirstAid anpassen. FirstAid ist Open Source. Den Quellcode können Sie auf Ihrem GeNiEnd2End Server finden.
Also: Verteilen Sie FirstAid, lassen Sie Ihre Nutzer messen und sparen Sie Zeit bei dem Finden von Problemen.

 

Ziel eines Kundenauftrages war es, eine Matrix zu erstellen, die die Erreichbarkeit von einer beliebigen Anzahl von Lokationen weltweit abbilden kann.
Da der Kunde schon die Lösung  GeNiEnd2End, die im Hause NETCOR entwickelt wird, verwendet, können die Messwerte aus der offengelegten Datenbank hierfür genutzt werden. GeNiEnd2End misst die Verfügbarkeit beliebiger Lokationen, speichert die Erreichbarkeit 24/7 in einer Datenbank und stellt diese in einer 24-Stunden-Übersicht dar.

Auszug aus GeNiEnd2End 4.6
(Farbige Markierungen deuten auf eine schlechte Verfügbarkeit hin)

Ziel war es, diese Daten in einer Matrix darzustellen, welche die aktuelle Verfügbarkeit pro Standort farbig darstellen soll.
Die Erweiterung "GeNiEnd2End Matrix" ermittelt einen Durchschnittswert des aktuellen Tages und vergleicht diesen mit dem aktuell gemessenen Wert. Kommt es zu Verschlechterungen zwischen dem Durchschnittswert und dem aktuellen Wert, so wird diese Lokation in der Matrix farbig hervorgehoben. Die gemessene Verschlechterung ist prozentual einstellbar und kann beispielsweise bei einem negativem Ergebnis von 5% gelb oder von 10% orangefarben dargestellt werden.

Die Ansicht zeigt alle Verfügbarkeiten auf einen Blick an, der Kunde kann somit schneller und effektiver arbeiten.

Der nächste WLAN-Standard steht vor der Tür und soll 2014 verabschiedet werden.

Dieser neue Standard heißt 802.11ac und verspricht unter anderem:

  • Höhere Geschwindigkeiten (Durchsatz + Kapazität)
  • Geringere Latenzzeit

Die ersten Geräte sind schon länger im Handel erhältlich,  AirMagnet WiFi Analyzer unterstützt bereits das Dekodieren von 802.11ac Paketen und  AirMagnet Survey kann bereits 802.11ac Messungen durchführen. 

Eine Kurzübersicht der Unterschiede von 802.11n zu 802.11ac:

  802.11n 802.11ac
Frequenzband 2.4GHz und 5GHz 5GHz
Kanalbreite 20 und 40MHz 20,40, 60, 80MHz (Option 160MHz)
Spatial Streams 1 bis 4 1 bis 8 (bis zu 4 pro Client)
Multiple User MIMO Nein Ja
Single stream max. client data rate 150Mb/s 433Mb/s (bei 80MHz-Kanälen)

Weitere Informationen (inklusive Whitepaper) und ein Webmeeting zum Thema 802.11ac können Sie sich bei Fluke anschauen:

 802.11ac Themenseite von Fluke

 

Oft werden wir um Empfehlungen für ein Tablet, ein Notebook oder einen WLAN-Adapter zum Messen mit   AirMagnet Produkten gebeten.
Die aus unseren Erfahrungen gewachsenen Empfehlungen möchten wir gerne mit Ihnen teilen. 

Im letzten Monat sind die neuen Versionen von  AirMagnet WiFi,  Survey,  Spectrum XT und  VoFi Analyzer erschienen, diese unterstützen Windows 8 als Betriebssystem. Somit gibt es einen frischen Wind in Sachen Tablets und eine größere Auswahl an verwendbaren Notebooks.

Folgende Tablets können wir empfehlen:

 
Unsere empfohlenen Systemanforderungen an ein Tablet oder Notebook können Sie dem folgenden PDF entnehmen.
 
Das Surface Pro wurde von Fluke mit dem Multi Adapter Kit getestet und funktioniert mit nur einem USB 3.0 Anschluss.
 
In Sachen WLAN-Adapter kann man aktuell nur den folgenden Adapter empfehlen, bzw. für Multi-Adapter Modus direkt den Kauf des entsprechenden Kits.
 
Die Multi-Adapter Kits für WiFi Analyzer & Survey unterscheiden sich lediglich durch die Anzahl der enthaltenen Adapter, können aber jeweils auch für die anderen AirMagnet Produkte genutzt werden. 
Die Preise für den USB-Adapter bzw. für die Multi-Adapter Kits können Sie gerne bei uns anfragen.
 
PS: Sollten Sie Probleme mit AirMagnet Survey unter Windows 8 haben, überprüfen Sie welches Grafikkartenmodell Sie haben. Sofern es sich um eine Intel HD 4000 Grafikkarte handelt, aktualisieren Sie bitte den Treiber über die Intel-Seite.

 

SPTA hat nichts mit den Tennisprofis aus der Schweiz zu tun; Im Gegenteil es steht für Structured Performance Troubleshooting Approach. Es ist zwar keine exakte Wissenschaft, aber wenn man es anwendet, verbessert man sich nicht nur kontinuierlich, sondern löst Performance Probleme sogar schneller. SPTA ist eine Zusammenfassung der Best Practices die  GeNiEnd2End Kunden angewendet haben, um Personen, Prozesse und Tools zu koordinieren, um ein optimales Performance Troubleshooting zu erzielen. Diese Unternehmen erwarten bedeutende Verbesserungen im MTTR im Hinblick auf performancerelevante Probleme.

Stufe
Ziel
1st level
2nd level
3rd level
1
Verifizieren von End-to-End Qualität der Kommunikationswege (OSI layer 4)
x
x
 
2
Verifizieren von End-to-End Qualität mittels gescripteten Usertransaktionen (OSI layer 7)
 
x
x
3
Multi-tier Performanceanalyse mit Packet Tracing (AdHoc & 24/7)
 
 
x

SPTA besteht aus einem 3 Stufen Troubleshooting Ansatz, der auf  GeNiEnd2End basiert und bietet die Möglichkeit der Integration in allen Support Levels der IT-Support Organisation. Jeder einzelne Support Level kann jetzt den Troubleshooting Prozess unterstützen. Die Grundlage auf der dieser Ansatz basiert, ist die Idee, dass mit einer präzisen Information für die richtige Person zur richtigen Zeit der Troubleshooting Prozess rationalisiert wird.

Zum Beispiel, der Service Desk hat somit die Möglichkeit den Supportprozess zu unterstützen, in dem er aus Sicht des Anwenders objektive End-to-End Performance Informationen erhält. Mit dieser fundierten Information kann das Ticket vom Service Desk bewertet werden und fundiert an den zuständigen IT-Spezialisten weitergeleitet werden. Dies wiederum vermindert die Bearbeitungszeit der einzelnen Tickets.

Wenn Sie interessiert sind oder SPTA mal testen wollen, fragen Sie uns einfach.

Bitte nicht weglaufen und in Deckung gehen. Kein Grund zur Panik. Im Gegenteil. Das Land der Kängurus, der Didgeridoos und der unzähligen giftigen Tiere hat etwas Neues. Den ersten Reseller für  GeNiEnd2End auf der Südhalbkugel! Glückwunsch, PlexNet Pty Ltd! Ob PlexNet GeNiEnd2End vor Ort mit Vegemite ausliefert, ist allerdings nicht bekannt, soll uns aber recht sein.

In der Vergangenheit stand bei Neuvorstellungen von Produkten immer die Liste der technischen Highlights im Vordergrund. Nach dem Prinzip „schneller, höher, weiter“ sollte die Menge der darstellbaren Parameter potentielle Kunden von der Qualität der Geräte überzeugen.

Doch wer als IT-Verantwortlicher möchte bzw. kann aus dieser Informationsflut letztendlich die wichtigen Informationen herausfiltern und so interpretieren, dass am Ende die Lösung des Problems steht?
Dank Vorreitern, wie z.B. Apple, die u.A. durch den Fokus auf die wichtigsten Details Marktführer im Consumer-Bereich geworden sind, achten nun auch Hersteller der IT-Messtechnik verstärkt auf die Übersichtlichkeit der Darstellung von Ergebnissen komplexer Analyseverfahren.

Das ist sicherlich sinnvoll, denn es interessiert den IT-Verantwortlichen im ersten Moment nur, ob die für den IT-Betrieb aus Anwendersicht relevanten Komponenten in gewünschter Zeit verfügbar sind. Erst dann, wenn Probleme aufgezeigt werden, möchte er sich mit den Details, die zu dem Problem geführt haben, detaillierter auseinander setzen.

Ein gutes Beispiel für die Umsetzung der vereinfachten Darstellung in der IT-Analyse sind das neue  Fluke OneTouch AT oder  GeNiEnd2End.

Wenn Sie Indiana Jones sind, haben Sie jetzt ein Problem. Wenn nicht, dann freuen Sie sich! 
GeNiEnd2End 4.6 unterstützt als weitere Applikations-Skriptsprache Python. Jetzt können Sie sich losgelöst von AutoIT ordentlich austoben und nahezu alles scripten, was Ihnen in den Sinn kommt. Vorausgesetzt, Sie wissen mit Python umzugehen. Wenn nicht, dann helfen wir Ihnen gern bei der Umsetzung Ihrer Ideen. Sie möchten einen Datenbankzugriff messen? Einen Traceroute auswerten und die dort gesammelten Daten als Messwerte erheben?
Es gibt fast nichts, was Python nicht kann. Und es wird noch besser: Die GeNiJacks können endlich "ordentlich" mitmessen und damit ihr tristes Dasein als einfache Endpunkte aufgeben, denn auf unseren  GeNiJacks läuft auch Python! Da möchte man doch wirklich zum Schlangenliebhaber werden, oder?

Aus der Sicht der IT gibt es viel Skepsis gegenüber dem Hype um BYOD (Bring Your Own Device). Und ob sich diese Organisationsrichtlinie sich durchsetzen wird, ist nicht sicher. In letzter Zeit hört man immer häufiger von PUOCE (Private Use of Company Equipment) – dem umgekehrten Weg, die Mitarbeiter bekommen ein Gerät von der Firma gestellt, welches auch privat genutzt werden kann.

Unabhängig davon, welcher Hype sich jetzt durchsetzen wird, es werden neue Arbeitsmodelle entstehen, bei denen die Leistung und nicht Anwesenheit im Mittelpunkt steht. Das Verwischen der Grenzen zwischen Berufs- und Privatleben ist nicht aufzuhalten. Hierdurch ergeben sich neue Chancen und Risiken für die Unternehmen. Ganz oben auf der Liste mit den Risiken steht das Thema Netzwerksicherheit und der Schutz geschäftskritischer und vertraulicher Daten.

Um die Netzwerksicherheit zu wahren, ist es deshalb äußerst wichtig, dass BOYD und Co. auf die Netzwerkzonen begrenzt wird, in denen Sicherheitsrichtlinien anwendbar sind. Im Falle einer Sicherheitsverletzung ist die IT darüber zu alarmieren. 

Um sicherzustellen, dass Endgeräten die Network Access Control Systeme oder andere Sicherheitsmechanismen nicht umgehen, sollte in Echtzeit aufgezeichnet werden, welche Endgeräten mit dem Netzwerk verbunden sind und - noch wichtiger - historisch dokumentiert werden, wo sie angeschlossen sind/waren.

An dieser Stelle wäre es wichtig und wertvoll ein System einzuführen, das in Echtzeit Sicherheitsverletzung, wie z.B. neue Geräte, ein Gerät welches sich in einer nicht-autorisierten Zone befindet oder unzulässige Netzwerkänderungen, automatisch meldet. Haben wir Ihr Interesse geweckt und wollen Sie mehr über ein solches System erfahren? Mehr Informationen dazu gibt es beim Security Auditor von Rebasoft.

In den letzten Jahren ist in der IT viel „optimiert“ worden. Konsolidierungen von Rechenzentren, Outsourcing und SAAS waren u.a. dabei die Schlagworte.

In diesem Zusammenhang ist in den Unternehmen sehr häufig hauseigene Kompetenz für die Sicherstellung des Betriebes der Business-kritischen Applikationen verloren gegangen. Insbesondere sporadische Probleme mit der Applikationsperformance stellen heute alle Beteiligten vor eine große Herausforderung. Die Überwachungssysteme für den jeweiligen Zuständigkeitsbereich stehen auf „grün“, doch die Anwender klagen trotzdem über langsame Anwendungen. Je nach Wichtigkeit der Anwendung, oder häufig auch der Hierarchie der Betroffenen im Unternehmen, steigt die Dringlichkeit das Problem zu beheben.

In dieser Phase beginnt dann nicht selten das sogenannte „Finger-Pointing“. Niemand möchte den „Schwarzen-Peter“ auf dem Tisch haben und versucht seine Unschuld, mit den ihm verfügbaren Informationen zu belegen. Aus dieser Situation heraus entstehen nicht selten langwierige, aufreibende „Grabenkämpfe“, in denen sich die Fronten verhärten.

In dieser Situation kann die  Unterstützung eines externen, unabhängigen „Dritten“ mehr als hilfreich sein. Unvorbelastet durch etwaige Vorgeschichten oder die Rücksichtnahme auf Empfindlichkeiten der Beteiligten kann das Problem analysiert und die Fehlerquelle zugeordnet werden. Zusätzlicher Vorteil: Ein  unabhängiger Dritter ist nach der Analyse wieder aus dem Haus und sitzt nicht beim nächsten Quartalsmeeting wieder mit am Tisch. Wichtig dabei ist, dass auf das Fehlerszenario abgestimmte Analyselösungen eingesetzt werden.

Mit dem neuen  GeNiJack plus gibt es eine neue Variante von unseren „warmen Semmeln“. Dieser GeNiJack plus bietet mit den 2 Ethernet-Ports und WLAN, neue Einsatzmöglichkeiten wie z.B. ein ferngesteuertes Packet-Tracing an einem Spiegelport. In Kombination mit der web-basierenden  GeNiEnd2End MultiTrace Software können jetzt mehrere GeNiJacks zentral für eine Multi-Segment-Datenaufzeichnung konfiguriert werden. Die Trace-Files werden auf der enthaltenen SD-Karte abgelegt und können anschließend bei Bedarf für eine Multi-Trace-Analyse mit z.B.  ClearSight Analyzer von Fluke Networks analysiert werden. Mit dem GeNiJack plus gibt es jetzt eine preiswerte Detailanalyse für die Paketanalyse in Remote Lokationen und ergänzt hiermit die integrierte Ende-zu-Ende/QoS Funktionalität.

Beim TCP-Protokoll stoßen Applikation und Netzwerk aufeinander und die Interaktion zwischen den beiden ermöglicht es uns die elementaren Fragen um die Applikationsperformance zu beantworten.

 
- Wie gut versorgt das Netzwerk die Applikation? und
- Wie gut nutzt die Applikation das Netzwerk?
 
Auch wenn die TCP-Mechanismen nicht gerade einfach zu verstehen sind (siehe für weitere Details den  Wiki-Eintrag zum TCP-Protokoll), liefert das TCP-Protokoll einige interessante Metriken um die Performance bzw. den Verursacher – z.B. ein ineffizientes Netz und/oder „untermotorisierte“ Server - zu ermitteln.  Mit den TCP-Metriken Retransmission, Retransmission Delay, Round Trip und Data Transfer Time kann die Qualität der Netzwerkleistung charakterisiert werden. Wenngleich TCP ein Netzwerkprotokoll ist kann es mit den richtigen Analysetools auch Probleme innerhalb eines Servers aufzeigen. Metriken wie zum Beispiel Server Response Time,  Zero Window und Connection Denied/Aborted visualisieren die interne Serverleistung. Diese TCP-Metriken - kombiniert mit Metriken auf der Applikationsebene wie z.B. der Anzahl der Transaktionen oder der Client Response Time - sind unentbehrlich für eine schnelle systematische Fehlersuche bei Performanceproblemen. Die Application Performance Suite (APS) von Securactive liefert diese Informationen passiv ohne eine Mehrbelastung der Systeme oder des Netzwerkes. Hier können Sie eine  Testversion der Securactive Virtual Appliance downloaden
Höhere Netzwerklaufzeiten die nach einem Umzug eines Data Centers entstehen können, sind nicht zu unterschätzen. Wird bei der Planung die geographische Entfernung nach dem Umzug zwischen den Anwendern und der Applikation nicht ausreichend berücksichtigt, kann dieses zu einem Misserfolg führen und letztendlich teuer werden.
 
Die Nutzung eines Netzwerkemulators zur Risikominimierung ist mittlerweile ein gängiger Projektschritt, um mögliche Applikationsperformanceprobleme, die durch höhere Latenzzeiten entstehen, aufzuzeigen. Allerdings scheiden sich die IT-Verantwortlichen an der Frage: Soll der Netzwerkemulator im Live-Betrieb zwischen den Anwendern und Applikationen eingeschleift, oder soll klassisch in einem Testlabor eine virtuelle Testumgebung für die betroffenen Anwendungen aufgebaut werden?
 
Der Einsatz eines Netzwerkemulators im Live-Betrieb ist vergleichbar mit einer Operation am offenen Herzen. Im vergangenen Jahrhundert waren solche Operationen spektakulär und risikoreich, heute gehören Sie zu den Routinearbeiten und verlaufen ohne Probleme.
 
So ist es auch mit den Netzwerkemulatoren, was früher undenkbar war ist mittlerweile ohne Weiteres möglich.
 
Heute ist ein Netzwerkemulator ein hochperformanter und hochverfügbarer Router/Switch, der problemlos im Live-Betrieb integriert werden kann, um z.B. eine realistische Simulation eines Rechenzentrumumzugs durchzuführen. Die Latenzzeit kann in kleinen Schritten erhöht oder die Bandbreite zusätzlich reduziert werden. Nach jeder Änderung können die Erfahrungswerte der Anwender beobachtet werden und bei einer Anhäufung von Performancebeschwerden kann sofort die letzte Änderung widerrufen werden.
 
Diese Methode ist  bei Weitem vorteilhafter im Vergleich zu Performance-Simulationen mittels WAN-Emulator in einem Testlabor.
 
Im White Paper  „Application Performance Testing for Data Centre Relocation“ der Firma JAR Technologies können die Pros & Cons ausführlich eingesehen werden.

Auch in diesem Herbst veranstaltet NETCOR seine Info-Days! Am 17.10.2012, 06.11.2012 und 07.11.2012 ist es wieder so weit: Hamburg, Stuttgart und Düsseldorf werden angesteuert Thematisch geht es auch in diesem Jahr um das Thema IT-Performance.

Zu den folgenden Themen gibt es praxisnahe Vorträge:

  • Effektive Netzwerk- und Anwendungsanalyse in 1 und 10G-Netzwerken
  • Security Information & Event Management (SIEM)
  • Datendurchsatz vs. Latenzzeit und Paketverlust

Zwei Themen werden besonders griffig anhand von Projektberichten behandelt:

  • Analyse sporadischer Performanceprobleme in Triple-Play-Netzwerken
  • WLAN-Troubleshooting in 802.11 a/b/g/n basierenden Netzwerken

 

Natürlich gibt es auch eine ausführliche Agenda.

Veranstaltungsorte sind der Flughafen Hamburg-Fuhlsbüttel, Stuttgart und Düsseldorf International. Düsseldorf ist tatsächlich ziemlich international, Stuttgart und Hamburg nicht so stark, dafür ist letzterer aber laut Skytrax der „Best Regional Airport Europe“ 2011.

Bereits im Jahr 2010 waren die NETCOR Info-Days auf einem Flughafen zu Gast. Damals hatten wir in Stuttgart allerdings nicht ganz so viel Glück. Durch die Aschewolke vom Vulkan Eyjafjallajökull (gar nicht so leicht auszusprechen...) haben wir während der Flughafentour (gibt es dieses Mal auch!) nur ein einziges sich bewegendes Flugzeug gesehen. Dafür ging es jedoch in die Flughafenfeuerwehr und wir sind in die Halle der Gepäcksortieranlage gekommen.

Statistisch ist es unwahrscheinlich, dass bei den NETCOR Info-Days 2012 erneut ein Vulkan den europäischen Flugverkehr lahmlegt und das Kabinenpersonal der Lufthansa sollte sich auch mit seinem Arbeitgeber geeignet haben. Damit steht einer jeweils sehr spannenden Tour, die die Vorträge abrundet, nichts im Wege!

Unsere Lehrlinge Patrick (IT-Systemkaufmann) und Jonas (Fachinformatiker Anwendungsentwicklung) haben ihre Ausbildung erfolgreich abgeschlossen.

Erfolgreiche Lehrlinge


Im Namen von NETCOR gratulieren wir ihnen herzlich und freuen uns auf eine weiterhin gute Zusammenarbeit mit ihnen!

Wieder wurden 50 Stück von einem Kunden bestellt. Auch wenn das nach Fließbandarbeit aussieht, werden alle GeNiJacks ausgepackt, emsig bespielt, beklebt und wieder eingepackt. Fast so wie Räuchermännchen aus dem Erzgebirge.

GeNiJacks

Ob unsere GeNiJacks wie warme Semmeln duften und schmecken, müssen Sie allerdings selbst herausfinden.

Nach langer Zeit und in liebevoller Handarbeit, einem Katana von Hattori Hanzō gleich, entsteigt GeNiEnd2End 4.5 dem noch heißen (Software-)Schmiedeofen. Allerdings kann das neue GeNiEnd2End 4.5 mehr als ein tumbes Schwert. Es steht nicht in einer schicken Vitrine herum, sondern es arbeitet für Sie.

Es führt für Sie automatisierte QoS-Prüfungen aus. Sie sehen sofort, wenn Ihre QoS-Pakete nicht da ankommen, wo sie sollen, da QoS-Abweichungen nun pair-basiert alarmiert werden. Außerdem lässt sich das QoS-Testing mit einem einzigen Klick aktivieren.

Die neuen GeNiJacks können jetzt Packet-Tracing durchführen. Das ermöglicht es Ihnen, GeNiJacks mit ins QoS-Testing einzubeziehen. Versuchen Sie das mal mit einem Schwert!

Die Möglichkeit benutzerdefinierter Einheiten öffnet Ihnen eine neue Welt der Messwerte. Sie können mit GeNiEnd2End 4.5 alle möglichen Werte einfügen und sogar umrechnen. Erstellen Sie sich doch mal Application-Tests, die Wetterdaten oder Spritpreise auswerten. Sie können jede erdenkliche Datenquelle anzapfen und die gewonnenen Daten in GeNiEnd2End 4.5 anzeigen.

Zusätzlich kommen weitere größere und kleinere Änderungen hinzu. Es wurde einiges am Web-GUI geändert, einige Arbeitsabläufe wurden verbessert oder verkürzt, der GeNiEnd2End Agent läuft nun im System-Tray, falls er als GUI-Version installiert wurde (endlich keine DOS-BOX mehr). Auch unter der Haube hat sich einiges getan. Stabilität und Geschwindigkeit wurden sowohl serverseitig als auch auf dem Agenten erhöht.

Alle Änderungen können Sie in den Release-Notes nachlesen. Sie möchten sich selbst überzeugen? Dann fragen Sie uns nach einer Teststellung oder kontaktieren Sie uns zur Unterstützung für ein Update Ihrer vorhandenen GeNiEnd2End-Installation.

Als ich mich vor 25 Jahren für eine Laufbahn in der IT-Branche entschieden habe, stand bei den Netzwerkverantwortlichen, wie auch heute noch, die Verfügbarkeit und Performance des Netzes im Fokus. Allerdings waren die damaligen X.25 Weitverkehrsnetze oder LANs auf Basis von Koaxialkabel im Vergleich zu den heutigen modernen Netzwerken fehleranfälliger. Deshalb war es seinerzeit wichtig mit den Netzwerkmanagementsystemen die Verfügbarkeit der Netzwerkkomponenten respektive –Ports zu dokumentieren. Das war die Zeit der Netzwerktopologiekarten, die mittels einer Ampeldarstellung die Verfügbarkeit visualisierten. Von den heute üblichen Verfügbarkeitszahlen konnte man damals nur träumen.

Mittlerweile sind hochverfügbare Netze Stand der Technik und werden sogar für Sprach- und Videodienste genutzt. Das war in jenen Tagen unvorstellbar und dieser technische Entwicklungsverlauf hat mit dafür gesorgt, dass das Telefonieren ins Ausland preiswert geworden ist.

Netzwerkausfälle gehören heutzutage zu den Ausnahmen. Performance hingegen ist durch die zunehmend komplexere IT-Landschaft für viele Netzwerkverantwortliche die neue Plage geworden. Dabei ist für mich wirklich unverständlich, dass die Netzwerkverantwortlichen so leidensfähig sind. Solange ich schon im IT-Geschäft unterwegs bin, bekomme ich zu hören, dass bei Performanceproblemen immer die Netzwerker schuld sind. Der technische Fortschritt ist bei den Netzwerkspezialisten angekommen, aber die gedankliche Weiterentwicklung - was die Performance betrifft -leider noch nicht. Mittels klassischen Netzwerkmanagementsystemen wird die Netzwerkleistung dokumentiert, Performancewerte der Netzwerkkomponenten und –Ports werden mittels SNMP abgefragt. Eventuell wird mittels Netflow und/oder Paketanalyse über den möglichen Lastverursacher noch eine Detailanalyse geliefert. Leider wird hier die Performance, die beim Anwender ankommt, außer Acht gelassen. Deshalb melden auch die Anwender die Performanceengpässe und nicht die Managementsysteme.

Es überrascht mich immer noch, wenn ich von Netzwerkadministratoren höre, dass sie mit den klassischen Management- und Analysentools entweder mit sehr viel Aufwand den/die Performanceverursacher ermittelt haben oder sogar aufgegeben haben. Wobei es heutzutage effizientere Ansätze gibt Performancebeschwerden zu beseitigen.

Vor Kurzem waren wir bei einem Kunden, der mit dauerhaften Performanceproblemen in einigen Filialen zu kämpfen hatte. Auch hier wurde bereits sehr viel Zeit investiert - aber ohne nennbaren Erfolg. Die vorhandenen Monitoring-Tools registrierten keine Auffälligkeiten, trotzdem beschwerten sich die Anwender in den Außenstellen über lange Antwortzeiten.

Als wir den Netzwerkverantwortlichen überzeugen konnten, dass es heutzutage einfachere Wege zur Erfassung der vorhandenen Netzwerkleistung aus Sicht des Anwenders gibt, waren sie bereit mittels GeNiEnd2End Network die Netzwerkqualität Ende-zu-Ende zu messen. Innerhalb kürzester Zeit konnte nachgewiesen werden, dass es auf der Weitverkehrsverbindung zu einigen Filialen erhebliche Paketverluste gab. Eigentlich sollte dieser schnelle Erfolg die Beteiligten erfreuen. Indessen gab es kritische Stimmen beim Kunden, die das Messprinzip in Frage gestellt haben. Nach dem Motto: So etwas „einfaches“ kann keine verlässlichen Messwerte liefern. Nachdem aber ein „Performancespezialist“ von NETCOR mittels der integrierten Packet-Trace-Funktion glaubhaft die Messergebnisse belegen konnte, akzeptierte der Kunde, dass die WAN-Verkehrsverbindungen der Verursacher, des Performanceproblems war. Das war natürlich nicht zur Freude des Netzwerkproviders.

Dieses Beispiel zeigt, dass eine Ende-zu-Ende Messlösung die vorhandenen Monitoring-Tools wirkungsvoll ergänzen kann. Diese klassischen Tools - die unverzichtbar für das Netzmanagement sind - liefern die üblichen Leistungswerte, wie z.B. die genutzte Bandbreite. Wobei eine hohe Netzwerkauslastung nicht automatisch mit langen Antwortzeiten aus Sicht des Anwenders gleichzusetzen ist. Im Umkehrschluss kann es trotz geringer Auslastung lange Antwortzeiten geben. Bandbreitenunabhängig kann mit GeNiEnd2End Network innerhalb einer Minute die Ende-zu-Ende-Leistung des Netzes bewertet werden.


Deshalb, lieber Netzwerker, tue dir selber einen gefallen und gehe neue Wege mit Ende-zu-Ende Performance-Tools. Oder wie die Chinesen sagen: Besser auf neuen Wegen etwas stolpern als auf alten Pfaden auf der Stelle treten!

Qualitätssicherung, Transparenz, Endanwenderzufriedenheit. Das sind Anforderungen, deren Umsetzung im Unternehmen ohne eine Investition in die Mess- und Monitoring-Lösungen nicht realisierbar sind. Ist der Entschluss erst einmal gefasst, ein Projekt in diese Richtung zu starten, sieht sich der Projektverantwortliche bei seiner Recherche einer Vielzahl von Produkten und Anbietern gegenüber. Anhand der über das Internet zur Verfügung gestellten Informationen ist es aber kaum möglich eine objektive Bewertung der vorgestellten Lösungen vorzunehmen.

Auf dem Datenblatt können die Produkte eh fast alles und mit Schlagworten, wie „End-User-Perspektive“ oder „Ende-zu-Ende Performance Monitoring“ wird vom Marketing des Herstellers selten gegeizt. Die Grenzen bzw. Schwächen eines Produktes nennt logischerweise keiner. Aber gerade diese Informationen sind für eine Kaufentscheidung letztendlich neben dem Preis ausschlaggebend.

An dieser Stelle ist eine herstellerübergreifende, objektive Beratung wichtig und wertvoll, um mit möglichst geringem Zeitaufwand eine Art Vorselektion zu treffen, um dann zu entscheiden, in welche Lösungen weitere Zeit, z.B. in eine Teststellung, investiert wird.

Was wie ein Hollywood-Blockbuster klingt entpuppte sich bei der letzten Kundenmessung als echte Herausforderung beim Applicationmonitoring mit GeNiEnd2End Application.
Haben Sie schon einmal versucht, eine Applikation, die in JAVA geschrieben ist über Citrix zu messen? Man geht voller Tatendrang zum Scripting über und steht plötzlich vor Applikationen, die nichts "mitteilen". Man kann weder auf Fenstertitel, noch auf Fensterinhalte prüfen, keine Buttons oder Texte erkennen.

Ein Mensch kann natürlich schon damit arbeiten, da er ja lesen und die entsprechenden Aktionen ausführen kann. Ein Robot-Script zur Anwendungsüberwachung hat es da schon schwerer. Man könnte zwar den geheimnisvollen Fenstern mit OCR-Software zuleibe rücken, aber das ist sicherlich viel zu aufwendig. Der bisherige Weg führte über aufwendige Pixel-Checksummen, die allerdings extrem starr waren und bei jeder Änderung der Applikation neu gebildet werden mussten. 

Glücklicherweise hatten die Kollegen bei NETCOR kurz zuvor den  ScreenShotHelper entwickelt, der es mir ermöglichte, Bildschirmausschnitte zu "fotografieren" und auf diese Ausschnitte zu prüfen. Mit wenigen Klicks konnte ich den gesuchten Bildschirmausschnitt markieren und sowohl als Messpunkt als auch als Klickziel definieren. Egal, wo sich der Ausschnitt befindet. Selbt bei Änderungen in der Applikation!
Seit dem gibt es bei NETCOR keinen großen Arbeitsaufwand bei "geheimnisvollen Fenstern" mehr. Alle mitteilungskargen Applikationen, Fenster oder Fensterinhalte wie zum Beispiel FLASH-Elemente im Browser, CITRIX-Fenster, TELNET-Applikationen, JAVA-Applikationen oder Remote- Desktop-Fenster stehen nun auf der "Gar-Kein-Problem"-Liste.

Wieder ist eine  Dienstleistung abgeschlossen. Das Problem wurde gefunden und der Kunde ist glücklich. Für den Kunden war es ein längerer Leidensweg, da die Probleme schon eine geraume Weile zwischen dem Lieferanten der Software, dem Server Betreiber, den Anwendungsbetreuern und den Netzwerkverantwortlichen verschoben wurde. Da die Umgebung auch keine simple Client zu "Single Server" Anwendung war, sondern deutlich komplexer, wählten wir den Weg des Ausschlussverfahrens. Komplex daran war: ESX Server auf 2 Blade Systemen, mit jeweils 2 virtuellen Servern und mehreren einzelnen verteilten Anwendungsdiensten. Das Ganze in einem MS Cluster, der aus VM Sicht und MS Clustersicht beliebig verteilt werden konnte. Natürlich alles doppelt redundant angeschlossen.

Wir setzten  GeNiEnd2End Application ein, um die sporadischen von den Anwendern beschriebenen Probleme sichtbar zu machen. Des Weiteren nutzen wir  GeNiEnd2End Network, um die Netzwerk Infrastruktur aus Sicht der Ende-zu-Ende Qualität zu betrachten.

Wie meistens üblich, ist es selten ein einziges großes Problem, sondern es sind viele kleine Probleme, die ein Problem groß werden lassen.

So stellte sich heraus, dass die Anwendung in der Tat sporadisch deutlich längere Transaktionszeiten aufwies. Aber auch das Netzwerk war nicht fehlerfrei. Die zentrale WAN Strecke wies Paketverluste auf. Außerdem kam die gemessene Anwendungstransaktion ins Stocken, weil lokale sowie remote angebundene Arbeitsplätze durch nur 1-2 verlorene Pakete statt einer Sekunde 2,5 Sekunden brauchten.

Die WAN Strecke wurde durch neue Router getuned, was zu einer deutlichen Verbesserung der nutzbaren Bandbreite, aber auch zum Wegfall aller Paketverluste führte.

Um die Ursache und den Ort der Paketverluste im LAN weiter einzuschränken wurde  GeNiEnd2End Multitrace eingesetzt. Damit war es nun sehr einfach möglich eine 3 Punkt Zangenmessung auszuführen und eine Problem-Transaktion zu untersuchen. Die Zangenmessung wurde auf dem VM Gast, am Serverswitch via SPAN und am Client aufgesetzt. Die Untersuchung ergab, dass die Pakete zwischen Serverswitch und VM Gast verloren gingen.

Diese Verluste wurden auch durch die Messung mit GeNiEnd2End Network bestätigt. Hier waren ebenfalls Paketverluste über den ganzen Zeitraum der Messung zwischen Serverswitch und vServer messbar.

Es folgten nun einige Versuche der Serverleute das Problem weiter einzugrenzen. Die Kontrolle oblag jetzt nur noch  GeNiEnd2End Network und  GeNiEnd2End Application – durch diese Tools erhielten wir eine Analyse mit nur minimalen Aufwand im einstelligen Minutenbereich! Alle Änderungen, z.B. vMotion nutzen, um das andere Blade zu testen oder Switch innerhalb des MS Clusters, brachten leider keinen Erfolg.

Letztendlich gelang eine Besserung durch den Tausch der virtuellen Netzwerkkarte innerhalb des VM Gastes.

Die Messungen zeigten nun, dass durch diese Änderung keine Verluste von Paketen innerhalb der VM mehr auftraten.

Somit wurde dieses Problem mit vergleichbar wenig Aufwand identifiziert und schlussendlich in der richtigen Abteilung behoben.

Sie kennen es sicherlich: die WLAN-Verbindung reißt ab und meist weiß man nicht, warum dies gerade geschehen ist.
Schlechter Empfang? Roaming von AP zu AP? Stört etwas die WLAN-Verbindung?

Manches kann man von Haus aus leicht erkennen, wie z.B schlechten Empfang, anderes aber nicht, wie Störquellen (WLAN-fremde Geräte), die das Signal beeinträchtigen.
Wie findet man nun also heraus, was gerade das WLAN-Signal beeinträchtigt und wo es sich befindet?

Das Tool AirMagnet Spectrum XT zeigt Störquellen auf, identifiziert sie und bietet Ihnen die Möglichkeit diese zu lokalisieren. Natürlich in allen WLAN-Frequenzbereichen und mit Messadapter auf USB-Basis. Zur Darstellung der Auswirkungen auf die WLAN-Umgebung gibt es integrierte WLAN Analyse Charts.

Die Identifikation von Geräten geht von Bluetooth bis Zigbee und es ist möglich, eigene Signalidentifikationen zu hinterlegen.

Sofern Sie selber kein Know-How zum Thema Spectrum Analyse aufbauen wollen oder punktuell Unterstützung beim Lösen von WLAN-Problemen benötigen, stehen wir Ihnen mit Dienstleistungen und Schulungen zur Seite.

 

Am 27.09. und 29.09. ist es wieder so weit: NETCOR veranstaltet seine Info-Days! Dieses Mal gastieren wir im Audi Forum Neckarsulm, in Hamburg sind wir im Madison Hotel und im Miniatur Wunderland.

Thematisch steht das Thema IT-Performance im Vordergrund:

  • WLAN-Troubleshooting in 802.11 a/b/g/n basierenden Netzwerken
  • Portmultiplikatoren für Analyse- und Monitoring-Systeme
  • Lokalisieren von Performanceproblemen in VoIP- und Datenanwendungen
  • Netzwerk- und Applikationsperformanceanalyse in 1 und 10G-Netzwerken
  • Analyse sporadischer Performanceprobleme in virtuellen Umgebungen

Natürlich gibt es auch eine ausführliche Agenda. Das Rahmenprogramm ist ziemlich spannend: In Neckarsulm schauen wir uns die Fertigung des Audi R8 an. Dieser beeindruckende Sportwagen verdreht mir bereits auf der Straße den Kopf – auf den Info Days kann aber jeder Teilnehmer dem Wagen ganz, ganz nahe kommen und aus der Nähe schmachtend anschauen. Sollten Sie dabei verliebt seufzen, keine Sorge, wir erzählen absolut niemandem von Ihren Gefühlen für dieses Automobil.

Beim Miniatur Wunderland Hamburg gibt es eine Führung. Anders als gewöhnlich wird nicht die Anlage aus Besuchersicht gezeigt, nein, es gibt eine neue Sichtweise: Wir schauen uns die Technik an, die hinter der sehr detaillierten Nachbildung zahlreicher Landschaften, Städte und Infrastrukturen steckt. Jeder, der sich ein bisschen für Details und clevere Lösungen begeistern kann, wird jede Menge Spaß haben.

Immer komplexer werdende Infrastrukturen mit zentral gehosteten Anwendungen machen die Suche nach evtl. Performanceengpässen zu einer zeitintensiven Aufgabe, die meist dann notwendig wird, wenn aufgrund der aktuellen Projektlage eigentlich eh keine Zeit dafür ist.

Gerade die Netzwerkverantwortlichen sind dabei in erster Linie gefordert. Die Aussage „Das Netzwerk ist mal wieder langsam!“ hat sich in den Köpfen der Anwender eingebrannt. Objektiv betrachtet gab es in den vergangenen Jahren eine eindeutige Verlagerung der Problemverursacher. Doch der Mensch bleibt gern bei dem, was ihm vertraut ist. Also ist eben erst einmal das Netzwerk schuld, bis das Gegenteil bewiesen wurde.

Auf der Suche nach möglichen Fehlerquellen bedient sich der Netzwerker typischer Weise SNMP- oder NetFlow Monitoring-Lösungen. Doch muss dabei vorab erst einmal verifiziert werden, welchen “Weg“ die Anwendung nimmt, was nicht immer einfach ist. Zudem muss ein Port mit hoher Last nicht gleich der Auslöser für hohe Antwortzeiten sein.

Auch zeitaufwendige Protokollanalyse ist ein häufig gewähltes Mittel, um den Fehler aufzudecken oder zumindest die eigene „Unschuld“ am Problem nachzuweisen. Wer sich damit schon einmal länger beschäftigt hat, weiß wie zeitintensiv das ist. Umso ärgerlicher ist es dann, wenn sich dabei herausstellt, dass das Problem gar nicht im Netz liegt!

Aus diesem Umstand heraus implementieren mehr und mehr Netzwerkverantwortliche eine Lösung, die die Performance der Infrastruktur 24x7 aus Sicht der Anwender misst und dokumentiert. Mit dem richtigen Tool kann dann innerhalb von wenigen Minuten be- oder wiederlegt werden, dass das Problem in der Infrastruktur liegt oder nicht. Eine schnell zu implementierende und bezahlbare Lösung dafür ist zum Beispiel GeNiEnd2End-Network.

Packets, Packets und noch einmal Packets. Alles dreht sich bei der nChronos-Software von Colasoft um die verteilte Langzeitdatenspeicherung von Datenpaketen für die forensische Netzwerkanalyse.

Über einen bewährten Workflow können nachträglich die gesammelten Datenpakete für die Identifizierung von Fehlerquellen mittels des integrierten Paketanalyzers oder auch mit Wireshark analysiert werden.
Nicht jeder kennt nChronos, aber das wird sich schnell ändern, weil im Vergleich zu den üblichen Anbietern von retrospektiven Appliance-Lösungen hat nChronos ein aggressiveres Preis/Leistungsverhältnis.

Weitere Informationen gibt es auf der Produktseite und eine Testversion kann hier auch gedownloadet werden.

Im aktuellen c´t Magazin gibt es es einen neuen Artikel aus der Serie "Tatort Internet“.
Das Forum eines Online-Spiels wird in dem vorliegenden Fall heftig mit einer SYN-Flut attackiert.

In Folge dessen quittiert der Server fast vollständig den Dienst. Ärgerlich und auch schnell teuer: Da Forum und das eigentliche (kostenpflichtige Abo-) Spiel miteinander kommunizieren, ist auch der Spielbetrieb gestört.

Sehr anschaulich wird beschrieben, wie der Administrator zuerst mit Nagios und dann sehr energisch mit Wireshark dem Quell des Übels auf die Schliche kommt.
Letztlich wird der Angreifer isoliert, lokalisiert und von Scotland Yard in die Mangel genommen. Der Täter legt ein Geständnis ab.

Einen kleinen Makel hat diese kriminalistische Sternstunde jedoch: Der Angreifer, ein trotziger Schüler, hat sich offensichtlich keinerlei Mühe gegeben seine Identität zu verschleiern...  

Falls Sie nun auf den Geschmack der Protokollanalyse gekommen sein sollten: Schauen Sie sich doch mal die Details zu unseren Wireshark-Schulungen an.
Unsere Schulungen sind gespickt mit Praxisbeispielen - vorerst jedoch ohne Scotland Yard.

Bei Messungen kommt es immer wieder vor, dass ich auf eine WLAN-Installation treffe, die sehr ungünstig konzipiert worden ist. In einem speziellen Fall beauftragte uns ein Kunde mit einer WLAN-Analyse, da die Anwender sich über eine langsame und unzuverlässige Übertragung beklagt hatten.
Dort stieß ich, wie auch bei anderen WLAN-Netzen, auf folgende Eigenheiten:

 
  1. Bei der Survey Messung war deutlich zu erkennen, dass das WLAN historisch gewachsen ist. Zu Beginn gab es Wireless ausschließlich in Besprechungsräumen, dort ist auch eine gute WLAN-Versorgung messbar. In den anderen Bereichen ist die Ausleuchtung hingegen schlecht. 

    Empfehlung: Soll im Gebäude ein lückenloser WLAN-Zugriff ermöglicht werden, ist eine Neuplanung des WLAN-Netzes notwendig
     
  2. Ein Survey im 802.11 b/g Umfeld zeigte, dass alle Kanäle von 1 bis 11 benutzt werden. Viele Störungen treten auf, die Übertragung ist entsprechend langsam.
    Bei der Installation wurde offenbar nicht berücksichtigt, dass es nur drei WLAN-Kanäle im 2,4 GHz Band gibt, die überschneidungsfrei sind.

    Empfehlung: Eine Änderung der Kanäle wird die Zuverlässigkeit und Geschwindigkeit erhöhen. Limitieren wird jedoch die Anordnung der Access Points.
 
Der Kunde entschied sich dazu im ersten Schritt die Kanaleinstellungen der Access Points zu ändern. Da der drahtlose Zugriff jedoch für das Unternehmen sehr wichtig geworden ist, wurde später das gesamte WLAN neu geplant.
Durch die gründliche Vorbereitung und eine permanente Kontrolle mit WLAN Analyse Tools konnte eine hochwertige WLAN-Versorgung realisiert werden.

Herzlich Willkommen im offiziellen Blog von NETCOR! Fragen Sie sich, wofür das gut sein soll? Kann ich gut nachvollziehen, so ging es einigen Kollegen zuerst auch. Allerdings hat so ein Blog jede Menge Vorteile.

An dieser Stelle möchten wir Sie immer dann informieren, wenn es etwas Neues zum Thema IT-Performance gibt. Das können Anwenderberichte, Erfahrungsberichte, neue Produkte, Tipps & Tricks für Netzwerkanalysen aber auch unsere Info-Days sein.
Also alles Themen bei denen wir Sie an unserer Kompetenz in IT-Performance teilhaben lassen wollen.

Via RSS können Sie sich automatisch auf dem Laufenden halten. Einfach oben auf die Schaltfläche abonnieren klicken und Sie erhalten Neuheiten aus diesem Blog automatisch. Der dafür benötigte RSS-Reader ist z.B. in IBM Lotus Notes und Apple Mail bereits integriert. Natürlich gibt es auch zahlreiche alternative Tools für Desktop und mobile Plattformen.
Wenn Ihnen danach ist, können Sie Ihre Follower über die entsprechende Schaltfläche via Twitter informieren.
Falls Sie Anregungen oder Wünschen zum NETCOR-Blog haben, melden Sie sich gern bei uns.

Nun aber wünsche ich Ihnen viel Spaß beim Lesen!