Implante o SQL Server no Azure Local com operações desconectadas

Aplica-se a:SQL Server

Este artigo descreve como planejar, implantar, proteger e operar o SQL Server no Windows Server ou em máquinas virtuais Linux (VMs) suportadas no Azure Local com operações desconectadas.

Antes de começar:

  • Obtenha a aprovação da sua organização.
  • Adquira a plataforma de operações desconectadas.
  • Implante a plataforma dentro dos limites de segurança da sua organização.

Cargas de trabalho do SQL Server, o plano de controle local, dados de gerenciamento, integração de identidade e governança permanecem on-local. O ambiente não exige conectividade contínua com o Azure ou a internet. Use fluxos de trabalho aprovados de transferência em etapas ou offline para atualizações, pacotes de suporte, dados de registro e outros artefatos necessários.

Para implantações que mantêm conectividade ao Azure, veja Deploy SQL Server no Azure Local.

Quando usar operações desconectadas

Considere operações em modo desconectado para:

  • Ambientes soberanos, regulados ou isolados onde a conectividade em nuvem pública é proibida ou não confiável.
  • Locais que exigem execução local, administração local e controle sobre dados e telemetria operacional.
  • Cargas de trabalho do SQL Server que precisam de virtualização e armazenamento Azure Local sem dependência do plano de controle público do Azure.

Você pode rodar cargas de trabalho transacionais, analíticas, de inteligência de negócios e data warehouse localmente. Integre as VMs do SQL Server com seus sistemas aprovados de identidade local, monitoramento, backup, segurança, patches e distribuição de software.

Important

A extensão SQL Server para Azure Arc não é suportada com operações desconectadas. Os recursos de inventário do SQL Server no Azure Arc, de avaliação de melhores práticas e de gerenciamento do SQL Server baseados no Azure não estão disponíveis por meio desta extensão. Use ferramentas locais suportadas para gerenciar e monitorar o SQL Server em cada VM.

Pré-requisitos

Antes de implantar o SQL Server, confirme que você tem:

  • Esses pré-requisitos não exigem conectividade contínua com o Azure ou a internet.
  • Um ambiente de operações desconectado Azure Local aprovado, implantado em hardware suportado dentro do limite de segurança da sua organização. Revise os serviços suportados e conclua a implantação da plataforma antes de continuar.
  • Suportava imagens para Windows Server ou Linux e capacidade suficiente de computação e armazenamento para criar VMs de carga de trabalho.
  • Rede local, identidade, certificados e sincronização de tempo que atendam aos requisitos de rede e identidade da plataforma.
  • Licenças SQL Server apropriadas e licenciamento separado da plataforma de operações desconectadas do Azure Local. Revise os limites de licenciamento e suporte e a cobrança de operações desconectadas.
  • Mídia de instalação do SQL Server aprovada, atualizações cumulativas, drivers, ferramentas de gerenciamento e pacotes de pré-requisitos, com um processo offline controlado para transferir e verificar esses artefatos.
  • Monitoramento local e alvos de backup protegidos para cargas de trabalho do SQL Server, separados dos backups no plano de controle.
  • Um processo de serviço offline aprovado para atualizações do SQL Server e do sistema operacional convidado.

Planeje a carga de trabalho do SQL Server

Antes de dimensionar as VMs, capture os requisitos da carga de trabalho:

  • Selecione a versão e edição do SQL Server com base no tamanho do banco de dados, recursos de disponibilidade, operações online, direitos de virtualização e ciclo de vida do suporte.
  • Registre o pico de utilização da CPU, memória do conjunto de trabalho, operações de entrada/saída por segundo (IOPS), throughput, latência, crescimento do banco de dados, tempdb demanda, taxa de geração de logs e concorrência.
  • Defina objetivos de pontos de recuperação (RPOs) e objetivos de tempo de recuperação (RTOs).
  • Identifique dependências de aplicações, métodos de autenticação, requisitos de Segurança da Camada de Transporte (TLS), portas, contas de serviço, janelas de manutenção, retenção de backup e dependências de software offline.

Crie as VMs do SQL Server

Use as seguintes orientações para projetar suas VMs do SQL Server:

Área de design Orientação do SQL Server
Computação Dimensione CPUs virtuais para utilização sustentada e eficiência de licenciamento. Evite a superalocação, pois isso cria latência imprevisível nas consultas.
Memory Reserve memória para o sistema operacional, agentes, drivers e atividade de failover. Configure max server memory para que o SQL Server não consuma a memória necessária por outros processos.
Armazenamento Use volumes separados para o sistema operacional, os dados, os logs de transações, tempdb e os backups. Valide latência, taxa de transferência, profundidade da fila, capacidade, resiliência e limiares de espaço livre.
Network Forneça rotas estáveis de cliente, gerenciamento, backup e réplica, conforme necessário. Valide DNS, unidade máxima de transmissão (MTU), regras de firewall, confiança TLS e conectividade do ouvinte.
Colocação Coloque réplicas de alta disponibilidade em diferentes nós Azure Local ou domínios de falha. Use antiafinidade quando disponível.

Instalar e configurar o SQL Server

  1. Crie VMs suportadas para Windows Server ou Linux seguindo as orientações da VM de operações desconectadas.
  2. Transfira mídias de instalação aprovadas, atualizações cumulativas, drivers, ferramentas de gerenciamento e pacotes pré-requisitos através do seu processo offline controlado.
  3. Instale o SQL Server usando as instruções para Windows ou Linux. Instale apenas os recursos que você precisar. Use arquivos de configuração repetíveis ou automação, proteja chaves de produto e credenciais, e documente a linha base da build.
  4. Aplique a atualização cumulativa aprovada. Configure contas de serviço, autenticação, certificados TLS, regras de firewall, ordenação, max server memory, tempdb, crescimento de arquivos de banco de dados e compressão de backups.
  5. Valide latência de armazenamento, pressão de CPU e memória, conectividade, integridade do banco de dados, backups, operações de restauração e comportamento da aplicação antes do uso em produção.

Configurar alta disponibilidade e recuperação de desastre

Projetar a disponibilidade e recuperação para a carga de trabalho do SQL Server separadamente do plano de controle Azure Local.

Opções de disponibilidade do SQL Server

  • Grupos de disponibilidade Always On: Use VMs separadas do SQL Server e coloque réplicas entre domínios de falha físicos. Para implantações no Windows, configure o Cluster de Failover do Windows Server, um witness local e o quórum, os listeners e o comportamento de repetição de tentativas do aplicativo sem depender do Azure Cloud Witness. Veja a visão geral dos grupos de disponibilidade e orientações para começar.
  • Instâncias de cluster de failover no Windows: Use armazenamento compartilhado suportado e uma configuração de SQL Server em cluster suportada quando precisar de proteção em nível de instância. Veja Instâncias de cluster de failover Always On e instalação do cluster de failover do SQL Server.
  • Resiliência do host: Use alocação com reconhecimento de cluster e anti-afinidade para que as réplicas do SQL Server não compartilhem o mesmo nó físico ou domínio de falha.

Para os requisitos de clustering do Windows, consulte Windows Server Failover Clustering with SQL Server.

Para Linux, um grupo de disponibilidade sem gerenciador de cluster fornece réplicas em escala de leitura, não alta disponibilidade. Implantações de alta disponibilidade exigem um gerenciador de cluster suportado, como o Pacemaker, e implantações em produção exigem cerca. Veja Configurar grupos de disponibilidade no Linux. Confirme se sua distribuição Linux, gerenciador de cluster, mecanismo de cercas e configuração de armazenamento são suportados no seu ambiente Azure Local desconectado antes de implantar. Os procedimentos do Windows linkados aqui não estabelecem suporte para uma topologia Linux.

Projeto de recuperação

Defina objetivos de recuperação para cada banco de dados. Mantenha backups do SQL Server consistentes com a aplicação separados dos backups no plano de controle. Replicar ou exportar backups para uma zona ou local de segurança secundário aprovado, proteger as chaves de criptografia de forma independente e executar testes de restauração programados.

Para mais informações, veja a visão geral de restauração e recuperação do SQL Server.

SQL Server seguro

Aplique uma linha de base de segurança do SQL Server que funcione sem serviços de nuvem pública:

  • No Windows, use domínio de menor privilégio ou contas de serviço gerenciado quando for suportado. Use a configuração de identidade de serviço suportada pelo seu sistema operacional e reschine permissões para backup, monitoramento e identidades de aplicações.
  • Prefiro autenticação integrada quando for suportado. No Linux, a autenticação do Active Directory usa Kerberos e requer configuração específica do nome principal de serviço (SPN) e keytab específica do SQL Server. A integração de identidade de plataforma não configura a autenticação do SQL Server. Restringa sysadmin a membresia, remova logins e recursos não utilizados, desative protocolos fracos e revise permissões regularmente.
  • Exigir TLS para conexões de clientes. Para o tráfego de réplica de grupo de disponibilidade, configure a autenticação e a criptografia nos endpoints de espelhamento do banco de dados. Gerencie certificados por meio da infraestrutura de chave pública (PKI) local e monitore a saúde da expiração e da cadeia de confiança.
  • Proteja os dados com criptografia de dados transparente (TDE) ou criptografia de volume, conforme apropriado. Criptografe backups, armazene chaves separadamente e teste a recuperação de chaves.
  • Ative o SQL Server Audit ou controles equivalentes para atividade privilegiada, falhas de login, alterações de permissões, acesso a objetos sensíveis e alterações de configuração.

Considerações de segurança desconectadas

  • Mantenha um repositório offline aprovado para atualizações do SQL Server, drivers, ferramentas, definições de segurança e dependências. Verifique assinaturas e escaneie artefatos importados.
  • Para chamadas REST externas, permita apenas endpoints HTTPS locais aprovados. Use credenciais com escopo no banco de dados, restrinja EXECUTE ANY EXTERNAL ENDPOINT e audite as solicitações. Analise as permissões e os requisitos do endpoint para sp_invoke_external_rest_endpoint.
  • Documente acesso de emergência, rotação de credenciais, renovação de certificados, sanitização de pacotes de suporte e procedimentos de recuperação que não dependam de serviços de nuvem pública.

Monitorar SQL Server

Você pode monitorar a infraestrutura Azure Local, os serviços de plano de controle e a saúde da VM por meio de soluções externas de monitoramento configuradas. Instale e configure os agentes e pacotes de gerenciamento necessários para sua solução de monitoramento. Operações desconectadas não oferecem um serviço dedicado para monitoramento do SQL Server.

Monitore o SQL Server dentro de cada VM com capacidades nativas, como visualizações de gerenciamento dinâmico, Eventos Estendidos e logs de erros, ou uma plataforma de monitoramento on-premises aprovada. No Windows, você também pode usar alertas do SQL Server Agent e contadores de desempenho do Windows. Alertas do SQL Server Agent não são suportados no Linux; revise o suporte a recursos do SQL Server em Linux para sua versão.

Colete os seguintes sinais, conforme apropriado para sua carga de trabalho:

  • Disponibilidade do SQL Server, status do banco de dados, idade do backup e falhas de trabalho.
  • Bloqueios, impasses, esperas, utilização de CPU e pressão de memória.
  • Latência de armazenamento, crescimento do banco de dados e dos logs e tempdb integridade.
  • Sincronização de réplicas de alta disponibilidade.

Mantenha a telemetria em repositórios locais aprovados. Defina limiares acionáveis e procedimentos de escalonamento. Para monitoramento de plataforma, veja Monitorar operações desconectadas.

Faça backup e recupere o SQL Server

Important

A capacidade de backup de operações desconectadas protege apenas os dados da VM do plano de controle. Ele não faz backup de cargas de trabalho do SQL Server nem de clusters de cargas de trabalho configurados. Configure separadamente os backups do SQL Server.

  1. Selecione modelos de recuperação com base nos seus RPOs. Programe backups completos e, conforme necessário, backups diferenciais para armazenamento local protegido. Para bancos de dados que utilizam o modelo de recuperação completo ou bulk-logged, também agende backups do log de transações. O modelo simples de recuperação não suporta backups de logs de transações ou recuperação pontual. Use compressão, somas de verificação e criptografia quando adequado.
  2. Mantenha cópias em um domínio de falha separado ou em um site separado. Proteja as chaves de backup e criptografia de forma independente, e monitore a capacidade e a idade do backup.
  3. Teste completo e restaurações em host alternativo. Quando for necessária a recuperação para um ponto específico no tempo, use o modelo de recuperação completo, mantenha a cadeia de backups de log e teste restaurações para um ponto específico no tempo. Na recuperação logada em massa, você não pode restaurar para um ponto dentro de um backup de log que contenha alterações logadas em massa. Registre os RPOs e RTOs alcançados e trate as lacunas.

Para procedimentos, veja Backup e restauração de bancos de dados do SQL Server, Criar um backup completo do banco de dados e a visão geral de restauração e recuperação.

Serviço SQL Server offline

Mantenha as linhas de base aprovadas para atualizações cumulativas do SQL Server, patches do sistema operacional convidado, drivers, ferramentas de gerenciamento e softwares de segurança:

  • Atualizações de teste em um ambiente representativo desconectado.
  • Faça backup das cargas de trabalho antes de aplicar atualizações.
  • Aplique patches nas réplicas de alta disponibilidade em uma sequência controlada.
  • Valide o failover, a conectividade da aplicação e o desempenho após a atualização.
  • A Microsoft publica a atualização cumulativa (), a versão geral de distribuição (GDR) ou a atualização de segurança aplicável do SQL Server por meio dos canais padrão de atualização de serviço do SQL Server e das últimas atualizações e histórico de versões do SQL Server.

Entregue atualizações do SQL Server e dos convidados por meio de um mecanismo aprovado para o sistema operacional convidado:

Siga as orientações separadas de atualização de operações desconectadas para atualizações de plataforma.

Construir aplicações locais de IA

O SQL Server 2025 pode se conectar a endpoints locais aprovados para conclusão de chat, como implantações compatíveis do Foundry Local. Aplicações podem combinar dados SQL com inferência de modelos on-premises sem exigir conectividade de nuvem pública.

O Foundry Local no Azure Local está em versão prévia. Complete seus pré-requisitos de implantação e acesso antes de integrar um modelo ao SQL Server. Antes de chamar um endpoint de um modelo local:

  • Habilite a opção de configuração do external rest endpoint enabled servidor. O procedimento é desativado por padrão no SQL Server 2025.
  • Conceda permissão principal ao banco EXECUTE ANY EXTERNAL ENDPOINT de dados que chama e configure a autenticação e as credenciais exigidas pelo endpoint.
  • Torne o endpoint HTTPS do modelo implantado acessível a partir da VM do SQL Server. Configure certificados TLS e confiança de certificados para uso em produção. Não confie em testes de inferência que contornam a validação de certificados.

Revise os endpoints suportados e os requisitos de segurança antes de usar sp_invoke_external_rest_endpoint. Para implantação e inferência de modelos, veja Foundry Local no Azure Local, execute inferência e traga seus próprios modelos.

A inferência local de modelos não estabelece que ferramentas de desenvolvedores possam operar sem conectividade em nuvem. Valide separadamente os requisitos de autenticação, cliente e conectividade de cada ferramenta antes de incluí-los em um fluxo de trabalho desconectado.

Licenciamento e limites de suporte

Escolha o modelo de licenciamento do SQL Server antes de finalizar o tamanho e a topologia de disponibilidade da VM. Avalie os requisitos de edição, licenciamento de núcleo virtual, licenciamento elegível de núcleo físico com virtualização ilimitada, garantia de software ou direitos de assinatura, e direitos não relacionados à produção. A capacidade da plataforma de operações desconectadas do Azure Local é licenciada separadamente.

  • Edição: Validar os requisitos de recursos das edições Standard e Enterprise, incluindo disponibilidade, escala, operações online e direitos de virtualização.
  • Escopo da licença: Compare a licença de núcleo virtual por VM com modelos de núcleo físico elegíveis, especialmente ao consolidar VMs do SQL Server.
  • Modelo de licenciamento: Validar requisitos de Garantia de Software ou Assinatura do SQL Server e elegibilidade para o Benefício Híbrido do Azure para operações desconectadas.
  • Registros: Mantenha inventários de hosts, VMs, núcleos atribuídos, edições, ambientes e evidências de licença.

Revise o faturamento de operações desconectadas quanto aos termos da plataforma. O SQL Server habilitado pela documentação de licenciamento do Azure Arc descreve a experiência de gerenciamento conectado; não é um procedimento para instalar a extensão SQL Server não suportada em operações desconectadas.

Conteúdo relacionado

  • Última atualização em