Clustering Looker

Ce tutoriel explique la méthode recommandée pour créer une configuration Looker en cluster.

Présentation

L'application Looker peut s'exécuter en nœud unique ou en cluster:

  • La configuration par défaut d'une application Looker à nœud unique comporte tous les services qui la composent.
  • Une configuration Looker en cluster est une configuration plus complexe, impliquant généralement des serveurs de base de données, des équilibreurs de charge et plusieurs serveurs exécutant l'application Looker. Dans une application Looker en cluster, chaque nœud correspond à un serveur exécutant une seule instance Looker.

Une organisation peut souhaiter exécuter Looker en tant que cluster pour deux raisons principales:

  • Équilibrage de charge
  • Amélioration de la disponibilité et du basculement

Selon les problèmes de scaling, un Looker en cluster peut ne pas fournir la solution. Par exemple, si un petit nombre de requêtes volumineuses utilisent la mémoire système, la seule solution consiste à augmenter la mémoire disponible pour le processus Looker.

Autres solutions d'équilibrage de charge

Avant d'équilibrer la charge de Looker, envisagez d'augmenter la mémoire et, éventuellement, le nombre de processeurs d'un seul serveur exécutant Looker. Looker recommande de configurer une surveillance détaillée des performances pour l'utilisation de la mémoire et du processeur afin de s'assurer que le serveur Looker est correctement dimensionné pour sa charge de travail.

Les requêtes volumineuses nécessitent davantage de mémoire pour de meilleures performances. Le clustering peut offrir des gains de performances lorsque de nombreux utilisateurs exécutent de petites requêtes.

Pour les configurations comptant jusqu'à 50 utilisateurs qui utilisent Looker légèrement, Looker recommande d'exécuter un seul serveur à l'équivalent d'une instance AWS EC2 de grande taille (M4.large: 8 Go de RAM, 2 cœurs de processeur). Pour les configurations comptant un plus grand nombre d'utilisateurs actifs ou un grand nombre d'utilisateurs actifs, vérifiez si le processeur connaît un pic ou si l'application est lente. Si tel est le cas, déplacez Looker sur un serveur plus grand ou exécutez une configuration Looker en cluster.

Amélioration de la disponibilité/basculement

L'exécution de Looker dans un environnement en cluster peut limiter les temps d'arrêt en cas de panne. La haute disponibilité est particulièrement importante si l'API Looker est utilisée dans les systèmes d'entreprise principaux ou si Looker est intégré dans des produits destinés aux clients.

Dans une configuration Looker en cluster, un serveur proxy ou un équilibreur de charge redirige le trafic lorsqu'il détermine qu'un nœud est en panne. Looker gère automatiquement les nœuds quittant et joignant le cluster.

Composants requis

Les composants suivants sont requis pour une configuration Looker en cluster:

  • Base de données de l'application MySQL
  • Nœuds Looker (serveurs exécutant le processus Java Looker)
  • Équilibreur de charge
  • Système de fichiers partagé
  • Version appropriée des fichiers JAR de l'application Looker

Le schéma suivant illustre l'interaction des composants:

Base de données de l'application MySQL

Looker utilise une base de données d'application (souvent appelée base de données interne) pour stocker les données d'application. Lorsque Looker est exécuté en tant qu'application à nœud unique, il utilise normalement une base de données HyperSQL en mémoire.

Dans une configuration Looker en cluster, chaque instance Looker doit pointer vers une base de données transactionnelle partagée (l'application partagée ou la base de données interne). La compatibilité de la base de données de l'application pour les Looker en cluster est la suivante:

  • Seul MySQL est compatible avec la base de données de l'application pour les instances Looker en cluster. Amazon Aurora et MariaDB ne sont pas compatibles.
  • Les versions 5.7 et ultérieures de MySQL sont compatibles.
  • Les bases de données en cluster telles que Galera ne sont pas compatibles.

Une base de données dupliquée avec accès en lecture est recommandée pour améliorer les performances et la redondance. Votre base de données dupliquée avec accès en lecture ne doit pas nécessairement être une base de données MySQL.

Looker ne gère pas la maintenance ni les sauvegardes de cette base de données. Toutefois, comme la base de données héberge presque toutes les données de configuration de l'application Looker, elle doit être provisionnée en tant que base de données à haute disponibilité et sauvegardée au moins une fois par jour.

Nœuds Looker

Chaque nœud est un serveur sur lequel le processus Java Looker s'exécute. Les serveurs du cluster Looker doivent pouvoir communiquer entre eux et avec la base de données de l'application Looker. Les ports par défaut sont listés sur la page Ouvrir les ports de communication des nœuds de cette page.

Équilibreur de charge

Pour équilibrer la charge ou les requêtes de redirection vers les nœuds disponibles, un équilibreur de charge ou un serveur proxy (par exemple, NGINX ou ELB AWS) est nécessaire pour diriger le trafic vers chaque nœud Looker. L'équilibreur de charge gère les vérifications d'état. En cas de défaillance d'un nœud, l'équilibreur de charge doit être configuré pour rediriger le trafic vers les nœuds opérationnels restants.

Lorsque vous choisissez et configurez l'équilibreur de charge, assurez-vous qu'il peut être configuré pour fonctionner uniquement en tant que couche 4. C'est le cas d'Amazon Classic ELB. De plus, l'équilibreur de charge doit avoir un long délai d'inactivité (3 600 secondes) pour éviter la suppression des requêtes.

Système de fichiers partagé

Vous devez utiliser un système de fichiers partagé compatible avec POSIX (par exemple, NFS, AWS EFS, Gluster, BeeGFS, Lustre, etc.). Looker utilise le système de fichiers partagé comme dépôt pour diverses informations utilisées par tous les nœuds du cluster.

Pour installer des applications et des outils à partir de Looker Marketplace, vous devez utiliser un système de fichiers partagé (réseau).

Application Looker (exécutable JAR)

Vous devez utiliser un fichier JAR d'application Looker version 3.56 ou ultérieure.

À partir de la version 6.18 de Looker, le fichier JAR Looker a été divisé en deux fichiers JAR distincts: le fichier JAR principal Looker et le fichier JAR des dépendances Looker. Si vous installez ou mettez à jour Looker 6.18 ou une version ultérieure, veillez à télécharger les deux fichiers JAR.

Looker recommande vivement que chaque nœud d'un cluster exécute la même version de Looker et la même version de correctif, comme indiqué dans la section Démarrer Looker sur les nœuds de cette page.

Configurer le cluster

Les tâches suivantes sont requises:

  1. Installer Looker
  2. Configurer une base de données d'application MySQL
  3. Configurer le système de fichiers partagé
  4. Partagez le dépôt de clés SSH (en fonction de votre situation)
  5. Ouvrir les ports permettant aux nœuds de communiquer
  6. Démarrer Looker sur les nœuds

Installer Looker

Assurez-vous d'avoir installé Looker sur chaque nœud à l'aide des fichiers JAR de l'application Looker et des instructions de la page de procédure d'installation hébergée par le client.

Configurer une base de données d'application MySQL

Pour une configuration Looker en cluster, la base de données de l'application doit être une base de données MySQL. Si vous disposez d'une instance Looker non mise en cluster qui utilise HyperSQL pour la base de données d'application, vous devez migrer les données d'application des données HyperSQL vers votre nouvelle base de données d'application MySQL partagée.

Veillez à sauvegarder votre répertoire Looker. Le processus de migration ne peut aller que d'une base de données HyperSQL vers une base de données MySQL, et non l'inverse.

Consultez la page de documentation Migrating to MySQL pour en savoir plus sur la sauvegarde de Looker, puis la migration de la base de données d'application de HyperSQL vers MySQL.

Configurer le système de fichiers partagé

Seuls les types de fichiers spécifiques (fichiers de modèle, clés de déploiement, plug-ins et fichiers manifestes d'application potentiels) appartiennent au système de fichiers partagé. Pour configurer le système de fichiers partagé:

  1. Sur le serveur qui stockera le système de fichiers partagé, vérifiez que vous avez accès à un autre compte qui peut su au compte utilisateur Looker.
  2. Sur le serveur du système de fichiers partagé, connectez-vous au compte utilisateur Looker.
  3. Si Looker est en cours d'exécution, arrêtez votre configuration Looker.
  4. Si vous effectuiez auparavant le clustering à l'aide de scripts Linux inotify, arrêtez ces scripts, supprimez-les de Cron, puis supprimez-les.
  5. Créer un partage réseau et l'installer sur chaque nœud du cluster Assurez-vous qu'il est configuré pour être installé automatiquement sur chaque nœud, et que l'utilisateur Looker peut lire et écrire dans celui-ci. Dans l'exemple suivant, le partage de réseau est nommé /mnt/looker-share.

  6. Sur un nœud, déplacez vos clés de déploiement, vos plug-ins et les répertoires looker/models et looker/models-user-*, qui stockent vos fichiers de modèle, vers votre partage réseau. Exemple :

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

  7. Pour chaque nœud, ajoutez le paramètre --shared-storage-dir à LOOKERARGS. Spécifiez le partage réseau, comme indiqué dans cet exemple:

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

    LOOKERARGS doit être ajouté à $HOME/looker/lookerstart.cfg pour que les paramètres ne soient pas affectés par les mises à jour. Si votre LOOKERARGS ne figure pas dans ce fichier, quelqu'un l'a peut-être ajouté directement au script shell $HOME/looker/looker.

    Chaque nœud du cluster doit écrire dans un répertoire /log unique ou au moins dans un fichier journal unique.

Partager le dépôt de clés SSH

  • Vous créez un cluster de système de fichiers partagé à partir d'une configuration Looker existante.
  • Certains de vos projets ont été créés dans Looker 4.6 ou une version antérieure.

La procédure suivante nécessite de modifier le $HOME/.ssh directory de l'utilisateur Looker. Cela peut rendre la connexion difficile et corriger quelque chose si la configuration comporte des erreurs. Avant d'effectuer ces étapes, assurez-vous d'avoir accès à un autre compte qui peut su au compte utilisateur Looker.

Configurez le dépôt de clés SSH à partager:

  1. Sur le serveur de fichiers partagé, créez un répertoire nommé ssh-share. Exemple : /mnt/looker-share/ssh-share.

    Assurez-vous que le répertoire ssh-share appartient à l'utilisateur Looker et que les autorisations sont 700. Assurez-vous également que les répertoires situés au-dessus du répertoire ssh-share (comme /mnt et /mnt/looker-share) ne sont pas accessibles en écriture ni en écriture de groupe.

  2. Sur un nœud, copiez le contenu de $HOME/.ssh dans le nouveau répertoire ssh-share. Exemple :

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

  3. Pour chaque nœud, effectuez une sauvegarde du fichier SSH existant et créez un lien symbolique vers le répertoire ssh-share. Exemple :

    cd $HOME
mv .ssh .ssh_bak
ln -s /mnt/looker-share/ssh-share .ssh

    Veillez à effectuer cette étape pour chaque nœud.

Ouvrir les ports permettant aux nœuds de communiquer

Les nœuds Looker en cluster communiquent entre eux via HTTPS avec des certificats autosignés et un schéma d'authentification supplémentaire basé sur la rotation de secrets dans la base de données de l'application.

Les ports par défaut à ouvrir entre les nœuds de cluster sont 1551 et 61616. Vous pouvez configurer ces ports à l'aide des options de démarrage listées ici. Nous vous recommandons vivement de restreindre l'accès réseau à ces ports afin de n'autoriser le trafic qu'entre les hôtes du cluster.

Démarrer Looker sur les nœuds

Redémarrez le serveur sur chaque nœud avec les options de démarrage requises.

Chaque nœud d'un cluster doit exécuter la même version et la même version de correctif.

Options de démarrage disponibles

Le tableau suivant présente les options de démarrage disponibles, y compris les options requises pour démarrer ou rejoindre un cluster:

Option Requis ? Valeurs Objectif
--clustered Yes Ajoutez un indicateur pour indiquer que ce nœud s'exécute en mode cluster.
-H ou --hostname Yes 10.10.10.10 Nom d'hôte utilisé par les autres nœuds pour contacter ce nœud, tel que l'adresse IP du nœud ou le nom d'hôte de son système. Doit être différent des noms d'hôte de tous les autres nœuds du cluster.
-n Non 1551 Port de communication entre les nœuds. La valeur par défaut est 1551. Tous les nœuds doivent utiliser le même numéro de port pour la communication entre les nœuds.
-q Non 61616 Port de mise en file d'attente des événements à l'échelle du cluster. La valeur par défaut est 61616.
-d Yes /path/to/looker-db.yml Chemin d'accès au fichier contenant les identifiants de la base de données de l'application Looker.
--shared-storage-dir Yes /path/to/mounted/shared/storage L'option doit renvoyer vers la configuration de répertoire partagé précédemment sur cette page qui contient les répertoires looker/model et looker/models-user-*.

Votre option de démarrage --clustered ne doit pas inclure de valeur.

Exemple de LOOKERARGS et spécification des identifiants de la base de données

Placez les options de démarrage de Looker dans un fichier lookerstart.cfg, situé dans le même répertoire que les fichiers JAR Looker.

Par exemple, vous pouvez indiquer à Looker:

  • Pour utiliser le fichier nommé looker-db.yml comme identifiants de base de données,
  • qu'il s'agit d'un nœud en cluster
  • que les autres nœuds du cluster doivent contacter cet hôte sur l'adresse IP 10.10.10.10.

Vous devez spécifier:

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

Veillez à spécifier la bonne adresse IP pour votre nœud.

Le fichier looker-db.yml contient les identifiants de la base de données, par exemple:

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

De plus, si votre base de données MySQL nécessite une connexion SSL, le fichier looker-db.yml requiert également les éléments suivants:

ssl: true

Suivez les bonnes pratiques concernant la sécurité lorsque vous enregistrez des identifiants dans un fichier. Idéalement, définissez les autorisations du fichier looker-db.yml sur 600, qui appartiennent au compte utilisateur Linux sous lequel l'application Looker est exécutée. Ce fichier ne doit jamais être enregistré dans un dépôt Git.

Si vous ne souhaitez pas stocker la configuration dans le fichier looker-db.yml sur le disque, vous pouvez configurer la variable d'environnement LOOKER_DB pour qu'elle contienne une liste de clés/valeurs pour chaque ligne du fichier looker-db.yml. Exemple :

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

Rechercher vos clés de déploiement SSH Git

L'emplacement de stockage des clés de déploiement SSH de Git dépend de la version dans laquelle le projet a été créé:

  • Pour les projets créés avant Looker 4.8, les clés de déploiement sont stockées dans le répertoire SSH natif du serveur, ~/.ssh.
  • Pour les projets créés dans Looker 4.8 ou version ultérieure, les clés de déploiement sont stockées dans un répertoire contrôlé par Looker, ~/looker/deploy_keys/PROJECT_NAME.

Modifier un cluster Looker

Après avoir créé un cluster Looker, vous pouvez ajouter ou supprimer des nœuds sans modifier les autres nœuds.

Mettre à jour un cluster vers une nouvelle version de Looker

Les mises à jour peuvent impliquer des modifications de schéma de la base de données interne de Looker qui ne seraient pas compatibles avec les versions précédentes de Looker. Pour mettre à jour Looker, il existe deux méthodes.

Méthode plus sûre

  1. Créer une sauvegarde de la base de données de l'application
  2. Arrêtez tous les nœuds du cluster.
  3. Remplacez les fichiers JAR sur chaque serveur.
  4. Démarrez chaque nœud individuellement.

Méthode plus rapide

Cette méthode permet de réduire les temps d'arrêt, mais de perdre les modifications effectuées entre la création de l'instance dupliquée et l'association du serveur proxy aux nouveaux nœuds. Par exemple, si une personne ajoute des utilisateurs ou crée des looks pendant la transition, ces modifications risquent de ne pas être enregistrées dans la nouvelle base de données de l'application.

Pour effectuer la mise à jour à l'aide de cette méthode plus rapide, mais moins aboutie:

  1. Créez une instance dupliquée de la base de données d'application de Looker.
  2. Démarrez un nouveau cluster pointant vers l'instance dupliquée.
  3. Pointez le serveur proxy ou l'équilibreur de charge vers les nouveaux nœuds. Vous pourrez ensuite arrêter les anciens nœuds.