Real Application Testing – Teil 4 von 7: Konsolidierung und Validierung neuer Hardware

Im Folgenden erläutert ein weiteres Beispiel, wie Real Application Testing in der Praxis wichtige Informationen über die Qualität von Datenbank- und Webanwendungen sowie Webservices liefert, um richtige Entscheidungen zur Produktivsetzung zu treffen.

Beispiel 2: Konsolidierung und Validierung neuer Hardware

Aufgabe

In vielen Rechenzentren von Unternehmen und Konzernen sieht man heute häufig folgendes Szenario: Es gibt viele – meist hundert oder mehr  Oracle Datenbanken auf unzähligen Servern verteilt, welche die Daten für Anwendungen verwalten.

Ferner kommt nicht auf allen Servern das gleiche Betriebssystem zum Einsatz noch stammen die Server aus der gleichen Hardwarefamilie. Oft laufen verschiedene Versionen der Datenbank-Management-Systeme innerhalb des Rechenzentrums auf denen jeweils ein Teil der Datenbanken residieren. Das gesamte Umfeld ist somit schwierig zu verwalten!

So liegt es nahe, wenn das IT-Management die Menge von Datenbanken in einer standardisierten Plattform konsolidieren möchte. Das Ziel sollte hierbei sein, die Anzahl der Datenbanken als die hierzu benötigten Server, deutlich zu reduzieren. In der Folge reduzieren sich auch die Wartungs- und  Administrationsaufwände im Rechenzentrumsbetrieb.

Methode

Das erste Ziel ist es, eine kosteneffiziente Hardware zu finden, die den Lastanforderungen aus der Produktion genügt und darüber hinaus noch Leistungsreserven bietet.

Auf Basis dieser Anforderungen kann man von Hardwarehersteller problemlos Angebote zu verschiedenen Lösungsoptionen bekommen. Die Frage ist jedoch, wie kann sinnvoll bestätigt werden, ob die Behauptungen des Herstellers tatsächlich für das konkrete Umfeld zutreffen? Und welche der angebotenen Plattformen stellt sich als die beste Alternative dar? Wäre vielleicht das kostengünstigste Angebot ausreichend, da die betreffende Hardwarelandschaft die Lastanforderungen ausreichend erfüllt?

Reine Ermittlung und Vergleiche der Performancewerte einzelner Systeme hilft nicht wirklich weiter, da letztlich das konkrete IT-Umfeld und das Lastverhalten unberücksichtigt bleiben. Real Application Testing liefert jedoch die notwendigen Aussagen, da in einer Testumgebung mithilfe von echter Last und Datenvolumen aus der Produktion die Eignung der verschiedenen Hardware Alternativen überprüft werden können.

Um Leistungseinbußen im SQL Umfeld zu vermeiden, wird SPA zur Identifikation potentieller Leistungsverschlechterungen eingesetzt. Das heißt, hier ist der gleiche Ansatz wie in Beispiel 1 – konkret die Maßnahmen des ersten Abschnittes – auszuführen.

Nachdem die Fragen bezüglich möglicher Leistungseinbußen beantwortet sind bzw. etwaige Leistungsschwächen beseitigt wurden, kann die Arbeitsauslastung der Hardware mithilfe des Tools Database Replay geprüft werden. Alle Datenbank Analysen werden mithilfe von AWR durchgeführt. Deren Berichte liefern alle Details zu Datenbankzeiten.

Daneben sollte man während der gesamten Untersuchung auch die OS Statistiken im Auge behalten:

Die erste Replay Iteration dient lediglich dazu zu prüfen, ob der entwickelte Testlauf keine großen Fehler beinhaltet. Diese sollten zuerst behoben werden, bevor der eigentliche Test beginnt, um belastbare Ergebnisdaten zu erhalten. Die Replay Funktion bietet eine Reihe von Parametern, welche das Systemverhalten beeinflussen.

In Bezug auf das konkrete System beziehungsweise Datenbankanwendung können die optimalen Einstellungen variieren. Das heißt, es gibt keine „Goldene Regel“ hierzu. Bevor also die eigentliche Vorprüfung beginnt oder dies nachfolgenden Test beginnen, ist Replay über geeignete Parameterwahl auf das konkrete System anzupassen. hierbei sind vor allem die Parameter sync, think_time und connect_time zu berücksichtigen, worüber das Datenvolumen beim Replay pro Zeiteinheit beziehungsweise der Replay Modus gesteuert werden kann.

Nach erfolgreicher Vorprüfung kann der erste Test gestartet werden. Hierbei wird mit der vom Hersteller empfohlenen Hardware Konfiguration begonnen. Vor den Tests sind nochmal die Replay Parameter zu prüfen.

Die aufgezeichnete Workload wird auf jeder Plattform abgespielt, um jegliche Abweichung zur Produktion festzustellen. Es werden die 10 wichtigsten Performanz Aussagen wie zum Beispiel CPU, I/O oder Zeitbedarf aus den AWR Reports für die Analyse und Bewertung ausgewählt. Der WAR Report dokumentiert für jede Konfiguration alle relevanten Informationen beziehungsweise Messwerte zu Zeit- und Ressourcenverbrauch zu allen wichtigen Hardware und Datenbank Komponenten.

Aufgabe 1: Identifizierung der CPU Engpasses

Hierbei wird das Abspielen der Workload mehrfach wiederholt. Dabei werden die Anzahl der verfügbaren CPUs schrittweise verringert. Mit dieser Methode kann die Minimalkonfiguration eines Systems ermittelt werden, welche zum erfolgreichen Betrieb benötigt wird.

Aufgabe 2: Plattformskalierbarkeit

Die aufgezeichnete Workload wird hierbei mit dem  SCALEUP_MULTIPLER ausgeführt. Der SCALEUP_MULTIUPLIER multipliziert die Benutzeranzahl und von jeder Shadow Session die Nur-Lese-Operationen. Daneben kann man aber auch die connect_time und think_time verringern, um eine höhere Last zu simulieren. Die Änderung der SCALEUP_MULTIPLIER (sinnvoll sind hier Werte von 2, 4 oder 8) hilft die Skalierbarkeit für jede Konfiguration zu ermitteln. Diese Methode ermittelt die Plattform mit dem besten Preis- / Leistungsverhältnis.

Aufgabe 3: Verringerung der Datenbankanzahl durch Server Konsolidierung

Hierbei ist zu prüfen, ob mehrere Anwendungen in derselben Datenbank koexistieren können. Diese Überprüfung kann mithilfe des sogenannten consolidated Replay erfolgen. Damit ist es möglich, mehrere Workloads verschiedener Anwendungen beziehungsweise Datenbanken auf der gleichen Datenbank einzuspielen.

Dies kann in folgenden Schritten durchgeführt werden:

• Aufzeichnung der SQL Tuning Sets für die betreffenden Datenbanken, welche zu konsolidieren sind.
• Ausführen des SQL Performance Analyzer -Leistungsanalyse für die betreffenden Datenbanken, welche zu konsolidieren sind, um SQL Wiederholungen zu identifizieren.
• Aufzeichnen des interessanten Zeitbereichs eines Workloads von jeder Datenbank, welche zu konsolidieren wäre.
• Zunächst wird jeder Workload isoliert abgespielt, um etwaige Performanz Probleme oder Fehler zu beseitigen.
• Ausführung eines consolidated Replays: nach jeder erfolgreichen Iteration beziehungsweise Beseitigung aller Probleme und Fehler in einem aufgezeichneten Workload wird besagte Aufzeichnung an das Abspiel Schema angefügt. Die Leistungswerte des Servers als auch der Datenbank werden dabei überwacht und bewertet. Der Replay Report zeigt neue Fehler oder Performanz Probleme auf, welche während der Wiedergabe auftreten. Diese sind dann natürlich zu beseitigen. Ist dies unmöglich, so wird hierdurch angezeigt, dass sich die betreffende Datenbank der zuletzt hinzugefügten Workload Aufzeichnung nicht mit den anderen Datenbanken konsolidieren lässt.

Ergebnisse

Mit diesem Ansatz kann rasch ermittelt werden, welche der Plattformen das beste Preis- / Leistungsverhältnis bietet. Darüber hinaus kann die Frage beantwortet werden, welche Risiken bei einer Konsolidierung von Anwendungen zu beachten sind.

Die Tests zeigen ferner auf, welche Anwendungen auf derselben Datenbank residieren können, ohne sich gegenseitig zu stören. Ebenso  liefern die Tests Informationen über den zukünftigen Ressourcenbedarf. Gerade bei Konsolidierungen, in welcher Datenbanksysteme zusammengefasst werden, sind diese Informationen besonders wichtig!