Flaschenhälsen auf der Spur

Taktgefühl: Performance-Tuning für Microsoft Dynamics AX

| Autor / Redakteur: Georg Kostner* / Ulrike Ostler

Eine Performance-Steigerung in ERP-Anwendungen wie „Microsoft Dynamics AX“ bdeutet eine höhere Verfügbarkeit und das freut den Admin, die Nutzer und die Unternehmensleitung. Doch ist ist nicht egal, welches Tool dafür hergenommen wird.
Eine Performance-Steigerung in ERP-Anwendungen wie „Microsoft Dynamics AX“ bdeutet eine höhere Verfügbarkeit und das freut den Admin, die Nutzer und die Unternehmensleitung. Doch ist ist nicht egal, welches Tool dafür hergenommen wird. (Bild: © Nomad_Soul / stock.adobe.com)

Eine ERP-Anwendung wie „Microsoft Dynamics AX“ ist in fast allen Unternehmen kritisch. Sie muss zuverlässig funktionieren. Das Performance Management als fortlaufender Prozess nimmt dabei eine zentrale Stellung ein. Denn Optimierung ist mehr als ein paar Konfigurations-Tweaks und zusätzliche Datenbank-Indizes: Was nicht gemessen werden kann, lässt sich nicht verbessern. Es gilt, den wirklichen Flaschenhals zu identifizieren.

Ohne ein funktionierendes und performantes ERP-System kann kaum ein Unternehmen heute seinen Geschäften nachkommen. Ausfälle des ERP bedeuten auch immer Ausfälle des Geschäftsbetriebs. So hat etwa die Schweizer Ausgabe der IT-Fachzeitschrift „Computerworld“ jüngst ermittelt, dass bei einem vorübergehenden Ausfall des ERP der durchschnittliche Schaden rund 30.000 Franken pro Tag beträgt – gut 27.000 Euro.

Bei großen Unternehmen mit mehr als 1.000 Mitarbeitern liegt die Schadenssumme pro Tag sogar bei ungefähr 60.000 Euro. Doch entstehen Schäden in der Praxis nicht nur bei einem kompletten Stillstand der ERP-Systeme. Auch Performance-Probleme können sich sehr negativ auf die Produktivität der Mitarbeiter auswirken. Die IT ist also gefordert, zu jeder Zeit die optimale Performance der ERP-Lösung zu gewährleisten.

ERP-Applikationen wie Microsoft Dynamics AX bestehen aus unterschiedlichen Komponenten. Die Basis bilden Datenbanken, im Falle von Dynamics AX kommt in der Regel ein „SQL-Server“ von Microsoft zum Einsatz. Darauf aufbauend arbeitet die Anwendungsschicht, die sich bei Dynamics AX aus dem File-Server und dem „Application Object Server“ (AOS) zusammensetzt. Die Geschäftslogik ist im AOS verankert, welcher auch die Kommunikation zwischen Datenbanken, Clients und der Anwendung regelt.

Das ERP-System „Microsoft Dynamics AX“ basiert auf einer vielschichtigen Architektur mit zahlreichen Abhängigkeiten.
Das ERP-System „Microsoft Dynamics AX“ basiert auf einer vielschichtigen Architektur mit zahlreichen Abhängigkeiten. (Bild: Würth Phoenix)

Die Dynamics-AX-Struktur

Je nach Größe der Installation können diese Instanzen auf einem gemeinsamen Server oder verteilt auf mehrere – auch virtuellen - Maschinen betrieben werden. Als dritte Schicht verfügt Dynamics AX wie jedes ERP über einen Präsentations-Layer, der mittels des AOS den Zugang zu den Daten und Funktionen herstellt. Weitere Komponenten wie Virtualisierungssoftware bringen zusätzliche Komplexität in das Gesamtsystem: Sowohl das ERP selbst als auch weitere Komponenten wie der SQL-Server oder AOS können mittels Hyper-Visor oder VMware virtualisiert sein.

Um potenziellen Flaschenhälsen im Gesamtsystem auf die Spur zu kommen, müssen alle genutzten Komponenten im Performance Management berücksichtigt werden - auch grundlegende Elemente wie Virtualisierungs-Layer oder Betriebssysteme. Die Gesamtstruktur kann in der Praxis über die reine ERP-Architektur hinausreichen – etwa, wenn externe Services integriert sind oder Shared Services wie ein SAN (Storage Area Network) eingesetzt werden.

User Experience

Um Flaschenhälse, Fehlkonfigurationen oder andere Störungsquellen zu erkennen, ist also ein gewisser Aufwand notwendig, der alle Komponenten der AX-Installation berücksichtigt. Das bedingt zunächst ein umfassendes Monitoring – nur was gemessen werden kann, lässt sich auch optimieren.

Ergänzendes zum Thema
 
Über Würth Phoenix

Das Monitoring liefert die relevanten Metriken, um zum einen Aussagen über den aktuellen Zustand der beteiligten Systeme zu liefern, zum anderen um das Lastverhalten der Server und anderer Komponenten zu verstehen. Ein wichtiger Baustein dabei ist die Simulation von Transaktionen auf dem System. Dieses Verfahren kommt auch beim End-to-End-Monitoring als „User Experience“ (UE) zum Einsatz und gibt Aufschluss über die tatsächlichen Reaktionszeiten der gesamten genutzten Dienste von der Datenbank bis hin zum Client.

Performance-Management in 5 Stufen

Da bereits die ERP-Anwendung für sich betrachtet ein hohes Maß an Komplexität besitzt und auch andere, nicht direkt damit verbundene Komponenten der IT wie etwa das Active Directory oder das Netzwerk auf die Gesamt-Performance Einfluss haben, sollte das Performance-Management in fünf Stufen umgesetzt werden:

  • 1. Bestandsaufnahme: Zunächst gilt es, die vorhandenen Komponenten zu erfassen, die im Rahmen einer End-to-End-Betrachtung für das ERP relevant sind.
  • 2. Architekturanalyse: Hier geht es darum, den Aufbau der Architektur genau kennenzulernen – Sind die Server physikalisch oder virtuell? Wie sind die Cluster aufgebaut? Wie wird das Backup realisiert? Und dergleichen mehr.
  • 3. Konfigurationsanalyse: In diesem Schritt wird die Konfiguration aller beteiligten Komponenten genau unter die Lupe genommen und falls sinnvoll optimiert.
  • 4. Performance-Messung: Alle relevanten Faktoren wie CPU- und Speicherauslastung, Transaktionen pro Sekunde, I/O-Operationen, Page-Zugriffe und vieles mehr werden in regelmäßigen Intervallen erfasst. In der Praxis hat sich ein Intervall von fünf Sekunden bewährt. Dieses liefert eine ausreichende Menge an Daten, ohne dabei eine unkontrollierbare Datenflut zu erzeugen.
  • 5. Performance-Analyse: Die Auswertung der im Monitoring gewonnenen Informationen zeichnet ein genaues Bild davon, wie sich das ERP-System unter verschiedenen Lastbedingungen verhält und wo sich Engpässe in der Komponentenkette befinden könnten.

Um die benötigten Performance-Daten zu erheben, kommt auf der einen Seite ein umfassender so genannter Unified-Monitoring-Ansatz zum Einsatz, mit dem konstant die entsprechenden Metriken erfasst und bei Leistungseinbrüchen Alarm gegeben werden kann. „Neteye“, eine vom Softwaredienstleister Würth Phoenix eigenentwickeltes Unified Monitoring-Tool, hat sich hierfür bewährt.

Neben dem Bereich IT System Management ist das zur Würth-Gruppe gehörende IT-Unternehmen nämlich auch profunder Kenner der Microsoft Dynamics AX-Welt und durch zahlreiche internationale Referenzen einer der erfolgreiches Microsoft-Partner-Unternehmen in diesem Bereich. Auf der anderen Seite wird die End-User-Experience über einen Roboter wie „Alyvix“ und durch die „Neteye User Experience“ erfasst. Alyvix ist in Neteye integriert und wird als Open-Source-Projekt von Würth Phoenix seit Jahren unterstützt.

Polling-Time

Beim Performance-Management innerhalb einer komplexen Umgebung wie Dynamics AX, die auf mehreren physischen und virtuellen Servern verteilt sein kann, kommt es nun im ersten Schritt auf eine geeignete Polling-Time bei der Performance-Messung an. Darunter versteht man das Intervall, in dem das Monitoring Daten der überwachten Komponenten abfragt.

Eine Polling-Time von einer Minute reicht bei einem Performance-Management nicht mehr aus. Klassische Monitoring-Systeme jedoch pollen die Daten alle fünf Minuten. Anhand dieser Durchschnittswerte lässt sich kein Engpass bei den Komponenten wie SQL-Server, Query, I/O, CPU oder RAM identifizieren.

Um eine Performance-Analyse durchführen zu können und entsprechend dann kontinuierlich zu messen, benötigt man Raw-Performance-Metriken im Sekundenbereich – ideal ist eine Sekunde, zwei Sekunden sollten nicht überschritten werden. Nur mit dieser detaillierten Betrachtungsweise ist ein Performance-Monitoring möglich.

Damit die Systeme selbst nicht durch das Abgreifen der Metriken alle Sekunde belastet werden, gibt es eigene Streaming-Verfahren. Es ist zudem empfehlenswert, sich auf die Metriken zu beschränken, welche für die Analyse ausschlaggebend sind.

Jede Komponente innerhalb eines ERP-System umfasst zahlreiche Metriken, die im Sekundentakt erfasst werden müssen, um aussagekräftige Ergebnisse zu erhalten.
Jede Komponente innerhalb eines ERP-System umfasst zahlreiche Metriken, die im Sekundentakt erfasst werden müssen, um aussagekräftige Ergebnisse zu erhalten. (Bild: Würth Phoenix)

Definieren des Normalzustands

Als nächsten wichtigen Schritt gilt es, aus den gesammelten Metriken eine geeignete Messbasis zu erarbeiten. Es muss klar ausgearbeitet werden, welche Performance-Kennzahlen im Bereich I/O-Latenzen, CPU, RAM, Query und dergleichen als normal gelten und welche Ausnahmen darstellen. Nur auf Basis dieser Messbasis kann dann entsprechend eine Alarmierung erfolgen.

Hier die Performance-Metrik für den SQL Server.
Hier die Performance-Metrik für den SQL Server. (Bild: Würth Phoenix)

Die Definition der Messbasis beruht auf einer Analyse der gesammelten Daten, der Betrachtung der Ressourcen und der Architektur sowie auf der Art und Weise, wie das ERP-System genutzt wird. Hierunter fallen Aspekte wie das Verhalten der Anwender, wie Geschäftsprozesse abgewickelt werden oder welche Batch-Prozesse zum Einsatz kommen.

Erst wenn der Normalzustand in Form der Messbasis definiert wurde, können Abweichungen bei der Auslastung der Systeme identifiziert werden. Die erkannten Performance-Probleme lassen sich dann zum Beispiel durch Änderungen der Query, Anpassungen am Source-Code in Dynamics AX, stärkere Hardware oder bessere Optimierung des SQL-Server beheben.

Hier die Metrik für den „Dynamics Applikation Server“ von Microsoft
Hier die Metrik für den „Dynamics Applikation Server“ von Microsoft (Bild: Würth Phoenix)

Einige Größen der Messbasis lassen sich auch logisch herleiten. So ist es zum Beispiel bei einem SQL-Server auf Basis von VMware extrem wichtig, dass die CPU Ready Time nie höher als bei 10 Prozent liegt. Das würde bedeuten, dass der SQL-Server CPU-Leistung benötigt, aber diese vom Virtualisierungsdienst nicht bekommt – mit gravierenden Auswirkungen: Analysiert man den SQL-Server über einen Zeitraum von 30 Sekunden, bedeutet eine CPU Ready Time von 10 Prozent, dass der Server drei Sekunden lang keinen Zugriff auf die CPU bekommt.

Der SQL-Server beantwortet also eine Anfrage drei Sekunden lang nicht. Das wiederum kann bedeuten, dass ein Anwender über drei Sekunden auf die Antwort warten muss. Geschieht dieses regelmäßig und bei mehreren Anwendern, behindert das die Produktivität und auch die Stimmung der User.

Auch die Virtualisierungsumgebung darf nicht vergessen werden.
Auch die Virtualisierungsumgebung darf nicht vergessen werden. (Bild: Würth Phoenix)

Wahrscheinlichkeit statt Mittelwert

Um die Performance aus der Sicht der Anwender zu betrachten, ist ein neuer Ansatz sehr hilfreich, den die Monitoring-Lösung Neteye seit einiger Zeit verfolgt: Über eine Analyse der Dichte können Untergruppen und deren Verhalten über einen bestimmten Zeitraum erkannt werden. Dabei kommen zwei Ansätze zur Anwendung. Zum einen nutzt das Verfahren die statistische Methode der Wahrscheinlichkeitsdichte, eines Verfahrens zur Beschreibung einer Wahrscheinlichkeitsverteilung innerhalb eines gegebenen Intervalls.

Anstatt den Standard-Traffic als „Datenverkehr innerhalb eines bestimmten Durchschnittsbereichs“ zu definieren, wurde versucht, die Datenverteilung durch eine Funktion der Wahrscheinlichkeitsdichte abzuschätzen. Die daraus resultierende Definition des Standard-Datenverkehrs ist damit ein „Datenverkehr innerhalb einer bestimmten Bandbreite des deutlichsten Maximalwerts der Wahrscheinlichskeitsdichtefunktion.“

Damit erhält man statt des bekannten Mittelwerts eine Dichte, die anzeigt, wie sich der Datenverkehr und die Datenmenge verteilen. Client-Latenz und Datendurchsatz können somit in einen Zusammenhang gebracht werden und lassen sich mittels 2D-Plots auch grafisch repräsentieren.

Dense und Sparse Plots, bei denen die Buffer Manager/Page Files dargestellt sind. Die Farbdichte macht die Häufigkeit der Transaktionen erkennbar.
Dense und Sparse Plots, bei denen die Buffer Manager/Page Files dargestellt sind. Die Farbdichte macht die Häufigkeit der Transaktionen erkennbar. (Bild: Würth Phoenix)

Bei diesem Ansatz wird der Datenverkehr durch ein Clustering-Verfahren in Dense und Sparse Traffic unterteilt. Anhand der so gewonnenen Informationen kann eine Aussage getroffen werden, welcher Anteil des Datenverkehrs sich in einem akzeptablen Bereich befindet (Dense) und welcher Prozentsatz der Requests Anomalien aufweist (Sparse).

Eine grafische Darstellung der Werte erleichtert die Auswertung. So kann zum Beispiel anhand der Farbdichte darauf geschlossen werden, ob sich das System in dem gemessenen Bereich stabil und skalierbar verhält. Eine große Verteilung der Messwerte deutet darauf hin, dass es Probleme gibt. Über fortlaufende Messungen erkennt man mit diesem Ansatz schnell, ob sich der Systemzustand verschlechtert.

Durch eine tiefergehende Analyse der Anomalien im Performance Management lässt sich ermitteln, ob die Verschlechterung der Performance durch Hardware-nahe Faktoren wie CPU oder I/O verursacht wird, durch Wechselwirkungen auf Virtualisierungsebene oder andere Komponenten der Infrastruktur. Ist der Flaschenhals dort nicht zu verorten, kann eine gründliche Analyse des Dynamics AX Hinweise liefern.

Dabei sollten insbesondere die Bereiche Query, temporäre Datenbank und der Cache im Fokus stehen. Auch im Quellcode der Anwendung selbst können sich Routinen finden, die sich negativ auf die Performance auswirken.

Mehr Performance, heißt auch: größere Verfügbarkeit.
Mehr Performance, heißt auch: größere Verfügbarkeit. (Bild: Würth Phoenix)

Mehr Performance, mehr Verfügbarkeit

Durch Performance Management kann der Betrieb von Microsoft Dynamics AX und anderen ERP-Lösungen deutlich optimiert werden. Das hat einige positive Effekte auf die IT, aber auch auf das gesamte Unternehmen: Durch die optimale Auslastung der vorhandenen Ressourcen lassen sich Neuanschaffungen bei der Hardware besser planen und als regelmäßige Upgrades deutlich effizienter und kostengünstiger umsetzen.

Die Ausfallsicherheit der Lösung steigt, da alle Komponenten genau in ihrer Relevanz bekannt sind, überwacht werden und potenzielle Fehlerquellen im Vorfeld beseitigt wurden. Damit steigt auch die Zufriedenheit der Anwender. Lange Antwortzeiten und Down-Times gehören der Vergangenheit an, die User können störungsfrei ihrer Arbeit nachgehen. Ohne lästige Produktivitätsbremsen.

* Georg Kostner verfügt über 17 Jahre Erfahrung in den Bereichen IT-System Management und Software-Entwicklung innerhalb der Würth-Gruppe. Zu Beginn seiner beruflichen Laufbahn beschäftigte er sich mit der Implementierung von ERP-Anwendungen und Framework-Entwicklungen. Sein Einsatz für innovative, technologische Forschungsprojekte und vor Allem sein Interesse für Open Source Software begleiten ihn bis heute. Aktuell ist er als Leiter der Abteilung System Integration bei Würth Phoenix und für die eigenentwickelten IT-System- und Service Management-Lösungen Würthphoenix Neteye und „Würthphoenix Erizone“ verantwortlich.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44775400 / Anwendungen)