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. Esas dependencias se denominan componentes en esta página, y cada componente se trata 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 de host
SO y distribución
Looker se ejecuta bien en las versiones más comunes de Linux: Red Hat, SUSE y Debian/Ubuntu. Los derivados de estas distribuciones que están diseñados y optimizados para ejecutarse en un entorno particular generalmente son adecuados. Por ejemplo, las distribuciones de Google Cloud o AWS de Linux son compatibles con Looker. Debian y Ubuntu es la variedad de Linux más usada en la comunidad de Looker, y estas son las versiones más conocidas para la asistencia de Looker. Lo más sencillo es usar Debian/Ubuntu o un sistema operativo para un proveedor de servicios en la nube específico que deriva 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, Looker no funcionará normalmente. Looker requiere Java HotSpot 1.8, actualización 161+ o Java OpenJDK 11.0.12+.
CPU y memoria
Los nodos de 4x16 (4 CPU 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 basura 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 disco son más que suficientes para un sistema de producción.
Consideraciones del 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, debe agregar nodos adicionales de 16 x 64 al clúster en lugar de aumentar el tamaño de los nodos a más de 16 x 64. También es posible que prefiramos 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 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. Deberías 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 estar centralizados, 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 detalla la información.
Configuración de JVM
La configuración de Looker JVM se define dentro de la secuencia de comandos de inicio de Looker. Después de cualquier actualización, Looker debe reiniciarse para que se apliquen los cambios en el manifiesto. Los parámetros de configuración predeterminados son los 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 se puede asignar hasta un 60% de la memoria total, pero hay advertencias según el tamaño de la máquina. Para las máquinas con un mínimo de 8 GB de memoria total, recomendamos asignar entre 4 y 5 GB para Java y 800 MB para Meta. En máquinas más grandes, se puede asignar una proporción menor de memoria al 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 parte mayor 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 más que 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 elementos no utilizados 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 esto 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 basura.
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 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 de la secuencia de comandos de shell que inicia Looker.
Conjuntos de subprocesos
Looker tiene varios grupos de subprocesos, ya que es una aplicación de varios 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 estos grupos deban modificarse en función de la configuración predeterminada. En particular, existen 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 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 se puede aumentar a <n>. Con <n> subprocesos del programador, cada nodo podrá ejecutar <n> trabajos de programación simultáneos. Por lo general, se recomienda mantener <n> por debajo de 2 veces la cantidad de CPUs. El host recomendado más grande es uno con 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 sean de renderización, agrega --concurrent-render-jobs=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Sin los nodos del procesador, no se ejecutará ningún trabajo de procesamiento 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 puede 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 conserva información sobre su propia configuración, las conexiones de bases de datos, los usuarios, los grupos y los roles, las carpetas, las Vistas y los paneles 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 MySQL remota. Si no es posible, te recomendamos migrar a una base de datos remota de MySQL 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 MySQL. Cada vez que un usuario ejecuta una Vista o una Exploración, Looker revisará la base de datos para verificar que el usuario aún haya accedido, que tenga privilegios para acceder a los datos, que tenga privilegios para ejecutar la Vista o Exploración, etcétera. Looker también escribirá datos en la base de datos de MySQL, como el 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 dar como resultado 15 o 20 operaciones de lectura y escritura pequeñas en la base de datos 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 y las instrucciones para migrar datos de una base de datos existente de HyperSQL a MySQL están disponibles en la página de documentación Migra la base de datos del backend de Looker a MySQL.
Cuando configures Looker para usar MySQL, se debe crear un archivo YAML que contenga la información de la 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 cuenta con doble licencia, 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 MySQL y ofrecen servicios como la administración de las copias de seguridad y la provisión de 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 con permiso para ver el modelo de Actividad del sistema tiene acceso a varios paneles de Looker compilados previamente para analizar estos datos. Los usuarios también pueden acceder a las exploraciones de metadatos de Looker para realizar análisis adicionales. La base de datos MySQL se usa principalmente para operaciones pequeñas, rápidas para tus consultas. El modelo grande y lento "analítico" las consultas que genera el modelo de actividad del sistema pueden competir con estas consultas operativas y ralentizar a 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 la actividad del sistema se pueden ejecutar en una instancia de MySQL o en una base de datos de Google BigQuery. No se prueban en 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. Estos parámetros de configuración se pueden aplicar 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 en la 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 está dedicado a ejecutar MySQL, innodb_buffer_pool_size se debe establecer entre un 50% y un 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.
Para este ejemplo, un servidor tiene 64 GB de memoria; Por lo tanto, el grupo de búferes de InnoDB debe ser de 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 la posibilidad de un cuello de botella de 8 subprocesos. Aumentar la cantidad de instancias del grupo de búferes reduce las posibilidades de que se produzca un cuello de botella. Se debe configurar innodb_buffer_pool_instances 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 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 adjuntarlo al registro en el momento de la confirmación, luego agrupar varios cambios en los archivos de datos y escribirlos en una sola operación de IO. Cuando se completa el archivo de registro, la base de datos debe detener el procesamiento de las 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. Deben representar alrededor del 25% del 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 servicios en 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 autoalojado, mide la velocidad de las escrituras 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 medimos 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 hacer la prueba, establece la cantidad de subprocesos entre la cantidad de CPU (o núcleos de CPU) en el sistema y 4 veces la cantidad de CPU. Para un sistema de 16 núcleos, es probable que este valor esté 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, 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 establecer el método de limpieza
Por lo general, el sistema operativo almacena en búfer las escrituras en el disco. Debido a que MySQL y el SO almacenan en búfer, existe 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
Habilitar 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
Inhabilitar las estadísticas de 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
Inhabilitar la caché de consultas
La caché de la consulta 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
Amplía 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 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 apropiado 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 variaciones de 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 version control 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.
Google Cloud Source
Consulta la publicación de la comunidad Cómo usar Cloud Source Repositories para el control de versiones en Looker para conocer los pasos para configurar Git con Cloud Source Repositories.
Bitbucket Cloud
Consulta la publicación de Comunidad sobre cómo usar Bitbucket para el control de versión en Looker si quieres conocer los pasos para configurar Git con Bitbucket Cloud. Desde agosto de 2021, Bitbucket Cloud no admite secretos en 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 Configura Phabricator y Looker para el control de versiones para obtener 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 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 pueda resolverse 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 requeridas. Se aplican las mismas consideraciones de SSL que con la aplicación web principal. Recomendamos usar un puerto distinto 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, se deben configurar para aceptar ese certificado.
Conexiones inactivas y tiempos de espera
Cuando un usuario inicia una solicitud grande en Looker, se podría generar una consulta que podría ser costosa de ejecutarse 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 finalizando la pestaña del navegador), Looker quiere saber y finalizar esa consulta de la base de datos.
Para manejar esta situación, cuando la aplicación web cliente realiza una solicitud para ejecutar una consulta a la base de datos, el navegador abrirá una conexión de socket mediante 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 del cliente se cierra o desconecta de alguna manera. El servidor verá que se desconectarán y cancelarán todas las consultas relacionadas con la base de datos.
A menudo, los balanceadores de cargas detectan estas conexiones inactivas abiertas y las finalizan. Para ejecutar Looker de forma eficaz, el balanceador de cargas debe estar configurado para permitir que esta conexión permanezca abierta mientras 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.
Las siguientes son conexiones de salida que Looker podría necesitar.
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
La telemetría y los servidores de licencias de Looker están disponibles con 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 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 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 proteger las conexiones salientes con el firewall.
- 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 usar 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, deberás agregar los nombres de IP o 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 especifica 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 codificar el 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 al tráfico del usuario final, pero los puertos 1551 y 61616 deben estar abiertos entre los nodos del clúster.