Explicar as opções de PaaS para implantar o SQL Server no Azure

• 12 minutos

A plataforma como serviço (PaaS) fornece um ambiente completo de desenvolvimento e implantação na nuvem, que pode ser usado para aplicativos simples baseados em nuvem, bem como para aplicativos corporativos avançados.

O Banco de Dados SQL do Azure e a Instância Gerenciada do SQL do Azure fazem parte da oferta de PaaS para o Azure SQL.

• Banco de Dados SQL do Azure – Parte de uma família de produtos criados com base no mecanismo do SQL Server, na nuvem. Ele oferece aos desenvolvedores uma grande flexibilidade na criação de novos serviços de aplicativos e opções de implantação granular em escala. O Banco de dados SQL oferece uma solução de baixa manutenção que pode ser uma ótima opção para determinadas cargas de trabalho.

• Instância Gerenciada SQL do Azure – É melhor para a maioria dos cenários de migração para a nuvem, pois fornece serviços e recursos totalmente gerenciados.

Como visto na imagem acima, cada oferta fornece um certo nível de administração que você tem sobre a infraestrutura, pelo grau de eficiência de custos.

Modelos de implementação

O Banco de Dados SQL do Azure está disponível em dois modelos de implantação diferentes:

• Banco de dados único – um único banco de dados que é cobrado e gerenciado em um nível por banco de dados. Você gerencia cada um de seus bancos de dados individualmente a partir de perspetivas de escala e tamanho de dados. Cada banco de dados implantado neste modelo tem seus próprios recursos dedicados, mesmo se implantado no mesmo servidor lógico.

• Pools elásticos – um grupo de bancos de dados que são gerenciados juntos e compartilham um conjunto comum de recursos. Os pools elásticos fornecem uma solução econômica para o modelo de aplicativo de software como serviço, uma vez que os recursos são compartilhados entre todos os bancos de dados. Você pode configurar recursos com base no modelo de compra baseado em DTU ou no modelo de compra baseado em vCore.

Modelo de compra

No Azure, todos os serviços são apoiados por hardware físico e você pode escolher entre dois modelos de compra diferentes:

Unidade de Transação de Banco de Dados (DTU)

As DTUs são calculadas com base em uma fórmula que combina recursos de computação, armazenamento e E/S. É uma boa escolha para clientes que desejam opções de recursos simples e pré-configuradas.

O modelo de compra DTU vem em várias camadas de serviço diferentes, como Basic, Standard e Premium. Cada camada tem recursos variados, que fornecem uma ampla gama de opções ao escolher essa plataforma.

Em termos de desempenho, a camada Basic é usada para cargas de trabalho menos exigentes, enquanto a Premium é usada para requisitos de carga de trabalho intensiva.

Os recursos de computação e armazenamento dependem do nível da DTU e fornecem uma variedade de recursos de desempenho com um limite fixo de armazenamento, retenção de backup e custo.

Para obter mais informações sobre o modelo de compra DTU, consulte Visão geral do modelo de compra baseado em DTU.

vCore

O modelo vCore permite que você compre um número especificado de vCores com base em suas cargas de trabalho fornecidas. vCore é o modelo de compra padrão ao comprar recursos do Banco de Dados SQL do Azure. Os bancos de dados vCore têm uma relação específica entre o número de núcleos e a quantidade de memória e armazenamento fornecidos ao banco de dados. O modelo de compra vCore é suportado pelo Banco de Dados SQL do Azure e pela Instância Gerenciada SQL do Azure.

Você também pode comprar bancos de dados vCore em três camadas de serviço diferentes:

• Finalidade geral – Esta camada é para cargas de trabalho de uso geral. Ele é apoiado pelo armazenamento premium do Azure. Ele terá latência maior do que o Business Critical. Ele também fornece as seguintes camadas de computação:

  • Provisionado – Os recursos de computação são pré-alocados. Cobrado por hora com base em vCores configurados.
  • Sem servidor – Os recursos de computação são dimensionados automaticamente. Cobrado por segundo com base nos vCores usados.

• Business Critical – Esta camada é para cargas de trabalho de alto desempenho, oferecendo a menor latência de qualquer camada de serviço. Essa camada é apoiada por SSDs locais em vez do armazenamento de blob do Azure. Ele também oferece a mais alta resiliência a falhas, além de fornecer uma réplica de banco de dados somente leitura interna que pode ser usada para descarregar cargas de trabalho de relatórios.

• Hiperescala – Os bancos de dados de hiperescala podem ser dimensionados muito além do limite de 4 TB das outras ofertas do Banco de Dados SQL do Azure e têm uma arquitetura exclusiva que dá suporte a bancos de dados de até 100 TB.

Sem servidor

O nome "Serverless" pode ser um pouco confuso, pois você ainda implanta seu Banco de Dados SQL do Azure em um servidor lógico, ao qual você se conecta. O Banco de Dados SQL do Azure sem servidor é uma camada de computação que aumentará ou reduzirá automaticamente os recursos de um determinado banco de dados com base na demanda de carga de trabalho. Se a carga de trabalho não exigir mais recursos de computação, o banco de dados ficará "pausado" e somente o armazenamento será cobrado durante o período em que o banco de dados estiver inativo. Quando uma tentativa de conexão é feita, o banco de dados será "retomado" e ficará disponível.

A configuração para controlar a pausa é conhecida como atraso de pausa automática e tem um valor mínimo de 60 minutos e um valor máximo de sete dias. Se o banco de dados estiver ocioso por esse período de tempo, ele será pausado.

Depois que o banco de dados estiver inativo pelo tempo especificado, ele será pausado até que uma conexão subsequente seja tentada. A configuração de um intervalo de dimensionamento automático de computação e um atraso de pausa automática afetam o desempenho do banco de dados e os custos de computação.

Todos os aplicativos que usam serverless devem ser configurados para lidar com erros de conexão e incluir lógica de repetição, pois conectar-se a um banco de dados pausado gerará um erro de conexão.

Outra diferença entre serverless e o modelo vCore normal do Banco de Dados SQL do Azure é que, com serverless, você pode especificar um número mínimo e máximo de vCores. Os limites de memória e E/S são proporcionais ao intervalo especificado.

A imagem acima mostra a tela de configuração de um banco de dados sem servidor no portal do Azure. Você tem a opção de selecionar um mínimo tão baixo quanto metade de um vCore e um máximo tão alto quanto 16 vCores.

O Serverless não é totalmente compatível com todos os recursos do Banco de Dados SQL do Azure, pois alguns deles exigem que processos em segundo plano sejam executados o tempo todo, como:

• Georreplicação
• Retenção de cópia de segurança de longa duração
• Um banco de dados de trabalhos em trabalhos elásticos
• O banco de dados de sincronização no SQL Data Sync (a Sincronização de Dados é um serviço que replica dados entre um grupo de bancos de dados)

Cópias de Segurança

Uma das características mais importantes da oferta de Plataforma como Serviço são os backups. Neste caso, os backups são realizados automaticamente sem qualquer intervenção sua. Os backups são armazenados no armazenamento com redundância geográfica de blob do Azure e, por padrão, são retidos por entre 7 e 35 dias, com base na camada de serviço do banco de dados. Os bancos de dados Basic e vCore têm como padrão sete dias de retenção, e nos bancos de dados vCore esse valor pode ser ajustado pelo administrador. O tempo de retenção pode ser estendido configurando a retenção de longo prazo (LTR), o que permitiria reter backups por até 10 anos.

Para fornecer redundância, você também pode usar armazenamento de blob com redundância geográfica acessível à leitura. Esse armazenamento replicaria os backups do banco de dados para uma região secundária de sua preferência. Também lhe permitiria ler a partir dessa região secundária, se necessário. Backups manuais de bancos de dados não são suportados, e a plataforma negará qualquer solicitação para fazê-lo.

Os backups de banco de dados são feitos em um determinado cronograma:

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

Esse agendamento de backup deve atender às necessidades da maioria dos RPO/RTO (Recovery Point Point Objetives, objetivos de ponto/tempo de recuperação), no entanto, cada cliente deve avaliar se eles atendem aos seus requisitos de negócios.

Há várias opções disponíveis para restaurar um banco de dados. Devido à natureza da plataforma como serviço, não é possível restaurar manualmente um banco de dados usando métodos convencionais, como a emissão do comando RESTORE DATABASET-SQL.

Independentemente do método de restauração implementado, não é possível restaurar em um banco de dados existente. Se um banco de dados precisar ser restaurado, o banco de dados existente deverá ser descartado ou renomeado antes de iniciar o processo de restauração. Além disso, lembre-se de que, dependendo da camada de serviço da plataforma, os tempos de restauração não são garantidos e podem flutuar. É recomendável testar o processo de restauração para obter uma métrica de linha de base sobre quanto tempo uma restauração pode levar.

As opções de restauração disponíveis são:

• Restaurar usando o portal do Azure – Usando o portal do Azure, você tem a opção de restaurar um banco de dados para o mesmo servidor do Banco de dados SQL do Azure ou pode usar a restauração para criar um novo banco de dados em um novo servidor em qualquer região do Azure.

• Restaurar usando linguagens de script – O PowerShell e a CLI do Azure podem ser utilizados para restaurar um banco de dados.

Para obter mais informações sobre backups automatizados, consulte Backups automatizados - Banco de Dados SQL do Azure & Instância Gerenciada SQL do Azure.

Georreplicação ativa

A replicação geográfica é um recurso de continuidade de negócios que replica de forma assíncrona um banco de dados para até quatro réplicas secundárias. Como as transações são confirmadas para o primário (e suas réplicas dentro da mesma região), as transações são enviadas para os secundários para serem reproduzidas. Como essa comunicação é feita de forma assíncrona, o aplicativo de chamada não precisa esperar que a réplica secundária confirme a transação antes que o SQL Server retorne o controle para o chamador.

Os bancos de dados secundários são legíveis e podem ser usados para descarregar cargas de trabalho somente leitura, liberando recursos para cargas de trabalho transacionais no primário ou colocando os dados mais perto dos usuários finais. Além disso, os bancos de dados secundários podem estar na mesma região que o primário ou em outra região do Azure.

Com a replicação geográfica, você pode iniciar um failover manualmente pelo usuário ou pelo aplicativo. Se ocorrer um failover, você potencialmente precisará atualizar as cadeias de conexão do aplicativo para refletir o novo ponto de extremidade do que agora é o banco de dados primário.

Grupos de ativação pós-falha

Os grupos de failover são criados com base na tecnologia usada na replicação geográfica, mas fornecem um único ponto de extremidade para conexão. A principal razão para usar grupos de failover é que a tecnologia fornece pontos de extremidade, que podem ser utilizados para rotear o tráfego para a réplica apropriada. Seu aplicativo pode se conectar após um failover sem alterações na cadeia de conexão.