Esta página explora as práticas comuns para componentes específicos da arquitetura do Looker e descreve como configurá-los numa implementação.
O Looker tem várias dependências para alojar o servidor, servir cargas de trabalho ad hoc e agendadas, acompanhar o desenvolvimento iterativo de modelos ou semelhantes. Estas dependências são denominadas componentes nesta página, e cada componente é abordado detalhadamente nas secções seguintes:
- Configuração do anfitrião
- Configuração da JVM
- Opções de arranque do Looker
- Base de dados interna (back-end)
- Serviço Git
- Rede
Configuração do anfitrião
SO e distribuição
O Looker funciona bem nas versões mais comuns do Linux: RedHat, SUSE e Debian/Ubuntu. Geralmente, não há problema em usar derivados destas distribuições concebidos e otimizados para serem executados num ambiente específico. Por exemplo, as distribuições Google Cloud ou AWS do Linux 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 familiares ao apoio técnico do Looker. É mais fácil usar o Debian/Ubuntu ou um sistema operativo para um fornecedor 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 conseguir executar o Looker, mas a versão e as bibliotecas Java que o Looker requer para funcionalidades específicas têm de estar atualizadas. Se a JVM não contiver todas as bibliotecas e versões recomendadas do Looker, o Looker não funciona normalmente. O Looker requer o Java HotSpot 1.8 update 161 ou superior, ou o Java OpenJDK 11.0.12 ou superior.
CPU e memória
Os nós 4x16 (4 CPUs e 16 GB de RAM) são suficientes para um sistema de desenvolvimento ou uma instância do Looker de testes básicos usada por uma equipa pequena. No entanto, para utilização em produção, isto não costuma ser suficiente. Na nossa experiência, os nós 16x64 (16 CPUs e 64 GB de RAM) representam um bom equilíbrio entre o preço e o desempenho. Ter mais de 64 GB de RAM pode afetar o desempenho, uma vez que os eventos de recolha de lixo são de thread único e interrompem todas as outras threads para execução.
Armazenamento em disco
Normalmente, 100 GB de espaço no disco são mais do que suficientes para um sistema de produção.
Considerações sobre clusters
O Looker é executado numa JVM Java e o Java pode ter dificuldades em gerir memória superior a 64 GB. Como regra geral, se precisar de mais capacidade, deve adicionar nós 16x64 adicionais ao cluster em vez de aumentar o tamanho dos nós para além de 16x64. Também podemos preferir usar uma arquitetura agrupada para aumentar a disponibilidade.
Num cluster, os nós do Looker têm de partilhar determinadas partes do sistema de ficheiros. Os dados partilhados incluem o seguinte:
- Modelos do LookML
- Os modelos do LookML do programador
- Conetividade do servidor Git
Uma vez que o sistema de ficheiros é partilhado e aloja vários repositórios Git, o processamento do acesso concorrente e do bloqueio de ficheiros é fundamental. O sistema de ficheiros tem de estar em conformidade com a norma POSIX. O sistema de ficheiros de rede (NFS) é conhecido por funcionar e está prontamente disponível com o Linux. Deve criar uma instância do Linux adicional e configurar o NFS para partilhar o disco. O NFS predefinido é potencialmente um ponto único de falha, pelo que deve considerar uma configuração de failover ou uma configuração de alta disponibilidade.
Os metadados do Looker também têm de ser centralizados, pelo que a respetiva base de dados interna tem de ser migrada para o MySQL. Pode ser um serviço MySQL ou uma implementação MySQL dedicada. A secção Base de dados interna (back-end) nesta página explica os detalhes.
Configuração da JVM
As definições da JVM do Looker são definidas no script de arranque do Looker. Após quaisquer atualizações, o Looker tem de ser reiniciado para que as alterações se manifestem. As configurações predefinidas 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 definições de recursos são definidas no script de arranque do Looker.
JAVAMEM="2300m" METAMEM="800m"
A atribuição de memória para a JVM tem de ter em consideração a sobrecarga do sistema operativo no qual o Looker está a ser executado. A regra geral é que a JVM pode ter até 60% da memória total, mas existem ressalvas consoante o tamanho da máquina. Para máquinas com o mínimo de 8 GB de memória total, recomendamos uma atribuição de 4 a 5 GB ao Java e 800 MB à Meta. Para máquinas maiores, pode ser alocada uma proporção inferior de memória para o sistema operativo. Por exemplo, para máquinas com 60 GB de memória total, recomendamos uma atribuição de 36 GB ao Java e 1 GB ao Meta. É importante ter em atenção que a atribuição de memória do Java deve, normalmente, ser dimensionada com a memória total da máquina, mas a Meta deve ser suficiente com 1 GB.
Além disso, uma vez que o Looker partilha recursos do sistema com outros processos, como o Chromium, para a renderização, a quantidade de memória alocada ao Java deve ser selecionada no contexto da carga de renderização prevista e do tamanho da máquina. Se o carregamento de renderização for esperado como baixo, pode ser atribuída ao Java uma maior parte da memória total. Por exemplo, numa máquina com 60 GB de memória total, o Java pode ser atribuído em segurança a 46 GB, o que é superior à recomendação geral de 60%. As atribuições de recursos exatas adequadas para cada implementação variam, por isso, use 60% como base e ajuste conforme a utilização.
Recolha de lixo
O Looker prefere usar o coletor de lixo mais moderno disponível para a sua versão Java. Por predefinição, o limite de tempo da recolha de lixo é de 2 segundos, mas pode alterá-lo editando a seguinte opção na configuração de arranque:
-XX:MaxGCPauseMillis=2000
Num computador maior com vários núcleos, o limite de tempo da recolha de lixo pode ser reduzido.
Registos
Por predefinição, os registos de recolha de lixo do Looker são armazenados em /tmp/gc.log. Pode alterar esta opção editando a seguinte opção na configuração de arranque:
-Xloggc:/tmp/gc.log
JMX
A gestão do Looker pode precisar de monitorização para ajudar a refinar a atribuição de recursos. Recomendamos que use o JMX para monitorizar a utilização da memória da JVM.
Opções de arranque do Looker
As opções de arranque são armazenadas num ficheiro denominado lookerstart.cfg. Este ficheiro é obtido no script de shell que inicia o Looker.
Conjuntos de threads
Como uma aplicação com várias threads, o Looker tem vários conjuntos de threads. Estes conjuntos de threads variam desde o servidor Web principal até subsistemas especializados, como agendamento, renderização e ligações a bases de dados externas. Consoante os fluxos de trabalho da sua empresa, pode ter de modificar estes conjuntos a partir da configuração predefinida. Em particular, existem considerações especiais para as topologias de cluster mencionadas na página Padrões e práticas de arquitetura de infraestrutura alojada pelo cliente.
Opções de rendimento de agendamento elevado
Para todos os nós que não sejam do Scheduler, adicione --scheduler-threads=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem threads do agendador, nenhuma tarefa agendada é executada nestes nós.
Para todos os nós do agendador dedicados, adicione --scheduler-threads=<n> à variável de ambiente LOOKERARGS em lookerstart.cfg. Por predefinição, o Looker começa com 10 threads do programador, mas este número pode ser aumentado para <n>. Com <n> threads do programador, cada nó é capaz de executar <n> tarefas de programação simultâneas. Geralmente, recomendamos que mantenha <n> abaixo do dobro do número de CPUs. O anfitrião recomendado mais elevado tem 16 CPUs e 64 GB de memória, pelo que o limite superior de threads do agendador deve ser inferior a 32.
Opções de rendimento de renderização elevado
Para todos os nós de não renderização, adicione --concurrent-render-jobs=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem nós de renderização, não são executados trabalhos de renderização nestes nós.
Para todos os nós de renderização dedicados, adicione --concurrent-render-jobs=<n> à variável de ambiente LOOKERARGS em lookerstart.cfg. Por predefinição, o Looker começa com dois threads de renderização, mas este número pode ser aumentado para <n>. Com <n> threads de renderização, cada nó é capaz de executar <n> tarefas de renderização simultâneas.
Cada tarefa de renderização pode usar uma quantidade significativa de memória. Orçamente cerca de 2 GB por tarefa de renderização. Por exemplo, se o processo principal do Looker (Java) tiver 60% da memória total atribuída e 20% da memória restante estiver reservada para o sistema operativo, os últimos 20% ficam para as tarefas de renderização. Numa máquina de 64 GB, restam 12 GB, o que é suficiente para 6 tarefas de renderização simultâneas. Se um nó for dedicado à renderização e não estiver incluído no conjunto do equilibrador de carga que está a processar tarefas interativas, a memória do processo principal do Looker pode ser reduzida para permitir mais tarefas de renderização. Numa máquina de 64 GB, pode atribuir aproximadamente 30% (20 GB) ao processo principal do Looker. Reservando 20% para a utilização geral do SO, restam 50% (32 GB) para a renderização, o que é suficiente para 16 tarefas de renderização simultâneas.
Base de dados interna (back-end)
O servidor do Looker mantém informações sobre a sua própria configuração, ligações à base de dados, utilizadores, grupos e funções, pastas, Looks e painéis de controlo definidos pelo utilizador, bem como vários outros dados numa base de dados interna.
Para uma instância autónoma do Looker de tamanho moderado, estes dados são armazenados numa base de dados HyperSQL na memória incorporada no próprio processo do Looker. Os dados desta base de dados são armazenados no ficheiro <looker install directory>/.db/looker.script. Embora seja conveniente e leve, esta base de dados tem problemas de desempenho com uma utilização intensa. Por isso, recomendamos que comece com uma base de dados MySQL remota. Se isto não for viável, recomendamos a migração para uma base de dados MySQL remota assim que o ficheiro ~/looker/.db/looker.script atingir 600 MB. Os clusters têm de usar uma base de dados MySQL.
O servidor do Looker faz muitas leituras e gravações pequenas na base de dados MySQL. Sempre que um utilizador executa um Look ou uma análise detalhada, o Looker verifica a base de dados para confirmar que o utilizador continua com sessão iniciada, que tem privilégios para aceder aos dados, que tem privilégios para executar o Look ou a análise detalhada, e assim sucessivamente. O Looker também escreve dados na base de dados do MySQL, como o SQL real que foi executado e a hora em que o pedido começou e terminou. Uma única interação entre um utilizador e a aplicação Looker pode resultar em 15 ou 20 leituras e escritas pequenas na base de dados MySQL.
MySQL
O servidor MySQL deve ser a versão 8.0.x e tem de estar configurado para usar a codificação utf8mb4. Tem de usar o motor de armazenamento InnoDB. As instruções de configuração do MySQL, bem como as instruções sobre como migrar dados de uma base de dados HyperSQL existente para o MySQL, estão disponíveis na página de documentação Migrar a base de dados de back-end do Looker para o MySQL.
Quando configura o Looker para usar o MySQL, tem de criar um ficheiro YAML com as informações de ligação. Atribua o nome looker-db.yml ao ficheiro YAML e adicione a definição -d looker-db.yml na secção LOOKERARGS do ficheiro lookerstart.cfg.
MariaDB
O MySQL tem uma dupla licença, estando disponível como código aberto e como produto comercial. A Oracle continuou a melhorar o MySQL, e o MySQL foi bifurcado como MariaDB. Sabe-se que as versões equivalentes do MariaDB do MySQL funcionam com o Looker, mas não são desenvolvidas nem testadas pelas equipas de engenharia do Looker. Por conseguinte, a funcionalidade não é suportada nem garantida.
Versões na nuvem
Se alojar o Looker na sua infraestrutura de nuvem, é lógico alojar a base de dados MySQL na mesma infraestrutura de nuvem. Os três principais fornecedores de nuvem: Amazon AWS, Microsoft Azure e Google Cloud. Os fornecedores de nuvem gerem grande parte da manutenção e configuração da base de dados MySQL e oferecem serviços como ajuda na gestão de cópias de segurança e recuperação rápida. Estes produtos funcionam bem com o Looker.
Consultas de atividade do sistema
A base de dados do MySQL é usada para armazenar informações sobre a forma como os utilizadores estão a usar o Looker. Qualquer utilizador do Looker com autorização para ver o modelo System Activity tem acesso a vários painéis de controlo do Looker pré-criados para analisar estes dados. Os utilizadores também podem aceder a explorações de metadados do Looker para criar análises adicionais. A base de dados do MySQL é usada principalmente para consultas "operacionais" pequenas e rápidas. As consultas "analíticas" grandes e lentas geradas pelo modelo de atividade do sistema podem competir com estas consultas operacionais e tornar o Looker mais lento.
Nestes casos, a base de dados do MySQL pode ser replicada para outra base de dados. Os sistemas autogeridos e determinados sistemas geridos na nuvem oferecem uma configuração básica da replicação para outras bases de dados. A configuração da replicação está fora do âmbito deste documento.
Para usar a réplica para as consultas de atividade do sistema, crie uma cópia do ficheiro looker-db.yml, por exemplo, com o nome looker-usage-db.yml, modifique-o para apontar para a réplica e adicione a definição --internal-analytics-connection-file looker-usage-db.yml
à secção LOOKERARGS do ficheiro lookerstart.cfg.
As consultas de atividade do sistema podem ser executadas numa instância do MySQL ou numa base de dados do Google BigQuery. Não são testadas em relação a outras bases de dados.
Configuração do desempenho do MySQL
Além das definições necessárias para migrar a base de dados de back-end do Looker para o MySQL, os clusters com muita atividade podem beneficiar de uma otimização e configuração adicionais. Estas definições podem ser feitas no ficheiro /etc/my.cnf ou através da consola Google Cloud para instâncias geridas na nuvem.
O ficheiro de configuração my.cnf está dividido em várias partes. As seguintes alterações às definições abordadas nesta secção são feitas na [mysqld] parte.
Defina o tamanho da memória intermédia do InnoDB
O tamanho do conjunto de buffers do InnoDB é a RAM total usada para armazenar o estado dos ficheiros de dados do InnoDB na memória. Se o servidor for dedicado à execução do MySQL, o innodb_buffer_pool_size deve ser definido como 50% a 70% da memória total do sistema.
Se o tamanho total da base de dados for pequeno, é permitido definir o conjunto de buffers do InnoDB para o tamanho da base de dados, em vez de 50% ou mais da memória.
Para este exemplo, um servidor tem 64 GB de memória. Por conseguinte, o conjunto de buffers do InnoDB deve ter entre 32 GB e 45 GB. Normalmente, quanto maior, melhor.
[mysqld] ... innodb_buffer_pool_size=45G
Defina as instâncias do conjunto de buffers do InnoDB
Quando vários threads tentam pesquisar um grande conjunto de buffers, podem entrar em conflito. Para evitar esta situação, o conjunto de buffers é dividido em unidades mais pequenas que podem ser acedidas por diferentes discussões sem conflitos. Por predefinição, o conjunto de buffers é dividido em 8 instâncias. Isto cria o potencial para um gargalo de 8 threads. Aumentar o número de instâncias do conjunto de buffers reduz a probabilidade de um gargalo. O innodb_buffer_pool_instances deve ser definido de modo que cada buffer pool receba, pelo menos, 1 GB de memória.
[mysqld] ... innodb_buffer_pool_instances=32
Otimize o ficheiro de registo do InnoDB
Quando uma transação é confirmada, a base de dados tem a opção de atualizar os dados no ficheiro real ou pode guardar detalhes sobre a transação no registo. Se a base de dados falhar antes de os ficheiros de dados serem atualizados, o ficheiro de registo pode ser "reproduzido" para aplicar as alterações. A escrita no ficheiro de registo é uma pequena operação de anexação. É eficiente anexar ao registo no momento da confirmação e, em seguida, agrupar várias alterações aos ficheiros de dados e escrevê-las numa única operação de E/S. Quando o ficheiro de registo está cheio, a base de dados tem de pausar o processamento de novas transações e escrever todos os dados alterados novamente no disco.
Regra geral, o ficheiro de registo do InnoDB deve ser suficientemente grande para conter 1 hora de transações.
Normalmente, existem dois ficheiros de registo do InnoDB. Devem representar cerca de 25% do seu conjunto de buffers do InnoDB. Para uma base de dados de exemplo com um buffer pool de 32 GB, os ficheiros de registo do InnoDB devem totalizar 8 GB ou 4 GB por ficheiro.
[mysqld] ... innodb_log_file_size=8GB
Configure a capacidade de E/S do InnoDB
O MySQL limita a velocidade a que as escritas são registadas no disco para não sobrecarregar o servidor. Os valores predefinidos são conservadores para a maioria dos servidores. Para um 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 escreva dados mais rapidamente.
Num sistema alojado na nuvem, o fornecedor da nuvem deve poder comunicar o desempenho dos discos usados para o armazenamento de dados. Para um servidor MySQL autoalojado, 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 Linux sysbench é uma forma de medir isto. Use esse valor para innodb_io_capacity_max e um valor de metade a três quartos desse valor para innodb_io_capacity. Assim, no exemplo seguinte, veríamos os valores se medíssemos 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configure threads do InnoDB
O MySQL abre, pelo menos, um segmento para cada cliente que está a ser servido. Se muitos clientes estiverem ligados em simultâneo, isso pode levar ao processamento de um número enorme de discussões. Isto pode fazer com que o sistema gaste mais tempo a trocar do que a processar.
A avaliação comparativa deve ser feita para determinar o número ideal de threads. Para testar, defina o número de threads entre o número de CPUs (ou núcleos da CPU) no sistema e 4 vezes o número de CPUs. Para um sistema de 16 núcleos, este valor está provavelmente entre 16 e 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilidade das transações
Um valor de transação de 1 força o MySQL a escrever no disco para cada transação. Se o servidor falhar, a transação não é perdida, mas o desempenho da base de dados é afetado. Se definir este valor como 0 ou 2, pode melhorar o desempenho, mas corre o risco de perder transações de dados equivalentes a alguns segundos.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Defina o método flush
Normalmente, o sistema operativo faz o armazenamento em buffer das gravações no disco. Uma vez que o MySQL e o SO estão a usar buffers, existe uma penalização de desempenho. Reduzir o método de descarga de uma camada de armazenamento intermédio pode melhorar o desempenho.
[mysqld] ... innodb_flush_method=O_DIRECT
Ative um ficheiro por tabela
Por predefinição, o MySQL usa um único ficheiro de dados para todos os dados. A definição innodb_file_per_table cria um ficheiro separado para cada tabela, o que melhora o desempenho e a gestão de dados.
[mysqld] ... innodb_file_per_table=ON
Desative as estatísticas nos metadados
Esta definição desativa a recolha de estatísticas em tabelas de metadados internos, o que melhora o desempenho de leitura.
[mysqld] ... innodb_stats_on_metadata=OFF
Desative a cache de consultas
A cache de consultas foi descontinuada, pelo que a definição de query_cache_size e query_cache_type como 0 a desativa.
[mysqld] ... query_cache_size=0 query_cache_type=0
Aumente a memória intermédia de junção
O join_buffer é usado para fazer junções na memória. Aumentá-la pode melhorar determinadas operações.
[mysqld] ... join_buffer_size=512KB
Aumente o tamanho da tabela temporária e os tamanhos máximos da memória
O tmp_table_size e o max_heap_table_size definem predefinições razoáveis para tabelas temporárias na memória, antes de serem forçadas a gravar no disco.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajuste a cache aberta da tabela
A definição table_open_cache determina o tamanho da cache que contém os descritores de ficheiros para tabelas abertas. A definição table_open_cache_instances divide a cache em várias partes mais pequenas. Existe um potencial de contenção de threads no table_open_cache, pelo que dividi-lo em partes mais pequenas ajuda a aumentar a concorrência.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Serviço Git
O Looker foi concebido para funcionar com um serviço Git para fornecer gestão de versões dos ficheiros LookML. Os principais serviços de alojamento Git são suportados, incluindo o GitHub, o GitLab e o Bitbucket. Os fornecedores de serviços Git oferecem vantagens adicionais, como uma GUI para ver as alterações ao código e suporte para fluxos de trabalho, como pedidos de obtenção e aprovações de alterações. Se necessário, o Git pode ser executado num servidor Linux simples.
Se um serviço de alojamento Git não for adequado para a sua implementação devido a regras de segurança, muitos destes fornecedores de serviços oferecem versões que podem ser executadas no seu próprio ambiente. O GitLab, em particular, é normalmente alojado por si próprio e pode ser usado como um produto de código aberto sem custo de licença ou como um produto licenciado com apoio técnico. O GitHub Enterprise está disponível como um serviço autoalojado e é um produto comercial suportado.
As secções seguintes indicam nuances para os fornecedores de serviços mais comuns.
GitHub/GitHub Enterprise
A página de documentação Configurar e testar uma ligação Git usa o GitHub como exemplo.
GitLab/gitlab.com
Consulte a publicação da comunidade do Looker Usar o GitLab para controlo de versões no Looker para ver os passos de configuração detalhados do GitLab. Se o seu repositório estiver contido em subgrupos, estes podem ser adicionados ao URL do repositório através do formato HTTPS ou SSH:
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
Além disso, existem três formas diferentes de armazenar chaves SSH geradas pelo Looker no GitLab: como uma chave SSH do utilizador, como uma chave de implementação do repositório ou como uma chave de implementação partilhada global. Pode encontrar uma explicação mais detalhada na documentação do GitLab.
Google Cloud Fonte
Consulte a publicação da comunidade Usar os Cloud Source Repositories para controlo de versões no Looker para ver os passos de configuração do Git com os Cloud Source Repositories.
Bitbucket Cloud
Consulte a publicação da comunidade Usar o Bitbucket para o controlo de versões no Looker para ver os passos de configuração do Git com o Bitbucket Cloud. Em agosto de 2021, o Bitbucket Cloud não suporta segredos em webhooks de implementação.
Bitbucket Server
Para usar pedidos de obtenção com o Bitbucket Server, pode ter de concluir os seguintes passos:
- Quando abre um pedido de envio, o Looker usa automaticamente o número da porta predefinido (7999) no URL. Se estiver a usar um número da porta personalizado, tem de substituir manualmente o número da porta no URL.
- Tem de aceder ao webhook de implementação do projeto para sincronizar o ramo de produção no Looker com o ramo principal do repositório.
Phabricator diffusion
Consulte a publicação da comunidade Configurar o Phabricator e o Looker para o controlo de versões para ver os passos de configuração do Git com o Phabricator.
Rede
Ligações recebidas
App Web Looker
Por predefinição, o Looker ouve pedidos HTTPS na porta 9999. O Looker usa um certificado autoassinado com um CN de self-signed.looker.com. Em alternativa, o servidor do Looker pode ser configurado para fazer o seguinte:
- Aceite ligações HTTP a partir de um proxy/balanceador de carga de terminação SSL com a
--ssl-provided-externally-by=<s>flag de arranque. O valor deve ser definido como o endereço IP do proxy ou como um nome de anfitrião que possa ser resolvido localmente para o endereço IP do proxy. O Looker aceita ligações HTTP apenas a partir deste endereço IP. - Use um certificado SSL fornecido pelo cliente com a flag de arranque
--ssl-keystore=<s>.
API Looker
A API Looker é responsável pela deteção na porta 19999. Se a instalação exigir acesso à API, o balanceador de carga deve ter as regras de encaminhamento necessárias. Aplicam-se as mesmas considerações de SSL que na aplicação Web principal. Recomendamos que use uma porta distinta da aplicação Web.
Balanceadores de carga
Um balanceador de carga é frequentemente usado para aceitar um pedido HTTPS na porta 443 através do certificado do cliente e, em seguida, encaminhar o pedido para o nó do servidor do Looker na porta 9999 através do certificado autoassinado ou HTTP. Se os balanceadores de carga estiverem a usar o certificado autoassinado do Looker, têm de ser configurados para aceitar esse certificado.
Ligações inativas e limites de tempo
Quando um utilizador inicia um pedido grande no Looker, isso pode resultar numa consulta que pode ser dispendiosa de executar na base de dados. Se o utilizador abandonar esse pedido de alguma forma, por exemplo, fechando a tampa do portátil, desligando-se da rede ou fechando esse separador no navegador, o Looker quer saber e terminar essa consulta à base de dados.
Para resolver esta situação, quando a aplicação Web do cliente faz um pedido para executar uma consulta de base de dados, o navegador abre uma ligação de socket através de um pedido HTTP de longa duração ao servidor do Looker. Esta ligação vai ficar aberta e inativa. Esta tomada é desligada se a aplicação Web do cliente for terminada ou desligada de alguma forma. O servidor vai detetar essa desassociação e cancelar todas as consultas de base de dados relacionadas.
Os balanceadores de carga reparam frequentemente nestas ligações inativas abertas e terminam-nas. Para executar o Looker de forma eficaz, o equilibrador de carga tem de ser configurado para permitir que esta ligação permaneça aberta durante o tempo da consulta mais longa que um utilizador possa executar. Sugere-se um tempo limite de, pelo menos, 60 minutos.
Ligações de saída
Os servidores do Looker podem ter acesso de saída sem restrições a todos os recursos, incluindo a Internet pública. Isto simplifica muitas tarefas, como a instalação do Chromium, que requer acesso aos repositórios de pacotes para a distribuição Linux.
Seguem-se as ligações de saída que o Looker pode ter de estabelecer.
Ligação interna da base de dados
Por predefinição, o MySQL escuta as ligações na porta 3306. Os nós do Looker têm de poder iniciar ligações ao MySQL nesta porta. Consoante a forma como o repositório está alojado, pode ter de atravessar uma firewall.
Serviços externos
Os servidores de telemetria e licenças do Looker estão disponíveis através de HTTPS na Internet pública. O tráfego de um nó do Looker para ping.looker.com:443 e license.looker.com:443 pode ter de ser adicionado a uma lista de autorizações.
Ligações de armazéns de dados
As bases de dados alojadas na nuvem podem exigir uma ligação através da Internet pública. Por exemplo, se estiver a usar o BigQuery, pode ter de adicionar accounts.google.com:443 e www.googleapis.com:443 a uma lista de autorizações. Se a base de dados estiver fora da sua própria infraestrutura, consulte o anfitrião da base de dados para obter detalhes da rede.
Serviços SMTP
Por predefinição, o Looker envia correio de saída através do SendGrid. Isso pode exigir a adição de smtp.sendgrid.net:587 a uma lista de autorizações. As definições de SMTP também podem ser alteradas na configuração para usar um processador de correio diferente.
Centros de ação, servidores de ações e webhooks
Muitos destinos do programador, em particular os webhooks e os que estão ativados no painel de administração do Looker, envolvem o envio de dados através de pedidos HTTPS.
- Para webhooks, estes destinos são especificados no tempo de execução pelos utilizadores e podem ser contrários ao objetivo de criar firewalls para ligações de saída.
- Para um centro de ações, estes pedidos são enviados para
actions.looker.com. Pode encontrar detalhes na nossa documentação de configuração do Action Hub do Looker. - Para outros servidores de ações, estas solicitações são enviadas para os domínios especificados na configuração do servidor de ações pelos administradores no painel AdministraçãodoLooker.
Servidor proxy
Se não for possível aceder diretamente à Internet pública, o Looker pode ser configurado para usar um servidor proxy para pedidos HTTP(S) adicionando 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"
Tenha em atenção que as comunicações entre nós ocorrem através de HTTPS. Por isso, se usar um servidor proxy e a sua instância estiver agrupada, normalmente, vai querer adicionar os IPs/nomes de anfitrião de todos os nós no argumento Dhttp.nonProxyHosts.
Comunicações entre nós
Identificador de anfitrião interno
Num cluster, cada nó tem de conseguir comunicar com os outros nós. Para permitir isto, o nome de anfitrião ou o endereço IP de cada nó é especificado na configuração de arranque. Quando o nó é iniciado, este valor é escrito no repositório MySQL. Os outros membros do cluster podem, em seguida, consultar esses valores para comunicar com este nó. Para especificar o nome do anfitrião ou o endereço IP na configuração de arranque, adicione -H node1.looker.example.com à variável de ambiente LOOKERARGS em lookerstart.cfg.
Uma vez que o nome do anfitrião tem de ser exclusivo por nó, o ficheiro lookerstart.cfg tem de ser exclusivo em cada instância. Em alternativa à codificação rígida do nome do anfitrião ou do endereço IP, pode usar o comando hostname -I ou hostname --fqdn para os encontrar no tempo de execução. Para implementar esta ação, 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 Web e de API, respetivamente, os nós do cluster comunicam entre si através de um serviço de agente de mensagens, que usa as portas 1551 e 61616. As portas 9999 e 19999 têm de estar abertas ao tráfego do utilizador final, mas as portas 1551 e 61616 têm de estar abertas entre os nós do cluster.