Explicar as opções de PaaS para a implantação do SQL Server no Azure
A PaaS (Plataforma como Serviço) fornece um ambiente completo de desenvolvimento e implantação na nuvem, que pode ser usado para aplicativos simples baseados em nuvem e para aplicativos empresariais avançados.
O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure fazem parte da oferta de PaaS para o SQL do Azure.
Banco de Dados SQL do Azure – Parte de uma família de produtos criada no mecanismo do SQL Server, na nuvem. Ele oferece aos desenvolvedores uma grande flexibilidade na criação de novos serviços de aplicativo 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 de 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 fornece um determinado nível de controle que você tem sobre a infraestrutura, de acordo com o grau de eficiência em custos.
Modelos de implantação
O Banco de Dados SQL do Azure está disponível em dois modelos de implantação diferentes:
Banco de dados único – Um banco de dados individual que é cobrado e gerenciado em um nível por banco de dados. Você gerencia cada um de seus bancos de dados individualmente por meio de perspectivas de escala e tamanho de dados. Cada banco de dados implantado nesse modelo tem os 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 software como um modelo de aplicativo de serviço, pois 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:
DTU (Unidade de Transação de Banco de Dados)
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 opção para clientes que desejam opções de recursos simples e pré-configuradas.
O modelo de compra de DTU vem em várias camadas de serviço diferentes, como Basic, Standard e Premium. Cada camada tem funcionalidades variadas, fornecendo uma ampla gama de opções ao escolher essa plataforma.
Em termos de desempenho, a camada Básica é usada para cargas de trabalho menos exigentes, enquanto a camada Premium é usada para requisitos intensivos de carga de trabalho.
Os recursos de computação e armazenamento dependem do nível de DTU e oferecem uma variedade de recursos de desempenho com limite de armazenamento, retenção de backup e custo fixos.
Para obter mais informações sobre o modelo de compra de DTU, consulte a 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 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 fornecida ao banco de dados. O modelo de compra do vCore é compatível com o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure.
Você também pode comprar bancos de dados vCore em três camadas de serviço diferentes:
| Camada de serviço | Mais Adequado Para | Tipo de armazenamento | Latência | Camadas de computação | Recursos de resiliência | Tamanho máximo do banco de dados |
|---|---|---|---|---|---|---|
| Uso Geral | Cargas de trabalho de uso geral | Armazenamento premium do Azure | Maior que BC | Provisionado, sem servidor | Não aplicável | 4 TB |
| Comercialmente Crítico | Cargas de trabalho de alto desempenho | SSDs locais | Menor | Provisionado | Réplica somente leitura interna, maior resiliência à falha | 4 TB |
| Hiperescala | Bancos de dados em larga escala | Armazenamento premium do Azure | Varia | Provisionado | Arquitetura exclusiva para escalabilidade | 100 TB |
A camada de serviço de Uso Geral oferece duas opções de computação: Provisionada e sem servidor. Os recursos provisionados são pré-alocados e cobrados por hora com base em vCores configurados, ideal 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. Sem servidor é 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 somente 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 autopausa, com um valor mínimo de 60 minutos e um valor máximo de sete dias. Se o banco de dados permanecer ocioso durante essa duração, ele será pausado.
Depois que o banco de dados estiver inativo pela hora especificada, ele pausará até uma tentativa de conexão subsequente. Configurar um intervalo de escalonamento automático de computação e um atraso de pausa automática afeta o desempenho do banco de dados e os custos de computação.
Os aplicativos que usam sem servidor devem ser configurados para lidar com erros de conexão e incluir lógica de repetição, pois a conexão a um banco de dados pausado gera um erro de conexão.
Outra diferença entre o modelo vCore padrão e sem servidor do Banco de Dados SQL do Azure é que, na opção sem servidor, 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 de até metade de um vCore e um máximo de 16 vCores.
A arquitetura serverless não é totalmente compatível com todos os recursos do Banco de Dados SQL do Azure, pois alguns deles exigem operação contínua de processos em segundo plano, como:
- Replicação geográfica
- Retenção de backup de longo prazo
- Um banco de dados de trabalho em trabalhos elásticos
- O banco de dados de sincronização na Sincronização de Dados SQL (a Sincronização de Dados é um serviço que replica dados entre um grupo de bancos de dados)
Observação
Atualmente, o Serverless é suportado apenas na camada General Purpose no modelo de compra do vCore.
Cópias de segurança
Um dos recursos mais importantes da oferta plataforma como serviço são os backups. Nesse caso, o sistema executa automaticamente backups sem nenhuma intervenção sua. O armazenamento com redundância geográfica 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 básicos e vCore têm uma retenção padrão de sete dias, e os administradores podem ajustar esse valor nos bancos de dados vCore. Você pode estender o tempo de retenção configurando a LTR (retenção de longo prazo), permitindo que você retenha backups por até 10 anos.
Para fornecer redundância, você também pode usar o armazenamento de blobs com redundância geográfica acessível por leitura. Esse armazenamento replicaria seus backups de banco de dados para uma região secundária de sua preferência. Ele também permitiria que você lesse 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 fazer isso.
Os Backups de Banco de Dados são feitos em um determinado agendamento:
- Completo – uma vez por semana
- Diferencial – a cada 12 horas
- Log– A cada 5 a 10 minutos, dependendo da atividade de log de transações
Esse cronograma de backup precisa atender às necessidades da maioria dos RPO/RTO (objetivos de tempo/ponto de recuperação), mas cada cliente deve avaliar se eles atendem aos requisitos de negócios.
Há várias opções disponíveis para restaurar um banco de dados. Devido à natureza da Plataforma como Serviço, você não pode restaurar manualmente um banco de dados usando métodos convencionais, como emitir o comando RESTORE DATABASET-SQL.
Independentemente de qual 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, tenha em mente que, dependendo da camada de serviço da plataforma, os tempos de restauração não são garantidos e podem flutuar. É recomendável que você teste 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 para o 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.
Observação
O backup somente cópia para o armazenamento de blobs do Azure está disponível para a Instância Gerenciada de SQL. O Banco de Dados SQL não dá suporte a esse recurso.
Para obter mais informações sobre backups automatizados, confira Backups automatizados – Banco de Dados SQL do Azure e Instância Gerenciada de 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. À medida que as transações são confirmadas no primário (e suas réplicas na mesma região), as transações são enviadas para os secundários a serem reproduzidos. 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 são legíveis e podem ser utilizados para descarregar as cargas de trabalho de leitura apenas, liberando recursos para cargas de trabalho transacionais no primário ou colocando os dados mais próximos 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
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 failover
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. O principal motivo para usar grupos de failover é que eles fornecem pontos de extremidade que podem ser utilizados para rotear o tráfego para a réplica apropriada. Em seguida, seu aplicativo pode se conectar após um failover sem alterações de cadeia de conexão.