Práticas recomendadas de arquitetura para a Instância Gerenciada de SQL do Azure

Examine cotas, limites e problemas conhecidos da Instância Gerenciada de SQL: A Instância Gerenciada de SQL impõe limites de implantação regionais, contagens de banco de dados e tetos de armazenamento que variam de acordo com o tipo e a camada de assinatura. Implantações de nível superior consomem mais cota de vCore, o que restringe o planejamento de capacidade regional.

• Considere problemas conhecidos que afetam grupos de failover, o comportamento do backup durante o uso do link de replicação e restrições de migração de versões mais antigas do SQL Server. Examine essas limitações durante o design inicial para evitar restrições que você não pode corrigir facilmente mais tarde.

Prever possíveis falhas: Use a análise do modo de falha para prever falhas e planejar mitigações para a Instância Gerenciada de SQL.

Criar redundância por meio da distribuição de zona e da seleção de camada apropriada: Use a redundância de zona e a seleção de camada apropriada para eliminar pontos únicos de falha em uma região.

• Ative a redundância no nível da zona para distribuir réplicas entre as zonas de disponibilidade. A arquitetura e a qualificação diferem por camada e configuração de implantação.

• Avalie os efeitos de redundância sobre o desempenho e os serviços dependentes, incluindo latência entre zonas em cargas de trabalho OLTP (processamento de transações online) e alinhamento do armazenamento de backup com implantações com redundância de zona.

Planeje o dimensionamento em torno dos tempos de entrega da operação de gerenciamento: As operações de gerenciamento levam horas em vez de minutos, o que requer uma abordagem diferente para dimensionar a estratégia e o planejamento de capacidade.

• Prevejo cronogramas estendidos para a criação da primeira sub-rede, o que leva significativamente mais tempo devido ao provisionamento de cluster virtual. Operações concorrentes são enfileiradas sequencialmente dentro de uma sub-rede.

• Dimensionar sub-redes com margem para expansão futura. Sub-redes subdimensionadas restringem o crescimento e as gerações mistas de hardware criam clusters virtuais separados que consomem endereços IP extras.

• Pré-provisionar instâncias em espera quando você precisar de tempos de resposta rigorosos para escalabilidade. Isole cargas de trabalho de produção em sub-redes dedicadas para impedir bloqueios operacionais entre instâncias.

Configure o monitoramento e alertas para o status de integridade e replicação por exemplo: Priorize alertas nas métricas que sinalizam os riscos de confiabilidade antecipadamente. Acompanhe a disponibilidade da instância por meio de eventos do Resource Health, monitore as transições de status da operação de gerenciamento por meio de um log de atividades e verifique a conclusão do backup automatizado regularmente, pois falhas de backup podem surgir silenciosamente quando o armazenamento enche ou ocorrem problemas de DNS. Para instâncias configuradas com grupos de failover, emita alertas sobre o atraso de replicação conforme os limites do RPO (objetivo de ponto de recuperação) para detectar descompasso de replicação geográfica antes que cause uma exposição inaceitável à perda de dados.

As transições de status do grupo de failover revelam interrupções antes que se transformem em lacunas de recuperação.

Implementar a resiliência de conexão e técnicas de autopreservação: Desenvolva resiliência a nível de aplicativo para lidar com falhas transitórias decorrentes de manutenção planejada, failovers e eventos de mudança de função de DNS.

• Adicione lógica de repetição com retirada exponencial que contabiliza durações reais de failover e janelas de atualização DNS estendidas durante o failover geográfico.

• Prepare-se para degradação do desempenho do cache a frio após failovers de camada de Uso Geral, em que a instância é reiniciada em um novo nó sem réplicas quentes.

• Agende janelas de manutenção durante períodos de baixo tráfego. Espaçar janelas de manutenção entre pares de grupos de alta disponibilidade para evitar a manutenção simultânea nos dois membros.

Projete a estratégia de recuperação de desastre usando grupos de failover: Os grupos de failover replicam todos os bancos de dados de usuário como uma unidade para uma instância geográfica secundária em outra região, mas os bancos de dados do sistema não estão incluídos. Você deve sincronizar entradas, credenciais, trabalhos do SQL Agent e configurações de nível de instância independentemente para evitar falhas de autenticação e lacunas operacionais após o failover.

Use pontos de extremidade do ouvinte de grupo de failover em cadeias de conexão para evitar alterações durante o failover. Sincronize as políticas de retenção entre os membros porque as alterações de configuração não são replicadas. Para ambientes híbridos, o link da Instância Gerenciada oferece um caminho de replicação alternativo.

Estabelecer uma linha de base de segurança: Comece com a linha de base de segurança do Azure para SQL do Azure. Concentre-se nos controles que o modelo com escopo de instância afeta mais, incluindo funções personalizadas no nível do servidor para segmentação administrativa, delegação de sub-rede de rede virtual para isolamento de rede, gerenciamento de chaves TDE (Transparent Data Encryption) em nível de instância e auditoria de operador para acesso ao Suporte da Microsoft.

A Instância Gerenciada de SQL compartilha a base de segurança do SQL do Azure, mas apresenta controles específicos de instância, como assemblies CLR (Common Language Runtime), servidores vinculados e SQL Agent, que expandem a superfície de ataque além do que o Banco de Dados SQL expõe. Priorize esses controles em sua revisão de linha de base.

Aplique estratégias de segmentação usando controles de nível de rede e baseados em identidade: A Instância Gerenciada de SQL dá suporte à segmentação baseada em identidade por meio de funções no nível do servidor e no nível do banco de dados que impõem a separação de tarefas. As funções personalizadas no nível do servidor fornecem segmentação administrativa detalhada não disponível no Banco de Dados SQL. A separação do acesso ao plano de controle do acesso ao plano de dados mantém a gestão de instâncias separada das operações de dados.

A segmentação em nível de rede depende da implantação de instâncias em sub-redes delegadas dedicadas em que os NSGs (grupos de segurança de rede) controlam os fluxos de tráfego. Evite reutilização de tabelas de rotas e NSGs entre sub-redes que participam do emparelhamento de rede virtual com sub-redes da Instância Gerenciada de SQL.

Conjuntos de instâncias compartilham recursos subjacentes de VMs, o que afeta as garantias de isolamento entre usuários quando você consolida instâncias. Avalie se as cargas de trabalho que têm requisitos de segurança diferentes precisam de instâncias separadas.

Integre-se à ID do Microsoft Entra para gerenciamento de identidade e acesso: A Instância Gerenciada de SQL dá suporte à autenticação do Microsoft Entra por meio de vários métodos. Esse suporte centraliza o gerenciamento de identidades e dá suporte a políticas de acesso condicional. A Instância Gerenciada de SQL também dá suporte à autenticação do Windows por meio do Kerberos para identidades do Microsoft Entra, uma funcionalidade não disponível no Banco de Dados SQL. Você pode fazer lift-and-shift de aplicativos herdados sem alterações de código.

Planeje a arquitetura de identidade catalogando identidades administrativas, de operador e de carga de trabalho. Atribua funções de banco de dados usando princípios de privilégios mínimos. Use identidades gerenciadas atribuídas pelo usuário como a identidade de instância para a integração de serviços do Azure.

Implementar o isolamento de rede usando a Rede Virtual do Azure: A Instância Gerenciada de SQL é implantada em uma sub-rede de rede virtual dedicada, que fornece isolamento no nível da rede por padrão e forma as decisões de conectividade e segurança.

• Mantenha o ponto de extremidade público desativado porque ele cria outra superfície de ataque, e os grupos de failover e o vínculo de Instância Gerenciada dão suporte apenas à conectividade local da rede virtual.

• Delegar a sub-rede da instância gerenciada exclusivamente ao tipo de instância gerenciada e aplicar regras NSG auxiliadas pelo serviço para controle de tráfego.

• Atribua tabelas de rotas exclusivas e NSGs a cada sub-rede da Instância Gerenciada de SQL para emparelhamento de rede virtual. Reutilização de tabelas compartilhadas causa falhas de conectividade.

Configurar a criptografia de dados para proteção em repouso e em trânsito: A Instância Gerenciada de SQL fornece várias camadas de criptografia que abrangem dados em repouso, em trânsito e no nível do aplicativo. Cada camada requer decisões de configuração distintas.

Proteja as configurações de instância para reduzir a superfície de ataque: A Instância Gerenciada de SQL expõe recursos além do Banco de Dados SQL que expandem a superfície de ataque. Essas capacidades exigem decisões de endurecimento direcionadas junto com controles de governança.

• A política de atualização controla a cadência de patch de segurança. Você enfrenta um compromisso entre a implementação imediata e a compatibilidade de link de Instância Gerenciada.

• O SQL Agent, servidores vinculados, assemblies CLR e xp_cmdshell exigem avaliação de risco. Desativar recursos não utilizados e impor padrões TLS atuais.

• Use o RBAC (controle de acesso baseado em função) do Azure para restringir operações de gerenciamento, aplicar bloqueios de recursos e impor configurações de segurança por meio do Azure Policy.

Proteja as credenciais e as chaves de criptografia usando identidades gerenciadas e o Azure Key Vault: As identidades gerenciadas eliminam credenciais armazenadas para conectividade entre aplicativos e integrações entre serviços. As identidades gerenciadas atribuídas pelo usuário removem os segredos da cadeia de conexão e simplificam o gerenciamento de rotação.

O Key Vault fornece gerenciamento unificado de ciclo de vida para os protetores de TDE e as chaves mestras de coluna do Always Encrypted. O monitoramento de acesso à chave detecta padrões de uso incomuns que podem indicar comprometimento.

A Instância Gerenciada de SQL usa objetos de credencial para gravar logs de auditoria no armazenamento de blobs. Renove essas credenciais antes de expirarem para manter a continuidade da auditoria. Planeje procedimentos de entrega de credenciais para identidades que usam a autenticação SQL durante a migração.

Configurar o monitoramento de segurança e o log de auditoria: A auditoria da Instância Gerenciada de SQL dá suporte ao Armazenamento de Blobs do Azure, aos Hubs de Eventos do Azure e aos logs do Azure Monitor como destinos de auditoria. A auditoria de operador fornece visibilidade das operações de suporte da Microsoft na instância. A integridade do log de auditoria requer controles de evidência de violação para conformidade.

A integração do Log Analytics dá suporte à consulta avançada e à correlação de eventos de segurança, enquanto os Hubs de Eventos dão suporte à integração de SIEM (gerenciamento de eventos e informações de segurança externas). O Microsoft Defender para SQL adiciona proteção contra ameaças, incluindo alertas para injeção, força bruta e padrões de acesso incomuns.

Acompanhe eventos de autenticação, execução de consulta e alterações de privilégio por meio de especificações de auditoria para detectar tentativas de escalonamento e acesso não autorizado.

Crie e mantenha um modelo de custo que contabilize o modelo de cobrança de computação provisionado: A Instância Gerenciada de SQL usa um modelo de computação sempre provisionado em que os vCores cobram continuamente, independentemente da utilização. Seu modelo de custo deve considerar os drivers de custo primários, que incluem seleção da camada de serviço, contagem de vCore, geração de hardware e alocação de armazenamento com base no tamanho máximo configurado.

A cobrança no escopo da instância significa que todos os bancos de dados compartilham custos de computação, o que requer um mapeamento claro para o chargeback (reembolso de custos) e o showback (exibição de custos). Inclua opções de licenciamento e compromisso, como o Benefício Híbrido do Azure, a capacidade reservada e as réplicas em espera sem licença. Cada alavanca reduz o custo por meio de um mecanismo diferente.

Restrições de cota de vCore regionais podem forçar arquiteturas de multissubscrição, o que adiciona complexidade ao controle de custos e à governança.

Monitore e analise os custos para identificar oportunidades de otimização: No modelo sempre provisionado, a computação ociosa ainda incorre em encargos. Use o Gerenciamento de Custos da Microsoft para acompanhar os custos de computação, armazenamento, backup e licenciamento por instância. Compare o consumo real de armazenamento com o máximo reservado para identificar o desperdício de cobrança.

Monitore a utilização de recursos para identificar o excesso de provisionamento de vCore e validar se a camada de serviço atual permanece justificada. Crie alertas de orçamento, previsão e anomalias para detectar aumentos de custos inesperados por meio de alterações de escala ou configuração.

Otimize as configurações de computação e licenciamento para reduzir os custos de recursos provisionados: Os custos de computação são acumulados continuamente no modelo somente provisionado, portanto, ajuste a quantidade de vCore e otimize o licenciamento desde o início. Analise a utilização antes de selecionar a configuração. Use a camada de Uso Geral quando as cargas de trabalho tolerarem maior latência de armazenamento. A diferença de camada é o maior fator individual de custo.

Aplique o Benefício Híbrido do Azure para licenças existentes do SQL Server, comprometa-se com capacidade reservada para cargas de trabalho previsíveis e designe secundárias de grupos de failover como réplicas em espera livres de licenças quando servirem apenas para recuperação de desastre.

Otimize os custos de ambiente em instâncias de produção e não produção: Configurações de produção e não produção idênticas desperdiçam o orçamento em um modelo sempre provisionado. Diferencie perfis de custo de ambiente aplicando mecanismos de economia específicos da Instância Gerenciada de SQL a cada camada.

• Otimize ambientes de não produção ativando/desativando instâncias de Propósito Geral durante períodos ociosos previsíveis para eliminar os encargos de computação e licenciamento.

• Diferencie as configurações de ambiente implantando instâncias de não produção que usam contagens de vCore reduzidas e preços de assinatura de teste de desenvolvimento.

• Otimize os ambientes de recuperação de desastre avaliando a restauração geográfica como uma alternativa de menor custo aos grupos de failover para cargas de trabalho não críticas.

Consolide pequenas cargas de trabalho usando pools de instâncias para melhorar a eficiência dos recursos: Os pools de instância consolidam várias instâncias pequenas na computação compartilhada, o que reduz a sobrecarga por instância. Os pools dão suporte a configurações menores de vCore, exclusivas para implantações em pool, e são restritos à camada de Propósito Geral em gerações de hardware suportadas.

A computação do pool é cobrada no nível do pool, independentemente de quantas instâncias são executadas dentro dela, portanto, vCores não utilizados ainda incorrem em custos. As decisões de licenciamento e capacidade reservada se aplicam uniformemente em todas as instâncias do pool.

As instâncias em pool compartilham recursos de rede e disco local, que podem criar efeitos de vizinho barulhento. Cada instância recebe vCores e memória dedicados, mas cargas de trabalho que exigem isolamento mais forte devem ser implantadas como instâncias autônomas.

Implementar práticas de implantação seguras para alterações de configuração de instância: As operações de gerenciamento da Instância Gerenciada de SQL envolvem alterações de infraestrutura de cluster virtual que são executadas por muito mais tempo do que as operações típicas de banco de dados. Planeje suas práticas de implantação em torno dessas durações estendidas para minimizar a interrupção da carga de trabalho.

• Leve em conta a duração estendida das operações de criação, escalonamento e alteração de nível. Não agende-os durante o horário de pico. As operações na mesma sub-rede são serializadas.

• Planeje estratégias de reversão e implantação em etapas que validem as alterações de configuração em instâncias de não produção primeiro, porque as operações de dimensionamento em ambas as direções levam tempo comparável.

• Coordene as alterações de implantação do grupo de failover garantindo que as instâncias possuam políticas de atualização consistentes. Agende alterações em instâncias primárias e secundárias em horários diferentes.

Defina a infraestrutura como código para implantações de instância integrada à rede virtual: A Instância Gerenciada de SQL requer implantação integrada à rede virtual com delegação de sub-rede, regras de NSG e tabelas de rotas em vigor antes do provisionamento. Estruture seus modelos de IaC (infraestrutura como código) em camadas de dependência, para que a rede seja implementada primeiro, a identidade e o RBAC em segundo e os recursos de instância por último.

Configure a detecção de desvio de configuração para regras de sub-rede, tabelas de rotas e propriedades de instância. Use o Azure Policy para impor padrões de implantação, como marcas necessárias, camadas permitidas e requisitos de redundância de zona para instâncias de produção.

Projete e crie pipelines de build e implantação para alterações de instância e esquema de banco de dados: As alterações de infraestrutura de instância e as implantações de esquema de banco de dados operam em tempos fundamentalmente diferentes. Separe os estágios do pipeline adequadamente. Use sondagem baseada em status para estágios de infraestrutura e portões de aprovação antes de qualquer operação que dispare o trabalho de gerenciamento estendido.

As alterações de esquema exigem validação em relação às diferenças de compatibilidade T-SQL documentadas antes da implantação. Verifique a compatibilidade no pipeline e verifique as dependências de consulta entre bancos de dados e os recursos com escopo de instância na validação pós-implantação.

Estabeleça a observabilidade usando o Azure Monitor e o diagnóstico nativo de SQL: A observabilidade da Instância Gerenciada de SQL requer telemetria da plataforma do Azure Monitor e diagnósticos nativos de SQL, como DMVs (exibições de gerenciamento dinâmico), Repositório de Consultas e eventos estendidos. Combine essas camadas para uma exibição completa da integridade da instância e do desempenho da carga de trabalho.

Configure o monitoramento de plataforma por meio do Azure Monitor aplicando configurações de diagnóstico em toda a instância. Os eventos de operação de gerenciamento aparecem no log de atividades e os alertas do Resource Health fornecem um aviso antecipado de eventos planejados e não planejados. No lado do banco de dados, use o Repositório de Consultas como sua principal ferramenta para análise de carga de trabalho e otimização de índice. A Instância Gerenciada de SQL não dá suporte ao ajuste automatizado de índice.

Assine alertas do Resource Health e notificações de manutenção antecipadas para avisar sobre eventos planejados e não planejados.

Automatizar tarefas de gerenciamento, monitoramento e manutenção: A Instância Gerenciada de SQL inclui o SQL Agent, um agendador de trabalho interno que lida com a manutenção do banco de dados e tarefas operacionais sem orquestração externa. Combine o SQL Agent com a automação no nível do Azure para cobertura completa das operações do mecanismo de banco de dados e do plano de gerenciamento.

• Use SQL Agent para manutenção recorrente do banco de dados, sincronização de logins para secundários do grupo de failover e alertas sobre falhas de tarefas.

• Use a Automação do Azure ou o Azure Functions para operações que exigem interação do Azure Resource Manager, como monitorar operações de gerenciamento e gerenciar a retenção de backup.

• Automatize operações de ciclo de vida, como agendamentos de interrupção e início para instâncias qualificadas durante períodos ociosos e configuração de diagnóstico consistente ao provisionar novas instâncias.

Estabeleça práticas de teste e validação para implantações de banco de dados: A compatibilidade do SQL Server no SQL Managed Instance dá suporte a ferramentas de teste padrão, mas você ainda precisa validar operações de gerenciamento, dependências entre bancos de dados e recursos com escopo de instância. Use ambientes de teste reais da Instância Gerenciada de SQL porque o Banco de Dados SQL e o SQL Server têm diferentes comportamentos de operação de gerenciamento e infraestrutura.

Realizar o planejamento de capacidade: A Instância Gerenciada de SQL usa um modelo com escopo de instância em que todos os bancos de dados compartilham vCores, memória, operações de entrada/saída por segundo (IOPS) e armazenamento. O planejamento de capacidade em toda a propriedade de banco de dados é essencial porque o consumo de recursos de um banco de dados afeta diretamente todas as outras.

Identifique as metas de desempenho para o tempo de resposta, a largura de banda e as sessões simultâneas. Capture linhas de base de desempenho antes da migração e projete padrões de crescimento para a contagem de bancos de dados, armazenamento e volume de transações ao longo do ciclo de vida da instância. Considere as restrições de TempDB da camada específica ao planejar cargas de trabalho com uso intensivo de TempDB.

As operações de gerenciamento para dimensionamento levam horas em vez dos minutos típicos de outras ofertas de SQL do Azure. Planeje a capacidade com buffer suficiente para evitar necessidades urgentes de dimensionamento e coordene operações com janelas de manutenção para minimizar a interrupção dos negócios.

Selecione a geração de hardware e a camada de serviço para requisitos de carga de trabalho: A geração de hardware e a seleção da camada de serviço determinam a taxa de memória, as características de E/S e o perfil de latência disponíveis para sua carga de trabalho.

Escolha a estratégia de dimensionamento correta para sua carga de trabalho: A Instância Gerenciada de SQL dá suporte apenas ao dimensionamento vertical. O serviço não oferece dimensionamento automático, computação sem servidor ou uma camada de Hiperescala.

• Planeje o dimensionamento vertical em torno de janelas de operação de várias horas para alterações de camada, alterações de geração de hardware e ajustes de vCore. Agende essas operações durante os períodos de manutenção planejados.

• Descarregue cargas de trabalho de leitura para a réplica secundária interna legível no Nível de Importância Comercial. Essa réplica atende a consultas somente leitura sem custo adicional para cargas de trabalho, como relatórios, análises e leituras eventualmente consistentes.

• Use memória flexível na Próxima Geração de Uso Geral para ajustar a alocação de memória independentemente da contagem de vCore. As alterações acionam um failover de instância na etapa final.

Execute testes de desempenho para validar o comportamento da carga de trabalho do banco de dados: Projete testes de desempenho que validem o comportamento simultâneo multidatabase no modelo com escopo de instância. Inclua combinações de transações realistas que combinam cargas de trabalho transacionais, em lote e de relatório que são executadas simultaneamente. Teste com a quantidade real de bancos de dados e os volumes de dados previstos para a instância.

Capture linhas de base de pré-implantação e compare o comportamento pós-migração entre diferentes gerações de hardware e camadas de serviço para confirmar se a configuração selecionada atende aos seus requisitos. Medir o tempo de recuperação da carga de trabalho após failovers e operações de gerenciamento, especialmente em camadas que usam o armazenamento remoto em que o pool de buffers deve ser recriado.

Identificar e monitorar indicadores de desempenho: Monitore nos níveis de instância e de banco de dados para identificar a contenção de recursos porque todos os bancos de dados compartilham recursos de computação no modelo com escopo de instância.

• Configure o monitoramento no nível da instância para acompanhar as métricas principais e definir alertas nos limites de utilização antes que as cargas de trabalho sejam afetadas. Inclua a taxa de transferência de gravação de log em relação aos limites por camada.

• Use o Repositório de Consultas como sua ferramenta principal para identificar consultas regredidas e planejar alterações. Combine-a com a análise manual de índice porque a Instância Gerenciada de SQL não dá suporte ao ajuste automático de índice.

• Adicione o monitoramento de recursos no nível do banco de dados para controlar o consumo por banco de dados e detectar a contenção de recursos compartilhados, como o TempDB e o armazenamento na memória.

Otimizar o desempenho da consulta e do design da carga de trabalho: A Instância Gerenciada de SQL inclui recursos do Enterprise Edition que abordam desafios de desempenho específicos ao modelo com escopo de instância, como governança de recursos em bancos de dados, consultas entre bancos de dados, transações distribuídas e processamento na memória.

Considere as restrições de recursos específicas do serviço em sua estratégia de otimização. Alocação corrigida de TempDB, limites de governança da taxa de log na capacidade de gravação e modelos de IOPS dependentes de camada representam tanto restrições quanto oportunidades de otimização.