Soluções de arquitetura hospedadas pelo cliente: tutoriais de componentes

Nesta página, exploramos práticas comuns para componentes específicos da arquitetura do Looker e descrevemos como configurá-los em uma implantação.

O Looker tem várias dependências para hospedar o servidor, atender cargas de trabalho ad hoc e programadas, rastrear o desenvolvimento iterativo de modelos ou semelhantes. Essas dependências são chamadas de componentes nesta página, e cada uma delas é abordada em detalhes nas seções a seguir:

Configuração do host

SO e distribuição

O Looker funciona bem nas versões mais comuns do Linux: RedHat, SUSE e Debian/Ubuntu. Derivados dessas distribuições projetados e otimizados para serem executados em um ambiente específico geralmente são adequados. Por exemplo, as distribuições Google Cloud ou AWS do Linux são compatíveis com o Looker. O Debian/Ubuntu é a variedade do Linux mais usada na comunidade do Looker, e essas são as versões mais conhecidas pelo suporte do Looker. A maneira mais fácil é usar o Debian/Ubuntu ou um sistema operacional para um provedor de nuvem específico derivado do Debian/Ubuntu.

O Looker é executado na máquina virtual Java (JVM). Ao escolher uma distribuição, considere se as versões do OpenJDK 11 estão atualizadas. Distribuições mais antigas do Linux podem executar o Looker, mas a versão e as bibliotecas do Java necessárias para recursos específicos precisam estar atualizadas. Se a JVM não tiver todas as bibliotecas e versões recomendadas do Looker, ele não vai funcionar normalmente. O Looker exige o Java HotSpot 1.8 update 161+ ou o Java OpenJDK 11.0.12+.

CPU e memória

Nós 4x16 (4 CPUs e 16 GB de RAM) são suficientes para um sistema de desenvolvimento ou uma instância básica de teste do Looker usada por uma equipe pequena. No entanto, para uso em produção, isso geralmente não é suficiente. Na nossa experiência, 16 nós de 64 (16 CPUs e 64 GB de RAM) são um bom equilíbrio entre preço e desempenho. Mais de 64 GB de RAM podem afetar o desempenho, já que os eventos de coleta de lixo são de uma única linha de execução e interrompem todas as outras para serem executados.

Armazenamento em disco

Normalmente, 100 GB de espaço em disco são mais do que suficientes para um sistema de produção.

Considerações sobre o cluster

O Looker é executado em uma JVM Java, e o Java pode ter dificuldade em gerenciar memória maior que 64 GB. Como regra geral, se for necessária mais capacidade, adicione mais nós 16x64 ao cluster em vez de aumentar o tamanho dos nós além de 16x64. Também podemos preferir usar uma arquitetura em cluster para aumentar a disponibilidade.

Em um cluster, os nós do Looker precisam compartilhar determinadas partes do sistema de arquivos. Os dados compartilhados incluem o seguinte:

  • Modelos do LookML
  • Os modelos do LookML do desenvolvedor
  • Conectividade do servidor Git

Como o sistema de arquivos é compartilhado e hospeda vários repositórios Git, o tratamento do acesso simultâneo e do bloqueio de arquivos é essencial. O sistema de arquivos precisa ser compatível com POSIX. O sistema de arquivos de rede (NFS) funciona e está disponível com o Linux. Crie outra instância do Linux e configure o NFS para compartilhar o disco. O NFS padrão pode ser um único ponto de falha. Por isso, considere uma configuração de failover ou de alta disponibilidade.

Os metadados do Looker também precisam ser centralizados, então o banco de dados interno precisa ser migrado para o MySQL. Pode ser um serviço MySQL ou uma implantação dedicada do MySQL. A seção Banco de dados interno (back-end) desta página explica melhor.

Configuração da JVM

As configurações da JVM do Looker são definidas no script de inicialização do Looker. Depois de qualquer atualização, o Looker precisa ser reiniciado para que as mudanças apareçam. As configurações padrão são as seguintes: 

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

Recursos

As configurações de recursos são definidas no script de inicialização do Looker. 

JAVAMEM="2300m"
METAMEM="800m"

A alocação de memória para a JVM precisa considerar a sobrecarga do sistema operacional em que o Looker está sendo executado. A regra geral é que a JVM pode receber até 60% da memória total, mas há ressalvas dependendo do tamanho da máquina. Para máquinas com o mínimo de 8 GB de memória total, recomendamos uma alocação de 4 a 5 GB para Java e 800 MB para Meta. Para máquinas maiores, uma proporção menor de memória pode ser alocada para o sistema operacional. Por exemplo, para máquinas com 60 GB de memória total, recomendamos uma alocação de 36 GB para Java e 1 GB para Meta. É importante observar que a alocação de memória do Java geralmente é dimensionada com a memória total da máquina, mas o Meta é suficiente com 1 GB.

Além disso, como o Looker compartilha recursos do sistema com outros processos, como o Chromium para renderização, a quantidade de memória alocada para o Java precisa ser selecionada no contexto da carga de renderização prevista e do tamanho da máquina. Se a carga de renderização for baixa, o Java poderá receber uma parte maior da memória total. Por exemplo, em uma máquina com 60 GB de memória total, o Java pode ser alocado com segurança para 46 GB, o que é maior do que a recomendação geral de 60%. As alocações de recursos exatas adequadas para cada implantação variam. Use 60% como um valor de referência e ajuste conforme o uso.

Coleta de lixo

O Looker prefere usar o coletor de lixo mais moderno disponível para a versão do Java. Por padrão, o tempo limite da coleta de lixo é de dois segundos, mas isso pode ser alterado editando a seguinte opção na configuração de inicialização: 

-XX:MaxGCPauseMillis=2000

Em uma máquina maior com vários núcleos, o tempo limite da coleta de lixo pode ser reduzido.

Registros

Por padrão, os registros de coleta de lixo do Looker são armazenados em /tmp/gc.log. Isso pode ser mudado ao editar a seguinte opção na configuração de inicialização: 

-Xloggc:/tmp/gc.log

JMX

O gerenciamento do Looker pode precisar de monitoramento para ajudar a refinar o provisionamento de recursos. Recomendamos usar o JMX para monitorar o uso da memória da JVM.

Opções de inicialização do Looker

As opções de inicialização são armazenadas em um arquivo chamado lookerstart.cfg. Esse arquivo é originado no script shell que inicia o Looker.

Pools de linhas de execução

Como um aplicativo multithread, o Looker tem vários pools de threads. Esses pools de linhas de execução variam do servidor Web principal a subserviços especializados, como programação, renderização e conexões de banco de dados externos. Dependendo dos fluxos de trabalho da sua empresa, talvez seja necessário modificar esses pools na configuração padrão. Em particular, há considerações especiais para as topologias de cluster mencionadas na página Padrões e práticas de arquitetura de infraestrutura hospedada pelo cliente.

Opções de alta capacidade de processamento de programação

Para todos os nós que não são programadores, adicione --scheduler-threads=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem threads do programador, nenhum job agendado será executado nesses nós.

Para todos os nós de programador dedicados, adicione --scheduler-threads=<n> à variável de ambiente LOOKERARGS em lookerstart.cfg. O Looker começa com 10 linhas de execução do programador por padrão, mas esse número pode ser aumentado para <n>. Com <n> linhas de execução do programador, cada nó poderá executar <n> jobs de programação simultâneos. Em geral, é recomendável manter <n> menor que o dobro do número de CPUs. O maior host recomendado tem 16 CPUs e 64 GB de memória. Portanto, o limite superior de linhas de execução do programador precisa ser menor que 32.

Opções de alta capacidade de renderização

Para todos os nós que não são de renderização, adicione --concurrent-render-jobs=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem nós de renderização, nenhuma tarefa de renderização será executada nesses nós.

Para todos os nós de renderização dedicados, adicione --concurrent-render-jobs=<n> à variável de ambiente LOOKERARGS em lookerstart.cfg. O Looker começa com duas linhas de execução de renderização por padrão, mas isso pode ser aumentado para <n>. Com <n> linhas de execução de renderização, cada nó poderá executar <n> jobs de renderização simultâneos.

Cada job de renderização pode usar uma quantidade significativa de memória. Reserve cerca de 2 GB por job de renderização. Por exemplo, se o processo principal do Looker (Java) receber 60% da memória total e 20% da memória restante for reservada para o sistema operacional, os últimos 20% serão para jobs de renderização. Em uma máquina de 64 GB, isso deixa 12 GB, o que é suficiente para 6 jobs de renderização simultâneos. Se um nó for dedicado à renderização e não estiver incluído no pool do balanceador de carga que processa jobs interativos, a memória do processo principal do Looker poderá ser reduzida para permitir mais jobs de renderização. Em uma máquina de 64 GB, é possível alocar aproximadamente 30% (20 GB) para o processo principal do Looker. Reservando 20% para uso geral do SO, restam 50% (32 GB) para renderização, o que é suficiente para 16 jobs de renderização simultâneos.

Banco de dados interno (back-end)

O servidor do Looker mantém informações sobre a própria configuração, conexões de banco de dados, usuários, grupos e funções, pastas, Looks e painéis definidos pelo usuário e vários outros dados em um banco de dados interno.

Para uma instância independente do Looker de tamanho moderado, esses dados são armazenados em um banco de dados HyperSQL na memória incorporado ao próprio processo do Looker. Os dados desse banco de dados são armazenados no arquivo <looker install directory>/.db/looker.script. Embora seja conveniente e leve, esse banco de dados tem problemas de desempenho com uso intenso. Portanto, recomendamos começar com um banco de dados MySQL remoto. Se isso não for possível, recomendamos a migração para um banco de dados MySQL remoto quando o arquivo ~/looker/.db/looker.script atingir 600 MB. Os clusters precisam usar um banco de dados MySQL.

O servidor do Looker faz muitas leituras e gravações pequenas no banco de dados MySQL. Sempre que um usuário executa um Look ou uma análise detalhada, o Looker verifica o banco de dados para confirmar se o usuário ainda está conectado, se tem privilégios para acessar os dados, se tem privilégios para executar o Look ou a análise detalhada e assim por diante. O Looker também grava dados no banco de dados MySQL, como o SQL real que foi executado e o horário de início e fim da solicitação. Uma única interação entre um usuário e o aplicativo Looker pode resultar em 15 ou 20 pequenas leituras e gravações no banco de dados MySQL.

MySQL

O servidor MySQL precisa ser da versão 8.0.x e estar configurado para usar a codificação utf8mb4. O mecanismo de armazenamento InnoDB precisa ser usado. As instruções de configuração do MySQL, bem como as instruções de como migrar dados de um banco de dados HyperSQL para o MySQL, estão disponíveis na página de documentação Migrar o banco de dados de back-end do Looker para o MySQL.

Ao configurar o Looker para usar o MySQL, é necessário criar um arquivo YAML com as informações de conexão. Nomeie o arquivo YAML como looker-db.yml e adicione a configuração -d looker-db.yml na seção LOOKERARGS do arquivo lookerstart.cfg.

MariaDB

O MySQL tem dupla licença e está disponível como código aberto e como produto comercial. A Oracle continuou aprimorando o MySQL, que foi ramificado como MariaDB. As versões equivalentes do MariaDB para MySQL funcionam com o Looker, mas não são desenvolvidas nem testadas pelas equipes de engenharia do Looker. Portanto, a funcionalidade não é compatível nem garantida.

Versões do Cloud

Se você hospedar o Looker na sua infraestrutura em nuvem, é lógico hospedar o banco de dados MySQL na mesma infraestrutura em nuvem. Os três principais fornecedores de nuvem: Amazon AWS, Microsoft Azure e Google Cloud. Os provedores de nuvem gerenciam grande parte da manutenção e configuração do banco de dados MySQL e oferecem serviços como ajuda no gerenciamento de backups e recuperação rápida. Esses produtos funcionam bem com o Looker.

Consultas de atividade do sistema

O banco de dados MySQL é usado para armazenar informações sobre como os usuários estão usando o Looker. Qualquer usuário do Looker com permissão para acessar o modelo Atividade do sistema tem acesso a vários painéis pré-criados do Looker para analisar esses dados. Os usuários também podem acessar as Análises detalhadas de metadados do Looker para criar outras análises. O banco de dados MySQL é usado principalmente para consultas pequenas, rápidas e "operacionais". As consultas grandes, lentas e "analíticas" geradas pelo modelo de atividade do sistema podem competir com essas consultas operacionais e diminuir a velocidade do Looker.

Nesses casos, o banco de dados MySQL pode ser replicado para outro banco de dados. Os sistemas autogerenciados e alguns gerenciados na nuvem oferecem configuração básica de replicação para outros bancos de dados. A configuração da replicação está fora do escopo deste documento.

Para usar a réplica nas consultas de atividade do sistema, crie uma cópia do arquivo looker-db.yml, por exemplo, chamada looker-usage-db.yml, modifique-a para apontar para a réplica e adicione a configuração --internal-analytics-connection-file looker-usage-db.yml à seção LOOKERARGS do arquivo lookerstart.cfg.

As consultas de atividade do sistema podem ser executadas em uma instância do MySQL ou em um banco de dados do Google BigQuery. Elas não são testadas em relação a outros bancos de dados.

Configuração de desempenho do MySQL

Além das configurações necessárias para migrar o banco de dados de back-end do Looker para o MySQL, os clusters altamente ativos podem se beneficiar de mais ajustes e configurações. Essas configurações podem ser feitas no arquivo /etc/my.cnf ou no console Google Cloud para instâncias gerenciadas na nuvem.

O arquivo de configuração my.cnf é dividido em várias partes. As seguintes mudanças de configuração discutidas nesta seção são feitas na parte [mysqld].

Definir o tamanho do pool de buffer do InnoDB

O tamanho do pool de buffer do InnoDB é a RAM total usada para armazenar o estado dos arquivos de dados do InnoDB na memória. Se o servidor for dedicado à execução do MySQL, o innodb_buffer_pool_size deverá ser definido como 50% a 70% da memória total do sistema.

Se o tamanho total do banco de dados for pequeno, é permitido definir o pool de buffer do InnoDB como o tamanho do banco de dados em vez de 50% ou mais da memória.

Neste exemplo, um servidor tem 64 GB de memória. Portanto, o pool de buffers do InnoDB precisa ter entre 32 GB e 45 GB. Quanto maior, melhor. 

[mysqld]
...
innodb_buffer_pool_size=45G

Definir as instâncias do pool de buffer do InnoDB

Quando várias linhas de execução tentam pesquisar um grande pool de buffers, elas podem entrar em conflito. Para evitar isso, o pool de buffers é dividido em unidades menores que podem ser acessadas por diferentes linhas de execução sem conflito. Por padrão, o pool de buffers é dividido em oito instâncias. Isso cria um possível gargalo de oito linhas de execução. Aumentar o número de instâncias do pool de buffer reduz a chance de um gargalo. O innodb_buffer_pool_instances precisa ser definido para que cada pool de buffers receba pelo menos 1 GB de memória. 

[mysqld]
...
innodb_buffer_pool_instances=32

Otimizar o arquivo de registro do InnoDB

Quando uma transação é confirmada, o banco de dados pode atualizar os dados no arquivo real ou salvar detalhes sobre a transação no registro. Se o banco de dados falhar antes da atualização dos arquivos de dados, o arquivo de registro poderá ser "reproduzido" para aplicar as mudanças. A gravação no arquivo de registro é uma pequena operação de anexação. É eficiente anexar ao registro no momento da confirmação e, em seguida, agrupar várias mudanças nos arquivos de dados e gravá-las em uma única operação de E/S. Quando o arquivo de registro é preenchido, o banco de dados precisa pausar o processamento de novas transações e gravar todos os dados alterados de volta no disco.

Como regra geral, o arquivo de registro do InnoDB precisa ser grande o suficiente para conter uma hora de transações.

Normalmente, há dois arquivos de registros do InnoDB. Eles precisam ser cerca de 25% do seu pool de buffer do InnoDB. Para um banco de dados de exemplo com um pool de buffer de 32 GB, os arquivos de registro do InnoDB devem totalizar 8 GB ou 4 GB por arquivo. 

[mysqld]
...
innodb_log_file_size=8GB

Configurar a capacidade de E/S do InnoDB

O MySQL vai limitar a velocidade em que as gravações são registradas no disco para não sobrecarregar o servidor. Os valores padrão são conservadores para a maioria dos servidores. Para ter o melhor desempenho, use o utilitário sysbench para medir a velocidade de gravação aleatória no disco de dados e use esse valor para configurar a capacidade de E/S para que o MySQL grave dados mais rapidamente.

Em um sistema hospedado na nuvem, o fornecedor de serviços em nuvem precisa informar o desempenho dos discos usados para armazenamento de dados. Para um servidor MySQL autohospedado, meça a velocidade de gravações aleatórias no disco de dados em operações de E/S por segundo (IOPS). O utilitário do Linux sysbench é uma maneira de medir isso. Use esse valor para innodb_io_capacity_max e um valor de metade a três quartos para innodb_io_capacity. Portanto, no exemplo a seguir, veríamos os valores se medíssemos 800 IOPS. 

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

Configurar threads do InnoDB

O MySQL abre pelo menos uma linha de execução para cada cliente atendido. Se muitos clientes estiverem conectados simultaneamente, isso poderá levar a um grande número de linhas de execução sendo processadas. Isso pode fazer com que o sistema passe mais tempo trocando do que processando.

Faça comparativos de mercado para determinar o número ideal de linhas de execução. Para testar, defina o número de linhas de execução entre o número de CPUs (ou núcleos de CPU) no sistema e 4 vezes o número de CPUs. Em um sistema de 16 núcleos, esse valor provavelmente está entre 16 e 64. 

[mysqld]
...
innodb_thread_concurrency=32

Durabilidade da transação

Um valor de transação de 1 força o MySQL a gravar no disco a cada transação. Se o servidor falhar, a transação não será perdida, mas o desempenho do banco de dados será afetado. Definir esse valor como 0 ou 2 pode melhorar o desempenho, mas há o risco de perder alguns segundos de transações de dados. 

[mysqld]
...
innodb_flush_log_at_trx_commit=1

Definir o método de descarga

Normalmente, o sistema operacional faz o buffer das gravações no disco. Como o MySQL e o SO estão armazenando em buffer, há uma penalidade de desempenho. Reduzir o método de descarga em uma camada de buffer pode melhorar o desempenho. 

[mysqld]
...
innodb_flush_method=O_DIRECT

Ativar um arquivo por tabela

Por padrão, o MySQL usa um único arquivo de dados para todos os dados. A configuração innodb_file_per_table cria um arquivo separado para cada tabela, o que melhora o desempenho e o gerenciamento de dados. 

[mysqld]
...
innodb_file_per_table=ON

Desativar estatísticas nos metadados

Essa configuração desativa a coleta de estatísticas em tabelas de metadados internos, melhorando a performance de leitura. 

[mysqld]
...
innodb_stats_on_metadata=OFF

Desativar o cache de consultas

O cache de consultas foi descontinuado. Portanto, definir query_cache_size e query_cache_type como 0 o desativa. 

[mysqld]
...
query_cache_size=0
query_cache_type=0

Ampliar o buffer de junções

O join_buffer é usado para realizar junções na memória. Aumentar esse valor pode melhorar algumas operações. 

[mysqld]
...
join_buffer_size=512KB

Aumentar os tamanhos da tabela temporária e do heap máximo

Os parâmetros tmp_table_size e max_heap_table_size definem padrões razoáveis para tabelas temporárias na memória antes de serem gravadas no disco. 

[mysqld
...
tmp_table_size=32MB
max_heap_table_size=32MB

Ajustar o cache de tabela aberta

A configuração table_open_cache determina o tamanho do cache que contém os descritores de arquivos para tabelas abertas. A configuração table_open_cache_instances divide o cache em várias partes menores. Há um potencial de disputa de threads no table_open_cache. Por isso, dividi-lo em partes menores ajuda a aumentar a simultaneidade. 

[mysqld]
...
table_open_cache=2048
table_open_cache_instances=16

Serviço Git

O Looker foi projetado para funcionar com um serviço do Git e oferecer gerenciamento de versões dos arquivos LookML. Os principais serviços de hospedagem Git são compatíveis, incluindo GitHub, GitLab e Bitbucket. Os provedores de serviços do Git oferecem outros recursos de valor agregado, como uma GUI para visualizar mudanças no código e suporte a fluxos de trabalho, como solicitações de envio e aprovações de mudanças. Se necessário, o Git pode ser executado em um servidor Linux simples.

Se um serviço de hospedagem do Git não for adequado para sua implantação devido a regras de segurança, muitos desses provedores de serviços oferecem versões que podem ser executadas no seu próprio ambiente. O GitLab, em particular, é comumente auto-hospedado e pode ser usado como um produto de código aberto sem custo de licença ou como um produto licenciado com suporte. O GitHub Enterprise está disponível como um serviço auto-hospedado e é um produto comercial com suporte.

As seções a seguir listam nuances para os provedores de serviços mais comuns.

GitHub/GitHub Enterprise

A página de documentação Como configurar e testar uma conexão do Git usa o GitHub como exemplo.

GitLab/gitlab.com

Consulte a postagem da comunidade do Looker Como usar o GitLab para controle de versão no Looker (em inglês) para ver as etapas detalhadas de configuração do GitLab. Se o repositório estiver contido em subgrupos, eles poderão ser adicionados ao URL do repositório usando o formato HTTPS ou SSH: 

https://gitlab.com/accountname/subgroup/reponame


git@gitlab.com:accountname/subgroup/reponame.git

Além disso, há três maneiras diferentes de armazenar chaves SSH geradas pelo Looker no GitLab: como uma chave SSH do usuário, como uma chave de implantação do repositório ou como uma chave de implantação compartilhada global. Uma explicação mais detalhada pode ser encontrada na documentação do GitLab.

Google Cloud Origem

Consulte a postagem na comunidade Como usar o Cloud Source Repositories para controle de versões no Looker e saiba como configurar o Git com o Cloud Source Repositories.

Bitbucket Cloud

Consulte a postagem na comunidade Como usar o Bitbucket para controle de versão no Looker para saber como configurar o Git com o Bitbucket Cloud. Desde agosto de 2021, o Bitbucket Cloud não é compatível com secrets em webhooks de implantação.

Bitbucket Server

Para usar solicitações de pull com o Bitbucket Server, talvez seja necessário seguir estas etapas:

  1. Quando você abre uma solicitação de envio, o Looker usa automaticamente o número da porta padrão (7999) no URL. Se você estiver usando um número de porta personalizado, substitua manualmente o número da porta no URL.
  2. Você precisará acessar o webhook de implantação do projeto para sincronizar a ramificação de produção no Looker com a ramificação principal do repositório.

Difusão do Phabricator

Consulte a postagem na comunidade Como configurar o Phabricator e o Looker para controle de versão para saber como configurar o Git com o Phabricator.

Rede

Conexões de entrada

Aplicativo da Web do Looker

Por padrão, o Looker detecta solicitações HTTPS na porta 9999. O Looker usa um certificado autoassinado com um CN de self-signed.looker.com. O servidor do Looker também pode ser configurado para fazer o seguinte:

  1. Aceite conexões HTTP de um balanceador de carga/proxy de terminação SSL com a --ssl-provided-externally-by=<s> flag de inicialização. O valor precisa ser definido como o endereço IP do proxy ou como um nome do host que pode ser resolvido localmente para o endereço IP do proxy. O Looker aceitará conexões HTTP apenas desse endereço IP.
  2. Use um certificado SSL fornecido pelo cliente com a flag de inicialização --ssl-keystore=<s>.

API Looker

A API Looker detecta na porta 19999. Se a instalação exigir acesso à API, o balanceador de carga precisará ter as regras de encaminhamento necessárias. As mesmas considerações sobre SSL se aplicam ao aplicativo da Web principal. Recomendamos usar uma porta diferente do aplicativo da Web.

Balanceadores de carga

Um balanceador de carga costuma ser usado para aceitar uma solicitação HTTPS na porta 443 usando o certificado do cliente e encaminhar a solicitação para o nó do servidor do Looker na porta 9999 usando o certificado autoassinado ou HTTP. Se os balanceadores de carga estiverem usando o certificado autoassinado do Looker, eles precisarão ser configurados para aceitar esse certificado.

Conexões inativas e tempos limite

Quando um usuário inicia uma solicitação grande no Looker, isso pode resultar em uma consulta que pode ser cara para executar no banco de dados. Se o usuário abandonar essa solicitação de alguma forma, como fechando a tampa do laptop, desconectando-se da rede ou fechando a guia no navegador, o Looker vai querer saber e encerrar essa consulta de banco de dados.

Para lidar com essa situação, quando o aplicativo da Web do cliente faz uma solicitação para executar uma consulta de banco de dados, o navegador abre uma conexão de soquete usando uma solicitação HTTP de longa duração para o servidor do Looker. Essa conexão vai ficar aberta e inativa. O soquete será desconectado se o aplicativo da Web do cliente for encerrado ou desconectado de alguma forma. O servidor vai detectar essa desconexão e cancelar todas as consultas de banco de dados relacionadas.

Os balanceadores de carga geralmente percebem essas conexões ociosas abertas e as encerram. Para executar o Looker de maneira eficaz, o balanceador de carga precisa ser configurado para permitir que essa conexão permaneça aberta durante a consulta mais longa que um usuário possa executar. Recomendamos um tempo limite de pelo menos 60 minutos.

Conexões de saída

Os servidores do Looker podem ter acesso de saída irrestrito a todos os recursos, incluindo a Internet pública. Isso simplifica muitas tarefas, como a instalação do Chromium, que exige acesso aos repositórios de pacotes da distribuição Linux.

Estas são as conexões de saída que o Looker pode precisar fazer.

Conexão interna com o banco de dados

Por padrão, o MySQL detecta conexões na porta 3306. Os nós do Looker precisam iniciar conexões com o MySQL nessa porta. Dependendo de como o repositório é hospedado, talvez seja necessário atravessar um firewall.

Serviços externos

Os servidores de telemetria e licença do Looker estão disponíveis usando HTTPS na Internet pública. O tráfego de um nó do Looker para ping.looker.com:443 e license.looker.com:443 pode precisar ser adicionado a uma lista de permissões.

Conexões de data warehouse

Os bancos de dados hospedados na nuvem podem exigir uma conexão usando a Internet pública. Por exemplo, se você estiver usando o BigQuery, talvez seja necessário adicionar accounts.google.com:443 e www.googleapis.com:443 a uma lista de permissões. Se o banco de dados estiver fora da sua infraestrutura, consulte o host para saber mais detalhes sobre a rede.

Serviços SMTP

Por padrão, o Looker envia e-mails de saída usando o SendGrid. Isso pode exigir a adição de smtp.sendgrid.net:587 a uma lista de permissões. As configurações de SMTP também podem ser alteradas na configuração para usar um gerenciador de e-mail diferente.

Hubs de ação, servidores de ação e webhooks

Muitos destinos do programador, principalmente webhooks e os ativados no painel de administrador do Looker, envolvem o envio de dados usando solicitações HTTPS.

  • Para webhooks, esses destinos são especificados no tempo de execução pelos usuários e podem ser contrários à meta de firewall de conexões de saída.
  • Para um hub de ações, essas solicitações são enviadas para actions.looker.com. Confira os detalhes na nossa documentação de configuração do Action Hub do Looker.
  • Para outros servidores de ações, essas solicitações são enviadas aos domínios especificados na configuração do servidor de ações por administradores no painel Administrador do Looker.

Servidor proxy

Se não for possível acessar a Internet pública diretamente, o Looker poderá ser configurado para usar um servidor proxy em solicitações HTTP(S). Para isso, adicione uma linha como a seguinte a lookerstart.cfg: 

JAVAARGS="-Dhttp.proxyHost=myproxy.example.com
  -Dhttp.proxyPort=8080
  -Dhttp.nonProxyHosts=127.0.0.1|localhost
  -Dhttps.proxyHost=myproxy.example.com
  -Dhttps.proxyPort=8080"

As comunicações entre nós acontecem por HTTPS. Portanto, se você usar um servidor proxy e sua instância estiver em cluster, geralmente é recomendável adicionar os IPs/nomes de host de todos os nós do cluster ao argumento Dhttp.nonProxyHosts.

Comunicações entre nós

Identificador interno do host

Em um cluster, cada nó precisa se comunicar com os outros. Para permitir isso, o nome do host ou o endereço IP de cada nó é especificado na configuração de inicialização. Quando o nó for iniciado, esse valor será gravado no repositório do MySQL. Outros membros do cluster podem se referir a esses valores para se comunicar com esse nó. Para especificar o nome do host ou o endereço IP na configuração de inicialização, adicione -H node1.looker.example.com à variável de ambiente LOOKERARGS em lookerstart.cfg.

Como o nome do host precisa ser exclusivo por nó, o arquivo lookerstart.cfg precisa ser exclusivo em cada instância. Como alternativa à codificação do nome do host ou do endereço IP, os comandos hostname -I ou hostname --fqdn podem ser usados para encontrá-los durante a execução. Para implementar isso, adicione -H $(hostname -I) ou -H $(hostname --fqdn) à variável de ambiente LOOKERARGS em lookerstart.cfg.

Portas internas

Além das portas 9999 e 19999, usadas para os servidores da Web e de API, respectivamente, os nós do cluster se comunicam entre si por um serviço de agente de mensagens, que usa as portas 1551 e 61616. As portas 9999 e 19999 precisam estar abertas para o tráfego do usuário final, mas as portas 1551 e 61616 precisam estar abertas entre os nós do cluster.