Looker-Clustering

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

Übersicht

Vom Kunden gehostete Bereitstellungen von Looker können mit einem Knoten oder geclustert 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 sollte:

• 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

Erwägen Sie vor dem Load-Balancing von Looker, den Arbeitsspeicher und möglicherweise die CPU-Anzahl eines einzelnen Servers zu erhöhen, auf dem Looker ausgeführt wird. 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 benötigen mehr Arbeitsspeicher, um eine bessere Leistung zu erzielen. Clustering kann zu Leistungssteigerungen führen, wenn viele Nutzer kleine Abfragen ausführen.

Bei Konfigurationen mit bis zu 50 Nutzern, die Looker nur wenig nutzen, empfiehlt Looker, einen einzelnen Server auf der Basis einer großen AWS EC2-Instanz auszuführen (M4.large: 8 GB RAM, 2 CPU-Kerne). Beobachten Sie bei Konfigurationen mit mehr Nutzern oder vielen aktiven Powerusern, ob die CPU-Auslastung ansteigt oder ob Nutzer eine langsame Anwendung feststellen. 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. Hochverfügbarkeit ist besonders wichtig, wenn die Looker-API in zentralen Geschäftssystemen verwendet wird oder wenn Looker in kundenseitige Produkte eingebettet ist.

In einer geclusterten Looker-Konfiguration leitet ein Proxyserver oder Load Balancer den Traffic um, wenn festgestellt wird, dass 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 zeigt, wie die Komponenten interagieren. Auf übergeordneter Ebene verteilt ein Lastenausgleichsmodul den Netzwerkverkehr auf geclusterte 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 Anwendung mit einem Knoten ausgeführt wird, verwendet es normalerweise eine speicherinterne HyperSQL-Datenbank.

In einer clusterbasierten Looker-Konfiguration muss die Looker-Instanz jedes Knotens auf eine gemeinsame Transaktionsdatenbank verweisen (die gemeinsame Anwendung oder interne Datenbank). Die Anwendungsdatenbank für geclusterte Looker-Cluster wird wie folgt unterstützt:

• 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.
• Geclusterte 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.

Die Wartung und Sicherung dieser Datenbank wird nicht von Looker verwaltet. 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 miteinander und mit der Looker-Anwendungsdatenbank erreichbar sein. Die Standardports sind auf dieser Seite unter Ports für die Kommunikation mit 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 werden, dass der Traffic an die verbleibenden fehlerfreien Knoten weitergeleitet wird.

Achten Sie bei der Auswahl und Konfiguration des Load-Balancers darauf, dass er nur als Ebene 4 verwendet werden kann. Der 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, Lustre usw.). 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 (ausführbare JAR-Datei)

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ängigkeits-JAR-Datei. Wenn Sie Looker 6.18 oder höher installieren oder aktualisieren, müssen Sie beide JAR-Dateien herunterladen.

Looker empfiehlt dringend, auf jedem Knoten in einem Cluster dieselbe Looker-Release- und Patchversion auszuführen, 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

Für eine geclusterte 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 unbedingt Ihr Looker-Verzeichnis. Der Migrationsprozess kann nur von einer HyperSQL-Datenbank zu einer MySQL-Datenbank erfolgen und nicht umgekehrt.

Auf der Dokumentationsseite Zu MySQL migrieren finden Sie Informationen zum Sichern von Looker und zum anschließenden Migrieren 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 kann.
2. Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
3. Wenn Looker ausgeführt wird, fahren Sie Ihre Looker-Konfiguration herunter.
4. Wenn Sie zuvor Clustering mit inotify-Linux-Skripts durchgeführt haben, halten Sie diese Skripts an, entfernen Sie sie aus Cron 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 die Bereitstellungsschlüssel auf einem Knoten und verschieben Sie Ihre Plug-ins sowie die Verzeichnisse looker/models und looker/models-user-*, in denen Ihre Modelldateien gespeichert sind, auf 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 mindestens eine eindeutige Logdatei schreiben.

SSH-Schlüssel-Repository freigeben

• Sie erstellen einen freigegebenen Dateisystem-Cluster 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. Dies kann das Anmelden und Beheben von Fehlern in der Konfiguration erschweren. Bevor Sie diese Schritte ausführen, benötigen Sie Zugriff auf ein anderes Konto, mit dem Sie su auf das Looker-Nutzerkonto anwenden können.

Richten Sie das SSH-Schlüssel-Repository zur 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 erstellen Sie 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

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

Die Standardports, die zwischen Clusterknoten offen 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 zu beschränken, damit nur Traffic zwischen den Clusterhosts zugelassen wird.

Looker auf den Knoten starten

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

Hinweis: Jeder Knoten in einem Cluster muss dieselbe Looker-Version und dieselbe Patchversion ausführen.

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/Optional?	Werte	Zweck
--clustered	Ja		Flag hinzufügen, um anzugeben, dass dieser Knoten im geclusterten Modus 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. Er 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 dieselbe Portnummer für die Kommunikation zwischen Knoten verwenden.
-q	Nein	61616	Der Port zum Einstellen clusterweiter Ereignisse in die Warteschlange. 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 Start-Flag --clustered sollte keinen Wert enthalten.

Beispiel für LOOKERARGS und Angeben von Datenbankanmeldedaten

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

Beispielsweise könnten Sie Looker mitteilen:

• So verwenden Sie die Datei looker-db.yml für ihre Datenbankanmeldedaten:
• dass es sich um einen geclusterten Knoten handelt
• 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 dann 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 Best Practices für die Sicherheit, wenn Sie Anmeldedaten in einer Datei speichern. Idealerweise solltest du die Berechtigungen für die Datei looker-db.yml auf 600 festlegen, die dem Linux-„Nutzer“ gehört Konto, mit 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 einem Laufwerk speichern möchten, können Sie die Umgebungsvariable LOOKER_DB so konfigurieren, dass sie für jede Zeile in der Datei looker-db.yml eine Liste mit Schlüsseln und Werten 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 vom Release ab, in dem 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 verringert, allerdings gehen alle Änderungen verloren, die zwischen dem Erstellen des Replikats und dem Verweisen des Proxyservers auf die neuen Knoten vorgenommen wurden. 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 Anwendungsdatenbank von Looker.
2. Starten Sie einen neuen Cluster, der auf das Replikat verweist.
3. Verweisen Sie den Proxyserver oder Load-Balancer auf die neuen Knoten. Anschließend können Sie die alten Knoten beenden.