Gerenciamento de recursos em pools elásticos densos

Aplica-se a: Banco de Dados SQL do Azure

Os pools elásticos do Banco de Dados SQL do Azure são uma solução econômica para o gerenciamento de muitos bancos de dados com diferentes usos de recursos. Todos os bancos de dados em um pool elástico compartilham a mesma alocação de recursos, como CPU, memória, threads de trabalho, espaço de armazenamento, tempdb, sob a hipótese de que somente um subconjunto de bancos de dados no pool usará recursos de computação em um determinado momento. Essa hipótese permite que os pools elásticos sejam econômicos. Em vez de pagar por todos os recursos que cada banco de dados poderia precisar, os clientes pagam por um conjunto muito menor de recursos, compartilhados entre todos os bancos de dados no pool.

Governança de recursos

O compartilhamento de recursos exige que o sistema controle cuidadosamente o uso de recursos para minimizar o efeito de "vizinho barulhento", em que um banco de dados com alto consumo de recursos afeta outros bancos no mesmo pool elástico. O Banco de Dados SQL do Azure atinge essas metas implementando a governança de recursos. Ao mesmo tempo, o sistema deve oferecer recursos suficientes para funcionalidades como HADR (alta disponibilidade e recuperação de desastre), backup e restauração, monitoramento, Repositório de Consultas, ajuste automático etc. para funcionar de modo confiável.

A economia é a meta de design principal dos pools elásticos. Por esse motivo, o sistema permite intencionalmente que os clientes criem pools densos, que são os pools com um número de bancos de dados que se aproximam ou estão no máximo permitido, mas com uma alocação moderada de recursos de computação. Pelo mesmo motivo, o sistema não reserva todos os recursos potencialmente necessários para seus processos internos, mas permite o compartilhamento de recursos entre os processos internos e as cargas de trabalho do usuário.

Essa abordagem permite que os clientes usem pools elásticos densos para atingir o desempenho adequado e maior economia de custos. No entanto, se a carga de trabalho em relação a muitos bancos de dados em um pool denso for suficientemente intensa, a contenção de recursos se tornará significativa. A contenção de recursos reduz o desempenho da carga de trabalho do usuário e pode afetar negativamente os processos internos.

Quando a contenção de recursos ocorre em um pool denso, os clientes podem escolher uma ou mais das seguintes ações para atenuá-la:

• Ajustar a carga de trabalho de consulta para reduzir o consumo de recursos ou distribuir o consumo de recursos entre vários bancos de dados ao longo do tempo.
• Reduzir a densidade do pool movendo alguns bancos de dados para outro pool ou tornando-os bancos de dados autônomos.
• Escalar verticalmente o pool para obter mais recursos.

Para ver sugestões sobre como implementar as duas últimas ações, confira as Recomendações operacionais mais adiante neste artigo. Reduzir a contenção de recursos beneficia as cargas de trabalho do usuário e os processos internos, além de permitir que o sistema mantenha o nível de serviço esperado de modo confiável.

Monitorar o consumo de recursos

Para evitar a degradação do desempenho devido à contenção de recursos, os clientes que usam pools elásticos densos devem monitorar proativamente o consumo de recursos e tomar medidas oportunas se o aumento da contenção de recursos começar a afetar as cargas de trabalho. O monitoramento contínuo é importante porque o uso de recursos em um pool muda ao longo do tempo devido a alterações na carga de trabalho do usuário, nos volumes de dados e na distribuição, na densidade do pool e no serviço do Banco de Dados SQL do Azure.

O Banco de Dados SQL do Azure conta com várias métricas relevantes para esse tipo de monitoramento. Exceder o valor médio recomendado para cada métrica indica que é preciso conter recursos no pool, o que deve ser resolvido usando uma das ações mencionadas anteriormente.

Para enviar um alerta quando a utilização de recursos do pool (CPU, E/S de dados, E/S de log, trabalhos etc.) excede um limite, considere criar alertas usando o portal do Azure ou o cmdlet Add-AzMetricAlertRulev2 do PowerShell. Ao monitorar pools elásticos, considere também criar alertas para bancos de dados individuais no pool, se necessário para o cenário. Para um cenário de exemplo de monitoramento de pools elásticos, confira Monitorar e gerenciar o desempenho do Banco de Dados SQL do Azure em um aplicativo SaaS multilocatário.

Além dessas métricas, o Banco de Dados SQL do Azure conta com uma exibição que retorna os limites de governança de recursos reais, bem como exibições adicionais que retornam estatísticas de utilização de recursos no nível do pool de recursos e no nível do grupo de carga de trabalho.

Essas exibições podem ser usadas para monitorar a utilização de recursos e solucionar problemas de contenção de recursos quase em tempo real. A carga de trabalho do usuário nas réplicas secundárias e primárias para leitura, incluindo réplicas geográficas, é classificada no pool de recursos SloSharedPool1 e no grupo de carga de trabalho UserPrimaryGroup.DBId[N], em que N significa o valor da ID do banco de dados.

Além de monitorar a utilização de recursos atual, os clientes que usam pools densos podem manter dados históricos de utilização de recursos em um armazenamento de dados separado. Esses dados podem ser usados na análise preditiva para gerenciar proativamente a utilização de recursos com base em tendências históricas e sazonais.

Recomendações operacionais

Deixe espaço reserva dinâmica suficiente para o recurso. Se ocorrerem contenção de recursos e degradação do desempenho, a mitigação poderá envolver a retirada de alguns bancos de dados do pool elástico afetado ou o escalada vertical do pool, conforme já dito. No entanto, essas ações exigem recursos de computação adicionais para serem concluídas. Em particular, para os pools Premium e Comercialmente Crítico, essas ações exigem a transferência de todos os dados para os bancos que estão sendo movidos ou para todos os bancos de dado no pool elástico, se o pool for escalado verticalmente. A transferência de dados é uma operação de execução prolongada com uso intensivo de recursos. Se o pool já estiver sob alta pressão de recursos, a própria operação de mitigação diminuirá o desempenho ainda mais. Em casos extremos, talvez não seja possível resolver a contenção de recursos por meio da movimentação do banco de dados ou da expansão do pool, porque os recursos necessários não estão disponíveis. Nesse caso, reduzir temporariamente a carga de trabalho de consulta no pool elástico afetado pode ser a única solução.

Os clientes que usam pools densos devem monitorar de perto as tendências de utilização de recursos, conforme descrito anteriormente, e realizar ações de mitigação enquanto as métricas permanecem dentro dos intervalos recomendados e ainda há recursos suficientes no pool elástico.

A utilização de recursos depende de vários fatores que mudam ao longo do tempo para cada banco de dados e cada pool elástico. Ter a taxa ideal de preço/desempenho em pools densos requer monitoramento e rebalanceamento contínuos, ou seja, mover bancos de dados dos pools mais usados para pools menos usados e criar pools conforme o necessário para acomodar a maior carga de trabalho.

Não mova bancos de dados "quente" . Se a contenção de recursos no nível do pool for causada principalmente por um pequeno número de bancos de dados altamente usados, poderá ser tentador mover esses bancos de dados para um pool menos utilizado ou torná-los bancos de dados autônomos. No entanto, fazer isso enquanto um banco de dados permanece altamente utilizado não é recomendado, pois a operação de movimentação diminuirá ainda mais o desempenho, tanto para o banco de dados que está sendo movido quanto para o pool inteiro. Em vez disso, aguarde até que a alta utilização diminua ou mova bancos de dados menos usados em vez de reduzir a pressão de recursos no nível do pool. Mas mover bancos de dados pouco usados não oferece nenhum benefício nesse caso, pois não reduz materialmente a utilização de recursos no nível do pool.

Crie bancos de dados em um pool de "quarentena" . Em cenários em que novos bancos de dados são criados com frequência, como aplicativos que usam o modelo locatário por banco de dados, há risco de que um novo banco de dados colocado em um pool elástico existente consuma recursos significativos de maneira inesperada e afete outros bancos dados e processos internos no pool. Para atenuar esse risco, crie um pool separado de "quarentena" com uma ampla alocação de recursos. Use esse pool para novos bancos de dados com padrões de consumo de recursos ainda desconhecidos. Quando um banco de dados permanece nesse pool por um ciclo empresarial, como uma semana ou um mês, e seu consumo de recursos é conhecido, ele pode ser movido para um pool com capacidade suficiente para acomodar esse uso de recurso adicional.

Monitore os espaços usados e alocados. Quando o espaço do pool alocado (o tamanho total de todos os arquivos de banco de dados no armazenamento de todos os bancos em um pool) atinge o tamanho máximo do pool, podem ocorrer erros de espaço insuficiente. Se as tendências de espaço alocado estiverem altas e no caminho para alcançar o tamanho máximo do pool, considere estas opções de mitigação:

• Mover alguns bancos de dados para fora do pool para reduzir o espaço alocado total
• Reduzir arquivos de banco de dados para diminuir o espaço alocado vazio nos arquivos
• Escalar verticalmente o pool para um objetivo de serviço com um tamanho máximo de pool maior

Se o espaço do pool usado (tamanho total dos dados em todos os bancos de dado em um pool, excluindo o espaço vazio nos arquivos) tiver alta tendência e estiver no caminho para alcançar o tamanho máximo do pool, considere estas opções de mitigação:

• Mover alguns bancos de dados para fora do pool para reduzir o espaço total usado
• Mover (arquivar) os dados fora do banco de dados ou excluir os dados desnecessários
• Implementar a compactação de dados
• Escalar verticalmente o pool para um objetivo de serviço com um tamanho máximo de pool maior

Evite servidores excessivamente densos. O Banco de Dados SQL do Azure é compatível com até cinco mil bancos de dados por servidor. Os clientes que usam pools elásticos com milhares de bancos de dados podem considerar o uso de vários pools elásticos em um servidor, com o número total de bancos de dados até o limite permitido. No entanto, os servidores com muitos milhares de bancos de dados criam desafios operacionais. As operações que exigem a enumeração de todos os bancos de dados em um servidor serão mais lentas, por exemplo, a exibição de bancos de dados no portal. Erros operacionais, como a modificação incorreta de logons no nível do servidor ou regras de firewall, afetarão um número maior de bancos de dados. A exclusão acidental do servidor exigirá ajuda do Suporte da Microsoft para recuperar bancos de dados no servidor excluído e causará uma interrupção prolongada para todos os bancos de dados afetados.

Limite o número de bancos de dados por servidor a um número menor do que o máximo com suporte. Em muitos cenários, o uso de até 1.000 a 2.000 bancos de dados por servidor é o ideal. Para reduzir a probabilidade de exclusão acidental de servidor, coloque um bloqueio de exclusão no servidor ou em seu grupo de recursos.

Exemplos

Exibir configurações de capacidade de banco de dados individual

Use o modo de exibição de gerenciamento dinâmico sys.dm_user_db_resource_governance para ver as configurações reais e as definições de capacidade usadas pela governança de recursos no banco de dados atual ou no pool elástico. Para obter mais informações, confira sys.dm_user_db_resource_governance.

Execute essa consulta em qualquer banco de dados em um pool elástico. Todos os bancos de dados no pool têm as mesmas configurações de governança de recursos.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Como monitorar o consumo geral de recursos do pool elástico

Use a exibição de catálogo do sistema sys.elastic_pool_resource_stats para monitorar o consumo de recursos do pool inteiro. Para obter mais informações, confira sys.elastic_pool_resource_stats.

Essa consulta de exemplo para exibir os últimos dez minutos deve ser executada no banco de dados master do servidor lógico do SQL do Azure que contém o pool elástico desejado.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Como monitorar o consumo de recursos do banco de dados individual

Use o modo de exibição de gerenciamento dinâmico sys.dm_db_resource_stats para monitorar o consumo de recursos de bancos de dados individuais. Para obter mais informações, confira sys.dm_db_resource_stats. Existe uma linha para cada 15 segundos, mesmo que não haja atividade. Os dados históricos são mantidos por cerca de uma hora.

Essa consulta de exemplo para exibir os últimos dez minutos de dados deve ser executada no banco de dados desejado.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Por um tempo maior de retenção com menos frequência, considere a seguinte consulta em sys.resource_stats, executada no banco de dados master do servidor lógico do SQL do Azure. Para obter mais informações, confira sys.resource_stats (Banco de Dados SQL do Azure). Existe uma linha a cada cinco minutos e os dados históricos são mantidos por duas semanas.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Monitorar o uso de memória

Essa consulta calcula a métrica oom_per_second de cada pool de recursos do histórico recente, com base no número de instantâneos disponíveis. Essa consulta de exemplo ajuda a identificar o número médio recente de alocações de memória com falha no pool. Essa consulta pode ser executada em qualquer banco de dados em um pool elástico.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Monitoramento do uso do espaço de log tempdb

Essa consulta retorna o valor atual da métrica tempdb_log_used_percent, mostrando o uso relativo do log de transações tempdb em relação ao tamanho máximo permitido. Essa consulta pode ser executada em qualquer banco de dados em um pool elástico.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Próximas etapas

• Para ver uma introdução aos pools elásticos, confira Pools elásticos ajudam você a gerenciar e dimensionar vários bancos de dados no Banco de Dados SQL do Azure.
• Para saber mais sobre como ajustar cargas de trabalho de consulta a fim de reduzir a utilização de recursos, confira Monitoramento e ajuste e Monitoramento e ajuste de desempenho.