Escala horizontal do Azure Analysis Services

Com a expansão, as consultas de cliente podem ser distribuídas entre várias réplicas de consulta em um pool de consulta, reduzindo os tempos de resposta durante cargas de trabalho de consulta altas. Você também pode separar o processamento do pool de consultas, garantindo que as consultas não são afetadas negativamente pelas operações de processamento. A escala horizontal pode ser configurada no Portal do Azure ou usando a API REST do Azure Analysis Services.

A escala horizontal está disponível para servidores no tipo de preço Standard. Cada réplica de consulta é cobrada com a mesma taxa de seu servidor. Todas as réplicas de consulta são criadas na mesma região que o servidor. O número de réplicas de consulta que você pode configurar é limitado pela região em que o seu servidor está. Para obter mais informações, veja Disponibilidade por região. A expansão não aumenta a quantidade de memória disponível para o servidor. Para aumentar a memória, você precisa atualizar seu plano.

Por que escalar horizontalmente?

Em uma implantação típica do servidor, um servidor funciona como o servidor de processamento e o servidor de consulta. Se o número de consultas de cliente em modelos em seu servidor exceder as QPUs (Unidades de Processamento de Consulta) do plano do servidor ou o processamento de modelo ocorrer ao mesmo tempo que cargas de trabalho de consulta altas, o desempenho poderá diminuir.

Com a expansão, você pode criar um pool de consulta com até mais sete recursos de réplica de consulta (oito no total, incluindo o servidor primário). Você pode escalar o número de réplicas no pool de consulta para atender às demandas de QPU em momentos críticos e você pode separar um servidor de processamento do pool de consultas a qualquer momento.

Independentemente do número de réplicas de consulta que você tem em um pool de consulta, as cargas de trabalho de processamento não são distribuídas entre as réplicas de consulta. O servidor primário atua como o servidor de processamento. Réplicas de consulta servem apenas as consultas em relação ao modelo de banco de dados sincronizado entre o servidor primário e cada réplica no pool de consulta.

Ao escalar horizontalmente, pode levar até cinco minutos para que novas réplicas de consulta sejam adicionadas incrementalmente ao pool de consulta. Quando todas as novas réplicas de consulta estiverem ativas e em execução, novas conexões de cliente serão balanceadas por carga em todos os recursos do pool de consulta. As conexões de clientes existentes não são alteradas a partir do recurso ao qual elas estão conectadas atualmente. Quando você reduz horizontalmente, todas as conexões de cliente existentes com um recurso de pool de consultas que está sendo removido do pool de consultas são encerradas. Os clientes podem se reconectar a um recurso do pool de consultas restante.

Como ele funciona

Quando você configura a expansão horizontal na primeira vez, os modelos de banco de dados no servidor primário são automaticamente sincronizados com novas réplicas em um novo pool de consultas. A sincronização automática ocorre apenas uma vez. Durante a sincronização automática, os arquivos de dados do servidor primário (criptografados em repouso no armazenamento de blob) são copiados para um segundo local, também criptografado em repouso no armazenamento de blob. As réplicas no pool de consultas são então hidratadas com dados do segundo conjunto de arquivos.

Embora uma sincronização automática seja executada somente quando você dimensiona um servidor pela primeira vez, você também pode executar uma sincronização manual. A sincronização garante que os dados em réplicas no pool de consulta correspondam ao servidor primário. Ao processar (atualizar) modelos no servidor primário, uma sincronização deve ser executada após a conclusão das operações de processamento. Essa sincronização copia os dados atualizados dos arquivos do servidor primário no armazenamento de blob para o segundo conjunto de arquivos. As réplicas no pool de consultas são então hidratadas com dados atualizados do segundo conjunto de arquivos no armazenamento de blob.

Ao executar uma operação de expansão subsequente, como aumentar o número de réplicas no pool de consultas de duas para cinco, as novas réplicas são hidratadas com dados do segundo conjunto de arquivos no armazenamento de blob. Não há sincronização. Se você executar uma sincronização depois de escalar horizontalmente, as novas réplicas no pool de consultas seriam hidratadas duas vezes – uma hidratação redundante. Ao executar uma operação de expansão subsequente, é importante ter em mente:

• Execute uma sincronização antes da operação de expansão para evitar hidratação redundante das réplicas adicionadas. A execução da sincronização simultânea e das operações de expansão ao mesmo tempo não é permitida.

• Ao automatizar operações de processamento e expansão, é importante processar primeiro os dados no servidor primário, depois executar uma sincronização e executar a operação de expansão. Essa sequência garante um impacto mínimo nos recursos de memória e QPU.

• Durante as operações de expansão, todos os servidores no pool de consultas, incluindo o servidor primário, estarão temporariamente offline.

• A sincronização é permitida mesmo quando não há réplicas no pool de consultas. Se você estiver expandindo de zero para uma ou mais réplicas com novos dados de uma operação de processamento no servidor primário, execute a sincronização primeiro sem réplicas no pool de consultas e, em seguida, faça a expansão. Sincronizar antes de expandir evita a hidratação redundante das réplicas recém-adicionadas.

• Quando você exclui um modelo de banco de dados do servidor primário, ele não é excluído automaticamente das réplicas no pool de consultas. Você deve executar uma operação de sincronização usando o comando do PowerShell Sync-AzAnalysisServicesInstance, que remove o(s) arquivo(s) do banco de dados do local de armazenamento de blob compartilhado da réplica e exclui o modelo de banco de dados nas réplicas no pool de consultas. Para determinar se um modelo de banco de dados existe em réplicas no pool de consultas, mas não no servidor primário, certifique-se de que a configuração Separar o servidor de processamento da consulta do pool seja Sim. Use o SSMS (SQL Server Management Studio) para se conectar ao servidor primário usando o qualificador :rw para ver se o banco de dados existe. Conecte-se às réplicas no pool de consultas conectando-se sem o qualificador :rw para ver se o mesmo banco de dados também existe. Se o banco de dados existir em réplicas no pool de consultas, mas não no servidor primário, execute uma operação de sincronização.

• Quando você renomeia um banco de dados no servidor primário, há outra etapa necessária para garantir que o banco de dados seja sincronizado corretamente com todas as réplicas. Após a renomeação, execute uma sincronização usando o comando Sync-AzAnalysisServicesInstance especificando o parâmetro -Database com o nome antigo do banco de dados. Essa sincronização remove o banco de dados e os arquivos com o nome antigo de qualquer réplica. Depois, execute outra sincronização especificando o parâmetro -Database com o novo nome do banco de dados. A segunda sincronização copia o banco de dados nomeado recentemente para o segundo conjunto de arquivos e hidrata todas as réplicas. Essas sincronizações não podem ser executadas usando o comando Sincronizar modelo no portal.

Modo de sincronização

Por padrão, as réplicas de consulta são reidratadas completamente e não de forma incremental. A reidratação acontece em fases. Elas são desanexadas e anexadas duas de cada vez (supondo que haja pelo menos três réplicas) para garantir que pelo menos uma réplica seja mantida online para consultas em um determinado momento. Em alguns casos, os clientes podem precisar se reconectar a uma das réplicas online durante esse processo. Usando a configuração ReplicaSyncMode, você agora pode especificar que a sincronização da réplica de consulta ocorra em paralelo. A sincronização paralela oferece os seguintes benefícios:

• Redução significativa no tempo de sincronização.
• Os dados entre réplicas têm maior probabilidade de serem consistentes durante o processo de sincronização.
• Como os bancos de dados são mantidos online em todas as réplicas durante o processo de sincronização, os clientes não precisam se reconectar.
• O cache na memória é atualizado de forma incremental com apenas os dados alterados, o que pode ser mais rápido do que reidratar o modelo completamente.

Definir ReplicaSyncMode

Use o SSMS para definir ReplicaSyncMode em Propriedades avançadas. Os valores possíveis são:

• 1 (padrão): reidratação completa de banco de dados de réplica em fases (incremental).
• 2: sincronização otimizada em paralelo.

Ao definir ReplicaSyncMode=2, dependendo da quantidade do cache que precisa ser atualizada, as réplicas de consulta podem consumir mais memória. Para manter o banco de dados online e disponível para consultas, dependendo da quantidade de dados alterada, a operação pode exigir até o dobro da memória na réplica, pois os segmentos antigos e novos são mantidos na memória simultaneamente. Os nós de réplica têm a mesma alocação de memória que o nó primário e normalmente há memória extra no nó primário das operações de atualização. Portanto, talvez seja improvável que as réplicas fiquem sem memória. Além disso, o cenário comum é que o banco de dados tenha uma atualização incremental no nó primário e, portanto, o requisito para o dobro da memória deve ser incomum. Se a operação de sincronização encontrar um erro de memória insuficiente, ela tentará novamente usando a técnica padrão (anexar/desanexar duas de cada vez).

Separe o processamento do pool de consulta

Para desempenho máximo para operações de processamento e consulta, você pode optar por separar seu servidor de processamento do pool de consulta. Quando separados, as conexões novas do cliente são atribuídas a réplicas de consulta apenas no pool de consulta. Se as operações de processamento ocuparem apenas um curto período de tempo, você poderá optar por separar seu servidor de processamento do pool de consulta apenas pelo tempo necessário para executar operações de processamento e sincronização e, em seguida, incluí-lo novamente no pool de consultas. Separar o servidor de processamento do pool de consulta ou adicioná-lo de volta ao pool de consultas pode levar até cinco minutos para que a operação seja concluída.

Monitorar o uso de QPU

Para determinar se a expansão do servidor é necessária, monitore as métricas do servidor no portal do Azure. Se a QPU for maximizada regularmente, isso significa que o número de consultas em relação aos modelos está excedendo o limite de QPU do plano. A métrica de comprimento da fila do trabalho do pool de consulta também aumenta quando o número de consultas na fila do pool de thread de consulta excede a QPU disponível.

Outra boa métrica a ser observada é a média de QPU por ServerResourceType. Essa métrica compara a QPU média do servidor primário com o pool de consulta.

Para configurar a QPU com ServerResourceType

1. Em um gráfico de linhas de Métricas, clique em Adicionar métrica.
2. Em RECURSO, selecione o servidor e, em NAMESPACE DA MÉTRICA, selecione Métricas padrão do Analysis Services, em MÉTRICA, selecione QPUe em AGREGAÇÃO, selecione Méd.
3. Clique em Aplicar separação.
4. Em VALORES, selecione ServerResourceType.

Log de diagnóstico detalhado

Use os logs do Azure Monitor para obter diagnósticos mais detalhados dos recursos do servidor de escalabilidade horizontal. Com os logs, você pode usar consultas do Log Analytics para dividir a QPU e a memória por servidor e réplica. Para obter mais informações, confira Analisar logs no workspace do Log Analytics. Para ver exemplos de consultas, consulte Exemplo de Consultas Kusto.

Configurar a escala horizontal

No Portal do Azure

1. No portal, clique em Expansão. Use o controle deslizante para selecionar o número de servidores de réplica de consulta. O número de réplicas escolhido é além dos servidores existentes.

2. Em Separar o servidor de processamento do pool de consulta, selecione Sim para excluir o servidor de processamento dos servidores de consulta. Conexões de cliente usando a cadeia de caracteres de conexão padrão (sem :rw) são redirecionadas para as réplicas no pool de consulta.

   

3. Clique em Salvar para provisionar os novos servidores de réplica de consulta.

Ao configurar a expansão de um servidor pela primeira vez, os modelos no servidor primário são sincronizados automaticamente com réplicas no pool de consulta. A sincronização automática ocorre apenas uma vez, quando você configura primeiro a expansão para uma ou mais réplicas. As alterações subsequentes no número de réplicas do mesmo servidor não dispararão outra sincronização automática. A sincronização automática não ocorrerá novamente mesmo que você defina o servidor como zero réplicas e escale horizontalmente para qualquer número de réplicas.

Sincronizar

As operações de sincronização devem ser executadas manualmente ou usando a API REST.

No Portal do Azure

Em Visão Geral> modelo >Sincronizar modelo.

API REST

Use a operação de sincronização.

Sincronizar um modelo

POST https://<region>.asazure.windows.net/servers/<servername>:rw/models/<modelname>/sync

Obter o status de sincronização

GET https://<region>.asazure.windows.net/servers/<servername>/models/<modelname>/sync

Códigos de status de devolução:

Código	Descrição
-1	Inválido
0	Replicar
1	Reidratação
2	Concluído(a)
3	Com falha
4	Finalização

PowerShell

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

Antes de usar o PowerShell, instale ou atualize o módulo do Azure PowerShell mais recente.

Para executar a sincronização, use Sync-AzAnalysisServicesInstance.

Para definir o número de réplicas de consulta, use Set-AzAnalysisServicesServer. Especifique o parâmetro -ReadonlyReplicaCount opcional.

Para separar o servidor de processamento do pool de consulta, use Set-AzAnalysisServicesServer. Especifique o parâmetro -DefaultConnectionMode opcional para usar Readonly.

Para saber mais, confira Usando uma entidade de serviço com o módulo Az.AnalysisServices.

conexões

Na página Visão Geral do servidor, há dois nomes de servidor. Se você ainda não tiver configurado a escala horizontal para um servidor, os dois nomes de servidor funcionam da mesma forma. Depois de configurar a expansão para um servidor, você precisará especificar o nome do servidor adequado dependendo do tipo de conexão.

Para conexões de cliente do usuário final como o Power BI Desktop, Excel e aplicativos personalizados, use Nome do servidor.

Para SSMS, Visual Studio e cadeias de conexão no PowerShell, aplicativos do Azure Functions e AMO, use o Nome do servidor de gerenciamento. O nome do servidor de gerenciamento inclui um qualificador especial :rw (leitura-gravação). Todas as operações de processamento ocorrem no servidor de gerenciamento (primário).

Escalar verticalmente, reduzir verticalmente versus escalar horizontalmente

Você pode alterar o tipo de preço em um servidor com várias réplicas. O mesmo tipo de preço se aplica a todas as réplicas. Uma operação de escala primeiro reduz todas as réplicas de uma só vez e, em seguida, aumenta todas as réplicas do novo tipo de preço.

Solucionar problemas

Problema: os usuários obtêm um erro não é possível encontrar o servidor ''<Nome da instância do servidor>'' no modo de conexão ''ReadOnly''.

Solução: ao selecionar a opção Separar o servidor de processamento do pool de consulta, conexões de cliente usando a cadeia de conexão padrão (sem :rw) são redirecionadas para réplicas de pool de consulta. Se as réplicas no pool de consulta estiverem ainda online porque a sincronização ainda não foi concluída, as conexões de cliente redirecionada podem falhar. Para evitar conexões com falha, deve haver, pelo menos, dois servidores no pool de consulta ao executar uma sincronização. Cada servidor é sincronizado individualmente, enquanto os outros permanecem online. Se você optar por não ter o servidor de processamento no pool de consulta durante o processamento, você poderá optar por removê-lo do pool para processamento e, em seguida, adicioná-lo novamente ao pool após a conclusão do processamento, mas antes da sincronização. Use as métricas Memória e QPU para monitorar o status de sincronização.

Informações relacionadas

Monitorar o Azure Analysis ServicesGerenciar o Azure Analysis Services