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 una serie de dependencias para alojar el servidor, prestar servicio a cargas de trabajo ad hoc y programadas, hacer un seguimiento del desarrollo de modelos iterativos, 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 de Java (JVM). A la hora de elegir una distribución, considera si las versiones de OpenJDK 11 están actualizadas. Es posible que las distribuciones anteriores 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, 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 no suele ser suficiente. Según nuestra experiencia, los nodos de 16 × 64 (16 CPU y 64 GB de RAM) constituyen 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 del clúster
Looker se ejecuta en una JVM de Java, y Java puede tener dificultades para administrar memorias de más de 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. Es posible que también prefieramos 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 control 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 es potencialmente un punto único de fallo, por lo que debes considerar una configuración de conmutación por error o de 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 la 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 asignar 36 GB a Java y 1 GB a Meta. Es importante tener en cuenta que, en general, la asignación de memoria de Java debería escalar con la memoria total de la máquina, pero Meta debería ser suficiente con 1 GB.
Además, dado que Looker comparte los recursos del sistema con otros procesos, como Chromium para la renderización, se debe elegir la cantidad de memoria asignada a Java en el contexto 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 exactas de recursos apropiadas para cada implementación varían, por lo que debes usar el 60% como modelo de referencia y ajustarlo según 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, el tiempo de espera de la recolección de elementos no utilizados podría acortarse.
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 editando 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 usar 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 programadores, agrega --scheduler-threads=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Sin los 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. Looker comienza con 10 subprocesos del programador de forma predeterminada, pero esto se puede aumentar a <n>. Con <n> del programador, cada nodo podrá ejecutar <n> programados de forma simultánea. Generalmente, se recomienda mantener <n> menos del doble de la cantidad de CPU. 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. Looker comienza con dos subprocesos de renderización de forma predeterminada, pero esto se puede aumentar a <n>. Con <n> renderizar subprocesos, cada nodo podrá ejecutar <n> trabajos de renderización simultáneos.
Cada trabajo de renderización puede usar una cantidad significativa de memoria. Ten un presupuesto de 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, el último 20% se deja para los trabajos de renderización. En una máquina de 64 GB, deja 12 GB, 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 maneja 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 puede asignar aproximadamente el 30% (20 GB) al proceso principal de Looker. Se reserva el 20% para el uso general del SO, lo que deja un 50% (32 GB) para la renderización, lo 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, usuarios, grupos y roles, carpetas, vistas y paneles definidos por el usuario, y muchos otros datos en una base de datos interna.
En una instancia independiente de Looker de tamaño moderado, estos datos se almacenan en una base de datos de HyperSQL en la memoria incorporada en el proceso de Looker. Los datos de esta base de datos se almacenan en el archivo <looker install directory>/.db/looker.script. Aunque es conveniente y ligera, esta base de datos experimenta problemas de rendimiento debido al uso intensivo. Por lo tanto, te recomendamos comenzar 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 MySQL debe ser de la versión 8.0.x y debe estar configurado para usar la codificación utf8mb4. Se debe usar el motor de almacenamiento de 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. Asígnale 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 no las desarrollaron ni probaron los equipos de ingeniería de Looker. Por lo tanto, la funcionalidad no está admitida o garantizada.
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 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 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 base de datos. Tanto los sistemas autoadministrados como algunos 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.
A fin de usar la réplica para las consultas de actividad del sistema, deberás crear una copia del archivo looker-db.yml (por ejemplo, looker-usage-db.yml), modificarlo para que apunte a la réplica y agregar 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 los parámetros de configuración necesarios para migrar la base de datos de backend de Looker a MySQL, los clústeres altamente 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].
Configura 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 configurar el grupo de búferes de InnoDB con el tamaño de la base de datos en lugar del 50% o más de 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úfer grande, podrían competir. Para evitar esto, el grupo de búferes se divide en unidades más pequeñas a las que pueden acceder diferentes subprocesos sin generar 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 la posibilidad de un cuello de botella. Se debe configurar innodb_buffer_pool_instances para 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 volver a reproducir. para aplicar los cambios. Escribir en el archivo de registro es una pequeña operación de anexo. 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. Para 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 registran las escrituras en el disco para no sobrecargar el servidor. Los valores predeterminados son conservadores para la mayoría de los servidores. Si deseas 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 los 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 de Linux sysbench es una forma de medirlo. Usa ese valor para innodb_io_capacity_max y un valor medio a tres cuartos 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 por cada cliente que se entregue. Si muchos clientes se conectan al mismo tiempo, se puede procesar una gran cantidad de subprocesos. Esto puede provocar que el sistema pase más tiempo intercambiando que procesando.
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, este valor es probable que 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 falla el servidor, no se perderá la transacción, pero el rendimiento de la base de datos se verá afectado. Establecer este valor en 0 o 2 puede mejorar el rendimiento, pero corre el riesgo de perder algunos segundos de las 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 único 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
Inhabilitar las estadísticas de los metadatos
Este parámetro de configuración inhabilita la recopilación de estadísticas en 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
Amplía la tabla temporal y los tamaños máximos de 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 fuerzan 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 para las tablas abiertas. La configuración table_open_cache_instances divide la caché en varias partes más pequeñas. Existe la posibilidad de que exista contención de subprocesos en table_open_cache, por lo que dividirla en partes más pequeñas ayudará 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 de LookML. Se admiten los principales servicios de hosting de Git, incluidos GitHub, GitLab y Bitbucket. Los proveedores de servicios de Git ofrecen valor agregado adicional, como una GUI para ver los cambios de código y compatibilidad con flujos de trabajo como las solicitudes de extracción y las 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. GitLab, en particular, suele ser autoalojado y se puede usar como producto de código abierto sin costo de licencia o como producto con licencia admitido. GitHub Enterprise está disponible como un servicio autoalojado y es un producto comercial admitido.
En las siguientes secciones, se enumeran las variaciones 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 Usa GitLab para el control de versión en Looker si quieres conocer los pasos de configuración detallados para GitLab. Si tu repositorio está contenido 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, hay tres formas diferentes de almacenar claves SSH generadas por Looker en GitLab: como una clave SSH de usuario, como una clave de implementación de repositorio o como una clave de implementación compartida global. Puedes encontrar una explicación más detallada en la documentación de GitLab.
Google Cloud Source
Consulta la publicación de Comunidad sobre cómo usar Cloud Source Repositories para el control de versión en Looker si quieres 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 production en Looker con la rama principal del repositorio.
Difusión de Phabricator
Si quieres conocer los pasos para configurar Git con Phabricator, consulta la publicación de Comunidad sobre cómo configurar Phabricator y Looker para el control de versiones.
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. El servidor de Looker se puede configurar de forma alternativa para que haga lo siguiente:
- Acepta conexiones HTTP de un proxy o balanceador de cargas de finalización de 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 pueda resolverse de forma local en la dirección IP del proxy. Looker solo aceptará conexiones HTTP de 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
Se suele usar 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á inactiva. Este socket se desconectará si la aplicación web del cliente se cierra o se desconecta de cualquier 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 de base de datos interna
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 la Internet pública. Por ejemplo, si usas BigQuery, es posible que accounts.google.com:443 y www.googleapis.com:443 deban agregarse 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 conocer los detalles de la red.
Servicios SMTP
De forma predeterminada, Looker envía correos electrónicos salientes con SendGrid. Es posible que debas agregar smtp.sendgrid.net:587 a una lista de entidades permitidas. En la configuración, se puede cambiar la configuración de SMTP para usar también un controlador de correo electrónico diferente.
Concentradores, servidores de acción y webhooks
Muchos destinos de 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, estos destinos se especifican en el entorno de ejecución por los usuarios y pueden ser contrarios al objetivo de usar un firewall de conexiones salientes.
- Para un centro de acciones, estas solicitudes se envían a
actions.looker.com. Encontrarás más detalles en nuestra documentación de configuración de Looker Action Hub. - Para otros servidores de acción, los administradores en el panel Administrador de Looker envían estas solicitudes a los dominios especificados en la configuración del servidor de acciones.
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 la 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.