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 un nodo, 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 prevede server di database, bilanciatori del carico e più server che eseguono l'applicazione Looker. Ogni nodo di un'applicazione Looker clusterizzata è un server su cui è in esecuzione una singola istanza di Looker.

Esistono due motivi principali per cui 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 un numero ridotto di query di grandi dimensioni sta utilizzando la memoria di sistema, l'unica soluzione è aumentare la memoria disponibile per il processo Looker.

Alternative al bilanciamento del carico

Prima di eseguire il bilanciamento del carico di Looker, valuta la possibilità di aumentare la memoria e, eventualmente, il numero di CPU di un singolo server su cui è in esecuzione 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 in base al 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 ridotto, 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, controlla se si verificano picchi della CPU o se gli utenti notano lentezza nell'applicazione. In questo caso, sposta Looker su un server più grande o esegui una configurazione di Looker in cluster.

Disponibilità/failover migliorati

L'esecuzione di Looker in un ambiente cluster può ridurre i tempi 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 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 dell'applicazione MySQL
• Nodi Looker (server su cui è in esecuzione 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. I nodi comunicano ciascuno con un database di applicazioni MySQL condiviso, una directory di archiviazione condivisa e i server Git per ogni progetto LookML.

Database dell'applicazione MySQL

Looker utilizza un database di applicazioni (spesso chiamato database interno) per memorizzare i dati dell'applicazione. Quando Looker viene eseguito come applicazione a un solo nodo, 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 del database dell'applicazione per Looker clusterizzato è il seguente:

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

Nota: è consigliabile un database con 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 di Looker devono essere in grado di comunicare tra loro e con il database dell'applicazione 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 guasto 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. L'ELB Amazon Classic è un esempio di questo tipo. Inoltre, il bilanciatore del carico deve avere un timeout lungo (3600 secondi) per impedire l'interruzione 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 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 (file JAR eseguibile)

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 distinti: 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 release e patch di Looker su ogni nodo di un cluster, come descritto in Avvia Looker sui nodi in questa pagina.

Configurazione del cluster

Sono necessarie le seguenti attività:

1. Installare Looker
2. Configurare un database di applicazioni MySQL
3. Configurare il file system condiviso
4. Condividi il repository delle chiavi SSH (a seconda della situazione)
5. Apri le porte per 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 hai già un'istanza Looker non clusterizzata 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 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, come 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 memorizza il file system condiviso, verifica di avere accesso a un altro account che può su all'account utente di Looker.
2. Sul server del file system condiviso, accedi all'account utente Looker.
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 ogni nodo e che l'utente di Looker abbia la possibilità di leggerlo e scriverci sopra. 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 progetti creati in Looker 4.6 o versioni precedenti.

Nota: la procedura che segue richiede la modifica della directory $HOME/.ssh dell'utente di Looker. Ciò può rendere difficile accedere e correggere un problema se sono presenti errori nella 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 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 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.

Apertura delle porte per 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 secret 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 utilizzando i flag di avvio elencati qui. Ti consigliamo vivamente di limitare l'accesso alla rete a queste porte per consentire il traffico solo tra gli host del cluster.

Avvio di 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 patch e release di Looker.

Flag di avvio disponibili

La tabella seguente mostra i flag di avvio disponibili, inclusi quelli necessari per avviare o partecipare a 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 utilizzato dagli altri nodi per contattare questo nodo, ad esempio l'indirizzo IP del nodo o il nome host di sistema. Deve essere diverso dagli hostname 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 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 indicata 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, situato nella stessa directory dei file JAR di Looker.

Ad esempio, potresti dire a Looker:

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

Dovresti 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 sottoposto a commit in un repository Git.

Se non vuoi memorizzare 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 versione 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. Interrompi 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 dell'applicazione.

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 che punti alla replica.
3. Indirizza il server proxy o il bilanciatore del carico ai nuovi nodi, dopodiché puoi arrestare i vecchi nodi.