Clustering di Looker

Questo tutorial spiega il metodo consigliato per creare una configurazione di Looker in cluster per le istanze in hosting presso il 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, include 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 prevede server di database, bilanciatori del carico e più server che eseguono l'applicazione Looker. Ogni nodo di un'applicazione Looker in cluster è un server su cui è in esecuzione una singola istanza di Looker.

Sono due i motivi principali per i quali un'organizzazione potrebbe voler eseguire Looker come cluster:

• Bilanciamento del carico
• Disponibilità e failover migliorati

A seconda dei problemi di scalabilità, un Looker clusterizzato potrebbe non fornire la soluzione. Ad esempio, se la memoria di sistema è esaurita da un numero ridotto di query di grandi dimensioni, 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 ed eventualmente il conteggio delle CPU di un singolo server che esegue Looker. Looker consiglia di configurare un monitoraggio dettagliato delle prestazioni per l'utilizzo di memoria e CPU per garantire che il server Looker sia dimensionato correttamente per il suo carico di lavoro.

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

Per le configurazioni con un massimo di 50 utenti che utilizzano Looker in modo limitato, 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 configurazioni con più utenti o con molti utenti esperti attivi, controlla se i picchi della CPU o se gli utenti notano un rallentamento nell'applicazione. In questo caso, sposta Looker su un server più grande o esegui una configurazione di Looker in cluster.

Disponibilità migliorata/failover

L'esecuzione di Looker in un ambiente in 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 è integrato nei prodotti rivolti ai clienti.

In una configurazione di Looker in cluster, un server proxy o un bilanciatore del carico reindirizzerà il traffico quando rileva che un nodo non è attivo. Looker gestisce automaticamente i nodi che escono e si uniscono 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 corretta dei file JAR dell'applicazione Looker

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

Database applicazioni MySQL

Looker utilizza un database di applicazioni (spesso chiamato database interno) per contenere i dati dell'applicazione. Quando Looker è in esecuzione come applicazione a nodo singolo, di solito 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 del database di applicazioni per Looker in cluster è il seguente:

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

Nota: si consiglia un database a replica di lettura per migliorare le prestazioni e la ridondanza. Il database della replica di lettura non deve 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, è necessario eseguire il provisioning come database ad alta disponibilità e 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 connettersi tra loro e al database delle applicazioni Looker. Le porte predefinite sono elencate in Apri le porte per la comunicazione tra i 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 in modo da reinstradare 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. L'ELB Amazon Classic è un esempio di questo tipo. Inoltre, il bilanciatore del carico deve avere un timeout lungo (3600 secondi) per evitare l'interruzione delle query.

File system condiviso

Devi utilizzare un file system condiviso compatibile con POSIX (ad esempio NFS, AWS EFS, Gluster, BeeGFS, Lustre o molti altri). Looker utilizza il file system condiviso come repository per vari frammenti di informazioni utilizzati da tutti i nodi del cluster.

Nota: l'installazione di applicazioni e strumenti dal 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 che ogni nodo in un cluster esegua la stessa release e versione della patch di Looker, come descritto in Avviare Looker dai nodi in questa pagina.

Configurazione del cluster

Sono necessarie le seguenti attività:

1. Installa Looker
2. Configura un database di applicazioni MySQL
3. Configurare il file system condiviso
4. Condividi il repository di chiavi SSH (a seconda della situazione)
5. Apri le porte per consentire la comunicazione tra i nodi
6. Avvia Looker sui nodi

Installazione di Looker

Assicurati di aver installato Looker su ogni nodo utilizzando i file JAR dell'applicazione Looker e le istruzioni riportate nella pagina della documentazione Passaggi per l'installazione in hosting presso il 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 disponi di un'istanza 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 di applicazioni MySQL condiviso.

Nota: assicurati di eseguire il backup della directory di Looker. Il processo di migrazione può essere eseguito solo da un database HyperSQL a un database MySQL, non viceversa.

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

Configurazione del file system condiviso

Solo tipi di file specifici (file di modello, 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 in cui verrà archiviato il file system condiviso, verifica di avere accesso a un altro account in grado di su all'account utente Looker.
2. Accedi all'account utente di Looker sul server del file system condiviso.
3. Se Looker è in esecuzione, arresta la configurazione di Looker.
4. Se in precedenza utilizzavi il clustering con script Linux inotify, interrompili, rimuovili da cron ed eliminali.
5. Crea una condivisione di rete e montala su ogni nodo del cluster. Assicurati che sia configurato per il montaggio automatico su ciascun nodo e che l'utente di Looker sia in grado di leggere e scrivere su quest'ultimo. 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 memorizzano i file del modello, 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 i tuoi LOOKERARGS non sono elencati in questo file, qualcuno potrebbe averli aggiunti 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.

Condivisione del repository delle chiavi SSH

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

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

Configura il repository delle chiavi 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 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 pubblicamente o scrivibili 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 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 consentire la comunicazione dei nodi

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

Le porte predefinite che devono essere aperte tra i nodi del cluster sono 1551 e 61616. Queste porte sono configurabili tramite 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.

Avvio di Looker sui nodi

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

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

Flag di avvio disponibili

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

Bandiera	Obbligatorio?	Valori	Finalità
--clustered	Sì		Aggiungi un flag per specificare che questo nodo è in esecuzione in modalità cluster.
-H o --hostname	Sì	10.10.10.10	Il nome host che altri nodi utilizzano per contattare questo nodo, come l'indirizzo IP del nodo o il relativo nome host di sistema. Deve essere diverso dai nomi host di tutti gli altri nodi nel 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 la comunicazione 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 deve puntare alla configurazione della directory condivisa precedente 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 della 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 dire a Looker:

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

Devi specificare:

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

Nota: assicurati di specificare l'indirizzo IP corretto per il tuo 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 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 best practice per la sicurezza quando salvi le credenziali in un file. Idealmente, imposta le autorizzazioni dei file looker-db.yml su 600, di proprietà dell'account "utente" Linux in 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 memorizza 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 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 di Looker, puoi aggiungere o rimuovere nodi senza apportare modifiche agli altri nodi raggruppati.

Aggiornamento di un cluster a una nuova release di Looker

Gli aggiornamenti potrebbero comportare modifiche allo schema del database interno di Looker che non sarebbero compatibili 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 ogni server.
4. Avvia un nodo alla volta.

Metodo più veloce

Nota: questo metodo riduce il tempo di riposo, ma vengono perse tutte le modifiche apportate tra la creazione della replica e l'assegnazione 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 delle applicazioni.

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

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