Looker clustern

In dieser Anleitung wird die empfohlene Methode zum Erstellen einer clusterbasierten Looker-Konfiguration für vom Kunden gehostete Instanzen erläutert.

Übersicht

Von Kunden gehostete Looker-Bereitstellungen können als einzelner Knoten oder als Cluster ausgeführt werden:

• Eine Looker-Anwendung mit einem einzelnen Knoten, die Standardkonfiguration, umfasst alle Dienste, aus denen die Looker-Anwendung besteht, die auf einem einzigen Server ausgeführt werden.
• Eine clusterbasierte Looker-Konfiguration ist eine komplexere Konfiguration, die in der Regel Datenbankserver, Load Balancer und mehrere Server umfasst, auf denen die Looker-Anwendung ausgeführt wird. Jeder Knoten in einer clusterbasierten Looker-Anwendung ist ein Server, auf dem eine einzelne Looker-Instanz ausgeführt wird.

Es gibt zwei Hauptgründe, warum ein Unternehmen Looker als Cluster ausführen möchte:

• Load Balancing
• Verbesserte Verfügbarkeit und Failover

Je nach Skalierungsproblemen ist ein geclusterter Looker möglicherweise nicht die Lösung. Wenn beispielsweise eine kleine Anzahl großer Abfragen den Systemspeicher belegt, besteht die einzige Lösung darin, den verfügbaren Arbeitsspeicher für den Looker-Prozess zu erhöhen.

Load Balancing-Alternativen

Bevor Sie Looker mit Load Balancing ausstatten, sollten Sie den Arbeitsspeicher und gegebenenfalls die CPU-Anzahl eines einzelnen Servers, auf dem Looker ausgeführt wird, erhöhen. Looker empfiehlt, eine detaillierte Leistungsüberwachung für die Speicher- und CPU-Auslastung einzurichten, damit der Looker-Server für die Arbeitslast richtig dimensioniert ist.

Große Abfragen erfordern mehr Arbeitsspeicher für eine bessere Leistung. Durch das Clustering kann die Leistung verbessert werden, wenn viele Nutzer kleine Abfragen ausführen.

Für Konfigurationen mit bis zu 50 Nutzern, die Looker nur gelegentlich verwenden, empfiehlt Looker, einen einzelnen Server mit der Leistung einer großen AWS EC2-Instanz (M4.large: 8 GB RAM, 2 CPU-Kerne) auszuführen. Bei Konfigurationen mit mehr Nutzern oder vielen aktiven Powerusern sollten Sie prüfen, ob es zu CPU-Spikes kommt oder ob Nutzer die Anwendung als langsam empfinden. In diesem Fall sollten Sie Looker auf einen größeren Server verschieben oder eine clusterbasierte Looker-Konfiguration ausführen.

Verbesserte Verfügbarkeit/Failover

Wenn Sie Looker in einer Clusterumgebung ausführen, können Sie bei einem Ausfall die Ausfallzeit verringern. Eine hohe Verfügbarkeit ist besonders wichtig, wenn die Looker API in Kerngeschäftssystemen verwendet wird oder Looker in kundenorientierten Produkten eingebettet ist.

In einer clusterbasierten Looker-Konfiguration leitet ein Proxyserver oder Load Balancer den Traffic um, wenn ein Knoten ausgefallen ist. Looker kümmert sich automatisch um Knoten, die den Cluster verlassen oder beitreten.

Erforderliche Komponenten

Für eine clusterbasierte Looker-Konfiguration sind die folgenden Komponenten erforderlich:

• MySQL-Anwendungsdatenbank
• Looker-Knoten (Server, auf denen der Looker-Java-Prozess ausgeführt wird)
• Load-Balancer
• Freigegebenes Dateisystem
• Die richtige Version der JAR-Dateien der Looker-Anwendung

Das folgende Diagramm veranschaulicht die Interaktion der Komponenten. Ein Load Balancer verteilt den Netzwerkverkehr grob zwischen den clusterisierten Looker-Knoten. Die Knoten kommunizieren jeweils mit einer freigegebenen MySQL-Anwendungsdatenbank, einem freigegebenen Speicherverzeichnis und den Git-Servern für jedes LookML-Projekt.

MySQL-Anwendungsdatenbank

Looker verwendet eine Anwendungsdatenbank (häufig als interne Datenbank bezeichnet), um Anwendungsdaten zu speichern. Wenn Looker als Ein-Knoten-Anwendung ausgeführt wird, wird normalerweise eine speicherresidente HyperSQL-Datenbank verwendet.

In einer clusterbasierten Looker-Konfiguration muss die Looker-Instanz jedes Knotens auf eine gemeinsame Transaktionsdatenbank verweisen (die gemeinsame Anwendung oder interne Datenbank). Die Unterstützung für die Anwendungsdatenbank für geclusterte Looker-Umgebungen ist so:

• Für die Anwendungsdatenbank geclusterter Looker-Instanzen wird nur MySQL unterstützt. Amazon Aurora und MariaDB werden nicht unterstützt.
• MySQL-Versionen ab 5.7 und 8.0 werden unterstützt.
• Clusterbasierte Datenbanken wie Galera werden nicht unterstützt.

Hinweis: Eine Datenbank mit Lesereplikat wird empfohlen, um die Leistung und Redundanz zu verbessern. Die Lesereplikatdatenbank muss keine MySQL-Datenbank sein.

Looker verwaltet die Wartung und Sicherung dieser Datenbank nicht. Da die Datenbank jedoch fast alle Konfigurationsdaten der Looker-Anwendung hostet, sollte sie als Hochverfügbarkeitsdatenbank bereitgestellt und mindestens täglich gesichert werden.

Looker-Knoten

Jeder Knoten ist ein Server, auf dem der Looker-Java-Prozess ausgeführt wird. Die Server im Looker-Cluster müssen sich gegenseitig und die Datenbank der Looker-Anwendung erreichen können. Die Standardports sind auf dieser Seite unter Ports für die Kommunikation der Knoten öffnen aufgeführt.

Load-Balancer

Um die Last auszugleichen oder Anfragen an verfügbare Knoten weiterzuleiten, ist ein Load Balancer oder Proxy-Server (z. B. NGINX oder AWS ELB) erforderlich, um den Traffic an jeden Looker-Knoten weiterzuleiten. Der Load Balancer führt die Systemdiagnosen durch. Bei einem Knotenausfall muss der Load Balancer so konfiguriert sein, dass der Traffic zu den verbleibenden fehlerfreien Knoten umgeleitet wird.

Achten Sie bei der Auswahl und Konfiguration des Load Balancers darauf, dass er nur für Layer 4 konfiguriert werden kann. Das Amazon Classic ELB ist ein solches Beispiel. Außerdem sollte der Load Balancer ein langes Zeitlimit (3.600 Sekunden) haben, um zu verhindern,dass Abfragen beendet werden.

Freigegebenes Dateisystem

Sie müssen ein POSIX-konformes freigegebenes Dateisystem verwenden, z. B. NFS, AWS EFS, Gluster, BeeGFS oder Lustre. Looker verwendet das freigegebene Dateisystem als Repository für verschiedene Informationen, die von allen Knoten im Cluster verwendet werden.

Hinweis: Für die Installation von Anwendungen und Tools aus dem Looker Marketplace ist ein freigegebenes (Netzwerk-)Dateisystem erforderlich.

Looker-Anwendung (JAR-Ausführdatei)

Sie müssen eine JAR-Datei der Looker-Anwendung verwenden, die Looker 3.56 oder höher ist.

Hinweis: Ab Looker 6.18 wurde die Looker-JAR-Datei in zwei separate JAR-Dateien aufgeteilt: die Looker-Kern-JAR-Datei und eine Looker-Abhängigkeiten-JAR-Datei. Wenn Sie Looker 6.18 oder höher installieren oder aktualisieren, müssen Sie beide JAR-Dateien herunterladen.

Looker empfiehlt dringend, dass auf jedem Knoten in einem Cluster dieselbe Looker-Release- und Patchversion ausgeführt wird, wie unter Looker auf den Knoten starten auf dieser Seite beschrieben.

Cluster einrichten

Folgende Aufgaben sind erforderlich:

1. Looker installieren
2. MySQL-Anwendungsdatenbank einrichten
3. Freigegebenes Dateisystem einrichten
4. SSH-Schlüssel-Repository freigeben (je nach Situation)
5. Ports für die Kommunikation der Knoten öffnen
6. Looker auf den Knoten starten

Looker installieren

Installieren Sie Looker auf jedem Knoten. Verwenden Sie dazu die JAR-Dateien der Looker-Anwendung und folgen Sie der Anleitung auf der Dokumentationsseite Installationsschritte für die vom Kunden gehostete Lösung.

MySQL-Anwendungsdatenbank einrichten

Bei einer clusterbasierten Looker-Konfiguration muss die Anwendungsdatenbank eine MySQL-Datenbank sein. Wenn Sie eine nicht geclusterte Looker-Instanz haben, die HyperSQL für die Anwendungsdatenbank verwendet, müssen Sie die Anwendungsdaten aus den HyperSQL-Daten in die neue freigegebene MySQL-Anwendungsdatenbank migrieren.

Hinweis: Sichern Sie Ihr Looker-Verzeichnis. Die Migration kann nur von einer HyperSQL-Datenbank zu einer MySQL-Datenbank erfolgen, nicht umgekehrt.

Auf der Dokumentationsseite Zu MySQL migrieren finden Sie Informationen zum Sichern von Looker und zur anschließenden Migration der Anwendungsdatenbank von HyperSQL zu MySQL.

Freigegebenes Dateisystem einrichten

Nur bestimmte Dateitypen – Modelldateien, Bereitstellungsschlüssel, Plug-ins und gegebenenfalls Anwendungsmanifestdateien – gehören in das freigegebene Dateisystem. So richten Sie das freigegebene Dateisystem ein:

1. Prüfen Sie auf dem Server, auf dem das freigegebene Dateisystem gespeichert wird, ob Sie Zugriff auf ein anderes Konto haben, das su auf das Looker-Nutzerkonto ausführen kann.
2. Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
3. Wenn Looker ausgeführt wird, beenden Sie die Looker-Konfiguration.
4. Wenn Sie zuvor mit inotify-Linux-Scripts einen Cluster erstellt haben, beenden Sie diese Scripts, entfernen Sie sie aus dem Cron-Tab und löschen Sie sie.
5. Erstellen Sie eine Netzwerkfreigabe und stellen Sie sie auf jedem Knoten im Cluster bereit. Achten Sie darauf, dass es auf jedem Knoten automatisch bereitgestellt wird und der Looker-Nutzer darauf lesen und schreiben kann. Im folgenden Beispiel heißt die Netzwerkfreigabe /mnt/looker-share.

6. Kopieren Sie auf einem Knoten Ihre Bereitstellungsschlüssel und verschieben Sie Ihre Plug-ins und die Verzeichnisse looker/models und looker/models-user-*, in denen Ihre Modelldateien gespeichert sind, in Ihre Netzwerkfreigabe. Beispiel:

   mv looker/models /mnt/looker-share/
   mv looker/models-user-* /mnt/looker-share/
   

   Hinweis :Ihre Bereitstellungsschlüssel müssen in den freigegebenen Speicher und auf jeden Knoten im Cluster kopiert werden.

7. Fügen Sie für jeden Knoten die Einstellung --shared-storage-dir zu LOOKERARGS hinzu. Geben Sie die Netzwerkfreigabe an, wie in diesem Beispiel gezeigt:

   --shared-storage-dir /mnt/looker-share
   

   LOOKERARGS sollte $HOME/looker/lookerstart.cfg hinzugefügt werden, damit die Einstellungen nicht von Updates betroffen sind. Wenn Ihre LOOKERARGS in dieser Datei nicht aufgeführt sind, hat jemand sie möglicherweise direkt dem $HOME/looker/looker-Shell-Script hinzugefügt.

   Jeder Knoten im Cluster muss in ein eindeutiges /log-Verzeichnis oder zumindest in eine eindeutige Protokolldatei schreiben.

SSH-Schlüssel-Repository freigeben

• Sie erstellen einen Cluster für das freigegebene Dateisystem aus einer vorhandenen Looker-Konfiguration und
• Sie haben Projekte, die in Looker 4.6 oder niedriger erstellt wurden.

Hinweis: Für die folgende Vorgehensweise muss das $HOME/.ssh-Verzeichnis des Looker-Nutzers geändert werden. Das kann es schwierig machen, sich anzumelden und Fehler in der Konfiguration zu beheben. Bevor Sie diese Schritte ausführen, müssen Sie Zugriff auf ein anderes Konto haben, das su auf das Looker-Nutzerkonto zugreifen kann.

Richten Sie das SSH-Schlüssel-Repository für die Freigabe ein:

1. Erstellen Sie auf dem freigegebenen Dateiserver ein Verzeichnis mit dem Namen ssh-share. Beispiel: /mnt/looker-share/ssh-share

   Der Inhaber des Verzeichnisses ssh-share muss der Looker-Nutzer sein und die Berechtigungen müssen 700 sein. Außerdem dürfen Verzeichnisse über dem Verzeichnis ssh-share (z. B. /mnt und /mnt/looker-share) nicht für alle oder für Gruppen beschreibbar sein.

2. Kopieren Sie auf einem Knoten den Inhalt von $HOME/.ssh in das neue Verzeichnis ssh-share. Beispiel:

   cp $HOME/.ssh/* /mnt/looker-share/ssh-share

3. Erstellen Sie für jeden Knoten eine Sicherung der vorhandenen SSH-Datei und einen Symlink zum Verzeichnis ssh-share. Beispiel:

   cd $HOME
   mv .ssh .ssh_bak
   ln -s /mnt/looker-share/ssh-share .ssh
   

   Führen Sie diesen Schritt für jeden Knoten aus.

Öffnen der Ports für die Kommunikation der Knoten

Clusterisierte Looker-Knoten kommunizieren über HTTPS mit selbst signierten Zertifikaten und einem zusätzlichen Authentifizierungsschema, das auf rotierenden Geheimnissen in der Anwendungsdatenbank basiert.

Die Standardports, die zwischen den Clusterknoten geöffnet sein müssen, sind 1551 und 61616. Diese Ports können mithilfe der hier aufgeführten Start-Flags konfiguriert werden. Wir empfehlen dringend, den Netzwerkzugriff auf diese Ports einzuschränken, damit nur Traffic zwischen den Cluster-Hosts zulässig ist.

Looker auf den Knoten starten

Starten Sie den Server auf jedem Knoten mit den erforderlichen Start-Flags neu.

Hinweis: Auf jedem Knoten in einem Cluster muss dieselbe Looker-Release- und Patch-Version ausgeführt werden.

Verfügbare Start-Flags

In der folgenden Tabelle sind die verfügbaren Start-Flags aufgeführt, einschließlich der Flags, die zum Starten oder Beitreten eines Clusters erforderlich sind:

Flag	Erforderlich?	Werte	Zweck
--clustered	Ja		Fügen Sie ein Flag hinzu, um anzugeben, dass dieser Knoten im Clustermodus ausgeführt wird.
-H oder --hostname	Ja	10.10.10.10	Der Hostname, über den andere Knoten diesen Knoten kontaktieren, z. B. die IP-Adresse oder der Systemhostname des Knotens. Muss sich von den Hostnamen aller anderen Knoten im Cluster unterscheiden.
-n	Nein	1551	Der Port für die Kommunikation zwischen Knoten. Der Standardwert ist 1551. Alle Knoten müssen für die Kommunikation zwischen Knoten dieselbe Portnummer verwenden.
-q	Nein	61616	Der Port für die Warteschlange clusterweiter Ereignisse. Der Standardwert ist 61616.
-d	Ja	/path/to/looker-db.yml	Der Pfad zur Datei mit den Anmeldedaten für die Looker-Anwendungsdatenbank.
--shared-storage-dir	Ja	/path/to/mounted/shared/storage	Die Option sollte auf das freigegebene Verzeichnis verweisen, das oben auf dieser Seite eingerichtet wurde und die Verzeichnisse looker/model und looker/models-user-* enthält.

Hinweis: Das Startflag --clustered darf keinen Wert enthalten.

Beispiel für LOOKERARGS und Angabe von Datenbankanmeldedaten

Platzieren Sie die Looker-Start-Flags in einer lookerstart.cfg-Datei im selben Verzeichnis wie die Looker-JAR-Dateien.

Sie könnten Looker beispielsweise Folgendes mitteilen:

• Wenn Sie die Datei looker-db.yml für die Datenbankanmeldedaten verwenden möchten,
• dass es sich um einen Clusterknoten handelt und
• dass die anderen Knoten des Clusters diesen Host über die IP-Adresse 10.10.10.10 kontaktieren sollen.

Sie geben Folgendes an:

LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"

Hinweis: Geben Sie die richtige IP-Adresse für Ihren Knoten an.

Die Datei looker-db.yml enthält die Anmeldedaten für die Datenbank, z. B.:

host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword

Wenn für Ihre MySQL-Datenbank eine SSL-Verbindung erforderlich ist, sind in der Datei looker-db.yml außerdem folgende Angaben erforderlich:

ssl: true

Hinweis: Sie müssen eine Kopie Ihrer Anmeldedatendatei im freigegebenen Speicher und auf jedem Knoten im Cluster speichern.

Hinweis: Beachten Sie die Sicherheitsbest Practices, wenn Sie Anmeldedaten in einer Datei speichern. Idealerweise sollten die Dateiberechtigungen für looker-db.yml auf 600 gesetzt werden. Eigentümer ist das Linux-Nutzerkonto, unter dem die Looker-Anwendung ausgeführt wird. Diese Datei sollte niemals in ein Git-Repository eingecheckt werden.

Wenn Sie die Konfiguration nicht in der Datei looker-db.yml auf dem Laufwerk speichern möchten, können Sie die Umgebungsvariable LOOKER_DB so konfigurieren, dass sie eine Liste von Schlüsseln und Werten für jede Zeile in der Datei looker-db.yml enthält. Beispiel:

export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"

Git-SSH-Bereitstellungsschlüssel finden

Wo Looker Git-SSH-Bereitstellungsschlüssel speichert, hängt davon ab, in welcher Version das Projekt erstellt wurde:

• Bei Projekten, die vor Looker 4.8 erstellt wurden, werden die Bereitstellungsschlüssel im integrierten SSH-Verzeichnis des Servers ~/.ssh gespeichert.
• Bei Projekten, die in Looker 4.8 oder höher erstellt wurden, werden die Bereitstellungsschlüssel in einem von Looker verwalteten Verzeichnis namens ~/looker/deploy_keys/PROJECT_NAME gespeichert.

Looker-Cluster ändern

Nachdem Sie einen Looker-Cluster erstellt haben, können Sie Knoten hinzufügen oder entfernen, ohne Änderungen an den anderen geclusterten Knoten vorzunehmen.

Cluster auf einen neuen Looker-Release aktualisieren

Updates können Schemaänderungen an der internen Datenbank von Looker beinhalten, die mit früheren Versionen von Looker nicht kompatibel sind. Es gibt zwei Möglichkeiten, Looker zu aktualisieren.

Sicherere Methode

1. Erstellen Sie eine Sicherung der Anwendungsdatenbank.
2. Beenden Sie alle Knoten des Clusters.
3. Ersetzen Sie die JAR-Dateien auf jedem Server.
4. Starten Sie jeden Knoten einzeln.

Schnellere Methode

Hinweis :Mit dieser Methode wird die Ausfallzeit verkürzt, aber alle Änderungen, die zwischen dem Erstellen des Replikats und dem Richten des Proxyservers auf die neuen Knoten vorgenommen wurden, gehen verloren. Wenn beispielsweise während der Umstellung Nutzer hinzugefügt oder Looks erstellt werden, werden diese Änderungen möglicherweise nicht in der neuen Anwendungsdatenbank erfasst.

So aktualisieren Sie mit dieser schnelleren, aber weniger vollständigen Methode:

1. Erstellen Sie ein Replikat der Looker-Anwendungsdatenbank.
2. Starten Sie einen neuen Cluster, der auf das Replikat verweist.
3. Weisen Sie den Proxyserver oder Load Balancer auf die neuen Knoten hin. Anschließend können Sie die alten Knoten beenden.