PaaS-opties uitleggen voor het implementeren van SQL Server in Azure
Platform as a Service (PaaS) biedt een volledige ontwikkel- en implementatieomgeving in de cloud, die kan worden gebruikt voor eenvoudige cloudtoepassingen en voor geavanceerde bedrijfstoepassingen.
Azure SQL Database en Azure SQL Managed Instance maken deel uit van paaS-aanbiedingen voor Azure SQL.
Azure SQL Database: onderdeel van een serie producten die zijn gebouwd op de SQL Server-engine, in de cloud. Het biedt ontwikkelaars veel flexibiliteit bij het bouwen van nieuwe toepassingsservices en gedetailleerde implementatieopties op schaal. SQL Database biedt een oplossing voor weinig onderhoud die een uitstekende optie kan zijn voor bepaalde workloads.
Azure SQL Managed Instance: het is het beste voor de meeste migratiescenario's naar de cloud, omdat het volledig beheerde services en mogelijkheden biedt.
Zoals u in de bovenstaande afbeelding ziet, biedt elk aanbod een bepaald beheerniveau dat u hebt via de infrastructuur, door de mate van kostenefficiëntie.
Implementatiemodellen
Azure SQL Database is beschikbaar in twee verschillende implementatiemodellen:
Individuele database: één database die wordt gefactureerd en beheerd op databaseniveau. U beheert elk van uw databases afzonderlijk vanuit het perspectief van schaal en gegevensgrootte. Elke database die in dit model is geïmplementeerd, heeft zijn eigen toegewezen resources, zelfs als deze is geïmplementeerd op dezelfde logische server.
Elastische pools: een groep databases die samen worden beheerd en een gemeenschappelijke set resources delen. Elastische pools bieden een rendabele oplossing voor software als een servicetoepassingsmodel, omdat resources worden gedeeld tussen alle databases. U kunt resources configureren op basis van het aankoopmodel op basis van DTU of het aankoopmodel op basis van vCore.
Aankoopmodel
In Azure worden alle services ondersteund door fysieke hardware en kunt u kiezen uit twee verschillende aankoopmodellen:
Database Transaction Unit (DTU)
DTU's worden berekend op basis van een formule die reken-, opslag- en I/O-resources combineert. Het is een goede keuze voor klanten die eenvoudige, vooraf geconfigureerde resourceopties willen.
Het DTU-aankoopmodel wordt geleverd in verschillende servicelagen, zoals Basic, Standard en Premium. Elke laag heeft verschillende mogelijkheden, die een breed scala aan opties bieden bij het kiezen van dit platform.
Wat de prestaties betreft, wordt de Basic-laag gebruikt voor minder veeleisende workloads, terwijl Premium wordt gebruikt voor intensieve workloadvereisten.
Reken- en opslagresources zijn afhankelijk van het DTU-niveau en bieden een reeks prestatiemogelijkheden voor een vaste opslaglimiet, retentie van back-ups en kosten.
Notitie
Het DTU-aankoopmodel wordt alleen ondersteund door Azure SQL Database.
Zie het overzicht van het aankoopmodel op basis van DTU voor meer informatie over het DTU-aankoopmodel.
vCore
Met het vCore-model kunt u een opgegeven aantal vCores aanschaffen op basis van uw opgegeven workloads. vCore is het standaardaankoopmodel bij het aanschaffen van Azure SQL Database-resources. vCore-databases hebben een specifieke relatie tussen het aantal kernen en de hoeveelheid geheugen en opslag die aan de database wordt verstrekt. Het vCore-aankoopmodel wordt ondersteund door Azure SQL Database en Azure SQL Managed Instance.
U kunt ook vCore-databases kopen in drie verschillende servicelagen:
Algemeen gebruik: deze laag is bedoeld voor workloads voor algemeen gebruik. Het wordt ondersteund door Azure Premium Storage. Deze heeft een hogere latentie dan Bedrijfskritiek. Het biedt ook de volgende rekenlagen:
- Ingericht: rekenresources worden vooraf toegewezen. Gefactureerd per uur op basis van geconfigureerde vCores.
- Serverloos: rekenresources worden automatisch geschaald. Gefactureerd per seconde op basis van gebruikte vCores.
Bedrijfskritiek – Deze laag is bedoeld voor workloads met hoge prestaties die de laagste latentie van een van beide servicelagen bieden. Deze laag wordt ondersteund door lokale HD's in plaats van Azure Blob Storage. Het biedt ook de hoogste tolerantie voor fouten en biedt een ingebouwde databasereplica met het kenmerk Alleen-lezen die kan worden gebruikt voor het off-load rapportageworkloads.
Hyperscale: Hyperscale-databases kunnen veel verder schalen dan de limiet van 4 TB voor andere Azure SQL Database-aanbiedingen en hebben een unieke architectuur die ondersteuning biedt voor databases van maximaal 100 TB.
Serverloos
De naam Serverloos kan enigszins verwarrend zijn omdat u uw Azure SQL Database nog steeds implementeert op een logische server waarmee u verbinding maakt. Serverloze Azure SQL Database is een rekenlaag waarmee de resources voor een bepaalde database automatisch omhoog of omlaag worden geschaald op basis van de vraag naar workloads. Als de werkbelasting geen rekenresources meer nodig heeft, wordt de database 'onderbroken' en wordt alleen de opslag gefactureerd tijdens de periode dat de database inactief is. Wanneer er een verbindingspoging wordt gedaan, wordt de database hervat en beschikbaar.
De instelling voor het onderbreken van het besturingselement wordt de vertraging voor automatischpause genoemd en heeft een minimumwaarde van 60 minuten en een maximumwaarde van zeven dagen. Als de database gedurende die periode inactief is geweest, wordt deze onderbroken.
Zodra de database gedurende de opgegeven tijd inactief is geweest, wordt deze onderbroken totdat een volgende verbinding wordt geprobeerd. Het configureren van een bereik voor automatisch schalen van berekeningen en een vertraging bij automatisch onderbreken zijn van invloed op de prestaties en rekenkosten van de database.
Toepassingen die serverloos gebruiken, moeten worden geconfigureerd om verbindingsfouten af te handelen en logica voor opnieuw proberen op te nemen, omdat het maken van verbinding met een onderbroken database een verbindingsfout genereert.
Een ander verschil tussen serverloos en het normale vCore-model van Azure SQL Database is dat u met serverloos een minimum en maximum aantal vCores kunt opgeven. Geheugen- en I/O-limieten zijn proportioneel met het bereik dat is opgegeven.
In de bovenstaande afbeelding ziet u het configuratiescherm voor een serverloze database in Azure Portal. U hebt de mogelijkheid om minimaal de helft van een vCore en maximaal 16 vCores te selecteren.
Serverloos is niet volledig compatibel met alle functies in Azure SQL Database, omdat sommige hiervan achtergrondprocessen altijd moeten worden uitgevoerd, zoals:
- Geo-replicatie
- Langetermijnretentie van back-ups
- Een taakdatabase in elastische taken
- De synchronisatiedatabase in SQL Data Sync (Data Sync is een service die gegevens repliceert tussen een groep databases)
Notitie
Serverloze SQL Database wordt momenteel alleen ondersteund in de laag Algemeen gebruik in het vCore-aankoopmodel.
Back-ups
Een van de belangrijkste functies van het Platform as a Service-aanbod is back-ups. In dit geval worden back-ups automatisch uitgevoerd zonder tussenkomst van u. Back-ups worden opgeslagen in geografisch redundante azure-blobopslag en worden standaard gedurende 7 tot 35 dagen bewaard op basis van de servicelaag van de database. Basis- en vCore-databases zijn standaard ingesteld op zeven dagen retentie en op de vCore-databases kan deze waarde worden aangepast door de beheerder. De bewaartijd kan worden verlengd door langetermijnretentie (LTR) te configureren, zodat u back-ups maximaal 10 jaar kunt bewaren.
Als u redundantie wilt bieden, kunt u ook geografisch redundante blobopslag met leestoegang gebruiken. Met deze opslag worden uw databaseback-ups gerepliceerd naar een secundaire regio van uw voorkeur. Zo nodig kunt u ook lezen uit die secundaire regio. Handmatige back-ups van databases worden niet ondersteund en het platform weigert een verzoek om dit te doen.
Databaseback-ups worden volgens een bepaald schema gemaakt:
- Volledig – eenmaal per week
- Differentiële – om de 12 uur
- Logboek : elke 5-10 minuten, afhankelijk van de activiteiten in het transactielogboek
Dit back-upschema moet voldoen aan de behoeften van de meeste beoogde herstelpunten (RPO/RTO), maar elke klant moet evalueren of deze voldoen aan uw bedrijfsvereisten.
Er zijn verschillende opties beschikbaar voor het herstellen van een database. Vanwege de aard van Platform as a Service kunt u een database niet handmatig herstellen met behulp van conventionele methoden, zoals het uitgeven van de T-SQL-opdracht RESTORE DATABASE.
Ongeacht welke herstelmethode is geïmplementeerd, is het niet mogelijk om te herstellen via een bestaande database. Als een database moet worden hersteld, moet de bestaande database worden verwijderd of een andere naam krijgen voordat het herstelproces wordt gestart. Houd er bovendien rekening mee dat afhankelijk van de platformservicelaag de hersteltijden niet gegarandeerd zijn en kunnen fluctueren. Het wordt aanbevolen om het herstelproces te testen om een metrische basislijn te verkrijgen over hoe lang een herstel kan duren.
De beschikbare herstelopties zijn:
Herstellen met behulp van Azure Portal: met behulp van Azure Portal hebt u de mogelijkheid om een database te herstellen naar dezelfde Azure SQL Database-server, of u kunt de herstelfunctie gebruiken om een nieuwe database te maken op een nieuwe server in elke Azure-regio.
Herstellen met behulp van scripttalen: zowel PowerShell als Azure CLI kunnen worden gebruikt om een database te herstellen.
Notitie
Back-up alleen kopiëren naar Azure Blob Storage is beschikbaar voor SQL Managed Instance. SQL Database biedt geen ondersteuning voor deze functie.
Zie Automatische back-ups - Azure SQL Database & Azure SQL Managed Instance voor meer informatie over geautomatiseerde back-ups.
Actieve geo-replicatie
Geo-replicatie is een functie voor bedrijfscontinuïteit waarmee een database asynchroon wordt gerepliceerd naar maximaal vier secundaire replica's. Omdat transacties worden doorgevoerd in de primaire (en de replica's binnen dezelfde regio), worden de transacties verzonden naar de secundaire bestanden die opnieuw moeten worden afgespeeld. Omdat deze communicatie asynchroon wordt uitgevoerd, hoeft de aanroepende toepassing niet te wachten totdat de secundaire replica de transactie doorvoert voordat SQL Server het besturingselement naar de aanroeper retourneert.
De secundaire databases kunnen worden gelezen en kunnen worden gebruikt voor het offloaden van alleen-lezen workloads, waardoor resources voor transactionele workloads op de primaire database worden vrijgemaakt of gegevens dichter bij uw eindgebruikers worden geplaatst. Bovendien kunnen de secundaire databases zich in dezelfde regio bevinden als de primaire of in een andere Azure-regio.
Met geo-replicatie kunt u handmatig een failover starten door de gebruiker of vanuit de toepassing. Als er een failover optreedt, moet u de toepassing mogelijk bijwerken verbindingsreeks s om het nieuwe eindpunt weer te geven van wat nu de primaire database is.
Failovergroepen
Failovergroepen zijn gebouwd op basis van de technologie die wordt gebruikt in geo-replicatie, maar bieden één eindpunt voor verbinding. De belangrijkste reden voor het gebruik van failovergroepen is dat de technologie eindpunten biedt, die kunnen worden gebruikt om verkeer naar de juiste replica te routeren. Uw toepassing kan vervolgens verbinding maken na een failover zonder verbindingsreeks wijzigingen.