Examinar a instância gerenciada de SQL

  • 9 minutos

Embora muitas organizações migrem inicialmente para o Azure usando ofertas de IaaS, a oferta de serviço de PaaS (plataforma como serviço) proporciona benefícios extra. Além disso, você não precisa mais instalar o SQL Server nem aplicar patches nele, pois isso será feito pelo serviço. A verificação de consistência e os backups também fazem parte do serviço gerenciado, incluindo ferramentas de segurança e desempenho incluídas nas ofertas de PaaS.

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

Recursos da Instância Gerenciada de SQL do Azure

A Instância Gerenciada de SQL do Azure proporciona caminhos de migração fáceis para aplicativos existentes ao permitir restaurações de backups locais. Diferente do Banco de Dados SQL do Azure, que foi projetado com base em estruturas de banco de dados individuais, a Instância Gerenciada de SQL fornece uma instância de SQL Server inteira, permitindo até 100 bancos de dados, além de fornecer acesso aos bancos de dados do sistema. A Instância Gerenciada de SQL fornece outros recursos que não estão disponíveis no Banco de Dados SQL do Azure, incluindo consultas entre bancos de dados, CLR (Common Language Runtime) e, em conjunto com o banco de dados do sistema msdb, permite o uso do SQL Agent.

Opções

Há duas camadas de serviço disponíveis ao criar uma Instância Gerenciada de SQL do Azure, que são iguais às do modelo vCore do Banco de Dados SQL do Azure (a instância gerenciada é adquirida usando o modelo vCore): Comercialmente Crítico e Uso Geral. Há diferenças mínimas de funcionalidade entre as duas camadas – as duas principais são que Comercialmente Crítico inclui OLTP In-Memory e oferece uma réplica secundária para leitura, e nenhuma dessas opções está disponível na camada de Uso Geral. Ambas as camadas oferecem os mesmos níveis de disponibilidade e permitem a configuração independente do armazenamento e da computação.

O recurso de link fornece a funcionalidade híbrida de replicação de bancos de dados de instâncias do SQL Server para a Instância Gerenciada de SQL do Azure. O recurso de link replica dados usando os grupos de disponibilidade distribuídos disponíveis na tecnologia de grupos de disponibilidade Always On. Os registros de log de transações são replicados como parte dos grupos de disponibilidade distribuídos.

Registros de log de transações na instância primária não podem ser truncados até que tenham sido replicados para a instância secundária. Backups de log de transações regulares reduzem o risco de ficar sem espaço na instância primária.

O recurso de link também pode ser usado como uma solução híbrida de recuperação de desastre, em que você pode fazer 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. De maneira semelhante, você pode usar o recurso de link para fornecer um banco de dados secundário somente leitura na Instância Gerenciada de SQL do Banco de Dados SQL para descarregar operações intensivas somente leitura.

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 (versão prévia)

O pool de instâncias oferece uma maneira econômica de migrar instâncias menores do SQL Server para a nuvem. Ao migrar para o Azure, em vez de consolidar bancos de dados menores em uma instância gerenciada maior, o que requer planejamento de segurança e governança extra, os pools de instâncias permitem provisionar previamente os recursos com base os requisitos e recursos totais da migração.

O recurso de pool de instâncias proporciona uma implantação rápida, de até cinco minutos, que é uma boa opção para cenários em que a duração da implantação é importante. Além disso, todas as instâncias em um pool compartilham a mesma máquina virtual, e a alocação total de IP independe 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

Como a Instância Gerenciada de SQL do Azure tem suporte do serviço de PaaS, ela tem alta disponibilidade inclusa no produto. Uma Instância Gerenciada de SQL autônoma oferece um SLA (Contrato de Nível de Serviço) de 99,99% que garante, no máximo, 52,60 minutos de inatividade por ano. A arquitetura é a mesma do Banco de Dados SQL do Azure com Uso Geral, que usa a replicação de armazenamento para disponibilidade, e comercialmente Crítico usando várias réplicas.

Backups

Os backups automáticos também são automaticamente configurados para a Instância Gerenciada de SQL do Azure. Uma diferença importante entre a MI (Instância Gerenciada) de SQL do Azure e o Banco de Dados SQL do Azure é que, com a MI, você poderá fazer um backup somente cópia de um banco de dados. Você precisa fazer backup em uma URL, pois o acesso ao armazenamento local não é permitido. Você também pode configurar a LTR (retenção de longo prazo) para reter backups automáticos por até dez anos no armazenamento de blobs do Azure com redundância geográfica.

Os backups de banco de dados ocorrem com cronograma igual ao do Banco de Dados SQL do Azure. Esses agendamentos não são ajustáveis.

  • 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

A restauração de um banco de dados para uma Instância Gerenciada de SQL do Azure também é semelhante ao processo com o Banco de Dados SQL do Azure. Você pode usar:

  • Portal do Azure
  • PowerShell
  • CLI do Azure

No entanto, há algumas limitações na restauração. Para restaurar de uma instância para outra, as duas instâncias precisam residir na mesma assinatura do Azure, bem como na mesma região do Azure. Além disso, não é possível restaurar toda a instância gerenciada, somente bancos de dados individuais dentro da Instância Gerenciada em si.

Assim como no Banco de Dados SQL do Azure, você não pode restaurar em um banco de dados existente. Você precisa descartar 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 comando RESTORE; já no Banco de Dados SQL do Azure, isso não é possível. No entanto, como se trata de um serviço de PaaS, há algumas limitações, como:

  • Você deve restaurar de um ponto de extremidade de URL. Você não tem acesso às unidades locais.
  • 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 TDE (Transparent Data Encryption) com uma chave gerenciada da Microsoft. Para fazer um backup somente cópia iniciado pelo usuário, você deve desativar o TDE para o banco de dados específico. Se um banco de dados for criptografado, você poderá restaurá-lo, mas precisará ter acesso ao certificado ou à chave assimétrica usada para criptografá-lo. Se você não tiver nenhum desses dois itens, não poderá restaurar o banco de dados para uma Instância Gerenciada de SQL.

Recuperação de desastre

A Instância Gerenciada de SQL do Azure oferece grupos de failover automático como um meio de implementar a recuperação de desastre. Esse recurso protege toda a instância gerenciada e todos os bancos de dados contidos nela, não apenas bancos de dados específicos. Esse processo replica dados de modo assíncrono da Instância Gerenciada de SQL do Azure para um secundário; no entanto, atualmente ele é limitado à região emparelhada do Azure da cópia primária, e apenas uma réplica é permitida.

Assim como o Banco de Dados SQL do Azure, os grupos de failover automático oferecem pontos de extremidade de ouvinte de leitura e gravação e somente leitura, o que facilita o gerenciamento da cadeia de conexão. Caso haja um failover, as cadeias de conexão do aplicativo serão roteadas automaticamente para a instância adequada. Embora sejam bastante consistentes com o Banco de Dados SQL do Azure, esses pontos de extremidade seguem um formato ligeiramente diferente, o formato <fog-name>.zone_id.database.windows.net whereas Azure SQL Database is in the <fog-name>.secondary.database.windows.net.

Cada instância gerenciada, primária e secundária, deve estar dentro da mesma zona DNS. Esse posicionamento garantirá que o mesmo certificado de vários domínios possa ser usado para autenticação de conexão de cliente entre qualquer uma das duas instâncias no mesmo grupo de failover. Você pode especificar um "Parceiro de Zona DNS" por meio de vários métodos, como o portal do Azure, o PowerShell ou a CLI do Azure.

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?.