Prestaties van sharded Azure SQL Database met meerdere tenant in een SaaS-app met meerdere tenants bewaken en beheren

Artikel
06/05/2023

Van toepassing op: Azure SQL Database

In deze zelfstudie worden verschillende scenario's voor prestatiebeheer in SaaS-toepassingen besproken. Het gebruik van een load-generator voor het simuleren van activiteit in sharded databases met meerdere tenants, de ingebouwde bewakings- en waarschuwingsfuncties van Azure SQL Database worden gedemonstreerd.

De Wingtip Tickets SaaS-database-app met meerdere tenants maakt gebruik van een sharded gegevensmodel, waarbij locatiegegevens (tenant) worden verspreid op tenant-ID over (mogelijk) meerdere databases. Net als bij veel andere SaaS-toepassingen, is het verwachte tenantworkloadpatroon onvoorspelbaar en sporadisch. Met andere woorden, kaartverkoop kan op ieder moment plaatsvinden. Om gebruik te maken van dit typische gebruikspatroon voor databases, kunnen databases omhoog en omlaag worden geschaald om de kosten van een oplossing te optimaliseren. Bij dit type patroon is het belangrijk om het gebruik van databaseresources te controleren om ervoor te zorgen dat loads goed over mogelijk meerdere databases zijn verdeeld. Ook moet u ervoor zorgen dat individuele databases voldoende resources hebben en hun eDTU-limieten niet overschrijden. In deze zelfstudie worden manieren toegelicht om databases te controleren en beheren. Ook wordt uitgelegd hoe u corrigerende maatregelen kunt nemen als reactie op wisselingen in de workload.

In deze zelfstudie leert u het volgende:

Gebruik op de sharded databases met meerdere tenants simuleren door het uitvoeren van een geleverde load-generator
De database bewaken terwijl deze reageert op de toegenomen belasting
De database omhoog schalen als reactie op de verhoogde databaseload
Een tenant inrichten in een database met één tenant

U kunt deze zelfstudie alleen voltooien als aan de volgende vereisten wordt voldaan:

De Wingtip Tickets SaaS Multi-tenant Database-app is geïmplementeerd. Zie De Wingtip Tickets SaaS Multi-tenant Database-toepassing implementeren en verkennen om deze binnen vijf minuten te implementeren
Azure PowerShell is geïnstalleerd. Zie Aan de slag met Azure PowerShell voor meer informatie.

Kennismaking met prestatiebeheerpatronen voor SaaS

Het beheren van de databaseprestaties bestaat uit het verzamelen en analyseren van prestatiegegevens en het reageren op deze gegevens door parameters aan te passen om een acceptabele reactietijd voor de toepassing te behouden.

Strategieën voor prestatiebeheer

Om te voorkomen dat u de prestaties handmatig moet bewaken, is het meest effectief om waarschuwingen in te stellen die worden geactiveerd wanneer databases buiten normale bereiken vallen.
Het eDTU-niveau kan omhoog of omlaag worden geschaald om te reageren op fluctuaties op de korte termijn in de rekenkracht van een database. Als deze fluctuatie regelmatig of op voorspelbare momenten optreedt, kan het schalen van de database op automatisch worden ingesteld. U kunt bijvoorbeeld omlaag schalen wanneer de workload licht is, zoals 's nachts of tijdens het weekend.
U kunt ook afzonderlijke tenants naar andere databases verplaatsen bij fluctuaties op de langere termijn of wijzigingen in de tenants.
Afzonderlijke tenants kunnen uit een database worden gehaald. Hieraan kan een afzonderlijke rekenkracht worden toegewezen als reactie op verhogingen op de korte termijn in de load van afzonderlijke tenants. Wanneer de load is verlaagd, kan de tenant naar de database met meerdere tenants worden teruggezet. Als dit vooraf bekend is, kunnen tenants uit voorzorg worden verplaatst om ervoor te zorgen dat ze altijd over de benodigde resources beschikken en om gevolgen voor de andere tenants in de database met meerdere tenants te voorkomen. Als het om een voorspelbare vereiste gaat, zoals bij een locatie die met een toename in kaartverkoop te maken krijgt voor een populair evenement, kan dit beheergedrag in de toepassing worden geïntegreerd.

Azure Portal biedt ingebouwde functionaliteit voor bewaking en waarschuwingen voor de meeste resources. Voor SQL Database zijn bewaking en waarschuwingen beschikbaar voor databases. De ingebouwde functionaliteit voor bewaking en waarschuwingen is resource-gebonden. Daardoor is het handig voor een klein aantal resources, maar niet handig als u met veel resources werkt.

Voor scenario's met grote volumes, waar u met veel resources werkt, kunnen Azure Monitor-logboeken worden gebruikt. Dit is een afzonderlijke Azure-service die analyse van verzonden logboeken biedt in een Log Analytics-werkruimte. Azure Monitor-logboeken kunnen telemetriegegevens verzamelen van veel services en worden gebruikt om waarschuwingen op te vragen en in te stellen.

De broncode en scripts van de Wingtip Tickets SaaS-databasetoepassing downloaden

De Wingtip Tickets SaaS-multitenantdatabasescripts en broncode van de toepassing zijn beschikbaar in de GitHub-opslagplaats WingtipTicketsSaaS-MultitenantDB. Bekijk de algemene richtlijnen voor stappen voor het downloaden en het deblokkeren van de Wingtip Tickets-SaaS-scripts.

Extra tenants inrichten

U hebt voor deze zelfstudie meerdere tenants in een sharded database met meerdere tenants nodig om een goed inzicht te krijgen in de werking van het bewaken en beheren van prestaties op schaal.

Als u al een batch tenants hebt ingericht in een eerdere zelfstudie, slaat u het gedeelte Gebruik simuleren op alle tenantdatabases over.

Open in PowerShell ISE ...\Learning Modules\Performance Monitoring and Management\Demo-PerformanceMonitoringAndManagement.ps1. Houd dit script open; u gaat verschillende scenario's uitvoeren tijdens deze zelfstudie.
Stel het volgende in: $DemoScenario = 1, Batch met tenants inrichten
Druk op F5 om het script uit te voeren.

Het script implementeert 17 tenants in een paar minuten in de databases met meerdere tenants.

Met het script New-TenantBatch maakt u nieuwe tenants met unieke tenantsleutels in de sharded database met meerdere tenants en initialiseert u deze met de tenantnaam en het locatietype. Dit komt overeen met de manier waarop de app een nieuwe tenant inricht.

Gebruik simuleren op alle tenantdatabases

Het script Demo-PerformanceMonitoringAndManagement.ps1 is bedoeld voor het simuleren van een workload die wordt uitgevoerd op alle databases met meerdere tenants. De load wordt gegenereerd met behulp van een van de beschikbare load-scenario's:

Demo	Scenario
2	Load genereren met normale intensiteit (ongeveer 30 DTU's)
3	Load genereren met langere pieken per tenant
4	Load genereren met meer DTU-bursts per tenant (ongeveer 70 DTU's)
5	Een load met hoge intensiteit genereren (ongeveer 90 DTU) op één tenant plus een load met een normale intensiteit op alle andere tenants

De load-generator past een synthetische load alleen voor CPU toe op elke tenantdatabase. De generator start voor elke tenantdatabase een taak, die periodiek een opgeslagen procedure aanroept die de load genereert. De load-niveaus (in DTU's), duur en intervallen zijn verschillend voor alle databases. Dit simuleert onvoorspelbare tenantactiviteit.

Open in PowerShell ISE ...\Learning Modules\Performance Monitoring and Management\Demo-PerformanceMonitoringAndManagement.ps1. Houd dit script open; u gaat verschillende scenario's uitvoeren tijdens deze zelfstudie.
Stel het volgende in: $DemoScenario = 2, Load van normale intensiteit genereren
Druk op F5 om een load toe te passen op al uw tenants.

Wingtip Tickets SaaS-database met meerdere tenants is een SaaS-app; de werkelijke workload van een SaaS-app is meestal sporadisch en onvoorspelbaar. Om dit te simuleren, produceert de load-generator een willekeurige workload die over alle tenants wordt verdeeld. Aangezien het een paar minuten duurt voordat er een load-patroon ontstaat, moet u de load-generator 3-5 minuten uitvoeren voordat u de workload in de volgende secties gaat volgen.

Belangrijk

De load-generator wordt uitgevoerd als een reeks taken in een nieuw PowerShell-venster. Als u de sessie sluit, stopt de loadgenerator. De load-generator bevindt zich in een status die taken aanroept waarbij de load wordt gegenereerd voor eventuele nieuwe tenants die zijn ingericht nadat de generator is gestart. Gebruik Ctrl-C om het aanroepen van nieuwe taken te stoppen en het script af te sluiten. De load-generator blijft actief, maar alleen op bestaande tenants.

Gebruik van resources bewaken met Azure Portal

Als u het resourcegebruik wilt controleren dat het gevolg is van de belasting die wordt toegepast, opent u de portal naar de database met meerdere tenants, tenants1die de tenants bevat:

Open Azure Portal en blader naar de server tenants1-mt-<USER>.
Schuif omlaag en zoek databases en selecteer tenants1. Deze sharded database met meerdere tenants bevat alle tenants die tot nu toe zijn gemaakt.

A screenshot of the Azure portal showing the database monitoring chart.

Bekijk de DTU-grafiek.

Prestatiewaarschuwingen voor de database instellen

Stel een waarschuwing in voor de database die wordt geactiveerd bij een gebruik van >75%:

Open de tenants1 database (op de tenants1-mt-<USER> server) in Azure Portal.
Selecteer Waarschuwingsregels en selecteer vervolgens + Waarschuwing toevoegen:
Geef een naam op, bijvoorbeeld hoog DTU.
Stel de volgende waarden in:
- Meetwaarde = DTU-percentage
- Voorwaarde = groter dan
- Drempel = 75.
- Periode = In de afgelopen 30 minuten
Voeg een e-mailadres toe aan het vak Extra e-mailadressen van de beheerder en selecteer OK.

Een zwaar belaste database omhoog schalen

Als het loadniveau voor een database in een dergelijke mate toeneemt dat de database volledig wordt gebruikt en 100% eDTU-gebruik wordt bereikt, worden de prestaties van databases beïnvloed, met mogelijk tragere query-reactietijden tot gevolg.

Overweeg op korte termijn om de database omhoog te schalen om aanvullende resources te voorzien, of om tenants te verwijderen uit de database met meerdere tenants (door ze te verwijderen uit de database met meerdere tenants naar een zelfstandige database).

Op de langere termijn kunt u query's of indexgebruik optimaliseren voor betere databaseprestaties. Afhankelijk van de gevoeligheid van de toepassing voor prestatieproblemen is het raadzaam om een database omhoog te schalen voordat het 100% DTU-gebruik bereikt. Gebruik een waarschuwing zodat u tijdig wordt gewaarschuwd.

U kunt een zwaar belaste database simuleren door de load die de generator produceert, te verhogen. Doordat de tenants vaker en langer maximaal worden gebruikt, wordt de load voor de database met meerdere tenants verhoogd zonder dat de vereisten van de afzonderlijke tenants worden gewijzigd. U kunt de database eenvoudig opschalen in de portal of vanuit PowerShell. In deze oefening wordt de portal gebruikt.

Stel $DemoScenario = 3 in, Genereer belasting met langere en frequentere bursts per database om de intensiteit van de cumulatieve belasting voor de database te verhogen zonder de piekbelasting te wijzigen die voor elke tenant is vereist.
Druk op F5 om een load toe te passen op al uw tenantdatabases.
Ga naar de tenants1 database in Azure Portal.

Controleer het verhoogde DTU-verbruik voor de database in de bovenste grafiek. Het duurt enkele minuten voordat de nieuwe, hogere load wordt geactiveerd, maar de database moet vrij snel maximaal gebruik bereiken. Zodra de load een nieuw patroon vormt, wordt de database snel overbelast.

Als u de database wilt omhoog schalen, selecteert u Prijscategorie (DTU's schalen) op de instellingenpagina.
Stel de DTU in op 100.
Selecteer Toepassen om de aanvraag in te dienen om de database te schalen.

Ga terug naar het tenants1>Overzicht om de bewakingsgrafieken weer te geven. Bewaak het effect van het leveren van meer resources aan de database (hoewel met weinig tenants en een willekeurige belasting het niet altijd gemakkelijk is om overtuigend te zien totdat u enige tijd wordt uitgevoerd). Houd er rekening mee dat 100% bij de bovenste grafiek nu staat voor 100 DTU's, terwijl voor de onderste grafiek 100% nog steeds 50 DTU's is.

Databases blijven gedurende het proces online en volledig beschikbaar. Om verbroken verbindingen opnieuw te proberen, moet altijd een toepassingscode worden geschreven zodat er opnieuw verbinding wordt gemaakt met de database.

Een nieuwe tenant in de eigen database inrichten

Met het sharded model voor meerdere tenants kunt u kiezen of u een nieuwe tenant wilt inrichten in een database met meerdere tenants naast andere tenants, of om de tenant in te richten in een eigen database. Door een tenant in te richten in een eigen database, profiteert deze van de isolatie die inherent is aan de afzonderlijke database, zodat u de prestaties van die tenant onafhankelijk van anderen kunt beheren, die tenant onafhankelijk van anderen kunt herstellen, enzovoort. U kunt er bijvoorbeeld voor kiezen om gratis proefversies of gewone klanten in een database met meerdere tenants en premium-klanten in afzonderlijke databases te plaatsen. Als er geïsoleerde database voor één tenant worden gemaakt, kunnen ze gezamenlijk worden beheerd in een elastische pool om resourcekosten te optimaliseren.

Als u al een nieuwe tenant in een eigen database hebt ingericht, kunt u de volgende stappen overslaan.

Open in de PowerShell ISE...\Learning Modules\ProvisionTenants\Demo-ProvisionTenants.ps1.
Wijzigen $TenantName = "Salix Salsa" en $VenueType = "dance".
Stel $Scenario = 2een tenant in, richt een tenant in een nieuwe database met één tenant in.
Druk op F5 om het script uit te voeren.

Het script richt deze tenant in in een afzonderlijke database, registreert de database en de tenant bij de catalogus en opent vervolgens de pagina Gebeurtenissen van de tenant in de browser. Vernieuw de pagina Event Hub en u ziet dat "Salix Salsa" is toegevoegd als locatie.

Notitie

Herstellen van databases met meerdere tenants naar één tenant is niet mogelijk.

Prestaties van een afzonderlijke database beheren

Als één tenant in een database met meerdere tenants voortdurend zwaar belast wordt, is het mogelijk dat het de resources van de databases domineert en dat andere tenants in dezelfde database hinder ondervinden; Als de activiteit mogelijk nog enige tijd voortduurt, kan de tenant tijdelijk uit de database worden verplaatst, naar zijn eigen database voor één tenant. Op deze manier kan de tenant de extra resources bevatten die nodig zijn en deze volledig isoleren van de andere tenants.

Deze oefening simuleert het effect van een hoge load voor Salix Salsa wanneer kaartjes voor een populair evenement in de verkoop gaan.

Open het ...\Demo-PerformanceMonitoringAndManagement.ps1 script.
Stel $DemoScenario = 5, Genereer een normale belasting plus een hoge belasting voor één tenant (ongeveer 90 DTU).
Instellen $SingleTenantName = Salix Salsa.
Voer het script uit met F5.

Ga naar Azure Portal en navigeer naar salixsalsa>Overview om de bewakingsgrafieken weer te geven.

Andere patronen voor prestatiebeheer

Selfservice omhoog schalen voor tenants

Omdat schalen een taak is die eenvoudig via de Management-API kan worden aangeroepen, kunt u gemakkelijk de mogelijkheid om tenantdatabases te schalen inbouwen in uw tenantgerichte toepassing en deze als een functie van uw SaaS-service aanbieden. Laat tenants bijvoorbeeld zelf omhoog en omlaag schalen beheren, mogelijk gekoppeld aan hun facturering.

Een database omhoog en omlaag schalen volgens een schema om aan gebruikspatronen te voldoen

Wanneer het cumulatieve tenantgebruik een voorspelbaar patroon volgt, kunt u Azure Automation gebruiken om een database volgens een schema omhoog en omlaag te schalen. Schaal een database bijvoorbeeld omlaag na 18:00 uur en weer omhoog vóór 06:00 op dagen waarvan u weet dat er een afname in de benodigde resources is.

Volgende stappen