Planejar, dimensionar e manter uma solução de gateway comercialmente crítica

Este artigo é indicado para quem planeja implantar um gateway de dados local em um cenário comercialmente crítico. Um gateway de dados local é comercialmente crítico quando é vital para a operação normal dos negócios e para o processamento de dados comercialmente críticos.

Se os gateways comercialmente críticos não forem gerenciados de maneira correta, as consultas poderão falhar ou ficar com desempenho lento. Quando você planeja, dimensiona e mantém corretamente sua solução de gateway comercialmente crítica, a probabilidade de problemas com impacto nos negócios pode ser minimizada.

Terminologia

Os seguintes termos importantes são usados ao longo deste artigo:

• Gateway: o aplicativo de gateway de dados local instalado em um computador.
• Servidor de gateway: um computador Windows (máquina virtual ou computador/servidor físico) que tem o aplicativo de gateway de dados local instalado.
• Cluster de gateway: um conjunto de gateways que funcionam em conjunto (e podem ter balanceamento de carga).
• Membro do gateway: um gateway que faz parte de um cluster de gateway.

A imagem a seguir demonstra a relação entre os conceitos definidos acima.

Recomendações para gateways comercialmente críticos

No caso de gateways comercialmente críticos, eles precisam ser implantados e gerenciados adequadamente para garantir alta disponibilidade, bom desempenho e escalabilidade sustentável. A implantação incorreta de gateways pode resultar em baixo desempenho, consultas com falha e dificuldade em diagnosticar possíveis problemas. Isso também pode prejudicar a capacidade de escalar os gateways vertical e horizontalmente conforme o uso aumenta.

Para garantir o nível ideal de escalabilidade, desempenho e taxa de transferência, siga as recomendações nas próximas seções.

Saiba quais são todas as chaves de recuperação de gateway

Saiba quais são todas as chaves de recuperação de gateway e guarde-as em um local seguro. Sem uma chave de recuperação, os gateways não podem ser recuperados nem passar por downgrade. Essa limitação é por design. Se você perder as chaves de recuperação, a única opção será criar outros gateways e recriar as fontes de dados. Além disso, não é possível adicionar novos gateways ao cluster sem a chave de recuperação, o que limitaria a escalabilidade futura.

Armazene as chaves de recuperação em um local seguro, assim como você armazenaria credenciais administrativas, como em um cofre de senha que possa ser acessado apenas por administradores autorizados.

Se no momento você não sabe quais são todas as chaves de recuperação de gateway, esse é um risco comercial significativo. Crie imediatamente clusters de gateway e comece a migrar as cargas de trabalho para os clusters de gateway.

Cargas de trabalho de desenvolvimento e cargas de trabalho comercialmente críticas

Separe as cargas de trabalho de desenvolvimento das comercialmente críticas configurando um ou mais clusters de gateway de desenvolvimento e um ou mais clusters de gateway de produção conforme a descrição abaixo.

Use um cluster de gateway de desenvolvimento para testar novos modelos semânticos, relatórios, consultas e assim por diante. Após a verificação de uma nova carga de trabalho, migre-a para um cluster de gateway comercialmente crítico. Esse processo impede que cargas de trabalho novas, não testadas ou experimentais tenham impactos de desempenho nas cargas de trabalho de produção.

Use também os clusters de gateway de desenvolvimento para testar as novas atualizações de gateway antes de aplicá-las aos clusters de gateway comercialmente críticos. As novas atualizações de gateway devem ser implantadas no mínimo 24 horas nos clusters de gateway de desenvolvimento antes de serem usadas em clusters de gateway comercialmente críticos.

Usar vários clusters de gateway

Se você estiver criando um cluster de gateway para um grande número de usuários na organização, precisará criar vários clusters de gateway com base em unidades de negócios ou menores para limitar possíveis impactos no desempenho a um pequeno subconjunto de usuários.

Não recomendamos que um só cluster de gateway comercialmente crítico seja usado para uma empresa inteira (a menos que a empresa seja pequena). Em um cenário de cluster de gateway único, um usuário pode enviar uma consulta que cause um impacto significativo no desempenho de todo o tráfego no gateway. Se o gateway for usado em toda a empresa, o impacto no desempenho poderá afetar toda a empresa. Além disso, quando um cluster de gateway é usado em toda a empresa, pode ser mais difícil identificar qual consulta está causando problemas de desempenho ao usar o recurso de monitoramento de desempenho do gateway.

Usar os recursos de alta disponibilidade e balanceamento de carga do gateway

Sempre use os recursos de alta disponibilidade e balanceamento de carga do gateway para qualquer cluster de gateway comercialmente crítico.

• Alta disponibilidade: impede que haja um ponto único de falha.
• Balanceamento de carga: distribui automaticamente a carga de trabalho entre todos os servidores de gateway no cluster.

Configure no mínimo dois gateways por cluster de gateway para o caso de um gateway ficar offline por algum motivo. Essa configuração garante que uma única falha de gateway não cause falha em todo o cluster de gateway. Além disso, limitações de CPU, memória e simultaneidade podem ser habilitadas nos gateways para distribuir melhor a carga no cluster de gateway.

Planejar e manter a escalabilidade do cluster de gateway

A configuração de um cluster de gateway usando nossas diretrizes de hardware e software recomendadas garante que o cluster seja executado com bom desempenho. Os gateways que não são dimensionados corretamente podem resultar em baixo desempenho. Há muitos fatores que você precisa considerar para garantir um bom desempenho no cluster de gateway.

Determinar as especificações de hardware do servidor de gateway

As especificações do servidor de gateway (CPU, memória, disco etc.) são um fator importante, pois geralmente as transformações do Power Query são aplicadas aos dados no servidor de gateway. Dessa forma, um servidor de gateway precisa ter recursos, memória e capacidade de processamento suficientes para processar todas as transformações de dados.

Quando é necessário escolher um tamanho de servidor, há duas métricas mais importantes: memória e CPU. Você precisa de bastante memória e energia da CPU para processar as etapas de transformação de dados Power Query no gateway. É importante que o servidor de gateway seja eficiente o suficiente para processar a maior carga de trabalho que você tem. Se o servidor de gateway não puder processar a carga de trabalho, o DirectQuery ou a atualização de dados falhará. Também é importante entender quantas consultas são executadas ao mesmo tempo.

Essas diferentes opções de consulta têm um efeito diferente no servidor de gateway.

Tipo de Consulta	Fator limite
Importar	Memória
DirectQuery	CPU
LiveConnect	CPU

Durante uma importação, todo o conjunto de dados precisa ser consultado e processado, o que é uma tarefa que exige muita memória. Essa importação muitas vezes também demora. DirectQueries e LiveConnections geralmente consomem muita CPU. Na maioria dos casos, as DirectQueries são executadas muitas vezes para processar apenas uma pequena parte dos dados. Como apenas uma pequena parte dos dados é processada, essas consultas diretas normalmente não exigem muita memória. Contudo, como as consultas são executadas muitas vezes sob demanda, essa ação pode exigir um alto uso da CPU.

Dependendo da carga de trabalho, considere otimizar o servidor de gateway para memória ou CPU.

Quando dimensionar um cluster de gateway

O dimensionamento é um aspecto importante de um cluster de gateway comercialmente crítico. À medida que o uso do cluster de gateway aumenta, ele precisa ser escalado vertical ou horizontalmente para garantir um bom desempenho. Recomendamos que você comece a escalar um cluster de gateway horizontalmente se já tiver escalado verticalmente os gateways no cluster.

Escalar e distribuir a carga de tráfego entre nós individuais em um cluster é um processo complexo que varia dependendo de cada cenário individual. Embora não haja um modelo definitivo para garantir que todo o tráfego de gateway seja atendido previsivelmente, os limites listados abaixo indicam uma necessidade de escala. Em geral, é recomendável dimensionar horizontalmente (adicionando nós ao cluster), de maneira preferencial para escalar verticalmente (aumentando o espaço em CPU, RAM ou disco em nós individuais). A escala horizontal tende a ser mais eficaz no geral na capacidade do sistema como um todo de lidar com o tráfego extra. A escala horizontal também tem um impacto positivo na largura de banda total que o cluster pode processar, enquanto a escala vertical geralmente não tem. Quando um ou mais nós de gateway mostram indicações de atingir os limites descritos abaixo, a escala horizontal do cluster deve ser considerada fortemente.

• CPU: a CPU está acima de 80% por longos períodos de tempo, porém picos ocasionais curtos (menos de 5 minutos) que atingiram o máximo de CPUs não são anormais.

• RAM: a memória disponível cai abaixo de 20% regularmente.

• Disco: o espaço livre em disco cai abaixo de 5 GB com frequência. Essa queda também pode indicar a necessidade de configurar o cache ou os diretórios de spool de forma mais estratégica.

• Simultaneidade: executando mais de 40 consultas simultaneamente em um único nó.

Como atualizações e consultas distribuídas entre nós de gateway podem ter perfis muito diferentes, também recomendamos que um seja realizado um escrutínio extra em trabalhos de execução longa ou com uso intensivo de memória. A otimização de consulta, nesses casos, pode ter um enorme impacto no desempenho e na escalabilidade, não apenas para os relatórios e atualizações individuais, mas para o sistema como um todo. É recomendável isolar atualizações em questão para um único cluster de gateway dedicado para avaliar as características de desempenho e executar a otimização usando diagnóstico de plano de consulta, indicadores de dobra e todas as outras recomendações de desempenho publicadas. Esse isolamento minimiza a quantidade de dados recuperados e a quantidade necessária de pós-processamento. Esse isolamento também pode ser usado como uma estratégia de longo prazo para sequestrar trabalhos ETL de longa execução para um cluster de gateway dedicado, a fim de reduzir a contenção com outras atualizações típicas em toda a organização.

Escalar verticalmente um cluster de gateway

A escala vertical consiste em aumentar as especificações (CPU, memória, disco e assim por diante) dos servidores gateway.

A escala vertical pode ser necessária se a CPU ou a memória máxima é atingida quando o gateway executa uma ou mais consultas. Uma consulta só pode ser executada em um servidor de gateway, razão pela qual o servidor de gateway deve ter recursos suficientes disponíveis para processar a consulta inteira junto com os dados resultantes.

Escalar horizontalmente um cluster de gateway

A escala horizontal será necessária se o servidor de gateway já tiver especificações altas (ou seja, já estiver sendo escalado verticalmente) ou se você atingir os limites do que um só servidor de gateway pode gerenciar em razão do número de consultas simultâneas executadas. O aumento de carga de base ampla em todo o conjunto de membros do gateway é uma boa indicação de que escalar um cluster adicionando nós é o curso de ação correto. Quando escalar um cluster de gateway fornece limites específicos que indicam quando é hora de dimensionar. Para obter mais informações sobre escala horizontal, acesse Usar os recursos de alta disponibilidade e balanceamento de carga de gateway.

Dimensionar por meio da criação de clusters de gateway

Se o uso de recursos do cluster de gateway for alto ou se um número extremamente grande de usuários depender de um cluster de gateway, um outro cluster de gateway poderá ser criado. Um subconjunto da carga de trabalho poderá ser migrado para o novo cluster de gateway. Quando um grande número de usuários depende de um só cluster de gateway, aumenta bastante a probabilidade de que um usuário envie uma consulta que cause um impacto significativo no desempenho em todo o cluster de gateway.

Um número extremamente grande de usuários que dependem de um só cluster de gateway é um indicador de que outro cluster de gateway deve ser criado.

Monitorar e solucionar problemas de desempenho do gateway

É importante monitorar o desempenho geral dos gateways comercialmente críticos usando o recurso de monitoramento de desempenho do gateway. Também é possível usar esse recurso para solucionar problemas de desempenho, identificar gargalos e identificar consultas que estejam afetando o desempenho geral do gateway. Esse recurso também é uma ferramenta importante para ajudar você a determinar quando dimensionar um cluster de gateway.

Se você identificar uma consulta com grande impacto no gateway, prejudicando o desempenho geral, reescreva a consulta para que fique mais eficiente e minimize o impacto no desempenho.

Se a Microsoft identificar um baixo desempenho causado por um gateway ou um componente relacionado ao gateway, como a capacidade do Power BI Premium com sobrecarga, o componente sobrecarregado precisará ser corrigido por meio do dimensionamento ou da redução da carga. A Microsoft não investiga o baixo desempenho quando um gateway ou um componente relacionado ao gateway está sobrecarregado.