Infrastrukturen maximieren: Aus weniger mach mehr

Es ist wichtig zu erkennen, dass aus der Perspektive der Anwender die Reaktionszeit eines der wichtigsten Kriterien darstellen kann. Der Wechsel auf Server-Farmen und ähnliche Arrangements, mit denen sich Hardware parallel betreiben lässt, bedeutet, dass sich ein höheres Niveau an Verfügbarkeit relativ leicht erreichen lässt. Für den Nutzer ist eine Anwendung jedoch nur dann tatsächlich „verfügbar“, wenn die Reaktionszeit annehmbar gering ist.

Tools wie AppManager von NetIQ erlauben es IT-Managern, die Reaktionszeiten auf aktive Weise zu überwachen und die Quelle jedes eventuell auftretenden Problems schnell zu identifizieren. Mick Lazarus, Senior Consultant bei NetIQ, betont, dass es wichtig sei, nicht nur den Zustand des Netzwerks sondern auch den Fluss der Anwendungen zu überwachen. So ist es möglich, dass zwei an unterschiedlichen Standorten befindliche Mailserver aufhören, zu kommunizieren, obwohl die Verbindung zwischen den beiden Standorten auch weiterhin ordnungsgemäß arbeitet.

Die Reaktionszeit mag zwar ein entscheidendes Kriterium sein, jedoch sei es, so Lazarus weiter, zur Lokalisierung eines beliebigen Problems auch weiterhin wichtig, die Leistungen der einzelnen Server innerhalb einer Farm sowie die Leistungen aller an bestimmten Transaktionen beteiligten Subsysteme zu überwachen (Webserver, Datenbank, Legacy-System etc.).

Die auf diese Weise gesammelten Informationen können anschließend für Zwecke der Kapazitätenplanung verwendet werden. Durch Beobachtung der Trends sind Manager in der Lage, besser vorherzusagen, wann eine größere Veränderung notwendig oder angemessen sein wird, wie zum Beispiel die Migration von einer direkt angebundenen Speicherlösung (Direct Attached Storage) auf ein Speichernetzwerk (SAN). Die detaillierten Daten könnten auch darauf hinweisen, dass eine relativ kleine Veränderung in einem bestimmten System – möglicherweise schon die Installation zusätzlichen RAM-Speichers – seine Lebensdauer verlängern könnte. Außerdem bieten sie eine Grundlage für die Identifizierung freier Kapazitäten und eines Bedarfs an Belastungsverteilung und Server-Konsolidierung.

„Wenn man eine Organisation sieht, die nicht besonders gut läuft und in der es sehr viele [IT-]Angestellte gibt, dann liegt dies für gewöhnlich daran, dass die Systeme ohne Management-Tools zu ihrer Kontrolle implementiert wurden“, so Lazarus weiter.

Ein detailliertes Verständnis und detaillierte Leistungsmessungen ermöglichen es Lazarus zufolge IT-Profis, vor allem deshalb im Umgang mit Anwendern „eine starke Position“ einzunehmen, weil Vermutungen durch genaue Zahlen ersetzt werden können.

Obgleich einige Produkte und Dienste auf spezielle Aspekte, wie z. B. die Netzwerk- oder Storage-Performance, abzielen, „sollte stets die Business-Anwendung und nicht die Technologie“ im Mittelpunkt stehen, so Graham Sowden, Managing Director von Mercury International.

Mercurys Vorgehensweise beginnt mit der Vorbereitung von Test-Scripts zur Simulation der Anwender, wobei es für verschiedene Aufgaben auch unterschiedliche Scripts gibt. Diese Scripts werden verwendet, um das System während einer Periode außerhalb der Spitzenbelastung einer Testbelastung auszusetzen, deren Auswirkungen gemessen werden. Schwierigkeiten mit der Belastung werden Sowden zufolge für gewöhnlich rasch entdeckt und das ihnen zugrunde liegende Problem wird daraufhin von den Mitarbeitern des Kunden oder anderen Diensteanbietern behoben. Stellt sich beispielsweise die Firewall als Engpass heraus, wird das Sicherheitsteam benachrichtigt. Um sicherzustellen, dass das Problem tatsächlich gelöst wurde, wird der Test wiederholt. Anschließend wird die Belastung etwas heraufgesetzt, um das nächste Problem erkennen zu können. Dieser Prozess wird so oft wiederholt wie nötig. „Das Auffinden des Problems stellt bereits 80 Prozent der Arbeit dar“, so Sowden.

Manche Probleme treten nur unter bestimmten Arten der Belastung auf, so Sowden weiter, was es sehr schwierig macht, sie ohne systematische Tests ausfindig zu machen.

„Man sollte nicht die Komponenten messen, sondern das Endergebnis“, sagte er und verwies auf das Beispiel einer wichtigen australischen Bank, die sechs Monate damit verbrachte, eine Datenbank so zu optimieren, dass sie nur 50 Prozent statt der vorherigen 80 Prozent ihrer Kapazität verwendete – was jedoch ohne jede Auswirkung auf die Erfahrung des Endanwenders war.