Cette page présente les pratiques courantes concernant des composants spécifiques de l'architecture Looker et explique comment les configurer dans un déploiement.
Looker présente un certain nombre de dépendances pour héberger le serveur, gérer les charges de travail ad hoc et planifiées, suivre le développement itératif des modèles, etc. Ces dépendances sont appelées composants sur cette page. Chacun d'eux est décrit en détail dans les sections suivantes:
- Configuration de l'hôte
- Configuration de la JVM
- Options de démarrage de Looker
- Base de données interne (backend)
- Service Git
- Réseau
Configuration de l'hôte
OS et distribution
Looker fonctionne correctement sur les versions les plus courantes de Linux: RedHat, SUSE et Debian/Ubuntu. Les dérivées de ces distributions conçues et optimisées pour s'exécuter dans un environnement particulier sont généralement acceptables. Par exemple, les distributions Linux Google Cloud ou AWS sont compatibles avec Looker. Debian/Ubuntu est la variante Linux la plus utilisée dans la communauté Looker. Il s'agit des versions les plus familières à l'équipe d'assistance Looker. Il est plus simple d'utiliser Debian/Ubuntu ou un système d'exploitation dérivé de Debian/Ubuntu pour un fournisseur de services cloud spécifique.
Looker s'exécute dans la machine virtuelle Java (JVM). Lorsque vous choisissez une distribution, vérifiez si les versions d'OpenJDK 11 sont à jour. Il est possible que les distributions Linux plus anciennes puissent exécuter Looker, mais la version et les bibliothèques Java requises par Looker pour certaines fonctionnalités doivent être à jour. Si la JVM ne contient pas toutes les bibliothèques et versions Looker recommandées, Looker ne fonctionnera pas normalement. Looker nécessite Java HotSpot 1.8 version 161 ou ultérieure ou Java OpenJDK 11.0.12 ou version ultérieure.
Processeur et mémoire
Des nœuds 4x16 (4 CPU et 16 Go de RAM) suffisent pour un système de développement ou une instance Looker de test de base utilisée par une petite équipe. Toutefois, pour une utilisation en production, cela n'est généralement pas suffisant. D'après notre expérience, les nœuds 16x64 (16 CPU et 64 Go de RAM) offrent un bon équilibre entre prix et performances. Plus de 64 Go de RAM peuvent avoir un impact sur les performances, car les événements de récupération des déchets sont monothread et arrêtent l'exécution de tous les autres threads.
Stockage sur disque
100 Go d'espace disque sont généralement plus que suffisants pour un système de production.
Considérations concernant les clusters
Looker s'exécute sur une JVM Java, et Java peut avoir du mal à gérer une mémoire supérieure à 64 Go. En règle générale, si vous avez besoin de plus de capacité, vous devez ajouter des nœuds 16x64 supplémentaires au cluster plutôt que d'augmenter la taille des nœuds au-delà de 16x64. Nous pouvons également préférer utiliser une architecture en cluster pour améliorer la disponibilité.
Dans un cluster, les nœuds Looker doivent partager certaines parties du système de fichiers. Les données partagées incluent les éléments suivants:
- Modèles LookML
- Les modèles LookML du développeur
- Connectivité du serveur Git
Étant donné que le système de fichiers est partagé et héberge un certain nombre de dépôts Git, la gestion de l'accès simultané et du verrouillage des fichiers est essentielle. Le système de fichiers doit être compatible avec POSIX. Le système de fichiers réseau (NFS) est connu pour fonctionner et est facilement disponible avec Linux. Vous devez créer une instance Linux supplémentaire et configurer NFS pour partager le disque. Le NFS par défaut est potentiellement un point de défaillance unique. Envisagez donc de configurer un basculement ou une haute disponibilité.
Les métadonnées Looker doivent également être centralisées. Par conséquent, sa base de données interne doit être migrée vers MySQL. Il peut s'agir d'un service MySQL ou d'un déploiement MySQL dédié. La section Base de données interne (backend) de cette page fournit des informations plus détaillées.
Configuration de la JVM
Les paramètres JVM de Looker sont définis dans le script de démarrage de Looker. Après toute mise à jour, Looker doit être redémarré pour que les modifications soient prises en compte. Les configurations par défaut sont les suivantes:
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
Ressources
Les paramètres de ressources sont définis dans le script de démarrage de Looker.
JAVAMEM="2300m" METAMEM="800m"
L'allocation de mémoire pour la JVM doit tenir compte de la surcharge du système d'exploitation sur lequel Looker s'exécute. En règle générale, la JVM peut être allouée jusqu'à 60% de la mémoire totale, mais il existe des exceptions en fonction de la taille de la machine. Pour les machines disposant d'un minimum de 8 Go de mémoire totale, nous vous recommandons d'allouer 4 à 5 Go à Java et 800 Mo à Meta. Pour les machines plus grandes, une proportion plus faible de mémoire peut être allouée au système d'exploitation. Par exemple, pour les machines disposant de 60 Go de mémoire totale, nous recommandons d'allouer 36 Go à Java et 1 Go à Meta. Il est important de noter que l'allocation de mémoire de Java doit généralement évoluer avec la mémoire totale de la machine, mais 1 Go devrait suffire pour Meta.
De plus, comme Looker partage des ressources système avec d'autres processus tels que Chromium pour le rendu, la quantité de mémoire allouée à Java doit être sélectionnée en fonction de la charge de rendu prévue et de la taille de la machine. Si la charge de rendu est faible, Java peut être alloué une plus grande part de la mémoire totale. Par exemple, sur une machine disposant de 60 Go de mémoire totale, Java peut être alloué à 46 Go sans risque, ce qui est supérieur à la recommandation générale de 60 %. Les allocations de ressources exactes adaptées à chaque déploiement varient. Utilisez donc 60% comme référence et ajustez-la en fonction de l'utilisation.
Récupération de mémoire
Looker préfère utiliser le garbage collector le plus moderne disponible pour sa version Java. Par défaut, le délai d'expiration du garbage collection est de deux secondes, mais vous pouvez le modifier en modifiant l'option suivante dans la configuration de démarrage:
-XX:MaxGCPauseMillis=2000
Sur une machine plus grande avec plusieurs cœurs, le délai avant expiration de la collecte des déchets peut être réduit.
Journaux
Par défaut, les journaux de récupération de mémoire de Looker sont stockés dans /tmp/gc.log. Pour modifier ce comportement, modifiez l'option suivante dans la configuration de démarrage:
-Xloggc:/tmp/gc.log
JMX
La gestion de Looker peut nécessiter une surveillance pour affiner les ressources. Nous vous recommandons d'utiliser JMX pour surveiller l'utilisation de la mémoire par la JVM.
Options de démarrage de Looker
Les options de démarrage sont stockées dans un fichier appelé lookerstart.cfg. Ce fichier est extrait du script shell qui démarre Looker.
Pools de threads
En tant qu'application multithread, Looker dispose d'un certain nombre de pools de threads. Ces pools de threads vont du serveur Web principal aux sous-services spécialisés tels que la planification, le rendu et les connexions à des bases de données externes. En fonction de vos processus métier, vous devrez peut-être modifier ces pools à partir de la configuration par défaut. En particulier, des considérations particulières s'appliquent aux topologies de cluster mentionnées sur la page Modèles et pratiques d'architecture d'infrastructure hébergée par le client.
Options de débit de planification élevé
Pour tous les nœuds autres que les planificateurs, ajoutez --scheduler-threads=0 à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Sans threads de planificateur, aucune tâche planifiée ne s'exécutera sur ces nœuds.
Pour tous les nœuds d'ordonnancement dédiés, ajoutez --scheduler-threads=<n> à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Looker démarre avec 10 threads de planification par défaut, mais ce nombre peut être augmenté à <n>. Avec <n> threads de planification, chaque nœud peut exécuter <n> tâches de planification simultanées. Il est généralement recommandé de limiter <n> à moins de deux fois le nombre de processeurs. L'hôte le plus important recommandé est celui qui dispose de 16 processeurs et de 64 Go de mémoire. La limite supérieure des threads d'ordonnancement doit donc être inférieure à 32.
Options de débit de rendu élevé
Pour tous les nœuds de rendu, ajoutez --concurrent-render-jobs=0 à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Sans nœuds de rendu, aucun travail de rendu ne s'exécutera sur ces nœuds.
Pour tous les nœuds de rendu dédiés, ajoutez --concurrent-render-jobs=<n> à la variable d'environnement LOOKERARGS dans lookerstart.cfg. Looker démarre avec deux threads de rendu par défaut, mais ce nombre peut être augmenté à <n>. Avec <n> threads de rendu, chaque nœud peut exécuter <n> tâches de rendu simultanées.
Chaque tâche de rendu peut utiliser une quantité importante de mémoire. Prévoyez environ 2 Go par tâche de rendu. Par exemple, si 60% de la mémoire totale est allouée au processus Looker principal (Java) et que 20% de la mémoire restante est réservée au système d'exploitation, les 20% restants sont réservés aux tâches de rendu. Sur une machine de 64 Go, cela laisse 12 Go, ce qui est suffisant pour six tâches de rendu simultanées. Si un nœud est dédié au rendu et n'est pas inclus dans le pool de l'équilibreur de charge qui gère les tâches interactives, la mémoire du processus Looker principal peut être réduite pour permettre d'effectuer davantage de tâches de rendu. Sur une machine de 64 Go, vous pouvez allouer environ 30% (20 Go) au processus de base Looker. En réservant 20% pour l'utilisation générale de l'OS, il reste 50% (32 Go) pour le rendu, ce qui est suffisant pour 16 tâches de rendu simultanées.
Base de données interne (backend)
Le serveur Looker conserve des informations sur sa propre configuration, ses connexions aux bases de données, ses utilisateurs, ses groupes et ses rôles, ses dossiers, ses looks et tableaux de bord définis par l'utilisateur, ainsi que diverses autres données dans une base de données interne.
Pour une instance Looker autonome de taille modérée, ces données sont stockées dans une base de données HyperSQL en mémoire intégrée au processus Looker lui-même. Les données de cette base de données sont stockées dans le fichier <looker install directory>/.db/looker.script. Bien qu'elle soit pratique et légère, cette base de données rencontre des problèmes de performances en cas d'utilisation intensive. Par conséquent, nous vous recommandons de commencer avec une base de données MySQL distante. Si ce n'est pas possible, nous vous recommandons de migrer vers une base de données MySQL distante lorsque le fichier ~/looker/.db/looker.script atteint 600 Mo. Les clusters doivent utiliser une base de données MySQL.
Le serveur Looker effectue de nombreuses petites lectures et écritures dans la base de données MySQL. Chaque fois qu'un utilisateur exécute une analyse ou une exploration, Looker vérifie dans la base de données que l'utilisateur est toujours connecté, qu'il dispose des droits d'accès aux données, qu'il est autorisé à exécuter l'analyse ou l'exploration, etc. Looker écrit également des données dans la base de données MySQL, telles que le code SQL exécuté et l'heure de début et de fin de la requête. Une seule interaction entre un utilisateur et l'application Looker peut entraîner 15 ou 20 petites lectures et écritures dans la base de données MySQL.
MySQL
Le serveur MySQL doit être de la version 8.0.x et doit être configuré pour utiliser l'encodage utf8mb4. Le moteur de stockage InnoDB doit être utilisé. Vous trouverez les instructions de configuration pour MySQL, ainsi que des instructions pour migrer des données d'une base de données HyperSQL existante vers MySQL, sur la page de documentation Migrer la base de données backend Looker vers MySQL.
Lorsque vous configurez Looker pour utiliser MySQL, vous devez créer un fichier YAML contenant les informations de connexion. Nommez le fichier YAML looker-db.yml et ajoutez le paramètre -d looker-db.yml dans la section LOOKERARGS du fichier lookerstart.cfg.
MariaDB
MySQL est doublement sous licence, disponible à la fois en tant que produit Open Source et en tant que produit commercial. Oracle a continué à améliorer MySQL, et MySQL a été dupliqué en tant que MariaDB. Les versions MariaDB équivalentes de MySQL sont connues pour fonctionner avec Looker, mais elles ne sont pas développées ni testées par les équipes d'ingénieurs Looker. Par conséquent, les fonctionnalités ne sont pas prises en charge ni garanties.
Versions Cloud
Si vous hébergez Looker dans votre infrastructure cloud, il est logique d'héberger la base de données MySQL dans la même infrastructure cloud. Les trois principaux fournisseurs de services cloud : Amazon AWS, Microsoft Azure et Google Cloud. Les fournisseurs de services cloud gèrent une grande partie de la maintenance et de la configuration de la base de données MySQL. Ils proposent également des services tels que la gestion des sauvegardes et la récupération rapide. Ces produits sont connus pour fonctionner correctement avec Looker.
Requêtes sur l'activité du système
La base de données MySQL permet de stocker des informations sur la façon dont les utilisateurs utilisent Looker. Tout utilisateur Looker autorisé à afficher le modèle Activité du système a accès à un certain nombre de tableaux de bord Looker prédéfinis pour analyser ces données. Les utilisateurs peuvent également accéder aux explorations des métadonnées Looker pour créer des analyses supplémentaires. La base de données MySQL est principalement utilisée pour les requêtes "opérationnelles", petites, rapides. Les requêtes "analytiques" volumineuses, lentes et générées par le modèle d'activité du système peuvent entrer en concurrence avec ces requêtes opérationnelles et ralentir Looker.
Dans ce cas, la base de données MySQL peut être répliquée dans une autre base de données. Les systèmes autogérés et certains systèmes gérés dans le cloud fournissent une configuration de base de la réplication vers d'autres bases de données. La configuration de la réplication n'entre pas dans le cadre de ce document.
Pour utiliser le réplica pour les requêtes d'activité système, vous devez créer une copie du fichier looker-db.yml, par exemple nommée looker-usage-db.yml, la modifier pour qu'elle pointe vers le réplica et ajouter le paramètre --internal-analytics-connection-file looker-usage-db.yml à la section LOOKERARGS du fichier lookerstart.cfg.
Les requêtes d'activité système peuvent être exécutées sur une instance MySQL ou une base de données Google BigQuery. Elles ne sont pas testées par rapport à d'autres bases de données.
Configuration des performances MySQL
En plus des paramètres requis pour migrer la base de données backend Looker vers MySQL, les clusters très actifs peuvent bénéficier d'un réglage et d'une configuration supplémentaires. Vous pouvez modifier ces paramètres dans le fichier /etc/my.cnf ou via la console Google Cloud pour les instances gérées dans le cloud.
Le fichier de configuration my.cnf est divisé en plusieurs parties. Les modifications de paramètres suivantes décrites dans cette section sont effectuées dans la partie [mysqld].
Définir la taille du pool de mémoire tampon InnoDB
La taille du pool de mémoire tampon InnoDB correspond à la quantité totale de RAM utilisée pour stocker l'état des fichiers de données InnoDB en mémoire. Si le serveur est dédié à l'exécution de MySQL, innodb_buffer_pool_size doit être défini sur 50 % à 70% de la mémoire système totale.
Si la taille totale de la base de données est faible, vous pouvez définir le pool de mémoire tampon InnoDB sur la taille de la base de données plutôt que sur 50% ou plus de la mémoire.
Dans cet exemple, un serveur dispose de 64 Go de mémoire. Par conséquent, le pool de tampons InnoDB doit être compris entre 32 Go et 45 Go. Plus la zone est grande, mieux c'est.
[mysqld] ... innodb_buffer_pool_size=45G
Définir les instances de pool de mémoire tampon InnoDB
Lorsque plusieurs threads tentent de rechercher dans un grand pool de tampons, ils peuvent entrer en conflit. Pour éviter cela, le pool de tampons est divisé en unités plus petites auxquelles différents threads peuvent accéder sans conflit. Par défaut, le pool de tampons est divisé en huit instances. Cela peut entraîner un goulot d'étranglement de huit threads. Augmenter le nombre d'instances de pool de mémoire tampon réduit le risque de goulot d'étranglement. La valeur innodb_buffer_pool_instances doit être définie de sorte que chaque pool de tampons dispose d'au moins 1 Go de mémoire.
[mysqld] ... innodb_buffer_pool_instances=32
Optimiser le fichier journal InnoDB
Lorsqu'une transaction est validée, la base de données peut mettre à jour les données du fichier réel ou enregistrer des informations sur la transaction dans le journal. Si la base de données plante avant que les fichiers de données n'aient été mis à jour, le fichier journal peut être "rejoué" pour appliquer les modifications. L'écriture dans le fichier journal est une petite opération d'ajout. Il est efficace d'ajouter des éléments au journal au moment de la validation, puis de regrouper plusieurs modifications dans les fichiers de données et de les écrire dans une seule opération d'E/S. Lorsque le fichier journal est rempli, la base de données doit suspendre le traitement des nouvelles transactions et réécrire toutes les données modifiées sur le disque.
En règle générale, le fichier journal InnoDB doit être suffisamment volumineux pour contenir une heure de transactions.
Il existe généralement deux fichiers journaux InnoDB. Elles doivent représenter environ 25% de votre pool de mémoire tampon InnoDB. Pour une base de données avec un pool de mémoire tampon de 32 Go, les fichiers journaux InnoDB doivent totaliser 8 Go, soit 4 Go par fichier.
[mysqld] ... innodb_log_file_size=8GB
Configurer la capacité d'E/S d'InnoDB
MySQL limite la vitesse à laquelle les écritures sont enregistrées sur le disque afin de ne pas surcharger le serveur. Les valeurs par défaut sont conservatrices pour la plupart des serveurs. Pour des performances optimales, utilisez l'utilitaire sysbench pour mesurer la vitesse d'écriture aléatoire sur le disque de données, puis utilisez cette valeur pour configurer la capacité d'E/S afin que MySQL écrive les données plus rapidement.
Sur un système hébergé dans le cloud, le fournisseur de services cloud doit pouvoir signaler les performances des disques utilisés pour le stockage des données. Pour un serveur MySQL auto-hébergé, mesurez la vitesse des écritures aléatoires sur le disque de données en opérations d'E/S par seconde (IOPS). L'utilitaire Linux sysbench est l'un des moyens de le mesurer. Utilisez cette valeur pour innodb_io_capacity_max et une valeur comprise entre la moitié et les trois quarts de cette valeur pour innodb_io_capacity. Dans l'exemple suivant, nous verrons les valeurs si nous avons mesuré 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configurer les threads InnoDB
MySQL ouvre au moins un thread pour chaque client desservi. Si de nombreux clients sont connectés simultanément, un grand nombre de threads peuvent être traités. Cela peut entraîner un temps d'échange plus long que le temps de traitement.
Un benchmark doit être effectué pour déterminer le nombre idéal de threads. Pour effectuer le test, définissez le nombre de threads entre le nombre de processeurs (ou de cœurs de processeur) du système et quatre fois le nombre de processeurs. Pour un système à 16 cœurs, cette valeur est probablement comprise entre 16 et 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilité des transactions
Une valeur de transaction de 1 force MySQL à écrire sur le disque pour chaque transaction. Si le serveur plante, la transaction n'est pas perdue, mais les performances de la base de données sont affectées. Définir cette valeur sur 0 ou 2 peut améliorer les performances, mais vous risquez de perdre quelques secondes de transactions de données.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Définir la méthode de vidage
Le système d'exploitation effectue généralement la mise en mémoire tampon des écritures sur le disque. Étant donné que MySQL et l'OS utilisent tous deux la mise en tampon, les performances sont affectées. Réduire la méthode de vidage d'une couche de mise en mémoire tampon peut améliorer les performances.
[mysqld] ... innodb_flush_method=O_DIRECT
Activer un fichier par table
Par défaut, MySQL utilise un seul fichier de données pour toutes les données. Le paramètre innodb_file_per_table crée un fichier distinct pour chaque table, ce qui améliore les performances et la gestion des données.
[mysqld] ... innodb_file_per_table=ON
Désactiver les statistiques sur les métadonnées
Ce paramètre désactive la collecte d'informations statistiques sur les tables de métadonnées internes, ce qui améliore les performances de lecture.
[mysqld] ... innodb_stats_on_metadata=OFF
Désactiver le cache de requêtes
Le cache de requêtes est obsolète. Par conséquent, si vous définissez query_cache_size et query_cache_type sur 0, il est désactivé.
[mysqld] ... query_cache_size=0 query_cache_type=0
Augmenter la taille du tampon de jointure
join_buffer permet d'effectuer des jointures en mémoire. L'augmenter peut améliorer certaines opérations.
[mysqld] ... join_buffer_size=512KB
Augmenter la taille de la table temporaire et des tailles de tas maximales
tmp_table_size et max_heap_table_size définissent des valeurs par défaut raisonnables pour les tables temporaires en mémoire, avant qu'elles ne soient forcées sur disque.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajuster le cache des tables ouvertes
Le paramètre table_open_cache détermine la taille du cache qui contient les descripteurs de fichiers pour les tables ouvertes. Le paramètre table_open_cache_instances divise le cache en plusieurs parties plus petites. Il existe un risque de conflit de threads dans le table_open_cache. Le diviser en parties plus petites permet donc d'augmenter la simultanéité.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Service Git
Looker est conçu pour fonctionner avec un service Git afin de gérer les versions des fichiers LookML. Les principaux services d'hébergement Git sont compatibles, y compris GitHub, GitLab et Bitbucket. Les fournisseurs de services Git offrent des avantages supplémentaires, comme une IUG pour afficher les modifications de code et la prise en charge de workflows tels que les requêtes pull et les approbations de modifications. Si nécessaire, Git peut être exécuté sur un serveur Linux standard.
Si un service d'hébergement Git n'est pas adapté à votre déploiement en raison de règles de sécurité, de nombreux fournisseurs de services proposent des versions pouvant être exécutées dans votre propre environnement. GitLab, en particulier, est généralement auto-hébergé et peut être utilisé en tant que produit Open Source sans frais de licence ou en tant que produit sous licence avec assistance. GitHub Enterprise est disponible en tant que service auto-hébergé et est un produit commercial pris en charge.
Les sections suivantes présentent les différences entre les fournisseurs de services les plus courants.
GitHub/GitHub Enterprise
La page de documentation Configurer et tester une connexion Git utilise GitHub comme exemple.
GitLab/gitlab.com
Pour connaître la procédure de configuration détaillée de GitLab, consultez l'article de la communauté Looker Utiliser GitLab pour le contrôle des versions dans Looker. Si votre dépôt est contenu dans des sous-groupes, vous pouvez les ajouter à l'URL du dépôt au format HTTPS ou SSH:
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
De plus, vous pouvez stocker les clés SSH générées par Looker dans GitLab de trois manières différentes: en tant que clé SSH utilisateur, en tant que clé de déploiement de dépôt ou en tant que clé de déploiement partagée globale. Pour en savoir plus, consultez la documentation GitLab.
Google Cloud Source
Consultez le post de la communauté Utiliser Cloud Source Repositories pour le contrôle des versions dans Looker pour découvrir comment configurer Git avec Cloud Source Repositories.
Bitbucket Cloud
Pour savoir comment configurer Git avec Bitbucket Cloud, consultez l'article de la communauté Utiliser Bitbucket pour le contrôle des versions dans Looker. Depuis août 2021, Bitbucket Cloud n'est pas compatible avec les secrets dans les webhooks de déploiement.
Bitbucket Server
Pour utiliser les demandes de tirage avec Bitbucket Server, vous devrez peut-être suivre les étapes suivantes:
- Lorsque vous ouvrez une demande d'extraction, Looker utilise automatiquement le numéro de port par défaut (7999) dans l'URL. Si vous utilisez un numéro de port personnalisé, vous devez le remplacer manuellement dans l'URL.
- Vous devez appeler le webhook de déploiement du projet pour synchroniser la branche de production dans Looker avec la branche principale du dépôt.
Diffusion de Phabricator
Pour savoir comment configurer Git avec Phabricator, consultez le post de la communauté Configurer Phabricator et Looker pour le contrôle des versions.
Réseau
Connexions entrantes
Application Web Looker
Par défaut, Looker écoute les requêtes HTTPS sur le port 9999. Looker utilise un certificat autosigné avec un CN de self-signed.looker.com. Le serveur Looker peut également être configuré pour effectuer les opérations suivantes:
- Acceptez les connexions HTTP à partir d'un équilibreur de charge/proxy avec terminaison SSL, avec l'indicateur de démarrage
--ssl-provided-externally-by=<s>. La valeur doit être définie sur l'adresse IP du proxy ou sur un nom d'hôte qui peut être résolu localement en adresse IP du proxy. Looker n'acceptera les connexions HTTP que depuis cette adresse IP. - Utilisez un certificat SSL fourni par le client, avec l'indicateur de démarrage
--ssl-keystore=<s>.
API Looker
L'API Looker écoute sur le port 19999. Si l'installation nécessite un accès à l'API, l'équilibreur de charge doit disposer des règles de transfert requises. Les mêmes considérations SSL s'appliquent qu'avec l'application Web principale. Nous vous recommandons d'utiliser un port distinct de l'application Web.
Équilibreurs de charge
Un équilibreur de charge est souvent utilisé pour accepter une requête HTTPS sur le port 443 à l'aide du certificat du client, puis pour transmettre la requête au nœud de serveur Looker sur le port 9999 à l'aide du certificat autosigné ou du protocole HTTP. Si les équilibreurs de charge utilisent le certificat autosigné Looker, ils doivent être configurés pour accepter ce certificat.
Connexions inactives et délais avant expiration
Lorsqu'un utilisateur lance une requête volumineuse dans Looker, il peut en résulter une requête dont l'exécution sur la base de données peut être coûteuse. Si l'utilisateur abandonne cette requête de quelque manière que ce soit (par exemple, en fermant le capot de son ordinateur portable, en se déconnectant du réseau ou en fermant cet onglet dans le navigateur), Looker doit le savoir et mettre fin à cette requête de base de données.
Pour gérer cette situation, lorsque l'application Web cliente envoie une requête pour exécuter une requête de base de données, le navigateur ouvre une connexion de socket à l'aide d'une requête HTTP longue durée au serveur Looker. Cette connexion restera ouverte et inactive. Ce socket sera déconnecté si l'application Web cliente est arrêtée ou déconnectée de quelque manière que ce soit. Le serveur verra cette déconnexion et annulera toutes les requêtes de base de données associées.
Les équilibreurs de charge remarquent souvent ces connexions ouvertes inactives et les arrêtent. Pour exécuter Looker efficacement, l'équilibreur de charge doit être configuré pour permettre à cette connexion de rester ouverte aussi longtemps que la requête la plus longue qu'un utilisateur peut exécuter. Nous vous recommandons de définir un délai avant expiration d'au moins 60 minutes.
Connexions sortantes
Les serveurs Looker peuvent disposer d'un accès sortant illimité à toutes les ressources, y compris à l'Internet public. Cela simplifie de nombreuses tâches, comme l'installation de Chromium, qui nécessite l'accès aux dépôts de paquets de la distribution Linux.
Vous trouverez ci-dessous les connexions sortantes que Looker peut être amené à effectuer.
Connexion à la base de données interne
Par défaut, MySQL écoute les connexions sur le port 3306. Les nœuds Looker doivent pouvoir établir des connexions à MySQL sur ce port. Selon la façon dont le dépôt est hébergé, vous devrez peut-être passer par un pare-feu.
Services externes
Les serveurs de télémétrie et de licence Looker sont disponibles sur l'Internet public via HTTPS. Vous devrez peut-être ajouter le trafic d'un nœud Looker vers ping.looker.com:443 et license.looker.com:443 à une liste d'autorisation.
Connexions à un entrepôt de données
Les bases de données hébergées dans le cloud peuvent nécessiter une connexion via l'Internet public. Par exemple, si vous utilisez BigQuery, vous devrez peut-être ajouter accounts.google.com:443 et www.googleapis.com:443 à une liste d'autorisation. Si la base de données se trouve en dehors de votre propre infrastructure, contactez l'hôte de la base de données pour obtenir des informations sur le réseau.
Services SMTP
Par défaut, Looker envoie les e-mails sortants à l'aide de SendGrid. Vous devrez peut-être ajouter smtp.sendgrid.net:587 à une liste d'autorisation. Vous pouvez également modifier les paramètres SMTP dans la configuration pour utiliser un autre gestionnaire de messagerie.
Action hubs, serveurs d'actions et webhooks
De nombreuses destinations de planification, en particulier les webhooks et celles qui sont activées dans le panneau d'administration Looker, impliquent l'envoi de données à l'aide de requêtes HTTPS.
- Pour les webhooks, ces destinations sont spécifiées par les utilisateurs au moment de l'exécution et peuvent être contraires à l'objectif de filtrage des connexions sortantes.
- Pour un hub d'actions, ces requêtes sont envoyées à
actions.looker.com. Pour en savoir plus, consultez notre documentation de configuration de Looker Action Hub. - Pour les autres serveurs d'actions, ces requêtes sont envoyées aux domaines spécifiés dans la configuration du serveur d'actions par les administrateurs dans le panneau Administration de Looker.
Serveur proxy
Si l'Internet public n'est pas accessible directement, Looker peut être configuré pour utiliser un serveur proxy pour les requêtes HTTP(S) en ajoutant une ligne semblable à la suivante à lookerstart.cfg:
JAVAARGS="-Dhttp.proxyHost=myproxy.example.com -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=127.0.0.1|localhost -Dhttps.proxyHost=myproxy.example.com -Dhttps.proxyPort=8080"
Notez que les communications inter-nœuds s'effectuent via HTTPS. Par conséquent, si vous utilisez un serveur proxy et que votre instance est en cluster, vous devez généralement ajouter les adresses IP/noms d'hôte de tous les nœuds du cluster à l'argument Dhttp.nonProxyHosts.
Communications internœuds
Identifiant d'hôte interne
Dans un cluster, chaque nœud doit pouvoir communiquer avec les autres nœuds. Pour ce faire, le nom d'hôte ou l'adresse IP de chaque nœud est spécifié dans la configuration de démarrage. Lorsque le nœud démarre, cette valeur est écrite dans le dépôt MySQL. Les autres membres du cluster peuvent ensuite se référer à ces valeurs pour communiquer avec ce nœud. Pour spécifier le nom d'hôte ou l'adresse IP dans la configuration de démarrage, ajoutez -H node1.looker.example.com à la variable d'environnement LOOKERARGS dans lookerstart.cfg.
Étant donné que le nom d'hôte doit être unique par nœud, le fichier lookerstart.cfg doit être unique pour chaque instance. Au lieu de coder en dur le nom d'hôte ou l'adresse IP, vous pouvez utiliser la commande hostname -I ou hostname --fqdn pour les trouver au moment de l'exécution. Pour ce faire, ajoutez -H $(hostname -I) ou -H $(hostname --fqdn) à la variable d'environnement LOOKERARGS dans lookerstart.cfg.
Ports internes
En plus des ports 9999 et 19999, qui sont utilisés respectivement pour les serveurs Web et d'API, les nœuds du cluster communiquent entre eux via un service de courtier de messages, qui utilise les ports 1551 et 61616. Les ports 9999 et 19999 doivent être ouverts au trafic des utilisateurs finaux, mais les ports 1551 et 61616 doivent être ouverts entre les nœuds du cluster.