Ce tutoriel explique la méthode recommandée pour créer une configuration Looker en cluster pour les instances hébergées par le client.
Présentation
Les déploiements de Looker hébergés par le client peuvent exécuter un nœud unique ou un cluster:
- Une application Looker à nœud unique, la configuration par défaut, contient 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. Chaque nœud d'une application Looker en cluster est un serveur exécutant une seule instance Looker.
Une entreprise peut souhaiter exécuter Looker en tant que cluster pour deux raisons principales:
- Équilibrage de charge
- Disponibilité et basculement améliorés
En fonction des problèmes de scaling, un groupe Looker peut ne pas fournir la solution. Par exemple, si un petit nombre de requêtes volumineuses utilise 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 mettre en place une surveillance détaillée des performances de 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 améliorer les performances. Le clustering peut améliorer les performances lorsque de nombreux utilisateurs exécutent de petites requêtes.
Pour les configurations comportant jusqu'à 50 utilisateurs utilisant Looker légèrement, Looker recommande d'exécuter un seul serveur équivalent à une instance AWS EC2 de grande taille (M4.large: 8 Go de RAM, 2 cœurs de processeur). Pour les configurations comportant davantage d'utilisateurs ou un grand nombre d'utilisateurs actifs, vérifiez si le CPU augmente ou si les utilisateurs remarquent une lenteur de l'application. Si tel est le cas, déplacez Looker vers un serveur plus grand ou exécutez une configuration Looker en cluster.
Disponibilité et basculement améliorés
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 des systèmes métier de base 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 qui quittent et rejoignent le cluster.
Composants requis
Les composants suivants sont requis pour une configuration Looker en cluster:
- Base de données d'application MySQL
- Nœuds Looker (serveurs exécutant le processus Looker Java)
- Équilibreur de charge
- Système de fichiers partagé
- Version appropriée des fichiers JAR de l'application Looker
Le schéma suivant illustre les interactions entre les composants. De manière générale, un équilibreur de charge répartit le trafic réseau entre les nœuds Looker en cluster. Les nœuds communiquent chacun avec une base de données d'application MySQL partagée, un répertoire de stockage partagé et les serveurs Git pour chaque projet LookML.
Base de données d'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 s'exécute comme une application à nœud unique, il utilise normalement une base de données HyperSQL en mémoire.
Dans une configuration Looker en cluster, l'instance Looker de chaque nœud doit pointer vers une base de données transactionnelle partagée (l'application partagée ou la base de données interne). La prise en charge de la base de données d'application pour Looker en cluster est la suivante:
- Seule MySQL est compatible avec la base de données d'application pour les instances Looker en cluster. Amazon Aurora et MariaDB ne sont pas pris en charge.
- Les versions 5.7 et ultérieures de MySQL, et les versions 8.0 et ultérieures sont prises en charge.
- Les bases de données en cluster telles que Galera ne sont pas acceptées.
Looker ne gère pas la maintenance ni les sauvegardes de cette base de données. Cependant, 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 Looker Java est en cours d'exécution. 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 répertoriés dans la section Ouvrir les ports pour les nœuds à communiquer sur cette page.
Équilibreur de charge
Pour équilibrer la charge ou rediriger les requêtes vers les nœuds disponibles, un équilibreur de charge ou un serveur proxy (par exemple, NGINX ou AWS ELB) est nécessaire afin de 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 en tant que couche 4 uniquement. C'est par exemple le cas d'Amazon Classic ELB. En outre, l'équilibreur de charge doit disposer d'un long délai avant expiration (3 600 secondes) pour empêcher la fermeture 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 ou bien d'autres). Looker utilise le système de fichiers partagé comme référentiel pour les différentes informations utilisées par tous les nœuds du cluster.
Application Looker (exécutable JAR)
Vous devez utiliser un fichier JAR de l'application Looker utilisant Looker 3.56 ou une version ultérieure.
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:
- Installer Looker
- Configurer une base de données d'application MySQL
- Configurer le système de fichiers partagé
- Partagez le dépôt de clés SSH (selon votre cas).
- Ouvrir les ports pour que les nœuds puissent communiquer
- Démarrer Looker sur les nœuds
Installation de Looker
Assurez-vous que Looker est installé sur chaque nœud, à l'aide des fichiers JAR de l'application Looker et des instructions de la page de documentation 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 existante sans cluster qui utilise HyperSQL pour la base de données d'application, vous devez migrer les données de l'application depuis les données HyperSQL vers votre nouvelle base de données d'application MySQL partagée.
Consultez la page de documentation Migrer vers MySQL pour en savoir plus sur la sauvegarde de Looker, puis la migration de la base de données de l'application de HyperSQL vers MySQL.
Configurer le système de fichiers partagé
Seuls certains types de fichiers (fichiers de modèle, clés de déploiement, plug-ins et potentiellement fichiers manifestes d'applications) appartiennent au système de fichiers partagé. Pour configurer le système de fichiers partagé:
- Sur le serveur qui stockera le système de fichiers partagé, vérifiez que vous avez accès à un autre compte pouvant
su
sur le compte utilisateur Looker. - Sur le serveur du système de fichiers partagé, connectez-vous au compte utilisateur Looker.
- Si Looker est en cours d'exécution, arrêtez votre configuration Looker.
- Si vous aviez précédemment effectué un clustering à l'aide de scripts Linux inotify, arrêtez-les, supprimez-les de Cron, puis supprimez-les.
- Créez un partage réseau et installez-le sur chaque nœud du cluster. Assurez-vous qu'il est configuré pour s'installer automatiquement sur chaque nœud, et que l'utilisateur Looker a la possibilité de le lire et d'y écrire. Dans l'exemple suivant, le partage réseau est nommé
/mnt/looker-share
. Sur un nœud, copiez vos clés de déploiement, puis déplacez vos plug-ins ainsi que les répertoires
looker/models
etlooker/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/
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
Vous devez ajouter
LOOKERARGS
à$HOME/looker/lookerstart.cfg
afin que les paramètres ne soient pas affectés par les mises à jour. Si vosLOOKERARGS
ne sont pas répertoriés dans ce fichier, il est possible que quelqu'un les ait ajoutés 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èmes 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.
Configurez le dépôt de clés SSH à partager:
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épertoiressh-share
(tels que/mnt
et/mnt/looker-share
) ne sont pas accessibles en écriture ou par groupe.Sur un nœud, copiez le contenu de
$HOME/.ssh
dans le nouveau répertoiressh-share
. Exemple :cp $HOME/.ssh/* /mnt/looker-share/ssh-share
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
Assurez-vous d'effectuer cette étape pour chaque nœud.
Ouvrir les ports pour que les nœuds puissent communiquer
Les nœuds Looker en cluster communiquent entre eux via HTTPS à l'aide de certificats autosignés et d'un schéma d'authentification supplémentaire basé sur la rotation des secrets dans la base de données de l'application.
Les ports par défaut qui doivent être ouverts entre les nœuds de cluster sont 1551 et 61616. Vous pouvez configurer ces ports à l'aide des indicateurs de démarrage répertoriés ici. Nous vous recommandons vivement de limiter l'accès réseau à ces ports afin de n'autoriser le trafic qu'entre les hôtes du cluster.
Démarrage de Looker sur les nœuds
Redémarrez le serveur sur chaque nœud avec les indicateurs de démarrage requis.
Indicateurs de démarrage disponibles
Le tableau suivant présente les options de démarrage disponibles, y compris celles requises pour démarrer ou rejoindre un cluster:
Option | Requis ? | Valeurs | Objectif |
---|---|---|---|
--clustered |
Oui | Ajoutez une option pour indiquer que ce nœud s'exécute en mode cluster. | |
-H ou --hostname |
Oui | 10.10.10.10 |
Nom d'hôte utilisé par d'autres nœuds pour contacter ce nœud (par exemple, l'adresse IP du nœud ou le nom d'hôte du système). Ils doivent être différents des noms d'hôte de tous les autres nœuds du cluster. |
-n |
Non | 1551 |
Port pour la 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 pour la mise en file d'attente des événements à l'échelle du cluster. La valeur par défaut est 61616. |
-d |
Oui | /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 |
Oui | /path/to/mounted/shared/storage |
L'option doit pointer vers le répertoire partagé que vous avez configuré précédemment sur cette page, qui contient les répertoires looker/model et looker/models-user-* . |
Exemple de LOOKERARGS
et de spécification des identifiants de la base de données
Placez les indicateurs de démarrage Looker dans un fichier lookerstart.cfg
, situé dans le même répertoire que les fichiers JAR de Looker.
Par exemple, vous pouvez indiquer à Looker:
- Pour utiliser le fichier nommé
looker-db.yml
pour ses 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"
Le fichier looker-db.yml
contiendrait les identifiants de la base de données, tels que:
host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword
Par ailleurs, si votre base de données MySQL requiert une connexion SSL, le fichier looker-db.yml
requiert également les éléments suivants:
ssl: true
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 et de valeurs pour chaque ligne du fichier looker-db.yml
. Exemple :
export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"
Trouver vos clés de déploiement SSH Git
L'emplacement de stockage des clés de déploiement SSH 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 intégré 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 du cluster.
Mise à jour d'un cluster vers une nouvelle version de Looker
Les mises à jour peuvent impliquer des modifications du schéma de la base de données interne de Looker qui ne seraient pas compatibles avec les versions précédentes de Looker. Il existe deux méthodes pour mettre à jour Looker.
Méthode plus sûre
- Créez une sauvegarde de la base de données de l'application.
- Arrêtez tous les nœuds du cluster.
- Remplacez les fichiers JAR sur chaque serveur.
- Démarrez chaque nœud un par un.
Méthode plus rapide
Pour effectuer la mise à jour à l'aide de cette méthode plus rapide, mais moins complète:
- Créez une instance répliquée de la base de données d'application de Looker.
- Démarrez un nouveau cluster pointant vers l'instance répliquée.
- Faites pointer le serveur proxy ou l'équilibreur de charge vers les nouveaux nœuds, après quoi vous pourrez arrêter les anciens nœuds.