Agrupamiento en clústeres de Looker

En este instructivo, se explica el método recomendado para crear una configuración agrupada de Looker.

Descripción general

La aplicación de Looker puede ejecutar un solo nodo o agrupado en clústeres:

  • Una aplicación de Looker de un solo nodo, la configuración predeterminada, tiene todos los servicios que conforman la aplicación de Looker ejecutándose en un solo servidor.
  • Una configuración de Looker agrupada en clústeres es una configuración más compleja que, por lo general, involucra 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 razones principales por las que una organización querría ejecutar Looker como un clúster:

  • Balanceo de cargas
  • Disponibilidad y conmutación por error mejoradas

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 consumen la memoria del sistema, la única solución es aumentar la memoria disponible para el proceso de Looker.

Alternativas de balanceo de cargas

Antes del balanceo de cargas, considera aumentar la memoria y, posiblemente, el recuento de CPU de un solo servidor que ejecuta Looker. Looker recomienda configurar una supervisión del rendimiento detallada para el uso de memoria y CPU a fin de 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 mejoras en el rendimiento cuando muchos usuarios ejecutan consultas pequeñas.

Para configuraciones con un máximo de 50 usuarios que usan Looker a la ligera, Looker recomienda ejecutar un solo servidor en el equivalente a una instancia de AWS EC2 de gran tamaño (M4.large: 8 GB de RAM, 2 núcleos de CPU). Para configuraciones con más usuarios o muchos usuarios activos, observa si la CPU aumenta 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 agrupada de Looker.

Disponibilidad/conmutación por error mejorada

Ejecutar Looker en un entorno agrupado 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 los sistemas empresariales principales o si Looker está incorporado en productos para los clientes.

En una configuración de Looker agrupada en clústeres, un servidor proxy o un balanceador de cargas redirigirá el tráfico cuando determine que un nodo está inactivo. Looker administra automáticamente los nodos que salen y se unen al clúster.

Componentes obligatorios

Los siguientes componentes son necesarios 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 Looker para Java)
  • 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:

Base de datos de aplicaciones de MySQL

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

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

  • Solo MySQL es compatible con la base de datos de aplicaciones para las instancias de Looker agrupadas. No se admiten Amazon Aurora ni MariaDB.
  • Se admiten las versiones 5.7 y posteriores de MySQL, además de 8.0.
  • No se admiten bases de datos agrupadas en clústeres, como Galera.

Se recomienda una base de datos de réplica de lectura para mejorar el rendimiento y la redundancia. No es necesario que la base de datos de réplica de lectura sea una base de datos de MySQL.

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

Nodos de Looker

Cada nodo es un servidor con el proceso de Looker para Java 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 Abrir 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) a fin de dirigir el tráfico a cada nodo de Looker. El balanceador de cargas controla las verificaciones de estado. En caso de que falle un nodo, el balanceador de cargas debe estar configurado para redirigir el tráfico a los nodos en buen estado restantes.

Cuando elija y configure el balanceador de cargas, asegúrese de que esté configurado solo para funcionar como la capa 4. El Amazon Classic ELB es un ejemplo de ello. Además, el balanceador de cargas debe tener un tiempo de espera prolongado (3,600 segundos) para evitar que se eliminen las consultas.

Sistema de archivos compartido

Debes usar un sistema de archivos compartidos que cumpla con POSIX (como NFS, AWS EFS, Gluster, BeeGFS, Lustre o muchos otros). Looker usa el sistema de archivos compartidos como repositorio para varios datos que usan todos los nodos del clúster.

Para instalar aplicaciones y herramientas desde Looker Marketplace, se requiere un sistema de archivos compartidos (de red).

Aplicación Looker (JAR ejecutable)

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

A partir de Looker 6.18, el archivo JAR de Looker se dividió en dos archivos JAR independientes: el archivo JAR principal de Looker y un archivo JAR de dependencias de Looker. Si estás instalando o actualizando 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 y parche de Looker, como se explica en Iniciar 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 aplicación de MySQL
  3. Configura el sistema de archivos compartidos
  4. Comparte el repositorio de claves SSH (según tu situación)
  5. Abrir los puertos para que los nodos se comuniquen
  6. Inicie Looker en los nodos

Instalación de Looker

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

Configura una base de datos de aplicación de MySQL

Para una configuración agrupada de Looker, la base de datos de la aplicación debe ser una base de datos de MySQL. Si tiene una instancia de Looker existente que no está agrupada y que usa HyperSQL para la base de datos de la aplicación, debe migrar los datos de la aplicación desde los datos de HyperSQL hasta la nueva base de datos de MySQL compartida.

Asegúrate de crear una copia de seguridad del directorio de Looker. El proceso de migración solo puede pasar de una base de datos de HyperSQL a una base de datos de MySQL, no a la inversa.

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

Configura el sistema de archivos compartidos

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

  1. En el servidor que almacenará el sistema de archivos compartidos, verifique que tenga acceso a otra cuenta que pueda su para la cuenta de usuario de Looker.
  2. En el servidor del sistema de archivos compartidos, accede a la cuenta de usuario de Looker.
  3. Si Looker está en ejecución, cierra la configuración de Looker.
  4. Si antes agrupabas en clústeres mediante secuencias de comandos de inotify de Linux, detén esas secuencias, 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é configurada para activarse automáticamente en cada nodo y de que el usuario de Looker tenga la capacidad de leer y escribir en él. En el siguiente ejemplo, el recurso compartido de red se llama /mnt/looker-share.

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

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

  7. Para cada nodo, agrega la 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

    Se debe agregar LOOKERARGS a $HOME/looker/lookerstart.cfg para que las actualizaciones no se vean afectadas. Si tus LOOKERARGS no aparecen en ese archivo, es posible que alguien las 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á creando un clúster de sistema de archivos compartido a partir de una configuración existente de Looker.
  • Tienes proyectos creados en Looker 4.6 o versiones anteriores.

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

Configura el repositorio de claves SSH que se compartirá:

  1. En el servidor de archivos compartido, 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 de que los permisos sean 700. Además, asegúrate de que los directorios que se encuentran por encima del directorio ssh-share (como /mnt y /mnt/looker-share) no puedan escribirse en todo el mundo ni escribir en grupos.

  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, crea una copia de seguridad del archivo SSH existente y crea un symlink al directorio ssh-share. Por ejemplo:

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

    Asegúrese de realizar este paso para cada nodo.

Cómo 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 rotativos 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 enumeran aquí. Recomendamos restringir el acceso de 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 necesarias.

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

Marcas de inicio disponibles

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

Flag ¿Es obligatorio? Valores Objetivo
--clustered Sí Agrega una marca para especificar que este nodo se ejecuta en modo de agrupamiento 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 el 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 colocar eventos en cola 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 para la base de datos de la aplicación de Looker.
--shared-storage-dir Sí /path/to/mounted/shared/storage La opción debe apuntar a la configuración del directorio compartido antes en esta página que contiene los directorios looker/model y looker/models-user-*.

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

Ejemplo de LOOKERARGS y especificación de las 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, puedes indicarle a Looker lo siguiente:

  • A fin de usar el archivo llamado looker-db.yml para sus credenciales de base de datos,
  • que es un nodo agrupado
  • que los otros nodos del clúster deberían comunicarse con este host en la dirección IP 10.10.10.10.

Debes especificar:

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

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

El archivo looker-db.yml contendrá las credenciales de la base de datos, como se muestra a continuación:

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

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

ssl: true

Sigue las prácticas recomendadas de seguridad cuando guardes credenciales en un archivo. Lo ideal es que los permisos del archivo looker-db.yml estén 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 deseas 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/valores para cada línea en el archivo looker-db.yml. Por ejemplo:

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

Encuentra tus claves de implementación de Git SSH

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

  • Para los proyectos creados antes de Looker 4.8, las claves de implementación se almacenan en el directorio SSH nativo del servidor, ~/.ssh.
  • Para 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, puede agregar o quitar nodos sin realizar cambios en los otros nodos agrupados.

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

Las actualizaciones pueden incluir cambios de esquema en la base de datos interna de Looker que no serían compatibles con las versiones anteriores de Looker. Hay dos métodos para 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. Reemplaza los archivos JAR de cada servidor.
  4. Inicia cada nodo de a uno.

Método más rápido

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

Para realizar la actualización con este método más rápido, pero menos completo:

  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. Apunta el servidor proxy o el balanceador de cargas a los nodos nuevos, después de lo cual podrás detener los nodos antiguos.