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 uma série de dependências para hospedar o servidor, atender cargas de trabalho ad-hoc e programadas, rastrear o desenvolvimento de modelos iterativos ou similares. Essas dependências são chamadas de componentes nesta página, e cada componente é abordado em detalhes nas seguintes seções:
- Configuração do host
- Configuração da JVM
- Opções de inicialização do Looker
- Banco de dados interno (back-end)
- Serviço 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. Os derivados dessas distribuições que são projetados e otimizados para serem executados em um ambiente específico geralmente são aceitáveis. 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. Distribuições mais antigas do Linux podem executar o Looker, mas a versão e as bibliotecas do Java que o Looker exige 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
Os nós de 4 x 16 (4 CPUs e 16 GB de RAM) são suficientes para um sistema de desenvolvimento ou uma instância de teste básico do Looker usada por uma equipe pequena. No entanto, para uso na 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 têm 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 o cluster
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ária mais capacidade, adicione nós de 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 certas partes do sistema de arquivos. Os dados compartilhados incluem o seguinte:
- Modelos do LookML
- Os modelos 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 é 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. Você deve criar uma instância extra do Linux e configurar o NFS para compartilhar o disco. O NFS padrão é potencialmente um ponto único de falha. Por isso, considere uma configuração de failover ou de alta disponibilidade.
Os metadados do Looker também precisam ser centralizados, portanto, 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 da 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 até 60% da memória total, mas há algumas 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 normalmente é dimensionada com a memória total da máquina, mas o 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 esperada e do tamanho da máquina. Se a carga de renderização for baixa, é possível alocar para Java uma parte maior da memória total. Por exemplo, em uma máquina com 60 GB de memória total, o Java poderia ser alocado com segurança para 46 GB, o que é mais 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. Isso pode ser alterado editando 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 é gerado 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 externas. Dependendo dos fluxos de trabalho da sua empresa, talvez seja necessário modificar esses pools na 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> 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 é 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 renderização por padrão, mas isso pode ser aumentado para <n>. Com <n> linhas 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) recebe 60% da memória total e 20% da memória restante é reservada para o sistema operacional, os últimos 20% são mantidos para jobs de renderização. Em uma máquina de 64 GB, isso deixa 12 GB, o 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, isso deixa 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 hiperSQL 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 apresenta 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, o Looker verifica o banco de dados para conferir 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 e assim por diante. O Looker também grava dados no banco de dados MySQL, como o SQL que foi executado e o horário em que a solicitação começou e terminou. 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 deve ser a versão 8.0.x e ser configurado para usar a codificação utf8mb4. O mecanismo de armazenamento do InnoDB precisa ser usado. As instruções de configuração do MySQL, bem como as instruções sobre 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 contendo 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 licença dupla, disponível como código aberto e 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ê hospeda 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 para gerenciar backups e fornecer 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 visualizar 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 fazer análises adicionais. O banco de dados MySQL é usado principalmente para aplicativos consultas. A abordagem grande, lenta e "analítica" as consultas geradas pelo modelo de atividade do sistema podem competir com essas consultas operacionais e deixar o Looker mais lento.
Nesses casos, o banco de dados MySQL pode ser replicado para outro banco de dados. 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 mais ajustes e configurações. Essas configurações podem ser feitas no arquivo /etc/my.cnf ou no console do Google Cloud, no caso de 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 buffers do InnoDB
O tamanho do pool de buffers 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 precisará ser definido como 50% a 70% da memória total do sistema.
Se o tamanho total do banco de dados for pequeno, é possível 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 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 buffers 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 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 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 registros 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 anexaçã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 acelera a velocidade de gravação das gravações 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 desse valor 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 as linhas de execução do InnoDB
O MySQL abrirá pelo menos uma thread para cada cliente atendido. Quando muitos clientes estão conectados simultaneamente, um grande número de threads pode ser processado. 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 armazenamento em buffer das gravações no disco. Como o MySQL e o SO estão armazenando em buffer, há uma queda de desempenho. Reduzir o método de limpeza em uma camada do buffer pode melhorar o desempenho.
[mysqld] ... innodb_flush_method=O_DIRECT
Ativar um arquivo por tabela
Por padrão, o MySQL usará 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 a performance 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 junção
O join_buffer é usado para realizar junções na memória. Aumentar esse valor pode melhorar determinadas operações.
[mysqld] ... join_buffer_size=512KB
Ampliar os tamanhos de tabela temporária e máximo de heap
tmp_table_size e 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 contém os descritores de arquivo para tabelas abertas. A configuração table_open_cache_instances divide o cache em várias partes menores. Há um potencial para contenção de linhas de execução na table_open_cache, então dividi-la 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 do Git para gerenciar a versão dos arquivos do LookML. Os principais serviços de hospedagem 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 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 na Comunidade Como usar o Cloud Source Repositories para controle de versões no Looker para saber como configurar o Git com o Cloud Source Repositories.
Bitbucket Cloud
Consulte a postagem da comunidade Como usar o Bitbucket para controle de versão no Looker para conferir as etapas de configuração do 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 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.
- Você terá que 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
Confira as etapas para configurar o Git com o Phabricator na postagem na Comunidade Como configurar o Phabricator e o Looker para controle de versões.
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. O servidor do Looker pode ser configurado para fazer o seguinte:
- Aceitar conexões HTTP de um balanceador de carga/proxy de terminação SSL, com a sinalização de inicialização
--ssl-provided-externally-by=<s>. O valor precisa ser definido como o endereço IP do proxy ou como um nome de host que possa ser resolvido localmente para o endereço IP do proxy. O Looker só vai aceitar 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 de SSL se aplicam ao aplicativo da Web principal. Recomendamos usar uma porta distinta do aplicativo da Web.
Balanceadores de carga
Um balanceador de carga geralmente é usado para aceitar uma solicitação HTTPS na porta 443 usando o certificado do cliente e, em seguida, encaminhá-la 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 desiste de alguma forma, por exemplo, fechando a tampa do laptop, desconectando a rede ou excluindo a guia do navegador, o Looker quer saber e encerrar a consulta ao banco de dados.
Para lidar com essa situação, quando o aplicativo da Web cliente solicita a execução de 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 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 notam essas conexões ociosas abertas e as encerram. 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, inclusive à Internet pública. Isso simplifica muitas tarefas, como a instalação do Chromium, que requer acesso aos repositórios de pacotes para a distribuição 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 passar por um firewall.
Serviços externos
A telemetria e os servidores de licenças 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
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 do banco de dados para saber os detalhes da rede.
Serviços SMTP
Por padrão, o Looker envia e-mails de saída usando o SendGrid. Para isso, talvez seja necessário adicionar 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, principalmente os webhooks ativados no painel Administrador do Looker, envolvem o envio de dados usando solicitações HTTPS.
- No caso dos webhooks, esses destinos são especificados no ambiente 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 documentação de configuração do Looker Action Hub. - Para outros servidores de ação, essas solicitações são enviadas para os domínios especificados na configuração do servidor de ações 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
Dentro de um cluster, cada nó precisa ser capaz de se comunicar com os outros nós. 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 consultar 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 à 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 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, que são 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.