Soluzioni di architettura ospitate dal cliente: procedure dettagliate dei componenti

Questa pagina esplora le pratiche comuni per componenti specifici dell'architettura di Looker e descrive come configurarle in un deployment.

Looker ha una serie di dipendenze per l'hosting del server, la gestione di carichi di lavoro ad hoc e pianificati, il monitoraggio dello sviluppo di modelli iterativi o simili. In questa pagina queste dipendenze sono indicate come componenti e ogni componente è trattato in dettaglio nelle sezioni seguenti:

Configurazione host

Sistema operativo e distribuzione

Looker funziona bene sulle versioni più comuni di Linux: RedHat, SUSE e Debian/Ubuntu. Le derivate di queste distribuzioni, progettate e ottimizzate per essere eseguite in un particolare ambiente, sono in genere corrette. Ad esempio, le distribuzioni di Linux di Google Cloud o AWS sono compatibili con Looker. Debian/Ubuntu è la varietà di Linux più utilizzata nella community di Looker e queste sono le versioni più familiari all'assistenza di Looker. È più facile utilizzare Debian/Ubuntu o un sistema operativo per un provider cloud specifico derivato da Debian/Ubuntu.

Looker viene eseguito nella macchina virtuale Java (JVM). Quando scegli una distribuzione, valuta se le versioni di OpenJDK 11 sono aggiornate. Le distribuzioni meno recenti di Linux potrebbero essere in grado di eseguire Looker, ma la versione e le librerie Java richieste da Looker per funzionalità specifiche devono essere aggiornate. Se la JVM non contiene tutte le librerie e le versioni di Looker consigliate, Looker non funzionerà normalmente. Looker richiede l'aggiornamento Java HotSpot 1.8 161 o versioni successive oppure Java OpenJDK 11.0.12 o versioni successive.

CPU e memoria

4x16 (4 CPU e 16 GB di RAM) nodi sono sufficienti per un sistema di sviluppo o un'istanza di Looker di test di base utilizzata da un piccolo team. Tuttavia, per l'utilizzo in produzione, in genere non è sufficiente. In base alla nostra esperienza, i nodi 16x64 (16 CPU e 64 GB di RAM) offrono un buon rapporto prezzo/prestazioni. Più di 64 GB di RAM possono influire sulle prestazioni, poiché gli eventi di raccolta dei rifiuti sono a thread singolo e interrompono l'esecuzione di tutti gli altri thread.

Spazio di archiviazione su disco

In genere, 100 GB di spazio su disco sono più che sufficienti per un sistema di produzione.

Considerazioni sul cluster

Looker viene eseguito su una JVM Java e Java può avere difficoltà a gestire una memoria superiore a 64 GB. Come regola generale, se è richiesta una maggiore capacità, devi aggiungere altri nodi 16x64 al cluster anziché aumentare le dimensioni dei nodi oltre 16x64. Potremmo inoltre preferire utilizzare un'architettura in cluster per una maggiore disponibilità.

In un cluster, i nodi Looker devono condividere determinate parti del file system. I dati condivisi includono:

  • Modelli LookML
  • I modelli LookML dello sviluppatore
  • Connettività del server Git

Poiché il file system è condiviso e ospita numerosi repository Git, la gestione degli accessi simultanei e del blocco dei file è fondamentale. Il file system deve essere compatibile con POSIX. È noto che il Network File System (NFS) funziona ed è subito disponibile con Linux. Devi creare un'istanza Linux aggiuntiva e configurare NFS per condividere il disco. NFS predefinito è potenzialmente un single point of failure, quindi valuta la possibilità di eseguire una configurazione di failover o di alta disponibilità.

Anche i metadati di Looker devono essere centralizzati, quindi è necessario eseguire la migrazione del relativo database interno a MySQL. Può essere un servizio MySQL o un deployment MySQL dedicato. La sezione Database interno (backend) in questa pagina fornisce ulteriori dettagli.

Configurazione della JVM

Le impostazioni JVM di Looker sono definite all'interno dello script di avvio di Looker. Dopo eventuali aggiornamenti, Looker deve essere riavviato per mostrare le modifiche. Le configurazioni predefinite sono le seguenti: 

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}

Risorse

Le impostazioni delle risorse sono definite nello script di avvio di Looker. 

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

L'allocazione della memoria per la JVM deve prendere in considerazione l'overhead del sistema operativo su cui viene eseguito Looker. La regola generale è che alla JVM può essere allocato fino al 60% della memoria totale, ma ci sono alcune avvertenze a seconda delle dimensioni della macchina. Per le macchine con un minimo di 8 GB di memoria totale, consigliamo di allocare 4-5 GB a Java e 800 MB a Meta. Per le macchine più grandi, è possibile allocare una proporzione inferiore di memoria per il sistema operativo. Ad esempio, per le macchine con 60 GB di memoria totale, consigliamo di allocare 36 GB a Java e 1 GB a Meta. È importante notare che l'allocazione della memoria di Java dovrebbe in genere essere scalabile in base alla memoria totale della macchina, ma 1 GB dovrebbe essere sufficiente per Meta.

Inoltre, poiché Looker condivide le risorse di sistema con altri processi come Chromium per il rendering, la quantità di memoria allocata a Java deve essere selezionata in base al carico di rendering previsto e alle dimensioni della macchina. Se si prevede che il carico di rendering sia ridotto, a Java può essere allocata una quota maggiore della memoria totale. Ad esempio, su una macchina con 60 GB di memoria totale, Java potrebbe essere allocato in sicurezza a 46 GB, un valore superiore al 60% consigliato in generale. Le allocazioni di risorse esatte appropriate per ogni implementazione variano, quindi utilizza il 60% come linea di base e modificalo in base all'utilizzo.

Garbage collection

Looker preferisce utilizzare il garbage collector più moderno disponibile per la sua versione Java. Per impostazione predefinita, il timeout della raccolta dei rifiuti è di 2 secondi, ma può essere modificato modificando la seguente opzione nella configurazione di avvio: 

-XX:MaxGCPauseMillis=2000

Su una macchina più grande con più core, il timeout della raccolta dei rifiuti potrebbe essere ridotto.

Log

Per impostazione predefinita, i log di garbage collection di Looker vengono archiviati in /tmp/gc.log. Questo può essere cambiato modificando la seguente opzione nella configurazione di avvio: 

-Xloggc:/tmp/gc.log

JMX

La gestione di Looker può richiedere il monitoraggio per perfezionare le risorse. Ti consigliamo di utilizzare JMX per monitorare l'utilizzo della memoria JVM.

Opzioni di avvio di Looker

Le opzioni di avvio sono memorizzate in un file denominato lookerstart.cfg. Questo file è indicato nello script shell che avvia Looker.

Pool di thread

In quanto applicazione multi-thread, Looker ha una serie di pool di thread. Questi pool di thread vanno dal server web principale a servizi secondari specializzati come pianificazione, rendering e connessioni a database esterni. A seconda dei flussi di lavoro aziendali, potrebbe essere necessario modificare questi pool rispetto alla configurazione predefinita. In particolare, ci sono considerazioni speciali per le topologie dei cluster menzionate nella pagina Modelli e pratiche di architettura dell'infrastruttura ospitata dal cliente.

Opzioni di pianificazione ad alta velocità effettiva

Per tutti i nodi non di pianificazione, aggiungi --scheduler-threads=0 alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Senza thread dello scheduler, su questi nodi non verranno eseguiti job pianificati.

Per tutti i nodi dello scheduler dedicati, aggiungi --scheduler-threads=<n> alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Looker inizia con 10 thread dello scheduler per impostazione predefinita, ma puoi aumentarli a <n>. Con <n> thread dello scheduler, ciascun nodo sarà in grado di eseguire <n> di job simultanei di pianificazione. In genere, è consigliabile conservare <n> il doppio del numero di CPU. L'host consigliato più grande è quello con 16 CPU e 64 GB di memoria, quindi il limite superiore dei thread dello scheduler dovrebbe essere inferiore a 32.

Opzioni di velocità effettiva di rendering elevata

Per tutti i nodi di rendering, aggiungi --concurrent-render-jobs=0 alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Senza nodi di rendering, su questi nodi non verranno eseguiti job di rendering.

Per tutti i nodi di rendering dedicati, aggiungi --concurrent-render-jobs=<n> alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Looker inizia con due thread di rendering per impostazione predefinita, ma questo valore può essere aumentato a <n>. Con <n> eseguire il rendering dei thread, ciascun nodo sarà in grado di eseguire <n> per i job di rendering simultanei.

Ogni job di rendering può utilizzare una quantità significativa di memoria. Budget di circa 2 GB per job di rendering. Ad esempio, se al processo principale di Looker (Java) viene allocato il 60% della memoria totale e il 20% della memoria rimanente è riservato al sistema operativo, rimane il 20% per i job di rendering. Su una macchina da 64 GB, rimangono 12 GB, sufficienti per 6 job di rendering simultanei. Se un nodo è dedicato al rendering e non è incluso nel pool del bilanciatore del carico che gestisce i job interattivi, la memoria dei processi principali di Looker può essere ridotta per consentire più job di rendering. Su una macchina da 64 GB, è possibile allocare circa il 30% (20 GB) al processo principale di Looker. Se prevedi di utilizzare il 20% per l'utilizzo generale del sistema operativo, rimane il 50% (32 GB) per il rendering, che è sufficiente per 16 job di rendering simultanei.

Database interno (di backend)

Il server Looker conserva informazioni su configurazione, connessioni del database, utenti, gruppi e ruoli, cartelle, Look e dashboard definiti dall'utente e vari altri dati in un database interno.

Per un'istanza di Looker autonoma di dimensioni moderate, questi dati vengono archiviati in un database HyperSQL in memoria incorporato nel processo Looker stesso. I dati di questo database sono archiviati nel file <looker install directory>/.db/looker.script. Sebbene comodo e leggero, questo database presenta problemi di prestazioni derivanti da un utilizzo intensivo. Pertanto, consigliamo di iniziare con un database MySQL remoto. Se non è possibile, consigliamo di eseguire la migrazione a un database MySQL remoto quando il file ~/looker/.db/looker.script raggiunge i 600 MB. I cluster devono utilizzare un database MySQL.

Il server Looker esegue molte operazioni di lettura e scrittura di piccole dimensioni sul database MySQL. Ogni volta che un utente esegue un Look o un'esplorazione, Looker controlla il database per verificare che l'utente sia ancora connesso, che disponga dei privilegi per accedere ai dati, che disponga dei privilegi per eseguire il Look o l'esplorazione e così via. Looker scriverà anche i dati nel database MySQL, ad esempio il codice SQL effettivo eseguito e l'ora di inizio e di fine della richiesta. Una singola interazione tra un utente e l'applicazione Looker può comportare 15 o 20 letture e scritture di piccole dimensioni sul database MySQL.

MySQL

Il server MySQL deve essere in versione 8.0.x e deve essere configurato per utilizzare la codifica utf8mb4. È necessario utilizzare il motore di archiviazione InnoDB. Le istruzioni per la configurazione di MySQL e le istruzioni per la migrazione dei dati da un database HyperSQL esistente a MySQL sono disponibili nella pagina della documentazione Migrazione del database backend di Looker a MySQL.

Quando configuri Looker per l'utilizzo di MySQL, devi creare un file YAML contenente le informazioni sulla connessione. Assegna al file YAML il nome looker-db.yml e aggiungi l'impostazione -d looker-db.yml nella sezione LOOKERARGS del file lookerstart.cfg.

MariaDB

MySQL è in licenza doppia, disponibile sia come open source sia come prodotto commerciale. Oracle ha continuato a migliorare MySQL, che è stato sottoposto a fork come MariaDB. È noto che le versioni equivalenti di MariaDB di MySQL funzionano con Looker, ma non sono sviluppate o testate dai team di tecnici di Looker. pertanto la funzionalità non è supportata né garantita.

Versioni cloud

Se ospiti Looker nella tua infrastruttura cloud, è logico ospitare il database MySQL nella stessa infrastruttura cloud. I tre principali fornitori di servizi cloud: Amazon AWS, Microsoft Azure e Google Cloud. I provider di servizi cloud gestiscono gran parte della manutenzione e della configurazione per il database MySQL e offrono servizi come la guida per la gestione dei backup e la fornitura di un ripristino rapido. Questi prodotti sono noti per funzionare bene con Looker.

Query sull'attività di sistema

Il database MySQL viene utilizzato per archiviare informazioni su come gli utenti utilizzano Looker. Qualsiasi utente di Looker che dispone dell'autorizzazione per visualizzare il modello Attività di sistema ha accesso a una serie di dashboard di Looker preconfigurate per analizzare questi dati. Gli utenti possono anche accedere alle esplorazioni dei metadati di Looker per creare analisi aggiuntive. Il database MySQL viene utilizzato principalmente per query "operative" piccole, veloci e di piccole dimensioni. Le query "analitiche" grandi, lente e complesse generate dal modello Attività di sistema possono competere con queste query operative e rallentare Looker.

In questi casi, il database MySQL può essere replicato in un altro database. Sia i sistemi autogestiti sia alcuni sistemi gestiti in cloud forniscono la configurazione di base della replica in altri database. La configurazione della replica non rientra nell'ambito di questo documento.

Per utilizzare la replica per le query dell'attività di sistema, creerai una copia del file looker-db.yml, ad esempio denominato looker-usage-db.yml, la modificherai in modo che punti alla replica e aggiungerai l'impostazione --internal-analytics-connection-file looker-usage-db.yml alla sezione LOOKERARGS del file lookerstart.cfg.

Le query sull'attività di sistema possono essere eseguite su un'istanza MySQL o su un database Google BigQuery. Non vengono testati rispetto ad altri database.

Configurazione delle prestazioni di MySQL

Oltre alle impostazioni necessarie per eseguire la migrazione del database backend Looker a MySQL, i cluster molto attivi possono trarre vantaggio da ottimizzazioni e configurazioni aggiuntive. Queste impostazioni possono essere applicate al file /etc/my.cnf o tramite la console Google Cloud per le istanze gestite su cloud.

Il file di configurazione my.cnf è diviso in diverse parti. Le seguenti modifiche alle impostazioni discusse in questa sezione vengono apportate nella parte [mysqld].

Imposta la dimensione del pool di buffer InnoDB

La dimensione del pool di buffer InnoDB è la RAM totale utilizzata per archiviare lo stato dei file di dati InnoDB in memoria. Se il server è dedicato all'esecuzione di MySQL, il valore innodb_buffer_pool_size deve essere impostato tra il 50% e il 70% della memoria di sistema totale.

Se le dimensioni totali del database sono ridotte, è consentito impostare il pool di buffer InnoDB in base alle dimensioni del database anziché al 50% o più della memoria.

In questo esempio, un server ha 64 GB di memoria; pertanto, il pool di buffer InnoDB dovrebbe essere compreso tra 32 GB e 45 GB. Più grande è in genere migliore. 

[mysqld]
...
innodb_buffer_pool_size=45G

Imposta le istanze del pool di buffer InnoDB

Quando più thread tentano di cercare in un pool di buffer di grandi dimensioni, potrebbero competere. Per evitare ciò, il pool di buffer è diviso in unità più piccole a cui possono accedere thread diversi senza conflitti. Per impostazione predefinita, il pool di buffer è diviso in 8 istanze. Ciò crea il potenziale per un collo di bottiglia a 8 thread. L'aumento del numero di istanze del pool di buffer riduce la possibilità di un collo di bottiglia. Il valore innodb_buffer_pool_instances deve essere impostato in modo che ogni pool di buffer riceva almeno 1 GB di memoria. 

[mysqld]
...
innodb_buffer_pool_instances=32

Ottimizza il file di log InnoDB

Quando viene eseguito il commit di una transazione, il database può scegliere di aggiornare i dati del file effettivo oppure di salvare i dettagli della transazione nel log. Se il database si arresta in modo anomalo prima che i file di dati siano stati aggiornati, il file di log può essere "riprodotto". per applicare le modifiche. La scrittura nel file di log è una piccola operazione di accodamento. È efficiente aggiungere al log al momento del commit, quindi raggruppare più modifiche ai file di dati e scriverle in un'unica operazione IO. Quando il file di log viene riempito, il database deve sospendere l'elaborazione delle nuove transazioni e scrivere di nuovo tutti i dati modificati su disco.

Come regola generale, il file di log InnoDB deve essere abbastanza grande da contenere 1 ora di transazioni.

In genere sono presenti due file di log InnoDB. Dovrebbero rappresentare circa il 25% del pool di buffer InnoDB. Per un database di esempio con un pool di buffer di 32 GB, i file di log InnoDB dovrebbero totalizzare 8 GB o 4 GB per file. 

[mysqld]
...
innodb_log_file_size=8GB

Configura la capacità IO di InnoDB

MySQL ridurrà la velocità con cui le scritture vengono registrate sul disco per non sovraccaricare il server. I valori predefiniti sono prudenti per la maggior parte dei server. Per ottenere le migliori prestazioni, utilizza l'utilità sysbench per misurare la velocità di scrittura casuale sul disco dati, quindi utilizza quel valore per configurare la capacità di I/O in modo che MySQL scriva i dati più rapidamente.

Su un sistema ospitato nel cloud, il fornitore di servizi cloud deve essere in grado di segnalare le prestazioni dei dischi utilizzati per l'archiviazione dei dati. Per un server MySQL self-hosted, misura la velocità delle scritture casuali sul disco dati in operazioni di I/O al secondo (IOPS). L'utilità Linux sysbench è un modo per misurarlo. Utilizza questo valore per innodb_io_capacity_max e un valore da metà a tre quarti per innodb_io_capacity. Nell'esempio seguente, quindi, vedremmo i valori misurando 800 IOPS. 

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

Configurare i thread InnoDB

MySQL aprirà almeno un thread per ogni client gestito. Se molti client sono connessi contemporaneamente, può portare all'elaborazione di un numero enorme di thread. Di conseguenza, il sistema potrebbe passare più tempo nello scambio rispetto all'elaborazione.

È necessario eseguire un benchmark per determinare il numero ideale di thread. Per il test, imposta il numero di thread tra il numero di CPU (o core della CPU) sul sistema e quadruplica il numero di CPU. Per un sistema a 16 core, questo valore è probabilmente compreso tra 16 e 64. 

[mysqld]
...
innodb_thread_concurrency=32

Durabilità delle transazioni

Il valore 1 obbliga MySQL a scrivere su disco per ogni transazione. Se il server si arresta in modo anomalo, la transazione non andrà persa, ma le prestazioni del database ne risentiranno. L'impostazione di questo valore su 0 o 2 può migliorare le prestazioni, ma rischia di perdere un paio di secondi. delle transazioni di dati. 

[mysqld]
...
innodb_flush_log_at_trx_commit=1

Imposta il metodo di svuotamento

In genere, il sistema operativo esegue il buffering delle scritture sul disco. Poiché sia MySQL sia il sistema operativo eseguono il buffering, si verifica una penalizzazione delle prestazioni. Ridurre il metodo di svuotamento di un livello di buffering può migliorare le prestazioni. 

[mysqld]
...
innodb_flush_method=O_DIRECT

Attiva un file per tabella

Per impostazione predefinita, MySQL utilizzerà un singolo file di dati per tutti i dati. L'impostazione innodb_file_per_table creerà un file separato per ogni tabella, al fine di migliorare le prestazioni e la gestione dei dati. 

[mysqld]
...
innodb_file_per_table=ON

Disattiva le statistiche sui metadati

Questa impostazione disattiva la raccolta delle statistiche nelle tabelle dei metadati interni, migliorando le prestazioni di lettura. 

[mysqld]
...
innodb_stats_on_metadata=OFF

Disattivare la cache delle query

La cache delle query è deprecata, pertanto se imposti query_cache_size e query_cache_type su 0 la disattivi. 

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

Aumentare il buffer di join

join_buffer viene utilizzato per eseguire i join in memoria. Aumentandolo, è possibile migliorare alcune operazioni. 

[mysqld]
...
join_buffer_size=512KB

Ingrandisci la tabella temporanea e le dimensioni massime dell'heap

tmp_table_size e max_heap_table_size impostano valori predefiniti ragionevoli per le tabelle temporanee in memoria prima che vengano forzate su disco. 

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

Modificare la cache delle tabelle aperte

L'impostazione table_open_cache determina le dimensioni della cache che contiene i descrittori di file per le tabelle aperte. L'impostazione table_open_cache_instances suddivide la cache in un numero di parti più piccole. Esiste una possibilità di contesa dei thread in table_open_cache, quindi suddividerlo in parti più piccole aiuta ad aumentare la contemporaneità. 

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

Servizio Git

Looker è progettato per funzionare con un servizio Git per fornire la gestione delle versioni dei file LookML. Sono supportati i principali servizi di hosting Git, tra cui GitHub, GitLab e Bitbucket. I fornitori di servizi Git offrono un valore aggiunto aggiuntivo, come una GUI per visualizzare le modifiche al codice e il supporto per flussi di lavoro come le richieste di pull e le approvazioni delle modifiche. Se necessario, Git può essere eseguito su un semplice server Linux.

Se un servizio di hosting Git non è appropriato per il tuo deployment a causa di regole di sicurezza, molti di questi fornitori di servizi offrono versioni che possono essere eseguite nel tuo ambiente. GitLab, in particolare, è comunemente ospitato autonomamente e può essere utilizzato come prodotto open source senza costi di licenza o come prodotto con licenza supportato. GitHub Enterprise è disponibile come servizio self-hosted ed è un prodotto commerciale supportato.

Le seguenti sezioni elencano le sfumature per i fornitori di servizi più comuni.

GitHub/GitHub Enterprise

La pagina della documentazione Configurazione e test di una connessione Git utilizza GitHub come esempio.

GitLab/gitlab.com

Per la procedura dettagliata di configurazione di GitLab, consulta il post della scheda Community di Looker Utilizzare GitLab per il controllo della versione in Looker. Se il tuo repository è contenuto in sottogruppi, questi possono essere aggiunti all'URL del repository utilizzando il formato HTTPS o SSH: 

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


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

Inoltre, esistono tre diversi modi per archiviare le chiavi SSH generate da Looker in GitLab: come chiave SSH utente, come chiave di deployment del repository o come chiave di deployment condivisa a livello globale. Una spiegazione più approfondita è disponibile nella documentazione di GitLab.

Sorgente Google Cloud

Per la procedura di configurazione di Git con Cloud Source Repositories, consulta il post della community Utilizzo di Cloud Source Repositories per il controllo della versione in Looker.

Bitbucket Cloud

Per conoscere la procedura di configurazione di Git con Bitbucket Cloud, consulta il post della scheda Community sull'utilizzo di Bitbucket per il controllo della versione in Looker. A partire da agosto 2021, Bitbucket Cloud non supporta i secret negli webhook di deployment.

Bitbucket Server

Per utilizzare le richieste pull con Bitbucket Server, potresti dover completare i seguenti passaggi:

  1. Quando apri una richiesta di pull, Looker utilizza automaticamente il numero di porta predefinito (7999) nell'URL. Se utilizzi un numero di porta personalizzato, dovrai sostituirlo manualmente nell'URL.
  2. Dovrai utilizzare l'webhook di deployment del progetto per sincronizzare il ramo di produzione in Looker con il ramo principale del repository.

Diffusione di Phabricator

Per i passaggi sulla configurazione di Git con Phabricator, consulta il post della scheda Community sulla configurazione di Phabricator e Looker per il controllo della versione.

Rete

Connessioni in entrata

Applicazione web Looker

Per impostazione predefinita, Looker rimane in ascolto delle richieste HTTPS sulla porta 9999. Looker utilizza un certificato autofirmato con un CN di self-signed.looker.com. In alternativa, puoi configurare il server Looker per:

  1. Accetta le connessioni HTTP da un bilanciatore del carico/proxy con terminazione SSL con il --ssl-provided-externally-by=<s>flag di avvio. Il valore deve essere impostato sull'indirizzo IP del proxy o su un nome host che può essere risolto localmente nell'indirizzo IP del proxy. Looker accetterà connessioni HTTP solo da questo indirizzo IP.
  2. Utilizza un certificato SSL fornito dal cliente, con il flag di avvio --ssl-keystore=<s>.

API Looker

L'API Looker rimane in ascolto sulla porta 19999. Se l'installazione richiede l'accesso all'API, il bilanciatore del carico deve avere le regole di inoltro richieste. Si applicano le stesse considerazioni SSL dell'applicazione web principale. Ti consigliamo di utilizzare una porta diversa dall'applicazione web.

Bilanciatori del carico

Un bilanciatore del carico viene spesso utilizzato per accettare una richiesta HTTPS sulla porta 443 utilizzando il certificato del cliente, quindi inoltrarla al nodo del server Looker sulla porta 9999 utilizzando il certificato autofirmato o HTTP. Se i bilanciatori del carico utilizzano il certificato autofirmato di Looker, devono essere configurati per accettarlo.

Connessioni inattive e timeout

Quando un utente avvia una richiesta di grandi dimensioni in Looker, potrebbe generare una query dispendiosa da eseguire sul database. Se l'utente abbandona la richiesta in qualsiasi modo, ad esempio chiudendo il coperchio del laptop, disconnettendosi dalla rete o chiudendo la scheda nel browser, Looker vuole sapere e terminare la query del database.

Per gestire questa situazione, quando l'applicazione web client richiede di eseguire una query sul database, il browser apre una connessione socket utilizzando una richiesta HTTP di lunga durata al server Looker. Questa connessione rimarrà aperta e inattiva. Questa socket verrà disconnessa se l'applicazione web client viene interrotta o disconnessa in qualsiasi modo. Il server vedrà la disconnessione e le eventuali query del database correlate.

I bilanciatori del carico spesso rilevano queste connessioni inattive aperte e le chiudono. Per eseguire Looker in modo efficace, il bilanciatore del carico deve essere configurato in modo da consentire a questa connessione di rimanere aperta per tutta la durata della query più lunga che un utente potrebbe eseguire. È consigliato un timeout di almeno 60 minuti.

Connessioni in uscita

I server di Looker possono avere accesso in uscita senza restrizioni a tutte le risorse, incluso il web pubblico. Ciò semplifica molte attività, come l'installazione di Chromium, che richiede l'accesso ai repository dei pacchetti per la distribuzione Linux.

Di seguito sono riportati i collegamenti in uscita che Looker potrebbe dover effettuare.

Connessione al database interno

Per impostazione predefinita, MySQL è in ascolto per le connessioni sulla porta 3306. I nodi Looker devono essere in grado di avviare connessioni a MySQL su questa porta. A seconda di come è ospitato il repository, potrebbe essere necessario attraversare un firewall.

Servizi esterni

I server di licenza e di telemetria di Looker sono disponibili tramite HTTPS sulla rete internet pubblica. Il traffico da un nodo Looker a ping.looker.com:443 e license.looker.com:443 potrebbe dover essere aggiunto a una lista consentita.

Connessioni del data warehouse

I database ospitati sul cloud potrebbero richiedere una connessione tramite internet pubblico. Ad esempio, se utilizzi BigQuery, accounts.google.com:443 e www.googleapis.com:443 potrebbero dover essere aggiunti a una lista consentita. Se il database si trova all'esterno della tua infrastruttura, consulta l'host del database per conoscere i dettagli della rete.

Servizi SMTP

Per impostazione predefinita, Looker invia la posta in uscita utilizzando SendGrid. Ciò potrebbe richiedere l'aggiunta di smtp.sendgrid.net:587 a una lista consentita. Le impostazioni SMTP possono essere modificate nella configurazione in modo da utilizzare anche un gestore di posta diverso.

Hub azioni, server azioni e webhook

Molte destinazioni del programma, in particolare gli webhook e quelli abilitati nel pannello di amministrazione di Looker, prevedono l'invio di dati tramite richieste HTTPS.

  • Per i webhook, queste destinazioni vengono specificate in fase di runtime dagli utenti e possono essere contrarie all'obiettivo del firewall per le connessioni in uscita.
  • Per un hub azioni, queste richieste vengono inviate a actions.looker.com. I dettagli sono disponibili nella nostra documentazione sulla configurazione di Looker Action Hub.
  • Per gli altri server delle azioni, queste richieste vengono inviate ai domini specificati nella configurazione del server delle azioni dagli amministratori nel riquadro Amministrazione di Looker.

Server proxy

Se non è possibile raggiungere direttamente la rete internet pubblica, Looker può essere configurato in modo da utilizzare un server proxy per le richieste HTTP(S) aggiungendo a lookerstart.cfg una riga simile alla seguente: 

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

Tieni presente che le comunicazioni tra i nodi avvengono tramite HTTPS, quindi se utilizzi un server proxy e la tua istanza è in cluster, in genere è consigliabile aggiungere gli IP/nomi host di tutti i nodi del cluster all'argomento Dhttp.nonProxyHosts.

Comunicazioni tra nodi

Identificatore host interno

All'interno di un cluster, ogni nodo deve essere in grado di comunicare con gli altri nodi. Per consentire ciò, il nome host o l'indirizzo IP di ciascun nodo viene specificato nella configurazione di avvio. All'avvio del nodo, questo valore verrà scritto nel repository MySQL. Gli altri membri del cluster possono quindi fare riferimento a questi valori per comunicare con questo nodo. Per specificare il nome host o l'indirizzo IP nella configurazione di avvio, aggiungi -H node1.looker.example.com alla variabile di ambiente LOOKERARGS in lookerstart.cfg.

Poiché il nome host deve essere univoco per ogni nodo, il file lookerstart.cfg deve essere univoco su ogni istanza. In alternativa all'hardcoded del nome host o dell'indirizzo IP, è possibile utilizzare il comando hostname -I o hostname --fqdn per individuarli in fase di runtime. Per implementarlo, aggiungi -H $(hostname -I) o -H $(hostname --fqdn) alla variabile di ambiente LOOKERARGS in lookerstart.cfg.

Porte interne

Oltre alle porte 9999 e 19999, utilizzate rispettivamente per i server web e API, i nodi del cluster comunicano tra loro tramite un servizio di broker di messaggi, che utilizza le porte 1551 e 61616. Le porte 9999 e 19999 devono essere aperte per il traffico degli utenti finali, mentre le porte 1551 e 61616 devono essere aperte tra i nodi del cluster.