Como fazer o clustering do Looker

Neste tutorial, explicamos o método recomendado de criação de uma configuração em cluster do Looker para instâncias hospedadas pelo cliente.

Visão geral

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

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

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

• Balanceamento de carga
• Melhoria na disponibilidade e no failover

Dependendo dos problemas de escalonamento, um Looker em cluster pode não oferecer 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 fazer o balanceamento de 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 um monitoramento de desempenho detalhado para o uso de memória e CPU, garantindo que o servidor do Looker seja dimensionado adequadamente para a carga de trabalho dele.

Consultas grandes precisam de mais memória para melhorar o desempenho. O clustering pode proporcionar ganhos de desempenho quando muitos usuários executam consultas pequenas.

Para configurações com até 50 usuários que usam o Looker de maneira leve, o Looker recomenda executar um único servidor no equivalente a uma instância AWS EC2 de grande porte (M4.large: 8 GB de RAM e dois núcleos de CPU). Para configurações com mais usuários ou muitos usuários ativos, observe se a CPU apresenta picos ou se os usuários percebem lentidão no aplicativo. Nesse caso, mova o Looker para um servidor maior ou execute uma configuração em cluster do Looker.

Maior disponibilidade/failover

A execução do Looker em um ambiente em cluster pode reduzir a inatividade em caso de interrupções. A alta disponibilidade é importante principalmente quando a API Looker é usada nos principais sistemas de negócios ou se o Looker está incorporado a produtos voltados para o cliente.

Em uma configuração em 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 ingressam no cluster.

Componentes obrigatórios

Os seguintes componentes são necessários para uma configuração em cluster do Looker:

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

O diagrama abaixo ilustra como os componentes interagem. De modo geral, o balanceador de carga distribui o tráfego de rede entre os nós em cluster do Looker. Cada um dos nós se comunica 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 de aplicativos MySQL

O Looker usa um banco de dados de aplicativos (geralmente chamado de banco de dados interno) para armazenar os dados do aplicativo. 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 em cluster do Looker, a instância do Looker de cada nó precisa apontar para um banco de dados transacional compartilhado (o aplicativo compartilhado ou o banco de dados interno). A compatibilidade do banco de dados de aplicativos para o Looker em cluster é a seguinte:

• O banco de dados do aplicativo para instâncias em cluster do Looker é compatível apenas com o MySQL. Não há suporte para o Amazon Aurora e o MariaDB.
• 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. Seu 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 com backup pelo menos uma vez por dia.

Nós do Looker

Cada nó é um servidor com o processo do Looker Java em execução. Os servidores no cluster do Looker precisam se comunicar entre si e com o banco de dados do aplicativo Looker. As portas padrão estão listadas em Abrir as portas para que os nós se comuniquem nesta página.

Balanceador de carga

Para equilibrar as solicitações de carga ou redirecionamento para os nós disponíveis, é necessário ter um balanceador de carga ou servidor proxy (por exemplo, NGINX ou ELB da AWS) para direcionar o tráfego para cada nó do Looker. O balanceador de carga processa verificações de integridade. Em caso de falha do 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 funcionar apenas como de camada 4. O ELB da Amazon Classic é um desses exemplos. Além disso, o balanceador de carga deve ter um tempo limite longo (3.600 segundos) para evitar que as consultas sejam encerradas.

Sistema de arquivos compartilhados

Você deve 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 do cluster.

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

Aplicativo Looker (JAR executável)

É necessário usar um arquivo JAR do aplicativo Looker com a versão 3.56 ou mais recente.

Observação: no Looker 6.18 e versões mais recentes, o arquivo JAR do Looker foi dividido em dois arquivos JAR separados: o 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 seguintes tarefas 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 situação)
5. Abrir as portas para os nós se comunicarem
6. Iniciar o Looker nos nós

Instalar o Looker

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

Como configurar um banco de dados de aplicativo MySQL

Para uma configuração em cluster do Looker, o banco de dados do aplicativo precisa ser MySQL. Se você já tiver uma instância do Looker sem cluster que usa o HyperSQL para o banco de dados do aplicativo, migre os dados do HyperSQL para o novo banco de dados compartilhado do app MySQL.

Observação :não se esqueça de fazer 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 para o contrário.

Consulte a página de documentação Como migrar para o MySQL para saber como fazer backup do Looker e migrar o banco de dados do aplicativo do HyperSQL para o MySQL.

Configurar o sistema de arquivos compartilhados

Somente tipos de arquivos específicos, como 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 pode 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, encerre a configuração.
4. Se você estava realizando o clustering usando scripts inotify Linux, interrompa esses scripts, remova-os do cron e exclua-os.
5. Criar um compartilhamento de rede e montá-lo em cada nó do cluster. Verifique se ele está configurado para montagem automática em cada nó e se o usuário do Looker pode 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 para seu compartilhamento de rede os plug-ins e os diretórios looker/models e looker/models-user-*, que armazenam os arquivos de modelo. Exemplo:

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

   Observação :é preciso copiar as chaves de implantação 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
   

   O LOOKERARGS precisa ser adicionado a $HOME/looker/lookerstart.cfg para que as configurações não sejam afetadas pelas atualizações Se os LOOKERARGS não estiverem listados nesse arquivo, é possível que alguém os tenha adicionado diretamente ao script de shell $HOME/looker/looker.

   Cada nó do 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 compartilhado com base em uma configuração atual do Looker e
• Você tem projetos que foram criados no Looker 4.6 ou anterior.

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

Configure o repositório de chaves SSH que 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, confira se os diretórios acima do diretório ssh-share (como /mnt e /mnt/looker-share) não são graváveis globalmente ou em grupo.

2. Em um nó, copie o conteúdo de $HOME/.ssh para o novo diretório ssh-share. 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. Exemplo:

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

   Essa etapa precisa ser realizada para cada nó.

Como abrir as portas para que os nós se comuniquem

Os nós em cluster do Looker se comunicam por HTTPS com certificados autoassinados e um esquema de autenticação adicional com base em secrets rotativos no banco de dados do aplicativo.

As portas padrão que precisam ser abertas entre os nós de cluster são 1551 e 61616. É possível configurar essas portas usando as sinalizações de inicialização listadas aqui. É altamente recomendável restringir o acesso de 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 sinalizações 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.

Sinalizações de inicialização disponíveis

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

Flag	Obrigatório?	Valores	Finalidade
--clustered	Sim		Adicionar sinalização para especificar que este nó está sendo executado no modo em 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 dele. Precisa ser diferente dos nomes do host de todos os outros nós do cluster.
-n	No	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 a comunicação entre nós.
-q	No	61616	A porta para enfileirar eventos em todo o 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 do diretório compartilhado anteriormente 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 de banco de dados

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

Por exemplo, talvez você queira informar ao Looker:

• Para usar o arquivo chamado looker-db.yml para as credenciais do banco de dados,
• que é um nó em cluster e
• para que os outros nós do cluster entrem 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 seu 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:é preciso armazenar uma cópia do arquivo de credenciais no armazenamento compartilhado e em cada nó do cluster.

Observação:siga as práticas recomendadas de segurança 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 colocado em um repositório Git.

Se você não quiser armazenar a configuração no arquivo looker-db.yml em disco, defina a variável de ambiente LOOKER_DB para conter uma lista de chaves e valores para cada linha no arquivo looker-db.yml. 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 alterar os outros nós em cluster.

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 são 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 do aplicativo.
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 as alterações feitas entre a criação da réplica e o direcionamento 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 do aplicativo.

Para atualizar usando esse método mais rápido, mas menos completo, faça o seguinte:

1. Criar 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, será possível interromper os nós antigos.