Upgrade des sicheren Clusters CDH4.5.0 auf CDH5.0.3

Upgrade eines sicheren Clusters CDH 4.5.0 auf CDH 5.0.3 unter Verwendung von Paketen

In diesem Blog werden wir beschreiben, wie wir das Upgrade des Hadoop-Clusters auf die neue Version der Cloudera Hadoop-Distributionen durchgeführt haben. Obwohl dieses Upgrade von Cloudera gut dokumentiert ist, verlief es nicht ohne Probleme. Wir werden die Probleme und die Lösungen erläutern.

Warum ein Upgrade?

Der Grund für ein Upgrade des Clusters hat mehrere Vorteile:

• Möglichkeit der Verwendung von YARN anstelle von MapReduce1 (ein generischerer und effizienterer Scheduler), damit Spark
• Neue Version von Hive 0.10 -> 0.12 (Viele Fehlerbehebungen und Verbesserungen, DECIMAL Datentyp)
• Neue Version von Impala 1.2.4 -> 1.3.1 (Ausführung auf YARN yarn-impala, neue Funktionen)
• Neue Version von Hue 2.5.0 -> 3.5.0 (Wesentlich bessere Benutzeroberfläche für die Arbeit mit Hive, Impala und die Anzeige der Ergebnisse)
• Leben Sie nicht in der Vergangenheit, sondern bleiben Sie auf dem Laufenden!

Unsere Landschaft

Der Cluster besteht aus 13 physischen Rechnern, auf denen CentOS 6 läuft, mit einem SAN (große Festplatte) für die Rohdaten und das Sammeln von Protokollen des Clusters.

Auf allen Rechnern haben wir Root-Zugriff und alle Befehle werden als Root ausgeführt. Auf allen Rechnern ist Java 1.6 mit der Java Extended Crypo Policy installiert, die für einen Kerberos-gesicherten Cluster erforderlich ist. Wir haben vor dem Upgrade nicht auf allen Rechnern ein 'yum update' durchgeführt.

In dem Cluster haben wir diese Knoten:

Welche Pakete haben wir verwendet?

Vor dem Upgrade hat der Cluster die Pakete verwendet:

• CDH-4.5.0
• Impala 1.2.4

Wir haben die folgenden Dienste in Anspruch genommen:

• hdfs1
• Bienenstock1
• Farbton1
• mapreduce1
• impala1
• Zoowärter
• inaktiv: sqoop1, oozie
• nicht installiert: Cloudera Navigator

Durchführen des Upgrades

Cloudera hat eine sehr gute und vollständige Dokumentation. Für das Upgrade haben wir den cloudera-CDH5-upgrade-guide befolgt.

Schritt 1: Aktualisieren Sie den Cloudera Manager

Während dieses Schritts ist der Cluster immer noch zur Nutzung verfügbar.

Die folgenden Schritte sind im cloudera-manager-upgrade-guide beschrieben.

Knoten: cloudera-mgmt:

1. Stoppen Sie den Cloudera Manager Server und die Datenbank:

  $ dienst cloudera-scm-server stop
  $ service cloudera-scm-server-db stop
  $ service cloudera-scm-agent stop

1. Installieren Sie yum repo & überprüfen Sie das Ergebnis:

  wget http://archive.cloudera.com/cm5/redhat/6/x86_64/cm/cloudera-manager.repo
  mv cloudera-manager.repo /etc/yum.repos.d/
  yum clean all
  yum upgrade  'cloudera-*'

  rpm -qa  'cloudera-manager-*'
  aussehen sollte:
  cloudera-manager-server-5.0.2-1.cm502.p0.297.el6.x86_64
  cloudera-manager-daemons-5.0.2-1.cm502.p0.297.el6.x86_64
  cloudera-manager-server-db-2-5.0.2-1.cm502.p0.297.el6.x86_64

1. Starten Sie den Cloudera Manager und prüfen Sie die Serverprotokolle

  sudo service cloudera-scm-server-db start
  sudo service cloudera-scm-server starten

  less /var/log/cloudera-scm-server/clou*.log

Die Installation von Cloudera Manager 5 verlief ohne Probleme, ja!

Agent-Pakete aktualisieren

Nach der Anmeldung im Cloudera Manager wird vorgeschlagen, die Agenten zu aktualisieren. Folgen Sie dem Upgrade-Assistenten für den Cluster. (Die Screenshots stammen von einem anderen Upgrade auf 5.1.0, sind aber sehr ähnlich)

1. Wählen Sie die Version und den Ort des CDH-Pakets. Wenn der Cluster nicht mit dem Internet verbunden ist, müssen Sie die Pakete herunterladen und sie selbst bereitstellen. Dann müssen Sie das benutzerdefinierte Repository verwenden, das auf diesen Speicherort verweist und die manifest.json und Paketdateien bereitstellt.
2. Installieren Sie Java Unlimited Strength Encryption Policy Files. Dies ist für die Kerberos-Sicherheit erforderlich. Diese Richtlinie ist spezifisch für die neue Version (Java 1.7). Wenn Sie bereits 1.7 installiert haben, sollten Sie das Kontrollkästchen für die neue Java-Version trotzdem aktivieren.
3. Agent installieren konfigurieren Hier wird festgelegt, wie Cloudera Manager mit den Agenten verbunden wird. Die Anzahl der gleichzeitigen Installationen ist eine Zahl, über die Sie nachdenken sollten. Versuchen Sie, eine 'intelligente' Zahl zu wählen, wir haben 12 Knoten, die aktualisiert werden. Wir haben die Standardzahl 10 verwendet und es hat sehr lange gedauert, bis das Upgrade auf den letzten 2 Agenten abgeschlossen und gestartet war. Die Netzwerk-IO ist sehr hoch, deshalb würden wir eine niedrigere Zahl empfehlen, damit das Upgrade nicht das Netzwerk belastet.In unserem Fall war es besser, 6 zu wählen. In zwei Runden werden alle Knoten mit begrenzter Netzwerk-IO installiert.
4. Führen Sie das Upgrade durch, drücken Sie die Daumen

In unserem Fall schlug das Update nach der Verteilung der Pakete mit der Meldung fehl:

kann parcel.json nicht in den Datenknoten kopieren

Die Balken aller Knoten waren grün, aber der Assistent konnte nicht fortfahren oder es erneut versuchen, wir mussten einige Probleme beheben...

Situation nach dem unterbrochenen Upgrade:

Der Assistent zeigt an, dass alle CDH.5.0.3 Pakete auf alle Knoten verteilt wurden. Wir konnten den Upgrade-Assistenten nicht erneut ausführen. Ein erneuter Versuch führte zu der Fehlermeldung "Upgrade-Assistent kann nicht erneut ausgeführt werden". Über die Cloudera Manager-Schnittstelle konnten wir die Knoten überprüfen:

• Alle Hosts sind online
• Alle Hostdienste werden gestoppt.
• Die Ausführung des Host-Inspektors zeigt keine Probleme.

Die Fehlermeldung besagte, dass die Dateien nicht auf den Datenknoten vorhanden sind. Wir haben das überprüft und die Dateien waren auf den in der Fehlermeldung genannten Datenknoten vorhanden und die md5sum war dieselbe wie auf den anderen Knoten.

Versuchen Sie, den Dienst 1 zu 1 über den Cloudera Manager zu starten.

• hdfs starten -> ok
• mapreduce starten -> ok
• Hive starten -> Fehler

Problem:

... Verursacht durch: MetaException(Meldung:Versionsinformationen nicht im Metaspeicher gefunden. ) ...

Nach einiger Recherche: CDH5 wird mit Hive 0.12 ausgeliefert, einem Upgrade von Hive 0.10 (CDH4). Bei diesem Update sollte das Datenbankschema aktualisiert werden. Wir vermuteten, dass das Update-Skript nicht ausgeführt wurde, weil der Assistent nicht abgeschlossen wurde. Aber wo sollten wir was ausführen?

Wo befindet sich die MetaStore-Datenbank?

• Cloudera Manager
• Klicken Sie auf den Hive-Dienst.
• Klicken Sie unter Instanzen auf den Hive MetaStore.
• Klicken Sie nun auf die Registerkarte Prozesse
• Klicken Sie auf > und zeigen Sie die hive-site.xml an.

Die Einstellungen enthalten den Speicherort und die Anmeldedaten für den Zugriff auf die vom HiveMetastore Server verwendete Datenbank. In unserem Fall befindet sich der HiveMetastore auf data01, so dass wir uns auf diesem Rechner anmelden, um die Update-Skripte zu finden und auszuführen.

Lösung:

Führen Sie die Datenbank-Upgrade-Skripte selbst aus. Es gibt Upgrade-Skripte für die unterstützten Datenbanken: derby, mysql, oracle und postgres. In jedem Ordner befindet sich eine README, die erklärt, was zu tun ist.

  aktualisiertb
  CDH-5.0.3 lokalisieren  |  grep upgrade  |  grep mysql

    cd 
/somewhere/CDH-5.0.3-1.cdh5.0.3.p0.35/lib/hive/scripts/metastore/upgrade/mysql/

  mysql -u root hive1 -p
  mysql> Quelle  upgrade-0.10.0-to-0.11.0.mysql.sql
  mysql> Quelle  upgrade-0.11.0-to-0.12.0.mysql.sql

Im Cloudera Manager versuchen wir, die Dienste erneut zu starten:

• Hive1 starten -> oke
• Start hue1 -> oke
• impala1 starten -> oke

Großartig, keine Fehler!

Alternative Lösung

Nachdem wir den Cluster auf die oben beschriebene Weise manuell aktualisiert hatten, entdeckten wir, dass es auch möglich ist, den Cloudera Manager zu verwenden, um das Upgrade für die einzelnen Dienste durchzuführen.

Für HDFS:

• Dienst -> hdfs
• Aktionen -> Stopp
• Aktionen -> HDFS-Metadaten aktualisieren
• Aktionen -> Start

Für HIVE:

• Service -> Bienenstock
• Aktionen -> Stopp
• Aktionen -> Hive Metastore NameNodes aktualisieren
• Aktionen -> Hive Metastore Datenbankschema aktualisieren
• Aktionen -> Start

Diese Schritte sollten die Upgrade-Skripte ausführen, die der Upgrade-Assistent nicht ausgeführt hat. Hoffentlich haben Sie jetzt wieder einen funktionierenden Cluster!

Lassen Sie uns versuchen, unsere Abfragen auszuführen! Warten Sie... Hue wurde gestartet und war erreichbar, aber wir konnten uns nicht mehr anmelden.

Problem:

/hue/runcpserver.log

  [16/Jul/2014 02:05:29 -0700] backend WARNING Bei der Authentifizierung von alexanderbij wurde ein LDAPFehler festgestellt: INVALID_CREDENTIALS({'info': 'Simple Bind Failed: NT_STATUS_LOGON_FAILURE', 'desc': 'Ungültige Anmeldedaten'},)
  [16/Jul/2014 02:05:29 -0700] access WARNING 172.16.20.53 -anon- - "POST /accounts/login/ HTTP/1.1" --Failed login for user "alexanderbij"

Aus dem Protokoll geht eindeutig hervor, dass simple_bind verwendet wird. Wir haben samba4 auf dem cloudera-mgmt so konfiguriert, dass simple_bind nicht erlaubt ist. Sie benötigen ein gültiges Kerberos-Ticket, um Benutzer gegen samba/ldap zu validieren. Dies ist kein Problem, wenn Sie keinen Kerberos-gesicherten Cluster haben.

Im Cloudera Manager haben wir die Hue-Konfiguration überprüft:

• Dienstleistungen -> Hue1
• Konfiguration -> Anzeigen und Bearbeiten
• Service-Wide -> Sicherheit

Die Einstellungen für das Authentifizierungs-Backend waren LdapBackend, das in CDH 4.5.0 vor dem Upgrade funktionierte.

Wir haben festgestellt, dass die hue.ini vom HUE_SERVER keine Kerberos-Einstellungen enthält. Der KT_RENEWER-Dienst hue.ini hat die richtigen Kerberos-Einstellungen. Wir sind nicht sicher, ob dies die Ursache des Problems ist. Für dieses Problem haben wir ein Ticket erstellt: HUE-2226, Fortsetzung folgt...

Lösung:

Die Lösung war, stattdessen die PamBackend-Authentifizierung zu verwenden. Bei der Anmeldung bei Hue werden die Anmeldedaten über die lokalen linux Pluggable Authentication Modules (PAM) geprüft. Jeder Knoten im Cluster verfügt über einen sssd-Authentifizierungsmechanismus, der sich als PAM-Modul einhakt und Kerberos und LDAP zur Authentifizierung verwendet. In diesem Blog werden wir nicht auf die Einzelheiten dieser Einrichtung eingehen.

Nach dem Neustart von Hue mit PamBackend konnten sich alle Benutzer wieder anmelden.

Das nächste Problem:

Auf dem Startbildschirm von Hue werden einige Warnungen angezeigt:

Die Ausführung von Hive- und Impala-Abfragen (von HUE aus) funktionierte nicht. Die Ausführung von Abfragen über die Kommandozeile mit hive und impala-shell funktionierte. Bei der Überprüfung des Serverprotokolls von Hue in /hue/runcpserver.log haben wir festgestellt:

  INFO Thrift hat eine Anwendungsausnahme festgestellt: Ungültiger Methodenname: 'GetSchemas'

in der Datei /hue/error.log:

  ERROR Thrift hat eine Ausnahme gesehen (dies kann erwartet werden).
  Traceback (letzter Aufruf):
  Datei "/opt/cloud.....sktop/lib/thrift_util.py", Zeile 367, in wrapper
  ret = res(*args, **kwargs)
  Datei "/opt/cloud...../gen-py/TCLIService/TCLIService.py", Zeile 355, in GetSchemas
  return self.recv_GetSchemas()
  Datei "/opt/cloud../gen-py/TCLIService/TCLIService.py", Zeile 371, in recv_GetSchemas
  erhöhen x
  TApplicationException: Ungültiger Methodenname: 'GetSchemas'

Lösung:

Es stellte sich heraus, dass wir Hue Savety Valve für impala konfiguriert hatten. Vor dem Upgrade haben wir eine Anleitung zur Verwendung von Impala befolgt: Installieren und Verwenden von Impala mit Hue. Die Eigenschaften verweisen auf Port 21000, den Port für das HiveServer1-Protokoll, aber die neuere Version verwendet das HiveServer2-Protokoll, das auf Port 21050 läuft. In der aktuellen Version des Cloudera Managers können Sie den impala-Dienst auswählen und müssen die impala-Eigenschaften nicht selbst angeben.

Im Cloudera Manager:

• Service -> Hue
• Konfiguration -> Anzeigen und Bearbeiten
• Dienstübergreifend -> Erweitert

  [impala]
  server_host=data05
  server_port=21000

Durch das Entfernen dieser zusätzlichen Sicherheitsventil-Konfiguration und die Auswahl des Impala-Dienstes: impala1 in der Kategorie Dienstübergreifend, gefolgt von einem Neustart von hue, war das Problem gelöst.

Fazit

Die Dokumentation von Cloudera ist vollständig und auf die verschiedenen Versionen der Komponenten abgestimmt. Die meisten Einstellungen und Konfigurationsdateien sind dort zu finden. Der Upgrade-Prozess wird ausführlich erklärt. Obwohl das Upgrade wie ein Kinderspiel klingt, wurde es nicht kampflos durchgeführt. Das Upgrade hat sich auf jeden Fall gelohnt, trotz aller Fehlerbehebungen. Die Benutzerfreundlichkeit hat sich erheblich verbessert und wir verwenden wieder das Neueste und Beste. Alle Benutzer des Clusters sind mit der neuen Version zufrieden. Die wichtigste Erkenntnis ist, dass der Upgrade-Assistent nicht erneut ausgeführt werden kann, wenn er fehlschlägt, was leider sowohl bei diesem Produktionscluster als auch bei einem VM-Testcluster der Fall war. Die Idee ist, alle Schritte, die der Assistent nicht ausführen konnte, manuell durchzuführen.