Operations heute und morgen – Teil 5 – BigData

Die verteilten Systeme in Big-Data-Szenarien stellen auch die Betriebsmitarbeiter vor neue Herausforderungen. Deswegen muss der Grad der Automatisierung wachsen. Hierbei können betriebliche Innovationen wie Docker, Kubernetes oder Platform as a Service helfen.

Ob etablierter Hersteller, Start-up-Unternehmen oder Open-Source-Projekte – jeder macht heute Big Data, und man hat das subjektive Gefühl, dass jede Woche eine neue – natürlich noch bessere – Technik hinzukommt. Dabei reicht die Bandbreite von hoch performanten Speichertechniken aus der NoSQL-Ecke wie Apache Cassandra oder MongoDB über spezialisierte Suchprodukte wie Elasticsearch oder Apache Solr bis hin zum allumfassenden Hadoop-Zoo, der für jede Funktion ein passendes Tierchen zu haben scheint.

Schaut man sich weiterhin die neueren Datenarchitekturen in Unternehmen an, ist schnell zu erkennen, dass es nicht “die eine” Big-Data-Lösung gibt. Es bilden sich zwar Best Practices wie der Data Lake oder die Lambda-Architekturund Software-Stacks wie MEAN (MongoDB, Express, AngularJS, Node.js) () oder SMACK (Spark, Mesos, Akka, Cassandra, Kafka) heraus, doch solange nicht der nächste Schub in der Hardwareentwicklung erfolgt, ist ihnen allen gemein, dass es sich um verteilte Systeme handelt. Das erhöht den Grad an Komplexität. Und nicht nur das Design solcher Cluster-Systeme stellt Datenarchitekten vor ganz neue Herausforderungen, auch die Betriebsabteilungen der Unternehmen müssen sich in dieser neuen Welt erst mal orientieren.

Bare Metal und der Zen-Modus

Waren die vorherrschenden Themen in den Rechenzentren in den letzten Jahren vor allem Kosteneinsparungen durch Shared Storage, Virtualisierung und Containerisierung, schreit die Big-Data-Welt nun laut auf: “Zurück zum blanken Blech, möglichst nah ran an die Hardware!” Nun sind diese Forderungen aus Performancesicht durchaus nachvollziehbar, doch widersprechen sie damit meist diametral den Anforderungen, die bisher an die Betriebsabteilungen gestellt wurden. Da ist es nicht verwunderlich, dass in Unternehmen zwischen den einzelnen Abteilungen durchaus einige hitzige Diskussionen bei der Einführung einer Big-Data-Strategie geführt wurden und werden.

Doch wie genau sieht ein Big-Data-System nun aus Betriebssicht aus? Es gibt nicht “das eine” Big-Data-System, sondern eine Vielzahl, und jedes hat bedingt durch unterschiedliche Designziele und Architekturen seine Eigenheiten. Möchte man sie aber auf einen gemeinsamen Nenner bringen, handelt es sich um verteilte Systeme, die sich auf Commodity Hardware wohlfühlen, dabei horizontal skalieren und häufig starken Gebrauch von In-Memory-Verarbeitung machen. Somit sind die folgenden Überlegungen für den Aufbau und Betrieb eines (Open-Source-)Hadoop-Systems sicherlich nicht eins zu eins auf andere Systeme übertragbar. Da Hadoop aber ob seiner Komplexität quasi die Champions League des Betriebs von Big-Data-Systemen darstellt, gelten die folgenden Grundregeln auch für andere Systeme.

Die Expertise der Betriebsabteilung kommt spätestens ins Spiel, wenn es um den detaillierten Aufbau eines Hadoop-Clusters geht und die Auswahl der Hardware ansteht. Allgemein achtet man hierbei besonders auf die Ausgeglichenheit der Dreieinigkeit von CPU, RAM und Festplatten. Die Idee hierbei ist, sie in einen Zen-ähnlichen Zustand zu bringen, sodass sie sich bestmöglich ausnutzen lassen. Denn was nützen viele CPU-Kerne und viel GByte an RAM, wenn sich am Ende alle Prozesse um lediglich einen Disk-Channel streiten müssen?

Diese Grundidee verfolgt man später bei der Konfiguration des Ressourcenmanagers YARN (Yet Another Resource Negotiator) von Hadoop weiter. Prinzipiell verhält sich YARN wie ein Betriebssystem und unterteilt die gesamten Cluster-Ressourcen in Container, die dann dynamisch Benutzern und Prozessen zugewiesen werden. Deren Anzahl und Größe wiederum wird anhand des limitierenden Faktors aus dem Tripel CPU, RAM und Festplatten bestimmt. Hat man mit diesem Hintergrundwissen, den Empfehlungen der Hadoop-Distributoren und deren Best Practices letztlich die grundsätzliche Hardwarespezifikation bestimmt, kann man damit problemlos zu seinem bevorzugten Hardwarehersteller gehen, denn diese haben sich mittlerweile auf die Anforderungen von Hadoop und Big Data eingestellt und entsprechende Server in ihrer Produktpalette.

Ein typischer Hadoop-Cluster

Die Master-Slave-Architektur von Hadoop spiegelt sich auch im Aufbau eines Clusters wider. Während ein sinnvolles, verteiltes Minimal-Setup (z. B. als Proof of Concept oder Testsystem), aus lediglich vier Servern bestehen kann, setzt sich ein typischer produktiver Einstiegs-Cluster mit Hochverfügbarkeit meist aus acht Servern zusammen. Hierbei übernehmen drei Server die Rolle von Master Nodes zur internen Verwaltung der Hadoop-Services und die restlichen fünf die Rolle von Worker Nodes zum Speichern und Verarbeiten von Benutzerdaten.

Bei den Master Nodes kümmern sich zwei hochverfügbar (im Aktiv-Passiv-Verbund) “hauptberuflich” um die Verwaltung der Dateien im verteilten Dateisystem HDFS sowie um das Ressourcenmanagement mit YARN. Der dritte Master Node wird meist als Management Node bezeichnet und beherbergt die Master-Komponenten der anderen Hadoop-Services wie des Provisionierungs- und Management-Tools Ambari oder des SQL-Frameworks Hive. Sollten diese für ein Unternehmen besonders kritisch sein, lassen sie sich auch hochverfügbar aufsetzen. In größeren Hadoop-Clustern kann die Anzahl der Master Nodes noch anwachsen. Man kann etwa die beiden Services HDFS und YARN für höhere Ausfallsicherheit entzerren oder im Rahmen eines Sicherheitskonzeptes noch einen meist Edge Node genannten Server einführen, der via Apache Knox den sicheren Zugriff für nichtadministrative Benutzer gewährt. Generell ist die Anzahl der Master Nodes aber begrenzt und erhöht sich auch über die Lebenszeit eines Clusters nicht signifikant.

Das lässt sich über die Worker Nodes nicht behaupten, denn sie sind die eigentlichen Arbeitstiere des Hadoop-Clusters. Daher ist das Hinzufügen weiterer Worker Nodes ein Teil des Lebenszyklus des Clusters. Ihre Hauptaufgabe ist das verteilte Speichern von Benutzerdaten in Blöcken und das Bereitstellen ihrer Ressourcen über YARN, damit verteilte Frameworks wie MapReduce, Tez oder Spark parallele Berechnungen auf diesen Blockdaten durchführen können.

Während sich die Worker Nodes in Sachen CPU und RAM meist nicht signifikant von den Master Nodes unterscheiden, ist deren Festplatten-Layout grundlegend anders. Auf den Master Nodes hat man meist RAID-10 (Redundant Array of Independent Disks) im Einsatz, um die Betriebssystem-Partition so gut wie möglich zu schützen. Diese enthält unter anderem den Namespace und das Journal von HDFS. Und sollten sie verloren gehen, hat man im schlimmsten Fall Tera- oder Petabyte von Blockdaten auf den Worker Nodes, ohne sie zuordnen zu können – ein kompletter Datenverlust. Zusätzlich existieren dort häufig noch eigene Festplatten für die Hadoop-Logs und den Hilfsservice Zookeeper, da sie einen Disk Channel ganz gut strapazieren können.

Bei den Worker Nodes setzt man RAID – falls überhaupt – nur für die Betriebssystem-Partition ein. Dann reicht aber ein RAID-1 – da per Design der Verlust eines Worker Node zu verschmerzen ist, kümmert sich doch HDFS bereits softwareseitig um die Replikation der Nutzerdaten. Und weil der Standard-Replikationsfaktor 3 beträgt und weiterhin auch Rack Awareness unterstützt wird, reicht hier typischerweise ein Service Level Agreement (SLA) von 24 Stunden für die Reparatur oder den Ersatz eines Worker Node vollkommen aus. Die Nutzerdaten selbst werden auf Festplatten (meist so viele, wie der Festplattenkäfig zulässt) in einer JBOD-Konfiguration (Just a Bunch of Disks) gespeichert. Hier wäre RAID also sogar hochgradig kontraproduktiv. Stattdessen mountet man die Festplatten einzeln, trägt sie in die Konfigurationsdatei von HDFS ein und überlässt so dem virtuellen Dateisystem HDFS die Verwaltung seiner eigenen Blöcke im physischen Dateisystem wie ext3 oder XFS.

Und was ist mit Shared Storage, Virtualisierung und der Cloud?

Alles berechtigte Einwände, drehten sich doch die bisherigen Überlegungen allein um Bare-Metal-Server. Das allerdings nicht ohne Grund, denn dies ist nach wie vor das Ideal der Big-Data-Welt und auch das Modell, das man derzeit am häufigsten in Unternehmen antrifft. Doch gerade aus Betriebssicht können auch andere Faktoren wichtig sein und ein Abweichen vom Ideal rechtfertigen. Denn was passiert jetzt zum Beispiel mit einem Storage Area Network (SAN) wie EMCs Isilon, das man in den letzten Jahren mühsam eingeführt hat? Muss man nun wirklich wieder zurück auf einzelne Festplatten gehen? Oder lassen sich diese Welten verknüpfen?

In der Tat gibt es hierzu einen Ausweg. Isilon dient in diesem Setup als HDFS-Speicherdienst, und die Worker Nodes benötigen folglich keine eigenen Festplatten mehr. Somit sind sie eigentlich nur noch Compute Nodes, die über YARN ihren Arbeitsspeicher und ihre Gigahertz zur Verfügung stellen. Aus betrieblicher Sicht hat dieses Setup für manche Unternehmen sicherlich seinen Charme, allerdings sollte man sich im Klaren darüber sein, dass – bildlich gesprochen – höchstwahrscheinlich das Kabel zur Isilon der Engpass dieses Clusters wird.

Und was ist mit Virtualisierung? Auch das widerspricht dem Ideal von Big Data etwas, allerdings wird der Verlust durch Virtualisierung meist in der Region von 5 bis 10 Prozent beziffert, was für manche Unternehmen und Anwendungsfälle aufgrund der betrieblichen Vorteile durchaus eine Überlegung wert sein sollte.

Häufig sieht man in diesem Bereich auch eine Mischform, da zum Beispiel bei Hadoop die Master Server meist nicht den Performance-Engpass darstellen und sich daher gut virtualisieren lassen. Bei den Worker Nodes muss man hier schon deutlich vorsichtiger sein, und bei der Virtualisierung sollten zumindest die Festplatten direkt auf die virtuellen Maschinen (VM) gemappt werden, da das sonst zum spürbaren Engpass mit entsprechenden Performance-Einbußen wird. Auch müssen zusätzlich die einer VM zugewiesenen Ressourcen mit den über YARN konfigurierten Containern in Einklang gebracht werden, was die ohnehin komplexe Konfiguration eines Hadoop-Cluster nicht vereinfacht.

Öffentliche Cloud-Angebote haben in den meisten deutschen Unternehmen immer noch einen schweren Stand, locken aber mit einem schnellen und kostengünstigen Einstieg – gerade auch in die verteilte Welt. In der Realität scheuen viele Unternehmen gerade in der Proof-of-Concept-Phase für ein Big-Data-System die meist hohen Anfangsinvestitionen in Hardware, die sich bei einem Fehlschlag potenziell gar nicht oder bei Erfolg erst über mehrere Jahre rechnen. Daher sind die vielfältigen Angebote der großen Cloud-Anbieter wie Amazon Web Services (AWS), Microsoft Azureoder Google Cloud Platform gerade in dieser Phase attraktiv. Und alle Anbieter bieten mindestens die Möglichkeit, sowohl eigene Big-Data-Cluster in der Cloud auf gemieteter Hardware zu betreiben als auch zusätzliche Mehrwert-Services wie Amazon Elastic MapReduce oder Google Cloud Dataproc.

Am deutlichsten macht aber Microsoft mit seinem Angebot HDInsight, welch essenzieller Teil der eigenen Cloud-Strategie Big Data ist. Kunden können einen vollumfänglichen Hadoop-Cluster mit allen Services wie Hive, HBase, Storm und Spark als Managed Service mieten und sich aufgrund der benutzerfreundlichen UI direkt dem Verarbeiten von Daten zuwenden, ohne sich zu sehr mit den komplexen Interna von Hadoop aufzuhalten.

Die Zukunft: Docker, Kubernetes und Big Data als Managed Service

Das zeigt zugleich die zukünftige Entwicklung auf, denn eigentlich steht doch bei allen Diskussionen über den Betrieb von Big-Data-Systemen die Beschäftigung mit Daten über allem, und das ist der Hauptgrund, warum Unternehmen in Hardware investieren. Der Betrieb von Big-Data-Systemen wird sich daher weiter automatisieren, und die Betriebsmannschaften weltweit werden ihr Bestmögliches dazu beitragen, die Komplexität und damit den Schrecken aus Big-Data-Systemen zu nehmen. Dazu tragen Softwareentwicklungen wie Apache Ambari oder CloudBreak bei, aber auch das Verschmelzen mit weiteren Innovationen aus dem Betriebsbereich wie Docker und Kubernetes.

Das lässt sich derzeit etwa beim Zusammengehen der NoSQL-Datenbank MongoDB mit OpenShift beobachten. Das Modell baut auf einem gemeinsamen Basis-Docker-Image auf, das unterschiedlich konfiguriert und instrumentiert innerhalb von Kubernetes-Pods die unterschiedlichen MongoDB-Prozesse startet, die wiederum ihre Daten in per NFS angebunden Ordnern persistieren. Das hat aus betrieblicher Sicht den Charme, dass sich während der Lebenszeit eines MongoDB-Clusters für jeden Service ein Replication Controller um die Verteilung und den Neustart der vorher definierten Anzahl von Pods kümmert. Zudem ist diese Konfiguration nur einmal initial durchzuführen, danach erfordern das Vergrößern eines Replica Set oder das Hinzufügen von Shards für den Betrieb nur einen einfacher Klick in der OpenShift-Oberfläche.

Von diesem Modell macht in Deutschland zum Beispiel bereits der Betreiber T-Systems bei seiner PaaS-Plattform AppAgile Gebrauch. Da ist es nur eine Frage der Zeit, bis diese Entwicklung auch für weitere Big-Data-Systeme und vor allem auch für das komplexere Hadoop-Ökosystem folgen wird.

Fazit: Flexibilität als entscheidender Faktor

Big Data stellt auch Betriebsmitarbeiter vor neue Herausforderungen und scheint die bisherigen Entwicklungen zur Kosteneinsparung wie Shared Storage oder Virtualisierung mit dem lauten Ruf nach Bare Metal in Frage zu stellen. Aufgrund derKomplexität verteilter Systeme ist deren Betrieb nicht trivial und der Grad der Automatisierung muss noch weiter wachsen – genauso wie die Expertise und Erfahrungswerte der Betriebsmitarbeiter. Ihnen kommt hierbei eine wichtige Rolle zu, und es reicht in dieser Welt nicht mehr aus, ein paar Prozesse zu überwachen, sondern es wird gerade beginnend im Betrieb ein tiefgründiges Wissen über die komplexen Zusammenhänge benötigt.

Dabei versperren sich die Big-Data-Angebote auch nicht den betrieblichen Innovationen wie Docker, Kubernetes oder OpenShift, sodass diese Welten weiter zusammenwachsen werden. Das ist auch dringend notwendig, denn in der schnelllebigen Big-Data-Welt wird Flexibilität im Betrieb und damit größtmögliche Kombinationsfreiheit bei der Wahl von Datenarchitekturen die Trumpfkarte sein, die es Unternehmen ermöglichen wird, das volle Potenzial aus ihren Daten zu schöpfen und so Mitbewerber auszustechen.

Quelle: http://www.heise.de/developer/artikel/Operations-heute-und-morgen-Teil-5-Big-Data-aus-Betriebssicht-3074778.html