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 consultas, 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 saber mais, confira 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 consultas com até sete recursos de réplica de consulta a mais (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 funciona

Quando você configura o dimensionamento horizontal pela primeira vez, bancos de dados modelo no servidor primário são sincronizados automaticamente 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 do pool de consultas são então preenchidas 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 modelos (atualizar) 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 a 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 primeiro processar dados no servidor primário, executar uma sincronização e, em seguida, 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 Sync-AzAnalysisServicesInstance PowerShell que remove os arquivos/s desse banco de dados do local de armazenamento de blobs compartilhado da réplica e, em seguida, exclui o banco de dados modelo nas réplicas no pool de consultas. Para determinar se existe um banco de dados de modelo em réplicas no pool de consultas, mas não no servidor primário, verifique se o servidor de processamento separado da configuração do pool de consultas é 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 renomear, execute uma sincronização usando o comando Sync-AzAnalysisServicesInstance especificando o -Database parâmetro com o nome do banco de dados antigo. 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 , agora você pode especificar que a sincronização de réplica de consulta ocorre 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 de quanto do cache precisa ser atualizado, mais memória pode ser consumida pelas réplicas de consulta. Para manter o banco de dados online e disponível para consultas, dependendo de quanto dos dados foram alterados, a operação pode exigir até o dobro da memória na réplica porque 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 base no ServerResourceType

1. Em um gráfico de linhas de Métricas, clique em Adicionar métrica.
2. No RESOURCE, selecione o servidor e, em SEGUIDA, no NAMESPACE DE MÉTRICA, selecione as métricas padrão do Analysis Services, em MÉTRICA, selecione QPU e, em AGREGAÇÃO, selecione Avg.
3. Clique em Aplicar Divisã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, consulte Analisar logs no workspace do Log Analytics. Para obter consultas de exemplo, consulte Consultas de exemplo de Kusto.

Configurar escalonamento horizontal

No Portal do Azure

1. No portal, clique em Escalar horizontalmente. Use a barra deslizante para selecionar o número de servidores de réplicas de consultas. O número de réplicas escolhido é além dos servidores existentes.

2. Em Separar o servidor de processamento do pool de consultas, selecione sim para excluir o servidor de processamento dos servidores de consulta. As conexões de cliente que usam a cadeia de conexão padrão (sem :rw) são redirecionadas para réplicas no pool de consultas.

   

3. Clique em Salvar para provisionar seus novos servidores de réplica de consultas.

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. Alterações subsequentes no número de réplicas no mesmo servidor não disparam 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

No modelo >De visão geral>, sincronize o 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
3	Falha
4	Finalização

PowerShell

Observação

Recomendamos que você use o módulo do 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 do Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

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

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 consultas, use Set-AzAnalysisServicesServer. Especifique o parâmetro -DefaultConnectionMode opcional para usar Readonly.

Para saber mais, confira Como usar 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 Power BI Desktop, Excel e aplicativos personalizados, use o nome do servidor.

Para SSMS, Visual Studio e cadeias de conexão no PowerShell, nos aplicativos do Azure Function e no 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

Questão: Os usuários recebem um erro e não conseguem encontrar a instância do servidor '<Nome do servidor>' no modo de conexão 'ReadOnly'.

Solução: Ao selecionar o servidor de processamento separado da opção de pool de consultas, as conexões de cliente usando a cadeia de conexão padrão (sem :rw) são redirecionadas para réplicas do pool de consultas. 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