En este instructivo, se explica el método recomendado para crear una configuración agrupada de Looker en clústeres para instancias alojadas por el cliente.
Descripción general
Las implementaciones de Looker alojadas por el cliente pueden ejecutar un nodo único o un clúster:
- La configuración predeterminada de la aplicación de Looker de un solo nodo tiene todos los servicios que conforman la aplicación de Looker ejecutándose en un solo servidor.
- Una configuración agrupada en clústeres de Looker 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 única instancia de Looker.
Existen dos motivos principales por los que una organización querría ejecutar Looker como 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 está consumiendo 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, el recuento de CPU de un solo servidor que ejecute Looker. Looker recomienda configurar una supervisión detallada del rendimiento del uso de CPU y memoria 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 obtener un mejor rendimiento. El agrupamiento en clústeres puede proporcionar mejoras de rendimiento cuando muchos usuarios ejecutan consultas pequeñas.
Para configuraciones con hasta 50 usuarios que usan Looker a la ligera, Looker recomienda ejecutar un solo servidor con el equivalente a una instancia de gran tamaño AWS EC2 (M4.large: 8 GB de RAM, 2 núcleos de CPU). Para configuraciones con más usuarios o muchos power users activos, observa si la CPU tiene un aumento repentino o si los usuarios notan una lentitud en la aplicación. Si es así, mueve Looker a un servidor más grande o ejecuta una configuración de Looker en clústeres.
Disponibilidad/conmutación por error mejorada
Ejecutar Looker en un entorno de 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 los sistemas comerciales principales o si Looker está incorporado en productos para los clientes.
En una configuración de Looker en clústeres, un servidor proxy o balanceador de cargas redirigirá el tráfico cuando determine que un nodo está inactivo. Looker controla automáticamente los nodos que salen del clúster y se unen a él.
Componentes obligatorios
Los siguientes componentes son obligatorios para una configuración de Looker en clústeres:
- Base de datos de aplicaciones de MySQL
- Nodos de Looker (servidores que ejecutan el proceso de Looker Java)
- Balanceador de cargas
- Sistema de archivos compartido
- Versión correcta 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 alto, un balanceador de cargas distribuye el tráfico de red entre los nodos de Looker en clústeres. Cada nodo se comunica con una base de datos compartida de aplicaciones de MySQL, un directorio de almacenamiento compartido y los servidores Git para cada proyecto de LookML.
Base de datos de aplicaciones de MySQL
Looker usa una base de datos de aplicación (a menudo llamada base de datos interna) para almacenar datos de la aplicación. Cuando Looker se ejecuta como una aplicación de nodo único, por lo general, usa una base de datos de HyperSQL en la memoria.
En una configuración de Looker 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 de la base de datos de aplicaciones para Looker en clústeres es la siguiente:
- Solo MySQL es compatible con la base de datos de aplicaciones para instancias de Looker en clústeres. No se admiten Amazon Aurora ni MariaDB.
- Se admiten las versiones 5.7 y 8.0 o posteriores de MySQL.
- No se admiten bases de datos agrupadas, como Galera.
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 las aplicaciones de Looker, debe aprovisionarse como una base de datos de alta disponibilidad y 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 de Looker para Java. Los servidores del clúster de Looker deben poder comunicarse entre sí y con la base de datos de la aplicación 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 las solicitudes de carga o redireccionamiento en 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. Si se produce una falla en un nodo, el balanceador de cargas debe configurarse para redirigir 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 funcione solo como capa 4. Un ejemplo de ello es la ELB clásica de Amazon. Además, el balanceador de cargas debería tener un tiempo de espera prolongado (3,600 segundos) para evitar que se finalicen las consultas.
Sistema de archivos compartido
Debes usar un sistema de archivos compartidos que cumpla con POSIX (como NFS, AWS EFS, Gluster, BeeGFS, Lustre y muchos más). Looker usa el sistema de archivos compartidos como repositorio de diversos datos que usan todos los nodos del clúster.
Aplicación de Looker (ejecutable de JAR)
Debes usar un archivo JAR de la aplicación de Looker que sea de Looker 3.56 o una versión posterior.
Looker recomienda que cada nodo de un clúster ejecute la misma versión de Looker y la de parche, como se explica en Inicia Looker en los nodos en esta página.
Configura el clúster
Se requieren las siguientes tareas:
- Instala Looker
- Configura una base de datos de aplicaciones de MySQL
- Configura el sistema de archivos compartidos
- Comparte el repositorio de claves SSH (según tu situación)
- Abre los puertos para que los nodos se comuniquen
- Inicia Looker en los nodos
Instalar Looker
Asegúrate de tener Looker instalado en cada nodo. Para ello, usa los archivos JAR de la aplicación de Looker y las instrucciones en la página de documentación de Pasos de instalación alojados por el cliente.
Configura una base de datos de aplicaciones de MySQL
Para una configuración de Looker en clústeres, la base de datos de la aplicación debe ser una base de datos MySQL. Si ya tienes una instancia de Looker no agrupada en clústeres que usa HyperSQL para la base de datos de la aplicación, debes migrar los datos de la aplicación desde los datos de HyperSQL hacia tu nueva base de datos compartida de aplicaciones de MySQL.
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 algunos 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 compartidos. Para configurar el sistema de archivos compartidos, sigue estos pasos:
- En el servidor que almacenará el sistema de archivos compartidos, verifica que tengas acceso a otra cuenta que pueda usar
su
para la cuenta de usuario de Looker. - En el servidor del sistema de archivos compartidos, accede a la cuenta de usuario de Looker.
- Si se está ejecutando Looker, cierra la configuración de Looker.
- Si anteriormente usabas secuencias de comandos inotify de Linux para agrupar en clústeres, detén esas secuencias, quítalas de cron y bórralas.
- Crear un recurso compartido de red y activarlo 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 leer y escribir en él. En el siguiente ejemplo, el recurso compartido de red se llama
/mnt/looker-share
. En un nodo, copia tus claves de implementación y mueve tus complementos y los directorios
looker/models
ylooker/models-user-*
, que almacenan los archivos del modelo, a tu recurso compartido de red. Por ejemplo:mv looker/models /mnt/looker-share/ mv looker/models-user-* /mnt/looker-share/
Para cada nodo, agrega el parámetro de configuración
--shared-storage-dir
aLOOKERARGS
. 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 afecten la configuración. Si tusLOOKERARGS
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 compartidos a partir de una configuración existente de Looker.
- Tienes proyectos que se crearon en Looker 4.6 o una versión anterior.
Configura el repositorio de claves SSH que se compartirá:
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 de que los permisos sean 700. Además, asegúrate de que los directorios sobre el directoriossh-share
(como/mnt
y/mnt/looker-share
) no puedan escribir en todo el mundo ni en grupos.En un nodo, copia el contenido de
$HOME/.ssh
en el nuevo directorio dessh-share
. Por ejemplo:cp $HOME/.ssh/* /mnt/looker-share/ssh-share
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úrate de realizar este paso para cada nodo.
Cómo abrir los puertos para que los nodos se comuniquen
Los nodos agrupados de Looker 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.
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 clúster. | |
-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 poner en cola eventos de 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 la aplicación de Looker. |
--shared-storage-dir |
Sí | /path/to/mounted/shared/storage |
La opción debería apuntar a la configuración del directorio compartido anteriormente en esta página que contiene los directorios looker/model y looker/models-user-* . |
Ejemplo de LOOKERARGS
y especificación de credenciales de 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 decirle a Looker:
- Si deseas usar el archivo llamado
looker-db.yml
para las credenciales de su base de datos, haz lo siguiente: - 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"
El archivo looker-db.yml
contendría las credenciales de la base de datos, por ejemplo:
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 requiere lo siguiente:
ssl: true
Si no quieres almacenar la configuración del 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"
Encuentra tus claves de implementación de SSH de Git
La ubicación en la que Looker almacena las claves de implementación SSH de Git 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 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 hacer cambios en los otros nodos del clúster.
Actualiza un clúster a una nueva versión de Looker
Es posible que las actualizaciones involucren cambios de esquema en la base de datos interna de Looker que no serían compatibles con versiones anteriores de Looker. Existen dos métodos para actualizar Looker.
Método más seguro
- Crear una copia de seguridad de la base de datos de la aplicación
- Detén todos los nodos del clúster.
- Reemplaza los archivos JAR en cada servidor.
- Inicia cada nodo uno a la vez.
Método más rápido
Para actualizar con este método más rápido, pero menos completo, haz lo siguiente:
- Crear una réplica de la base de datos de aplicaciones de Looker
- Inicia un clúster nuevo que apunte a la réplica.
- Apuntar el servidor proxy o el balanceador de cargas a los nodos nuevos, después de lo cual puedes detener los nodos antiguos