Back to top

Amazon Web Services gegen Microsoft Azure – Ein Rennen um Big Data in der Cloud?

Einblicke aus dem Alltag eines Ingenieurs an vorderster Front

Die explosionsartige Entwicklung bei Big Data in den letzten Jahren hat die Marktführer im Cloud Computing in ein ständiges Wettrennen gestürzt, stets die besten Lösungen für Big Data in der Cloud für die Geschäftsanforderungen zu liefern. Amazon Web Services (AWS) ist seit langem für Skalierbarkeit, Flexibilität und Erschwinglichkeit bekannt, Microsoft Azure hat sich als leistungsfähige, vielseitige Cloud-Plattform der Unternehmensklasse etabliert.

Bob Hummel, unser Experte für Cloud-Einsatz von Big Data, hat erst vor kurzem eine Migration von AWS auf Microsoft Azure für einen Kunden vorgenommen. Nutzen wir das als Gelegenheit, einen tieferen Einblick in dieses Thema zu gewinnen. Also habe ich mich in Marley’s Brewery and Grill mit Bob getroffen, der nach einem langen Tag schwerster Arbeit noch die Kraft gefunden hat, uns seine Erkenntnisse weiterzugeben.

 

Paul Nelson:  Fangen wir mit AWS an. Wie lange hat es gedauert, ein produktionsfähiges Big Data-System über Cloudera auf AWS zu erstellen? Sagen wir, wirklich vom Anfang der Programmierung bis zur Aufnahme in die Produktion, lassen wir die Planungszeit mal außen vor.

Bob Hummel:  Etwa drei Wochen. Ich hatte vor diesem Einsatz von Cloudera auf AWS schon verschiedene Open-Source-Systeme mit Hadoop entwickelt. Aber bei AWS musste ich einige Besonderheiten beachten, wie etwa die Auflösung von IP-Adressen, die Mittelwert-Algorithmen für die Synchronisation der logischen Uhren, das Öffnen von Ports und dergleichen mehr, damit das System problemfrei läuft. 

Paul:  Die Herausforderungen lagen also bei der Auflösung von IP-Adressen, der Synchronisation der logischen Uhren und dem Öffnen von Ports. Kannst du da etwas mehr ins Detail gehen?

Bob:  Gerne. Bei den IP-Adressen war die Netzwerkdatei /etc/sysconf/ von Amazon automatisch eingerichtet, der interne Domänenname war als „localhost“ definiert, nicht mit dem Domänennamen des Rechners. Das bedeutet, dass Prozesse in Hadoop einander nicht finden konnten. Daher mussten die Domänennamen überall vollqualifiziert werden, einschließlich in /etc/hosts. 

Das Problem mit den Ports war, dass es etwas gedauert hat, die gesamte Liste der Ports zu bestimmen, sodass die Hadoop-Prozesse miteinander kommunizieren konnten. 

Die Synchronisation der Uhren war eher ein kleineres Problem, das zusammen mit einigen anderen kleineren Problemen gelöst wurde, die hier und da angefallen sind.

Im Prinzip mussten wir die gesamten Installationsanweisungen für Hadoop Schritt für Schritt durchgehen und sicherstellen, dass wirklich alles, einschließlich der SELinux-Sicherheitseinstellungen, von Anfang an korrekt konfiguriert war.

Paul:  Welche Art von Rechnern habt ihr für AWS eingesetzt?

Bob:  Ich glaube, wir haben M3 2XLarge mit 32GB RAM, 8 Kernen und Amazon Elastic Block Storage (EBS) für das Hadoop Distributed File System (HDFS) eingesetzt. [Anmerkung: HDFS ist ein hochgradig fehlertolerantes verteiltes Dateisystem, entworfen, um auf preisgünstiger Hardware eingesetzt zu werden.] 

Paul:  Wie lange hat dann die Migration der Big Data-Anwendung von AWS auf Microsoft Azure gedauert?

Bob:  Oh, das hat lange gedauert. Ich erinnere mich kaum noch an die gesamte Dauer. Ich glaube, das waren um die neun Monate.

Paul:  Neun Monate? Ernsthaft? Warum hat das so lang gedauert?

Bob:  Ein Bottleneck war, dass die Festplatten bei Azure deutlich langsamer waren als bei AWS. Zusätzlich dazu hatten wir häufige Spitzen in der Latenz der Festplatten, sodass die Cloudera-Knoten sich verweigerten und ein Neustart erforderlich wurde. Als Beispiel: Wenn ein Cloudera-Datenknoten versucht hat, auf eine Festplatte zuzugreifen, und Azure minutenlang gebraucht hat, um auf diese Anforderung zu reagieren, hat der Rechner sich gesperrt. Wenn ein Rechner sich auf diese Art gesperrt hat, ist der Cloudera Manager davon ausgegangen, dass der Rechner abgestürzt sei. In dem Fall wurde dann eine neue Instanz gestartet und der alte Prozess aufgegeben.

Paul:  Und wie habt ihr das Problem dann schließlich gelöst?

Bob:  Eher durch Zufall. Wir mussten auf die neuste Version der Linux Integration Services aktualisieren, damit iostat (Input/Output-Statistik) uns die Logs liefert, die Microsoft Support benötigt. Nach dem Upgrade war das Problem mit der Latenz verschwunden. Anscheinend hat das Upgrade auch eine Reihe Verbesserungen an der Leistung enthalten, hinsichtlich der Kommunikation zwischen Linux und der Microsoft Hyper-V Visualisierungsumgebung. Diese Änderungen haben das Problem dann gelöst.

Andererseits hätte ein Wechsel auf Azure Premium Storage dieses Problem ebenso gelöst, leider war dieser Dienst aber nicht für die von uns benötigte Region verfügbar. [Anmerkung: Dieser Dienst ist aktuell nur für USA West, USA Ost 2, Westeuropa, Ostchina, Südostasien und Japan West verfügbar.] Unsere Server mussten aus rechtlichen Gründen in der Region Nordeuropa eingesetzt werden, das war von den Ländern abhängig, in denen die Daten unseres Kunden gehostet werden. Mehr dazu findet man auch in der Cloudera Referenzarchitektur für Azure.

Paul:  Was gab es sonst noch für Herausforderungen, die für diese lange Verzögerung im Einsatz von Cloudera auf Azure gesorgt haben?

Bob:  Es gab auch Schwierigkeiten mit dem Netzwerk, wir hatten ursprünglich ein einzelnes Speicherkonto für den gesamten Cluster erstellt. Deshalb haben wir dann den Speicherplatz neu strukturiert (ein Speicherkonto pro Host) und die Anzahl der Festplatten pro Host von vier auf zehn angehoben. Außerdem haben wir auch die Größe der Festplatten auf je 1 TB angehoben und von geo-redundantem auf lokal-redundanten Speicher gewechselt.

Ein anderes Problem war die mangelnde Automatisierung und die fehlende benutzerfreundliche Schnittstelle. Das Azure Web Portal kann gelegentlich recht langsam und zäh sein. Es ist ein ziemlicher Aufwand, alles selbst über PowerShell zu automatisieren, um die Einrichtung des gesamten Clusters zu vereinfachen.

Paul:  Wie ware es mit Netzwerkangelegenheiten, IP-Adressen und Domänennamen bei Gruppen von Rechnern?

Bob:  Oh, ja, da erinnere ich mich noch dran. In AWS sind alle Rechner individuell ansprechbar. In Azure werden Rechner in einen „Clouddienst“ eingruppiert, sodass alle auf denselben Domänennamen, aber unterschiedliche Ports reagieren.

Paul:  Wie spricht man diese unterschiedlichen Ports auf demselben Rechner an?

Bob:  Die verschiedenen Ports sind nur für den externen Zugriff auf individuelle Rechner gedacht. Intern kommunizieren die Rechner ganz normal miteinander. Allerdings war das ganz anders gelöst als bei AWS, daher mussten wir uns erst umstellen. Da wir verschiedene Cluster verwenden, wie etwa Rechner für Hadoop, Solr, Aspire usw., bietet Microsoft an, diese Cluster nach Rechnerart in einem separaten Cloud-Server zu Gruppen zusammenzustellen, der dann die Kommunikation zwischen diesen Clustern übernimmt. 

Paul:  Wie siehst du den Einsatz von Cloudera in AWS und Azure?

Bob:  Was mir bei Azure gut gefällt, ist, dass man leicht eigene interne Netzwerke einrichten kann, mit Subnetzen und anderen Konfigurationen jeweils für jeden Cluster. Damit kann man dann wirklich den einzelnen Rechnern die IPs nach Wahl zuweisen und eigene Domänenname über einen eigenen DNS-Server nutzen. Wir haben unsere internen Domänennamen so eingerichtet, dass sie den externen Domänennamen gleichen. Damit konnten die Webschnittstellen bei Cloudera (Cloudera Manager, Job Tracker Interface, Resource Manager usw.) korrekt arbeiten. 

Bei AWS nutzen alle Weblinks innerhalb der Benutzerschnittstellen von Cloudera die internen Rechnernamen, daher muss man sie in der Datei /etc/hosts des Clients zuordnen, damit sie korrekt funktionieren. Aber, wenn ich jetzt so darüber nachdenke, könnte es sein, dass man bei AWS vielleicht auch einen DNS-Server einrichten kann, ebenso wie bei Azure, nur dass wir damals nicht daran gedacht haben.

Paul:  Fällt dir sonst noch etwas zu dieser Cloud-Migration ein?

Bob:  [Denkt nach]  Ich denke, das Wichtigste haben wir erwähnt. Wir hatten auch das Glück, dass wir eine Ingenieurin bei Microsoft getroffen haben, die früher für Cloudera gearbeitet hat. Sie hat uns eine Liste der Speichereinstellungen gegeben, über die Hadoop für die Rechner eingestellt wurde, die wir im Einsatz hatten. Dadurch ist die Leistung unserer MapReduce-Vorgänge um gut 30% gestiegen.

Paul:  Welche Art von Rechnern habt ihr für Azure eingesetzt?

Bob:  D14, 128GB RAM, 32 Kerne.

Paul:  Habt ihr für Azure dann weniger Rechner gebraucht, weil sie ja immerhin deutlich leistungsfähiger waren als die Rechner mit 32GB RAM und 8 Kernen, die für AWS genutzt wurden?

Bob:  Nein. Unser Cluster umfasste vier Knoten. Man braucht mindestens vier Datenknoten, damit man immer noch eine dreifache Replikation hat, wenn ein Knoten ausfällt. Aber es ist nett, dass Azure mit dem Speicher großzügiger ist als AWS.

Paul:  Toll! Es hört sich ja so an, also ob ihr bei der Migration von AWS zu Azure einiges gelernt habt.

Bob:  Cloudera hat gleichzeitig denselben Lernprozess durchlaufen. Es war eine Herausforderung, aber auch gleichzeitig ein interessanter Prozess, als einer der ersten die Azure-Plattform für Big Data zu nutzen.

Paul:  Fällt dir sonst noch etwas ein, was man zu Azure als Big Data-Plattform anmerken sollte?

Bob:  Ich würde in jedem Fall empfehlen, der Cloudera Referenzarchitektur für Microsoft Azure so exakt wie möglich zu folgen, da Azure strenger ist als AWS, hinsichtlich kleinerer Fehler und Ungenauigkeiten. Azure ist eine gute Wahl, wenn man sich gut vorbereitet und einen detaillierten Migrationsplan erstellt. Azure ist zwar noch eine junge Technologie, aber ich bin mir sicher, dass sie mit der Zeit eine der Schlüsselrollen bei Cloud-Infrastruktur für Big Data einnehmen wird.

Paul:  Vielen Dank für deine Zeit. Ich lasse dich jetzt mal in Ruhe essen. Das nächste Mal sollten wir uns irgendwo in der Natur treffen.

0