Exercício – Grupos de ativação pós-falha automática distribuídos geograficamente com escalamento horizontal de leituras

Concluído

Ficou a conhecer a georreplicação e os grupos de ativação pós-falha automática na unidade anterior. Neste exercício, vai configurar grupos de ativação pós-falha automática para a base de dados SQL do Azure. Em seguida, vai iniciar uma ativação pós-falha e ver os resultados.

Grupos de ativação pós-falha automática no Azure SQL

Para configurar os grupos de ativação pós-falha automática para uma ou mais bases de dados e ver os resultados, precisará de concluir estes passos:

  1. Configurar o ambiente.
  2. Criar um servidor da Base de Dados SQL do Microsoft Azure vazio na região de ativação pós-falha.
  3. Criar um grupo de ativação pós-falha entre os servidores.
  4. Configurar a rede.
  5. Adicionar uma ou mais bases de dados ao grupo de ativação pós-falha.
  6. Configurar as aplicações de linha de comandos.
  7. Compreender as aplicações em execução.
  8. Iniciar uma ativação pós-falha.
  9. efetuar a reativação pós-falha.

Este exercício o orienta na configuração de grupos de failover automático para seu banco de dados AdventureWorks. Em seguida, vai utilizar uma aplicação de linha de comandos simples para compreender onde ocorrem as leituras e as escritas, e a importância da lógica de repetição nas aplicações. Por último, vai realizar um exercício divertido para determinar quantas réplicas de leitura estão associadas a uma base de dados do escalão Crítico para a Empresa, que também tem um grupo de ativação pós-falha automática.

Configurar o ambiente

  1. Copie o código seguinte para o Bloco de notas ou para outro editor de texto. Introduza as suas informações. Adicione a palavra-passe de autenticação do SQL. Em $drLocation, indique a região onde quer que esteja o grupo de ativação pós-falha. Idealmente, escolha uma região que esteja emparelhada com a região do servidor atual. Pode ver a lista de regiões emparelhadas. No mínimo, não pode ser a região onde está a base de dados original. Por último, adicione o endereço IP do computador local. Se precisar de determinar o endereço IP, abra o PowerShell no computador local e execute (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content.

    # Add your info
    $password = "password"
    $drLocation = "westus2"
    $ipAddress = "xx.xx.xx.xx"
    
  2. Execute o comando atualizado no Azure Cloud Shell (no lado direito desta página).

  3. Execute este script no Azure Cloud Shell para configurar as variáveis para os passos que se seguem:

    $admin = "cloudadmin"
    $resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like <rgn>Sandbox resource group name</rgn>
    $location = $resourceGroup.Location
    $resourceGroup = $resourceGroup.ResourceGroupName
    $database = "AdventureWorks"
    $server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
    $server = $server.ServerName
    $drServer = "$($server)-dr"
    $failoverGroup = "$($server)-fg"
    $firewallRule = "AllowMyIp"
    Write-Host "Variables Received"
    
  4. Crie um servidor da Base de Dados SQL do Microsoft Azure vazio na região de ativação pós-falha ao executar este script no Azure Cloud Shell:

    # Create a backup server in the failover region
    New-AzSqlServer -ResourceGroupName $resourceGroup `
        -ServerName $drServer `
        -Location $drLocation `
        -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential `
        -ArgumentList $admin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
    Write-Host "New Azure SQL Database logical server Created in different region"
    
  5. Crie um grupo de ativação pós-falha entre os servidores ao executar este script no Azure Cloud Shell:

    # Create a failover group between the servers
    New-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
        -ServerName $server `
        -PartnerServerName $drServer `
        -FailoverGroupName $failoverGroup 
    Write-Host "New auto-failover group created between the two Azure SQL Database logical servers"
    
  6. Configure a rede ao executar este script no Azure Cloud Shell:

    # Add a firewall rule that gives your VM access to the new server
    New-AzSqlServerFirewallRule -ResourceGroupName $resourceGroup `
        -ServerName $drServer `
        -FirewallRuleName $firewallRule `
        -StartIpAddress $ipAddress `
        -EndIpAddress $ipAddress;
    

    Para ilustrar os grupos de ativação pós-falha automática, esta configuração de rede é suficiente. É ligeiramente diferente dos passos que executaria num ambiente empresarial. Num ambiente empresarial, a máquina virtual que precisa de acesso seria provavelmente um conjunto de recursos que constituem algum tipo de aplicação. Se a base de dados efetuar a ativação pós-falha, poderá também querer efetuar a ativação pós-falha da aplicação, das VMs ou de outros recursos para uma nova região. Os dois conjuntos de recursos terão de ter acesso aos recursos, aos servidores e às bases de dados na outra região. Para tal, pode utilizar o peering de rede virtual, as ligações de rede virtual para rede virtual ou possivelmente outra ligação (como o Azure ExpressRoute). Depende do seu cenário.

  7. Adicione uma ou mais bases de dados ao grupo de ativação pós-falha ao executar este script no Azure Cloud Shell:

    # Add the database or databases to the failover group
    Get-AzSqlDatabase -ResourceGroupName $resourceGroup `
        -ServerName $server -DatabaseName $database | `
        Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $resourceGroup `
        -ServerName $server `
        -FailoverGroupName $failoverGroup
    Write-Host "AdventureWorks database added to the auto-failover group"
    

    Levará algum tempo para que esse script seja executado. Está a restaurar a base de dados na outra região, o que implica copiar os dados a partir da região original para a região de recuperação após desastre. Pode trabalhar nos passos na próxima secção e, em seguida, verificar se o script foi concluído.

Acabou de implementar e configurar um grupo de ativação pós-falha automática para a base de dados AdventureWorks.

Configurar as aplicações de linha de comandos

Nesta secção, vai utilizar duas cargas de trabalho de ostress para verificar a Updateability (se uma base de dados está num estado ReadWrite ou ReadOnly) dos servidores primários e dos servidores secundários no grupo de ativação pós-falha. Este cenário tem como objetivo simular uma aplicação para a qual tem cargas de trabalho de leitura e escrita.

  1. Abra duas janelas de Linhas de Comando separadas. Configure-as para que possa ver esta janela (o browser) e as duas da Linha de Comandos.

  2. Nas duas janelas da Linha de Comandos, aceda à pasta Disponibilidade, tal como fez nos exercícios anteriores. Por exemplo, poderá utilizar este comando:

    cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
    
  3. Vai utilizar a primeira janela da Linha de Comandos para verificar o estado do servidor primário no grupo de ativação pós-falha que criou. Execute este comando com o seu nome do servidor e a palavra-passe:

    .\ostress.exe -S"<server-name>-fg.database.windows.net" -Q"SELECT DATABASEPROPERTYEX(DB_NAME(),'Updateability')" -U"cloudadmin" -d"AdventureWorks" -P"password" -n1 -r5000 -oprimary
    

    Nota

    Com os grupos de ativação pós-falha automática, liga-se ao nome do grupo de ativação pós-falha, que é a abstração da base de dados.

  4. Vai utilizar a segunda janela da Linha de Comandos para verificar o estado do servidor secundário no grupo de ativação pós-falha criado. Execute este comando com o seu nome do servidor e a palavra-passe:

    ostress.exe -S"<server-name>-fg.secondary.database.windows.net" -Q"SELECT DATABASEPROPERTYEX(DB_NAME(),'Updateability')" -U"cloudadmin" -d"AdventureWorks" -P"password" -n1 -r5000 -osecondary
    

O resultado do primeiro comando deve ser READ_WRITE, porque ele verifica o servidor do grupo de failover primário e você não iniciou nenhum failover.

O resultado do segundo comando deve ser READ_ONLY, porque ele verifica a recuperação de desastres ou o servidor secundário que você configurou. Só deverá ser capaz de escrever a partir de um dos servidores num determinado momento.

Nos próximos passos, verá o que acontece aos dois servidores quando ocorre uma ativação pós-falha.

Iniciar uma ativação pós-falha e ver os resultados

  1. Use o terminal do Azure Cloud Shell no lado direito desta página para verificar o status do servidor secundário:

    (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
        -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole
    

    O resultado indicará se o servidor secundário do grupo de ativação pós-falha automática está a ser utilizado como base de dados primária ou secundária.

  2. Agora, pode ver o que acontece quando ocorre uma ativação pós-falha. Inicie uma ativação pós-falha manual. Para isso, introduza estas linhas de comando do Azure PowerShell no terminal do Azure Cloud Shell:

    Switch-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
     -ServerName $drServer -FailoverGroupName $failoverGroup
    

    Quando o failover ocorre, você pode notar que as conexões são interrompidas por um momento, mas como o aplicativo continua tentando, o aplicativo não falha completamente. Quando a ativação pós-falha terminar, deverá reparar que os resultados READ_WRITE e READ_ONLY são retomados e não são alterados.

    Um dos benefícios dos grupos de ativação pós-falha automática na Base de Dados SQL do Azure e no Azure SQL Managed Instance é que não tem de atualizar as cadeias de ligação após uma ativação pós-falha. Continua a ligar-se à base de dados primária (<failover-group>.database.windows.net) para as cargas de trabalho de escrita e à secundária (<failover-group>.secondary.database.windows.net) para as cargas de trabalho de leitura. O Azure encarrega-se do encaminhamento para a base de dados adequada na região/servidor correspondente.

  3. Verifique o estado do servidor secundário ao executar este script no Azure Cloud Shell:

    (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
        -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole
    

    Este servidor deverá agora ser a função primária.

  4. Efetue a reativação pós-falha ao executar este script no Azure Cloud Shell:

    Switch-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
     -ServerName $server -FailoverGroupName $failoverGroup
    
  5. Por fim, pode verificar novamente o estado do servidor secundário. Execute este script no Azure Cloud Shell:

    (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
        -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole
    
  6. Pode agora fechar as duas janelas da Linha de Comandos e maximizar a janela do browser do Microsoft Learn.

Neste exercício, aprendeu a implementar e a configurar grupos de ativação pós-falha automática. Também ficou a saber o que isso significa do pontos de vista da aplicação. Os grupos de ativação pós-falha automática são apenas uma maneira de ir mais longe na disponibilidade e escalamento horizontal de leituras no Azure SQL.