Desbloqueando o Azure: como construir uma infraestrutura de banco de dados SQL altamente flexível

Não é segredo que nos últimos anos a Infraestrutura como Serviço e a Plataforma como Serviço se tornaram cada vez mais difundidas em vários projetos devido às suas capacidades, particularmente eficiência de recursos e flexibilidade. Como resultado, a Microsoft gastou muito tempo e esforço criando um ambiente amigável no qual o SQL pudesse ser usado.

A equipe do Social Discovery Group usa uma variedade de bancos de dados, incluindo SQL, para potencializar nossos produtos. Com um portfólio de mais de 40 serviços globais que ajudam a conhecer e conectar-se em todo o mundo, nossa base de usuários inclui mais de 250 milhões de pessoas em todo o mundo. Para garantir a confiabilidade de nossos produtos para os usuários, mantemos parte da infraestrutura chave na nuvem. Isso ajuda a aumentar sua resiliência, segurança e flexibilidade.

Temos bastante experiência na implantação de bancos de dados de servidores e serviços em diversas plataformas, incluindo clusters Kubernetes. No entanto, enfrentámos a necessidade de tornar uma parte da infraestrutura de bases de dados SQL relacionada na nuvem Azure tão flexível, eficiente e fiável quanto possível. Existem 3 maneiras de usar SQL na nuvem Microsoft Azure:

• Banco de dados SQL do Azure
• Instância Gerenciada de SQL do Azure
• SQL Server em máquinas virtuais do Azure

Após a pesquisa, decidimos usar bancos de dados SQL do Azure. Só para esclarecer quem nunca ouviu falar dos chamados bancos de dados SQL do Azure, eles são bancos de dados em nuvem gerenciados fornecidos como parte do Microsoft Azure.

Destaquei os seguintes benefícios:

• Não há necessidade de se preocupar com atualizações ou suporte em fim de vida;
• Fácil configuração e implantação;
• Velocidade de implantação (e, portanto, desenvolvimento) e escalabilidade;
• Alta disponibilidade;
• Tolerância ao erro;
• Facilidade de backup;
• Otimização de custos;
• Um sistema integrado de monitoramento do Microsoft Azure.

Agora vamos falar passo a passo e dar uma olhada no processo de implantação e criação de um banco de dados. Isso pode ser feito usando um script Power Shell ou a CLI do Azure, mas para maior clareza, analiso o processo usando a interface gráfica do portal. Para fazer isso, vá para Azure SQL, clique em ‘Criar’ e selecione ‘Bancos de Dados SQL’.

Especificamos o grupo de recursos, selecionamos se existe um servidor existente ou criamos um novo (indicando o nome e os dados do administrador) e criamos um nome para o banco de dados. Eu recomendo escolher pacotes agrupados baseados em DTU (unidade de transação de banco de dados) com uma combinação equilibrada de recursos de computação e armazenamento para nossas cargas de trabalho comuns.

Existem também algumas guias de configurações: Rede, Segurança, Configurações adicionais e Tags; para uma configuração padrão mínima, estes podem ser deixados inalterados por padrão. Então esperamos que o banco de dados seja criado. Isso completa a configuração mínima e a base está pronta.

O tamanho dos recursos do banco de dados pode ser alterado facilmente, literalmente com um clique, e em caso de recursos insuficientes, podemos definir os parâmetros que precisamos em termos de tamanho e desempenho.

Depois você pode se conectar ao seu banco de dados da maneira que preferir externamente, sem esquecer de adicionar seu endereço IP ou sub-rede, ou de permitir todas as conexões no firewall do servidor onde este banco de dados está hospedado.

É conveniente conectar-se e gerenciar ainda mais por meio do SQL Server Management Studio (SSMS), mas também é possível fazer isso por meio de outras ferramentas e do próprio portal do Azure.

Além de um ponto de conexão público, você também pode criar um privado adicionando um servidor à sub-rede necessária e configurando zonas DNS privadas.

Falando em tolerância a falhas, vemos aqui uma implementação de failover muito conveniente e intuitiva, um grupo de servidores de proteção baseados em diferentes regiões.

No Azure, é possível adicionar e remover bases de dados em servidores num grupo de failover, failover forçado e modo de failover automático.

Você pode ver isso na imagem abaixo. Vamos criar um nome para o grupo de failover e colocar o servidor em failover. A sincronização dos bancos de dados especificados começará automaticamente. O segundo servidor estará no modo somente leitura. No caso de uma falha, o tráfego é automaticamente comutado para a segunda região e os servidores primário e secundário trocam automaticamente de lugar.

Mas o failover não ajudará se houver um problema no nível dos dados nos próprios bancos de dados. Com certeza, neste caso, você precisa criar backups. É possível configurar backups tanto dentro do portal como através de ferramentas de terceiros ou, por exemplo, Azure DevOps (no pipeline você pode usar a tarefa SqlAzureDacpacDeployment + AzureFileCopy). Dentro do portal, os backups são configurados na aba Backups e as políticas de armazenamento necessárias são definidas.

Se você preferir usar ferramentas de backup de terceiros, recomendo considerar ferramentas de pacote Azure DevOps ou SQL.

O processo de recuperação no próprio portal não é muito conveniente na minha opinião. A primeira coisa que você nota é o longo tempo de recuperação de bancos de dados de teste simples. Por exemplo, levei mais de meia hora para restaurar um banco de dados de tamanho básico de 30 MB do backup de ontem! Após entrar em contato com o suporte do Microsoft Azure, fui aconselhado a usar scripts do PowerShell para recuperação e notificado que o tamanho do banco de dados deveria ser pelo menos S3 para o processo de recuperação, e posteriormente o tamanho poderia ser reduzido. Abaixo vou apresentar alguns dos meus scripts e desenvolvimentos sobre este assunto, eles podem ser melhorados e aprimorados, mas tenho certeza que muitos de vocês podem considerá-los úteis.

Vou te levar passo a passo:

1. Caso você não tenha o PowerShell ISE instalado no Windows, baixe-o aqui: https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. Em seguida, você precisa instalar o módulo Azure: Install-Module Az
3. Após instalar o módulo AZ, importe o módulo AZ: Import-Module Az
4. Depois de importado, você pode conectar-se à sua conta do Azure: Connect-AzAccount. Um pop-up aparecerá para fazer login em sua conta do Azure e você estará conectado
5. Execute o próprio script do PowerShell.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 – Este código inicia uma restauração de banco de dados com um nome diferente. Se o nome original do banco de dados restaurado for "dbforscript", o nome do banco de dados restaurado será dbforscript_new. O banco de dados restaurado será o SLO versão S3 ou superior, que é a forma recomendada de realizar esta ação, a variável para isso é $PITRSLO = "S3", você pode usar S3 ou superior. Depois disso iremos redefinir o nível do SLO para o original, isto é apenas para recuperação.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - Este código removerá o banco de dados de origem do grupo de failover: banco de dados de origem: dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - Este código removerá o banco de dados réplica do servidor onde ele está localizado: dbforscript no servidor test-serv2.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - Este código irá renomear o banco de dados original para um nome diferente: após a renomeação, dbforscript será dbforscript_old.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - Este código irá renomear o banco de dados restaurado para o nome do banco de dados original, renomeando dbforscript_new para dbforscript.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - Este código retornará o nível de SLO do seu banco de dados ao valor S0 anterior (original). se seu banco de dados for básico, você pode atualizar de S0 para básico posteriormente no portal.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - O último código adiciona o banco de dados restaurado ao grupo de failover, que já possui o nome original (já que alteramos no código anterior).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Você pode considerar adicionar o parâmetro - ErrorAction Stop após o comando. Isso impedirá que os comandos a seguir sejam executados em caso de erro e não haverá bola de neve.

Além disso, você pode adicionar Get-Date no início e no final do script para calcular o tempo de execução. No meu caso, um banco de dados de cerca de 3,3 GB foi restaurado por esse script em menos de 6 minutos.

Se desejar, você certamente pode otimizar o script, adicioná-lo via Azure DevOps, reduzir o número de variáveis ou codificar algo, mas tentei descrevê-lo com o máximo de detalhes possível e de uma forma que todos possam entender.

O monitoramento de bancos de dados no Azure e a capacidade de integração com diversos sistemas, como o Datadog, merecem atenção especial. O monitoramento é bastante conveniente, mas não sem nuances (no momento em que este artigo foi escrito, por exemplo, os usuários somente leitura só podiam ver o monitoramento de um banco de dados, não de uma só vez... bem, aqui estão as sombras).

Concluindo, nossa equipe otimizou despesas com sucesso, ao mesmo tempo em que abordou preocupações relacionadas a atualizações e descontinuação de suporte. Alcançamos melhorias em desempenho, resiliência, velocidade de desenvolvimento e flexibilidade. Além disso, a implementação de scripts melhorou notavelmente a nossa capacidade de recuperação rápida quando necessário.

Escrito por Pavel Shapurau, engenheiro-chefe de DevOps do Social Discovery Group.