Questa pagina esplora le pratiche comuni 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, la gestione dei workload ad hoc e pianificati, il monitoraggio dello sviluppo iterativo del modello e così via. Queste dipendenze sono denominate componenti in questa pagina e ogni componente è trattato in dettaglio nelle sezioni seguenti:
- Configurazione host
- Configurazione JVM
- Opzioni di avvio di Looker
- Database interno (di backend)
- Servizio Git
- Rete
Configurazione host
Sistema operativo e distribuzione
Looker funziona bene sulle versioni più comuni di Linux: RedHat, SUSE e Debian/Ubuntu. I derivati di queste distribuzioni progettati e ottimizzati per l'esecuzione in un ambiente particolare sono generalmente accettabili. Ad esempio, le distribuzioni Google Cloud o AWS di Linux sono compatibili con Looker. Debian/Ubuntu è la varietà di Linux più utilizzata nella community di Looker e queste sono le versioni più familiari al team di assistenza Looker. È più facile utilizzare Debian/Ubuntu o un sistema operativo per un provider di servizi cloud specifico derivato da Debian/Ubuntu.
Looker viene eseguito nella macchina virtuale Java (JVM). Quando scegli una distribuzione, verifica che le versioni di OpenJDK 11 siano 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 librerie e le versioni di Looker consigliate, Looker non funzionerà normalmente. Looker richiede Java HotSpot 1.8 update 161+ o Java OpenJDK 11.0.12+.
CPU e memoria
I nodi 4x16 (4 CPU e 16 GB di RAM) sono sufficienti per un sistema di sviluppo o un'istanza Looker di test di base utilizzata da un piccolo team. Tuttavia, per l'uso in produzione, questo non è in genere sufficiente. Nella nostra esperienza, 16 nodi x 64 (16 CPU e 64 GB di RAM) rappresentano un buon equilibrio tra prezzo e prestazioni. Più di 64 GB di RAM possono influire sulle prestazioni, poiché gli eventi di Garbage Collection sono single-thread e interrompono tutti gli altri thread per l'esecuzione.
Archiviazione disco
In genere, 100 GB di spazio su disco sono più che sufficienti per un sistema di produzione.
Considerazioni sui 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 è necessaria una maggiore capacità, devi aggiungere altri nodi 16x64 al cluster anziché aumentare le dimensioni dei nodi oltre 16x64. Potremmo anche preferire l'utilizzo di un'architettura in cluster per una maggiore disponibilità.
In un cluster, i nodi Looker devono condividere alcune parti del file system. I dati condivisi includono quanto segue:
- Modelli LookML
- Modelli LookML dello sviluppatore
- Connettività del server Git
Poiché il file system è condiviso e ospita diversi 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 è facilmente 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 configurare un failover o l'alta affidabilità.
Anche i metadati di Looker devono essere centralizzati, quindi il relativo database interno deve essere migrato a MySQL. Può trattarsi di un servizio MySQL o di un deployment MySQL dedicato. La sezione Database interno (backend) di questa pagina fornisce maggiori dettagli.
Configurazione JVM
Le impostazioni JVM di Looker sono definite all'interno dello script di avvio di Looker. Dopo qualsiasi aggiornamento, 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 dell'overhead 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 avvertenze a seconda delle dimensioni della macchina. Per le macchine con un minimo di 8 GB di memoria totale, consigliamo un'allocazione di 4-5 GB per Java e 800 MB per Meta. Per le macchine più grandi, è possibile allocare una percentuale 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 deve essere scalata in base alla memoria totale della macchina, ma Meta dovrebbe essere sufficiente a 1 GB.
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 il carico di rendering è previsto basso, a Java può essere assegnata una quota maggiore della memoria totale. Ad esempio, su una macchina con 60 GB di memoria totale, Java potrebbe essere allocato in modo sicuro a 46 GB, un valore superiore al consiglio generale del 60%. Le allocazioni esatte delle risorse appropriate per ogni deployment variano, quindi utilizza il 60% come base di riferimento e modificalo in base all'utilizzo.
Garbage collection
Looker preferisce utilizzare il garbage collector più moderno disponibile per la sua versione di Java. Per impostazione predefinita, il timeout della 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 sono archiviati in /tmp/gc.log. Puoi modificare questa impostazione modificando la seguente opzione nella configurazione di avvio:
-Xloggc:/tmp/gc.log
JMX
La gestione di Looker potrebbe richiedere un monitoraggio per perfezionare l'assegnazione delle 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 è incluso nello script shell che avvia Looker.
Pool di thread
In quanto applicazione multithread, Looker dispone di diversi pool di thread. Questi pool di thread vanno dal server web principale a servizi secondari specializzati come la pianificazione, il rendering e le connessioni a database esterni. A seconda dei flussi di lavoro della tua attività, questi pool potrebbero dover essere modificati 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 throughput di pianificazione elevato
Per tutti i nodi non scheduler, aggiungi --scheduler-threads=0 alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Senza thread dello scheduler, nessun job pianificato verrà eseguito su questi nodi.
Per tutti i nodi dello scheduler dedicati, aggiungi --scheduler-threads=<n> alla variabile di ambiente LOOKERARGS in lookerstart.cfg. Per impostazione predefinita, Looker inizia con 10 thread dello scheduler, ma questo valore può essere aumentato fino a <n>. Con <n> thread dello scheduler, ogni nodo sarà in grado di eseguire <n> job di pianificazione simultanei. In genere, è consigliabile mantenere <n> inferiore al doppio del numero di CPU. L'host più grande consigliato ha 16 CPU e 64 GB di memoria, quindi il limite superiore dei thread dello scheduler deve essere inferiore a 32.
Opzioni di 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, nessun job di rendering verrà eseguito su questi nodi.
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 valore può essere aumentato fino 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. Prevedi circa 2 GB per ogni 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 principale 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 core di Looker. Se riservi 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 informazioni sulla propria configurazione, sulle connessioni ai database, su 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 per questo database sono archiviati nel file <looker install directory>/.db/looker.script. Sebbene sia comodo e leggero, questo database presenta problemi di prestazioni in caso di utilizzo intenso. Pertanto, ti consigliamo di iniziare con un database MySQL remoto. Se non è fattibile, ti consigliamo di eseguire la migrazione a un database MySQL remoto una volta che 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 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 l'SQL effettivo eseguito e l'ora di inizio e 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 la versione 8.0.x e deve essere configurato per utilizzare la codifica utf8mb4. Deve essere utilizzato il motore di archiviazione InnoDB. Le istruzioni di configurazione per MySQL, nonché le istruzioni per la migrazione dei dati da un database HyperSQL esistente a MySQL, sono disponibili nella pagina di documentazione Migrazione del database di backend di Looker a MySQL.
Quando configuri Looker per utilizzare 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 è con doppia licenza, disponibile sia come open source sia come prodotto commerciale. Oracle ha continuato a migliorare MySQL, che è stato creato come fork di MariaDB. È noto che le versioni equivalenti di MySQL di MariaDB funzionano 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 cloud provider gestiscono gran parte della manutenzione e della configurazione del database MySQL e offrono servizi come la gestione dei backup e il ripristino rapido. È noto che questi prodotti funzionano 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 disponga dell'autorizzazione per visualizzare il modello Attività del 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 piccole, veloci e "operative". Le query "analitiche" grandi e lente 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 che alcuni sistemi gestiti nel cloud forniscono la configurazione di base della replica ad altri database. La configurazione della replica non rientra nell'ambito di questo documento.
Per utilizzare la replica per le query Attività di sistema, crea una copia del file looker-db.yml, ad esempio denominata looker-usage-db.yml, modificala in modo che punti alla replica e aggiungi 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 di backend di Looker a MySQL, i cluster molto attivi possono trarre vantaggio da un'ulteriore ottimizzazione e configurazione. 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 è suddiviso in più parti. Le seguenti modifiche alle impostazioni descritte in questa sezione vengono apportate nella parte [mysqld].
Imposta le dimensioni 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, innodb_buffer_pool_size deve essere impostato sul 50-70% della memoria di sistema totale.
Se la dimensione totale del database è ridotta, è consentito impostare il pool di buffer InnoDB sulla dimensione del database anziché sul 50% o più della memoria.
Per questo esempio, un server ha 64 GB di memoria, quindi il buffer pool 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 cercare in un buffer pool di grandi dimensioni, potrebbero entrare in conflitto. Per evitare questo problema, il buffer pool è suddiviso in unità più piccole a cui possono accedere thread diversi senza conflitti. Per impostazione predefinita, il buffer pool è suddiviso in 8 istanze. Ciò crea il potenziale per un collo di bottiglia a 8 thread. L'aumento del numero di istanze del buffer pool riduce la possibilità di un collo di bottiglia. innodb_buffer_pool_instances deve essere impostato in modo che ogni buffer pool riceva almeno 1 GB di memoria.
[mysqld] ... innodb_buffer_pool_instances=32
Ottimizzare il file di log InnoDB
Quando una transazione viene eseguita, il database ha la possibilità di aggiornare i dati nel file effettivo oppure può salvare i dettagli della transazione nel log. Se il database si arresta in modo anomalo prima dell'aggiornamento dei file di dati, 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 una singola operazione di I/O. Quando il file di log è pieno, il database deve sospendere l'elaborazione di nuove transazioni e scrivere 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 esistono due file di log InnoDB. Devono corrispondere a 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 devono avere una dimensione totale di 8 GB, ovvero 4 GB per file.
[mysqld] ... innodb_log_file_size=8GB
Configura la capacità IO InnoDB
MySQL limiterà la velocità con cui le scritture vengono registrate sul disco per non sovraccaricare il server. I valori predefiniti sono conservativi per la maggior parte dei server. Per ottenere prestazioni ottimali, utilizza l'utilità sysbench per misurare la velocità di scrittura casuale sul disco dati, quindi utilizza questo valore per configurare la capacità di I/O in modo che MySQL scriva i dati più rapidamente.
In un sistema ospitato sul cloud, il fornitore di servizi cloud dovrebbe essere in grado di segnalare le prestazioni dei dischi utilizzati per l'archiviazione dei dati. Per un server MySQL autogestito, misura la velocità delle scritture casuali sul disco di 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 compreso tra la metà e i tre quarti per innodb_io_capacity. Quindi, nel seguente esempio, vedremmo i valori se misurassimo 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configura i thread InnoDB
MySQL aprirà almeno un thread per ogni client servito. Se molti client sono connessi contemporaneamente, è possibile che venga elaborato un numero elevato di thread. Ciò può causare un aumento del tempo dedicato allo swapping rispetto all'elaborazione.
Il benchmarking deve essere eseguito 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 4 volte 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
Un valore di transazione pari a 1 impone a MySQL di 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 a rischio di perdere transazioni di dati di un paio di secondi.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Impostare il metodo di scarico
Il sistema operativo esegue normalmente il buffering delle scritture sul disco. Poiché sia MySQL che il sistema operativo eseguono il buffering, le prestazioni ne risentono. Ridurre il metodo di scaricamento di un livello di buffering può migliorare le prestazioni.
[mysqld] ... innodb_flush_method=O_DIRECT
Attiva un file per tabella
Per impostazione predefinita, MySQL utilizza 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 di statistiche sulle tabelle di metadati interni, migliorando le prestazioni di lettura.
[mysqld] ... innodb_stats_on_metadata=OFF
Disattivare la cache delle query
La cache delle query è deprecata, quindi l'impostazione di query_cache_size e query_cache_type su 0 la disattiva.
[mysqld] ... query_cache_size=0 query_cache_type=0
Ingrandire il buffer di join
join_buffer viene utilizzato per eseguire join in memoria. Aumentarlo può migliorare alcune 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 la dimensione 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 la suddivisione 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 ulteriori valori aggiunti, come una GUI per visualizzare le modifiche al codice e il supporto per flussi di lavoro come richieste di pull e approvazioni delle modifiche. Se necessario, Git può essere eseguito su un server Linux semplice.
Se un servizio di hosting Git non è appropriato per la tua implementazione a causa delle regole di sicurezza, molti di questi fornitori di servizi offrono versioni che possono essere eseguite nel tuo ambiente. In particolare, GitLab è 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 self-hosted ed è un prodotto commerciale supportato.
Le sezioni seguenti elencano le sfumature 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 i passaggi di configurazione dettagliati per GitLab, consulta il post della community di Looker Utilizzo di GitLab per il controllo delle versioni in Looker. Se il 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 modi diversi 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 globale. Una spiegazione più approfondita è disponibile nella documentazione di GitLab.
Google Cloud Origine
Consulta il post della community Utilizzo di Cloud Source Repositories per il controllo della versione in Looker per i passaggi per configurare Git con Cloud Source Repositories.
Bitbucket Cloud
Consulta il post della community Utilizzo di Bitbucket per il controllo della versione in Looker per i passaggi per configurare 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:
- 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 sostituire manualmente il numero di porta nell'URL.
- Dovrai attivare il webhook di deployment del progetto per sincronizzare il ramo di produzione in Looker con il ramo principale del repository.
Diffusione di Phabricator
Consulta il post della community Configurazione di Phabricator e Looker per il controllo della versione per i passaggi per configurare Git con Phabricator.
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 nome comune di self-signed.looker.com. In alternativa, il server Looker può essere configurato per eseguire le seguenti operazioni:
- 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. - 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 forwarding necessarie. Valgono le stesse considerazioni SSL dell'applicazione web principale. Ti consigliamo di utilizzare una porta diversa 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 inoltra la richiesta 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 la cui 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 saperlo e terminare la query del database.
Per gestire questa situazione, quando l'applicazione web client effettua una richiesta per eseguire una query del database, il browser apre una connessione socket utilizzando una richiesta HTTP di lunga durata al server Looker. Questa connessione rimarrà aperta e inattiva. Questo socket verrà disconnesso se l'applicazione web client viene chiusa o disconnessa in qualsiasi modo. Il server vedrà la disconnessione e annullerà tutte le query di database correlate.
I bilanciatori del carico spesso rilevano queste connessioni inattive aperte e le interrompono. Per eseguire Looker in modo efficace, il bilanciamento 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. È consigliabile un timeout di almeno 60 minuti.
Connessioni in uscita
I server Looker possono avere accesso in uscita illimitato a tutte le risorse, inclusa la rete internet pubblica. Ciò semplifica molte attività, come l'installazione di Chromium, che richiede l'accesso ai repository di pacchetti per la distribuzione Linux.
Di seguito sono riportate le connessioni in uscita che Looker potrebbe dover effettuare.
Connessione al database interno
Per impostazione predefinita, MySQL è in ascolto delle 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 telemetria e licenze di Looker sono disponibili tramite HTTPS su internet pubblico. 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 ai 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 si trova al di fuori della tua infrastruttura, consulta l'host del database per i dettagli di 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 gestore di posta diverso.
Hub azioni, server di azioni e webhook
Molte destinazioni dello scheduler, in particolare i webhook e quelle abilitate 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 potrebbero essere contrarie all'obiettivo di firewalling delle connessioni in uscita.
- Per un hub delle azioni, queste richieste vengono inviate a
actions.looker.com. Per maggiori dettagli, consulta la nostra documentazione sulla configurazione di Looker Action Hub. - Per gli altri action server, queste richieste vengono inviate ai domini specificati nella configurazione dell'action server dagli amministratori nel pannello Amministrazione di Looker.
Server proxy
Se non è possibile raggiungere direttamente internet pubblico, 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 devi aggiungere gli IP/i 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 consentirlo, il nome host o l'indirizzo IP di ogni 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 alla codifica hardcoded del nome host o dell'indirizzo IP, è possibile utilizzare il comando hostname -I o hostname --fqdn per trovarli in fase di runtime. 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 comunicano tra loro tramite un servizio di message broker, che utilizza le porte 1551 e 61616. Le porte 9999 e 19999 devono essere aperte al traffico degli utenti finali, mentre le porte 1551 e 61616 devono essere aperte tra i nodi del cluster.