Clustering di Looker

Questo tutorial spiega il metodo consigliato per creare una configurazione di Looker in cluster per le istanze ospitate dal cliente.

Panoramica

I deployment di Looker ospitati dal cliente possono essere eseguiti su un singolo nodo o in cluster:

• Un'applicazione Looker a nodo singolo, la configurazione predefinita, ha tutti i servizi che compongono l'applicazione Looker in esecuzione su un singolo server.
• Una configurazione di Looker in cluster è una configurazione più complessa, che in genere coinvolge 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 potrebbe voler eseguire Looker come cluster:

• Bilanciamento del carico
• Miglioramento della disponibilità e del failover

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

Alternative al bilanciamento del carico

Prima di bilanciare il carico di Looker, valuta la possibilità di aumentare la memoria e, possibilmente, il numero di CPU di un singolo server che esegue Looker. Looker consiglia di configurare il monitoraggio dettagliato delle prestazioni per l'utilizzo di memoria e CPU per assicurarsi che il server Looker sia dimensionato correttamente per il suo workload.

Le query di grandi dimensioni richiedono più memoria per prestazioni migliori. Il clustering può fornire miglioramenti delle prestazioni quando molti utenti eseguono query di piccole dimensioni.

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

Miglioramento della disponibilità/failover

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

In una configurazione di Looker in cluster, un server proxy o un bilanciatore del carico reindirizza il traffico quando rileva che un nodo è inattivo. Looker gestisce automaticamente i nodi che lasciano e si uniscono al cluster.

Componenti obbligatori

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

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

Il seguente diagramma illustra l'interazione tra i componenti. A livello generale, un bilanciatore del carico distribuisce il traffico di rete tra i nodi Looker in cluster. I nodi comunicano ciascuno con un database dell'applicazione MySQL condiviso, una directory di archiviazione condivisa e i server Git per ogni progetto LookML.

Database dell'applicazione MySQL

Looker utilizza un database dell'applicazione (spesso chiamato database interno) per archiviare i dati dell'applicazione. Quando Looker viene eseguito come applicazione a nodo singolo, in genere utilizza un database HyperSQL in memoria.

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

• Per il database dell'applicazione per le istanze di Looker in cluster è supportato solo MySQL. 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.

Nota: per migliorare le prestazioni e la ridondanza, è consigliabile utilizzare un database di replica di lettura. Il database di replica di lettura non deve necessariamente essere un database MySQL.

Looker non gestisce la manutenzione e i backup di questo database. Tuttavia, poiché il database ospita quasi tutti i dati di configurazione dell'applicazione Looker, deve essere sottoposto a provisioning come database ad alta disponibilità e di cui deve essere eseguito il backup almeno una volta al giorno.

Nodi Looker

Ogni nodo è un server su cui è in esecuzione il processo Java di Looker. I server nel cluster Looker devono essere in grado di raggiungersi a vicenda e raggiungere il database dell'applicazione Looker. Le porte predefinite sono elencate in Aprire le porte per la comunicazione dei nodi in questa pagina.

Bilanciatore del carico

Per bilanciare il carico o reindirizzare le richieste ai nodi disponibili, è necessario un bilanciatore del carico o un server proxy (ad esempio, NGINX o AWS ELB) per indirizzare il traffico a ogni nodo Looker. Il bilanciatore del carico gestisce i controlli di integrità. In caso di errore di un 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 per funzionare solo come livello 4. Amazon Classic ELB è un esempio di questo tipo. Inoltre, il bilanciatore del carico deve avere un timeout lungo (3600 secondi) per evitare che le query vengano interrotte.

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.

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

Applicazione Looker (eseguibile JAR)

Devi utilizzare un file JAR dell'applicazione Looker 3.56 o versioni successive.

Nota: 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 stai installando o eseguendo l'aggiornamento a Looker 6.18 o versioni successive, assicurati di scaricare entrambi i file JAR.

Looker consiglia vivamente di eseguire la stessa versione di rilascio e patch di Looker su ogni nodo di un cluster, come descritto in Avviare Looker sui nodi in questa pagina.

Configurare il cluster

Sono necessarie le seguenti attività:

1. Installare Looker
2. Configurare un database dell'applicazione MySQL
3. Configurare il file system condiviso
4. Condividere il repository delle chiavi SSH (a seconda della situazione)
5. Aprire le porte per la comunicazione dei nodi
6. Avviare Looker sui nodi

Installare Looker

Assicurati di aver installato Looker su ogni nodo utilizzando i file JAR dell'applicazione Looker e le istruzioni nella pagina della documentazione Passaggi di installazione ospitata dal cliente.

Configurare un database dell'applicazione MySQL

Per una configurazione di Looker in cluster, il database dell'applicazione deve essere un database MySQL. Se hai un'istanza di Looker non in cluster esistente che utilizza HyperSQL per il database dell'applicazione, devi eseguire la migrazione dei dati dell'applicazione dai dati HyperSQL al nuovo database dell'applicazione MySQL condiviso.

Nota: assicurati di eseguire il backup della directory Looker. La procedura di migrazione può avvenire solo da un database HyperSQL a un database MySQL, non al contrario.

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

Configurare il file system condiviso

Solo tipi di file specifici, ovvero file di modelli, chiavi di deployment, plug-in e, potenzialmente, file manifest dell'applicazione, appartengono al file system condiviso. Per configurare il file system condiviso:

1. Sul server che ospiterà il file system condiviso, verifica di avere accesso a un altro account che possa eseguire su sull'account utente Looker.
2. Sul server per il file system condiviso, accedi all'account utente Looker.
3. Se Looker è in esecuzione, arresta la configurazione di Looker.
4. Se in precedenza hai utilizzato script Linux inotify per il clustering, arrestali, rimuovili da cron ed eliminali.
5. Crea una condivisione di rete e montala su ogni nodo del cluster. Assicurati che sia configurata per il montaggio automatico su ogni nodo e che l'utente Looker abbia la possibilità di leggerla e scriverla. Nell'esempio seguente, la condivisione di rete è denominata /mnt/looker-share.

6. Su un nodo, copia le chiavi di deployment e sposta i plug-in e le directory looker/models e looker/models-user-*, che archiviano i file dei modelli, nella condivisione di rete. Ad esempio:

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

   Nota: le chiavi di deployment devono essere copiate nello spazio di archiviazione condiviso e in ogni nodo del cluster.

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

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

   LOOKERARGS deve essere aggiunto a $HOME/looker/lookerstart.cfg in modo che le impostazioni non siano interessate dagli aggiornamenti. Se LOOKERARGS non è elencato in questo file, è possibile che qualcuno lo abbia aggiunto direttamente allo script shell $HOME/looker/looker.

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

Condividere il repository delle chiavi SSH

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

Nota: la seguente procedura richiede la modifica della directory $HOME/.ssh dell'utente Looker. Questo può rendere difficile l'accesso e la correzione di eventuali errori nella configurazione. Prima di eseguire questi passaggi, assicurati di avere accesso a un altro account che possa eseguire su sull'account utente Looker.

Configura il repository delle chiavi SSH in modo che sia condiviso:

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

   Assicurati che la directory ssh-share sia di proprietà dell'utente 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 da tutti o dal 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 ogni nodo, esegui il backup del file SSH esistente e crea un link 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.

Aprire le 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 sulla 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. Ti consigliamo vivamente di limitare l'accesso di rete a queste porte per consentire il traffico solo tra gli host del cluster.

Avviare Looker sui nodi

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

Nota: ogni nodo di un cluster deve eseguire la stessa versione di rilascio e patch di Looker.

Flag di avvio disponibili

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

Flag	Obbligatorio?	Valori	Finalità
--clustered	Sì		Aggiungi il flag per specificare che questo nodo è in esecuzione in modalità cluster.
-H o --hostname	Sì	10.10.10.10	Il nome host che gli altri nodi utilizzano per contattare questo nodo, ad esempio l'indirizzo IP del nodo o il nome host del sistema. Deve essere diverso dai nomi host di tutti gli altri nodi del cluster.
-n	No	1551	La porta per la comunicazione tra i nodi. Il valore predefinito è 1551. Tutti i nodi devono utilizzare lo stesso numero di porta per la comunicazione tra i nodi.
-q	No	61616	La porta per la messa in coda degli 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 deve puntare alla directory condivisa configurata in precedenza in questa pagina che contiene le directory looker/model e looker/models-user-*.

Nota: il flag di avvio --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 voler indicare a Looker:

• Di utilizzare il file denominato looker-db.yml per le credenziali del database,
• Che si tratta di un nodo in cluster e
• Che gli altri nodi del cluster devono contattare questo host all'indirizzo IP 10.10.10.10.

Specificheresti:

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

Nota: assicurati di specificare l'indirizzo IP corretto per il nodo.

Il file looker-db.yml conterrebbe 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 database MySQL richiede una connessione SSL, il file looker-db.yml richiede anche quanto segue:

ssl: true

Nota: devi archiviare una copia del file delle credenziali nello spazio di archiviazione condiviso e su ogni nodo del cluster.

Nota: segui le considerazioni di sicurezza delle best practice quando salvi le credenziali in un file. Idealmente, imposta le autorizzazioni del file looker-db.yml su 600, di proprietà dell'account "utente" Linux con cui viene eseguita l'applicazione Looker. Questo file non deve mai essere archiviato 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 in modo che contenga un elenco di chiavi e valori per ogni riga del file looker-db.yml. Ad esempio:

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

Trovare le chiavi di deployment SSH di 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 vengono archiviate nella directory SSH integrata 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.

Modificare un cluster Looker

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

Aggiornare un cluster a una nuova release di Looker

Gli aggiornamenti potrebbero comportare modifiche dello schema al database interno di Looker che non sarebbero compatibili con le versioni precedenti di Looker. Per aggiornare Looker, esistono due metodi.

Metodo più sicuro

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

Metodo più veloce

Nota: questo metodo riduce i tempi di inattività, ma perderà tutte le modifiche apportate tra la creazione della replica e il puntamento del server proxy ai nuovi nodi. Ad esempio, se qualcuno 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 più veloce ma meno completo:

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