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 nó único ou em cluster:

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

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

• Balanceamento de carga
• Disponibilidade e failover aprimorados

Dependendo dos problemas de escalonamento, um Looker em cluster 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 é 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, aumente a memória e possivelmente o número de CPUs de um único servidor que executa o Looker. O Looker recomenda configurar o monitoramento detalhado de desempenho para o uso de memória e CPU, garantindo que o servidor do Looker tenha o tamanho adequado para a carga de trabalho.

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

Para configurações com até 50 usuários que usam o Looker com leveza, 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 percebem lentidão no aplicativo. Se esse for o caso, mova o Looker para um servidor maior ou execute uma configuração em cluster do Looker.

Disponibilidade/failover aprimorados

Executar o Looker em um ambiente em cluster pode reduzir a inatividade em caso de interrupção. A alta disponibilidade é importante principalmente se 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 gerencia automaticamente os nós que saem e entram no cluster.

Componentes obrigatórios

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

• Banco de dados do aplicativo 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. Em níveis mais altos, um 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 compartilhado de aplicativos MySQL, 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 (também 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, cada 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 do banco de dados de aplicativos para o Looker em cluster é o seguinte:

• Somente o MySQL é compatível com o banco de dados do aplicativo para instâncias em 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 suportados.

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 deve 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 do Looker Java em execução nele. Os servidores no cluster do Looker precisam conseguir 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 balancear as solicitações de carga ou redirecionamento para os nós disponíveis, é necessário um balanceador de carga ou servidor proxy (por exemplo, NGINX ou ELB da AWS) para direcionar o tráfego a cada nó do Looker. O balanceador de carga processa as verificações de integridade. Em caso de falha do nó, o balanceador de carga precisa ser configurado para redirecionar o tráfego para os outros nós íntegros.

Ao escolher e configurar o balanceador de carga, verifique se ele pode funcionar apenas como camada 4. O ELB clássico da Amazon é 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ê precisa usar um sistema de arquivos compartilhado 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 de várias informações usadas por todos os nós no cluster.

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

Aplicativo Looker (executável JAR)

Use um arquivo JAR do aplicativo Looker que esteja na versão 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 do aplicativo MySQL
3. Configurar o sistema de arquivos compartilhados
4. Compartilhe o repositório de chaves SSH (dependendo da situação)
5. Abra as portas para que os nós se comuniquem
6. Iniciar o Looker nos nós

Instalar o Looker

Verifique se você tem o Looker 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 hospedada pelo cliente.

Como configurar um banco de dados do aplicativo MySQL

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

Observação :faça backup do seu diretório do Looker. O processo de migração só pode ser feito de um banco de dados HyperSQL para um banco de dados MySQL, e não de forma inversa.

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.

Como configurar o sistema de arquivos compartilhado

Somente tipos de arquivos específicos — arquivos de modelo, chaves de implantação, plug-ins e, possivelmente, 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 para a 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, encerre sua configuração.
4. Se você usava scripts do inotify Linux, pare esses scripts, remova-os do cron e exclua-os.
5. Criar um compartilhamento de rede e montá-lo em cada nó no cluster. Verifique se ele está configurado para ser montado automaticamente em cada nó e se o usuário do Looker tem permissão para 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. Exemplo:

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

   Observação: suas chaves de implantação precisam ser copiadas para o armazenamento compartilhado e para cada nó do 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 seus LOOKERARGS não estiverem listados nesse arquivo, eles podem ter sido adicionados 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 registros exclusivo.

Como compartilhar o repositório de chaves SSH

• Você está criando um cluster de sistema de arquivos compartilhados usando uma configuração atual do Looker e
• Você tem projetos criados no Looker 4.6 ou anterior.

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 erros caso haja erros na configuração. Antes de realizar essas etapas, verifique se você tem acesso a outra conta que pode su a conta de usuário do Looker.

Configure o repositório de chaves SSH para compartilhar:

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 podem ser graváveis em todo o mundo nem 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
   

   Execute esta etapa para todos os nós.

Abrindo 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 extra baseado em secrets rotativos no banco de dados do aplicativo.

As portas padrão que precisam ser abertas entre os nós do cluster são 1551 e 61616. Essas portas podem ser configuradas usando os sinalizadores de inicialização listados aqui. É altamente recomendável 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.

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

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

Sinalização	Obrigatório?	Valores	Finalidade
--clustered	Sim		Adicionar sinalização para especificar que este nó está em execução 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 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	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 sinalização 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, informe ao Looker:

• Para usar o arquivo chamado looker-db.yml como credenciais de banco de dados,
• que é um nó em cluster e
• 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 conteria 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:você precisa 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, que pertencem ao "usuário" do Linux. conta em que o aplicativo Looker é executado. Nunca faça check-in desse arquivo em um repositório 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 onde 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 alterações de esquema no banco de dados interno do Looker que não seriam compatíveis com versões anteriores do Looker. Para atualizar o Looker, há dois métodos.

Método mais seguro

1. Criar 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 um nó 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 alterações 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 de aplicativos do Looker.
2. Inicie um novo cluster direcionado 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.