Looker em cluster

Neste tutorial, explicamos o método recomendado para criar uma configuração em cluster do Looker.

Visão geral

O aplicativo Looker pode executar nós únicos ou em cluster:

  • O aplicativo Looker de nó único, a configuração padrão, 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 é uma configuração 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 querer executar o Looker como um cluster:

  • Balanceamento de carga
  • Melhor disponibilidade e failover

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 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 CPU 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 esteja adequadamente dimensionado para sua carga de trabalho.

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

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

Disponibilidade/failover melhorado

Executar o Looker em um ambiente em cluster pode reduzir a inatividade em caso de falha. A alta disponibilidade é importante principalmente se a API Looker for usada nos principais sistemas de negócios ou se o Looker estiver incorporado em 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 em cluster do Looker:

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

O diagrama a seguir ilustra como os componentes interagem:

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

  • O MySQL só oferece suporte ao banco de dados do aplicativo em instâncias em cluster do Looker. A Amazon Aurora e o MariaDB não são compatíveis.
  • As versões 5.7 e 8.0 ou mais recentes do MySQL são compatíveis.
  • Bancos de dados em cluster, como Galera, não são compatíveis.

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 de aplicativos do Looker, ele deve ser provisionado como um banco de dados de alta disponibilidade e armazenado em backup pelo menos diariamente.

Nós do Looker

Cada nó é um servidor com o processo Java do Looker em execução nele. Os servidores no cluster do Looker precisam ser capazes de acessar uns aos outros e ao banco de dados do aplicativo do 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 equilibrar as solicitações de carregamento ou de redirecionamento aos nós disponíveis, é necessário um balanceador de carga ou um 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 como a camada 4. O ELB clássico da Amazon é um desses exemplos. Além disso, o balanceador de carga deve ter um longo tempo limite (3.600 segundos) para evitar que as consultas sejam eliminadas.

Sistema de arquivos compartilhados

Use um sistema de arquivos compartilhados em conformidade com POSIX (como NFS, AWS EFS, Gluster, BeeGFS, Lustre, entre 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.

A instalação de aplicativos e ferramentas do Looker Marketplace requer o uso de um sistema de arquivos compartilhados (rede).

Aplicativo Looker (executável JAR)

Você precisa usar um arquivo JAR do aplicativo do Looker que seja o Looker 3.56 ou mais recente.

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 obrigató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 da chave SSH (dependendo da sua situação).
  5. Abra 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 do Looker e as instruções na página de documentação Etapas de instalação hospedada pelo cliente.

Como configurar um banco de dados de aplicativos MySQL

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

Faça backup do diretório do Looker. O processo de migração só pode ir de um banco de dados do HyperSQL para um banco de dados MySQL, não no sentido inverso.

Consulte a página de documentação Como migrar para o MySQL para ver informações sobre como fazer backup do Looker e, em seguida, migrar o banco de dados do aplicativo do HyperSQL para MySQL.

Configurar o sistema de arquivos compartilhados

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

  1. No servidor que 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, encerre sua configuração do Looker.
  4. Se você estava agrupando em cluster usando scripts do Linux inotify, interrompa esses scripts, remova-os do cron e os exclua.
  5. Crie e compartilhe um compartilhamento de rede em cada nó do cluster. Verifique se ele está configurado para ser montado automaticamente em cada nó e se o usuário do Looker consegue ler e gravar nele. No exemplo a seguir, o compartilhamento de rede é chamado de /mnt/looker-share.

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

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

  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

    É necessário adicionar LOOKERARGS 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, é possível que eles tenham sido adicionados diretamente ao script de shell $HOME/looker/looker.

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

Como compartilhar o repositório de chaves SSH

  • Você está criando um cluster compartilhado do sistema de arquivos com base em uma configuração atual do Looker.
  • Você tem projetos criados no Looker 4.6 ou versões anteriores.

O procedimento a seguir requer a modificação do $HOME/.ssh directory do usuário do Looker. Isso pode dificultar o login e uma correção quando há erros na configuração. Confira se você tem acesso a outra conta que pode usar a su para a conta de usuário do Looker antes de executar estas etapas.

Configure o repositório da chave 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 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 em todo o mundo ou graváveis 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 os nós se comunicarem

Os nós em cluster do Looker se comunicam entre si por HTTPS com certificados autoassinados e um esquema de autenticação adicional baseado em rotação de secrets 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 as sinalizações de inicialização listadas aqui. É altamente recomendável restringir o acesso à rede a essas portas para permitir o tráfego somente entre os hosts de clusters.

Como iniciar o Looker nos nós

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

Cada nó em um cluster precisa executar a mesma versão de lançamento e de patch.

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

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

Sinalização Obrigatório? Valores Finalidade
--clustered Yes Adicione uma sinalização para especificar que esse nó está em execução no modo em cluster.
-H ou --hostname Yes 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 do nó ou o nome do host do sistema dele. Precisa ser diferente dos nomes do host de todos os outros nós no 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 comunicação entre nós.
-q No 61616 A porta para colocar eventos em todo o cluster. O padrão é 61616.
-d Yes /path/to/looker-db.yml O caminho para o arquivo que contém as credenciais do banco de dados do aplicativo do Looker.
--shared-storage-dir Yes /path/to/mounted/shared/storage A opção precisa apontar para a configuração do diretório compartilhado antes desta página que contém os diretórios looker/model e looker/models-user-*.

A sinalização de inicialização da --clustered não precisa 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.

Talvez você queira dizer ao Looker:

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

Especifique o endereço IP correto do 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

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

ssl: true

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 do Linux "user" 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, defina a variável de ambiente LOOKER_DB para conter uma lista de chaves/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 chaves de implantação SSH do Git

Onde o Looker armazena chaves de implantação SSH 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 nativo do servidor, ~/.ssh.
  • Para projetos criados no Looker 4.8 ou posterior, 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 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 são compatíveis com versões anteriores do Looker. Para atualizar o Looker, existem dois métodos.

Método mais seguro

  1. Criar um backup do banco de dados do aplicativo.
  2. Interromper todos os nós do cluster.
  3. Substitua os arquivos JAR de cada servidor.
  4. Inicie cada nó um de cada vez.

Método mais rápido

Esse método diminui a 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 aparência durante a transição, essas alterações não serão capturadas no novo banco de dados de aplicativos.

Para atualizar usando este 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 cluster novo 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.