Agrupar o Looker

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

Vista geral

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

• Uma aplicação Looker de nó único, a configuração predefinida, tem todos os serviços que compõem a aplicação Looker a serem executados num único servidor.
• Uma configuração do Looker em cluster é uma configuração mais complexa, que envolve normalmente servidores de base de dados, balanceadores de carga e vários servidores que executam a aplicação Looker. Cada nó numa aplicação Looker agrupada é um servidor que executa uma única instância do Looker.

Existem dois motivos principais pelos quais uma organização quer executar o Looker como um cluster:

• Balanceamento de carga
• Disponibilidade e comutação por falha melhoradas

Consoante os problemas de escalabilidade, um Looker agrupado pode não oferecer a solução. Por exemplo, se um pequeno número de consultas grandes estiver a usar 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 equilibrar a carga do Looker, considere aumentar a memória e, possivelmente, o número de CPUs de um único servidor que execute o Looker. O Looker recomenda a configuração de uma monitorização detalhada do desempenho para a utilização da memória e da CPU, de modo a garantir que o servidor do Looker tem o tamanho adequado para a respetiva carga de trabalho.

As consultas grandes precisam de mais memória para um melhor desempenho. O agrupamento pode proporcionar ganhos de desempenho quando muitos utilizadores estão a executar pequenas consultas.

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

Disponibilidade/ativação pós-falha melhorada

A execução do Looker num ambiente agrupado pode mitigar o tempo de inatividade em caso de indisponibilidade. A elevada disponibilidade é especialmente importante se a API Looker for usada em sistemas empresariais essenciais ou se o Looker estiver incorporado em produtos virados para o cliente.

Numa configuração do Looker em cluster, um servidor proxy ou um equilibrador de carga reencaminha o tráfego quando determina que um nó está inativo. O Looker processa 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:

• Base de dados de aplicações MySQL
• Nós do Looker (servidores que executam o processo Java do Looker)
• Balanceador de carga
• Sistema de ficheiros partilhado
• Versão adequada dos ficheiros JAR da aplicação Looker

O diagrama seguinte ilustra a forma como os componentes interagem. A um nível elevado, um balanceador de carga distribui o tráfego de rede entre os nós do Looker agrupados. Cada nó comunica com uma base de dados de aplicações MySQL partilhada, um diretório de armazenamento partilhado e os servidores Git para cada projeto do LookML.

Base de dados de aplicações MySQL

O Looker usa uma base de dados de aplicações (muitas vezes denominada base de dados interna) para armazenar dados de aplicações. Quando o Looker é executado como uma aplicação de nó único, usa normalmente uma base de dados HyperSQL na memória.

Numa configuração do Looker agrupada, a instância do Looker de cada nó tem de apontar para uma base de dados transacional partilhada (a aplicação partilhada ou a base de dados interna). O apoio técnico da base de dados de aplicações para o Looker agrupado é o seguinte:

• Apenas o MySQL é suportado para a base de dados da aplicação para instâncias do Looker agrupadas. O Amazon Aurora e o MariaDB não são suportados.
• As versões 5.7 e 8.0 do MySQL são suportadas.
• As bases de dados agrupadas, como o Galera, não são suportadas.

Nota: recomenda-se uma base de dados de réplica de leitura para melhorar o desempenho e a redundância. A base de dados de réplica de leitura não tem de ser uma base de dados do MySQL.

O Looker não gere a manutenção nem as cópias de segurança dessa base de dados. No entanto, uma vez que a base de dados aloja quase todos os dados de configuração da aplicação Looker, deve ser aprovisionada como uma base de dados de alta disponibilidade e ter uma cópia de segurança, 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 têm de conseguir comunicar entre si e com a base de dados da aplicação Looker. As portas predefinidas estão listadas em Abra as portas para os nós comunicarem nesta página.

Balanceador de carga

Para equilibrar a carga ou redirecionar pedidos para nós disponíveis, é necessário um equilibrador de carga ou um servidor proxy (por exemplo, NGINX ou AWS ELB) para direcionar o tráfego para cada nó do Looker. O balanceador de carga processa as verificações de funcionamento. Em caso de falha de um nó, o balanceador de carga tem de ser configurado para redirecionar o tráfego para os nós em bom estado restantes.

Ao escolher e configurar o equilibrador de carga, certifique-se de que pode ser configurado para funcionar apenas na camada 4. O Amazon Classic ELB é um desses exemplos. Além disso, o balanceador de carga deve ter um limite de tempo longo (3600 segundos) para evitar que as consultas sejam terminadas.

Sistema de ficheiros partilhado

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

Nota: a instalação de aplicações e ferramentas a partir do Looker Marketplace requer a utilização de um sistema de ficheiros partilhado (de rede).

Aplicação Looker (executável JAR)

Tem de usar um ficheiro JAR da aplicação Looker que seja o Looker 3.56 ou posterior.

Nota: a partir do Looker 6.18, o ficheiro JAR do Looker foi dividido em dois ficheiros JAR separados: o ficheiro JAR principal do Looker e um ficheiro JAR de dependências do Looker. Se estiver a instalar ou a atualizar para o Looker 6.18 ou posterior, certifique-se de que transfere ambos os ficheiros JAR.

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

Configurar o cluster

As seguintes tarefas são obrigatórias:

1. Instale o Looker
2. Configure uma base de dados de aplicações MySQL
3. Configure o sistema de ficheiros partilhado
4. Partilhe o repositório de chaves SSH (consoante a sua situação)
5. Abra as portas para que os nós comuniquem
6. Inicie o Looker nos nós

Instalar o Looker

Certifique-se de que tem o Looker instalado em cada nó, usando os ficheiros JAR da aplicação Looker e as instruções na página de documentação Passos de instalação alojada pelo cliente.

Configurar uma base de dados de aplicações MySQL

Para uma configuração do Looker em cluster, a base de dados da aplicação tem de ser uma base de dados do MySQL. Se tiver uma instância do Looker não agrupada que esteja a usar o HyperSQL para a base de dados da aplicação, tem de migrar os dados da aplicação dos dados do HyperSQL para a nova base de dados da aplicação MySQL partilhada.

Nota: certifique-se de que faz uma cópia de segurança do diretório do Looker. O processo de migração só pode ser feito de uma base de dados HyperSQL para uma base de dados MySQL e não ao contrário.

Consulte a página de documentação Migrar para o MySQL para obter informações sobre como fazer uma cópia de segurança do Looker e, em seguida, migrar a base de dados da aplicação do HyperSQL para o MySQL.

Configurar o sistema de ficheiros partilhado

Apenas tipos de ficheiros específicos, como ficheiros de modelos, chaves de implementação, plug-ins e, potencialmente, ficheiros de manifesto de aplicações, pertencem ao sistema de ficheiros partilhado. Para configurar o sistema de ficheiros partilhado:

1. No servidor que vai armazenar o sistema de ficheiros partilhado, verifique se tem acesso a outra conta que possa su à conta de utilizador do Looker.
2. No servidor do sistema de ficheiros partilhado, inicie sessão na conta de utilizador do Looker.
3. Se o Looker estiver em execução, encerre a configuração do Looker.
4. Se estava anteriormente a agrupar usando scripts Linux inotify, pare esses scripts, remova-os do cron e elimine-os.
5. Crie uma partilha de rede e monte-a em cada nó no cluster. Certifique-se de que está configurado para montagem automática em cada nó e que o utilizador do Looker tem a capacidade de ler e escrever no mesmo. No exemplo seguinte, a partilha de rede tem o nome /mnt/looker-share.

6. Num nó, copie as chaves de implementação e mova os plug-ins e os diretórios looker/models e looker/models-user-*, que armazenam os ficheiros de modelo, para a partilha de rede. Por exemplo:

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

   Nota: as chaves de implementação têm de ser copiadas para o armazenamento partilhado e para todos os nós no cluster.

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

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

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

   Cada nó no cluster tem de escrever num diretório /log exclusivo ou, pelo menos, num ficheiro de registo exclusivo.

Partilhar o repositório de chaves SSH

• Está a criar um cluster de sistema de ficheiros partilhado a partir de uma configuração do Looker existente e
• Tem projetos criados no Looker 4.6 ou anterior.

Nota: o procedimento seguinte requer a modificação do diretório $HOME/.ssh do utilizador do Looker. Isto pode dificultar o início de sessão e a correção de algo se existirem erros na configuração. Antes de realizar estes passos, certifique-se de que tem acesso a outra conta que possa su à conta de utilizador do Looker.

Configure o repositório de chaves SSH para partilha:

1. No servidor de ficheiros partilhado, crie um diretório denominado ssh-share. Por exemplo: /mnt/looker-share/ssh-share.

   Certifique-se de que o diretório ssh-share é propriedade do utilizador do Looker e que as autorizações são 700. Além disso, certifique-se de que os diretórios acima do diretório ssh-share (como /mnt e /mnt/looker-share) não são graváveis por todos nem graváveis por grupos.

2. Num 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 uma cópia de segurança do ficheiro SSH existente 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
   

   Certifique-se de que realiza este passo para cada nó.

Abrir as portas para os nós comunicarem

Os nós do Looker agrupados comunicam entre si através de HTTPS com certificados autoassinados e um esquema de autenticação adicional baseado na rotação de segredos na base de dados da aplicação.

As portas predefinidas que têm de estar abertas entre os nós do cluster são 1551 e 61616. Estas portas são configuráveis através das flags de arranque indicadas aqui. Recomendamos vivamente que restrinja o acesso à rede a estas portas para permitir o tráfego apenas entre os anfitriões do cluster.

Iniciar o Looker nos nós

Reinicie o servidor em cada nó com as flags de arranque necessárias.

Nota: cada nó num cluster tem de executar a mesma versão de lançamento e patch do Looker.

Flags de arranque disponíveis

A tabela seguinte mostra as flags de arranque disponíveis, incluindo as flags necessárias para iniciar ou juntar-se a um cluster:

Bandeira	Obrigatório?	Valores	Finalidade
--clustered	Sim		Adicione uma flag para especificar que este nó está a ser executado no modo de cluster.
-H ou --hostname	Sim	10.10.10.10	O nome de anfitrião que outros nós usam para contactar este nó, como o endereço IP do nó ou o nome de anfitrião do sistema. Tem de ser diferente dos nomes de anfitrião de todos os outros nós no cluster.
-n	Não	1551	A porta para comunicação entre nós. A predefinição é 1551. Todos os nós têm de usar o mesmo número de porta para a comunicação entre nós.
-q	Não	61616	A porta para colocar eventos em fila de espera ao nível do cluster. A predefinição é 61616.
-d	Sim	/path/to/looker-db.yml	O caminho para o ficheiro que contém as credenciais da base de dados da aplicação Looker.
--shared-storage-dir	Sim	/path/to/mounted/shared/storage	A opção deve apontar para a configuração do diretório partilhado anteriormente nesta página que contém os diretórios looker/model e looker/models-user-*.

Nota: a flag de inicialização --clustered não deve incluir um valor.

Exemplo de LOOKERARGS e especificação das credenciais da base de dados

Coloque as flags de arranque do Looker num ficheiro lookerstart.cfg, localizado no mesmo diretório que os ficheiros JAR do Looker.

Por exemplo, pode querer dizer ao Looker:

• Para usar o ficheiro denominado looker-db.yml para as respetivas credenciais da base de dados:
• que é um nó agrupado e
• que os outros nós do cluster devem contactar este anfitrião no endereço IP 10.10.10.10.

Especificaria:

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

Nota: certifique-se de que especifica o endereço IP correto para o seu nó.

O ficheiro looker-db.yml conteria as credenciais da base de dados, como:

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

Além disso, se a sua base de dados MySQL exigir uma ligação SSL, o ficheiro looker-db.yml também requer o seguinte:

ssl: true

Nota: tem de armazenar uma cópia do ficheiro de credenciais no armazenamento partilhado e em todos os nós no cluster.

Nota: siga as considerações de segurança das práticas recomendadas quando guardar credenciais num ficheiro. Idealmente, defina as autorizações de ficheiros looker-db.yml como 600, pertencentes à conta "user" do Linux na qual a aplicação Looker é executada. Este ficheiro nunca deve ser adicionado a um repositório Git.

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

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

Encontrar as chaves de implementação de SSH do Git

O local onde o Looker armazena as chaves de implementaçã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 implementação são armazenadas no diretório SSH incorporado do servidor, ~/.ssh.
• Para projetos criados no Looker 4.8 ou posterior, as chaves de implementação são armazenadas num diretório controlado pelo Looker, ~/looker/deploy_keys/PROJECT_NAME.

Modificar um cluster do Looker

Depois de criar um cluster do Looker, pode adicionar ou remover nós sem fazer alterações aos outros nós agrupados.

Atualizar um cluster para uma nova versão do Looker

As atualizações podem envolver alterações ao esquema da base de dados interna do Looker que não seriam compatíveis com versões anteriores do Looker. Existem dois métodos para atualizar o Looker.

Método mais seguro

1. Crie uma cópia de segurança da base de dados da aplicação.
2. Pare todos os nós do cluster.
3. Substitua os ficheiros JAR em cada servidor.
4. Inicie cada nó um de cada vez.

Método mais rápido

Nota: este método diminui o tempo de inatividade, mas perde todas as alterações feitas entre a criação da réplica e a indicação dos novos nós ao servidor proxy. Por exemplo, se alguém adicionar utilizadores ou criar aparências durante a transição, essas alterações podem não ser captadas na nova base de dados da aplicação.

Para fazer a atualização através deste método mais rápido, mas menos completo:

1. Crie uma réplica da base de dados da aplicação do Looker.
2. Inicie um novo cluster apontado para a réplica.
3. Direcione o servidor proxy ou o equilibrador de carga para os novos nós. Depois, pode parar os nós antigos.