Tag: Hochverfügbarkeit

Categories
Kommentar

Cloud Computing ist nicht einfach!

Cloud Computing verspricht vermeintlich einfach zu sein. Hier und da einen virtuellen Server starten und fertig ist die eigene virtuelle Cloud Infrastruktur. Wer nun meint, dass ich mit der Aussage recht habe, der liegt dermaßen falsch. Virtuelle Server sind nur ein kleiner Bestandteil einer virtuellen Infrastruktur bei einem Cloud Anbieter. Ein paar virtuelle Maschinen machen noch lange keine Cloud. Die Komplexität liegt in dem, wie die Architektur der Applikation geschaffen ist. Und somit in der Intelligenz, die der Architekt und der Softwareentwickler ihr vereinleibt. Das dies manchmal nicht so umgesetzt wird, haben uns die einen oder anderen Cloud Nutzer nicht nur einmal eindrucksvoll gezeigt. Regelmäßig fallen immer die selben Verdächtigen aus, wenn deren Cloud Anbieter mal wieder mit sich selbst zu kämpfen hat. Cloud Computing ist nicht einfach! Ich meine hiermit nicht simples Software-as-a-Service (SaaS). Ich spreche von Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) und hier sogar noch granular von der Königsklasse namentlich Skalierbarkeit und Hochverfügbarkeit. Und genau das sollte man Abseits des Marketing der Cloud Anbieter verstehen und uneingeschränkt berücksichtigen, wenn man Cloud Computing erfolgreich einsetzen möchte.

Software-defined Scalability und Software-defined High-Availability

Derzeit kursieren wieder neue Begriffe durch die IT-Stratosphäre. Software-defined Networking (SDN) und auch Software-defined Datacenter (SDD). Ein SDN führt eine weitere Abstraktionsebene oberhalb der Netzwerkkomponenten ein. Typischerweise besitzt jeder Router und Switch seine eigene lokale Software, über die er per Programmierung mit Intelligenz versorgt wird. Der Netzwerkadministrator sagt dem Router somit bspw. welches Paket unter welchen Bedingungen wohin geleitet werden soll oder auch nicht. Innerhalb eines SDN entfällt die Aufgabe jeder einzelnen Komponente für sich eine lokale Intelligenz einzuverleiben. Die Intelligenz wandert eine Ebene höher in eine Managementschicht, in der das gesamte Netzwerk designed wird und die einzelnen Regeln für jede Komponente zentral festgelegt wird. Ist das Design fertiggestellt, wird es über die Netzwerkkomponenten ausgerollt und das Netzwerk ist konfiguriert. Mit SDN soll es daher möglich sein ein vollständiges Netzwerkdesign “per Knopfdruck” zu verändern, ohne jede einzelne Komponente direkt anfassen zu müssen.

Die Idee des SDN Konzepts muss bei der Nutzung einer Cloud-Infrastruktur ebenfalls zwingend in Betracht gezogen werden. Denn der Einsatz eines PaaS aber noch viel mehr eines IaaS bedeutet sehr viel Eigenverantwortung. Mehr als man auf dem ersten Blick denken mag. Eine oder zwei virtuelle Maschinen zu starten bedeutet nicht, dass man eine virtuelle Cloud Infrastruktur nutzt. Es sind und bleiben zwei virtuelle Server. Ein IaaS Anbieter stellt darüber hinaus nur die Komponenten, wie die genannten virtuellen Maschinen, Speicherplatz, weitere Services und zusätzlich APIs bereit, mit denen die Infrastruktur genutzt werden kann. Unterm Strich lässt sich vereinfacht sagen, dass ein IaaS Anbieter seinen Kunden nur die Ressourcen und entsprechenden Werkzeuge zur Verfügung stellt, um damit auf seiner Cloud Infrastruktur eine eigene virtuelle Infrastruktur respektive ein eigenes virtuelles Rechenzentrum aufzubauen.

Man muss daher per Software (die eigene Applikation) selbst dafür sorgen, dass die Cloud Infrastruktur bei Bedarf skaliert (Software-defined Scalability, SDS) und im Falle eines Ausfalls einer Cloud Infrastruktur-Komponente berücksichtigen, dass entsprechend eine Ersatzkomponente (z.B. virtuelle Maschine) gestartet wird und die Ausgefallene damit ersetzt wird (Software-defined High-Availability, SDHA). Die Software sorgt also für die Skalierbarkeit und Hochverfügbarkeit der genutzten virtuellen Cloud Infrastruktur, damit die Web-Applikation selbst skaliert und ausfallsicher ist und den Charakter der jeweiligen Cloud eines Anbieters nutzt und das Maximum aus ihr schöpft.

Wie eine Cloud Computing Infrastruktur quasi in Perfektion genutzt wird zeigt Netflix eindrucksvoll.

Cloud Computing ist nicht einfach! Begreif's doch endlich, ...

Quelle: Adrian Cockcroft

Netflix das Paradebeispiel

Netflix ist mit Abstand der größte Cloud Service weltweit. Der Video-Streaming Dienst ist während Spitzenzeiten mittlerweile für ein Drittel des gesamten Internetverkehrs verantwortlich. Diese Nutzeranfragen gilt es selbstverständlich performant und zu jedem Zeitpunkt zu beantworten. Dazu setzt Netflix schon seit seinem Start im Jahr 2009 auf Cloud Technologien und hat im November 2012 seinen vollständigen Technologie-Stack und die darauf basierende Infrastruktur in die Cloud zu den Amazon Web Services verlagert. Hier laufen rund 1.000 virtuelle auf Linux basierende Tomcat Java Server und NGINX Web-Server. Hinzu kommen weitere Services wie Amazon Simple Storage Service (S3) und die NoSQL Datenbank Cassandra in Verbindung mit Memcached sowie ein verteiltes Memory Object Caching.

Das ist jedoch nur die eine Seite der Medaille. Viel wichtiger ist die Nutzung mehrerer Availability Zones in der Amazon Cloud. Netflix nutzt insgesamt drei Availability Zones, um die Verfügbarkeit und Geschwindigkeit des eigenen Service zu erhöhen. Tritt in einer Availability Zone ein Problem auf, ist die Architektur der Netflix-Applikation so ausgelegt, dass der Service durch die anderen beiden weiterlaufen kann. Dabei hat Netflix sich nicht auf die reinen Marketing-Versprechen von Amazon verlassen, sondern mit dem Chaos Gorilla selbst eine eigene Software entwickelt, mit der die Stabilität der virtuellen Server Amazon Elastic Compute Cloud (EC2) getestet wird. Kurzum wird dabei der Ausfall einer kompletten EC2 Region bzw. Availability Zone simuliert, um sicherzustellen, dass der Netflix-Service im Ernstfall weiterhin funktioniert. Eine der größten Herausforderungen besteht dabei darin, dass im Falle eines Fehlers in einer Amazon Zone, das Domain Name System (DNS) automatisch neu konfiguriert wird, damit die Netflix Kunden von dem Ausfall nichts mitbekommen. Die unterschiedlichen APIs der DNS-Anbieter machen die Aufgabe hier allerdings nicht einfacher. Zudem sind die meisten so entwickelt worden, dass die Einstellungen noch manuell vorgenommen werden müssen, was es nicht einfacher macht, dies zu automatisieren.

Unterm Strich ist zu sagen, dass Netflix für den Fehlerfall vorausschauend plant und sich nicht auf die Cloud verlässt. Denn irgendwas läuft auch mal in der Cloud schief, wie in jedem gewöhnlichen Rechenzentrum auch. Mann muss nur darauf vorbereitet sein. Wer sich mehr dafür interessiert, was Netflix macht um diesen Zustand zu erreichen sollte “Netflix: Der Chaos Monkey und die Simian Army – Das Vorbild für eine gute Cloud Systemarchitektur” lesen.

Die Einfachheit zählt

Vielleicht verlange ich noch zu viel. Schließlich ist Cloud Computing in seiner Form ein relativ junges Konzept. Dennoch zeigt Netflix eindrucksvoll das es funktioniert. Wenn man jedoch bedenkt, was für einen Aufwand Netflix betreibt, um in der Cloud erfolgreich zu sein, muss man einfach sagen, dass Cloud Computing nicht einfach ist und eine Cloud Infrastruktur, egal bei welchem Anbieter, mit der entsprechenden Architektur aufgebaut werden muss. Das bedeutet im Umkehrschluss, dass die Nutzung der Cloud simpler werden muss, um auch die versprochenen Kostenvorteile zu erzielen. Denn wenn man Cloud Computing richtig nutzt, ist es zwangsläufig nicht günstiger. Neben den Einsparungen der Infrastrukturkosten die immer vorgerechnet werden, dürfen niemals die weiteren Kosten z.B. für das Personal mit den notwendigen Kenntnissen und die Kosten für die Entwicklung der skalierbaren und ausfallsicheren Applikation in der Cloud vernachlässigt werden.

Das erfreuliche ist, dass ich erste Startups am Horizont sehe, die sich der Problematik annehmen und den einfachen Bezug von fertigen Cloud Ressourcen, ohne als Nutzer selbst auf Skalierbarkeit und Hochverfügbarkeit achten zu müssen, zu ihrer Aufgabe gemacht haben.

Categories
Management @de

IaaS: Sie selbst sind für die Hochverfügbarkeit und Skalierbarkeit verantwortlich

Cloud Computing Architekturen unterscheiden sich grundsätzlich von traditionellen Systemmodellen. Aber um die Hochverfügbarkeit, Skalierbarkeit usw. der Cloud tatsächlich zu nutzen, gilt es die Prinzipien des Cloud Computing, aber vor allem die Infrastruktur des jeweiligen Anbieter, speziell im Falle von IaaS (Infrastructure-as-as-Service), bis ins Detail zu durchdringen und bestmöglich für sich und das eigene System zu nutzen.

Die Freude kommt während des Falls

Die jüngsten Ausfälle haben gezeigt, dass viele Nutzer sich nicht mit der Cloud selbst und der des jeweiligen Anbieters auseinandergesetzt haben. Andere hingegen haben direkt von Beginn an viele Anstrengungen unternommen, um ihre Systeme Cloud gerecht zu entwickeln und wurden nicht von plötzlichen bzw. unvorhersagbaren Ereignissen in die Knie gezwungen. Man sollte daher meinen, dass gute Cloud Architekten einen Freudentanz aufführen, wenn der Anbieter dann doch einmal unerwartet Probleme hat und sie sich mit ihren eigenen robusten System brüsten können.

Da gibt es doch bestimmt Lessons Learned

Wenn man selbst keine Ahnung, dann fragt man jemanden der sich damit auskennt oder schaut im besten Fall, wie die anderen mit solchen Szenarien umgehen.

Bevor sich ein Unternehmen also in die Cloud begibt, sollten die Verantwortlichen also viel Zeit damit verbringen, das System des Anbieters zu verstehen und zunächst Test-Systeme innerhalb der Infrastruktur aufzubauen, bevor es in den Produktivbetrieb geht.

Everything fails everytime

Als Verantwortlicher sollte man sich immer bewusst machen, dass irgendetwas zu jedem Zeitpunkt immer einen defekt erleiden kann. Und genau so sollte auch die Architektur des Systems auf der Cloud entwickelt werden. Jedes System muss unabhängig von den anderen Systemen einwandfrei funktionieren. Das bedeutet, dass jedes System innerhalb der verteilten Architektur so entwickelt werden muss, dass es darauf vorbereitet ist, den Ausfall anderer Teilsysteme, zu denen Abhängigkeiten bestehen, zu tolerieren.

Eigene Tools für den Betrieb des Systems

On-Demand Video Anbieter Netflix hat für den Betrieb seines Systems in der Amazon Cloud eine Reihe von eigenen Tools entwickelt, die sicherstellen, dass das Angebot zu jederzeit verfügbar ist und Instanzen, die nicht mehr einwandfrei funktionieren ausgetauscht werden. So zerstört bspw. der Chaos Monkey zufällig Instanzen und Services innerhalb der Architektur, um damit den unabhängigen Betrieb der einzelnen Komponenten fortlaufend zu testen. Der Chaos Gorilla geht sogar noch einen Schritt weiter und simuliert den kompletten Ausfall einer Amazon Availability Zone, um damit zu prüfen, dass die Systeme in einer anderen Zone die Aufgaben übernehmen.

Anforderungen und Bedürfnisse klären

Der Betrieb in einer Cloud unterscheidet sich vollständig von dem in einem traditionellen Rechenzentrum. Hochverfügbarkeit und Skalierbarkeit werden per se von einer Cloud Infrastruktur erwartet, ein Hirngespinst, dass sich noch in vielen Köpfen von Verantwortlichen befindet. Richtig ist, dass der Anbieter für die Hochverfügbarkeit seiner Infrastruktur sorgen muss. Allerdings hat er mit den Systemen, die von den Kunden auf der Cloud betrieben werden nichts zu tun.

IT-Verantwortliche müssen sich daher die Fragen stellen, wie moderne Architekturen in der Cloud sicher aufgebaut und betrieben werden können und welche Auswirkungen dies auf die Planungs- und Betriebs-Prozesse hat. Schlussendlich wird sich aber ebenfalls die Komplexität der Architektur erhöhen, wenn die Applikationen und Systeme in die Cloud verlagert werden.

Bildquelle: ©Gerd Altmann / PIXELIO

Categories
Management @de

Netflix: Der Chaos Monkey und die Simian Army – Das Vorbild für eine gute Cloud Systemarchitektur

Die letzten Ausfälle bei den Amazon Web Services (AWS) hier und hier haben gezeigt, dass bei manchen Kunden wie bspw. Instagram, die Systemarchitektur nicht auf das Cloud Computing ausgelegt ist. Und auch wenn AWS so etwas nicht (mehr) passieren darf, sollte man selbst darauf achtgeben, präventiv auf den möglichen Ernstfall vorbereitet zu sein. Eine Möglichkeit ist der von Netflix entwickelte Chaos Monkey und weitere Tools, die ich in diesem Artikel vorstellen möchte.

Üben, Lernen, Testen

Bevor sich Netflix für den Einsatz seines Systems auf den Amazon Web Services entschieden hat (Migration von einer eigenen Infrastruktur), verbrachte das Unternehmen viel Zeit damit, um die AWS Plattform zu verstehen und ein Test-System innerhalb der Infrastruktur aufzubauen. Dabei wurde insbesondere darauf geachtet, soviel realistischen Traffic bzw. Traffic Szenarien wie möglich zu erzeugen, um damit das Test-System auf seine Stabilität hin zu prüfen.

Anfangs entwickelte Netflix dazu einen einfachen Repeater, der die echten und vollständigen Kundenanfragen auf das System innerhalb der AWS Infrastruktur kopierte. Damit identifizierte Netflix die möglichen Engpässe seiner Systemarchitektur und optimierte im Zuge dessen die Skalierbarkeit.

Netflix Rambo Architektur

Netflix selbst bezeichnet seine Software Architektur gerne auch als Rambo Architektur. Das hat den Hintergrund, dass jedes System unabhängig von den anderen Systemen einwandfrei funktionieren muss. Dazu wurde jedes System innerhalb der verteilten Architektur so entwickelt, dass es darauf vorbereitet ist, dass andere Systeme zu denen eine Abhängigkeit besteht, ausfallen können und das dieses toleriert wird.

Sollte das Bewertungssystem ausfallen, verschlechtert sich zwar die Qualität der Antworten, aber es wird dennoch eine Antwort geben. Statt personalisierten Angeboten werden dann nur bekannte Titel angezeigt. Sollte das System, dass für die Suchfunktion zuständig ist, unerträglich langsam sein, muss das Streaming der Filme trotzdem einwandfrei funktionieren.

Der Chaos Monkey

Eines der ersten Systeme die Netflix auf bzw. für AWS entwickelt hat, nennt sich Chaos Monkey. Sein Job ist es zufällig Instanzen und Services innerhalb der Architektur zu zerstören. Damit stellt Netflix sicher, dass alle Komponenten unabhängig voneinander funktionieren, selbst dann wenn Teil-Komponenten ein Problem haben.

Neben dem Chaos Monkey hat Netflix viele weitere Monitoring und Test-Tools für den Betrieb seines Systems auf den Amazon Web Services entwickelt, die das Unternehmen als The Netflix Simian Army bezeichnet.

Latency Monkey

Der Latency Monkey induziert künstliche Verzögerungen im Netflix eigenem REST-Client-Server Communication-Layer, um einen Leistungsabfall zu simulieren und rechtzeitig Maßnahmen zu ergreifen bzw. im Vorwege angemessen zu reagieren. Indem sehr große Verzögerungen erzeugt werden, kann damit zudem der Ausfall eines Nodes oder eines vollständigen Service simuliert werden, ohne diese Instanzen tatsächlich zu zerstören. Damit wird die Fehlertoleranz eines neuen Service überprüft, indem der Ausfall seiner Abhängigkeiten simuliert wird. Der Ausfall dieser Abhängigkeiten wirkt sich dabei jedoch nicht auf den Rest des Systems aus.

Conformity Monkey

Der Conformity Monkey findet Instanzen, die nicht den Best-Practices Anforderungen entsprechen und fährt diese herunter. Wenn z.B. Instanzen gefunden werden, die nicht zu einer Auto-Scaling Group gehören, weiß der Conformity Monkey, dass dieses zu Problemen führen wird. Diese werden also heruntergefahren, um dem Service-Owner die Gelegenheit zu geben, neue Instanzen mit den erwarteten Eigenschaften hochzufahren.

Doctor Monkey

Der Doctor Monkey überprüft die Health Checks, die sich auf jeder Instanz befinden und überwacht zudem weitere Eigenschaften, wie bspw. die CPU-Auslastung, um mögliche Fehlerquellen innerhalb der Instanzen selbst zu erkennen. Werden fehlerbehaftete Instanzen entdeckt, werden diese zunächst automatisch vom Service entfernt. Anschließend erhält der Service-Owner die Gelegenheit die Ursache für den Fehler zu finden und beendet diese Möglicherweise um stattdessen neue Instanzen zu starten.

Janitor Monkey

Der Janitor Monkey sorgt dafür, dass die Netflix Cloud Umgebung effizient betrieben wird und sich kein Müll oder überschüssige Instanzen anhäufen. Dazu sucht er nach ungenutzten Ressourcen und sorgt dafür, dass diese verschwinden.

Security Monkey

Der Security Monkey ist eine Erweiterung des Conformity Monkey. Er findet Sicherheitslücken oder Schwachstellen wie falsch konfigurierte AWS Security Groups und beendet die beanstandeten Instanzen. Er stellt zudem sicher, dass alle SSL-und DRM-Zertifikate gültig sind.

10-18 Monkey

Der 10-18 Monkey (steht auch für Lokalisierung-Internationalisierung bzw. l10n-i18n) erkennt Konfigurations- und Laufzeit Probleme innerhalb von Instanzen, die Kunden in verschiedenen geografischen Regionen, mit unterschiedlichen Sprachen und Zeichensätze bedienen.

Chaos Gorilla

Der Chaos Gorilla ist vergleichbar mit dem Chaos Monkey, simuliert allerdings einen vollständigen Ausfall einer Amazon Availability Zone. Damit wird sichergestellt, dass die Funktionalität des Systems automatisch in andere Availability Zones verschoben wird, ohne das ein manueller Eingriff von Netflix erforderlich ist und das der Nutzer davon etwas bemerkt.

Fazit

Die Simian Army von Netflix ist ein Extrembeispiel wie eine Cloud Architektur auszusehen hat. Das Unternehmen hat viel Zeit, Anstrengungen und Kapital in die Entwicklung seiner Systemarchitektur investiert, die auf der Cloud Infrastruktur der Amazon Web Services läuft. Aber es lohnt sich und jedes Unternehmen, das die Cloud ernsthaft nutzen möchte und ein hochverfügbares Angebot präsentieren will, sollte sich Netflix unbedingt zum Vorbild nehmen.