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, administrar cargas de trabajo ad hoc y programadas, hacer un seguimiento del desarrollo iterativo de modelos, etcétera. En esta página, esas dependencias se denominan componentes, y cada uno de ellos se analiza en detalle en las siguientes secciones:
- Configuración del host
- Configuración de JVM
- Opciones de inicio de Looker
- Base de datos interna (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: Red Hat, SUSE y Debian/Ubuntu. Por lo general, las derivadas de estas distribuciones que están diseñadas y optimizadas para ejecutarse en un entorno determinado son adecuadas. Por ejemplo, las distribuciones de Linux de Google Cloud o 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 más conocidas por el equipo de asistencia de Looker. Lo más fácil 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, ten en cuenta 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 requiere Looker 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 actualización 161 o posterior, o Java OpenJDK 11.0.12 o posterior.
CPU y memoria
4 nodos de 16 (4 CPUs y 16 GB de RAM) son suficientes para un sistema de desarrollo o una instancia de prueba básica de Looker que usa un equipo pequeño. Sin embargo, para el uso en producción, esto suele no ser suficiente. En nuestra experiencia, 16 nodos de 64 (16 CPUs y 64 GB de RAM) son 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 su ejecución.
Almacenamiento en disco
Por lo general, 100 GB de espacio en el 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 memoria superior a 64 GB. Como regla general, si se requiere más capacidad, debes agregar 16 nodos de 64 bits adicionales al clúster en lugar de aumentar el tamaño de los nodos más allá de 16 nodos de 64 bits. También podemos preferir usar una arquitectura 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 de inmediato 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 fallo, por lo que se recomienda configurar la conmutación por error o la 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 proporcionan más detalles.
Configuración de JVM
La configuración de 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 manifiesten los cambios. 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 la JVM puede asignar hasta el 60% de la memoria total, pero existen excepciones según el tamaño de la máquina. Para 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 máquinas con 60 GB de memoria total, recomendamos una asignación de 36 GB a Java y 1 GB a Meta. Es importante tener en cuenta que, por lo general, la asignación de memoria de Java debe escalar con la memoria total de la máquina, pero Meta debería ser suficiente con 1 GB.
Además, como Looker comparte recursos del sistema con otros procesos, como Chromium para la renderización, la cantidad de memoria asignada a Java debe seleccionarse en función de la carga de renderización anticipada 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 parte de la memoria total. Por ejemplo, en una máquina con 60 GB de memoria total, Java se podría asignar de forma segura a 46 GB, 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 requiera 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. Para cambiar esto, edita 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 JVM.
Opciones de inicio de Looker
Las opciones de inicio se almacenan en un archivo llamado lookerstart.cfg. Este archivo se obtiene en la secuencia de comandos de shell que inicia Looker.
Conjuntos de subprocesos
Como aplicación multiproceso, Looker tiene varios grupos de subprocesos. Estos grupos de subprocesos van desde el servidor web principal hasta subservicios especializados, como la programación, la renderización y las conexiones de 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ústeres que se mencionan en la página Patrones y prácticas de arquitectura de infraestructura alojada por el cliente.
Opciones de alta capacidad de procesamiento de programación
Para todos los nodos que no sean de 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 dedicado, agrega --scheduler-threads=<n> a la variable de entorno LOOKERARGS en lookerstart.cfg. De forma predeterminada, Looker comienza con 10 subprocesos del programador, pero se puede aumentar a <n>. Con <n> subprocesos del programador, cada nodo podrá ejecutar <n> tareas de programación simultáneas. Por lo general, se recomienda mantener <n> por debajo de 2 veces la cantidad de CPUs. El host más grande recomendado es uno con 16 CPUs y 64 GB de memoria, por lo que el límite superior de subprocesos del programador debe ser inferior a 32.
Opciones de alta capacidad de procesamiento de renderización
Para todos los nodos que no renderizan, agrega --concurrent-render-jobs=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Sin nodos de renderización, no se ejecutarán tareas 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 se puede aumentar a <n>. Con <n> subprocesos de renderización, cada nodo podrá ejecutar <n> tareas de renderización simultáneas.
Cada trabajo de renderización puede usar una cantidad significativa de memoria. Reserva alrededor de 2 GB por trabajo de renderización. Por ejemplo, si al proceso principal de Looker (Java) se le asigna el 60% de la memoria total y el 20% de la memoria restante se reserva para el sistema operativo, queda el último 20% para las tareas de renderización. En una máquina de 64 GB, quedan 12 GB, que son suficientes 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 las tareas interactivas, se puede reducir la memoria del proceso principal de Looker para permitir más tareas 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 reservas el 20% para el uso general del SO, queda el 50% (32 GB) para la renderización, que es suficiente para 16 trabajos de renderización simultáneos.
Base de datos interna (backend)
El servidor de Looker mantiene información sobre su propia configuración, conexiones de bases de datos, usuarios, grupos y roles, carpetas, paneles y vistas definidos por el usuario, y muchos otros datos 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 la memoria incorporada en el propio 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 tiene problemas de rendimiento con un uso intensivo. Por lo tanto, te recomendamos que comiences con una base de datos de MySQL remota. Si esto no es posible, te recomendamos que migres 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 de MySQL.
El servidor de Looker realiza muchas operaciones de lectura y escritura pequeñas en la base de datos de MySQL. Cada vez que un usuario ejecuta una vista o una exploración, Looker verifica la base de datos para comprobar que el usuario aún haya accedido, que tenga privilegios para acceder a los datos, que tenga privilegios para ejecutar la vista o la exploración, etcétera. Looker también escribirá datos en la base de datos de MySQL, como la sentencia SQL 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 15 o 20 operaciones de lectura y escritura pequeñas en la base de datos de MySQL.
MySQL
El servidor de MySQL debe ser la versión 8.0.x y debe configurarse 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 HyperSQL existente a MySQL, están disponibles en la página de documentación Cómo migrar la base de datos de backend de Looker a MySQL.
Cuando configuras Looker para usar MySQL, se debe 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 doble, disponible como producto comercial y de código abierto. Oracle continuó mejorando MySQL, y MySQL se bifurca 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 garantiza la funcionalidad.
Versiones de Cloud
Si alojas Looker en tu infraestructura de nube, es lógico alojar la base de datos de MySQL en la misma infraestructura de nube. Los tres proveedores de servicios en la nube principales: 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 las 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 usan Looker. Cualquier usuario de Looker que tenga permiso para ver el modelo Actividad del sistema tiene acceso a una serie de paneles de Looker precompilados para analizar estos datos. Los usuarios también pueden acceder a las exploraciones de los metadatos de Looker para crear análisis adicionales. La base de datos de MySQL se usa principalmente para consultas "operativas" pequeñas, rápidas. Las consultas "analíticas" grandes, lentas y pesadas 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. Tanto los sistemas autoadministrados como ciertos sistemas administrados en la nube proporcionan una configuración básica de replicación a otras bases de datos. La configuración de la replicación está fuera del alcance de este documento.
Para usar la réplica para las consultas de actividad del sistema, 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 de 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 un ajuste y una configuración adicionales. Puedes realizar esta configuración en el archivo /etc/my.cnf o a través de la consola de Google Cloud para instancias administradas en 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].
Establece 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 se dedica a ejecutar MySQL, 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 grupo de búferes de InnoDB debe estar entre 32 GB y 45 GB. Por lo general, cuanto más grande, mejor.
[mysqld] ... innodb_buffer_pool_size=45G
Configura las instancias del grupo de búferes de InnoDB
Cuando varios subprocesos intentan buscar un grupo de búferes grande, pueden entrar en conflicto. Para evitar esto, el grupo de búferes se divide en unidades más pequeñas a las que pueden acceder diferentes subprocesos sin conflictos. De forma predeterminada, el grupo de búferes 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 posibilidad de un cuello de botella. Se debe configurar innodb_buffer_pool_instances para que cada grupo de búferes tenga 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 guardar detalles sobre la transacción en el registro. Si la base de datos falla antes de que se actualicen los archivos de datos, se puede "volver a reproducir" el archivo de registro para aplicar los cambios. La escritura en el archivo de registro es una pequeña operación de inserció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 completa el archivo de registro, la base de datos debe pausar el procesamiento de transacciones nuevas y volver a 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. Deberían 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 deben sumar 8 GB o 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 escriben las operaciones 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 E/S de modo que MySQL escriba datos más rápido.
En un sistema alojado en la nube, el proveedor de la nube debería poder informar el rendimiento de los discos que se usan para el almacenamiento de datos. En el caso de un servidor MySQL alojado por el cliente, mide la velocidad de las operaciones de escritura aleatorias en el disco de datos en operaciones de E/S por segundo (IOPS). La utilidad sysbench de Linux 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 valor 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 entregue contenido. Si muchos clientes se conectan de forma simultánea, se puede procesar una gran cantidad de subprocesos. 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 CPUs (o núcleos de CPU) del sistema y 4 veces la cantidad de CPUs. Para un sistema de 16 núcleos, es probable que este valor esté entre 16 y 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilidad de las transacciones
Un valor de transacción de 1 obliga a MySQL a escribir en el disco para cada transacción. Si el servidor falla, no se perderá la transacción, pero se verá afectado el rendimiento de la base de datos. Establecer este valor en 0 o 2 puede mejorar el rendimiento, pero corres el riesgo de perder un par de segundos de transacciones de datos.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Cómo configurar el método de limpieza
Por lo general, el sistema operativo almacena en búfer las operaciones de escritura en el disco. Dado que MySQL y el SO están en búfer, se produce una penalización de rendimiento. Reducir el método de limpieza 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. La configuración de 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 en los metadatos
Este parámetro de configuración inhabilita la recopilación de estadísticas en las tablas de metadatos internas, lo que mejora el rendimiento de lectura.
[mysqld] ... innodb_stats_on_metadata=OFF
Cómo inhabilitar la caché de consultas
La caché de consultas dejó de estar disponible, por lo que se inhabilita si se configuran query_cache_size y query_cache_type en 0.
[mysqld] ... query_cache_size=0 query_cache_type=0
Aumenta el búfer de unión
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 el tamaño máximo del montón
tmp_table_size y max_heap_table_size establecen valores predeterminados razonables para las tablas temporales en la memoria, antes de que se transfieran de forma forzosa al 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 de las tablas abiertas. La configuración de table_open_cache_instances divide la caché en varias partes más pequeñas. Existe la posibilidad de que se produzca una 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 para proporcionar administración de versiones de los archivos de LookML. Se admiten los principales servicios de hosting de Git, incluidos GitHub, GitLab y Bitbucket. Los proveedores de servicios de Git ofrecen beneficios 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 ser autoalojado y se puede usar como producto de código abierto sin costo de licencia o como producto con licencia compatible. GitHub Enterprise está disponible como servicio autoalojado y es un producto comercial compatible.
En las siguientes secciones, se enumeran las diferencias entre los proveedores de servicios más comunes.
GitHub o 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 Using GitLab for control de versión in Looker de la comunidad de Looker para obtener 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 de usuario, como clave de implementación de repositorio o como clave de implementación global compartida. Puedes encontrar una explicación más detallada en la documentación de GitLab.
Fuente deGoogle Cloud
Consulta la publicación de la comunidad Cómo usar Cloud Source Repositories para el control de versión en Looker para conocer los pasos para configurar Git con Cloud Source Repositories.
Bitbucket Cloud
Consulta la publicación de la comunidad Cómo usar Bitbucket para el control de versión en Looker para obtener pasos para configurar Git con Bitbucket Cloud. A partir de 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 abras 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 en la URL de forma manual.
- Deberás acceder al 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 Cómo configurar Phabricator y Looker para el control de versiones para obtener pasos sobre cómo 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 hacer lo siguiente:
- Acepta conexiones HTTP de un balanceador de cargas o proxy con finalización SSL con el indicador 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 aceptará conexiones HTTP solo 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 distinto del 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, es posible que se genere 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 la laptop, desconectándose de la red o cerrando la pestaña en el navegador), Looker quiere conocer y finalizar esa consulta a la base de datos.
Para controlar esta situación, cuando la aplicación web cliente realice 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 estado inactivo. Este socket se desconectará si la aplicación web cliente se cierra o desconecta de alguna manera. El servidor verá esa desconexión y cancelará las consultas de base de datos relacionadas.
Los balanceadores de cargas suelen detectar estas conexiones inactivas abiertas y finalizarlas. Para ejecutar Looker de manera eficaz, el balanceador de cargas debe configurarse para permitir que esta conexión permanezca abierta durante el tiempo que dure la consulta más larga que pueda ejecutar un usuario. 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 de la distribución de Linux.
Las siguientes son 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 esté alojado el repositorio, es posible que debas atravesar un firewall.
Servicios externos
Los servidores de telemetría y licencias de Looker están disponibles a través de HTTPS en la Internet pública. Es posible que debas agregar el tráfico de un nodo de Looker a ping.looker.com:443 y license.looker.com:443 a una lista de entidades permitidas.
Conexiones de almacenes de datos
Es posible que las bases de datos alojadas en la nube requieran una conexión a través de 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 está fuera de tu propia infraestructura, consulta con el host de la base de datos para obtener detalles de la red.
Servicios de SMTP
De forma predeterminada, Looker envía el correo saliente con SendGrid. Es posible que debas agregar smtp.sendgrid.net:587 a una lista de entidades permitidas. La configuración de SMTP también se puede cambiar para usar un controlador de correo electrónico diferente.
Concentradores de acciones, servidores de acciones y webhooks
Muchos destinos del programador, en particular los webhooks y los que están habilitados en el panel de administración de Looker, implican el envío de datos mediante solicitudes HTTPS.
- En el caso de los webhooks, los usuarios especifican estos destinos durante el tiempo de ejecución y pueden ser contrarios al objetivo de aplicar un firewall a las conexiones salientes.
- En el caso de un centro de acciones, estas solicitudes se envían a
actions.looker.com. Puedes encontrar los detalles en nuestra documentación de configuración de Looker Action Hub. - 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 directamente a la Internet pública, se puede configurar Looker 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, por lo general, querrás agregar las IP 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, se especifica el nombre de host o la dirección IP de cada nodo en la configuración de inicio. Cuando se inicie el nodo, este valor se escribirá en el repositorio de MySQL. Luego, otros miembros del clúster pueden consultar 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 fija del nombre de host o la dirección IP, se puede usar el comando 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 agente de mensajes, que usa los puertos 1551 y 61616. Los puertos 9999 y 19999 deben estar abiertos para el tráfico del usuario final, pero los puertos 1551 y 61616 deben estar abiertos entre los nodos del clúster.