In dieser Anleitung wird die empfohlene Methode zum Erstellen einer Looker-Clusterkonfiguration 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 Knoten, die Standardkonfiguration, verfügt über alle Dienste, aus denen die Looker-Anwendung besteht, die auf einem einzigen Server ausgeführt wird.
- Eine geclusterte Looker-Konfiguration ist eine komplexere Konfiguration, die in der Regel Datenbankserver, Lastenausgleichsmodule und mehrere Server umfasst, auf denen die Looker-Anwendung ausgeführt wird. Jeder Knoten in einer geclusterten 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 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. Wenn ja, verschieben Sie Looker auf einen größeren Server oder führen Sie eine Looker-Clusterkonfiguration aus.
Verbesserte Verfügbarkeit/Failover
Die Ausführung von Looker in einer geclusterten Umgebung kann die Ausfallzeit im Falle eines Ausfalls 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 clusterbasierten Looker-Konfiguration leitet ein Proxyserver oder Load Balancer den Traffic um, wenn ein Knoten ausfällt. Looker verarbeitet automatisch Knoten, die den Cluster verlassen und ihm beitreten.
Erforderliche Komponenten
Die folgenden Komponenten sind für eine Looker-Clusterkonfiguration erforderlich:
- MySQL-Anwendungsdatenbank
- Looker-Knoten (Server, auf denen der Looker-Java-Prozess ausgeführt wird)
- Load-Balancer
- Freigegebenes Dateisystem
- Korrekte 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 – oft 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 Looker-Clusterkonfiguration muss die Looker-Instanz jedes Knotens auf eine freigegebene Transaktionsdatenbank verweisen (die gemeinsame Anwendung oder die interne Datenbank). Die Anwendungsdatenbank für geclusterte Looker-Cluster wird wie folgt unterstützt:
- Für die Anwendungsdatenbank für Looker-Instanzen im Cluster wird nur MySQL unterstützt. Amazon Aurora und MariaDB werden nicht unterstützt.
- Es werden MySQL-Versionen 5.7+ und 8.0+ unterstützt.
- Geclusterte Datenbanken wie Galera werden nicht unterstützt.
Looker verwaltet nicht die Wartung und Sicherungen dieser Datenbank. 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
Zum Ausgleichen der Last oder Weiterleitung von Anfragen an verfügbare Knoten ist ein Load-Balancer oder Proxyserver (z. B. NGINX oder AWS ELB) erforderlich, um Traffic an jeden Looker-Knoten weiterzuleiten. Der Load-Balancer verarbeitet Systemdiagnosen. 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. 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.
Looker-Anwendung (ausführbare JAR-Datei)
Sie müssen eine JAR-Datei der Looker-Anwendung verwenden, die Looker 3.56 oder höher ist.
Looker empfiehlt dringend, für jeden Knoten in einem Cluster dieselbe Looker-Version und dieselbe Patchversion auszuführen, wie unter Looker auf den Knoten starten auf dieser Seite beschrieben.
Cluster einrichten
Folgende Aufgaben sind erforderlich:
- Looker installieren
- MySQL-Anwendungsdatenbank einrichten
- Freigegebenes Dateisystem einrichten
- SSH-Schlüssel-Repository freigeben (je nach Situation)
- Ports für die Knotenkommunikation öffnen
- Looker auf den Knoten starten
Looker installieren
Prüfen Sie, ob Looker auf jedem Knoten installiert ist. Verwenden Sie dazu die JAR-Dateien der Looker-Anwendung und die Anleitung auf der Dokumentationsseite Vom Kunden gehostete Installationsschritte.
MySQL-Anwendungsdatenbank einrichten
Für eine geclusterte Looker-Konfiguration muss die Anwendungsdatenbank eine MySQL-Datenbank sein. Wenn Sie bereits eine nicht geclusterte Looker-Instanz haben, die HyperSQL für die Anwendungsdatenbank verwendet, müssen Sie die Anwendungsdaten aus den HyperSQL-Daten in Ihre neue freigegebene MySQL-Anwendungsdatenbank migrieren.
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 möglicherweise App-Manifestdateien – gehören zum freigegebenen Dateisystem. So richten Sie das freigegebene Dateisystem ein:
- 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. - Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
- Wenn Looker ausgeführt wird, fahren Sie Ihre Looker-Konfiguration herunter.
- Wenn Sie zuvor Cluster mit inotify-Linux-Scripts erstellt haben, beenden Sie diese Scripts, entfernen Sie sie aus cron und löschen Sie sie.
- Erstellen Sie eine Netzwerkfreigabe und stellen Sie sie auf jedem Knoten im Cluster bereit. Achten Sie darauf, dass er für die automatische Bereitstellung auf jedem Knoten konfiguriert ist und der Looker-Benutzer Lese- und Schreibzugriff auf diesen Knoten hat. Im folgenden Beispiel heißt die Netzwerkfreigabe
/mnt/looker-share
. Kopieren Sie die Bereitstellungsschlüssel auf einem Knoten und verschieben Sie Ihre Plug-ins sowie die Verzeichnisse
looker/models
undlooker/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/
Fügen Sie für jeden Knoten die Einstellung
--shared-storage-dir
zuLOOKERARGS
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 IhreLOOKERARGS
nicht in dieser Datei aufgeführt sind, hat jemand sie möglicherweise direkt dem$HOME/looker/looker
-Shell-Skript 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 Cluster mit freigegebenem Dateisystem aus einer vorhandenen Looker-Konfiguration und
- Sie haben Projekte, die in Looker 4.6 oder niedriger erstellt wurden.
Richten Sie das SSH-Schlüssel-Repository zur Freigabe ein:
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 Verzeichnisssh-share
(z. B./mnt
und/mnt/looker-share
) nicht für alle oder für Gruppen beschreibbar sein.Kopieren Sie auf einem Knoten den Inhalt von
$HOME/.ssh
in das neue Verzeichnisssh-share
. Beispiel:cp $HOME/.ssh/* /mnt/looker-share/ssh-share
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 durch.
Ö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.
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 | 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, mit dem andere Knoten diesen Knoten kontaktieren, z. B. die IP-Adresse des Knotens oder den Systemhostnamen 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 die Einrichtung des freigegebenen Verzeichnisses weiter oben auf dieser Seite verweisen, das die Verzeichnisse looker/model und looker/models-user-* enthält. |
Beispiel für LOOKERARGS
und Angeben von Datenbankanmeldedaten
Platzieren Sie die Looker-Start-Flags in einer lookerstart.cfg
-Datei im selben Verzeichnis wie die Looker-JAR-Dateien.
Beispielsweise können 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 unter der IP-Adresse 10.10.10.10 kontaktieren sollen.
Sie geben Folgendes an:
LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"
Die looker-db.yml
-Datei 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
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 (
~/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 eine neue Looker-Version 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 Methoden, Looker zu aktualisieren.
Sicherere Methode
- Erstellen Sie eine Sicherung der Anwendungsdatenbank.
- Beenden Sie alle Knoten des Clusters.
- Ersetzen Sie die JAR-Dateien auf jedem Server.
- Starten Sie jeden Knoten einzeln.
Schnellere Methode
So aktualisieren Sie mit dieser schnelleren, aber weniger vollständigen Methode:
- Erstellen Sie ein Replikat der Anwendungsdatenbank von Looker.
- Starten Sie einen neuen Cluster, der auf das Replikat verweist.
- Verweisen Sie den Proxyserver oder Load-Balancer auf die neuen Knoten. Anschließend können Sie die alten Knoten beenden.