Boas práticas de arquitetura para Azure SQL Managed Instance

Analisar quotas, limites e problemas conhecidos do SQL Managed Instance: SQL Managed Instance impõe limites regionais de implementação, contagem de bases de dados e limites de armazenamento, variando conforme o tipo de subscrição e a camada. Implementações de níveis superiores consomem mais quota vCore, o que limita o planeamento regional da capacidade.

• Considere problemas conhecidos que afetam grupos de failover, comportamento de backup durante o uso do link de replicação e restrições de migração de versões mais antigas do SQL Server. Reveja estas limitações durante o desenho inicial para evitar restrições que não consiga corrigir facilmente mais tarde.

Antecipe possíveis falhas: Utilize a análise de modos de falha para antecipar falhas e planear mitigações para a Instância Gerida de SQL.

Construir redundância através da distribuição de zonas e seleção apropriada de níveis: Use redundância de zonas e seleção de níveis adequada para eliminar pontos únicos de falha dentro de uma região.

• Active a redundância a nível de zona para distribuir réplicas entre zonas de disponibilidade. A arquitetura e a elegibilidade variam consoante o nível e a configuração de implementação.

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

Planear a escalabilidade com base nos tempos de execução das operações de gestão: As operações de gestão demoram horas em vez de minutos, o que requer uma abordagem diferente para a estratégia de escalabilidade e para o planeamento da capacidade.

• Prepare-se para prazos mais longos para a criação da primeira instância na sub-rede, o que leva muito mais tempo devido ao provisionamento de clusters virtuais. As operações concorrentes colocam-se sequencialmente na fila dentro de uma sub-rede.

• Dimensione subredes considerando a capacidade de expansão futura. Sub-redes subdimensionadas limitam o crescimento, e gerações mistas de hardware criam clusters virtuais separados que consomem endereços IP extra.

• Preprovisiona instâncias de espera quando precisas de tempos de resposta de escalabilidade rigorosos. Isolar cargas de trabalho de produção em sub-redes dedicadas para evitar o bloqueio de operações entre instâncias.

Configure monitorização e alertas, por exemplo, para o estado de saúde e replicação: Dê prioridade aos alertas nas métricas que sinalizam riscos de fiabilidade desde cedo. Acompanhe a disponibilidade das instâncias através de eventos de Saúde de Recursos, monitorize as transições de estado das operações de gestão através de um registo de atividade e verifique regularmente a conclusão automática de backups, pois falhas de backup podem surgir silenciosamente quando surgem preenchidos de armazenamento ou problemas no Sistema de Nomes de Domínio (DNS). Para instâncias configuradas com grupos de failover, emita um alerta sobre o atraso de replicação em relação aos limites de RPO para detetar uma deriva de geo-replicação antes que cause uma exposição inaceitável de perda de dados.

As transições de estado do grupo de failover revelam perturbações antes de escalarem para lacunas no processo de recuperação.

Implementar técnicas de resiliência de conexão e autopreservação: Construir resiliência ao nível da aplicação para absorver falhas transitórias de manutenção planeada, falhas e eventos de intercâmbio de funções DNS.

• Adicione lógica de novas tentativas com backoff exponencial que leve em consideração a duração real dos failovers e as janelas prolongadas de atualização do DNS durante o failover geográfico.

• Prepare-se para a degradação do desempenho do cold cache após failovers de nível de Uso Geral, onde a instância reinicia num novo nó sem réplicas quentes.

• Programe janelas de manutenção durante períodos de baixo tráfego. Espaçar janelas entre pares de grupos de failover para evitar manutenção simultânea em ambos os membros.

Desenhe a estratégia de recuperação de desastres utilizando grupos de failover: Os grupos de failover replicam todas as bases de dados de utilizadores como uma unidade para uma instância geo-secundária noutra região, mas as bases de dados do sistema não estão incluídas. Deve sincronizar os inícios de sessão, credenciais, trabalhos do SQL Agent e definições ao nível da instância de forma independente para evitar falhas de autenticação e lacunas operacionais após a ocorrência de um failover.

** Utilize endpoints de ouvintes de grupos de failover em strings de ligação para evitar alterações durante o failover. Sincroniza as políticas de retenção entre membros porque as alterações de configuração não se replicam. Para ambientes híbridos, a ligação de Instância Gerida oferece um caminho alternativo de replicação.

Estabeleça uma linha de base de segurança: Comece com a linha base de segurança do Azure para Azure SQL. Foque-se nos controlos que o modelo com escopo de instância mais afeta, incluindo funções personalizadas ao nível do servidor para segmentação administrativa, delegação de subredes virtuais de rede para isolamento de rede, gestão de chaves Transparent Data Encryption (TDE) ao nível da instância e auditoria de operadores para acesso ao Suporte Microsoft.

O SQL Managed Instance partilha a base de segurança do Azure SQL, mas introduz controlos específicos da instância, como assemblies Common Language Runtime (CLR), servidores ligados e SQL Agent, que expandem a superfície de ataque para além do que a SQL Database expõe. Priorize estes controlos na sua revisão de base.

Aplicar estratégias de segmentação utilizando controlos baseados em identidade e ao nível da rede: A Instância Gerida SQL suporta segmentação baseada em identidade através de funções ao nível do servidor e da base de dados que impõem a separação de tarefas. Funções personalizadas ao nível do servidor fornecem segmentação administrativa detalhada que não está disponível na base de dados SQL. Separar o acesso ao plano de controlo do acesso ao plano de dados mantém a gestão das instâncias distinta das operações de dados.

A segmentação ao nível da rede baseia-se na implantação de instâncias em sub-redes dedicadas e delegadas, onde os grupos de segurança de rede (NSGs) controlam os fluxos de tráfego. Evite reutilizar tabelas de roteamento e NSGs entre sub-redes que participam no peering de rede virtual com sub-redes SQL Managed Instance.

Os agrupamentos de instâncias partilham recursos subjacentes de VM, o que afeta as garantias de isolamento entre locatários quando se consolidam as instâncias. Avalie se cargas de trabalho com requisitos de segurança diferentes precisam de instâncias separadas.

Integre com o Microsoft Entra ID para gestão de identidade e acesso: A Instância Gerida SQL suporta a autenticação Microsoft Entra através de diferentes métodos. Este suporte centraliza a gestão de identidades e apoia políticas de acesso condicional. A Instância Gerida SQL também suporta autenticação Windows através do Kerberos para os principais Microsoft Entra, uma funcionalidade não disponível na base de dados SQL. Pode fazer lift-and-shift de aplicações legadas sem alterações de código.

Planeie a arquitetura de identidade catalogando as identidades administrativas, operadoras e de carga de trabalho. Atribuir funções da base de dados usando princípios de privilégio mínimo. Use identidades geridas atribuídas pelo utilizador como identidade de instância para integração de serviços Azure.

Implemente isolamento de rede utilizando a Azure Virtual Network: A Instância Gerida SQL é implementada numa sub-rede virtual dedicada, que proporciona isolamento ao nível da rede por defeito e molda as decisões de conectividade e segurança.

• Mantenha o endpoint público desativado, pois isso cria uma outra superfície de ataque, e os grupos de failover e a ligação da Instância Gerida suportam apenas conectividade de rede virtual local.

• Delegue a sub-rede da instância gerida exclusivamente ao tipo de instância gerida e aplique regras NSG assistidas por serviços para controlo de tráfego.

• Atribua tabelas de rotas únicas e NSGs a cada sub-rede de Instância Gerida de SQL para peering de rede virtual. Reutilizar tabelas partilhadas causa falhas de conectividade.

Configure a encriptação dos dados para proteção em repouso e em trânsito: A Instância Gerida SQL fornece múltiplas camadas de encriptação que cobrem dados em repouso, em trânsito e ao nível da aplicação. Cada camada exige decisões de configuração distintas.

Endureça configurações de instâncias para reduzir a superfície de ataque: A Instância Gerida do SQL expõe capacidades para além da Base de Dados do SQL que expandem a superfície de ataque. Estas capacidades exigem decisões de reforço direcionadas juntamente com controlos de governação.

• A política de atualização controla a cadência dos patches de segurança. Enfrenta um dilema entre a aplicação imediata e a compatibilidade do link da Instância Gerida.

• SQL Agent, servidores ligados, assemblies CLR e xp_cmdshell exigem avaliação de risco. Desative as capacidades não utilizadas e faça cumprir os padrões TLS atuais.

• Use o controlo de acesso baseado em funções do Azure (Azure RBAC) para restringir operações de gestão, aplicar bloqueios de recursos e impor configurações de segurança através do Azure Policy.

Proteja credenciais e chaves de encriptação usando identidades geridas e Azure Key Vault: As identidades geridas eliminam credenciais armazenadas para conectividade aplicação-instância e integrações entre serviços. As identidades geridas atribuídas pelo utilizador removem os segredos das cadeias de ligação e simplificam a gestão da rotação.

O Key Vault fornece gestão unificada do ciclo de vida para protetores TDE e chaves mestras de coluna Always Encrypted. A monitorização de acesso a chaves deteta padrões de utilização invulgares que podem indicar uma violação.

O SQL Managed Instance utiliza objetos de credenciais para escrever registos de auditoria em armazenamento de blobs. Renove estas credenciais antes de expirarem para manter a continuidade da auditoria. Planeie procedimentos de transferência de credenciais para identidades que utilizam autenticação SQL durante a migração.

Configurar monitorização de segurança e registo de auditorias: A auditoria SQL Managed Instance suporta Azure Blob Storage, Azure Event Hubs e registos Azure Monitor como alvos de auditoria. A auditoria do operador proporciona visibilidade sobre as operações de Suporte Microsoft na instância. A integridade dos registos de auditoria exige controlos de evidência de adulteração para a conformidade.

A integração com Log Analytics suporta consulta avançada e correlação de eventos de segurança, enquanto os Event Hubs suportam a integração externa de informação de segurança e gestão de eventos (SIEM). O Microsoft Defender para SQL adiciona proteção contra ameaças, incluindo alertas para injeção, força bruta e padrões de acesso invulgares.

Acompanhar eventos de autenticação, execução de consultas e alterações de privilégios através de especificações de auditoria para detetar tentativas de escalonamento e acessos não autorizados.

Crie e mantenha um modelo de custos que tenha em conta o modelo de faturação computacional provisionada: SQL Managed Instance utiliza um modelo de computação sempre provisionado, onde os vCores faturam continuamente independentemente da utilização. O seu modelo de custo deve ter em conta os principais fatores de custo, que incluem seleção de níveis de serviço, contagem de vCores, geração de hardware e alocação de armazenamento com base no tamanho máximo configurado.

Faturação ao nível da instância significa que todas as bases de dados partilham os custos de computação, o que requer um mapeamento claro para chargeback e showback. Inclui mecanismos de licenciamento e compromisso como Azure Hybrid Benefit, capacidade reservada e réplicas em espera sem necessidade de licença adicional. Cada alavanca reduz custos através de um mecanismo diferente.

As restrições regionais de quotas vCore podem forçar arquiteturas multisubscrição, o que acrescenta complexidade ao acompanhamento de custos e à governação.

Monitorizar e analisar custos para identificar oportunidades de otimização: No modelo sempre provisionado, a computação ociosa ainda incorre em custos. Use o Microsoft Cost Management 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 faturação.

Monitorize a utilização de recursos para identificar o sobreprovisionamento do vCore e validar se o nível de serviço atual permanece justificado. Crie alertas de orçamento, previsão e anomalias para detetar aumentos inesperados de custos devido a alterações de escalabilidade ou configuração.

Otimize as configurações de computação e licenciamento para reduzir os custos de recursos provisionados: Os custos de computação acumulam-se continuamente no modelo apenas provisionado, por isso, ajuste corretamente o número de vCores e otimize o licenciamento desde o início. Analise a utilização antes de selecionar a configuração. Use o nível de Uso Geral quando as cargas de trabalho tolerarem maior latência de armazenamento. A diferença de escalão é a maior alavanca de custo.

Aplicar o Benefício Híbrido do Azure para licenças SQL Server existentes, comprometer-se com capacidade reservada para cargas de trabalho previsíveis e designar os secundários do grupo de failover como réplicas standby sem licença quando servem apenas para recuperação de desastres.

Otimize os custos ambientais em instâncias de produção e não produtivas: Configurações idênticas de produção e não produção desperdiçam o orçamento num modelo sempre provisionado. Diferencie os perfis de custos do ambiente aplicando mecanismos de poupança específicos de SQL Managed Instance a cada nível.

• Otimize ambientes não produtivos utilizando stop/start em instâncias de uso geral durante períodos de inatividade previsíveis para eliminar custos de computação e licenciamento.

• Diferencie configurações de ambiente implementando instâncias não produtivas que utilizem contagem reduzida de vCore e preços de subscrição para testes de desenvolvimento.

• Otimize os ambientes de recuperação de desastres 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 utilizando pools de instâncias para melhorar a eficiência dos recursos: Os pools de instâncias consolidam múltiplas pequenas instâncias em computação partilhada, o que reduz a sobrecarga por instância. Os pools suportam configurações vCore mais pequenas, exclusivas de implementações em pool, e estão restritos ao nível de Uso Geral nas gerações de hardware suportadas.

A computação do pool é cobrada ao nível do pool independentemente do número de instâncias que sejam executadas nele, portanto, vCores não utilizados continuam a gerar custos. As decisões sobre licenciamento e capacidade reservada aplicam-se uniformemente em todas as instâncias do pool.

As instâncias agrupadas partilham recursos locais de disco e rede, o que pode criar efeitos de vizinho ruidoso. Cada instância recebe vCores dedicados e memória, mas cargas de trabalho que exijam isolamento mais forte devem ser implementadas como instâncias autónomas.

Implementar práticas seguras de implementação para alterações de configuração das instâncias: As operações de gestão de instâncias geridas em SQL envolvem alterações de infraestrutura de clusters virtuais que duram muito mais tempo do que as operações típicas de base de dados. Planeie as suas práticas de implantação tendo em conta estes períodos prolongados para minimizar a perturbação da carga de trabalho.

• Tenha em conta a duração prolongada das operações de criação, escalabilidade e alteração de níveis. Não os agendes durante as horas de ponta. As operações dentro da mesma sub-rede são serializadas.

• Planeie estratégias de rollback e implementação em fases que validem as alterações de configuração em instâncias não produtivas primeiro, porque as operações de escalabilidade em ambas as direções demoram tempo comparável.

• Coordenar as alterações na implementação do grupo de failover garantindo que as instâncias tenham políticas de atualização que correspondam. Alterações de calendário para instâncias primárias e secundárias em diferentes momentos.

Defina infraestrutura como código para implantações de instâncias integradas em rede virtual: A Instância Gerida SQL requer uma implementação integrada em rede virtual, com delegação de sub-rede, regras NSG e tabelas de roteamento definidas antes do provisionamento. Estruture a sua infraestrutura como modelos de código (IaC) em camadas de dependência, de modo que a rede seja implementada primeiro, seguidos pela identidade e RBAC, e os recursos da instância por último.

Configura a deteção de desvio de configuração para regras de sub-rede, tabelas de rotas e propriedades de instância. Use a Política Azure para impor padrões de implementação como etiquetas obrigatórias, níveis permitidos e requisitos de redundância de zonas para instâncias de produção.

Pipelines de design, construção e implementação para alterações de esquemas e instâncias de base de dados: As alterações na infraestrutura das instâncias e as implementações de esquemas de base de dados operam em escalas temporais fundamentalmente diferentes. Separa as fases do pipeline de forma adequada. Utilize sondagens baseadas no estado para as fases da infraestrutura e portas de aprovação antes de qualquer operação que desencadeie trabalho prolongado de gestão.

As alterações de esquema requerem validação face a diferenças documentadas de compatibilidade T-SQL antes da implementação. Verifique a compatibilidade no pipeline e verifique as dependências de consultas entre bases de dados e as funcionalidades de âmbito de instância na validação pós-implementação.

Estabeleça observabilidade utilizando o Azure Monitor e diagnósticos nativos SQL: A observabilidade da Instância Gerida SQL requer tanto telemetria da plataforma Azure Monitor como diagnósticos nativos SQL, como vistas de gestão dinâmica (DMVs), Query Store e eventos estendidos. Combine estas camadas para obter uma visão completa da saúde da instância e do desempenho da carga de trabalho.

Configura a monitorização da plataforma através do Azure Monitor aplicando definições de diagnóstico em toda a instância. Os eventos das operações de gestão aparecem no registo de atividades, e os alertas de Saúde de Recursos fornecem avisos precoces tanto de eventos planeados como não planeados. No lado da base de dados, use o Query Store como ferramenta principal para análise de carga de trabalho e otimização de índices. O SQL Managed Instance não suporta afinação automática de índices.

Subscreva alertas de Saúde de Recursos e notificações antecipadas de manutenção para avisos precoces de eventos planeados e não planeados.

Automatizar tarefas de gestão, monitorização e manutenção: A Instância Gerida SQL inclui o SQL Agent, um agendador de tarefas incorporado que gere a manutenção da base de dados e tarefas operacionais sem orquestração externa. Combine o SQL Agent com automação ao nível Azure para uma cobertura total tanto das operações do motor de base de dados como do plano de gestão.

• Use o SQL Agent para manutenção recorrente da base de dados, sincronização de login com grupos secundários de failover e alertas sobre falhas de trabalho.

• Use Azure Automation ou Azure Functions para operações que requerem interação com o Azure Resource Manager, como monitorizar operações de gestão e gerir a retenção de backups.

• Automatize operações de ciclo de vida, como interrupções e reinícios agendados para instâncias elegíveis durante períodos de inatividade e configuração de diagnóstico consistente ao provisionar novas instâncias.

Estabelecer práticas de teste e validação para implementações de bases de dados: A compatibilidade do SQL Managed Instance com o SQL Server suporta ferramentas de teste padrão, mas ainda é necessário validar as operações de gestão, as dependências entre bases de dados e as funcionalidades no âmbito da instância. Use ambientes de teste de Instâncias Geridas SQL reais porque a base de dados SQL e o SQL Server têm comportamentos diferentes de infraestrutura e operações de gestão.

Planeamento da capacidade de condução: A Instância Gerida SQL utiliza um modelo com âmbito de instância onde todas as bases de dados partilham vCores, memória, operações de entrada/saída por segundo (IOPS) e armazenamento. O planeamento da capacidade em todo o património da base de dados é essencial porque o consumo de recursos de uma base de dados afeta diretamente todas as outras.

Identificar metas de desempenho para tempo de resposta, taxa de transferência e sessões simultâneas. Capturar as linhas de base de desempenho antes da migração e os padrões de crescimento do projeto para o número de bases de dados, armazenamento e volumes de transações ao longo do ciclo de vida da instância. Tenha em conta as restrições específicas do TempDB por nível quando planeia cargas de trabalho intensivas em TempDB.

As operações de gestão para escalabilidade demoram horas, em vez dos minutos típicos de outras ofertas Azure SQL. Planeie a capacidade com margem suficiente para evitar necessidades urgentes de escalabilidade e coordene as operações com janelas de manutenção para minimizar a interrupção do negócio.

Selecione a geração de hardware e o nível de serviço conforme os requisitos de carga de trabalho: A geração de hardware e a seleção do nível de serviço determinam a razão de memória, as características de I/O e o perfil de latência disponíveis para a sua carga de trabalho.

Escolha a estratégia de escalabilidade certa para a sua carga de trabalho: A Instância Gerida SQL suporta apenas escalabilidade vertical. O serviço não oferece escalabilidade automática, computação sem servidor ou uma camada Hyperscale.

• Planeie o escalonamento vertical em janelas de operação com duração de várias horas para alterações de níveis, alterações de geração de hardware e ajustes de vCore. Programe estas operações durante os períodos de manutenção planeados.

• Descarregue as cargas de trabalho de leitura para a réplica secundária legível integrada na camada Business Critical. Esta réplica serve consultas apenas de leitura sem custo adicional para cargas de trabalho como relatórios, análises e, eventualmente, leituras consistentes.

• Utilize memória flexível na Next-gen General Purpose para ajustar a alocação de memória independentemente da contagem de vCores. As alterações desencadeiam um failover de instância como passo final.

Execute testes de desempenho para validar o comportamento da carga de trabalho da base de dados: Desenhe testes de desempenho que validem o comportamento concurrente de múltiplas bases de dados no modelo com âmbito de instância. Inclua combinações realistas de transações que combinem cargas de trabalho transacionais, em lote e de relatórios que corram simultaneamente. Efetue um teste com a contagem real de registos na base de dados e os volumes de dados planeados para a instância.

Capture as linhas de base pré-implementação e compare o comportamento pós-migração entre diferentes gerações de hardware e níveis de serviço para confirmar que a configuração selecionada cumpre os seus requisitos. Meça o tempo de recuperação da carga de trabalho após failovers e operações de gestão, especialmente em níveis que utilizam armazenamento remoto onde o pool de buffers tem de ser reconstruído.

Identificar e monitorizar indicadores de desempenho: Monitorizar tanto ao nível de instância como de base de dados para identificar contenção de recursos, pois todas as bases de dados partilham recursos computacionais no modelo de âmbito de instância.

• Configure monitorização ao nível da instância para acompanhar métricas principais e defina alertas sobre os limiares de utilização antes de as cargas de trabalho serem afetadas. Incluir o throughput de escrita de logs em relação aos limites de cada nível.

• Use a Loja de Consultas como ferramenta principal para identificar consultas regressadas e planear alterações. Combine-o com análise manual de índices porque o SQL Managed Instance não suporta afinação automática de índices.

• Adicionar monitorização de recursos ao nível da base de dados para acompanhar o consumo por base de dados e detetar contendas entre recursos partilhados como TempDB e armazenamento em memória.

Otimize o design da carga de trabalho e o desempenho das consultas: A Instância Gerida SQL inclui capacidades da Edição Empresarial que abordam desafios de desempenho específicos do modelo de âmbito de instância, como governação de recursos em bases de dados, consultas entre bases de dados, transações distribuídas e processamento em memória.

Tenha em conta as restrições específicas de recursos do serviço na sua estratégia de otimização. A alocação fixa do TempDB, as limitações de governação da taxa de escrita no log e os modelos de IOPS dependentes de camadas apresentam restrições e oportunidades de otimização.