Operations heute und morgen, Teil 5: Big Data aus Betriebssicht

Inhaltsverzeichnis

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.

Mehr Infos

Operations heute und morgen

Das Business scheint aus IT-Sicht seine Anforderungen und Wünsche nach neuen und aktualisierten Features immer schneller zu ändern. Gleichzeitig gibt es innerhalb der IT fortwährend neue Trends, die umgesetzt werden wollen. Doch wo steht der IT-Betrieb bei der Umsetzung der Anforderungen und Wünsche? Haben die Entwickler mit dem agilen Trend die Mauern zum Business eingerissen, kam in den letzten Jahren zunehmend der Wunsch nach DevOps auf. Dev steht für Development/Entwicklung und Ops für Operations/Betrieb. Damit soll auch die Mauer zwischen Entwicklung und Betrieb überwunden werden. Doch was hat sich bisher wirklich durchgesetzt? Das betrachtet die Artikelserie "Operations heute und morgen":

• Das moderne IT-Unternehmen
• DevOps im Jahre 2015
• Virtualisierung & Containerisierung
• Hochverfügbarkeit
• Big Data aus Betriebssicht
• Monitoring

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-Architektur und 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.

Mehr Infos

Commodity Hardware?

Um Missverständnissen vorzubeugen: Bei Commodity Hardware handelt es sich keinesfalls um die billigstmögliche vom Discounter, sondern durchaus um hochwertige und leistungsfähige Hardware. Da man bei verteilten Systemen aber nicht mehr vertikal, sondern horizontal skaliert, muss es eben nicht mehr der Mainframe oder das hochgezüchtete Einzelsystem sein. Stattdessen nimmt man Server, die ein möglichst ideales Preis-Leistungs-Verhältnis aufweisen. Typisch für aktuelle Hadoop-Cluster sind zum Beispiel die
folgenden Spezifikationen:

• Dual Socket CPU mit 2+ GHz
• 128+ GByte RAM
• 12 (+ 2) Festplatten mit 3+ TByte 10G-Netzwerk

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.