Clustering Looker

Este tutorial explica o método recomendado para criar uma configuração de cluster do Looker para instâncias hospedadas pelo cliente.

Visão geral

As implantações do Looker hospedadas pelo cliente podem ser de nó único ou em cluster:

• Um aplicativo do Looker de nó único, a configuração padrão, tem todos os serviços que compõem o aplicativo do Looker em execução em um único servidor.
• Uma configuração de cluster do Looker é mais complexa, geralmente envolvendo servidores de banco de dados, balanceadores de carga e vários servidores que executam o aplicativo do Looker. Cada nó em um aplicativo de cluster do Looker é um servidor que executa uma única instância do Looker.

Há dois motivos principais para uma organização querer executar o Looker como um cluster:

• Balanceamento de carga
• Melhor disponibilidade e failover

Dependendo dos problemas de escalonamento, um cluster do Looker pode não fornecer a solução. Por exemplo, se um pequeno número de consultas grandes estiver usando a memória do sistema, a única solução será aumentar a memória disponível para o processo do Looker.

Alternativas de balanceamento de carga

Antes de balancear a carga do Looker, considere aumentar a memória e, possivelmente, a contagem de CPUs de um único servidor que executa o Looker. O Looker recomenda configurar o monitoramento detalhado de desempenho para uso de memória e CPU para garantir que o servidor do Looker seja dimensionado corretamente para a carga de trabalho.

Consultas grandes precisam de mais memória para um melhor desempenho. O cluster pode proporcionar ganhos de desempenho quando muitos usuários estão executando consultas pequenas.

Para configurações com até 50 usuários que usam o Looker com moderação, o Looker recomenda executar um único servidor no equivalente a uma instância grande do AWS EC2 (M4.large: 8 GB de RAM, 2 núcleos de CPU). Para configurações com mais usuários ou muitos usuários avançados ativos, observe se a CPU aumenta ou se os usuários notam lentidão no aplicativo. Se for o caso, mova o Looker para um servidor maior ou execute uma configuração de cluster do Looker.

Melhor disponibilidade/failover

A execução do Looker em um ambiente de cluster pode atenuar o tempo de inatividade em caso de interrupção. A alta disponibilidade é especialmente importante se a API Looker for usada em sistemas de negócios principais ou se o Looker estiver incorporado a produtos voltados ao cliente.

Em uma configuração de cluster do Looker, um servidor proxy ou balanceador de carga vai redirecionar o tráfego quando determinar que um nó está inativo. O Looker processa automaticamente os nós que saem e entram no cluster.

Componentes obrigatórios

Os componentes a seguir são necessários para uma configuração de cluster do Looker:

• Banco de dados do aplicativo MySQL
• Nós do Looker (servidores que executam o processo Java do Looker)
• Balanceador de carga
• Sistema de arquivos compartilhados
• Versão adequada dos arquivos JAR do aplicativo Looker

O diagrama a seguir ilustra como os componentes interagem. Em um nível alto, um balanceador de carga distribui o tráfego de rede entre os nós de cluster do Looker. Os nós se comunicam com um banco de dados de aplicativos MySQL compartilhado, um diretório de armazenamento compartilhado e os servidores Git para cada projeto do LookML.

Banco de dados do aplicativo MySQL

O Looker usa um banco de dados de aplicativos (geralmente chamado de banco de dados interno) para armazenar dados de aplicativos. Quando o Looker é executado como um aplicativo de nó único, ele normalmente usa um banco de dados HyperSQL na memória.

Em uma configuração de cluster do Looker, a instância do Looker de cada nó precisa apontar para um banco de dados transacional compartilhado (o aplicativo compartilhado ou banco de dados interno). O suporte ao banco de dados de aplicativos para cluster do Looker é o seguinte:

• Somente o MySQL é compatível com o banco de dados de aplicativos para instâncias de cluster do Looker. O Amazon Aurora e o MariaDB não são compatíveis.
• As versões 5.7 e 8.0 do MySQL são compatíveis.
• Bancos de dados em cluster, como o Galera, não são compatíveis.

Observação: um banco de dados de réplica de leitura é recomendado para melhorar o desempenho e a redundância. O banco de dados de réplica de leitura não precisa ser um banco de dados MySQL.

O Looker não gerencia a manutenção e os backups desse banco de dados. No entanto, como o banco de dados hospeda quase todos os dados de configuração do aplicativo Looker, ele precisa ser provisionado como um banco de dados de alta disponibilidade e fazer backup pelo menos diariamente.

Nós do Looker

Cada nó é um servidor com o processo Java do Looker em execução. Os servidores no cluster do Looker precisam conseguir alcançar uns aos outros e o banco de dados do aplicativo Looker. As portas padrão estão listadas em Abrir as portas para os nós se comunicarem nesta página.

Balanceador de carga

Para balancear a carga ou redirecionar solicitações para nós disponíveis, um balanceador de carga ou servidor proxy (por exemplo, NGINX ou AWS ELB) é necessário para direcionar o tráfego a cada nó do Looker. O balanceador de carga processa as verificações de integridade. Em caso de falha de nó, o balanceador de carga precisa ser configurado para redirecionar o tráfego para os nós íntegros restantes.

Ao escolher e configurar o balanceador de carga, verifique se ele pode ser configurado para operar apenas como camada 4. O Amazon Classic ELB é um exemplo. Além disso, o balanceador de carga precisa ter um tempo limite longo (3.600 segundos) para evitar que as consultas sejam encerradas.

Sistema de arquivos compartilhados

É necessário usar um sistema de arquivos compartilhados compatível com POSIX (como NFS, AWS EFS, Gluster, BeeGFS, Lustre ou muitos outros). O Looker usa o sistema de arquivos compartilhados como um repositório para várias informações usadas por todos os nós no cluster.

**Observação**: a instalação de aplicativos e ferramentas do Marketplace do Looker exige o uso de um sistema de arquivos compartilhados (de rede).

Aplicativo Looker (JAR executável)

É necessário usar um arquivo JAR do aplicativo Looker que seja do Looker 3.56 ou mais recente.

Observação: a partir do Looker 6.18, o arquivo JAR do Looker foi dividido em dois arquivos JAR separados: o arquivo JAR principal do Looker e um arquivo JAR de dependências do Looker. Se você estiver instalando ou atualizando para o Looker 6.18 ou mais recente, faça o download dos dois arquivos JAR.

O Looker recomenda que cada nó em um cluster execute a mesma versão de lançamento e patch do Looker, conforme discutido em Iniciar o Looker nos nós nesta página.

Como configurar o cluster

As tarefas a seguir são necessárias:

1. Instalar o Looker
2. Configurar um banco de dados de aplicativos MySQL
3. Configurar o sistema de arquivos compartilhados
4. Compartilhar o repositório de chaves SSH (dependendo da sua situação)
5. Abrir as portas para os nós se comunicarem
6. Iniciar o Looker nos nós

Como instalar o Looker

Verifique se o Looker está instalado em cada nó, usando os arquivos JAR do aplicativo Looker e as instruções na página de documentação Etapas de instalação hospedadas pelo cliente.

Como configurar um banco de dados de aplicativos MySQL

Para uma configuração de cluster do Looker, o banco de dados de aplicativos precisa ser um banco de dados MySQL. Se você tiver uma instância do Looker não clusterizada que esteja usando o HyperSQL para o banco de dados de aplicativos, será necessário migrar os dados do aplicativo do HyperSQL para o novo banco de dados de aplicativos MySQL compartilhado.

Observação: faça backup do diretório do Looker. O processo de migração só pode ir de um banco de dados HyperSQL para um banco de dados MySQL, não o contrário.

Consulte a página de documentação Migrar para o MySQL para informações sobre como fazer backup do Looker e migrar o banco de dados de aplicativos do HyperSQL para o MySQL.

Como configurar o sistema de arquivos compartilhados

Somente tipos de arquivos específicos (arquivos de modelo, chaves de implantação, plug-ins e, possivelmente, arquivos de manifesto de aplicativos) pertencem ao sistema de arquivos compartilhados. Para configurar o sistema de arquivos compartilhados:

1. No servidor que vai armazenar o sistema de arquivos compartilhados, verifique se você tem acesso a outra conta que possa su para a conta de usuário do Looker.
2. No servidor do sistema de arquivos compartilhados, faça login na conta de usuário do Looker.
3. Se o Looker estiver em execução, desligue a configuração do Looker.
4. Se você estava fazendo o cluster usando scripts do inotify Linux, interrompa esses scripts, remova-os do cron e exclua-os.
5. Crie um compartilhamento de rede e monte-o em cada nó do cluster. Verifique se ele está configurado para montagem automática em cada nó e se o usuário do Looker tem a capacidade de ler e gravar nele. No exemplo a seguir, o compartilhamento de rede é chamado de /mnt/looker-share.

6. Em um nó, copie as chaves de implantação e mova os plug-ins e os diretórios looker/models e looker/models-user-*, que armazenam os arquivos de modelo, para o compartilhamento de rede. Por exemplo:

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

   Observação: as chaves de implantação precisam ser copiadas para o armazenamento compartilhado e para cada nó no cluster.

7. Para cada nó, adicione a configuração --shared-storage-dir ao LOOKERARGS. Especifique o compartilhamento de rede, conforme mostrado neste exemplo:

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

   LOOKERARGS precisa ser adicionado a $HOME/looker/lookerstart.cfg para que as configurações não sejam afetadas por atualizações. Se os LOOKERARGS não estiverem listados nesse arquivo, alguém poderá tê-los adicionado diretamente ao script de shell $HOME/looker/looker.

   Cada nó no cluster precisa gravar em um diretório /log exclusivo ou, pelo menos, em um arquivo de registro exclusivo.

Como compartilhar o repositório de chaves SSH

• Você está criando um cluster de sistema de arquivos compartilhados a partir de uma configuração do Looker e
• Você tem projetos criados no Looker 4.6 ou versões anteriores.

Observação: o procedimento a seguir exige a modificação do diretório $HOME/.ssh do usuário do Looker. Isso pode dificultar o login e a correção de algo se houver erros na configuração. Antes de realizar essas etapas, verifique se você tem acesso a outra conta que possa su para a conta de usuário do Looker.

Configure o repositório de chaves SSH para ser compartilhado:

1. No servidor de arquivos compartilhados, crie um diretório chamado ssh-share. Por exemplo: /mnt/looker-share/ssh-share.

   Verifique se o diretório ssh-share pertence ao usuário do Looker e se as permissões são 700. Além disso, verifique se os diretórios acima do diretório ssh-share (como /mnt e /mnt/looker-share) não são graváveis ou graváveis em grupo.

2. Em um nó, copie o conteúdo de $HOME/.ssh para o novo diretório ssh-share. Por exemplo:

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

3. Para cada nó, faça um backup do arquivo SSH atual e crie um link simbólico para o diretório ssh-share. Por exemplo:

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

   Faça essa etapa para cada nó.

Como abrir as portas para os nós se comunicarem

Os nós de cluster do Looker se comunicam entre si por HTTPS com certificados autoassinados e um esquema de autenticação adicional com base em chaves secretas rotativas no banco de dados de aplicativos.

As portas padrão que precisam estar abertas entre os nós do cluster são 1551 e 61616. Essas portas podem ser configuradas usando as flags de inicialização listadas aqui. Recomendamos restringir o acesso à rede a essas portas para permitir o tráfego apenas entre os hosts do cluster.

Como iniciar o Looker nos nós

Reinicie o servidor em cada nó com as flags de inicialização necessárias.

**Observação**: cada nó em um cluster precisa executar a mesma versão de lançamento e patch do Looker.

Flags de inicialização disponíveis

A tabela a seguir mostra as flags de inicialização disponíveis, incluindo as necessárias para iniciar ou participar de um cluster:

Sinalização	Obrigatório?	Valores	Finalidade
--clustered	Sim		Adicione a flag para especificar que esse nó está sendo executado no modo de cluster.
-H ou --hostname	Sim	10.10.10.10	O nome do host que outros nós usam para entrar em contato com esse nó, como o endereço IP ou o nome do host do sistema. Precisa ser diferente dos nomes de host de todos os outros nós no cluster.
-n	Não	1551	A porta para comunicação entre nós. O padrão é 1551. Todos os nós precisam usar o mesmo número de porta para comunicação entre nós.
-q	Não	61616	A porta para enfileirar eventos de cluster. O padrão é 61616.
-d	Sim	/path/to/looker-db.yml	O caminho para o arquivo que contém as credenciais do banco de dados do aplicativo Looker.
--shared-storage-dir	Sim	/path/to/mounted/shared/storage	A opção precisa apontar para a configuração de diretório compartilhado anterior nesta página que contém os diretórios looker/model e looker/models-user-*.

**Observação** :a flag de inicialização --clustered não pode incluir um valor.

Exemplo de LOOKERARGS e especificação de credenciais do banco de dados

Coloque as flags de inicialização do Looker em um arquivo lookerstart.cfg, localizado no mesmo diretório dos arquivos JAR do Looker.

Por exemplo, você pode querer informar ao Looker:

• Para usar o arquivo chamado looker-db.yml para as credenciais do banco de dados,
• que é um nó de cluster e
• que os outros nós do cluster precisam entrar em contato com esse host no endereço IP 10.10.10.10.

Você especificaria:

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

Observação: especifique o endereço IP correto para o nó.

O arquivo looker-db.yml contém as credenciais do banco de dados, como:

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

E, se o banco de dados MySQL exigir uma conexão SSL, o arquivo looker-db.yml também vai exigir o seguinte:

ssl: true

Observação: é necessário armazenar uma cópia do arquivo de credenciais no armazenamento compartilhado e em cada nó no cluster.

Observação: siga as considerações de segurança recomendadas ao salvar credenciais em um arquivo. O ideal é definir as permissões do arquivo looker-db.yml como 600, pertencentes à conta de "usuário" do Linux em que o aplicativo Looker é executado. Esse arquivo nunca deve ser verificado em um repositório Git.

Se você não quiser armazenar a configuração no arquivo looker-db.yml no disco, poderá configurar a variável de ambiente LOOKER_DB para conter uma lista de chaves e valores para cada linha no arquivo looker-db.yml. Por exemplo:

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

Como encontrar as chaves de implantação SSH do Git

O local em que o Looker armazena as chaves de implantação SSH do Git depende da versão em que o projeto foi criado:

• Para projetos criados antes do Looker 4.8, as chaves de implantação são armazenadas no diretório SSH integrado do servidor, ~/.ssh.
• Para projetos criados no Looker 4.8 ou mais recente, as chaves de implantação são armazenadas em um diretório controlado pelo Looker, ~/looker/deploy_keys/PROJECT_NAME.

Como modificar um cluster do Looker

Depois de criar um cluster do Looker, é possível adicionar ou remover nós sem fazer alterações nos outros nós clusterizados.

Como atualizar um cluster para uma nova versão do Looker

As atualizações podem envolver mudanças de esquema no banco de dados interno do Looker que não seriam compatíveis com versões anteriores do Looker. Há dois métodos para atualizar o Looker.

Método mais seguro

1. Crie um backup do banco de dados de aplicativos.
2. Interrompa todos os nós do cluster.
3. Substitua os arquivos JAR em cada servidor.
4. Inicie cada nó um de cada vez.

Método mais rápido

Observação: esse método diminui o tempo de inatividade, mas perde todas as mudanças feitas entre a criação da réplica e o apontamento do servidor proxy para os novos nós. Por exemplo, se alguém adicionar usuários ou criar Looks durante a transição, essas mudanças poderão não ser capturadas no novo banco de dados de aplicativos.

Para atualizar usando esse método mais rápido, mas menos completo:

1. Crie uma réplica do banco de dados de aplicativos do Looker.
2. Inicie um novo cluster apontado para a réplica.
3. Aponte o servidor proxy ou o balanceador de carga para os novos nós. Depois disso, você poderá interromper os nós antigos.