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

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

Cada oferta proporciona um determinado nível de administração que o utilizador tem sobre a infraestrutura, dependendo do 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:

• Base de dados única – 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 bases de dados que são geridos juntos e partilham 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, já 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 dão suporte a hardware físico e você tem a flexibilidade de escolher entre dois modelos de compra diferentes:

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

O modelo de compra baseado em DTU é calculado 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 capacidades variadas, fornecendo uma ampla gama de opções ao escolher esta plataforma.

Em termos de desempenho, a camada Basic é usada para cargas de trabalho menos exigentes, enquanto a camada 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 de compra baseado em vCore permite que você compre um número especificado de vCores com base em suas cargas de trabalho específicas. 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:

A camada de serviço de uso geral oferece duas opções de computação: provisionado e sem servidor. Os recursos provisionados são preconfigurados e faturados por hora, baseado nos vCores configurados, sendo ideais para cargas de trabalho consistentes. Os recursos sem servidor são dimensionados automaticamente com base na demanda e são cobrados por segundo, tornando-o econômico para cargas de trabalho variáveis.

Sem servidor

O termo "Sem servidor" pode ser enganoso porque você ainda implanta seu Banco de Dados SQL do Azure em um servidor lógico para conexão. Serverless é uma camada de computação que dimensiona automaticamente os recursos para cima ou para baixo com base na demanda de carga de trabalho. Quando a carga de trabalho não requer mais recursos de computação, o banco de dados é pausado e apenas o armazenamento é cobrado durante o período inativo. Após uma tentativa de conexão, o banco de dados é retomado e fica disponível.

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

Quando o banco de dados estiver inativo pelo tempo especificado, ele será pausado até uma tentativa de conexão subsequente. Configurar um intervalo de escalonamento automático de computação e um atraso para suspensão automática afeta o desempenho do banco de dados e os custos de computação.

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 gera um erro de conexão.

Outra diferença entre serverless e o modelo vCore padrão 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 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 constantemente, como:

• Georreplicação
• Retenção de backup de longo prazo
• Um banco de dados de tarefas elásticas
• 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, o sistema realiza backups automaticamente sem qualquer intervenção sua. O armazenamento com redundância geográfica de blob do Azure armazena esses backups e, por padrão, os retém por entre 7 e 35 dias, dependendo da camada de serviço do banco de dados. Os bancos de dados Basic e vCore usam como padrão sete dias de retenção, e os administradores podem ajustar esse valor para bancos de dados vCore. Você pode estender o tempo de retenção configurando a retenção de longo prazo (LTR), permitindo que você mantenha 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. Não há suporte para backups manuais de bancos de dados, 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
• Registo – A cada 5-10 minutos, dependendo da atividade do registo de transações

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

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.

• 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 lógico 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.

Replicação geográfica 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 ao chamador.

Os bancos de dados secundários estão disponíveis para leitura e podem ser usados para aliviar cargas de trabalho de leitura somente, liberando assim recursos ao mesmo tempo que para cargas de trabalho transacionais no banco de dados primário ou colocando os dados geograficamente mais perto dos seus utilizadores 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

Você pode iniciar um failover manualmente pelo usuário ou programaticamente pelo aplicativo. Se ocorrer um failover, você poderá 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 tolerância a falhas

Os grupos de failover são construídos com base na tecnologia utilizada na geo-replicação, mas oferecem um único endpoint para a conexão. A principal razão para usar grupos de alternância de falha é que eles fornecem pontos finais 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.