Examinar a instância gerenciada de SQL

  • 9 minutos

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

A Instância Gerenciada de 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 CLR (Common Language Runtime). Esse serviço usa a mesma infraestrutura que o Banco de Dados SQL do Azure e oferece todos os benefícios do PaaS, como backups automáticos, patch automático e alta disponibilidade interna.

Funcionalidades da Instância Gerenciada de SQL do Azure

A Instância Gerenciada de SQL do Azure oferece um caminho de migração contínuo para aplicativos existentes, permitindo restaurações de backups locais. Ao contrário do Banco de Dados SQL do Azure, projetado para estruturas de banco de dados individuais, a Instância Gerenciada de SQL fornece uma instância completa do SQL Server, oferecendo suporte a até 100 bancos de dados e concedendo acesso a 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, CLR (Common Language Runtime) e o uso do SQL Agent por meio do banco de dados do sistema msdb.

Ao criar uma Instância Gerenciada de SQL do Azure, você pode escolher entre duas camadas de serviço: Comercialmente Crítico e Uso Geral. Essas camadas se alinham com o modelo vCore do Banco de Dados SQL do Azure, pois as Instâncias Gerenciadas de SQL são adquiridas usando esse modelo. As principais diferenças entre as duas camadas são que a Business Critical inclui o OLTP in-memory e fornece um secundário legível, recursos não disponíveis na camada Uso Geral. Ambas as camadas oferecem alta disponibilidade, com a camada Comercialmente Crítica usando Grupos de Disponibilidade AlwaysOn para maior resiliência. Além disso, ambas as camadas 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 de 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 em sua instância primária.

O recurso Link também pode ser usado como uma solução de recuperação de desastre híbrida, permitindo que você faça failover dos bancos de dados do SQL Server hospedados em qualquer lugar para um banco de dados em execução na Instância Gerenciada de SQL. Além disso, você pode usar o recurso Link para fornecer um banco de dados secundário em modo somente leitura na Instância Gerenciada de SQL, aliviando operações de leitura intensiva.

Para saber mais sobre como configurar o recurso de link para a Instância Gerenciada de SQL do Azure, confira Preparar o ambiente para o recurso de link – Instância Gerenciada de SQL do Azure.

Pool de instâncias

Os pools de instância 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, que exige governança extra e planejamento de segurança, os pools de instâncias permitem pré-provisionar recursos com base em suas necessidades e requisitos de migração totais.

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 de SQL, confira Implantar a Instância Gerenciada de SQL do Azure em um pool de instâncias.

Alta disponibilidade e recuperação de desastre

A Instância Gerenciada de SQL do Azure, como um serviço de PaaS, fornece inerentemente alta disponibilidade. Uma Instância Gerenciada de SQL autônoma oferece um SLA (Contrato de Nível de Serviço) 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 Geral usa a replicação de armazenamento para alta disponibilidade, enquanto a camada Comercialmente Crítico emprega várias réplicas para maior resiliência.

A Instância Gerenciada de SQL do Azure oferece grupos de failover automático para recuperação de desastre, 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 de 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 Banco de Dados SQL do Azure, os grupos de failover automático fornecem pontos de extremidade de ouvinte de leitura e gravação e somente leitura, simplificando o gerenciamento de cadeia de conexão. Se houver um failover, as strings de conexão do aplicativo serão roteadas automaticamente 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 de 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árias e secundárias 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, do PowerShell ou da CLI do Azure.

Backups

Os backups automáticos são configurados por padrão para a Instância Gerenciada de SQL do Azure. Uma diferença importante entre a Instância Gerenciada de SQL do Azure e o Banco de Dados SQL do Azure é que, com a Instância Gerenciada de 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 LTR (retenção de longo prazo) para reter backups automáticos por até 10 anos no Armazenamento de Blobs do Azure com redundância geográfica.

Os backups de banco de dados seguem a mesma agenda que o Banco de Dados SQL do Azure e esses agendamentos não podem ser ajustados.

  • Completo – uma vez por semana
  • Diferencial – a cada 12 horas
  • Log de Transações – a cada cinco a dez minutos, dependendo do uso do log de transações

Restaurar um banco de dados para uma Instância Gerenciada de 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, você não pode restaurar toda a instância gerenciada, apenas bancos de dados individuais dentro da Instância Gerenciada de SQL.

Assim como no Banco de Dados SQL do Azure, você não pode restaurar em um banco de dados existente. Você precisa remover ou renomear o banco de dados existente antes de restaurá-lo do backup. Como a Instância Gerenciada de 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, há algumas limitações:

  • Você deve restaurar de um ponto de extremidade de URL, pois as unidades locais não são acessíveis.
  • Você pode usar as seguintes opções (além de especificar o banco de dados):
    • FILELISTONLY
    • HEADERONLY
    • LABELONLY
    • VERIFYONLY
  • Os arquivos de backup que contêm vários arquivos de log não podem ser restaurados
  • Os arquivos de backup que contêm vários conjuntos de backup não podem ser restaurados
  • Backups que contêm In-Memory/FILESTREAM não podem ser restaurados

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

Para saber mais sobre os novos recursos para a Instância Gerenciada de SQL do Azure, confira Novidades na Instância Gerenciada de SQL do Azure?.