Clustering di Looker

Questo tutorial spiega il metodo consigliato per la creazione di 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, include tutti i servizi che la costituiscono in esecuzione su un singolo server.
• Una configurazione di 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 Looker.

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

• Bilanciamento del carico
• Disponibilità e failover migliorati

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

Alternative di bilanciamento del carico

Prima di bilanciare il carico 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 assicurare che il server Looker sia dimensionato in modo adeguato 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 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 di CPU). Per le configurazioni con più utenti o molti utenti attivi, controlla se la CPU raggiunge un picco o se gli utenti notano un rallentamento dell'applicazione. In questo caso, sposta Looker su un server più grande o esegui una configurazione Looker in cluster.

Disponibilità/failover migliorata

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

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

Componenti obbligatori

Per una configurazione 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 dei componenti. A livello generale, un bilanciatore del carico distribuisce il traffico di rete tra i nodi Looker in cluster. Ciascuno dei nodi comunica 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 dell'applicazione, spesso chiamato database interno, per conservare i dati dell'applicazione. Quando Looker è in esecuzione come applicazione a nodo singolo, normalmente utilizza un database HyperSQL in memoria.

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

• Solo MySQL è supportato per il database dell'applicazione per le istanze Looker in cluster. 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: è consigliato un database con replica di lettura per migliorare le prestazioni e la ridondanza. Il tuo database di replica di lettura non deve essere necessariamente un database MySQL.

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

Nodi Looker

Ciascun nodo è un server su cui è in esecuzione il processo Java di Looker. I server nel cluster Looker devono potersi raggiungere tra loro e con il database dell'applicazione Looker. Le porte predefinite sono elencate nella sezione Apri le porte per 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 Classic ELB ne è un esempio. Inoltre, il bilanciatore del carico dovrebbe avere un timeout lungo (3600 secondi) per evitare che le query vengano eliminate.

File system condiviso

È necessario utilizzare un file system condiviso conforme a POSIX (come 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 (in rete).

Applicazione Looker (eseguibile JAR)

È necessario utilizzare un file JAR dell'applicazione Looker versione 3.56 o successiva.

Nota: a partire da Looker 6.18, il file JAR di Looker è stato suddiviso in due file JAR separati: il file JAR di base e un file JAR di dipendenze 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 a ciascun nodo di un cluster di eseguire la stessa versione di patch e release di Looker, come descritto in Avviare Looker sui nodi in questa pagina.

Configurazione del cluster

Sono necessarie le seguenti attività:

1. Installare Looker
2. Configurare un database dell'applicazione MySQL
3. Configurare il file system condiviso
4. Condividi il repository della chiave SSH (a seconda del tuo caso)
5. Apri le porte per la comunicazione dei 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 indicazioni riportate 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 di Looker non in cluster che utilizza HyperSQL per il database dell'applicazione, devi eseguire la migrazione dei dati dell'applicazione dai dati di HyperSQL al nuovo database dell'applicazione 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 a caso.

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

Configurazione del file system condiviso

Solo file di tipo specifico (file modello, chiavi di deployment, plug-in e potenzialmente file manifest di 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 Looker.
3. Se Looker è attualmente in esecuzione, interrompi la configurazione di Looker.
4. Se in precedenza stavi eseguendo il clustering utilizzando script Linux di notifica, interrompi gli script, rimuovili da cron ed eliminali.
5. Crea una condivisione di rete e montala su ogni nodo nel cluster. Assicurati che sia configurato per il montaggio automatico su ogni nodo e che l'utente di Looker abbia la capacità di leggere e scrivere. 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 del modello, nella condivisione di rete. Ecco alcuni esempi:

   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 il tuo LOOKERARGS non è elencato nel file, qualcuno potrebbe averlo aggiunto direttamente allo script 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 di chiavi SSH

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

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

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 impostate su 700. Inoltre, assicurati che le directory sopra la directory ssh-share (come /mnt e /mnt/looker-share) non siano scrivibili a livello mondiale o di gruppo.

2. Su un nodo, copia il contenuto di $HOME/.ssh nella nuova directory ssh-share. Ecco alcuni esempi:

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

3. Per ogni nodo, esegui il backup del file SSH esistente e crea un collegamento simbolico alla directory ssh-share. Ecco alcuni esempi:

   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 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 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 dei cluster.

Avvio di Looker sui nodi in corso

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

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

Flag di avvio disponibili

La tabella seguente 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 o il 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 l'inserimento in coda 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 dovrebbe indirizzare alla configurazione della directory condivisa 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 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 comunicare a Looker:

• Per utilizzare il file denominato looker-db.yml per le credenziali del database,
• che sia un nodo in cluster e
• 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 contiene le credenziali del database, ad esempio:

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

Se il tuo database MySQL richiede una connessione SSL, il file looker-db.yml richiede inoltre quanto segue:

ssl: true

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

Nota: segui le best practice per la sicurezza al momento di salvare le credenziali su un file. Idealmente, imposta le autorizzazioni del 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 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 in modo che contenga un elenco di chiavi/valori per ogni riga nel file looker-db.yml. Ecco alcuni esempi:

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

Ricerca delle chiavi di deployment SSH di Git

La posizione 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 sono archiviate nella directory SSH nativa del server, ~/.ssh.
• Per i progetti creati in Looker 4.8 o versioni successive, le chiavi di deployment sono 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 cluster.

Aggiornamento di un cluster a una nuova release di Looker

Gli aggiornamenti potrebbero includere 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 ogni nodo uno alla volta.

Metodo più rapido

Nota: questo metodo riduce il tempo di inattività, ma perde 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 dell'applicazione.

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

1. Creare 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 interrompere i vecchi nodi.