Clustering Looker

Neste tutorial, explicamos 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 hospedadas pelo cliente do Looker podem ser executadas em um nó 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 executando o aplicativo do Looker. Cada nó em um aplicativo do Looker agrupado é 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
• Disponibilidade e failover aprimorados

Dependendo dos problemas de escalonamento, um Looker agrupado 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 é 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 CPU de um único servidor que executa o Looker. O Looker recomenda configurar o monitoramento de desempenho detalhado para a memória e a utilização da CPU para garantir que o servidor do Looker tenha o tamanho adequado para a carga de trabalho.

Consultas grandes precisam de mais memória para um melhor desempenho. O agrupamento pode proporcionar ganhos de desempenho quando muitos usuários executam pequenas consultas.

Para configurações com até 50 usuários que usam o Looker de forma leve, ele recomenda executar um único servidor no equivalente a uma instância AWS EC2 de tamanho grande (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 tem picos ou se os usuários notam lentidão no aplicativo. Se sim, 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 clusterizado pode reduzir o tempo de inatividade no caso de uma interrupção. A alta disponibilidade é especialmente importante se a API Looker for usada nos sistemas de negócios principais ou se estiver integrada 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 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 a seguir ilustra como os componentes interagem. De maneira geral, um balanceador de carga distribui o tráfego de rede entre nós do Looker agrupados. Cada um dos nós se comunica com um banco de dados de aplicativo MySQL compartilhado, um diretório de armazenamento compartilhado e os servidores do Git para cada projeto do LookML.

Banco de dados de aplicativos MySQL

O Looker usa um banco de dados do aplicativo (geralmente chamado de banco de dados interno) para armazenar dados do aplicativo. Quando o Looker está sendo 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 o banco de dados interno). O suporte ao banco de dados do aplicativo para o Looker agrupado é o seguinte:

• Somente o MySQL é compatível com o banco de dados do aplicativo para instâncias de Looker em cluster. O Amazon Aurora e o MariaDB não são compatíveis.
• O MySQL nas versões 5.7 e 8.0 ou mais recentes são compatíveis.
• Não há suporte para bancos de dados em cluster, como o Galera.

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 e ter backup pelo menos uma vez por dia.

Nós do Looker

Cada nó é um servidor com o processo Java do Looker em execução. Os servidores no cluster do Looker precisam se comunicar entre si e com o banco de dados do aplicativo do 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 balancear a carga ou redirecionar solicitações para nós disponíveis, é necessário um balanceador de carga ou servidor proxy (por exemplo, NGINX ou AWS ELB) 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 um 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 na camada 4. O ELB do Amazon Classic é um exemplo disso. 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 compartilhado como um repositório de várias informações usadas por todos os nós do cluster.

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

Aplicativo do Looker (JAR executável)

É necessário usar um arquivo JAR do aplicativo 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 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 compartilhado
4. Compartilhar o repositório de chaves SSH (dependendo da sua situação)
5. Abrir as portas para que os nós se comuniquem
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 do Looker e as instruções na página de documentação Etapas de instalação hospedadas pelo cliente.

Configurar um banco de dados de aplicativos do MySQL

Para uma configuração de cluster do Looker, o banco de dados do aplicativo precisa ser um banco de dados MySQL. Se você tiver uma instância do Looker não agrupada que usa o HyperSQL para o banco de dados do aplicativo, migre os dados do aplicativo dos dados do HyperSQL para o novo banco de dados de aplicativo MySQL compartilhado.

Observação: faça backup do diretório do Looker. O processo de migração só pode ser feito de um banco de dados HyperSQL para um MySQL, e não 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 compartilhado

Somente tipos de arquivos específicos, como arquivos de modelo, chaves de implantação, plug-ins e arquivos de manifesto de aplicativo, pertencem ao sistema de arquivos compartilhado. Para configurar o sistema de arquivos compartilhado:

1. No servidor que vai armazenar o sistema de arquivos compartilhado, verifique se você tem acesso a outra conta que pode su à conta de usuário do Looker.
2. No servidor do sistema de arquivos compartilhado, faça login na conta de usuário do Looker.
3. Se o Looker estiver em execução, desligue a configuração dele.
4. Se você estava agrupando usando scripts do inotify Linux, pare 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 permissão para ler e gravar nele. No exemplo abaixo, o compartilhamento de rede é chamado /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 do modelo, para o compartilhamento de rede. 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 pode ter adicionado eles 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 compartilhado 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 requer 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 pode su à conta de usuário do Looker.

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

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

   Verifique se o diretório ssh-share é de propriedade do usuário do Looker e se as permissões são 700. Além disso, verifique se os diretórios acima de ssh-share (como /mnt e /mnt/looker-share) não são graváveis para todos ou para o 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 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
   

   Siga essa etapa para cada nó.

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

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

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 flags necessárias para iniciar ou ingressar em um cluster:

Sinalização	Obrigatório?	Valores	Motivo
--clustered	Sim		Adicione uma flag para especificar que este nó está sendo executado no modo 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 a comunicação entre nós.
-q	Não	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 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 dizer ao Looker:

• Para usar o arquivo chamado looker-db.yml para as credenciais do banco de dados,
• que é um nó agrupado 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

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

ssl: true

Observação: é necessário 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, de propriedade da conta de "usuário" do Linux em que o aplicativo Looker é executado. Esse arquivo nunca deve ser verificado em um repositório do Git.

Se você não quiser armazenar a configuração no arquivo looker-db.yml no disco, configure 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 versões mais recentes, as chaves de implantação são armazenadas em um diretório controlado pelo Looker, ~/looker/deploy_keys/PROJECT_NAME.

Modificar um cluster do Looker

Depois de criar um cluster do Looker, você pode adicionar ou remover nós sem fazer mudanças nos outros nós agrupados.

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ó de uma 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 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 podem não ser capturadas no novo banco de dados do aplicativo.

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

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