Esta página aborda práticas comuns para componentes específicos da arquitetura do Looker e descreve 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, acompanhar o desenvolvimento de modelos iterativos ou algo semelhante. Essas dependências são chamadas de componentes nesta página, e cada componente é abordado em detalhes nas seções a seguir:
- Configuração do host
- Configuração da JVM
- Opções de inicialização do Looker
- Banco de dados interno (back-end)
- Serviço do Git
- Rede
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 que são projetados e otimizados para serem executados em um ambiente específico geralmente são bons. Por exemplo, as distribuições de Linux do Google Cloud ou da AWS são compatíveis com o Looker. O Debian/Ubuntu é a variedade de Linux mais usada na comunidade do Looker, e estas são as versões mais conhecidas do suporte do Looker. É 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. As 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, o Looker não vai funcionar normalmente. O Looker requer o Java HotSpot 1.8 atualização 161 ou mais recente ou o Java OpenJDK 11.0.12 ou mais recente.
CPU e memória
Quatro nós de 16 (quatro CPUs e 16 GB de RAM) são suficientes para um sistema de desenvolvimento ou uma instância de teste básica do Looker usada por uma pequena equipe. No entanto, para uso em produção, isso geralmente não é suficiente. Na nossa experiência, nós usamos nós de 16x64 (16 CPUs e 64 GB de RAM) para encontrar 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 usam uma única linha de execução e interrompem a execução de todas as outras.
Armazenamento em disco
100 GB de espaço em disco normalmente são mais do que suficientes para um sistema de produção.
Considerações sobre clusters
O Looker é executado em uma JVM Java, e o Java pode ter dificuldade para gerenciar memórias superiores a 64 GB. Como regra geral, se for necessário mais capacidade, adicione outros nós de 16 x 64 ao cluster em vez de aumentar o tamanho dos nós além de 16 x 64. 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 LookML do desenvolvedor
- Conectividade do servidor do Git
Como o sistema de arquivos é compartilhado e hospeda vários repositórios Git, o gerenciamento do acesso simultâneo e do bloqueio de arquivos é fundamental. O sistema de arquivos precisa ser compatível com POSIX. O Network File System (NFS) é conhecido por funcionar e está prontamente disponível no Linux. Crie outra instância do Linux e configure o NFS para compartilhar o disco. O NFS padrão é potencialmente um ponto único de falha. Portanto, 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 do MySQL ou uma implantação dedicada do MySQL. A seção Banco de dados interno (back-end) desta página traz mais detalhes.
Configuração do JVM
As configurações da JVM do Looker são definidas no script de inicialização do Looker. Após as atualizações, o Looker precisa ser reiniciado para que as alterações no manifesto sejam feitas. 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 ser alocada em 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. A alocação de memória do Java normalmente é escalonada de acordo com a memória total da máquina, mas a Meta deve ser 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 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 parcela 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 em 46 GB, o que é maior do que a recomendação geral de 60%. As alocações exatas de recursos apropriadas para cada implantação variam. Portanto, use 60% como valor de referência e faça os ajustes conforme as regras de uso.
Coleta de lixo
O Looker prefere usar o coletor de lixo mais moderno disponível para a versão 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 de 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. Para mudar isso, edite 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 a alocação de recursos. Recomendamos o uso do 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 é fornecido no script de shell que inicia o Looker.
Pools de linhas de execução
Como um aplicativo com várias linhas de execução, o Looker tem vários pools de linhas de execução. Esses pools de linhas de execução variam do servidor da 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, esses pools precisam ser modificados da configuração padrão. Há considerações especiais para as topologias de cluster mencionadas na página Práticas e padrões de arquitetura de infraestrutura hospedada pelo cliente.
Opções de alta capacidade de programação
Para todos os nós que não são de programação, adicione --scheduler-threads=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem as linhas de execução do programador, nenhum job programado 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 isso pode ser aumentado para <n>. Com <n> linhas de execução do programador, cada nó poderá executar <n> trabalhos de programação simultâneos. Em geral, é recomendável manter <n> menor que o dobro do número de CPUs. O maior host recomendado é um com 16 CPUs e 64 GB de memória. Portanto, o limite superior das linhas de execução do programador precisa ser menor que 32.
Opções de alta capacidade de processamento 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 os nós do renderizador, nenhum job de renderização será executado 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 forem reservados para o sistema operacional, os últimos 20% serão usados para renderizações. Em uma máquina de 64 GB, isso deixa 12 GB, o que é suficiente para seis 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, restando 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 papéis, pastas, Looks e dashboards definidos pelo usuário e vários outros dados em um banco de dados interno.
Para uma instância autônoma 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 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 viá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 Looker faz muitas leituras e gravações pequenas no banco de dados MySQL. Toda vez que um usuário executa um Look ou uma Análise, o Looker verifica o banco de dados para verificar se o usuário ainda está conectado, se ele tem privilégios para acessar os dados, se ele tem privilégios para executar o Look ou a Análise 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 término da solicitação. Uma única interação entre um usuário e o aplicativo Looker pode resultar em 15 ou 20 leituras e gravações pequenas no banco de dados MySQL.
MySQL
O servidor MySQL precisa ser a versão 8.0.x e precisa ser configurado para usar a codificação utf8mb4. O mecanismo de armazenamento InnoDB precisa ser usado. As instruções de configuração do MySQL e de como migrar dados de um banco de dados hiperSQL para o MySQL estão disponíveis na página de documentação Como 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 duas licenças, disponível tanto como código aberto quanto como produto comercial. A Oracle continuou a melhorar o MySQL, que foi bifurcado como MariaDB. As versões do MySQL equivalentes do MariaDB 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 de nuvem, será lógico hospedar o banco de dados MySQL na mesma infraestrutura. 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 no fornecimento de recuperação rápida. Esses produtos funcionam bem com o Looker.
Consultas de atividades do sistema
O banco de dados MySQL é usado para armazenar informações sobre como os usuários estão utilizando o Looker. Qualquer usuário do Looker que tenha permissão para acessar o modelo Atividade do sistema tem acesso a vários painéis predefinidos do Looker para analisar esses dados. Os usuários também podem acessar as Análises dos metadados do Looker para criar outras análises. O banco de dados MySQL é usado principalmente para operações consultas. A abordagem grande, lenta e "analítica" as consultas geradas pelo modelo de atividade do sistema podem competir com essas consultas operacionais e tornar o Looker mais lento.
Nesses casos, o banco de dados MySQL pode ser replicado para outro. Os sistemas autogerenciados e alguns sistemas gerenciados pela nuvem fornecem a configuração básica da 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, chamado 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. Eles não são testados 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 ajustes e configurações adicionais. Essas configurações podem ser feitas no arquivo /etc/my.cnf ou no console do Google Cloud para instâncias gerenciadas pela nuvem.
O arquivo de configuração my.cnf é dividido em várias partes. As mudanças de configuração a seguir, 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 a executar o MySQL, o innodb_buffer_pool_size precisará ser definido como 50% a 70% da memória total do sistema.
Se o tamanho total do banco de dados for pequeno, será possível definir o pool de buffers do InnoDB para 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 buffer 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 pool de buffers grande, elas podem entrar em conflito. Para evitar isso, o pool de buffer é dividido em unidades menores que podem ser acessadas por diferentes linhas de execução sem conflito. Por padrão, o pool de buffer é dividido em 8 instâncias. Isso cria o potencial de um gargalo de 8 linhas. Aumentar o número de instâncias de pool de buffers reduz a chance de um gargalo. O innodb_buffer_pool_instances precisa ser definido para que cada pool de buffer 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 tem a opção de atualizar os dados no arquivo real ou pode salvar detalhes sobre a transação no registro. Se o banco de dados falhar antes que os arquivos de dados sejam atualizados, o arquivo de registro poderá ser "reproduzido" para aplicar as alterações. A gravação no arquivo de registro é uma pequena operação de adição. É eficiente anexar ao registro no momento da confirmação, agrupar várias alterações 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 no disco.
Como regra geral, o arquivo de registro do InnoDB deve ser grande o suficiente para conter uma hora de transações.
Normalmente, há dois arquivos de registro InnoDB. Elas devem ser cerca de 25% do seu pool de buffers do InnoDB. Para um banco de dados de exemplo com um pool de buffers 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 limita 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, em seguida, use esse valor para configurar a capacidade de E/S de modo que o MySQL grave os dados mais rapidamente.
Em um sistema hospedado na nuvem, o fornecedor de nuvem precisa informar o desempenho dos discos usados para armazenamento de dados. Para um servidor MySQL auto-hospedado, 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 sysbench do Linux é uma maneira de medir isso. Use esse valor para innodb_io_capacity_max e um valor de metade a três quartos dele para innodb_io_capacity. No exemplo a seguir, os valores seriam mostrados se medíssemos 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configurar linhas de execução do InnoDB
O MySQL abrirá pelo menos uma thread para cada cliente atendido. Se muitos clientes estiverem conectados ao mesmo tempo, isso pode levar a um grande número de linhas de execução sendo processadas. Isso pode fazer com que o sistema gaste mais tempo com trocas do que processando.
É necessário fazer uma comparação para determinar o número ideal de linhas de execução. Para testar, defina o número de linhas entre o número de CPUs (ou núcleos de CPU) no sistema e o número de CPUs multiplicado por quatro. Para um sistema de 16 núcleos, esse valor provavelmente fica 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 em disco para 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. em transações de dados.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Definir o método de limpeza
O sistema operacional normalmente faz o buffer de gravações no disco. Como o MySQL e o SO estão em buffer, há uma penalidade de desempenho. Reduzir o método de limpeza em uma camada de armazenamento em 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 em metadados
Essa configuração desativa a coleta de estatísticas em tabelas de metadados internas, melhorando o desempenho de leitura.
[mysqld] ... innodb_stats_on_metadata=OFF
Desativar o cache de consultas
O cache de consulta 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 mesclagem
O join_buffer é usado para realizar junções na memória. Aumentar o valor pode melhorar algumas operações.
[mysqld] ... join_buffer_size=512KB
Ampliar a tabela temporária e os tamanhos de heap máximos
O tmp_table_size e o max_heap_table_size definem padrões razoáveis para tabelas temporárias na memória antes de serem forçadas para o disco.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajustar o cache aberto da tabela
A configuração table_open_cache determina o tamanho do cache que armazena os descritores de arquivos para tabelas abertas. A configuração table_open_cache_instances divide o cache em várias partes menores. Há uma possível contenção de linha de execução no table_open_cache. Portanto, dividi-lo em partes menores ajuda a aumentar a simultaneidade.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Serviço do Git
O Looker foi projetado para funcionar com um serviço Git para gerenciar as versões dos arquivos do LookML. Os principais serviços de hospedagem do Git são compatíveis, incluindo GitHub, GitLab e Bitbucket. Os provedores de serviços Git oferecem outros benefícios, como uma GUI para conferir as 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 Git não for apropriado para a implantação devido às regras de segurança, muitos provedores oferecem versões que podem ser executadas no seu ambiente. O GitLab, em particular, é geralmente 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 as nuances dos 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 na Comunidade do Looker Como usar o GitLab para controle de versões 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 de usuário, como uma chave de implantação de repositório ou como uma chave de implantação compartilhada global. Veja uma explicação mais detalhada na documentação do GitLab (em inglês).
Google Cloud Source
Consulte a postagem da comunidade Como usar o Cloud Source Repositories para controle de versões no Looker para conferir as etapas de configuração do Git com o Cloud Source Repositories.
Bitbucket Cloud
Consulte a postagem na comunidade Como usar o Bitbucket para controle de versões no Looker (em inglês) e veja as etapas de configuração do Git com o Bitbucket Cloud. Desde agosto de 2021, o Bitbucket Cloud não oferece suporte a segredos em webhooks de implantação.
Bitbucket Server
Para usar solicitações de envio com o Bitbucket Server, talvez seja necessário concluir as seguintes etapas:
- Quando você abre uma solicitação de envio, o Looker usa automaticamente o número de porta padrão (7999) no URL. Se estiver usando um número de porta personalizado, você terá que substituir o número da porta no URL manualmente.
- É necessário 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 fabricadora
Consulte a postagem na Comunidade Como configurar o Phabricator e o Looker para controle de versões para saber como configurar o Git com o Phabricator.
Rede
Conexões de entrada
Aplicativo da Web Looker
Por padrão, o Looker detecta solicitações HTTPS na porta 9999. O Looker usa um certificado autoassinado com uma CN de self-signed.looker.com. Outra opção é configurar o servidor do Looker para fazer o seguinte:
- Aceite conexões HTTP de um balanceador de carga/proxy de terminação SSL com a flag de inicialização
--ssl-provided-externally-by=<s>. O valor deve ser definido como o endereço IP do proxy ou como um nome de host que pode ser resolvido localmente para o endereço IP do proxy. O Looker só aceita conexões HTTP desse endereço IP. - Use um certificado SSL fornecido pelo cliente com a sinalização de inicialização
--ssl-keystore=<s>.
API Looker
A API Looker detecta atividade 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 do SSL se aplicam ao aplicativo da Web principal. Recomendamos usar uma porta distinta do aplicativo da Web.
Balanceadores de carga
Um balanceador de carga é usado com frequência para aceitar uma solicitação HTTPS na porta 443 usando o certificado do cliente e, em seguida, encaminhar a solicitação para o nó do servidor do Looker na porta 9999 usando o certificado autoassinado ou o 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 a solicitação de alguma forma (por exemplo, fechando a tampa do laptop, desconectando da rede ou eliminando a guia do navegador), o Looker vai querer saber e encerrar essa consulta ao 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. Esta conexão ficará aberta e inativa. Esse soquete será desconectado se o aplicativo da Web do cliente for encerrado ou desconectado de alguma forma. O servidor vai desconectar e cancelar todas as consultas relacionadas ao banco de dados.
Os balanceadores de carga geralmente percebem essas conexões ociosas abertas e as eliminam. Para executar o Looker de forma 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 puder executar. Sugerimos 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 do Linux.
Confira a seguir as conexões de saída que o Looker pode precisar fazer.
Conexão interna de banco de dados
Por padrão, o MySQL detecta conexões na porta 3306. Os nós do Looker precisam ser capazes de iniciar conexões com o MySQL nessa porta. Dependendo de como o repositório é hospedado, pode ser necessário atravessar um firewall.
Serviços externos
Os servidores de licenciamento e de telemetria do Looker estão disponíveis usando HTTPS na Internet pública. Talvez seja necessário adicionar o tráfego de um nó do Looker para ping.looker.com:443 e license.looker.com:443 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 própria infraestrutura, consulte o host do banco de dados para saber detalhes da 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 do SMTP podem ser alteradas nas configurações para usar um gerenciador de e-mails diferente também.
Hubs de ação, servidores de ação e webhooks
Muitos destinos do programador, em particular os webhooks e os que são ativados no painel administrativo do Looker, envolvem o envio de dados usando solicitações HTTPS.
- Para webhooks, esses destinos são especificados no momento da execução pelos usuários e podem ser contrários ao objetivo de bloquear as conexões de saída.
- No caso de um hub de ações, essas solicitações são enviadas para
actions.looker.com. Confira os detalhes na documentação de configuração do Looker Action Hub. - Para outros servidores de ação, essas solicitações são enviadas aos domínios especificados na configuração do servidor de ação pelos 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 para solicitações HTTP(S). Basta adicionar uma linha como esta 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, adicione os nomes de IPs/hosts de todos os nós do cluster ao argumento Dhttp.nonProxyHosts.
Comunicações entre nós
Identificador de host interno
Em um cluster, cada nó precisa ser capaz de se comunicar com os outros. Para permitir isso, o nome do host ou 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 para cada nó, o arquivo lookerstart.cfg precisa ser exclusivo em cada instância. Como alternativa à fixação do código do nome do host ou do endereço IP, o comando hostname -I ou hostname --fqdn pode ser usado para encontrá-los no ambiente de execução. Para implementar, 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 da API, respectivamente, os nós do cluster se comunicarão entre si por meio de 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 1551 e 61616 precisam estar abertas entre os nós do cluster.