Clustering de Looker

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

Información general

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

• Una aplicación de Looker de un solo nodo, que es la configuración predeterminada, tiene todos los servicios que componen la aplicación de Looker ejecutándose en un solo servidor.
• Una configuración de Looker en clúster es más compleja y suele incluir servidores de bases de datos, balanceadores de carga y varios servidores que ejecutan la aplicación 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 clúster:

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

En función de los problemas de escalado, es posible que un Looker agrupado no proporcione la solución. Por ejemplo, si un número reducido de consultas grandes está consumiendo la memoria del sistema, la única solución es aumentar la memoria disponible para el proceso de Looker.

Alternativas de balanceo de carga

Antes de balancear la carga de Looker, plantéate aumentar la memoria y, posiblemente, el número de CPUs de un solo servidor que ejecute Looker. Looker recomienda configurar una monitorización detallada del rendimiento del uso de la memoria y la CPU para asegurarse de que el servidor de Looker tenga el tamaño adecuado para su carga de trabajo.

Las consultas grandes necesitan más memoria para mejorar el rendimiento. La agrupación en clústeres puede mejorar el rendimiento cuando muchos usuarios ejecutan consultas pequeñas.

En las configuraciones con hasta 50 usuarios que usan Looker de forma esporádica, Looker recomienda ejecutar un solo servidor con el equivalente a una instancia EC2 de AWS de gran tamaño (M4.large: 8 GB de RAM y 2 núcleos de CPU). En las configuraciones con más usuarios o muchos usuarios avanzados activos, comprueba si la CPU se dispara o si los usuarios notan que la aplicación va lenta. Si es así, mueve Looker a un servidor más grande o ejecuta una configuración de Looker en clúster.

Mejora de la disponibilidad y la conmutación por error

Ejecutar Looker en un entorno agrupado puede reducir el tiempo de inactividad en caso de interrupción. La alta disponibilidad es especialmente importante si la API de Looker se usa en sistemas empresariales básicos o si Looker está insertado en productos orientados a los clientes.

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

Componentes necesarios

Se necesitan los siguientes componentes para una configuración de Looker en clúster:

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

En el siguiente diagrama se muestra cómo interactúan los componentes. A grandes rasgos, un balanceador de carga 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 MySQL compartida, un directorio de almacenamiento compartido y los servidores Git de cada proyecto de LookML.

Base de datos de aplicaciones MySQL

Looker usa una base de datos de aplicaciones (a menudo denominada 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 memoria.

En una configuración de Looker en clúster, 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 la aplicación de Looker en clústeres es la siguiente:

• Solo se admite MySQL para la base de datos de la aplicación de las 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, así como las posteriores.
• No se admiten bases de datos agrupadas en clústeres, como Galera.

Looker no gestiona 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 Looker, debe aprovisionarse como una base de datos de alta disponibilidad y se debe crear una copia de seguridad al menos una vez al día.

Nodos de Looker

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

Balanceador de carga

Para equilibrar la carga o redirigir las solicitudes a los nodos disponibles, se necesita un balanceador de carga o un servidor proxy (por ejemplo, NGINX o AWS ELB) para dirigir el tráfico a cada nodo de Looker. El balanceador de carga gestiona las comprobaciones del estado. En caso de que falle un nodo, el balanceador de carga debe configurarse para redirigir el tráfico a los nodos en buen estado restantes.

Cuando elija y configure el balanceador de carga, asegúrese de que se pueda configurar para que funcione solo en la capa 4. Amazon Classic ELB es un ejemplo de este tipo de balanceador de carga. Además, el balanceador de carga debe tener un tiempo de espera largo (3600 segundos) para evitar que se cancelen las consultas.

Sistema de archivos compartido

Debes usar un sistema de archivos compartido compatible con POSIX (como NFS, AWS EFS, Gluster, BeeGFS, Lustre u otros). Looker usa el sistema de archivos compartido como repositorio de varios elementos de información que utilizan todos los nodos del clúster.

Aplicación Looker (ejecutable JAR)

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

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

Configurar el clúster

Debes realizar las siguientes tareas:

1. Instalar Looker
2. Configurar una base de datos de aplicaciones MySQL
3. Configurar 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. Iniciar Looker en los nodos

Instalar Looker

Asegúrate de que Looker esté instalado en cada nodo. Para ello, usa los archivos JAR de la aplicación Looker y las instrucciones de la página de documentación Pasos para la instalación alojada por el cliente.

Configurar una base de datos de aplicación MySQL

En una configuración de Looker en clúster, la base de datos de la aplicación debe ser una base de datos MySQL. Si tienes una instancia de Looker no agrupada que usa HyperSQL para la base de datos de la aplicación, debes migrar los datos de la aplicación de los datos de HyperSQL a tu nueva base de datos de la aplicación MySQL compartida.

Consulta la página de documentación Migrar a MySQL para obtener información sobre cómo crear una copia de seguridad de Looker y, a continuación, migrar la base de datos de la aplicación de HyperSQL a MySQL.

Configurar el sistema de archivos compartido

Solo determinados tipos de archivos (archivos de modelo, claves de implementación, complementos y, posiblemente, archivos de manifiesto de aplicaciones) pertenecen al sistema de archivos compartido. Para configurar el sistema de archivos compartido, sigue estos pasos:

1. En el servidor que almacenará el sistema de archivos compartido, comprueba que tienes acceso a otra cuenta que pueda su a la cuenta de usuario de Looker.
2. En el servidor del sistema de archivos compartido, inicia sesión en la cuenta de usuario de Looker.
3. Si Looker está en ejecución, cierra la configuración de Looker.
4. Si antes usabas clústeres con secuencias de comandos de Linux inotify, detén esas secuencias, quítalas de cron y elimínalas.
5. Crea un recurso compartido de red y móntalo en cada nodo del clúster. Asegúrate de que esté configurado para montarse automáticamente en cada nodo y de que el usuario de Looker pueda leer y escribir en él. En el siguiente ejemplo, el nombre del recurso compartido de red es /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/
   

7. En cada nodo, añade el ajuste --shared-storage-dir al LOOKERARGS. Especifica la cuota de red, como se muestra en este ejemplo:

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

   LOOKERARGS debe añadirse a $HOME/looker/lookerstart.cfg para que los ajustes no se vean afectados por las actualizaciones. Si tus LOOKERARGS no aparecen en ese archivo, es posible que alguien los haya añadido directamente a la secuencia de comandos 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.

Compartir el repositorio de claves SSH

• Vas a crear un clúster de sistema de archivos compartido a partir de una configuración de Looker y
• Tienes proyectos que se crearon en Looker 4.6 o versiones anteriores.

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 por encima del directorio ssh-share (como /mnt y /mnt/looker-share) no tengan permisos de escritura para todos los usuarios ni para 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. En cada nodo, haz una copia de seguridad del archivo SSH y crea un enlace 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 en todos los nodos.

Abrir 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 rotatorios en la base de datos de la aplicación.

Los puertos predeterminados que deben estar abiertos entre los nodos del clúster son 1551 y 61616. Estos puertos se pueden configurar mediante 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.

Iniciar Looker en los nodos

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

Flags de inicio disponibles

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

Ejemplo de LOOKERARGS y especificación de credenciales de bases de datos

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

Por ejemplo, puede que quieras decirle a Looker lo siguiente:

• Para usar el archivo llamado looker-db.yml para sus credenciales de base de datos,
• que es un nodo agrupado y
• que los demás nodos del clúster deben ponerse en contacto con este host en la dirección IP 10.10.10.10.

Especifica lo siguiente:

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

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 MySQL requiere una conexión SSL, el archivo looker-db.yml también debe incluir lo siguiente:

ssl: true

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

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

Buscar tus claves de implementación SSH de Git

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

• En los proyectos creados antes de Looker 4.8, las claves de implementación se almacenan en el directorio SSH integrado del servidor, ~/.ssh.
• En 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.

Modificar un clúster de Looker

Después de crear un clúster de Looker, puedes añadir o quitar nodos sin hacer cambios en los demás nodos del clúster.

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

Las actualizaciones pueden implicar cambios en el esquema de la base de datos interna de Looker que no serían compatibles con versiones anteriores de Looker. Hay dos formas de actualizar Looker.

Método más seguro

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

Método más rápido

Para actualizar con este método más rápido, pero menos completo, sigue estos pasos:

1. Crea una réplica de la base de datos de la aplicación de Looker.
2. Inicia un nuevo clúster que apunte a la réplica.
3. Dirige el servidor proxy o el balanceador de carga a los nuevos nodos. Después, podrás detener los nodos antiguos.