Examinar instância gerenciada SQL

  • 9 minutos

Embora muitas organizações migrem inicialmente para o Azure usando ofertas de IaaS, a plataforma como serviço (PaaS) oferece benefícios extras. Com o PaaS, o serviço lida com a instalação e a aplicação de patches no SQL Server, para que você não precise mais executar essas tarefas. Verificações de consistência, backups, segurança e ferramentas de desempenho também estão incluídos como parte do serviço gerenciado.

A Instância Gerenciada do SQL do Azure é uma instância do SQL Server totalmente funcional que é quase 100% compatível com seu ecossistema local. Ele inclui recursos como SQL Agent, acesso a tempdb, consultas entre bancos de dados e Common Language Runtime (CLR). Esse serviço usa a mesma infraestrutura do Banco de Dados SQL do Azure e oferece todos os benefícios do PaaS, como backups automáticos, patches automáticos e alta disponibilidade interna.

Recursos da Instância Gerenciada SQL do Azure

A Instância Gerenciada SQL do Azure oferece um caminho de migração contínuo para aplicativos existentes, habilitando restaurações de backups locais. Ao contrário do Banco de Dados SQL do Azure, que é projetado para estruturas de banco de dados únicas, a Instância Gerenciada do SQL fornece uma instância completa do SQL Server, dando suporte a até 100 bancos de dados e concedendo acesso aos bancos de dados do sistema. Ele também inclui recursos não disponíveis no Banco de Dados SQL do Azure, como consultas entre bancos de dados, Common Language Runtime (CLR) e o uso do SQL Agent por meio do banco de dados do sistema msdb.

Ao criar uma Instância Gerenciada SQL do Azure, você pode escolher entre duas camadas de serviço: Crítica para os Negócios e Finalidade Geral. Essas camadas se alinham com o modelo vCore do Banco de Dados SQL do Azure, pois as Instâncias Gerenciadas do SQL são adquiridas usando esse modelo. As principais diferenças entre as duas camadas são que o Business Critical inclui In-Memory OLTP e fornece um secundário legível, recursos não disponíveis na camada de uso geral. Ambos os níveis oferecem alta disponibilidade, com o nível Crítico de Negócios usando Grupos de Disponibilidade Always On para maior resiliência. Além disso, ambos os níveis permitem a configuração independente de recursos de armazenamento e computação.

O recurso Link fornece recursos híbridos replicando bancos de dados de instâncias do SQL Server para a Instância Gerenciada SQL do Azure. Ele usa grupos de disponibilidade distribuídos, parte da tecnologia de grupo de disponibilidade Always On, para replicar dados. Os registros de log de transações são replicados como parte desses grupos de disponibilidade distribuídos.

Os registros de log de transações na instância primária não podem ser truncados até que sejam replicados para a instância secundária. Backups regulares de log de transações ajudam a reduzir o risco de ficar sem espaço na instância principal.

O recurso Link também pode ser usado como uma solução híbrida de recuperação de desastres, permitindo que você faça failover de seus bancos de dados do SQL Server hospedados em qualquer lugar para um banco de dados em execução na Instância Gerenciada do SQL. Pode-se, além disso, usar o recurso "Link" para fornecer um banco de dados secundário de leitura exclusiva na Instância Gerida SQL, aliviando operações intensivas de leitura exclusiva.

Para obter mais informações sobre como configurar o recurso de link para a Instância Gerenciada SQL do Azure, consulte Preparar o ambiente para o recurso de link - Instância Gerenciada SQL do Azure.

Conjunto de instância

Os pools de instâncias fornecem uma maneira econômica de migrar instâncias menores do SQL Server para a nuvem. Em vez de consolidar bancos de dados menores em uma instância gerenciada maior, o que requer controle e planejamento de segurança extras, os pools de instâncias permitem pré-provisionar recursos com base em suas necessidades e requisitos totais de migração.

O recurso de pool de instâncias oferece um tempo de implantação rápido de até 10 minutos, tornando-o ideal para cenários em que a duração da implantação é crucial. Além disso, todas as instâncias em um pool compartilham a mesma máquina virtual e a alocação total de IP é independente do número de instâncias implantadas.

Para saber como implantar um pool de instâncias para a Instância Gerenciada do SQL, consulte Implantar a Instância Gerenciada SQL do Azure em um pool de instâncias .

Alta disponibilidade e recuperação de desastres

A Instância Gerenciada SQL do Azure, como um serviço PaaS, fornece inerentemente alta disponibilidade. Uma Instância Gerenciada SQL autônoma oferece um SLA (Service Level Agreement, SLA) de 99,99%, garantindo um máximo de 52,60 minutos de tempo de inatividade por ano. A arquitetura espelha a do Banco de Dados SQL do Azure: a camada de Uso Geral usa replicação de armazenamento para disponibilidade, enquanto a camada Crítica de Negócios emprega várias réplicas para maior resiliência.

A Instância Gerenciada SQL do Azure oferece grupos de failover automático para recuperação de desastres, protegendo toda a instância gerenciada e todos os seus bancos de dados. Esse recurso replica de forma assíncrona dados da Instância Gerenciada SQL do Azure primária para uma instância secundária, mas atualmente está limitado à região emparelhada do Azure da instância primária, com apenas uma réplica permitida.

Semelhante ao Azure SQL Database, os grupos de failover automático fornecem pontos de extremidade de escuta para leitura e escrita e de escuta somente leitura, simplificando o gerenciamento da cadeia de conexão. Se houver um failover, as cadeias de conexão do aplicativo serão automaticamente roteadas para a instância apropriada. No entanto, esses pontos de extremidade seguem um formato ligeiramente diferente: <fog-name>.zone_id.database.windows.net para a Instância Gerenciada do SQL, em comparação com <fog-name>.zone_id.database.windows.net enquanto o Banco de Dados SQL do Azure está no Banco de Dados SQL do <fog-name>.secondary.database.windows.net Azure.

As instâncias gerenciadas primária e secundária devem estar dentro da mesma zona DNS. Isso garante que o mesmo certificado de vários domínios possa ser usado para autenticação de conexão de cliente entre as instâncias no grupo de failover. Você pode especificar um "Parceiro de Zona DNS" por meio do portal do Azure, PowerShell ou CLI do Azure.

Cópias de Segurança

Os backups automáticos são configurados por padrão para a Instância Gerenciada SQL do Azure. Uma diferença importante entre a Instância Gerenciada SQL do Azure e o Banco de Dados SQL do Azure é que, com a Instância Gerenciada do SQL, você pode criar manualmente um backup somente cópia de um banco de dados. Esses backups devem ser armazenados em uma URL, pois o acesso ao armazenamento local não é permitido. Além disso, você pode configurar a retenção de longo prazo (LTR) para reter backups automáticos por até 10 anos no armazenamento de Blob do Azure com redundância geográfica.

Os backups de banco de dados seguem o mesmo agendamento do Banco de Dados SQL do Azure e essas agendas não podem ser ajustadas.

  • Completo – Uma vez por semana
  • Diferencial – A cada 12 horas
  • Log de transações – A cada 5-10 minutos, dependendo do uso do log de transações

Restaurar um banco de dados para uma Instância Gerenciada SQL do Azure é semelhante ao processo com o Banco de Dados SQL do Azure. Você pode usar o portal do Azure, o PowerShell ou a CLI do Azure. Para restaurar de uma instância para outra, ambas as instâncias devem residir na mesma assinatura e região do Azure. Além disso, não é possível restaurar toda a instância gerenciada, apenas bancos de dados individuais dentro da Instância Gerenciada SQL.

Tal como acontece com a Base de Dados SQL do Azure, não pode restaurar através de uma base de dados existente. Você precisa descartar ou renomear o banco de dados existente antes de restaurá-lo do backup. Como a Instância Gerenciada do SQL é uma instância do SQL Server totalmente funcional, você pode executar um RESTORE comando, o que não é possível com o Banco de Dados SQL do Azure. No entanto, como um serviço de PaaS, existem algumas limitações:

  • Você deve restaurar a partir de um endpoint de URL, pois as unidades locais não estão disponíveis.
  • Você pode usar as seguintes opções (além de especificar o banco de dados):
    • FILELISTONLY
    • SOMENTE CABEÇALHO
    • APENAS RÓTULO
    • VERIFICARAPENAS
  • Os arquivos de backup contendo vários arquivos de log não podem ser restaurados
  • Os arquivos de backup contendo vários conjuntos de backup não podem ser restaurados
  • Backups contendo In-Memory/FILESTREAM não podem ser restaurados

Por padrão, os bancos de dados em uma instância gerenciada são criptografados usando TDE (Transparent Data Encryption) com uma chave gerenciada pela Microsoft. Para fazer um backup somente cópia iniciado pelo usuário, você deve desabilitar o TDE para o banco de dados específico. Se um banco de dados estiver criptografado, você poderá restaurá-lo, mas precisará acessar o certificado ou a chave assimétrica usada para criptografia. Sem eles, não é possível restaurar o banco de dados para uma instância gerenciada do SQL.

Para conhecer os novos recursos da Instância Gerenciada SQL do Azure, consulte O que há de novo na Instância Gerenciada SQL do Azure?.