Het creëren van een elastische pool voor je eerste SQL-database in Azure is een relatief eenvoudige stap: je hoeft enkel een naam toe te wijzen aan de pool. Nadat de pool is ingesteld, kunnen aanvullende databases worden aangemaakt die gebruik maken van de gedeelde bronnen binnen diezelfde pool. Wanneer nodig, kunnen gebruikers de opslagcapaciteit van de pool uitbreiden door meer opslag toe te voegen. Dit biedt flexibele schaalbaarheid voor verschillende toepassingen en workloads.

De keuze van het juiste servicetarief is essentieel voor het afstemmen van de prestaties en kosten van de SQL Database. Azure SQL Database biedt twee belangrijke aankoopmodellen: Database Transaction Units (DTU’s) en vCore. Elk van deze modellen heeft zijn eigen servicetiers en prestatieniveaus, waarmee gebruikers hun databaseprestaties kunnen aanpassen op basis van hun behoeften.

Het DTU-model maakt gebruik van een enkele maatstaf om de toegewezen CPU-, geheugen- en I/O-bronnen te definiëren. Dit is een eenvoudigere keuze voor wie een vooraf geconfigureerde oplossing zoekt. Het model biedt drie servicetiers: Basis, Standaard en Premium. Elke tier biedt verschillende niveaus van rekencapaciteit, een aanpasbare maximale databasesize en toenemende retentie van back-ups. De kosten per DTU variëren afhankelijk van de gekozen tier, maar gebruikers kunnen het aantal toegewezen DTU’s aanpassen naarmate de vereisten veranderen.

Voor diegenen die meer controle over hun bronnen willen, biedt het vCore-model meer gedetailleerde afstemming. Dit model maakt het mogelijk om de compute-, geheugen- en opslagcapaciteit van de database nauwkeuriger te schalen. Binnen het vCore-model zijn er verschillende tiers beschikbaar: General Purpose, Business Critical en Hyperscale.

Het standaard servicetarief voor een nieuw aangemaakte SQL Database is de General Purpose vCore-optie. Dit biedt een goed evenwicht tussen kosten en prestaties voor de meeste workloads. Voor een hogere mate van beschikbaarheid en fouttolerantie kunnen gebruikers de Business Critical-tier kiezen, die betere I/O-prestaties biedt, maar tegen een hogere prijs. De prijs per vCore in de Business Critical-tier is ongeveer 2,7 keer die van de General Purpose-tier, wat deels te maken heeft met de drie extra database-replicas die worden meegeleverd. Daarnaast biedt deze tier SSD-opslag met lagere latentie, wat de algehele prestaties verhoogt.

De Hyperscale-tier is een meer gespecialiseerde optie, ontworpen voor databases die extreem grote opslagcapaciteiten vereisen. In vergelijking met de andere tiers, die een maximum van 4 TB per database ondersteunen, biedt Hyperscale tot wel 100 TB opslagcapaciteit en tot 327.680 I/O-operaties per seconde (IOPS). Hyperscale biedt ook aanzienlijk meer geheugen per vCore – tot 10,2 GB, wat twee keer zoveel is als bij de andere tiers. Het is echter belangrijk om te weten dat de overstap naar de Hyperscale-tier een onomkeerbare beslissing is. Zodra je database naar deze tier is geconfigureerd, is de enige manier om terug te schakelen naar een andere service tier door de database opnieuw te implementeren en de gegevens te migreren.

Naast het kiezen van een servicetarief, moeten gebruikers die het vCore-model kiezen ook een keuze maken voor de compute-tier, die bepaalt of de database op een geconfigureerde (Provisioned) of dynamisch geschaalde (Serverless) manier werkt. In de Provisioned-optie worden de computebronnen vooraf toegewezen, wat resulteert in een vast tarief op basis van het aantal vCores. De Serverless-optie maakt het mogelijk om de computecapaciteit dynamisch aan te passen op basis van de werkbelasting. Dit biedt meer flexibiliteit voor kleinere of variabele workloads, omdat de database kan worden gepauzeerd wanneer deze niet in gebruik is, wat kosten bespaart op compute.

Binnen het vCore-model kunnen gebruikers ook kiezen uit verschillende hardwareconfiguraties. De maximale capaciteit in termen van vCores, geheugen en opslag wordt bepaald door de gekozen configuratie, wat een grotere mate van controle en flexibiliteit biedt voor gebruikers die specifieke prestatievereisten hebben.

Wanneer een Azure SQL Managed Instance (SQL MI) wordt geconfigureerd, wordt de keuze voor hardware en instellingen van toepassing op alle databases binnen die instantie. SQL MI biedt zowel General Purpose als Business Critical tiers, die respectievelijk geschikt zijn voor verschillende soorten workloads. De Business Critical-tier biedt lagere latentie en hogere beschikbaarheid, maar is duurder dan de General Purpose-tier. Net als bij de SQL Database, kunnen gebruikers van SQL MI ook hun computecapaciteit schalen door de juiste hardwareconfiguratie te kiezen, afhankelijk van het type CPU en het aantal vCores.

Voor de meeste toepassingen is het gebruik van Azure SQL Database of SQL MI voldoende, maar voor geavanceerdere of specifieke behoeften biedt Azure ook de optie van SQL Server op een virtuele machine (VM) in een Infrastructure-as-a-Service (IaaS)-omgeving. Dit biedt de grootste flexibiliteit en controle over zowel compute- als opslagcapaciteit. Deze oplossing is ideaal voor organisaties die zeer specifieke prestatieniveaus of configuraties vereisen die niet binnen de standaard PaaS-opties passen.

Het kiezen van de juiste configuratie en servicetiers vereist niet alleen een begrip van de technische mogelijkheden, maar ook een goed inzicht in de werkbelasting van de toepassing. Het is belangrijk om zowel de huidige als de toekomstige behoeften van de database goed in kaart te brengen, zodat de gekozen oplossing op lange termijn voldoet aan de vereiste prestaties en kosten.

Hoe kun je een FCI implementeren in Azure VMs voor hoogbeschikbaarheid en disaster recovery?

In het geval van een serverstoring biedt een Always On Failover Cluster Instance (FCI) een krachtige oplossing voor het garanderen van de beschikbaarheid van kritieke toepassingen, zoals SQL Server. Hoewel het mogelijk is om een FCI te creëren met on-premises Windows-servers, kan het ook volledig worden geïmplementeerd in de cloud met behulp van Windows Server op Azure Virtual Machines (VM’s). Dit biedt veel flexibiliteit en schaalbaarheid, maar vereist wel dat aan bepaalde voorwaarden wordt voldaan, zoals het gebruik van gedeelde opslag. Azure biedt verschillende mogelijkheden om deze vereisten in te vullen, elk met zijn eigen kenmerken en voordelen.

Een FCI vereist gedeelde opslag zodat alle knooppunten in het cluster dezelfde gegevens kunnen benaderen. Bij on-premises implementaties wordt vaak een Storage Area Network (SAN) geïnstalleerd om dit mogelijk te maken. Azure biedt echter verschillende opties voor gedeelde opslag die kunnen worden gekozen afhankelijk van de situatie, waaronder Azure Shared Disks, Premium File Shares, Storage Spaces Direct en Azure Elastic SAN.

Azure Shared Disks maken het mogelijk om managed disks met elkaar te delen, zodat alle VM’s in een cluster toegang kunnen krijgen tot dezelfde schijf. Microsoft beveelt aan om voor gedeelde SQL Server-opslag alleen Premium SSD’s te gebruiken vanwege hun hogere prestaties. Premium File Shares bieden verbeterde prestaties voor FCIs die draaien op Windows Server 2012 of later, en die over meerdere beschikbaarheidszones zijn verspreid. Storage Spaces Direct biedt een softwarematige SAN-oplossing voor FCIs die draaien op Windows Server 2016 of later, met de mogelijkheid voor blob caching. Azure Elastic SAN is een iSCSI-gebaseerde block storage-oplossing die ideaal is voor FCIs die draaien op Windows Server 2019 of later, in combinatie met SQL Server 2022 of latere versies.

Deze opslagopties beïnvloeden de keuze van het quorum-systeem dat binnen de FCI wordt gebruikt. In on-premises implementaties wordt vaak een disk witness gebruikt voor het quorum, terwijl FCIs die draaien op Azure VM’s andere witness-opties kunnen gebruiken, zoals de Cloud Witness, Disk Witness of File Share Witness. Het is belangrijk om de juiste keuze te maken, afhankelijk van de infrastructuur en de implementatiebehoeften.

Daarnaast moeten er mechanismen worden geïmplementeerd om verkeer naar de cluster te routeren als de FCI-knooppunten zich op een enkel subnet van een virtueel netwerk bevinden. Dit kan bijvoorbeeld door het gebruik van een Virtual Network Name (VNN) met een load balancer, of door een Distributed Network Name (DNN).

Naast de opslagconfiguratie en quorum-opties, is ook de configuratie van log shipping van cruciaal belang. Log shipping is een geautomatiseerd proces dat transactie-logboekback-ups maakt op een primaire server, deze kopieert naar secundaire servers, en de back-ups herstelt op secundaire databases. Dit biedt een eenvoudige disaster recovery-oplossing, maar biedt geen automatische failover van de primaire database naar de secundaire. In het geval van een storing van de primaire database moet een beheerder handmatig de failover uitvoeren.

De procedure voor log shipping bestaat uit een aantal stappen, zoals het configureren van de back-uplocaties, het instellen van de secundaire servers en databases, en het plannen van het primaire back-upwerk. Beheerders kunnen log shipping configureren via SQL Server Management Studio (SSMS) of via T-SQL. Het is belangrijk om te begrijpen dat log shipping geen failover-functies bevat, dus het is een tijdelijke oplossing totdat een meer robuuste oplossing voor hoogbeschikbaarheid en disaster recovery kan worden geïmplementeerd.

Daarnaast is het essentieel dat HA/DR-oplossingen regelmatig worden gecontroleerd om er zeker van te zijn dat ze goed functioneren. Dit houdt in dat de status van back-upwerkzaamheden gecontroleerd moet worden en dat periodieke hersteltests worden uitgevoerd om te bevestigen dat de gegevens daadwerkelijk beschermd zijn. Dit geldt niet alleen voor on-premises implementaties, maar ook voor SQL Server-databases die draaien op Azure Windows VM’s. Beheerders kunnen de prestaties van de virtuele hardware van de VM’s en de werking van de SQL Server-services controleren met behulp van tools zoals Performance Monitor.

Foutopsporingsprocessen voor HA/DR-oplossingen zijn eveneens cruciaal. Wanneer failovers niet plaatsvinden zoals verwacht of te vaak plaatsvinden, is het belangrijk om te controleren of alle knooppunten correct zijn aangesloten op het cluster, of het netwerk goed functioneert en of de quantumconfiguratie juist is ingesteld. Het is ook belangrijk om te controleren of er geen prestatieproblemen zijn, zoals verlies van pakketten of hoge hertransmissiesnelheden, die de failover-prestaties kunnen beïnvloeden.

Voor Azure-gebaseerde oplossingen kunnen beheerders gebruik maken van verschillende Azure-hulpmiddelen, zoals de Service Health-pagina, om te controleren of er geen onverwachte storingen of onderhoudsactiviteiten plaatsvinden die van invloed kunnen zijn op de prestaties van hun HA/DR-oplossingen.

Het is belangrijk te benadrukken dat een goed ontworpen hoogbeschikbaarheid- en disaster recovery-oplossing niet alleen afhankelijk is van de technologieën en tools die worden gebruikt, maar ook van de manier waarop deze worden beheerd en gecontroleerd. Dit omvat het juiste gebruik van verschillende opslagopties, het implementeren van een effectieve failoverstrategie, en het regelmatig testen van back-up- en herstelprocedures om te zorgen voor minimale downtime en dataverlies in het geval van een storing.

Hoe wordt de Kritische Straal van een Reactor Bepalen?
Wat drijft een lafaard tot geweld?
Hoe Lokale Mechanische Belasting de Verdeling van Magnetisatie in Ferromagnetoelastische Materialen Beïnvloedt