Soluzioni di architettura ospitate dal cliente: procedure dettagliate dei componenti

Questa pagina illustra le best practice per componenti specifici dell'architettura di Looker e descrive come configurarli in un deployment.

Looker ha una serie di dipendenze per l'hosting del server, il servizio di workload sia ad hoc che pianificati, il monitoraggio dello sviluppo iterativo dei modelli e così via. In questa pagina queste dipendenze sono indicate come componenti e ogni componente è trattato in dettaglio nelle sezioni seguenti:

Configurazione dell'host

Sistema operativo e distribuzione

Looker funziona bene sulle versioni più comuni di Linux: RedHat, SUSE e Debian/Ubuntu. In genere, i derivati di queste distribuzioni progettati e ottimizzati per l'esecuzione in un determinato ambiente sono accettabili. 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ù semplice 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 precedenti 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 versioni e le librerie di Looker consigliate, Looker non funzionerà normalmente. Looker richiede Java HotSpot 1.8 aggiornamento 161 o versioni successive o Java OpenJDK 11.0.12 o versioni successive.

CPU e memoria

Nodi 4x16 (4 CPU e 16 GB di RAM) sono sufficienti per un sistema di sviluppo o un'istanza di test di base di Looker 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 garbage collection 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 anche preferire utilizzare un'architettura in cluster per una maggiore disponibilità.

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

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

Poiché il file system è condiviso e ospita una serie di repository Git, la gestione dell'accesso simultaneo e del blocco dei file è fondamentale. Il file system deve essere conforme a 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, pertanto è necessario eseguire la migrazione del database interno a MySQL. Può trattarsi di un servizio MySQL o di 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 nello script di avvio di Looker. Dopo gli aggiornamenti, Looker deve essere riavviato affinché le modifiche vengano applicate. 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 tenere conto del sovraccarico del sistema operativo su cui è in esecuzione Looker. La regola generale è che alla JVM può essere allocato fino al 60% della memoria totale, ma ci sono delle limitazioni 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 in genere dovrebbe 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 garbage collection è 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 garbage collection potrebbe essere ridotto.

Log

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

-Xloggc:/tmp/gc.log

JMX

La gestione di Looker potrebbe 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 della tua attività, potrebbe essere necessario modificare questi pool rispetto alla configurazione predefinita. In particolare, esistono considerazioni speciali per le topologie dei cluster menzionate nella pagina Modelli e pratiche di architettura dell'infrastruttura ospitata dal cliente.

Opzioni di pianificazione ad alto throughput

Per tutti i nodi non schedulatore, aggiungi --scheduler-threads=0 alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Senza thread di pianificazione, su questi nodi non verrà eseguito alcun job pianificato.

Per tutti i nodi di pianificazione dedicati, aggiungi --scheduler-threads=<n> alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Per impostazione predefinita, Looker inizia con 10 thread di pianificazione, ma questo numero può essere aumentato a <n>. Con <n> thread di pianificazione, ogni nodo sarà in grado di eseguire <n> job pianificati in contemporanea. In genere, è consigliabile mantenere <n> inferiore al doppio del numero di CPU. L'host più grande consigliato è quello con 16 CPU e 64 GB di memoria, quindi il limite superiore dei thread di pianificazione deve essere inferiore a 32.

Opzioni per un throughput di rendering elevato

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. Per impostazione predefinita, Looker inizia con due thread di rendering, ma questo numero può essere aumentato a <n>. Con <n> thread di rendering, ogni nodo sarà in grado di eseguire <n> 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 del processo di base di Looker può essere ridotta per consentire un maggior numero di 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 gestisce le informazioni sulla propria configurazione, sulle connessioni al database, sugli utenti, sui gruppi e sui ruoli, sulle cartelle, sui Look e sulle dashboard definiti dall'utente e su 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 di Looker stesso. I dati di questo database sono archiviati nel file <looker install directory>/.db/looker.script. Sebbene pratico e leggero, questo database presenta problemi di prestazioni con un utilizzo elevato. Pertanto, ti consigliamo di iniziare con un database MySQL remoto. Se non è possibile, ti 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 piccole letture e scritture nel database MySQL. Ogni volta che un utente esegue un Look o un'esplorazione, Looker controlla il database per verificare che l'utente abbia ancora eseguito l'accesso, che abbia i privilegi per accedere ai dati, che abbia i 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 potrebbe comportare 15 o 20 piccole letture e scritture nel database MySQL.

MySQL

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

Quando configuri Looker per l'utilizzo di MySQL, devi creare un file YAML contenente le informazioni di 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. Le versioni equivalenti di MariaDB di MySQL sono note per funzionare con Looker, ma non sono sviluppate o testate dai team di ingegneria di Looker. Pertanto, la funzionalità non è supportata o 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 fornitori di servizi cloud gestiscono gran parte della manutenzione e della configurazione del database MySQL e offrono servizi come assistenza per la gestione dei backup e il recupero 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 predefinite 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 e veloci. 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 Attività di sistema, devi creare una copia del file looker-db.yml, ad esempio denominato looker-usage-db.yml, modificarlo in modo che punti alla replica e aggiungere l'impostazione --internal-analytics-connection-file looker-usage-db.yml alla sezione LOOKERARGS del file lookerstart.cfg.

Le query 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 di backend di Looker a MySQL, i cluster molto attivi possono trarre vantaggio da una configurazione e un'ottimizzazione aggiuntive. Queste impostazioni possono essere apportate al file /etc/my.cnf o tramite la console Google Cloud per le istanze gestite dal cloud.

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

Impostare le dimensioni del pool di buffer InnoDB

La dimensione del pool di buffer InnoDB corrisponde alla RAM totale utilizzata per memorizzare lo stato dei file di dati InnoDB in memoria. Se il server è dedicato all'esecuzione di MySQL, innodb_buffer_pool_size deve essere impostato sul 50-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.

Per questo esempio, un server ha 64 GB di memoria; pertanto, il pool di buffer InnoDB deve essere compreso tra 32 GB e 45 GB. In genere, più grande è meglio. 

[mysqld]
...
innodb_buffer_pool_size=45G

Imposta le istanze del pool di buffer InnoDB

Quando più thread tentano di eseguire una ricerca in un pool di buffer di grandi dimensioni, potrebbero entrare in conflitto. 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ò potrebbe creare un collo di bottiglia di 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 una transazione viene confermata, il database ha la possibilità di aggiornare i dati nel file effettivo o 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 di nuovo" 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 di I/O. Quando il file di log è pieno, il database deve mettere in pausa l'elaborazione delle nuove transazioni e riscrivere tutti i dati modificati sul 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 essere 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 di dati, quindi utilizza questo valore per configurare la capacità IO in modo che MySQL scriva i dati più rapidamente.

In un sistema ospitato sul cloud, il fornitore del cloud dovrebbe essere in grado di segnalare il rendimento dei dischi utilizzati per l'archiviazione dei dati. Per un server MySQL autonomo, misura la velocità delle scritture casuali sul disco di dati in operazioni I/O al secondo (IOPS). L'utilità Linux sysbench è un modo per misurarlo. Utilizza questo valore per innodb_io_capacity_max e un valore compreso tra la metà e i tre quarti di questo per innodb_io_capacity. Pertanto, nell'esempio seguente vedremmo i valori se misurassimo 800 IOPS. 

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

Configurare i thread InnoDB

MySQL aprirà almeno un thread per ogni client servito. Se molti client sono connessi contemporaneamente, può essere elaborato un numero enorme di thread. Ciò può causare un maggiore tempo di scambio rispetto all'elaborazione.

È necessario eseguire un benchmark per determinare il numero ideale di thread. Per eseguire il test, imposta il numero di thread tra il numero di CPU (o core della CPU) sul sistema e il quadruplo del 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

Un valore di transazione pari a 1 forza MySQL a scrivere sul 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 comporta il rischio di perdere un paio di secondi di 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 utilizzano 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 crea un file separato per ogni tabella, il che migliora le prestazioni e la gestione dei dati. 

[mysqld]
...
innodb_file_per_table=ON

Disattivare 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 l'impostazione di query_cache_size e query_cache_type su 0 la disattiva. 

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

Aumentare il buffer di join

join_buffer viene utilizzato per eseguire join in memoria. Aumentandolo puoi migliorare determinate operazioni. 

[mysqld]
...
join_buffer_size=512KB

Aumenta le dimensioni della tabella temporanea e dell'heap massimo

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 la possibilità di contesa dei thread in table_open_cache, quindi suddividerlo in parti più piccole contribuisce ad aumentare la concorrenza. 

[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 vantaggi aggiuntivi, come una GUI per visualizzare le modifiche al codice e il supporto di flussi di lavoro come le richieste pull e le approvazioni delle modifiche. Se necessario, Git può essere eseguito su un normale 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 self-hosted e può essere utilizzato come prodotto open source senza costi di licenza o come prodotto con licenza supportata. GitHub Enterprise è disponibile come servizio autonomo ed è un prodotto commerciale supportato.

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

GitHub/GitHub Enterprise

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

GitLab/gitlab.com

Per la procedura di configurazione dettagliata di GitLab, consulta il post della 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.

OrigineGoogle 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

Consulta il post della community Utilizzo di Bitbucket per il controllo della versione in Looker per conoscere la procedura di configurazione di Git con Bitbucket Cloud. 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 pull, Looker utilizza automaticamente il numero di porta predefinito (7999) nell'URL. Se utilizzi un numero di porta personalizzato, dovrai sostituire il numero di porta nell'URL manualmente.
  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 la procedura di configurazione di Git con Phabricator, consulta il post della scheda Community Configurare 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, il server Looker può essere configurato per eseguire le seguenti operazioni:

  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à le 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 distinta da quella dell'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 di cui l'esecuzione sul database potrebbe essere costosa. 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 invia una richiesta per eseguire una query sul database, il browser apre una connessione socket utilizzando una richiesta HTTP long-lived 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 rileverà la disconnessione e annullerà 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. Potrebbe essere necessario aggiungere il traffico da un nodo Looker a ping.looker.com:443 e license.looker.com:443 a una lista consentita.

Connessioni al data warehouse

I database ospitati sul cloud potrebbero richiedere una connessione tramite internet pubblico. Ad esempio, se utilizzi BigQuery, potrebbe essere necessario aggiungere accounts.google.com:443 e www.googleapis.com:443 a una lista consentita. Se il database non fa parte della tua infrastruttura, rivolgiti all'host del database per i dettagli della rete.

Servizi SMTP

Per impostazione predefinita, Looker invia la posta in uscita utilizzando SendGrid. Potrebbe essere necessario aggiungere smtp.sendgrid.net:587 a una lista consentita. Le impostazioni SMTP possono essere modificate nella configurazione per utilizzare anche un altro gestore della posta.

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 gli webhook, queste destinazioni vengono specificate dagli utenti in fase di esecuzione e potrebbero essere contrarie allo scopo del firewalling delle connessioni in uscita.
  • Per un hub di azioni, queste richieste vengono inviate a actions.looker.com. Per maggiori dettagli, consulta la documentazione sulla configurazione di Looker Action Hub.
  • Per altri server di azioni, queste richieste vengono inviate ai domini specificati nella configurazione del server di azioni dagli amministratori nel pannello Amministrazione di Looker.

Server proxy

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

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 questo, il nome host o l'indirizzo IP di ogni nodo è 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 alla codifica fissa del nome host o dell'indirizzo IP, puoi utilizzare il comando hostname -I o hostname --fqdn per trovarli in fase di esecuzione. Per implementare questa operazione, 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 comunicheranno 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.