Clustering Looker

Questo tutorial spiega il metodo consigliato per creare una configurazione di Looker in cluster.

Panoramica

L'applicazione Looker può eseguire un nodo singolo o in cluster:

  • Un'applicazione Looker a nodo singolo, la configurazione predefinita, contiene tutti i servizi che compongono l'applicazione Looker in esecuzione su un singolo server.
  • Una configurazione Looker in cluster è una configurazione più complessa, che di solito richiede server di database, bilanciatori del carico e più server che eseguono l'applicazione Looker. Ogni nodo in un'applicazione Looker in cluster è un server che esegue una singola istanza di Looker.

Esistono due motivi principali per cui un'organizzazione vorrebbe eseguire Looker come cluster:

  • Bilanciamento del carico
  • Disponibilità e failover migliorati

A seconda dei problemi di scalabilità, una soluzione Looker in cluster potrebbe non fornire la soluzione. Ad esempio, se un numero ridotto di grandi query utilizza la memoria di sistema, l'unica soluzione è aumentare la memoria disponibile per il processo di Looker.

Alternative di bilanciamento del carico

Prima di eseguire il bilanciamento del carico di Looker, valuta la possibilità di aumentare la memoria ed eventualmente il conteggio della CPU di un singolo server che esegue Looker. Looker consiglia di configurare il monitoraggio dettagliato delle prestazioni per l'utilizzo della memoria e della CPU in modo che il server Looker abbia le dimensioni adeguate per il suo carico di lavoro.

Le query di grandi dimensioni richiedono più memoria per migliorare le prestazioni. Il clustering può migliorare le prestazioni quando molti utenti eseguono query di piccole dimensioni.

Per le configurazioni con un massimo di 50 utenti che utilizzano Looker leggermente, Looker consiglia di eseguire un singolo server equivalente a un'istanza AWS EC2 di grandi dimensioni (M4.large: 8 GB di RAM, 2 core di CPU). Per le configurazioni con più utenti o molti utenti esperti attivi, verifica se la CPU raggiunge i picchi o se gli utenti notano una lentezza nell'applicazione. In questo caso, sposta Looker su un server più grande o esegui una configurazione Looker in cluster.

Disponibilità/failover migliorati

L'esecuzione di Looker in un ambiente cluster può ridurre il tempo di inattività in caso di interruzione. L'alta disponibilità è particolarmente importante se l'API Looker viene utilizzata nei sistemi aziendali principali o se Looker è incorporato in prodotti rivolti ai clienti.

In una configurazione Looker in cluster, un server proxy o un bilanciatore del carico reindirizza il traffico quando determina che un nodo è inattivo. Looker gestisce automaticamente l'uscita dai nodi e la loro partecipazione al cluster,

Componenti obbligatori

Per una configurazione di Looker in cluster sono necessari i seguenti componenti:

  • Database applicazioni MySQL
  • Nodi Looker (server che eseguono il processo Java di Looker)
  • Bilanciatore del carico
  • File system condiviso
  • Versione appropriata dei file JAR dell'applicazione Looker

Il seguente diagramma illustra l'interazione dei componenti:

Database applicazioni MySQL

Looker utilizza un database dell'applicazione (spesso chiamato un database interno) per contenere i dati dell'applicazione. Quando Looker è eseguito come applicazione a nodo singolo, di solito utilizza un database HyperSQL in memoria.

In una configurazione Looker in cluster, ogni istanza di Looker del nodo deve puntare a un database transazionale condiviso (l'applicazione o il database interno). Il supporto per il database delle applicazioni per Looker in cluster è il seguente:

  • Per le istanze di Looker in cluster è supportato solo MySQL per il database dell'applicazione. Amazon Aurora e MariaDB non sono supportati.
  • Sono supportate le versioni di MySQL 5.7+ e 8.0+.
  • I database in cluster come Galera non sono supportati.

Si consiglia di utilizzare un database di replica di lettura per migliorare le prestazioni e la ridondanza. Il tuo database di replica di lettura non deve necessariamente essere un database MySQL.

Looker non gestisce la manutenzione e i backup di quel database. Tuttavia, poiché il database ospita quasi tutti i dati di configurazione delle applicazioni di Looker, è necessario eseguirne il provisioning come database ad alta disponibilità ed eseguirne il backup almeno una volta al giorno.

Nodi Looker

Ogni nodo è un server con il processo Java di Looker in esecuzione. I server nel cluster Looker devono essere in grado di connettersi fra loro e con il database dell'applicazione di Looker. Le porte predefinite sono elencate in Apri le porte che consentono la comunicazione dei nodi in questa pagina.

Bilanciatore del carico

Per bilanciare il carico o le richieste di reindirizzamento ai nodi disponibili, è necessario un bilanciatore del carico o un server proxy (ad esempio NGINX o AWS ELB) per indirizzare il traffico a ciascun nodo di Looker. Il bilanciatore del carico gestisce i controlli di integrità. In caso di errore del nodo, il bilanciatore del carico deve essere configurato per reindirizzare il traffico ai nodi integri rimanenti.

Quando scegli e configuri il bilanciatore del carico, assicurati che possa essere configurato in modo da funzionare solo come livello 4. L'Amazon EELB è un esempio. Inoltre, il bilanciatore del carico deve avere un timeout lungo (3600 secondi) per evitare l'arresto delle query.

File system condiviso

Devi utilizzare un file system condiviso conforme a POSIX (ad esempio NFS, AWS EFS, Gluster, BeeGFS, Lustre o molti altri). Looker utilizza il file system condiviso come repository per varie informazioni utilizzate da tutti i nodi del cluster.

L'installazione di applicazioni e strumenti da Looker Marketplace richiede l'utilizzo di un file system condiviso (di rete).

Applicazione Looker (eseguibile JAR)

È necessario utilizzare un file JAR dell'applicazione Looker diverso da Looker 3.56 o versioni successive.

A partire da Looker 6.18, il file JAR di Looker è stato suddiviso in due file JAR separati: il file JAR principale di Looker e un file JAR delle dipendenze di Looker. Se installi o esegui l'aggiornamento a Looker 6.18 o versioni successive, assicurati di scaricare entrambi i file JAR.

Looker consiglia vivamente a ciascun nodo in un cluster di eseguire la stessa versione di patch e patch di Looker, come illustrato in Start Looker sui nodi in questa pagina.

Configurazione del cluster

Sono necessarie le seguenti attività:

  1. Installa Looker
  2. Configurare un database di applicazioni MySQL
  3. Configurare il file system condiviso
  4. Condividi il repository delle chiavi SSH (a seconda della tua situazione)
  5. Apri le porte dei nodi per comunicare
  6. Avvia Looker sui nodi

Installare Looker

Assicurati di avere installato Looker su ciascun nodo, utilizzando i file JAR dell'applicazione Looker e le istruzioni riportate nella pagina della documentazione Passaggi di installazione ospitati dal cliente.

Configurazione di un database di applicazioni MySQL

Per una configurazione di Looker in cluster, il database dell'applicazione deve essere un database MySQL. Se hai già un'istanza di Looker non in cluster che utilizza HyperSQL per il database dell'applicazione, devi eseguire la migrazione dei dati dell'applicazione dal database dell'applicazione MySQL condiviso alla fine.

Assicurati di eseguire il backup della directory di Looker. Il processo di migrazione può andare solo da un database HyperSQL a un database MySQL, non inverso.

Per informazioni sul backup di Looker e sulla migrazione del database dell'applicazione da HyperSQL a MySQL, consulta la pagina della documentazione relativa alla migrazione a MySQL.

Configurazione del file system condiviso

Solo determinati tipi di file (file modello, chiavi di deployment, plug-in e potenzialmente file manifest delle applicazioni) appartengono al file system condiviso. Per configurare il file system condiviso:

  1. Sul server che archivierà il file system condiviso, verifica di avere accesso a un altro account che può su per l'account utente di Looker.
  2. Sul server per il file system condiviso, accedi all'account utente di Looker.
  3. Se Looker è attualmente in esecuzione, arresta la tua configurazione di Looker.
  4. Se in precedenza stavi eseguendo il clustering utilizzando gli script i software Linux, arrestali, rimuovili da cron ed eliminali.
  5. Creare una condivisione di rete e montarla su ciascun nodo nel cluster. Assicurati che sia configurato per il montaggio automatico su ciascun nodo e che l'utente di Looker possa leggere e scrivere. Nell'esempio seguente, la condivisione della rete è denominata /mnt/looker-share.

  6. Su un nodo, sposta le chiavi di deployment, i plug-in e le directory looker/models e looker/models-user-*, in cui sono archiviati i file del modello, nella condivisione di rete. Ad esempio:

    mv looker/models /mnt/looker-share/
mv looker/models-user-* /mnt/looker-share/

  7. Per ogni nodo, aggiungi l'impostazione --shared-storage-dir a LOOKERARGS. Specifica la condivisione di rete, come illustrato in questo esempio:

    --shared-storage-dir /mnt/looker-share

    LOOKERARGS deve essere aggiunta a $HOME/looker/lookerstart.cfg in modo che le impostazioni non siano interessate dagli aggiornamenti. Se le LOOKERARGS non sono elencate nel file, è possibile che qualcuno le abbia aggiunte direttamente allo script della shell $HOME/looker/looker.

    Ogni nodo nel cluster deve scrivere in una directory /log univoca o almeno in un file di log univoco.

Condivisione del repository della chiave SSH

  • Stai creando un cluster di file system condiviso da una configurazione Looker esistente e
  • Hai dei progetti creati in Looker 4.6 o versioni precedenti.

La procedura seguente richiede la modifica dell'$HOME/.ssh directory dell'utente di Looker. Questo può rendere difficile l'accesso e risolvere un problema in caso di errori di configurazione. Assicurati di avere accesso a un altro account che possa su all'account utente Looker prima di eseguire questi passaggi.

Configura il repository della chiave SSH da condividere:

  1. Sul file server condiviso, crea una directory denominata ssh-share. Ad esempio: /mnt/looker-share/ssh-share.

    Assicurati che la directory ssh-share sia di proprietà dell'utente di Looker e che le autorizzazioni siano 700. Inoltre, assicurati che le directory sopra la directory ssh-share (come /mnt e /mnt/looker-share) non siano scrivibili a livello mondiale o scrivibile di gruppo.

  2. Su un nodo, copia i contenuti di $HOME/.ssh nella nuova directory ssh-share. Ad esempio:

    cp $HOME/.ssh/* /mnt/looker-share/ssh-share

  3. Per ciascun nodo, esegui il backup del file SSH esistente e crea un collegamento simbolico alla directory ssh-share. Ad esempio:

    cd $HOME
mv .ssh .ssh_bak
ln -s /mnt/looker-share/ssh-share .ssh

    Assicurati di eseguire questo passaggio per ogni nodo.

Apertura delle porte per la comunicazione dei nodi

I nodi Looker in cluster comunicano tra loro tramite HTTPS con certificati autofirmati e uno schema di autenticazione aggiuntivo basato su rotazione dei secret nel database dell'applicazione.

Le porte predefinite che devono essere aperte tra i nodi del cluster sono 1551 e 61616. Queste porte sono configurabili utilizzando i flag di avvio elencati qui. Consigliamo vivamente di limitare l'accesso di rete a queste porte per consentire il traffico solo tra gli host del cluster.

Avvio di Looker sui nodi

Riavvia il server su ciascun nodo con i flag di avvio richiesti.

Ogni nodo in un cluster deve eseguire la stessa versione di patch e release.

Flag di avvio disponibili

La seguente tabella mostra i flag di avvio disponibili, inclusi i flag necessari per avviare o partecipare a un cluster.

Flag Obbligatorio? Valori Finalità
--clustered Sì Aggiungi flag per specificare che questo nodo è in esecuzione in modalità cluster.
-H o --hostname Sì 10.10.10.10 Il nome host utilizzato da altri nodi per contattare questo nodo, ad esempio l'indirizzo IP del nodo o il nome host di sistema. Deve essere diverso dai nomi host di tutti gli altri nodi del cluster.
-n No 1551 La porta per la comunicazione tra nodi. Il valore predefinito è 1551. Tutti i nodi devono utilizzare lo stesso numero di porta per le comunicazioni tra nodi.
-q No 61616 La porta per mettere in coda gli eventi a livello di cluster. Il valore predefinito è 61616.
-d Sì /path/to/looker-db.yml Il percorso del file che contiene le credenziali per il database dell'applicazione Looker.
--shared-storage-dir Sì /path/to/mounted/shared/storage L'opzione dovrebbe puntare alla configurazione della directory condivisa precedente in questa pagina che contiene le directory looker/model e looker/models-user-*.

Il flag di avvio di --clustered non deve includere un valore.

Esempio di LOOKERARGS e specifica delle credenziali del database

Inserisci i flag di avvio di Looker in un file lookerstart.cfg, che si trova nella stessa directory dei file JAR di Looker.

Ad esempio, potresti specificare a Looker:

  • Per utilizzare il file denominato looker-db.yml per le relative credenziali del database,
  • che si tratta di un nodo in cluster,
  • che gli altri nodi del cluster dovrebbero contattare questo host sull'indirizzo IP 10.10.10.10.

Devi specificare:

LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"

Assicurati di specificare l'indirizzo IP corretto per il nodo.

Il file looker-db.yml conterrà le credenziali del database, ad esempio:

host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword

Inoltre, se il tuo database MySQL richiede una connessione SSL, il file looker-db.yml richiede anche quanto segue:

ssl: true

Segui le best practice per la sicurezza quando salvi le credenziali in un file. Idealmente, imposta le autorizzazioni del file looker-db.yml su 600, di proprietà dell'account"user"di Linux, su cui viene eseguita l'applicazione Looker. Questo file non deve mai essere inserito in un repository Git.

Se non vuoi archiviare la configurazione nel file looker-db.yml su disco, puoi configurare la variabile di ambiente LOOKER_DB per contenere un elenco di chiavi/valori per ogni riga nel file looker-db.yml. Ad esempio:

export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"

Ricerca delle chiavi di deployment SSH Git

La posizione in cui Looker archivia le chiavi di deployment SSH di Git dipende dalla release in cui è stato creato il progetto:

  • Per i progetti creati prima di Looker 4.8, le chiavi di deployment sono archiviate nella directory SSH nativa del server, ~/.ssh.
  • Per i progetti creati in Looker 4.8 o versioni successive, le chiavi di deployment vengono archiviate in una directory controllata da Looker, ~/looker/deploy_keys/PROJECT_NAME.

Modifica di un cluster Looker

Dopo aver creato un cluster Looker, puoi aggiungere o rimuovere i nodi senza apportare modifiche agli altri nodi in cluster.

Aggiornamento di un cluster a una nuova release di Looker

Gli aggiornamenti possono includere modifiche allo schema del database interno di Looker che non sarebbe compatibile con le versioni precedenti di Looker. Esistono due metodi per aggiornare Looker.

Metodo più sicuro

  1. Crea un backup del database dell'applicazione.
  2. Arresta tutti i nodi del cluster.
  3. Sostituisci i file JAR su ciascun server.
  4. Avvia ogni nodo uno alla volta.

Metodo più veloce

Questo metodo riduce i tempi di inattività, ma perderà eventuali modifiche apportate tra la creazione della replica e il puntamento del server proxy ai nuovi nodi. Ad esempio, se un utente aggiunge utenti o crea Look durante la transizione, queste modifiche potrebbero non essere acquisite nel nuovo database dell'applicazione.

Per eseguire l'aggiornamento utilizzando questo metodo, ma in modo più rapido ma meno completo:

  1. Crea una replica del database dell'applicazione di Looker.
  2. Avvia un nuovo cluster indirizzato alla replica.
  3. Punta il server proxy o il bilanciatore del carico ai nuovi nodi, dopodiché potrai arrestare i nodi precedenti.