En esta página se describen las prácticas habituales de componentes específicos de la arquitectura de Looker y se explica cómo configurarlos en una implementación.
Looker tiene varias dependencias para alojar el servidor, dar servicio a cargas de trabajo ad hoc y programadas, hacer un seguimiento del desarrollo iterativo de modelos, etc. En esta página, estas dependencias se denominan componentes, 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 Git
- Red
Configuración del host
SO y distribución
Looker funciona correctamente en las versiones más comunes de Linux: RedHat, SUSE y Debian/Ubuntu. Por lo general, no hay ningún problema con las derivadas de estas distribuciones que se diseñan y optimizan para ejecutarse en un entorno concreto. 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 con las que el equipo de Asistencia de Looker está más familiarizado. Lo más fácil es usar Debian o Ubuntu, o un sistema operativo de un proveedor de servicios en la nube específico que se derive de Debian o Ubuntu.
Looker se ejecuta en la máquina virtual Java (JVM). Al elegir una distribución, comprueba si las versiones de OpenJDK 11 están actualizadas. Es posible que las distribuciones anteriores de Linux puedan ejecutar Looker, pero la versión de Java y las bibliotecas que Looker requiere para determinadas funciones deben estar actualizadas. Si la JVM no contiene todas las bibliotecas y versiones recomendadas de Looker, Looker no funcionará correctamente. Looker requiere Java HotSpot 1.8 update 161 o una versión posterior, o Java OpenJDK 11.0.12 o una versión posterior.
CPU y memoria
Los nodos 4x16 (4 CPUs y 16 GB de RAM) son suficientes para un sistema de desarrollo o una instancia de Looker de prueba básica que utilice un equipo pequeño. Sin embargo, para la producción, esto no suele ser suficiente. Según nuestra experiencia, 16 nodos de 64 (16 CPUs y 64 GB de RAM) ofrecen un buen equilibrio entre precio y rendimiento. Si se supera el límite de 64 GB de RAM, el rendimiento puede verse afectado, ya que los eventos de recogida de elementos no utilizados se ejecutan en un solo proceso y detienen todos los demás procesos.
Almacenamiento en disco
Normalmente, 100 GB de espacio en disco son más que suficientes para un sistema de producción.
Consideraciones sobre los clústeres
Looker se ejecuta en una JVM de Java, y Java puede tener dificultades para gestionar una memoria superior a 64 GB. Por lo general, si necesitas más capacidad, debes añadir nodos 16x64 al clúster en lugar de aumentar el tamaño de los nodos a más de 16x64. También podemos preferir usar una arquitectura en clúster para aumentar la disponibilidad.
En un clúster, los nodos de Looker deben compartir determinadas partes del sistema de archivos. Los datos compartidos incluyen lo siguiente:
- Modelos de LookML
- Los modelos de LookML de desarrollador
- Conectividad del servidor Git
Dado que el sistema de archivos se comparte y aloja varios repositorios de Git, es fundamental gestionar el acceso simultáneo y el bloqueo de archivos. El sistema de archivos debe cumplir el estándar POSIX. Se sabe que el sistema de archivos de red (NFS) funciona y está disponible en Linux. Deberías crear una instancia de Linux adicional y configurar NFS para compartir el disco. El sistema NFS predeterminado puede ser un punto único de fallo, por lo que te recomendamos que utilices una configuración de conmutación por error o de alta disponibilidad.
Los metadatos de Looker también deben centralizarse, por lo que su base de datos interna debe migrarse a MySQL. Puede ser un servicio MySQL o una implementación de MySQL dedicada. En la sección Base de datos interna (backend) de esta página se explica con más detalle.
Configuración de JVM
Los ajustes de JVM de Looker se definen en la secuencia de comandos de inicio de Looker. Después de cualquier actualización, Looker debe reiniciarse para que los cambios se manifiesten. 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
Los ajustes de recursos se definen en la secuencia de comandos de inicio de Looker.
JAVAMEM="2300m" METAMEM="800m"
La asignación de memoria de la JVM debe tener en cuenta la sobrecarga del sistema operativo en el que se ejecuta Looker. Por lo general, se puede asignar a la JVM hasta el 60% de la memoria total, pero hay excepciones en función del tamaño de la máquina. En el caso de las máquinas con el mínimo de 8 GB de memoria total, recomendamos asignar entre 4 y 5 GB a Java y 800 MB a Meta. En el caso de las máquinas más grandes, se puede asignar una proporción menor de memoria al sistema operativo. Por ejemplo, en el caso de las máquinas con 60 GB de memoria total, recomendamos asignar 36 GB a Java y 1 GB a Meta. Es importante tener en cuenta que la asignación de memoria de Java suele escalarse 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 renderizar, la cantidad de memoria asignada a Java debe seleccionarse en el contexto de la carga de renderización prevista y el tamaño de la máquina. Si se espera que la carga de renderización sea baja, se puede asignar a Java una mayor parte de la memoria total. Por ejemplo, en una máquina con 60 GB de memoria total, se podrían asignar 46 GB a Java de forma segura, lo que supera la recomendación general del 60 %. Las asignaciones de recursos exactas adecuadas para cada implementación varían, por lo que te recomendamos que utilices el 60% como valor de referencia y que lo ajustes según el uso.
Recolección de memoria residual
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 recogida 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, el tiempo de espera de la recolección de elementos no utilizados podría reducirse.
Registros
De forma predeterminada, los registros de recolección de elementos no utilizados de Looker se almacenan en /tmp/gc.log. Para cambiarlo, edita la siguiente opción en la configuración de inicio:
-Xloggc:/tmp/gc.log
JMX
Para gestionar Looker, puede que sea necesario monitorizarlo para optimizar los recursos. Te recomendamos que uses JMX para monitorizar el uso de memoria de la JVM.
Opciones de inicio de Looker
Las opciones de inicio se almacenan en un archivo llamado lookerstart.cfg. Este archivo se obtiene del archivo de shell que inicia Looker.
Grupos de hilos
Como aplicación multihilo, Looker tiene varios grupos de hilos. 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. En función de los flujos de trabajo de tu empresa, es posible que tengas que modificar estos grupos a partir de la configuración predeterminada. En concreto, hay consideraciones especiales para las topologías de clúster mencionadas en la página Patrones y prácticas de la arquitectura de infraestructura alojada por el cliente.
Opciones de alto rendimiento de programación
En todos los nodos que no sean de programación, añade --scheduler-threads=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Sin los subprocesos del programador, no se ejecutará ninguna tarea programada en estos nodos.
En todos los nodos de programador dedicados, añade --scheduler-threads=<n> a la variable de entorno LOOKERARGS en lookerstart.cfg. Looker empieza con 10 hilos de programación de forma predeterminada, pero este número se puede aumentar a <n>. Con <n> hilos de programación, cada nodo podrá ejecutar <n> trabajos de programación simultáneos. Por lo general, se recomienda que <n> sea inferior al doble del número de CPUs. El host más grande recomendado tiene 16 CPUs y 64 GB de memoria, por lo que el límite superior de los subprocesos del programador debe ser inferior a 32.
Opciones de alto rendimiento de renderización
En todos los nodos que no sean de renderización, añade --concurrent-render-jobs=0 a la variable de entorno LOOKERARGS en lookerstart.cfg. Si no hay nodos de renderizado, no se ejecutará ningún trabajo de renderizado en estos nodos.
En todos los nodos de renderización dedicados, añade --concurrent-render-jobs=<n> a la variable de entorno LOOKERARGS en lookerstart.cfg. Looker empieza con dos subprocesos de renderización de forma predeterminada, pero este número se puede aumentar a <n>. Con <n> subprocesos de renderización, cada nodo podrá ejecutar <n> trabajos de renderización simultáneos.
Cada trabajo de renderización puede usar una cantidad de memoria considerable. Calcula unos 2 GB por tarea de renderizado. Por ejemplo, si al proceso principal de Looker (Java) se le asigna el 60% de la memoria total y se reserva el 20% de la memoria restante para el sistema operativo, queda el 20% para los trabajos de renderización. En un ordenador con 64 GB, quedan 12 GB, lo que es suficiente para 6 tareas de renderizado simultáneas. Si un nodo se dedica al renderizado y no se incluye en el grupo del balanceador de carga que gestiona los trabajos interactivos, la memoria del proceso principal de Looker se puede reducir para permitir más trabajos de renderizado. En una máquina de 64 GB, se podría asignar aproximadamente el 30% (20 GB) al proceso principal de Looker. Si se reserva un 20% para el uso general del SO, queda un 50% (32 GB) para el renderizado, lo que es suficiente para 16 tareas de renderizado simultáneas.
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, Looks y paneles definidos por el usuario, y otros datos en una base de datos interna.
En una instancia de Looker independiente de tamaño moderado, estos datos se almacenan en una base de datos HyperSQL en memoria insertada en el propio proceso de Looker. Los datos de esta base de datos se almacenan en el archivo <looker install directory>/.db/looker.script. Aunque es cómoda y ligera, esta base de datos tiene problemas de rendimiento cuando se usa mucho. Por lo tanto, te recomendamos que empieces con una base de datos MySQL remota. Si no es posible, te recomendamos que migres a una base de datos MySQL remota cuando el archivo ~/looker/.db/looker.script alcance los 600 MB. Los clústeres deben usar una base de datos MySQL.
El servidor de Looker realiza muchas lecturas y escrituras pequeñas en la base de datos MySQL. Cada vez que un usuario ejecuta un look o una exploración, Looker comprueba la base de datos para verificar que el usuario sigue conectado, que tiene privilegios para acceder a los datos y para ejecutar el look o la exploración, etc. Looker también escribirá datos en la base de datos MySQL, como el SQL real que se ejecutó y la hora en la que se inició y finalizó la solicitud. Una sola interacción entre un usuario y la aplicación Looker puede dar lugar a entre 15 y 20 lecturas y escrituras pequeñas en la base de datos MySQL.
MySQL
El servidor MySQL debe ser de 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 a MySQL, están disponibles en la página de documentación Migrar la base de datos backend de Looker a MySQL.
Cuando se configura 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 añade el ajuste -d looker-db.yml en la sección LOOKERARGS del archivo lookerstart.cfg.
MariaDB
MySQL tiene una licencia dual, por lo que está disponible tanto como software libre como producto comercial. Oracle ha seguido mejorando MySQL, que se ha bifurcado 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 han desarrollado ni probado. Por lo tanto, no se admite ni se garantiza su funcionalidad.
Versiones de Cloud
Si alojas Looker en tu infraestructura de nube, lo lógico es que alojes la base de datos MySQL en la misma infraestructura. Los tres principales proveedores de servicios en la nube: Amazon AWS, Microsoft Azure y Google Cloud. Los proveedores de servicios en la nube gestionan gran parte del mantenimiento y la configuración de la base de datos MySQL, y ofrecen servicios como la gestión de copias de seguridad y la recuperación rápida. Se sabe que estos productos funcionan bien con Looker.
Consultas de actividad del sistema
La base de datos MySQL se usa para almacenar información sobre cómo usan Looker los usuarios. Cualquier usuario de Looker que tenga permiso para ver el modelo Actividad del sistema tiene acceso a varios paneles de Looker prediseñados para analizar estos datos. Los usuarios también pueden acceder a Exploraciones de metadatos de Looker para crear análisis adicionales. La base de datos MySQL se usa principalmente para consultas pequeñas, rápidas y "operativas". Las consultas grandes y lentas de "analíticas" que genera el modelo Actividad del sistema pueden competir con estas consultas operativas y ralentizar Looker.
En estos casos, la base de datos MySQL se puede replicar en otra base de datos. Tanto los sistemas autogestionados como algunos gestionados en la nube ofrecen una configuración básica de la réplica en otras bases de datos. La configuración de la replicación no se trata en este documento.
Para usar la réplica en 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 añadirás el ajuste --internal-analytics-connection-file looker-usage-db.yml
a la sección LOOKERARGS del archivo lookerstart.cfg.
Las consultas de actividad del sistema se pueden ejecutar en una instancia de MySQL o en una base de datos de Google BigQuery. No se prueban con otras bases de datos.
Configuración del rendimiento de MySQL
Además de los ajustes necesarios para migrar la base de datos backend de Looker a MySQL, los clústeres con mucha actividad pueden beneficiarse de ajustes y configuraciones adicionales. Estos ajustes se pueden realizar en el archivo /etc/my.cnf o a través de la consola Google Cloud en las instancias gestionadas en la nube.
El archivo de configuración my.cnf se divide en varias partes. Los cambios en la configuración que se describen en esta sección se realizan en la parte [mysqld].
Definir el tamaño del grupo de búferes de InnoDB
El tamaño del grupo de búferes de InnoDB es la cantidad total de RAM 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 debe configurarse 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 puede definir el tamaño del grupo de búferes de InnoDB como el tamaño de la base de datos en lugar de un 50% o más de la memoria.
En este ejemplo, un servidor tiene 64 GB de memoria, por lo que el grupo de búferes de InnoDB debe tener entre 32 y 45 GB. Por lo general, cuanto más grande sea, mejor.
[mysqld] ... innodb_buffer_pool_size=45G
Definir las instancias del grupo de búferes de InnoDB
Cuando varios subprocesos intentan buscar en un grupo de búferes grande, pueden producirse conflictos. Para evitarlo, el grupo de búfer se divide en unidades más pequeñas a las que pueden acceder diferentes subprocesos sin que haya conflictos. De forma predeterminada, el grupo de búferes se divide en 8 instancias. Esto crea un posible cuello de botella de 8 hilos. Aumentar el número de instancias del pool de búfer reduce la probabilidad de que se produzca un cuello de botella. El valor de innodb_buffer_pool_instances debe ser tal que cada grupo de búferes obtenga al menos 1 GB de memoria.
[mysqld] ... innodb_buffer_pool_instances=32
Optimizar el archivo de registro de InnoDB
Cuando se confirma una transacción, la base de datos tiene la opción de actualizar los datos del archivo o de guardar los detalles de la transacción en el registro. Si la base de datos falla antes de que se actualicen los archivos de datos, el archivo de registro se puede "reproducir" para aplicar los cambios. Escribir en el archivo de registro es una pequeña operación de anexión. Es eficiente añadir datos al registro en el momento de la confirmación y, a continuación, agrupar varios cambios en los archivos de datos y escribirlos en una sola operación de E/S. Cuando el archivo de registro se llena, la base de datos tiene que pausar el procesamiento de las nuevas transacciones y escribir todos los datos modificados en el disco.
Por lo general, el archivo de registro de InnoDB debe ser lo suficientemente grande como para contener una hora de transacciones.
Normalmente, hay dos archivos de registro de InnoDB. Deberían ocupar aproximadamente el 25% de tu grupo de búferes de InnoDB. En el caso de una base de datos de ejemplo con un grupo de búferes de 32 GB, los archivos de registro de InnoDB deberían sumar 8 GB, es decir, 4 GB por archivo.
[mysqld] ... innodb_log_file_size=8GB
Configurar la capacidad de E/S de InnoDB
MySQL limitará la velocidad a la que se registran las escrituras en el disco para no sobrecargar el servidor. Los valores predeterminados son conservadores para la mayoría de los servidores. Para obtener el mejor rendimiento, usa la utilidad sysbench para medir la velocidad de escritura aleatoria en el disco de datos y, a continuación, usa ese valor para configurar la capacidad de E/ de forma que MySQL escriba los datos más rápido.
En un sistema alojado en la nube, el proveedor de la nube debería poder informar del rendimiento de los discos utilizados para el almacenamiento de datos. En el caso de un servidor MySQL autogestionado, 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 en innodb_io_capacity_max y un valor entre la mitad y las tres cuartas partes de ese valor en 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
Configurar los hilos de InnoDB
MySQL abrirá al menos un hilo por cada cliente al que se le preste servicio. Si muchos clientes se conectan simultáneamente, se pueden procesar una gran cantidad de hilos. Esto puede provocar que el sistema dedique más tiempo a intercambiar datos que a procesarlos.
Se deben realizar pruebas comparativas para determinar el número ideal de subprocesos. Para hacer pruebas, define el número de subprocesos entre el número de CPUs (o núcleos de CPU) del sistema y cuatro veces el número de CPUs. En un sistema de 16 núcleos, este valor suele estar entre 16 y 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilidad de las transacciones
Si el valor de la transacción es 1, MySQL se ve obligado a escribir en el disco en cada transacción. Si el servidor falla, la transacción no se perderá, pero el rendimiento de la base de datos se verá afectado. Si se asigna el valor 0 o 2, se puede mejorar el rendimiento, pero se corre el riesgo de perder datos de transacciones de un par de segundos.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Definir el método flush
Normalmente, el sistema operativo almacena en búfer las escrituras en el disco. Como MySQL y el SO almacenan datos en búfer, el rendimiento se ve afectado. Si se reduce el método de vaciado en una capa de almacenamiento en búfer, se 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. La opción innodb_file_per_table creará un archivo independiente para cada tabla, lo que mejorará el rendimiento y la gestión de los datos.
[mysqld] ... innodb_file_per_table=ON
Inhabilitar las estadísticas de los metadatos
Este ajuste inhabilita la recogida 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 consulta
La caché de consultas está obsoleta, por lo que, si asignas el valor 0 a query_cache_size y query_cache_type, se inhabilita.
[mysqld] ... query_cache_size=0 query_cache_type=0
Ampliar el búfer de unión
El join_buffer se usa para realizar combinaciones en la memoria. Si lo aumentas, puedes mejorar algunas operaciones.
[mysqld] ... join_buffer_size=512KB
Aumentar el tamaño de la tabla temporal y el tamaño máximo del montículo
tmp_table_size y max_heap_table_size definen valores predeterminados razonables para las tablas temporales en memoria antes de que se escriban en el disco.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajustar la caché de apertura de tablas
El ajuste table_open_cache determina el tamaño de la caché que contiene los descriptores de archivo de las tablas abiertas. El ajuste table_open_cache_instances divide la caché en varias partes más pequeñas. Existe la posibilidad de que se produzcan conflictos de subprocesos en el 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 se ha diseñado para funcionar con un servicio de Git que proporcione gestión de versiones de los archivos LookML. Se admiten los principales servicios de alojamiento de Git, como GitHub, GitLab y Bitbucket. Los proveedores de servicios de Git ofrecen ventajas adicionales, como una interfaz gráfica de usuario para ver los cambios en el 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 normal.
Si un servicio de alojamiento 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 concreto, GitLab suele alojarse de forma local y se puede usar como producto de código abierto sin coste de licencia o como producto con licencia y asistencia. GitHub Enterprise está disponible como servicio autohospedado y es un producto comercial compatible.
En las siguientes secciones se enumeran los matices de los proveedores de servicios más habituales.
GitHub o GitHub Enterprise
En la página de documentación Configurar y probar una conexión Git se usa GitHub como ejemplo.
GitLab/gitlab.com
Consulta la publicación de la comunidad de Looker Using GitLab for version control in Looker (Usar GitLab para el control de versiones en Looker) para ver los pasos detallados de configuración de GitLab. Si tu repositorio está incluido en subgrupos, estos se pueden añadir a la URL del repositorio mediante 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 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 compartida global. Puedes consultar una explicación más detallada en la documentación de GitLab.
Google Cloud Fuente
Consulta la publicación de la comunidad sobre cómo usar Cloud Source Repositories para el control de versiones en Looker para ver los pasos que debes seguir para configurar Git con Cloud Source Repositories.
Bitbucket Cloud
Consulta la publicación de la comunidad sobre cómo usar Bitbucket para el control de versiones en Looker para ver los pasos que debes seguir para configurar Git con Bitbucket Cloud. Desde agosto del 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 tengas que seguir estos pasos:
- Cuando abres una solicitud de extracción, Looker usa automáticamente el número de puerto predeterminado (7999) en la URL. Si utilizas un número de puerto personalizado, tendrás que sustituirlo manualmente en la URL.
- Deberá acceder al webhook de implementación del proyecto para sincronizar la rama de producción de Looker con la rama principal del repositorio.
Difusión de Phabricator
Consulta la publicación de la comunidad sobre cómo configurar Phabricator y Looker para el control de versiones para ver los pasos que debes seguir para configurar Git con Phabricator.
Red
Conexiones entrantes
Aplicación web de Looker
De forma predeterminada, Looker recibe solicitudes HTTPS en el puerto 9999. Looker usa un certificado autofirmado con el CN self-signed.looker.com. El servidor de Looker también se puede configurar para hacer lo siguiente:
- Acepta conexiones HTTP de un balanceador de carga o proxy de terminación SSL con la
--ssl-provided-externally-by=<s>marca de inicio. El valor debe ser la dirección IP del proxy o un nombre de host que se pueda resolver localmente en la dirección IP del proxy. Looker solo aceptará conexiones HTTP desde esta dirección IP. - Usa un certificado SSL proporcionado por el cliente con la marca de inicio
--ssl-keystore=<s>.
API de Looker
La API de Looker escucha en el puerto 19999. Si la instalación requiere acceso a la API, el balanceador de carga debe tener las reglas de reenvío necesarias. Se aplican las mismas consideraciones sobre SSL que en la aplicación web principal. Te recomendamos que uses un puerto distinto del de la aplicación web.
Balanceadores de carga
Los balanceadores de carga se suelen usar para aceptar una solicitud HTTPS en el puerto 443 mediante el certificado del cliente y, a continuación, reenviar la solicitud al nodo del servidor de Looker en el puerto 9999 mediante el certificado autofirmado o HTTP. Si los balanceadores de carga 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, puede dar lugar a una consulta que sea costosa de ejecutar en la base de datos. Si el usuario abandona esa solicitud de alguna forma (por ejemplo, cerrando la tapa de su portátil, desconectándose de la red o cerrando esa pestaña en el navegador), Looker quiere saberlo y finalizar esa consulta de base de datos.
Para gestionar esta situación, cuando la aplicación web cliente hace una solicitud para ejecutar una consulta de 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 e inactiva. Este socket se desconectará si la aplicación web del cliente se cierra o se desconecta de alguna forma. El servidor detectará la desconexión y cancelará las consultas de bases de datos relacionadas.
Los balanceadores de carga suelen detectar estas conexiones inactivas abiertas y las cierran. Para que Looker funcione correctamente, el balanceador de carga debe configurarse para que esta conexión permanezca abierta durante el tiempo que dure la consulta más larga que pueda ejecutar un usuario. Se recomienda un tiempo de espera de al menos 60 minutos.
Conexiones salientes
Los servidores de Looker pueden tener acceso de salida sin restricciones a todos los recursos, incluido Internet público. Esto simplifica muchas tareas, como la instalación de Chromium, que requiere acceso a los repositorios de paquetes de la distribución de Linux.
A continuación, se indican las conexiones salientes que puede que Looker necesite establecer.
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 con MySQL en este puerto. En función de cómo se aloje el repositorio, es posible que tengas que atravesar un cortafuegos.
Servicios externos
Los servidores de telemetría y licencias de Looker están disponibles a través de HTTPS en la red pública de Internet. Es posible que deba añadir a una lista de permitidos el tráfico de un nodo de Looker a ping.looker.com:443 y license.looker.com:443.
Conexiones de almacén de datos
Las bases de datos alojadas en la nube pueden requerir una conexión a través de Internet pública. Por ejemplo, si usas BigQuery, es posible que tengas que añadir accounts.google.com:443 y www.googleapis.com:443 a una lista de permitidos. Si la base de datos está fuera de tu infraestructura, consulta los detalles de la red con tu proveedor de alojamiento de bases de datos.
Servicios SMTP
De forma predeterminada, Looker envía el correo saliente mediante SendGrid. Para ello, puede que tengas que añadir smtp.sendgrid.net:587 a una lista de permitidos. También se pueden cambiar los ajustes de SMTP en la configuración para usar otro gestor de correo.
Centros de acciones, servidores de acciones y webhooks
Muchos destinos de programación, 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 en el tiempo de ejecución, lo que puede ir en contra del objetivo de proteger las conexiones salientes con un cortafuegos.
- En el caso de un centro de actividades, estas solicitudes se envían a
actions.looker.com. Puedes consultar los detalles en nuestra documentación de configuración de Action Hub de Looker. - En el caso de otros servidores de acciones, los administradores envían estas solicitudes a los dominios especificados en la configuración del servidor de acciones desde el panel Administración de Looker.
Servidor proxy
Si no se puede acceder directamente a Internet público, Looker se puede configurar para que use un servidor proxy en las solicitudes HTTP(S). Para ello, añada 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 utilizas un servidor proxy y tu instancia está agrupada en clústeres, normalmente querrás añadir las IPs o los nombres de host de todos los nodos del clúster al argumento Dhttp.nonProxyHosts.
Comunicaciones entre nodos
Identificador de host interno
En un clúster, cada nodo debe poder comunicarse con los demás nodos. Para permitirlo, el nombre de host o la dirección IP de cada nodo se especifican en la configuración de inicio. Cuando se inicie el nodo, este valor se escribirá en el repositorio de MySQL. Otros miembros del clúster pueden hacer referencia a esos valores para comunicarse con este nodo. Para especificar el nombre de host o la dirección IP en la configuración de inicio, añade -H node1.looker.example.com a la variable de entorno LOOKERARGS en lookerstart.cfg.
Como el nombre de host debe ser único por nodo, el archivo lookerstart.cfg debe ser único en cada instancia. Como alternativa a la codificación del nombre de host o la dirección IP, se pueden usar los comandos hostname -I o hostname --fqdn para encontrarlos en tiempo de ejecución. Para implementar esta función, añade -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 APIs, respectivamente, los nodos del clúster se comunicarán entre sí a través de un servicio de intermediario de mensajes, que usa los puertos 1551 y 61616. Los puertos 9999 y 19999 deben estar abiertos al tráfico de usuarios finales, pero los puertos 1551 y 61616 deben estar abiertos entre los nodos del clúster.