© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 11: Verfügbarkeit von Websystemen

Wir sind immer für Sie da

Websysteme sind komplex und anfällig gegen unterschiedliche Störungen. Dennoch ist Hochverfügbarkeit ein häufig gewünschtes Qualitätsmerkmal, insbesondere im E-Commerce. Eine hohe Verfügbarkeit bedeutet jedoch auch hohe Kosten im Betrieb und der Produktion eines Websystems. In diesem Artikel beschreiben wir, wie sich die Verfügbarkeit definieren und berechnen lässt, und einige Methoden, um sie zu verbessern.

Nicolas Bär, Daniel Takai


Verfügbarkeit gehört zum Qualitätsmerkmal der Widerstandsfähigkeit eines Systems (Resiliency). Tatsächlich wird sie in vielen Fällen als Synonym betrachtet [1]. In Kombination mit der Diskussion um Prüfbarkeit (Monitoring) und Wiederherstellbarkeit (Recoverability) ist es dem Webarchitekten möglich, verschiedene Maßnahmen zu definieren, die eine höhere Uptime eines funktionierenden Systems ermöglichen. Für uns bedeutet Resiliency, dass möglichst viele Störungen eines Systems bekannt und wir dagegen gewappnet sind. Die Konzepte rund um die Verfügbarkeit sowie das Zusammenspiel mit der Resiliency zeigt Abbildung 1.

Abb. 1: Konzepte rund um die Verfügbarkeit

Es gibt verschiedene Gründe, warum eine Komponente in unserem System versagen kann. Nebenläufigkeitsprobleme kommen häufig vor, denn Deadlocks, Race Conditions, Livelocks und Starvations sind schwierig mit Testfällen nachzustellen. Generell hat das Timing-Verhalten in verteilten Systemen einen Einfluss auf das Verhalten seiner Komponenten. Denken Sie nur an einen überlasteten Service, der nur wenige KB pro Minute liefert, und extrapolieren Sie dies auf das Verhalten Ihrer Anwendung.

Auch Designfehler können problematisch sein: Der falsche Entwurf eines Systems kann ein System zum Absturz bringen oder es so langsam machen, dass es sich schlicht nicht für die angedachte Aufgabe einsetzen lässt. Designfehler in der Architektur sind leicht zu finden, aber sehr schwierig – da kostspielig – zu beheben, denn die Behebung erfordert ein Redesign des Systems. Denken Sie an eine Spaghettiarchitektur, die nicht mehr beherrschbar ist, und führen Sie dann nachträglich eine Middleware ein. Die Kosten hierfür sind höher, als wenn die Middleware von Anfang an mit dabei gewesen wäre. Designfehler entstehen durch Fehler in der Erhebung und Analyse der gewünschten Qualitätsmerkmale und deren Abbildung auf die Architektur eines Systems.

Auch Überlast kann ein Softwaresystem zum Absturz bringen. Wenn die benötigte Kapazität die verfügbare Kapazität sprengt, wird sich das System erratisch verhalten. Langsame Antwortzeiten sind dann nur ein Symp­tom der Überlast. Eine bekannte Ursache für Überlast sind Denial-of-Service-Angriffe.

Sneaks [2] sind Fehler, die in bestimmten Zuständen eines verteilten Systems zu Problemen führen. Nicht alle Zustände eines Systems lassen sich aufgrund der großen Anzahl möglicher Kombinationen testen. Zudem bestehen verteilte Systeme aus verschiedenen Komponenten, die aus praktischen Gründen nicht in ih...

Java Magazin
Teil 11: Verfügbarkeit von Websystemen

Wir sind immer für Sie da

Websysteme sind komplex und anfällig gegen unterschiedliche Störungen. Dennoch ist Hochverfügbarkeit ein häufig gewünschtes Qualitätsmerkmal, insbesondere im E-Commerce. Eine hohe Verfügbarkeit bedeutet jedoch auch hohe Kosten im Betrieb und der Produktion eines Websystems. In diesem Artikel beschreiben wir, wie sich die Verfügbarkeit definieren und berechnen lässt, und einige Methoden, um sie zu verbessern.

Nicolas Bär, Daniel Takai


Verfügbarkeit gehört zum Qualitätsmerkmal der Widerstandsfähigkeit eines Systems (Resiliency). Tatsächlich wird sie in vielen Fällen als Synonym betrachtet [1]. In Kombination mit der Diskussion um Prüfbarkeit (Monitoring) und Wiederherstellbarkeit (Recoverability) ist es dem Webarchitekten möglich, verschiedene Maßnahmen zu definieren, die eine höhere Uptime eines funktionierenden Systems ermöglichen. Für uns bedeutet Resiliency, dass möglichst viele Störungen eines Systems bekannt und wir dagegen gewappnet sind. Die Konzepte rund um die Verfügbarkeit sowie das Zusammenspiel mit der Resiliency zeigt Abbildung 1.

Abb. 1: Konzepte rund um die Verfügbarkeit

Es gibt verschiedene Gründe, warum eine Komponente in unserem System versagen kann. Nebenläufigkeitsprobleme kommen häufig vor, denn Deadlocks, Race Conditions, Livelocks und Starvations sind schwierig mit Testfällen nachzustellen. Generell hat das Timing-Verhalten in verteilten Systemen einen Einfluss auf das Verhalten seiner Komponenten. Denken Sie nur an einen überlasteten Service, der nur wenige KB pro Minute liefert, und extrapolieren Sie dies auf das Verhalten Ihrer Anwendung.

Auch Designfehler können problematisch sein: Der falsche Entwurf eines Systems kann ein System zum Absturz bringen oder es so langsam machen, dass es sich schlicht nicht für die angedachte Aufgabe einsetzen lässt. Designfehler in der Architektur sind leicht zu finden, aber sehr schwierig – da kostspielig – zu beheben, denn die Behebung erfordert ein Redesign des Systems. Denken Sie an eine Spaghettiarchitektur, die nicht mehr beherrschbar ist, und führen Sie dann nachträglich eine Middleware ein. Die Kosten hierfür sind höher, als wenn die Middleware von Anfang an mit dabei gewesen wäre. Designfehler entstehen durch Fehler in der Erhebung und Analyse der gewünschten Qualitätsmerkmale und deren Abbildung auf die Architektur eines Systems.

Auch Überlast kann ein Softwaresystem zum Absturz bringen. Wenn die benötigte Kapazität die verfügbare Kapazität sprengt, wird sich das System erratisch verhalten. Langsame Antwortzeiten sind dann nur ein Symp­tom der Überlast. Eine bekannte Ursache für Überlast sind Denial-of-Service-Angriffe.

Sneaks [2] sind Fehler, die in bestimmten Zuständen eines verteilten Systems zu Problemen führen. Nicht alle Zustände eines Systems lassen sich aufgrund der großen Anzahl möglicher Kombinationen testen. Zudem bestehen verteilte Systeme aus verschiedenen Komponenten, die aus praktischen Gründen nicht in ih...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang