Clouds und Container verändern Monitoring und Management

Den Preis im Auge behalten

Konvergenz, Cloud und Container sind allesamt spannende Technologien. Sie bieten eine weitere Abstraktion zwischen Workloads und Infrastruktur. Mehr Abstraktion ist großartig für unsere neue verteilte, DevOps-orientierte Welt, aber sie neigt auch dazu, die ultimative Transparenz darüber zu verlieren, die normalerweise für eine gute IT-Performance sorgt.

Es gibt viele Möglichkeiten, die Leistung zu betrachten, aber konzentrieren wir uns auf die Reaktionszeit der Workloads als eines der wichtigsten Maßstäbe dafür, wie zufrieden der Endanwender mit seiner IT-Erfahrung sein wird. Stellen Sie sich ein Diagramm vor, bei dem die CPU-Auslastung auf der X-Achse linear von 0 auf 100 Prozent steigt. Wenn wir die durchschnittliche interaktive Transaktionsleistung für diese CPU auf der Y-Achse darstellen, werden wir am Ende eine exponentielle Kurve erhalten, die bei einer angemessenen Servicezeit bei 0 Prozent beginnt, aber bei 100 Prozent Auslastung in Richtung Unendlichkeit ansteigt. (Hinweis: Für Mathematiker kann die Reaktionszeitkurve mit Hilfe der Queuing-Theorie modelliert werden, um die wahrscheinliche Wartezeit für die zunehmend ausgelastete Ressource zu berechnen.)

Die Auslastung einer Infrastrukturressource so hoch wie möglich zu gestalten, indem man die Last erhöht, wird schließlich kontraproduktiv im Hinblick auf das IT-Performance-Management.

Es ist wahr, dass Batch-Workloads mehr an ihrem Durchsatz gemessen werden, was bei maximaler Auslastung maximal ausfällt. Die Reaktionszeit ist jedoch entscheidend für jede interaktive Workload. Und in der heutigen Welt der schnellen Daten verarbeiten wir mehr Quellen und Datenströme in nahezu Echtzeit durch und für interaktive Operationen und Anwendungen. Big Data bedeutet heute, so viel Intelligenz wie möglich so weit wie möglich an das operativen Ende heranzuführen.

Cloud und Container verändern das IT-Performance-Management auf unterschiedliche Weise, und während Änderungen beängstigend sein können, gibt es für IT-Administratoren Möglichkeiten, die Leistung in einem akzeptablen Bereich zu halten.

Individuelle Entitäten vs. Massenware

Cloud-App-Designer neigen dazu, Teile des kritischen Codes eher wie austauschbare Massenware zu behandeln – und weniger wie die individuellen Entitäten, die sie früher in den Silos der traditionellen Rechenzentrumsinfrastruktur waren. Früher haben wir geschäftskritische Anwendungen und deren Ressourcen sorgfältig überwacht und verwaltet; jede Abweichung vom Normalzustand wird sofort getestet. Bei vielen der heutigen Cloud-Anwendungen führt eine Leistungsabweichung dazu, dass die App mit einer neuen Cloud-Instanz neu bereitgestellt wird, die besser funktionieren sollte.

Aber nicht unbedingt. Um dies zu verstehen, lassen Sie uns einen Blick auf die Virtualisierung werfen, die viele Vorteile, aber nicht immer eine bessere Leistung gebracht hat. In einem virtualisierten Host war die garantierte tatsächliche Antwortzeitleistung schon immer ein Problem.

Während ein virtueller Administrator einer bestimmten VM eine Zahl an Host-Ressourcen (in Bezug auf die Auslastung) zuweisen kann, wird jede Host-Ressource per Definition von vielen VMs gleichzeitig genutzt. Sobald wir verstehen, dass die Antwortzeitleistung im Hinblick auf die Gesamtsystemnutzung nichtlinear ist, können wir sofort sehen, wie das „Noisy-Neighbour“-Problem auf stark ausgelasteten virtuellen Servern entsteht – selbst wenn unsere kritische VM eine garantierte Auslastungsrate aufweist.

Betrachten wir beispielsweise, wie alle VMs auf einem bestimmten Host-Server einen garantierten Kapazitätsanteil erhalten. Wenn genügend VMs ihre Kapazität gleichzeitig nutzen, um die Gesamtauslastung des Servers über 50-60 Prozent zu steigern, verschlechtert sich die Reaktionszeit für alle. Ab einer bestimmten Auslastungsschwelle von weit unter 100 Prozent hat die zugrundeliegende Serverressource noch Restkapazität, aber die erfahrene Leistung kann sich um die Hälfte verringern. Wenn sich die Auslastung auf 100 Prozent nähert, kann die Reaktionsfähigkeit bis zu dem Punkt abnehmen, an dem wenig tatsächliche Arbeit überhaupt durch das System gelangt.

Wenn wir an Clouds, öffentliche oder private, als große virtuelle Serverfarmen denken, können wir sehen, warum eine Cloud-Maschineninstanz nicht immer die Leistung bietet, die wir benötigen.

Wenn wir an Clouds, öffentliche oder private, als große virtuelle Serverfarmen denken, können wir sehen, warum eine Cloud-Maschineninstanz nicht immer die Leistung bietet, die wir benötigen. Der Cloud Service Provider verspricht eine gewisse Ressourcenauslastung, wenn wir unsere Kreditkartennummer eingeben und einen Cloud-Server auswählen. Der Cloud-Provider gewährleistet jedoch in der Regel nicht, dass Ihre spezielle Maschineninstanz nicht mit vielen anderen konkurrierenden Instanzen kohärent sein wird. Das bedeutet, dass viele gehostete Maschineninstanzen in Stoßzeiten nicht das gleiche Leistungsniveau bieten, wie wenn ihre zugrunde liegende Cloud-Infrastruktur weniger als halb im Leerlauf ist.

Grundsätzlich sind Clouds kosteneffizient, weil sie die Infrastruktur so weit wie möglich bündeln und teilen. Ein Cloud-Service-Provider ist wirtschaftlich motiviert, so viele virtuelle Instanzen wie möglich in einen bestimmten Footprint der Cloud-Infrastruktur zu integrieren. Tatsächlich liegt einer der Schlüsselbereiche der Gewinnmarge für einen Cloud-Provider darin, die reale Infrastruktur bei mehreren Mandanten so weit wie möglich zu über-provisionieren, wobei statistisch gesehen bekannt ist, dass viele Maschineninstanzen in den meisten Fällen stark unterausgelastet sind, wenn sie überhaupt genutzt werden.

So behandeln Web-App-Administratoren und DevOps-Mitarbeiter ihre Cloud-Anwendungen eher wie Massenware. Sie entwerfen ihre Webanwendungen auf eine verteilte Weise über viele Maschineninstanzen hinweg, so dass sie, wenn eine einzelne Maschineninstanz innerhalb dieses Pools jemals an langsamer Leistung leidet, sie sie einfach beenden und neu starten. Wenn Ihr Service Provider groß genug ist, garantiert der Neustartvorgang fast immer, dass die neue Instanz in einem anderen Bereich der Cloud-Infrastruktur angelegt wird und nicht mehr neben dem „Noisy Neighbour“ liegt. Es ist anzumerken, dass dieser Ansatz in weniger expansiven Public Clouds möglicherweise nicht so gut funktioniert.

Containerisierte Sichtbarkeit

Mit containerisierten, Mikro-Service-lastigen Anwendungen kann die Performance sogar noch undurchsichtiger sein. Ein einzelner Mikro-Service per Originaldefinition hält einfach nicht lange, auch wenn seine Leistung schlecht ist. Bei einer massiv containerisierten Anwendung kann es sein, dass wir nur eine schlechte Performance im Gesamtendergebnis sehen. Und da Mikro-Services flüchtig sein können, können wir sie nicht wirklich als individuelle Entität oder Massenware verwalten.

Als wir Entitäten ihrer eigenen isolierten Infrastruktur zugewiesen bekamen, ermöglichten End-to-End-Infrastruktur-Performance-Management-Tools IT-Administratoren, offensichtliche Leistungsprobleme zu identifizieren und zu beheben. Während die Virtualisierung das IT-Performance-Management undurchsichtig machte, gab es immer noch effektive Möglichkeiten, die Anwendungsleistung mit der virtualisierten Infrastruktur zu korrelieren. Aber sobald wir unsere Anwendungen in eine Public Cloud verlagern, wird das Management für hohe Performance eher zu einem statistischen Katz-und-Maus-Spiel. Und jetzt, mit dem Aufkommen der Container, ist das Management der Performance eine noch größere Herausforderung.

Die gute Nachricht ist, dass wir mit Containerarchitekturen problemlos Performance-Instrumente auf einem sehr granularen Niveau in unsere Anwendung integrieren können. Angesichts einer neuen Generation von hochskalierbaren und reaktionsschnellen Management-Tools sollte es möglich sein, Containerfarmen mit Hilfe einer sinnvollen IT-Betriebsautomatisierung (wahrscheinlich basierend auf der effektiven Nutzung von maschinellem Lernen) auf in bessere Performance-Regionen zu bringen.

Der eigentliche Trick für ein wettbewerbsfähiges Technologieunternehmen wird darin bestehen, proaktiv, wenn auch nicht vorhersehbar und kontinuierlich, hohe Leistungen zu erbringen und gleichzeitig eine bewusst gewählte Kosten- oder Ausgabenpolitik umzusetzen. Dieser Spagat wird bei Cloud und Containern in gewisser Weise schwieriger – wegen der erhöhten Undurchsichtigkeit und Skalierbarkeit –, aber auch einfacher, wegen der verteilten Daten- und Verarbeitungstechnologien.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!