Lösungen für vom Kunden gehostete Architekturen: Schritt-für-Schritt-Anleitungen für Komponenten

Auf dieser Seite werden gängige Praktiken für bestimmte Komponenten der Looker-Architektur erläutert und beschrieben, wie sie in einer Bereitstellung konfiguriert werden.

Looker hat eine Reihe von Abhängigkeiten für das Hosting des Servers, die Bereitstellung sowohl von Ad-hoc- als auch von geplanten Arbeitslasten, die Nachverfolgung der iterativen Modellentwicklung usw. Diese Abhängigkeiten werden auf dieser Seite als Komponenten bezeichnet. Jede Komponente wird in den folgenden Abschnitten ausführlich behandelt:

Hostkonfiguration

Betriebssystem und Distribution

Looker funktioniert gut auf den gängigsten Linux-Versionen: RedHat, SUSE und Debian/Ubuntu. Ableitungen dieser Distributionen, die für die Ausführung in einer bestimmten Umgebung entwickelt und optimiert wurden, sind in der Regel in Ordnung. Beispielsweise sind die Google Cloud - oder AWS-Distributionen von Linux mit Looker kompatibel. Debian/Ubuntu ist die am häufigsten verwendete Linux-Variante in der Looker-Community und diese Versionen sind dem Looker-Support am besten vertraut. Am einfachsten ist es, Debian/Ubuntu oder ein Betriebssystem für einen bestimmten Cloud-Anbieter zu verwenden, das von Debian/Ubuntu abgeleitet ist.

Looker wird in der Java Virtual Machine (JVM) ausgeführt. Berücksichtigen Sie bei der Auswahl einer Distribution, ob die Versionen von OpenJDK 11 auf dem neuesten Stand sind. Auf älteren Linux-Distributionen kann Looker möglicherweise ausgeführt werden. Die Java-Version und die Bibliotheken, die Looker für bestimmte Funktionen benötigt, müssen jedoch auf dem neuesten Stand sein. Wenn die JVM nicht alle empfohlenen Looker-Bibliotheken und -Versionen enthält, funktioniert Looker nicht normal. Für Looker ist Java HotSpot 1.8 Update 161 oder höher oder Java OpenJDK 11.0.12 oder höher erforderlich.

CPU und Arbeitsspeicher

4 x 16 (4 CPUs und 16 GB RAM) Knoten reichen für ein Entwicklungssystem oder eine einfache Looker-Testinstanz für ein kleines Team aus. Für den Produktionseinsatz ist dies jedoch in der Regel nicht ausreichend. Unserer Erfahrung nach bieten 16 x 64 Knoten (16 CPUs und 64 GB RAM) ein gutes Preis-Leistungs-Verhältnis. Mehr als 64 GB RAM können sich auf die Leistung auswirken, da Garbage-Collection-Ereignisse ein einzelnes Thread haben und alle anderen Threads anhalten.

Festplattenspeicher

100 GB Speicherplatz sind für ein Produktionssystem in der Regel mehr als ausreichend.

Hinweise zu Clustern

Looker wird auf einer Java-JVM ausgeführt. Bei Java kann es zu Problemen beim Verwalten von mehr als 64 GB Arbeitsspeicher kommen. Wenn mehr Kapazität erforderlich ist, sollten Sie dem Cluster in der Regel zusätzliche 16 x 64-Knoten hinzufügen, anstatt die Größe der Knoten über 16 x 64 zu erhöhen. Möglicherweise bevorzugen wir auch eine Clusterarchitektur für eine höhere Verfügbarkeit.

In einem Cluster müssen die Looker-Knoten bestimmte Teile des Dateisystems gemeinsam nutzen. Zu den weitergegebenen Daten gehören:

  • LookML-Modelle
  • Die LookML-Modelle des Entwicklers
  • Git-Serververbindung

Da das Dateisystem freigegeben ist und eine Reihe von Git-Repositories hostet, ist die Verarbeitung des gleichzeitigen Zugriffs und der Dateisperre entscheidend. Das Dateisystem muss POSIX-konform sein. Das Network File System (NFS) ist bekannt und unter Linux verfügbar. Sie sollten eine zusätzliche Linux-Instanz erstellen und NFS so konfigurieren, dass das Laufwerk freigegeben wird. Standard-NFS ist potenziell ein Single Point of Failure. Daher sollten Sie eine Failover- oder Hochverfügbarkeitseinrichtung in Betracht ziehen.

Die Looker-Metadaten müssen ebenfalls zentralisiert werden, sodass die interne Datenbank zu MySQL migriert werden muss. Dies kann ein MySQL-Dienst oder eine dedizierte MySQL-Bereitstellung sein. Im Abschnitt Interne (Backend-)Datenbank auf dieser Seite finden Sie weitere Informationen.

JVM-Konfiguration

Die Looker-JVM-Einstellungen werden im Looker-Startskript definiert. Nach jeder Aktualisierung muss Looker neu gestartet werden, damit die Änderungen wirksam werden. Die Standardkonfigurationen sind: 

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

Ressourcen

Die Ressourceneinstellungen werden im Looker-Startskript definiert. 

JAVAMEM="2300m"
METAMEM="800m"

Bei der Arbeitsspeicherzuweisung für die JVM muss der Overhead des Betriebssystems berücksichtigt werden, unter dem Looker ausgeführt wird. Als Faustregel gilt, dass der JVM bis zu 60% des gesamten Arbeitsspeichers zugewiesen werden können. Je nach Größe des Computers gibt es jedoch Einschränkungen. Für Maschinen mit mindestens 8 GB Arbeitsspeicher empfehlen wir, 4–5 GB für Java und 800 MB für Meta zuzuweisen. Bei größeren Maschinen kann dem Betriebssystem ein geringerer Arbeitsspeicheranteil zugewiesen werden. Für Maschinen mit 60 GB Arbeitsspeicher empfehlen wir beispielsweise, 36 GB für Java und 1 GB für Meta zuzuweisen. Die Arbeitsspeicherzuweisung von Java sollte normalerweise mit dem Gesamtspeicher des Computers skalieren. Für Meta sollte jedoch 1 GB ausreichen.

Da Looker Systemressourcen für das Rendern mit anderen Prozessen wie Chromium teilt, sollte die Menge des Java-Arbeitsspeichers im Hinblick auf die erwartete Renderlast und die Größe des Computers ausgewählt werden. Wenn die Renderinglast voraussichtlich niedrig ist, kann Java ein größerer Anteil des gesamten Arbeitsspeichers zugewiesen werden. Auf einem Computer mit 60 GB Arbeitsspeicher können beispielsweise 46 GB für Java zugewiesen werden, was über der allgemeinen Empfehlung von 60% liegt. Die genaue Ressourcenzuweisung für jede Bereitstellung variiert. Verwenden Sie daher 60% als Ausgangspunkt und passen Sie die Zuweisung an die Nutzung an.

Automatische Speicherbereinigung

Looker verwendet vorzugsweise den modernsten Garbage Collector, der für die Java-Version verfügbar ist. Standardmäßig beträgt das Zeitlimit für die Garbage Collection 2 Sekunden. Sie können es jedoch ändern, indem Sie die folgende Option in der Startkonfiguration bearbeiten: 

-XX:MaxGCPauseMillis=2000

Auf einem größeren Computer mit mehreren Kernen kann die Zeitüberschreitung für die Garbage Collection verkürzt werden.

Logs

Die Looker-Logs zur automatischen Speicherbereinigung werden standardmäßig in /tmp/gc.log gespeichert. Sie können dies ändern, indem Sie die folgende Option in der Startkonfiguration bearbeiten: 

-Xloggc:/tmp/gc.log

JMX

Die Verwaltung von Looker erfordert möglicherweise ein Monitoring, um die Ressourcen besser zu optimieren. Wir empfehlen die Verwendung von JMX, um die JVM-Arbeitsspeichernutzung zu überwachen.

Looker-Startoptionen

Die Startoptionen werden in einer Datei namens lookerstart.cfg gespeichert. Diese Datei wird im Shell-Script verwendet, das Looker startet.

Thread pools

Da Looker eine mehrstufige Anwendung ist, hat sie eine Reihe von Threadpools. Diese Threadpools reichen vom Webserverkern bis hin zu spezialisierten Unterdiensten wie Planung, Rendering und externen Datenbankverbindungen. Je nach Ihren Geschäftsabläufen müssen diese Pools möglicherweise von der Standardkonfiguration geändert werden. Insbesondere gibt es spezielle Überlegungen für die Clustertopologien, die auf der Seite Muster und Praktiken für die vom Kunden gehostete Infrastrukturarchitektur erwähnt werden.

Optionen für einen hohen Planungsdurchsatz

Fügen Sie für alle Knoten, die nicht dem Planer zugeordnet sind, der Umgebungsvariablen LOOKERARGS in lookerstart.cfg --scheduler-threads=0 hinzu. Ohne Planerthreads werden auf diesen Knoten keine geplanten Jobs ausgeführt.

Fügen Sie für alle dedizierten Scheduler-Knoten der Umgebungsvariablen LOOKERARGS in lookerstart.cfg --scheduler-threads=<n> hinzu. Looker startet standardmäßig mit 10 Scheduler-Threads, die Anzahl kann aber auf <n> erhöht werden. Mit <n> Scheduler-Threads kann jeder Knoten <n> gleichzeitige geplante Jobs ausführen. Im Allgemeinen wird empfohlen, <n> auf weniger als das Doppelte der Anzahl der CPUs festzulegen. Der größte empfohlene Host hat 16 CPUs und 64 GB Arbeitsspeicher. Die Obergrenze für Scheduler-Threads sollte daher unter 32 liegen.

Optionen für einen hohen Rendering-Durchsatz

Fügen Sie allen Nicht-Renderknoten in lookerstart.cfg die Umgebungsvariable LOOKERARGS mit dem Wert --concurrent-render-jobs=0 hinzu. Ohne Rendererknoten werden auf diesen Knoten keine Renderjobs ausgeführt.

Fügen Sie für alle dedizierten Renderknoten der Umgebungsvariablen LOOKERARGS in lookerstart.cfg --concurrent-render-jobs=<n> hinzu. Looker startet standardmäßig mit zwei Rendering-Threads, die Anzahl kann aber auf <n> erhöht werden. Mit <n> Rendering-Threads kann jeder Knoten <n> parallele Rendering-Jobs ausführen.

Jeder Renderjob kann einen erheblichen Arbeitsspeicher belegen. Sie sollten etwa 2 GB pro Renderjob einplanen. Wenn beispielsweise dem Looker-Kernprozess (Java) 60% des gesamten Arbeitsspeichers zugewiesen werden und 20% des verbleibenden Arbeitsspeichers für das Betriebssystem reserviert sind, bleiben 20% für Renderjobs übrig. Auf einem 64-GB-Rechner bleiben 12 GB übrig, was für sechs gleichzeitige Renderjobs ausreicht. Wenn ein Knoten dem Rendering gewidmet ist und nicht zum Load Balancer-Pool gehört, der interaktive Jobs verarbeitet, kann der Arbeitsspeicher des Looker-Prozesses reduziert werden, um mehr Renderjobs zu ermöglichen. Auf einem 64-GB-Rechner können Sie dem Looker-Kernprozess etwa 30% (20 GB) zuweisen. Wenn Sie 20% für die allgemeine Nutzung des Betriebssystems reservieren, bleiben 50% (32 GB) für das Rendern übrig. Das reicht für 16 gleichzeitige Renderjobs.

Interne (Backend-)Datenbank

Der Looker-Server verwaltet Informationen zu seiner eigenen Konfiguration, Datenbankverbindungen, Nutzern, Gruppen und Rollen, Ordnern, benutzerdefinierten Looks und Dashboards sowie verschiedene andere Daten in einer internen Datenbank.

Bei einer eigenständigen Looker-Instanz mittlerer Größe werden diese Daten in einer speicherinternen HyperSQL-Datenbank gespeichert, die in den Looker-Prozess eingebettet ist. Die Daten für diese Datenbank werden in der Datei <looker install directory>/.db/looker.script gespeichert. Diese Datenbank ist zwar praktisch und effizient, bei intensiver Nutzung treten jedoch Leistungsprobleme auf. Wir empfehlen daher, mit einer Remote-MySQL-Datenbank zu beginnen. Andernfalls empfehlen wir, die Datei in eine Remote-MySQL-Datenbank zu migrieren, sobald sie 600 MB erreicht hat.~/looker/.db/looker.script Cluster müssen eine MySQL-Datenbank verwenden.

Der Looker-Server führt viele kleine Lese- und Schreibvorgänge in der MySQL-Datenbank aus. Jedes Mal, wenn ein Nutzer einen Look oder ein Explore ausführt, prüft Looker in der Datenbank, ob der Nutzer noch angemeldet ist, ob er Berechtigungen für den Zugriff auf die Daten hat, ob er Berechtigungen für die Ausführung des Looks oder Explores hat usw. Looker schreibt auch Daten in die MySQL-Datenbank, z. B. die tatsächlich ausgeführte SQL-Abfrage und die Uhrzeit, zu der die Anfrage gestartet und beendet wurde. Eine einzelne Interaktion zwischen einem Nutzer und der Looker-Anwendung kann 15 oder 20 kleine Lese- und Schreibvorgänge in der MySQL-Datenbank auslösen.

MySQL

Der MySQL-Server sollte Version 8.0.x haben und für die Verwendung der utf8mb4-Codierung konfiguriert sein. Die InnoDB-Speicher-Engine muss verwendet werden. Eine Anleitung zum Einrichten von MySQL sowie eine Anleitung zum Migrieren von Daten aus einer vorhandenen HyperSQL-Datenbank zu MySQL finden Sie auf der Dokumentationsseite Looker-Backend-Datenbank zu MySQL migrieren.

Wenn Sie Looker für die Verwendung von MySQL konfigurieren, muss eine YAML-Datei mit den Verbindungsinformationen erstellt werden. Benennen Sie die YAML-Datei in looker-db.yml und fügen Sie die Einstellung -d looker-db.yml im Abschnitt LOOKERARGS der Datei lookerstart.cfg hinzu.

MariaDB

MySQL ist doppelt lizenziert und sowohl als Open-Source- als auch als kommerzielles Produkt verfügbar. Oracle hat MySQL weiter verbessert und MySQL wurde als MariaDB abgespalten. Die MariaDB-Entsprechungen von MySQL funktionieren zwar mit Looker, werden aber nicht von den Looker-Entwicklungsteams entwickelt oder getestet. Daher wird die Funktionalität nicht unterstützt oder garantiert.

Cloud-Versionen

Wenn Sie Looker in Ihrer Cloud-Infrastruktur hosten, ist es sinnvoll, die MySQL-Datenbank in derselben Cloud-Infrastruktur zu hosten. Die drei großen Cloud-Anbieter: Amazon AWS, Microsoft Azure und Google Cloud. Die Cloud-Anbieter übernehmen einen Großteil der Wartung und Konfiguration der MySQL-Datenbank und bieten Dienste wie die Verwaltung von Sicherungen und die schnelle Wiederherstellung. Diese Produkte sind für ihre gute Kompatibilität mit Looker bekannt.

Abfragen zur Systemaktivität

In der MySQL-Datenbank werden Informationen dazu gespeichert, wie Nutzer Looker verwenden. Jeder Looker-Nutzer, der die Berechtigung zum Ansehen des Modells Systemaktivität hat, hat Zugriff auf eine Reihe vordefinierter Looker-Dashboards, um diese Daten zu analysieren. Nutzer können auch auf Explores von Looker-Metadaten zugreifen, um zusätzliche Analysen zu erstellen. Die MySQL-Datenbank wird hauptsächlich für kleine, schnelle und „operative“ Abfragen verwendet. Die großen, langsamen „analytischen“ Abfragen, die vom Systemaktivitätsmodell generiert werden, können mit diesen betrieblichen Abfragen konkurrieren und Looker verlangsamen.

In diesen Fällen kann die MySQL-Datenbank in einer anderen Datenbank repliziert werden. Sowohl selbstverwaltete als auch bestimmte cloudbasierte Systeme bieten eine grundlegende Konfiguration der Replikation in anderen Datenbanken. Die Konfiguration der Replikation wird in diesem Dokument nicht behandelt.

Wenn Sie das Replikat für Abfragen zur Systemaktivität verwenden möchten, erstellen Sie eine Kopie der Datei looker-db.yml, z. B. mit dem Namen looker-usage-db.yml, ändern Sie sie so, dass sie auf das Replikat verweist, und fügen Sie dem Abschnitt LOOKERARGS der Datei lookerstart.cfg die Einstellung --internal-analytics-connection-file looker-usage-db.yml hinzu.

Die Abfragen zur Systemaktivität können auf einer MySQL-Instanz oder einer Google BigQuery-Datenbank ausgeführt werden. Sie werden nicht mit anderen Datenbanken verglichen.

MySQL-Leistungskonfiguration

Zusätzlich zu den Einstellungen, die für die Migration der Looker-Backend-Datenbank zu MySQL erforderlich sind, können hochaktive Cluster von zusätzlicher Optimierung und Konfiguration profitieren. Diese Einstellungen können in der Datei /etc/my.cnf oder über die Google Cloud Console für cloudverwaltete Instanzen vorgenommen werden.

Die my.cnf-Konfigurationsdatei ist in mehrere Teile unterteilt. Die folgenden in diesem Abschnitt beschriebenen Einstellungsänderungen werden im Bereich [mysqld] vorgenommen.

Größe des InnoDB-Pufferpools festlegen

Die Größe des InnoDB-Pufferpools ist der gesamte RAM, der zum Speichern des Status der InnoDB-Dateien im Arbeitsspeicher verwendet wird. Wenn der Server ausschließlich für die Ausführung von MySQL verwendet wird, sollte innodb_buffer_pool_size auf 50 % bis 70% des gesamten Systemspeichers festgelegt werden.

Wenn die Gesamtgröße der Datenbank klein ist, können Sie den InnoDB-Pufferpool auf die Größe der Datenbank statt auf 50% oder mehr des Arbeitsspeichers festlegen.

In diesem Beispiel hat ein Server 64 GB Arbeitsspeicher. Daher sollte der InnoDB-Pufferpool zwischen 32 GB und 45 GB liegen. Je größer, desto besser. 

[mysqld]
...
innodb_buffer_pool_size=45G

InnoDB-Pufferpoolinstanzen festlegen

Wenn mehrere Threads versuchen, einen großen Pufferpool zu durchsuchen, kann es zu Konflikten kommen. Um dies zu verhindern, wird der Pufferpool in kleinere Einheiten unterteilt, auf die verschiedene Threads konfliktfrei zugreifen können. Standardmäßig ist der Pufferpool in 8 Instanzen unterteilt. Dies kann zu einem Engpass bei 8 Threads führen. Durch eine Erhöhung der Anzahl der Pufferpoolinstanzen verringert sich die Wahrscheinlichkeit eines Engpasses. Die innodb_buffer_pool_instances sollte so festgelegt werden, dass jeder Pufferpool mindestens 1 GB Arbeitsspeicher erhält. 

[mysqld]
...
innodb_buffer_pool_instances=32

InnoDB-Logdatei optimieren

Wenn eine Transaktion verbindlich wird, kann die Datenbank die Daten in der tatsächlichen Datei aktualisieren oder Details zur Transaktion im Protokoll speichern. Wenn die Datenbank abstürzt, bevor die Datendateien aktualisiert wurden, kann die Protokolldatei „abgespielt“ werden, um die Änderungen anzuwenden. Das Schreiben in die Protokolldatei ist ein kleiner Append-Vorgang. Es ist effizient, dem Protokoll zum Zeitpunkt des Commits etwas hinzuzufügen und dann mehrere Änderungen an den Datendateien in einem einzigen E/A-Vorgang zu schreiben. Wenn die Protokolldatei voll ist, muss die Datenbank die Verarbeitung neuer Transaktionen pausieren und alle geänderten Daten wieder auf die Festplatte schreiben.

Als Faustregel gilt, dass die InnoDB-Protokolldatei groß genug sein sollte, um Transaktionen von einer Stunde zu enthalten.

Normalerweise gibt es zwei InnoDB-Protokolldateien. Sie sollten etwa 25% Ihres InnoDB-Pufferpools ausmachen. Bei einer Beispieldatenbank mit einem Pufferpool von 32 GB sollten die InnoDB-Protokolldateien insgesamt 8 GB oder 4 GB pro Datei betragen. 

[mysqld]
...
innodb_log_file_size=8GB

InnoDB-E/A-Kapazität konfigurieren

MySQL drosselt die Geschwindigkeit, mit der Schreibvorgänge auf das Laufwerk aufgezeichnet werden, um den Server nicht zu überlasten. Die Standardwerte sind für die meisten Server konservativ. Für eine optimale Leistung sollten Sie mit dem Dienstprogramm sysbench die Geschwindigkeit des zufälligen Schreibens auf das Datenlaufwerk messen und dann mit diesem Wert die I/O-Kapazität so konfigurieren, dass MySQL Daten schneller schreibt.

Bei einem in der Cloud gehosteten System sollte der Cloud-Anbieter die Leistung der Laufwerke, die für die Datenspeicherung verwendet werden, erfassen können. Messen Sie bei einem selbst gehosteten MySQL-Server die Geschwindigkeit der zufälligen Schreibvorgänge auf das Datenlaufwerk in E/A-Vorgängen pro Sekunde (IOPS). Das Linux-Dienstprogramm sysbench ist eine Möglichkeit, dies zu messen. Verwenden Sie diesen Wert für innodb_io_capacity_max und einen Wert, der zwischen der Hälfte und drei Vierteln dieses Werts liegt, für innodb_io_capacity. Im folgenden Beispiel sehen wir die Werte, die wir bei 800 IOPS gemessen haben. 

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

InnoDB-Threads konfigurieren

MySQL öffnet mindestens einen Thread für jeden Client, der bedient wird. Wenn viele Clients gleichzeitig verbunden sind, kann das zu einer großen Anzahl von Threads führen, die verarbeitet werden müssen. Dies kann dazu führen, dass das System mehr Zeit für das Auslagern als für die Verarbeitung aufwendet.

Die ideale Anzahl von Threads sollte durch Benchmarking ermittelt werden. Legen Sie für den Test die Anzahl der Threads zwischen der Anzahl der CPUs (oder CPU-Kerne) im System und dem Vierfachen der Anzahl der CPUs fest. Bei einem 16-Kern-System liegt dieser Wert wahrscheinlich zwischen 16 und 64. 

[mysqld]
...
innodb_thread_concurrency=32

Transaktionsdauer

Bei einem Transaktionswert von 1 wird MySQL gezwungen, bei jeder Transaktion auf die Festplatte zu schreiben. Wenn der Server abstürzt, geht die Transaktion nicht verloren, aber die Datenbankleistung wird beeinträchtigt. Wenn Sie diesen Wert auf 0 oder 2 festlegen, kann die Leistung verbessert werden. Es besteht jedoch das Risiko, dass Datentransaktionen von einigen Sekunden verloren gehen. 

[mysqld]
...
innodb_flush_log_at_trx_commit=1

Spülenmethode festlegen

Das Betriebssystem übernimmt normalerweise das Puffern von Schreibvorgängen auf das Laufwerk. Da sowohl MySQL als auch das Betriebssystem zwischenspeichern, kommt es zu Leistungseinbußen. Wenn Sie die Flush-Methode um eine Pufferebene reduzieren, kann sich die Leistung verbessern. 

[mysqld]
...
innodb_flush_method=O_DIRECT

Eine Datei pro Tabelle aktivieren

Standardmäßig verwendet MySQL eine einzelne Datendatei für alle Daten. Bei der Einstellung innodb_file_per_table wird für jede Tabelle eine separate Datei erstellt, was die Leistung und die Datenverwaltung verbessert. 

[mysqld]
...
innodb_file_per_table=ON

Statistiken zu Metadaten deaktivieren

Bei dieser Einstellung werden keine Statistiken in internen Metadatentabellen erfasst, wodurch die Leseleistung verbessert wird. 

[mysqld]
...
innodb_stats_on_metadata=OFF

Abfrage-Cache deaktivieren

Der Abfragecache wird nicht mehr unterstützt. Wenn Sie query_cache_size und query_cache_type auf 0 setzen, wird er deaktiviert. 

[mysqld]
...
query_cache_size=0
query_cache_type=0

Join-Puffer vergrößern

Der join_buffer wird verwendet, um Joins im Arbeitsspeicher auszuführen. Durch eine Erhöhung kann die Leistung bestimmter Vorgänge verbessert werden. 

[mysqld]
...
join_buffer_size=512KB

Größe der temporären Tabelle und des maximalen Heaps vergrößern

Mit tmp_table_size und max_heap_table_size werden angemessene Standardwerte für temporäre In-Memory-Tabellen festgelegt, bevor sie auf das Laufwerk geschrieben werden. 

[mysqld
...
tmp_table_size=32MB
max_heap_table_size=32MB

Cache für geöffnete Tabellen anpassen

Die Einstellung table_open_cache bestimmt die Größe des Caches, der die Dateideskriptoren für geöffnete Tabellen enthält. Bei der Einstellung table_open_cache_instances wird der Cache in mehrere kleinere Teile aufgeteilt. Es besteht die Gefahr von Threadkonflikten in der table_open_cache. Durch die Aufteilung in kleinere Teile lässt sich die Parallelität erhöhen. 

[mysqld]
...
table_open_cache=2048
table_open_cache_instances=16

Git-Dienst

Looker wurde für die Verwendung mit einem Git-Dienst entwickelt, um die Versionsverwaltung der LookML-Dateien zu ermöglichen. Es werden gängige Git-Hosting-Dienste unterstützt, darunter GitHub, GitLab und Bitbucket. Git-Anbieter bieten zusätzliche Vorteile wie eine Benutzeroberfläche zum Ansehen von Codeänderungen und Unterstützung für Workflows wie Pull-Requests und Änderungsgenehmigungen. Bei Bedarf kann Git auf einem einfachen Linux-Server ausgeführt werden.

Wenn ein Git-Hostingdienst aufgrund von Sicherheitsregeln nicht für Ihre Bereitstellung geeignet ist, bieten viele dieser Dienstanbieter Versionen an, die in Ihrer eigenen Umgebung ausgeführt werden können. Insbesondere GitLab wird häufig selbst gehostet und kann als Open-Source-Produkt ohne Lizenzkosten oder als unterstütztes lizenziertes Produkt verwendet werden. GitHub Enterprise ist als selbst gehosteter Dienst verfügbar und ein unterstütztes kommerzielles Produkt.

In den folgenden Abschnitten werden die Besonderheiten der gängigsten Dienstanbieter aufgeführt.

GitHub/GitHub Enterprise

Auf der Dokumentationsseite Git-Verbindung einrichten und testen wird GitHub als Beispiel verwendet.

GitLab/gitlab.com

Eine ausführliche Anleitung zur Einrichtung von GitLab finden Sie im Looker-Communitybeitrag GitLab für die Versionskontrolle in Looker verwenden. Wenn sich Ihr Repository in Untergruppen befindet, können diese der Repository-URL entweder im HTTPS- oder SSH-Format hinzugefügt werden: 

https://gitlab.com/accountname/subgroup/reponame


git@gitlab.com:accountname/subgroup/reponame.git

Außerdem gibt es drei verschiedene Möglichkeiten, von Looker generierte SSH-Schlüssel in GitLab zu speichern: als Nutzer-SSH-Schlüssel, als Repository-Deployment-Schlüssel oder als global freigegebener Deployment-Schlüssel. Eine ausführlichere Erklärung finden Sie in der GitLab-Dokumentation.

Google Cloud Quelle

Im Communitybeitrag Cloud Source Repositories für die Versionskontrolle in Looker verwenden finden Sie eine Anleitung zum Einrichten von Git mit Cloud Source Repositories.

Bitbucket Cloud

Eine Anleitung zum Einrichten von Git mit Bitbucket Cloud finden Sie im Communitybeitrag Bitbucket für die Versionskontrolle in Looker verwenden. Seit August 2021 werden in Bitbucket Cloud keine Geheimnisse in Deploy-Webhooks unterstützt.

Bitbucket Server

Wenn Sie Pull-Requests mit Bitbucket Server verwenden möchten, müssen Sie möglicherweise die folgenden Schritte ausführen:

  1. Wenn Sie einen Pull-Request öffnen, verwendet Looker automatisch die Standardportnummer (7999) in der URL. Wenn Sie eine benutzerdefinierte Portnummer verwenden, müssen Sie die Portnummer in der URL manuell ersetzen.
  2. Sie müssen den Bereitstellungs-Webhook des Projekts aufrufen, um den Produktionszweig in Looker mit dem Hauptzweig des Repositorys zu synchronisieren.

Phabricator-Einführung

Im Communitybeitrag Phabricator und Looker für die Versionskontrolle einrichten finden Sie eine Anleitung zum Einrichten von Git mit Phabricator.

Netzwerk

Eingehende Verbindungen

Looker-Webanwendung

Standardmäßig wartet Looker auf HTTPS-Anfragen an Port 9999. Looker verwendet ein selbst signiertes Zertifikat mit der CN self-signed.looker.com. Der Looker-Server kann alternativ für Folgendes konfiguriert werden:

  1. HTTP-Verbindungen von einem Load Balancer/Proxy mit SSL-Beendigung mit dem --ssl-provided-externally-by=<s> Startup-Flag akzeptieren Der Wert sollte entweder auf die IP-Adresse des Proxys oder auf einen Hostnamen festgelegt werden, der lokal in die IP-Adresse des Proxys aufgelöst werden kann. Looker akzeptiert nur HTTP-Verbindungen von dieser IP-Adresse.
  2. Verwenden Sie ein vom Kunden bereitgestelltes SSL-Zertifikat mit dem Startflag --ssl-keystore=<s>.

Looker API

Die Looker API überwacht Port 19999. Wenn für die Installation Zugriff auf die API erforderlich ist, sollte der Load Balancer die erforderlichen Weiterleitungsregeln haben. Für die SSL-Verschlüsselung gelten dieselben Überlegungen wie für die Hauptwebanwendung. Wir empfehlen, einen anderen Port als den der Webanwendung zu verwenden.

Load-Balancer

Ein Load Balancer wird häufig verwendet, um eine HTTPS-Anfrage an Port 443 mit dem Zertifikat des Kunden anzunehmen und die Anfrage dann mit dem selbstsignierten Zertifikat oder HTTP an den Looker-Serverknoten an Port 9999 weiterzuleiten. Wenn Load Balancer das selbst signierte Zertifikat von Looker verwenden, müssen sie so konfiguriert werden, dass sie dieses Zertifikat akzeptieren.

Inaktive Verbindungen und Zeitüberschreitungen

Wenn ein Nutzer eine große Anfrage in Looker startet, kann das zu einer Abfrage führen, deren Ausführung in der Datenbank sehr aufwendig ist. Wenn der Nutzer diese Anfrage auf irgendeine Weise abbricht, z. B. indem er den Laptop schließt, die Verbindung zum Netzwerk trennt oder den Tab im Browser schließt, muss Looker diese Datenbankabfrage beenden.

Wenn die Client-Webanwendung eine Anfrage zum Ausführen einer Datenbankabfrage stellt, öffnet der Browser eine Socket-Verbindung mit einer langlebigen HTTP-Anfrage an den Looker-Server. Diese Verbindung bleibt offen und inaktiv. Dieser Socket wird getrennt, wenn die Client-Webanwendung auf irgendeine Weise beendet oder getrennt wird. Der Server erkennt diese Trennung und bricht alle zugehörigen Datenbankabfragen ab.

Load Balancer erkennen diese offenen, inaktiven Verbindungen häufig und beenden sie. Damit Looker effizient ausgeführt werden kann, muss der Load Balancer so konfiguriert sein, dass diese Verbindung so lange geöffnet bleibt, wie die längste Abfrage eines Nutzers ausgeführt wird. Wir empfehlen eine Zeitüberschreitung von mindestens 60 Minuten.

Ausgehende Verbindungen

Looker-Server können unbegrenzten ausgehenden Zugriff auf alle Ressourcen haben, einschließlich des öffentlichen Internets. Dies vereinfacht viele Aufgaben, z. B. die Installation von Chromium, für die Zugriff auf die Paket-Repositories der Linux-Distribution erforderlich ist.

Im Folgenden finden Sie ausgehende Verbindungen, die Looker möglicherweise herstellen muss.

Interne Datenbankverbindung

Standardmäßig überwacht MySQL Verbindungen an Port 3306. Die Looker-Knoten müssen über diesen Port Verbindungen zu MySQL herstellen können. Je nachdem, wie das Repository gehostet wird, müssen Sie möglicherweise eine Firewall durchqueren.

Externe Dienstleistungen

Die Looker-Telemetrie- und Lizenzserver sind über HTTPS im öffentlichen Internet verfügbar. Traffic von einem Looker-Knoten zu ping.looker.com:443 und license.looker.com:443 muss möglicherweise einer Zulassungsliste hinzugefügt werden.

Data-Warehouse-Verbindungen

Für in der Cloud gehostete Datenbanken ist möglicherweise eine Verbindung über das öffentliche Internet erforderlich. Wenn Sie beispielsweise BigQuery verwenden, müssen accounts.google.com:443 und www.googleapis.com:443 möglicherweise einer Zulassungsliste hinzugefügt werden. Wenn sich die Datenbank außerhalb Ihrer eigenen Infrastruktur befindet, erkundigen Sie sich bei Ihrem Datenbankhost nach den Netzwerkdetails.

SMTP-Dienste

Standardmäßig sendet Looker ausgehende E-Mails über SendGrid. Möglicherweise müssen Sie smtp.sendgrid.net:587 einer Zulassungsliste hinzufügen. Die SMTP-Einstellungen können in der Konfiguration so geändert werden, dass ein anderer E-Mail-Handler verwendet wird.

Action Hubs, Action-Server und Webhooks

Bei vielen Zielen des Zeitplaners, insbesondere bei Webhooks und solchen, die im Looker-Admin-Bereich aktiviert sind, werden Daten per HTTPS-Anfrage gesendet.

  • Bei Webhooks werden diese Ziele von Nutzern zur Laufzeit angegeben und können dem Ziel der Firewall für ausgehende Verbindungen widersprechen.
  • Bei einem Action-Hub werden diese Anfragen an actions.looker.com gesendet. Weitere Informationen finden Sie in der Dokumentation zur Konfiguration von Looker Action Hub.
  • Bei anderen Action-Servern werden diese Anfragen an die Domains gesendet, die Administratoren im Looker-Bereich Verwaltung in der Konfiguration des Action-Servers angegeben haben.

Proxy server

Wenn das öffentliche Internet nicht direkt erreichbar ist, kann Looker so konfiguriert werden, dass ein Proxyserver für HTTP(S)-Anfragen verwendet wird. Fügen Sie dazu eine Zeile wie die folgende zu lookerstart.cfg hinzu: 

JAVAARGS="-Dhttp.proxyHost=myproxy.example.com
  -Dhttp.proxyPort=8080
  -Dhttp.nonProxyHosts=127.0.0.1|localhost
  -Dhttps.proxyHost=myproxy.example.com
  -Dhttps.proxyPort=8080"

Die Kommunikation zwischen Knoten erfolgt über HTTPS. Wenn Sie also einen Proxyserver verwenden und Ihre Instanz in einem Cluster ausgeführt wird, sollten Sie dem Dhttp.nonProxyHosts-Argument in der Regel die IP-Adressen/Hostnamen aller Knoten im Cluster hinzufügen.

Interknoten-Kommunikation

Interne Host-ID

Innerhalb eines Clusters muss jeder Knoten mit den anderen Knoten kommunizieren können. Dazu wird in der Startkonfiguration der Hostname oder die IP-Adresse jedes Knotens angegeben. Beim Starten des Knotens wird dieser Wert in das MySQL-Repository geschrieben. Andere Mitglieder des Clusters können dann auf diese Werte verweisen, um mit diesem Knoten zu kommunizieren. Wenn Sie den Hostnamen oder die IP-Adresse in der Startkonfiguration angeben möchten, fügen Sie der Umgebungsvariablen LOOKERARGS in lookerstart.cfg -H node1.looker.example.com hinzu.

Da der Hostname pro Knoten eindeutig sein muss, muss die lookerstart.cfg-Datei auf jeder Instanz eindeutig sein. Alternativ zum Einbetten des Hostnamens oder der IP-Adresse können Sie den Befehl hostname -I oder hostname --fqdn verwenden, um diese Werte zur Laufzeit zu ermitteln. Fügen Sie dazu der Umgebungsvariablen LOOKERARGS in lookerstart.cfg -H $(hostname -I) oder -H $(hostname --fqdn) hinzu.

Interne Ports

Zusätzlich zu den Ports 9999 und 19999, die für den Web- und API-Server verwendet werden, kommunizieren die Clusterknoten über einen Message-Broker-Dienst, der die Ports 1551 und 61616 verwendet. Die Ports 9999 und 19999 müssen für den Endnutzerverkehr geöffnet sein, 1551 und 61616 jedoch zwischen den Clusterknoten.