Oefening: bedrijfskritieke hoge beschikbaarheidbaarheid

  • 10 minuten

In deze oefening werkt u uw database bij naar de laag Bedrijfskritiek. U ontdekt hoe deze actie leesreplica's en betere prestaties biedt.

U gebruikt het hulpprogramma ostress, dat u in de vorige oefening hebt gebruikt om een workload te maken. Vervolgens start u een failover met behulp van de module Azure PowerShell in Azure Cloud Shell. Ten slotte bekijkt u het effect van de failover op de ostress-workload.

Basic hoge beschikbaarheid in de Azure SQL-servicelaag Bedrijfskritiek

In deze oefening voert u de volgende stappen uit:

  1. Implementeer de database uit de vorige oefening in de laag Bedrijfskritiek.
  2. Voer de ostress-workload uit.
  3. Gebruik PowerShell om een failover te initiëren.
  4. Geef de resultaten in ostress weer.
  5. Maak verbinding met een leesbare secundaire replica.

Implementeer dezelfde database in de laag Bedrijfskritiek

In een vorige module hebt u geleerd hoe u een database kunt schalen met behulp van T-SQL. Het doel van deze oefening is om de database die u in de vorige oefening hebt gebruikt, bij te werken van Algemeen gebruik naar Bedrijfskritiek. U gebruikt Azure Cloud Shell om de database te upgraden. Omdat er een limiet is voor de failoverfrequentie, gebruikt u dezelfde voorbeelddatabase, maar geeft u het de naam AdventureWorks-bc.

  1. Voer in de Azure Cloud Shell-terminal aan de rechterkant van de pagina het volgende PowerShell-script uit om uw omgeving te configureren:

    $resourceGroup = "<rgn>Sandbox resource group name</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

  2. Voer deze opdracht uit om een database te maken in de servicelaag Bedrijfskritiek:

    az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false

    Het duurt even voordat deze opdracht is voltooid. Terwijl de opdracht wordt uitgevoerd, kunt u enkele van de gebruikte parameters bekijken:

    • family: Met deze parameter geeft u de generatie van de hardware op. We hebben Gen5 gebruikt voor consistentie met de vorige oefening.

    • capacity: Met deze parameter geeft u het aantal DTU's of vCores op. We hebben 2 vCores gebruikt voor consistentie met de vorige oefening.

    • sample-name: Om consistent te zijn met de vorige oefening, hebben we het AdventureWorksLT databasevoorbeeld gebruikt.

    • edition: Deze parameternaam is een beetje misleidend. In werkelijkheid verwijst de parameter naar de servicelaag, wat niet hetzelfde is als de editie die wordt gebruikt in SQL Server.

    • read-scale: Deze optie is niet standaard ingeschakeld, maar er zijn geen extra kosten aan gekoppeld. Als u deze optie inschakelt, schakelt u een van de secundaire replica's in om te worden gebruikt als een leesbare secundaire.

    • zone-redundant: Deze parameter is standaard ingesteld op false. U kunt de parameter instellen op waar als u een implementatie voor meervoudige beschikbaarheidszones wilt, zonder extra kosten. Meer informatie over beschikbaarheidszones krijgt u in de volgende les.

      Notitie

      Beschikbaarheidszones zijn slechts beschikbaar in bepaalde regio's. Ze zijn momenteel niet beschikbaar voor Azure SQL Managed Instance.

  3. Na het maken van de database wordt gedetailleerde informatie weergegeven over de updates in de Azure Cloud Shell-uitvoer. U ziet twee hoofdcategorieën (hoewel u ook indicatoren onder verschillende andere eigenschappen ziet):

    • currentServiceObjectiveName: moet zijn BC_Gen5_2. BC staat voor Bedrijfskritiek.
    • currentSku:
      • name: moet zijn BC_Gen5.
      • tier: moet zijn BusinessCritical.

  4. U kunt de servicelaag ook controleren door naar uw database te gaan in Azure Portal. Ga naar het tabblad Overzicht en vervolgens naar Prijscategorie.

    Tip

    Er zijn veel verschillende manieren om deze updates weer te geven. U kunt bijvoorbeeld SSMS gebruiken. Als u met de rechtermuisknop op uw database klikt en Eigenschappen>SLO configureren selecteert, kunt u de wijzigingen bekijken.

De ostress-workload uitvoeren

Net zoals in de vorige oefening gebruikt u ostress om herhaaldelijk een query op uw Azure SQL-database uit te voeren.

  1. Als u de opdrachtprompt hebt gesloten die u in de vorige oefening hebt gebruikt, opent u een nieuw opdrachtpromptvenster op uw lokale computer. Gebruik cd om naar de map te gaan in de opslagplaats die u eerder hebt gekloond of gedownload en die de beschikbaarheidsmodule bevat. U kunt bijvoorbeeld deze opdracht gebruiken:

    cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability

    De ostress-workload maakt verbinding en voert een eenvoudige query 50.000 keer uit.

  2. Gebruik het volgende ostress-script om de workload uit te voeren. Vervang serverName door de naam van uw logische Azure SQL Database-server. Vervang password door uw wachtwoord. Deze opdracht verschilt enigszins van de opdracht in de vorige oefening. De databasenaam is nu AdventureWorks-bc.

    .\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000

    Als uw workload correct wordt uitgevoerd, zou u het resultaat van de query 847 herhaaldelijk moeten zien in het opdrachtpromptvenster.

    Als u de uitvoering van de ostress-workload wilt stoppen voordat deze is voltooid, kunt u in de terminal CTRL + C selecteren.

    U kunt de workload opnieuw starten door de opdracht opnieuw uit te voeren.

Initieer vervolgens een failover en bekijk de resultaten

  1. Configureer de vensters zodanig dat u deze browser en het opdrachtpromptvenster tegelijkertijd kunt zien.

  2. Voer de volgende code uit in de Azure Cloud Shell-terminal. Deze opdracht is dezelfde als de opdracht die u in de vorige oefening hebt gebruikt.

    # create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

  3. Terwijl deze opdracht wordt uitgevoerd, let u op de wijzigingen die in de terminal worden weergegeven. Tijdens de failover hebt u geen toegang tot de database. Dit duurt maar even. Nadat de verbinding is verbroken, moet u na ongeveer vijf seconden opnieuw verbonden zijn. Deze failover is ruim zes keer sneller dan de failover in de laag Algemeen gebruik.

    Houd er rekening mee dat databases of beheerde exemplaren in de servicelaag Bedrijfskritiek in feite achter de schermen een AlwaysOn-beschikbaarheidsgroep hebben geïmplementeerd, dus wanneer u een failover uitvoert, is alles wat er gebeurt een wijziging in de back-end wanneer Azure u omleidt naar een van de secundaire databases. Dit verklaart waarom de failover zo veel sneller is dan in Algemeen gebruik.

Verbinding maken met de alleen-lezenreplica

Aangezien u de parameter read-scale hebt ingeschakeld, kunt u een van de secundaire replica's gebruiken voor alleen-lezenworkloads. Om toegang te krijgen tot de alleen-lezenreplica in toepassingen, hoeft u alleen deze parameter toe te voegen aan de verbindingsreeks voor een database:

ApplicationIntent=ReadOnly;

  1. Maak een nieuwe queryverbinding in SSMS. (Selecteer Bestand>Nieuw>Query voor database-engine.)

    Screenshot that shows how to create a query connection.

  2. Gebruik de configuratie die u hebt gebruikt om verbinding te maken met uw logische Azure SQL Database-Server in het dialoogvenster Verbinding maken met server. (Dat wil gezegd, gebruik SQL Server-verificatie.) Selecteer Opties.

    Screenshot that shows the Connect to Server dialog box.

  3. Selecteer Verbindingseigenschappen en vervolgens Alles opnieuw instellen. Selecteer onder Verbinding maken met database de optie Bladeren op server en selecteer vervolgens de database AdventureWorks-bc. Selecteer OK.

  4. Selecteer Extra verbindingsparameters en plak het volgende in het tekstvak. Selecteer Verbinding maken.

    ApplicationIntent=ReadOnly;

    Met SSMS moet u de server en de database opgeven waarmee u een verbinding voor alleen-lezen wilt maken. Dit is nodig omdat er op een server meerdere databases zijn die verschillende mogelijkheden hebben voor leesbare secundaire zones.

  5. Om dit te testen, voert u de volgende query uit op de nieuwe query voor de database-engine. Bekijk de resultaten. Verwachtte u deze resultaten?

    SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')

    Screenshot that shows the read-only response.

  6. U kunt ervoor kiezen om opnieuw verbinding te maken en de aanvullende verbindingsparameters bij te werken. (Vervangen ReadOnly door ReadWrite.) Controleer of u toegang hebt tot de primaire replica voor lezen/schrijven. ReadWrite is de standaardinstelling. Als u niets selecteert, ziet u dit:

    Screenshot that shows the read/write response.