Agrupamiento de Looker

En este instructivo, se explica el método recomendado para crear una configuración de Looker agrupada en clústeres para instancias alojadas por el cliente.

Descripción general

Las implementaciones de Looker alojadas por el cliente pueden ejecutar un solo nodo o estar agrupadas en clústeres:

• Una aplicación de Looker de un solo nodo, la configuración predeterminada, tiene todos los servicios que componen la aplicación de Looker que se ejecutan en un solo servidor.
• Una configuración de Looker agrupada en clústeres es una configuración más compleja que, por lo general, incluye servidores de bases de datos, balanceadores de cargas y varios servidores que ejecutan la aplicación de Looker. Cada nodo de una aplicación de Looker agrupada en clústeres es un servidor que ejecuta una sola instancia de Looker.

Hay dos motivos principales por los que una organización querría ejecutar Looker como un clúster:

• Balanceo de cargas
• Mejora de la disponibilidad y la conmutación por error

Según los problemas de escalamiento, es posible que un Looker agrupado en clústeres no proporcione la solución. Por ejemplo, si una pequeña cantidad de consultas grandes usan la memoria del sistema, la única solución es aumentar la memoria disponible para el proceso de Looker.

Alternativas de balanceo de cargas

Antes de balancear las cargas de Looker, considera aumentar la memoria y, posiblemente, la cantidad de CPU de un solo servidor que ejecuta Looker. Looker recomienda configurar la supervisión detallada del rendimiento para el uso de la memoria y la CPU para garantizar que el servidor de Looker tenga el tamaño adecuado para su carga de trabajo.

Las consultas grandes necesitan más memoria para un mejor rendimiento. El agrupamiento en clústeres puede proporcionar ganancias de rendimiento cuando muchos usuarios ejecutan consultas pequeñas.

Para las configuraciones con hasta 50 usuarios que usan Looker con poca frecuencia, Looker recomienda ejecutar un solo servidor en el equivalente a una instancia de AWS EC2 de tamaño grande (M4.large: 8 GB de RAM, 2 núcleos de CPU). Para las configuraciones con más usuarios o muchos usuarios activos avanzados, observa si la CPU tiene picos o si los usuarios notan lentitud en la aplicación. Si es así, mueve Looker a un servidor más grande o ejecuta una configuración de Looker agrupada en clústeres.

Mejora de la disponibilidad y la conmutación por error

Ejecutar Looker en un entorno agrupado en clústeres puede mitigar el tiempo de inactividad en caso de una interrupción. La alta disponibilidad es especialmente importante si la API de Looker se usa en sistemas empresariales centrales o si Looker está incorporado en productos orientados al cliente.

En una configuración de Looker agrupada en clústeres, un servidor proxy o un balanceador de cargas redireccionará el tráfico cuando determine que un nodo está inactivo. Looker controla automáticamente los nodos que abandonan el clúster y se unen a él.

Componentes obligatorios

Se requieren los siguientes componentes para una configuración de Looker agrupada en clústeres:

• Base de datos de aplicaciones de MySQL
• Nodos de Looker (servidores que ejecutan el proceso de Java de Looker)
• Balanceador de cargas
• Sistema de archivos compartido
• Versión adecuada de los archivos JAR de la aplicación de Looker

En el siguiente diagrama, se ilustra cómo interactúan los componentes. En un nivel superior, un balanceador de cargas distribuye el tráfico de red entre los nodos de Looker agrupados en clústeres. Cada nodo se comunica con una base de datos de aplicaciones de MySQL compartida, un directorio de almacenamiento compartido y los servidores de Git para cada proyecto de LookML.

Base de datos de aplicaciones de MySQL

Looker usa una base de datos de aplicaciones (a menudo llamada base de datos interna) para almacenar datos de aplicaciones. Cuando Looker se ejecuta como una aplicación de un solo nodo, normalmente usa una base de datos HyperSQL en la memoria.

En una configuración de Looker agrupada en clústeres, la instancia de Looker de cada nodo debe apuntar a una base de datos transaccional compartida (la aplicación compartida o la base de datos interna). La compatibilidad con la base de datos de aplicaciones para Looker agrupado en clústeres es la siguiente:

• Solo se admite MySQL para la base de datos de aplicaciones para instancias de Looker agrupadas en clústeres. No se admiten Amazon Aurora ni MariaDB.
• Se admiten las versiones 5.7+ y 8.0+ de MySQL.
• No se admiten bases de datos agrupadas en clústeres, como Galera.

Nota: Se recomienda una base de datos de réplica de lectura para mejorar el rendimiento y la redundancia. Tu base de datos de réplica de lectura no necesita ser una base de datos de MySQL.

Looker no administra el mantenimiento ni las copias de seguridad de esa base de datos. Sin embargo, como la base de datos aloja casi todos los datos de configuración de la aplicación de Looker, se debe aprovisionar como una base de datos de alta disponibilidad y se debe realizar una copia de seguridad al menos una vez al día.

Nodos de Looker

Cada nodo es un servidor con el proceso de Java de Looker en ejecución. Los servidores del clúster de Looker deben poder comunicarse entre sí y con la base de datos de aplicaciones de Looker. Los puertos predeterminados se enumeran en Abre los puertos para que los nodos se comuniquen en esta página.

Balanceador de cargas

Para balancear la carga o redireccionar las solicitudes a los nodos disponibles, se requiere un balanceador de cargas o un servidor proxy (por ejemplo, NGINX o AWS ELB) para dirigir el tráfico a cada nodo de Looker. El balanceador de cargas controla las verificaciones de estado. En caso de falla de un nodo, el balanceador de cargas debe configurarse para redireccionar el tráfico a los nodos restantes en buen estado.

Cuando elijas y configures el balanceador de cargas, asegúrate de que se pueda configurar para que opere solo como capa 4. Amazon Classic ELB es un ejemplo. Además, el balanceador de cargas debe tener un tiempo de espera largo (3,600 segundos) para evitar que se eliminen las consultas.

Sistema de archivos compartido

Debes usar un sistema de archivos compartido compatible con POSIX (como NFS, AWS EFS, Gluster, BeeGFS, Lustre o muchos otros). Looker usa el sistema de archivos compartido como un repositorio para varias partes de la información que usan todos los nodos del clúster.

Nota: Para instalar aplicaciones y herramientas desde Looker Marketplace, se requiere el uso de un sistema de archivos compartido (de red).

Aplicación de Looker (JAR ejecutable)

Debes usar un archivo JAR de la aplicación de Looker que sea Looker 3.56 o una versión posterior.

Nota: A partir de Looker 6.18, el archivo JAR de Looker se dividió en dos archivos JAR separados: el archivo JAR principal de Looker y un archivo JAR de dependencias de Looker. Si instalas o actualizas a Looker 6.18 o una versión posterior, asegúrate de descargar ambos archivos JAR.

Looker recomienda que cada nodo de un clúster ejecute la misma versión de lanzamiento y parche de Looker, como se explica en Inicia Looker en los nodos de esta página.

Configura el clúster

Se requieren las siguientes tareas:

1. Instala Looker.
2. Configura una base de datos de aplicaciones de MySQL.
3. Configura el sistema de archivos compartido.
4. Comparte el repositorio de claves SSH (según tu situación).
5. Abre los puertos para que los nodos se comuniquen.
6. Inicia Looker en los nodos.

Instala Looker

Asegúrate de tener Looker instalado en cada nodo con los archivos JAR de la aplicación de Looker y las instrucciones de la página de documentación Pasos de instalación alojados por el cliente.

Configura una base de datos de aplicaciones de MySQL

Para una configuración de Looker agrupada en clústeres, la base de datos de aplicaciones debe ser una base de datos de MySQL. Si tienes una instancia de Looker existente que no está agrupada en clústeres y que usa HyperSQL para la base de datos de aplicaciones, debes migrar los datos de la aplicación de los datos de HyperSQL a tu nueva base de datos de aplicaciones de MySQL compartida.

Nota: Asegúrate de hacer una copia de seguridad de tu directorio de Looker. El proceso de migración solo puede ir de una base de datos HyperSQL a una base de datos de MySQL, no al revés.

Consulta la página de documentación Migra a MySQL para obtener información sobre cómo hacer una copia de seguridad de Looker y, luego, migrar la base de datos de aplicaciones de HyperSQL a MySQL.

Configura el sistema de archivos compartido

Solo los tipos de archivos específicos (archivos de modelo, claves de implementación, complementos y, posiblemente, archivos de manifiesto de la aplicación) pertenecen al sistema de archivos compartido. Para configurar el sistema de archivos compartido, haz lo siguiente:

1. En el servidor que almacenará el sistema de archivos compartido, verifica que tengas acceso a otra cuenta que pueda su a la cuenta de usuario de Looker.
2. En el servidor del sistema de archivos compartido, accede a la cuenta de usuario de Looker.
3. Si Looker está en ejecución, apaga tu configuración de Looker.
4. Si antes agrupabas en clústeres con secuencias de comandos de Linux inotify, detén esas secuencias de comandos, quítalas de cron y bórralas.
5. Crea un recurso compartido de red y actívalo en cada nodo del clúster. Asegúrate de que esté configurado para activarse automáticamente en cada nodo y de que el usuario de Looker pueda leerlo y escribir en él. En el siguiente ejemplo, el recurso compartido de red se llama /mnt/looker-share.

6. En un nodo, copia tus claves de implementación y mueve tus complementos y los directorios looker/models y looker/models-user-*, que almacenan tus archivos de modelo, a tu recurso compartido de red. Por ejemplo:

   mv looker/models /mnt/looker-share/
   mv looker/models-user-* /mnt/looker-share/
   

   Nota: Tus claves de implementación deben copiarse en el almacenamiento compartido y en cada nodo del clúster.

7. Para cada nodo, agrega el parámetro de configuración --shared-storage-dir a LOOKERARGS. Especifica el recurso compartido de red, como se muestra en este ejemplo:

   --shared-storage-dir /mnt/looker-share
   

   LOOKERARGS se debe agregar a $HOME/looker/lookerstart.cfg para que la configuración no se vea afectada por las actualizaciones. Si tus LOOKERARGS no aparecen en ese archivo, es posible que alguien los haya agregado directamente a la secuencia de comandos de shell $HOME/looker/looker.

   Cada nodo del clúster debe escribir en un directorio /log único o, al menos, en un archivo de registro único.

Comparte el repositorio de claves SSH

• Estás creando un clúster de sistema de archivos compartido a partir de una configuración de Looker existente.
• Tienes proyectos que se crearon en Looker 4.6 o versiones anteriores.

Nota: El siguiente procedimiento requiere modificar el directorio $HOME/.ssh del usuario de Looker. Esto puede dificultar el acceso y la solución de problemas si hay errores en la configuración. Antes de realizar estos pasos, asegúrate de tener acceso a otra cuenta que pueda su a la cuenta de usuario de Looker.

Configura el repositorio de claves SSH para que se comparta:

1. En el servidor de archivos compartidos, crea un directorio llamado ssh-share. Por ejemplo: /mnt/looker-share/ssh-share.

   Asegúrate de que el directorio ssh-share sea propiedad del usuario de Looker y que los permisos sean 700. Además, asegúrate de que los directorios que están sobre el directorio ssh-share (como /mnt y /mnt/looker-share) no se puedan escribir en el mundo ni en el grupo.

2. En un nodo, copia el contenido de $HOME/.ssh en el nuevo directorio ssh-share. Por ejemplo:

   cp $HOME/.ssh/* /mnt/looker-share/ssh-share

3. Para cada nodo, haz una copia de seguridad del archivo SSH existente y crea un vínculo simbólico al directorio ssh-share. Por ejemplo:

   cd $HOME
   mv .ssh .ssh_bak
   ln -s /mnt/looker-share/ssh-share .ssh
   

   Asegúrate de realizar este paso para cada nodo.

Abre los puertos para que los nodos se comuniquen

Los nodos de Looker agrupados en clústeres se comunican entre sí a través de HTTPS con certificados autofirmados y un esquema de autenticación adicional basado en secretos rotativos en la base de datos de aplicaciones.

Los puertos predeterminados que deben estar abiertos entre los nodos del clúster son 1551 y 61616. Estos puertos se pueden configurar con las marcas de inicio que se indican aquí. Te recomendamos que restrinjas el acceso a la red a estos puertos para permitir el tráfico solo entre los hosts del clúster.

Inicia Looker en los nodos

Reinicia el servidor en cada nodo con las marcas de inicio requeridas.

Nota: Cada nodo de un clúster debe ejecutar la misma versión de lanzamiento y parche de Looker.

Marcas de inicio disponibles

En la siguiente tabla, se muestran las marcas de inicio disponibles, incluidas las marcas que se requieren para iniciar un clúster o unirse a él:

Marcar	¿Es obligatorio?	Valores	Objetivo
--clustered	Sí		Agrega una marca para especificar que este nodo se ejecuta en modo agrupado en clústeres.
-H o --hostname	Sí	10.10.10.10	El nombre de host que usan otros nodos para comunicarse con este nodo, como la dirección IP del nodo o su nombre de host del sistema. Debe ser diferente de los nombres de host de todos los demás nodos del clúster.
-n	No	1551	El puerto para la comunicación entre nodos. El valor predeterminado es 1551. Todos los nodos deben usar el mismo número de puerto para la comunicación entre nodos.
-q	No	61616	El puerto para poner en cola eventos en todo el clúster. El valor predeterminado es 61616.
-d	Sí	/path/to/looker-db.yml	La ruta al archivo que contiene las credenciales de la base de datos de aplicaciones de Looker.
--shared-storage-dir	Sí	/path/to/mounted/shared/storage	La opción debe apuntar al directorio compartido configurado anteriormente en esta página que contiene los directorios looker/model y looker/models-user-*.

Nota: Tu marca de inicio --clustered no debe incluir un valor.

Ejemplo de LOOKERARGS y especificación de credenciales de la base de datos

Coloca las marcas de inicio de Looker en un archivo lookerstart.cfg, ubicado en el mismo directorio que los archivos JAR de Looker.

Por ejemplo, es posible que quieras indicarle a Looker lo siguiente:

• Que use el archivo llamado looker-db.yml para sus credenciales de base de datos
• Que es un nodo agrupado en clústeres
• Que los otros nodos del clúster deben comunicarse con este host en la dirección IP 10.10.10.10

Especificarías lo siguiente:

LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"

Nota: Asegúrate de especificar la dirección IP correcta para tu nodo.

El archivo looker-db.yml contendría las credenciales de la base de datos, como las siguientes:

host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword

Además, si tu base de datos de MySQL requiere una conexión SSL, el archivo looker-db.yml también requiere lo siguiente:

ssl: true

Nota: Debes almacenar una copia de tu archivo de credenciales en el almacenamiento compartido y en cada nodo del clúster.

Nota: Sigue las consideraciones de seguridad recomendadas cuando guardes credenciales en un archivo. Lo ideal es establecer los permisos del archivo looker-db.yml en 600, propiedad de la cuenta de "usuario" de Linux en la que se ejecuta la aplicación de Looker. Este archivo nunca debe registrarse en un repositorio de Git.

Si no quieres almacenar la configuración en el archivo looker-db.yml en el disco, puedes configurar la variable de entorno LOOKER_DB para que contenga una lista de claves y valores para cada línea del archivo looker-db.yml. Por ejemplo:

export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"

Busca tus claves de implementación de SSH de Git

El lugar donde Looker almacena las claves de implementación de SSH de Git depende de la versión en la que se creó el proyecto:

• En el caso de los proyectos creados antes de Looker 4.8, las claves de implementación se almacenan en el directorio SSH integrado del servidor, ~/.ssh.
• En el caso de los proyectos creados en Looker 4.8 o versiones posteriores, las claves de implementación se almacenan en un directorio controlado por Looker, ~/looker/deploy_keys/PROJECT_NAME.

Modifica un clúster de Looker

Después de crear un clúster de Looker, puedes agregar o quitar nodos sin realizar cambios en los otros nodos agrupados en clústeres.

Actualiza un clúster a una nueva versión de Looker

Las actualizaciones pueden implicar cambios de esquema en la base de datos interna de Looker que no serían compatibles con versiones anteriores de Looker. Para actualizar Looker, hay dos métodos.

Método más seguro

1. Crea una copia de seguridad de la base de datos de aplicaciones.
2. Detén todos los nodos del clúster.
3. Reemplaza los archivos JAR en cada servidor.
4. Inicia cada nodo de a uno.

Método más rápido

Nota: Este método disminuye el tiempo de inactividad, pero perderá los cambios realizados entre la creación de la réplica y el momento en que el servidor proxy apunta a los nodos nuevos. Por ejemplo, si alguien agrega usuarios o crea Looks durante la transición, es posible que esos cambios no se capturen en la nueva base de datos de aplicaciones.

Para actualizar con este método más rápido, pero menos completo, haz lo siguiente:

1. Crea una réplica de la base de datos de aplicaciones de Looker.
2. Inicia un clúster nuevo que apunte a la réplica.
3. Haz que el servidor proxy o el balanceador de cargas apunten a los nodos nuevos, después de lo cual podrás detener los nodos anteriores.