En esta página, se exploran las prácticas comunes para componentes específicos de la arquitectura de Looker y se describe cómo configurarlos en una implementación.
Looker tiene varias dependencias para alojar el servidor, atender cargas de trabajo ad hoc y programadas, hacer un seguimiento del desarrollo iterativo del modelo, etc. En esta página, estas dependencias se denominan componentes, y cada componente se explica en detalle en las siguientes secciones:
- Configuración del host
- Configuración de JVM
- Opciones de inicio de Looker
- Base de datos interna (de backend)
- Servicio de Git
- Red
Configuración del host
SO y distribución
Looker se ejecuta bien en las versiones más comunes de Linux: RedHat, SUSE y Debian/Ubuntu. Por lo general, las derivadas de estas distribuciones que se diseñan y optimizan para ejecutarse en un entorno en particular son adecuadas. Por ejemplo, las distribuciones de Linux Google Cloud o de AWS son compatibles con Looker. Debian/Ubuntu es la variedad de Linux más utilizada en la comunidad de Looker, y estas son las versiones con las que el equipo de asistencia de Looker está más familiarizado. Lo más sencillo es usar Debian/Ubuntu o un sistema operativo para un proveedor de servicios en la nube específico que se derive de Debian/Ubuntu.
Looker se ejecuta en la máquina virtual Java (JVM). Cuando elijas una distribución, considera si las versiones de OpenJDK 11 están actualizadas. Es posible que las distribuciones más antiguas de Linux puedan ejecutar Looker, pero la versión y las bibliotecas de Java que Looker requiere para funciones específicas deben estar actualizadas. Si la JVM no contiene todas las bibliotecas y versiones recomendadas de Looker, este no funcionará con normalidad. Looker requiere Java HotSpot 1.8 update 161 o versiones posteriores, o Java OpenJDK 11.0.12 o versiones posteriores.
CPU y memoria
Los nodos de 4 CPU y 16 GB de RAM son suficientes para un sistema de desarrollo o una instancia de Looker de prueba básica que utiliza un equipo pequeño. Sin embargo, para el uso en producción, esto no suele ser suficiente. Según nuestra experiencia, los nodos de 16 x 64 (16 CPUs y 64 GB de RAM) ofrecen un buen equilibrio entre precio y rendimiento. Más de 64 GB de RAM pueden afectar el rendimiento, ya que los eventos de recolección de elementos no utilizados son de un solo subproceso y detienen todos los demás subprocesos para ejecutarse.
Almacenamiento en disco
Por lo general, 100 GB de espacio en disco son más que suficientes para un sistema de producción.
Consideraciones sobre el clúster
Looker se ejecuta en una JVM de Java, y Java puede tener dificultades para administrar una memoria superior a 64 GB. Como regla general, si se requiere más capacidad, debes agregar nodos adicionales de 16 CPU x 64 GB al clúster en lugar de aumentar el tamaño de los nodos más allá de 16 CPU x 64 GB. También podemos preferir usar una arquitectura agrupada en clústeres para aumentar la disponibilidad.
En un clúster, los nodos de Looker deben compartir ciertas partes del sistema de archivos. Los datos compartidos incluyen lo siguiente:
- Modelos de LookML
- Los modelos de LookML del desarrollador
- Conectividad del servidor de Git
Dado que el sistema de archivos es compartido y aloja varios repositorios de Git, el manejo del acceso simultáneo y el bloqueo de archivos es fundamental. El sistema de archivos debe ser compatible con POSIX. Se sabe que el sistema de archivos de red (NFS) funciona y está disponible con Linux. Debes crear una instancia de Linux adicional y configurar NFS para compartir el disco. El NFS predeterminado puede ser un punto único de falla, por lo que te recomendamos que consideres una configuración de conmutación por error o de alta disponibilidad.
Los metadatos de Looker también deben centralizarse, por lo que su base de datos interna debe migrarse a MySQL. Puede ser un servicio de MySQL o una implementación dedicada de MySQL. En la sección Base de datos interna (backend) de esta página, se explican los detalles.
Configuración de JVM
La configuración de la JVM de Looker se define dentro de la secuencia de comandos de inicio de Looker. Después de cualquier actualización, se debe reiniciar Looker para que se apliquen los cambios en el manifiesto. Las configuraciones predeterminadas son las siguientes:
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}
Recursos
La configuración de recursos se define en la secuencia de comandos de inicio de Looker.
JAVAMEM="2300m" METAMEM="800m"
La asignación de memoria para la JVM debe tener en cuenta la sobrecarga del sistema operativo en el que se ejecuta Looker. La regla general es que se puede asignar a la JVM hasta el 60% de la memoria total, pero hay advertencias según el tamaño de la máquina. Para las máquinas con el mínimo de 8 GB de memoria total, recomendamos una asignación de 4 a 5 GB para Java y 800 MB para Meta. En el caso de las máquinas más grandes, se puede asignar una proporción menor de memoria para el sistema operativo. Por ejemplo, para las máquinas con 60 GB de memoria total, recomendamos asignar 36 GB a Java y 1 GB a Meta. Es importante tener en cuenta que la asignación de memoria de Java suele ajustarse con la memoria total de la máquina, pero Meta debería ser suficiente con 1 GB.
Además, dado que Looker comparte recursos del sistema con otros procesos, como Chromium para la renderización, la cantidad de memoria asignada a Java debe seleccionarse en el contexto de la carga de renderización prevista y el tamaño de la máquina. Si se espera que la carga de renderización sea baja, se puede asignar a Java una mayor proporción de la memoria total. Por ejemplo, en una máquina con 60 GB de memoria total, Java podría asignarse de forma segura a 46 GB, lo que es superior a la recomendación general del 60%. Las asignaciones de recursos exactas adecuadas para cada implementación varían, por lo que debes usar el 60% como referencia y ajustarlo según lo dicte el uso.
Recolección de elementos no utilizados
Looker prefiere usar el recolector de basura más moderno disponible para su versión de Java. De forma predeterminada, el tiempo de espera de la recolección de elementos no utilizados es de 2 segundos, pero se puede cambiar editando la siguiente opción en la configuración de inicio:
-XX:MaxGCPauseMillis=2000
En una máquina más grande con varios núcleos, se podría acortar el tiempo de espera de la recolección de elementos no utilizados.
Registros
De forma predeterminada, los registros de recolección de elementos no utilizados de Looker se almacenan en /tmp/gc.log. Esto se puede cambiar si editas la siguiente opción en la configuración de inicio:
-Xloggc:/tmp/gc.log
JMX
Es posible que la administración de Looker requiera supervisión para ayudar a definir mejor los recursos. Te recomendamos que uses JMX para supervisar el uso de memoria de la JVM.
Opciones de inicio de Looker
Las opciones de inicio se almacenan en un archivo llamado lookerstart.cfg. Este archivo se incluye en la secuencia de comandos de shell que inicia Looker.
Conjuntos de subprocesos
Como aplicación de subprocesos múltiples, Looker tiene varios grupos de subprocesos. Estos grupos de subprocesos abarcan desde el servidor web principal hasta subservicios especializados, como la programación, la renderización y las conexiones a bases de datos externas. Según los flujos de trabajo de tu empresa, es posible que debas modificar estos grupos desde la configuración predeterminada. En particular, hay consideraciones especiales para las topologías de clúster mencionadas en la página Patrones y prácticas de arquitectura de infraestructura alojada por el cliente.
Opciones de alta capacidad de procesamiento de la programación
Para todos los nodos que no son del programador, agrega --scheduler-threads=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Sin subprocesos del programador, no se ejecutarán trabajos programados en estos nodos.
Para todos los nodos del programador dedicados, agrega --scheduler-threads=<n> a la variable de entorno LOOKERARGS en lookerstart.cfg. De forma predeterminada, Looker comienza con 10 subprocesos del programador, pero esta cantidad se puede aumentar a <n>. Con <n> subprocesos del programador, cada nodo podrá ejecutar <n> trabajos de programación simultáneos. En general, se recomienda mantener <n> en menos del doble de la cantidad de CPU. El host más grande recomendado tiene 16 CPU y 64 GB de memoria, por lo que el límite superior de los subprocesos del programador debe ser inferior a 32.
Opciones de alta capacidad de procesamiento de renderización
Para todos los nodos que no son de renderización, agrega --concurrent-render-jobs=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Sin nodos de renderización, no se ejecutarán trabajos de renderización en estos nodos.
Para todos los nodos de renderización dedicados, agrega --concurrent-render-jobs=<n> a la variable de entorno LOOKERARGS en lookerstart.cfg. De forma predeterminada, Looker comienza con dos subprocesos de renderización, pero esta cantidad se puede aumentar a <n>. Con <n> subprocesos de renderización, cada nodo podrá ejecutar <n> trabajos de renderización simultáneos.
Cada trabajo de renderización puede usar una cantidad significativa de memoria. Asigna aproximadamente 2 GB por trabajo de renderización. Por ejemplo, si el proceso principal de Looker (Java) tiene asignado el 60% de la memoria total y el 20% de la memoria restante se reserva para el sistema operativo, el 20% restante se destina a los trabajos de renderización. En una máquina de 64 GB, quedan 12 GB, lo que es suficiente para 6 trabajos de renderización simultáneos. Si un nodo está dedicado a la renderización y no se incluye en el grupo del balanceador de cargas que controla los trabajos interactivos, la memoria del proceso principal de Looker se puede reducir para permitir más trabajos de renderización. En una máquina de 64 GB, se podría asignar aproximadamente el 30% (20 GB) al proceso principal de Looker. Si se reserva el 20% para el uso general del SO, queda el 50% (32 GB) para la renderización, lo que es suficiente para 16 trabajos de renderización simultáneos.
Base de datos interna (de backend)
El servidor de Looker mantiene información sobre su propia configuración, las conexiones de bases de datos, los usuarios, los grupos y los roles, las carpetas, los paneles y las vistas definidos por el usuario, y otros datos diversos en una base de datos interna.
En el caso de una instancia independiente de Looker de tamaño moderado, estos datos se almacenan en una base de datos HyperSQL en memoria integrada en el proceso de Looker. Los datos de esta base de datos se almacenan en el archivo <looker install directory>/.db/looker.script. Si bien es conveniente y liviana, esta base de datos experimenta problemas de rendimiento con un uso intensivo. Por lo tanto, te recomendamos que comiences con una base de datos MySQL remota. Si esto no es factible, recomendamos migrar a una base de datos de MySQL remota una vez que el archivo ~/looker/.db/looker.script alcance los 600 MB. Los clústeres deben usar una base de datos MySQL.
El servidor de Looker realiza muchas lecturas y escrituras pequeñas en la base de datos de MySQL. Cada vez que un usuario ejecuta un Look o una exploración, Looker verificará la base de datos para confirmar que el usuario aún haya accedido, que tenga privilegios para acceder a los datos, que tenga privilegios para ejecutar el Look o la exploración, y así sucesivamente. Looker también escribirá datos en la base de datos de MySQL, como el código SQL real que se ejecutó y la hora en que comenzó y finalizó la solicitud. Una sola interacción entre un usuario y la aplicación de Looker podría generar entre 15 y 20 lecturas y escrituras pequeñas en la base de datos de MySQL.
MySQL
El servidor de MySQL debe ser la versión 8.0.x y debe estar configurado para usar la codificación utf8mb4. Se debe usar el motor de almacenamiento InnoDB. Las instrucciones de configuración de MySQL, así como las instrucciones para migrar datos de una base de datos de HyperSQL existente a MySQL, están disponibles en la página de documentación Migrating the Looker backend database to MySQL.
Cuando configures Looker para usar MySQL, debes crear un archivo YAML que contenga la información de conexión. Asigna el nombre looker-db.yml al archivo YAML y agrega el parámetro de configuración -d looker-db.yml en la sección LOOKERARGS del archivo lookerstart.cfg.
MariaDB
MySQL tiene una licencia dual y está disponible como código abierto y como producto comercial. Oracle siguió mejorando MySQL, y MySQL se bifurcó como MariaDB. Se sabe que las versiones equivalentes de MariaDB de MySQL funcionan con Looker, pero los equipos de ingeniería de Looker no las desarrollan ni las prueban. Por lo tanto, no se admite ni se garantiza la funcionalidad.
Versiones de Cloud
Si alojas Looker en tu infraestructura de nube, es lógico que alojes la base de datos de MySQL en la misma infraestructura de nube. Los tres principales proveedores de servicios en la nube: Amazon AWS, Microsoft Azure y Google Cloud. Los proveedores de servicios en la nube administran gran parte del mantenimiento y la configuración de la base de datos de MySQL, y ofrecen servicios como ayuda para administrar copias de seguridad y proporcionar una recuperación rápida. Se sabe que estos productos funcionan bien con Looker.
Consultas de actividad del sistema
La base de datos de MySQL se usa para almacenar información sobre cómo los usuarios utilizan Looker. Cualquier usuario de Looker que tenga permiso para ver el modelo System Activity tiene acceso a varios paneles prediseñados de Looker para analizar estos datos. Los usuarios también pueden acceder a las exploraciones de los metadatos de Looker para generar análisis adicionales. La base de datos de MySQL se usa principalmente para consultas pequeñas, rápidas y "operativas". Las consultas grandes y lentas de "análisis" que genera el modelo de Actividad del sistema pueden competir con estas consultas operativas y ralentizar Looker.
En estos casos, la base de datos de MySQL se puede replicar en otra base de datos. Tanto los sistemas autoadministrados como algunos sistemas administrados en la nube proporcionan una configuración básica de la replicación en otras bases de datos. La configuración de la replicación está fuera del alcance de este documento.
Para usar la réplica en las consultas de System Activity, crearás una copia del archivo looker-db.yml, por ejemplo, con el nombre looker-usage-db.yml, la modificarás para que apunte a la réplica y agregarás el parámetro de configuración --internal-analytics-connection-file looker-usage-db.yml a la sección LOOKERARGS del archivo lookerstart.cfg.
Las consultas de actividad del sistema se pueden ejecutar en una instancia de MySQL o en una base de datos de Google BigQuery. No se prueban con otras bases de datos.
Configuración del rendimiento de MySQL
Además de la configuración necesaria para migrar la base de datos de backend de Looker a MySQL, los clústeres muy activos pueden beneficiarse de ajustes y configuraciones adicionales. Estos parámetros de configuración se pueden realizar en el archivo /etc/my.cnf o a través de la consola de Google Cloud para las instancias administradas por la nube.
El archivo de configuración my.cnf se divide en varias partes. Los siguientes cambios de configuración que se analizan en esta sección se realizan en la parte [mysqld].
Cómo establecer el tamaño del grupo de búferes de InnoDB
El tamaño del grupo de búferes de InnoDB es la RAM total que se usa para almacenar el estado de los archivos de datos de InnoDB en la memoria. Si el servidor está dedicado a ejecutar MySQL, el valor de innodb_buffer_pool_size debe establecerse entre el 50% y el 70% de la memoria total del sistema.
Si el tamaño total de la base de datos es pequeño, se permite establecer el grupo de búferes de InnoDB en el tamaño de la base de datos en lugar del 50% o más de la memoria.
En este ejemplo, un servidor tiene 64 GB de memoria; por lo tanto, el búfer de InnoDB debe tener entre 32 y 45 GB. Por lo general, cuanto más grande, mejor.
[mysqld] ... innodb_buffer_pool_size=45G
Cómo configurar las instancias del grupo de búferes de InnoDB
Cuando varios subprocesos intentan buscar en un grupo de búferes grande, podrían competir. Para evitar esto, el búfer de memoria se divide en unidades más pequeñas a las que pueden acceder diferentes subprocesos sin conflictos. De forma predeterminada, el búfer de memoria se divide en 8 instancias. Esto crea el potencial de un cuello de botella de 8 subprocesos. Aumentar la cantidad de instancias del grupo de búferes reduce la probabilidad de un cuello de botella. Los innodb_buffer_pool_instances se deben configurar de modo que cada grupo de búferes obtenga al menos 1 GB de memoria.
[mysqld] ... innodb_buffer_pool_instances=32
Optimiza el archivo de registro de InnoDB
Cuando se confirma una transacción, la base de datos tiene la opción de actualizar los datos en el archivo real o puede guardar detalles sobre la transacción en el registro. Si la base de datos falla antes de que se actualicen los archivos de datos, el archivo de registro se puede "reproducir" para aplicar los cambios. La escritura en el archivo de registro es una pequeña operación de anexión. Es eficiente agregar al registro en el momento de la confirmación y, luego, agrupar varios cambios en los archivos de datos y escribirlos en una sola operación de E/S. Cuando se llena el archivo de registro, la base de datos debe pausar el procesamiento de transacciones nuevas y escribir todos los datos modificados en el disco.
Como regla general, el archivo de registro de InnoDB debe ser lo suficientemente grande como para contener 1 hora de transacciones.
Por lo general, hay dos archivos de registro de InnoDB. Deben representar alrededor del 25% de tu grupo de búferes de InnoDB. En el caso de una base de datos de ejemplo con un grupo de búferes de 32 GB, los archivos de registro de InnoDB deberían sumar 8 GB, o bien 4 GB por archivo.
[mysqld] ... innodb_log_file_size=8GB
Configura la capacidad de E/S de InnoDB
MySQL limitará la velocidad a la que se registran las escrituras en el disco para no sobrecargar el servidor. Los valores predeterminados son conservadores para la mayoría de los servidores. Para obtener el mejor rendimiento, usa la utilidad sysbench para medir la velocidad de escritura aleatoria en el disco de datos y, luego, usa ese valor para configurar la capacidad de IO de modo que MySQL escriba datos más rápido.
En un sistema alojado en la nube, el proveedor de la nube debe poder informar el rendimiento de los discos que se usan para el almacenamiento de datos. En el caso de un servidor MySQL autohospedado, mide la velocidad de las escrituras aleatorias en el disco de datos en operaciones de E/S por segundo (IOPS). La utilidad de Linux sysbench es una forma de medir esto. Usa ese valor para innodb_io_capacity_max y un valor de la mitad a tres cuartos de ese para innodb_io_capacity. Por lo tanto, en el siguiente ejemplo, veríamos los valores si midiéramos 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configura subprocesos de InnoDB
MySQL abrirá al menos un subproceso para cada cliente al que se le preste servicio. Si muchos clientes están conectados de forma simultánea, esto puede generar una gran cantidad de subprocesos que se procesan. Esto puede hacer que el sistema dedique más tiempo al intercambio que al procesamiento.
Se deben realizar comparativas para determinar la cantidad ideal de subprocesos. Para realizar la prueba, establece la cantidad de subprocesos entre la cantidad de CPU (o núcleos de CPU) del sistema y 4 veces la cantidad de CPU. Para un sistema de 16 núcleos, es probable que este valor se encuentre entre 16 y 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilidad de la transacción
Un valor de transacción de 1 obliga a MySQL a escribir en el disco para cada transacción. Si el servidor falla, la transacción no se perderá, pero el rendimiento de la base de datos se verá afectado. Establecer este valor en 0 o 2 puede mejorar el rendimiento, pero se corre el riesgo de perder datos de transacciones de unos segundos.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Cómo configurar el método de vaciado
Normalmente, el sistema operativo almacena en búfer las escrituras en el disco. Como MySQL y el SO almacenan en búfer, hay una penalización de rendimiento. Reducir el método de vaciado en una capa de almacenamiento en búfer puede mejorar el rendimiento.
[mysqld] ... innodb_flush_method=O_DIRECT
Habilita un archivo por tabla
De forma predeterminada, MySQL usará un solo archivo de datos para todos los datos. El parámetro de configuración innodb_file_per_table creará un archivo independiente para cada tabla, lo que mejora el rendimiento y la administración de datos.
[mysqld] ... innodb_file_per_table=ON
Inhabilita las estadísticas sobre los metadatos
Este parámetro de configuración inhabilita la recopilación de estadísticas en las tablas de metadatos internos, lo que mejora el rendimiento de lectura.
[mysqld] ... innodb_stats_on_metadata=OFF
Inhabilita la caché de consultas
La caché de consultas dejó de estar disponible, por lo que establecer query_cache_size y query_cache_type en 0 la inhabilita.
[mysqld] ... query_cache_size=0 query_cache_type=0
Cómo ampliar el búfer de unión
El join_buffer se usa para realizar uniones en la memoria. Aumentarlo puede mejorar ciertas operaciones.
[mysqld] ... join_buffer_size=512KB
Aumenta el tamaño de la tabla temporal y del montón máximo
Los parámetros tmp_table_size y max_heap_table_size establecen valores predeterminados razonables para las tablas temporales en la memoria, antes de que se escriban en el disco.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajusta la caché abierta de la tabla
El parámetro de configuración table_open_cache determina el tamaño de la caché que contiene los descriptores de archivos para las tablas abiertas. El parámetro de configuración table_open_cache_instances divide la caché en varias partes más pequeñas. Existe la posibilidad de que haya contención de subprocesos en table_open_cache, por lo que dividirlo en partes más pequeñas ayuda a aumentar la simultaneidad.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Servicio de Git
Looker está diseñado para funcionar con un servicio de Git y proporcionar administración de versiones de los archivos LookML. Se admiten los principales servicios de hosting de Git, incluidos GitHub, GitLab y Bitbucket. Los proveedores de servicios de Git ofrecen valores agregados adicionales, como una GUI para ver los cambios de código y compatibilidad con flujos de trabajo, como solicitudes de extracción y aprobaciones de cambios. Si es necesario, Git se puede ejecutar en un servidor Linux simple.
Si un servicio de hosting de Git no es adecuado para tu implementación debido a las reglas de seguridad, muchos de estos proveedores de servicios ofrecen versiones que se pueden ejecutar en tu propio entorno. En particular, GitLab suele alojarse por cuenta propia y se puede usar como un producto de código abierto sin costo de licencia o como un producto con licencia compatible. GitHub Enterprise está disponible como un servicio autoalojado y es un producto comercial compatible.
En las siguientes secciones, se enumeran los detalles de los proveedores de servicios más comunes.
GitHub/GitHub Enterprise
En la página de documentación Configura y prueba una conexión de Git, se usa GitHub como ejemplo.
GitLab/gitlab.com
Consulta la publicación de Comunidad de Looker Using GitLab for control de versión in Looker para obtener los pasos de configuración detallados de GitLab. Si tu repositorio se encuentra dentro de subgrupos, estos se pueden agregar a la URL del repositorio con el formato HTTPS o SSH:
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
Además, existen tres formas diferentes de almacenar las claves SSH generadas por Looker en GitLab: como clave SSH del usuario, como clave de implementación del repositorio o como clave de implementación compartida global. Puedes encontrar una explicación más detallada en la documentación de GitLab.
Google Cloud Fuente
Consulta la publicación de la comunidad Using Cloud Source Repositories for control de versión in Looker para conocer los pasos para configurar Git con Cloud Source Repositories.
Bitbucket Cloud
Consulta la publicación de la comunidad Using Bitbucket for control de versión in Looker para conocer los pasos para configurar Git con Bitbucket Cloud. Desde agosto de 2021, Bitbucket Cloud no admite secretos en los webhooks de implementación.
Bitbucket Server
Para usar solicitudes de extracción con Bitbucket Server, es posible que debas completar los siguientes pasos:
- Cuando abres una solicitud de extracción, Looker usará automáticamente el número de puerto predeterminado (7999) en la URL. Si usas un número de puerto personalizado, deberás reemplazarlo manualmente en la URL.
- Deberás presionar el webhook de implementación del proyecto para sincronizar la rama de producción en Looker con la rama principal del repositorio.
Difusión de Phabricator
Consulta la publicación de la comunidad Configuración de Phabricator y Looker para el control de versiones para conocer los pasos para configurar Git con Phabricator.
Red
Conexiones entrantes
Aplicación web de Looker
De forma predeterminada, Looker escucha las solicitudes HTTPS en el puerto 9999. Looker usa un certificado autofirmado con un CN de self-signed.looker.com. Como alternativa, el servidor de Looker se puede configurar para que realice las siguientes acciones:
- Aceptar conexiones HTTP desde un balanceador de cargas o proxy de finalización SSL, con la marca de inicio
--ssl-provided-externally-by=<s>El valor debe establecerse en la dirección IP del proxy o en un nombre de host que se pueda resolver de forma local en la dirección IP del proxy. Looker solo aceptará conexiones HTTP desde esta dirección IP. - Usa un certificado SSL proporcionado por el cliente con la marca de inicio
--ssl-keystore=<s>.
API de Looker
La API de Looker escucha en el puerto 19999. Si la instalación requiere acceso a la API, el balanceador de cargas debe tener las reglas de reenvío necesarias. Se aplican las mismas consideraciones de SSL que con la aplicación web principal. Te recomendamos que uses un puerto diferente al de la aplicación web.
Balanceadores de cargas
A menudo, se usa un balanceador de cargas para aceptar una solicitud HTTPS en el puerto 443 con el certificado del cliente y, luego, reenviar la solicitud al nodo del servidor de Looker en el puerto 9999 con el certificado autofirmado o HTTP. Si los balanceadores de cargas usan el certificado autofirmado de Looker, deben configurarse para aceptar ese certificado.
Conexiones inactivas y tiempos de espera
Cuando un usuario inicia una solicitud grande en Looker, esto podría generar una consulta que podría ser costosa de ejecutar en la base de datos. Si el usuario abandona esa solicitud de alguna manera (por ejemplo, cerrando la tapa de su laptop, desconectándose de la red o cerrando esa pestaña en el navegador), Looker quiere saberlo y finalizar esa consulta de la base de datos.
Para controlar esta situación, cuando la aplicación web del cliente realiza una solicitud para ejecutar una consulta de base de datos, el navegador abrirá una conexión de socket con una solicitud HTTP de larga duración al servidor de Looker. Esta conexión permanecerá abierta y en espera. Este socket se desconectará si la aplicación web del cliente se cierra o se desconecta de alguna manera. El servidor verá esa desconexión y cancelará cualquier consulta de base de datos relacionada.
Los balanceadores de cargas suelen detectar estas conexiones inactivas abiertas y las cierran. Para que Looker se ejecute de manera eficaz, el balanceador de cargas debe configurarse de modo que permita que esta conexión permanezca abierta durante el tiempo que dure la consulta más larga que un usuario pueda ejecutar. Se sugiere un tiempo de espera de al menos 60 minutos.
Conexiones salientes
Los servidores de Looker pueden tener acceso saliente sin restricciones a todos los recursos, incluida la Internet pública. Esto simplifica muchas tareas, como la instalación de Chromium, que requiere acceso a los repositorios de paquetes para la distribución de Linux.
A continuación, se indican las conexiones salientes que Looker podría necesitar establecer.
Conexión interna a la base de datos
De forma predeterminada, MySQL escucha las conexiones en el puerto 3306. Los nodos de Looker deben poder iniciar conexiones a MySQL en este puerto. Según cómo se aloje el repositorio, es posible que debas atravesar un firewall.
Servicios externos
Los servidores de licencias y telemetría de Looker están disponibles a través de HTTPS en la Internet pública. Es posible que el tráfico de un nodo de Looker a ping.looker.com:443 y license.looker.com:443 deba agregarse a una lista de entidades permitidas.
Conexiones del almacén de datos
Es posible que las bases de datos alojadas en la nube requieran una conexión a través de la Internet pública. Por ejemplo, si usas BigQuery, es posible que debas agregar accounts.google.com:443 y www.googleapis.com:443 a una lista de entidades permitidas. Si la base de datos se encuentra fuera de tu propia infraestructura, consulta con tu host de base de datos para obtener detalles de la red.
Servicios de SMTP
De forma predeterminada, Looker envía correos electrónicos salientes con SendGrid. Esto puede requerir que se agregue smtp.sendgrid.net:587 a una lista de entidades permitidas. También se puede cambiar la configuración de SMTP para usar otro controlador de correo.
Centros de acción, servidores de acción y webhooks
Muchos destinos del programador, en particular los webhooks y los que están habilitados en el panel de administrador de Looker, implican el envío de datos a través de solicitudes HTTPS.
- En el caso de los webhooks, los usuarios especifican estos destinos en el tiempo de ejecución, y pueden ser contrarios al objetivo de establecer un firewall para las conexiones salientes.
- En el caso de un centro de acción, estas solicitudes se envían a
actions.looker.com. Puedes encontrar los detalles en nuestra documentación de configuración de Action Hub de Looker. - En el caso de otros servidores de acciones, los administradores envían estas solicitudes a los dominios especificados en la configuración del servidor de acciones en el panel Administrador de Looker.
Servidor proxy
Si no se puede acceder a Internet pública directamente, Looker se puede configurar para que use un servidor proxy para las solicitudes HTTP(S). Para ello, agrega una línea como la siguiente a 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"
Ten en cuenta que las comunicaciones entre nodos se realizan a través de HTTPS, por lo que, si usas un servidor proxy y tu instancia está agrupada en clústeres, por lo general, querrás agregar las IPs o los nombres de host de todos los nodos del clúster al argumento Dhttp.nonProxyHosts.
Comunicaciones entre nodos
Identificador de host interno
Dentro de un clúster, cada nodo debe poder comunicarse con los demás. Para permitir esto, el nombre de host o la dirección IP de cada nodo se especifican en la configuración de inicio. Cuando se inicie el nodo, este valor se escribirá en el repositorio de MySQL. Luego, los demás miembros del clúster pueden hacer referencia a esos valores para comunicarse con este nodo. Para especificar el nombre de host o la dirección IP en la configuración de inicio, agrega -H node1.looker.example.com a la variable de entorno LOOKERARGS en lookerstart.cfg.
Dado que el nombre de host debe ser único por nodo, el archivo lookerstart.cfg debe ser único en cada instancia. Como alternativa a la codificación del nombre de host o la dirección IP, se pueden usar los comandos hostname -I o hostname --fqdn para encontrarlos en el tiempo de ejecución. Para implementar esto, agrega -H $(hostname -I) o -H $(hostname --fqdn) a la variable de entorno LOOKERARGS en lookerstart.cfg.
Puertos internos
Además de los puertos 9999 y 19999, que se usan para los servidores web y de API, respectivamente, los nodos del clúster se comunicarán entre sí a través de un servicio de intermediario de mensajes, que usa los puertos 1551 y 61616. Los puertos 9999 y 19999 deben estar abiertos al tráfico de usuarios finales, pero los puertos 1551 y 61616 deben estar abiertos entre los nodos del clúster.