Clustering di Looker

Questo tutorial illustra 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 in cluster o a nodo singolo:

• 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 di solito 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 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 in cluster 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 di 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ò fornire miglioramenti delle prestazioni quando molti utenti eseguono query di piccole dimensioni.

Per configurazioni con un massimo di 50 utenti che utilizzano Looker con leggerezza, 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 attivi 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 è incorporato in prodotti rivolti ai clienti.

In una configurazione di Looker in cluster, un server proxy o un bilanciatore del carico reindirizzeranno il traffico quando determina che un nodo non è disponibile. Looker gestisce automaticamente i nodi che escono dal cluster e che 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 livello generale, un bilanciatore del carico distribuisce il traffico di rete tra i nodi Looker 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 conservare 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 in cluster 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 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 dell'applicazione Looker, è necessario eseguirne il provisioning come database ad alta disponibilità e il relativo 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 Aprire le porte per la comunicazione dei nodi in questa pagina.

Bilanciatore del carico

Per bilanciare le richieste di carico o 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 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'Amazon Classic ELB ne è un esempio. 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 varie informazioni utilizzate da tutti i nodi nel 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 che sia 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 di base 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 ciascun nodo, utilizzando i file JAR dell'applicazione Looker e le istruzioni nella pagina della documentazione Procedura di installazione ospitata 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 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ò passare solo da un database HyperSQL a un database MySQL, non invertire.

Consulta la pagina della documentazione 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 stavi eseguendo il clustering utilizzando script Linux di notifica, arresta questi script, rimuovili da cron ed eliminali.
5. Crea una condivisione di rete e montala su ciascun 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-*, in cui sono archiviati i file del tuo 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 su 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 nel file, è possibile che qualcuno li abbia 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 di chiavi 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.

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 in grado di su all'account utente Looker.

Configura il repository di 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 ciascun nodo, esegui un 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.

Aprire le porte per consentire 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 secret a 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. 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 in un cluster deve eseguire la stessa release e versione della patch di Looker.

Flag di avvio disponibili

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

Flag	Obbligatorio?	Valori	Finalità
--clustered	Sì		Aggiungi un flag per specificare che questo nodo è in esecuzione in modalità in 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 le comunicazioni 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 l'accodamento di 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 indirizzare alla configurazione della directory condivisa precedente in questa pagina che contiene le directory looker/model e looker/models-user-*.

Nota: il flag di avvio di --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 debbano contattare 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 tuo file delle credenziali nello spazio di archiviazione condiviso e su ogni nodo del cluster.

Nota: segui le considerazioni sulla sicurezza delle best practice quando salvi le credenziali in un file. Idealmente, imposta le autorizzazioni dei 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"

Individuazione delle chiavi di deployment SSH Git

Il punto in cui Looker archivia le chiavi di deployment SSH 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.

Modifica di un cluster Looker

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

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 ciascun server.
4. Avvia ogni nodo uno alla volta.

Metodo più veloce

Nota: questo metodo riduce i tempi di inattività, ma perderà le 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 delle applicazioni.

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

1. Crea una replica del database delle applicazioni 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.