Azure SQL Database Managed Instance is eind 2018 algemeen beschikbaar gekomen. Sindsdien zijn veel organisaties begonnen met migreren naar Managed Instance vanwege de voordelen van een beheerde omgeving. Organisaties profiteren van beheerde back-ups, veel ingebouwde beveiligingsfuncties, een uptime SLA van 99,99% en een altijd up-to-date omgeving waarin ze niet langer verantwoordelijk zijn voor het patchen van SQL Server of het besturingssysteem.
Eén maat doet niet altijd passen. Managed Instance biedt twee prestatielagen. Het Algemeen doel tier is ontworpen voor toepassingen met typische prestatie- en I/O-latentievereisten en biedt ingebouwde HA. De Bedrijfskritiek tier is ontworpen voor toepassingen die een lage I/O-latentie en hogere HA-vereisten vereisen. Business Critical biedt ook twee niet-leesbare secundairen en één leesbare secundaire. De leesbare secundaire is een geweldige manier om de werklast van de primaire te verdelen, waardoor de servicelaag die nodig is voor de primaire kan worden verlaagd, waardoor de totale uitgaven voor de instantie afnemen.
Toen Managed Instance voor het eerst werd uitgebracht, kon je kiezen tussen Gen4- en Gen5-processors. Gen4 wordt nog steeds beschreven in de documentatie, maar deze optie is nu meestal niet beschikbaar. Voor dit artikel behandel ik alleen configuraties met de Gen5-processors.
Elke servicelaag ondersteunt 4 tot 80 logische CPU's, ook wel virtuele cores of vCores genoemd. Geheugen wordt toegewezen aan ongeveer 5,1 GB per vCore. General Purpose biedt tot 8 TB hoogwaardige Azure Blob-opslag, terwijl Business Critical tot 4 TB supersnelle lokale SSD-opslag biedt.
Geheugen
Met slechts 5,1 GB geheugen per vCore, zou een instantie met minder vCores moeite kunnen hebben. De opties voor vCore-configuraties zijn 4, 8, 16, 24, 32, 40, 64 en 80 vCores. Als u rekent met elk van de vCore-opties ((number of vCores) × (5.1 GB) ), krijg je de volgende combinaties van core / geheugen:
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Bij veel organisaties die ik heb geholpen bij de overgang van on-premises naar Managed Instance, heb ik een aanzienlijke vermindering van het geheugen gezien. Typische on-premises configuraties zijn 4 vCores en 32 GB geheugen, of 8 vCores en 64 GB. Beide zijn goed voor meer dan 30% vermindering van het geheugen. Als de instance al onder geheugendruk stond, kan dit problemen veroorzaken. In de meeste gevallen hebben we de on-premises instantie kunnen optimaliseren om de geheugendruk te verlichten voordat we overgingen naar een beheerd exemplaar, maar in enkele gevallen moest de klant een hogere vCore-instantie gebruiken om de geheugendruk te verlichten .
Opslag
Opslag is iets moeilijker te plannen en te overwegen, omdat er met meerdere factoren rekening moet worden gehouden. Voor opslag moet u rekening houden met de algemene opslagvereiste voor zowel de opslaggrootte als de I/O-behoeften. Hoeveel GB's of TB's zijn er nodig voor de SQL Server-instantie en hoe snel moet de opslag zijn? Hoeveel IOPS en hoeveel doorvoer gebruikt het on-premises exemplaar? Daarvoor moet u uw huidige werklast op nul zetten met perfmon om gemiddelde en maximale MB/s vast te leggen en/of momentopnamen te maken van sys.dm_io_virtual_file_stats om het doorvoergebruik vast te leggen. Dit geeft je een idee van welk type I/O en doorvoer je nodig hebt in de nieuwe omgeving. Verschillende klanten met wie ik heb gewerkt, hebben dit essentiële onderdeel van de migratieplanning gemist en hebben prestatieproblemen ondervonden door het selecteren van een instantieniveau dat hun werklast niet ondersteunde.
Dit is van cruciaal belang voor de basislijn, omdat het bij on-premises servers gebruikelijk is om opslag te hebben van een supersnel SAN met hoge doorvoercapaciteiten naar kleinere virtuele machines. In Azure worden uw IOPS- en doorvoerlimieten bepaald door de grootte van het rekenknooppunt en in het geval van instantie beheren wordt dit bepaald door het aantal toegewezen vCores. Voor algemeen gebruik is er een limiet van 30-40k IOPS per instantie of 500 tot 12.500 IOPS per bestand, afhankelijk van de bestandsgrootte. De doorvoer per bestand is ook gebaseerd op een grootte die begint bij 100 MiB/s voor bestanden tot 128 GB en tot 480 MiB/s voor bestanden van 4 TB en groter. In Business Critical variëren IOPS van 5,5K – 110K per instantie of 1375 IOPS per vCore.
Consumenten moeten ook rekening houden met de schrijfsnelheid van logbestanden voor de instantie. Algemeen doel is 3 MB/s per vCore met een maximum van 22 MB/s voor de instance en Business Critical is 4 MB/s per vCore met een maximum van 48 MB/s voor de hele instance. In mijn ervaring met klanten hebben velen deze limieten voor schrijfdoorvoer ver overschreden. Voor sommigen was het een showstopper en voor anderen hebben ze hun systeem kunnen optimaliseren en aanpassen om de belasting te verminderen.
Naast de algemene doorvoer- en I/O-vereisten, is de opslaggrootte ook gekoppeld aan het aantal gekozen vCores. Voor algemeen gebruik:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Voor bedrijfskritiek:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Voor algemeen gebruik, zodra u 8 vCores hebt bereikt, kunt u de beschikbare opslagruimte maximaal benutten, wat goed werkt voor degenen die alleen algemeen gebruik nodig hebben. Maar als je Business Critical nodig hebt, kan het een grotere uitdaging zijn. Ik heb met veel klanten gewerkt die meerdere TB's hebben toegewezen aan VM's met 4, 8, 16 en 24 logische processors. Voor al deze klanten zouden ze minimaal 32 vCores moeten verhogen om aan hun opslagbehoefte te voldoen, een dure optie. Azure SQL Database heeft een soortgelijk probleem met de maximale databasegrootte en Microsoft heeft een Hyperscale-optie bedacht. We verwachten dat dit op een gegeven moment een optie zal worden voor Managed Instance om de opslaglimieten op een vergelijkbare manier aan te pakken.
De grootte van tempdb is ook gecorreleerd aan het aantal vCores. In de laag Algemeen gebruik krijgt u 24 GB per vCore (tot 1.920 GB) voor de gegevensbestanden, met een maximale grootte van het tempdb-logbestand van 120 GB. Voor de Business Critical-laag kan tempdb helemaal doorgroeien tot de momenteel beschikbare instance-opslaggrootte.
In-memory OLTP
Voor degenen die momenteel gebruikmaken van In-Memory OLTP (of van plan zijn dit te doen), houd er rekening mee dat dit alleen wordt ondersteund in de Business Critical-servicelaag. De hoeveelheid beschikbare ruimte voor In-Memory-tafels wordt ook beperkt door vCores:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Conclusie
Bij het plannen van een migratie naar Azure SQL Managed Instance, zijn er meerdere overwegingen waarmee u rekening moet houden voordat u besluit te migreren. Eerst moet u uw geheugen, CPU en opslagvereisten volledig begrijpen, omdat dit de grootte van de instantie bepaalt. Net zo belangrijk is te weten wat uw storage-I/O-vereisten zijn. IOPS en doorvoer voor de laag voor algemeen gebruik zijn rechtstreeks gekoppeld aan vCores en de grootte van de databasebestanden. Voor Business Critical is het gekoppeld aan het aantal vCores. Als u een zeer I/O-intensieve workload hebt, is Business Critical de aantrekkelijkste servicelaag omdat het hogere IOPS- en doorvoercijfers biedt. De uitdaging bij Business Critical is de lagere opslagcapaciteit en slechts ondersteuning van 1TB voor de gehele instance tot 16 vCores.
Met de juiste planning en mogelijke deconsolidatie van grotere instanties naar kleinere beheerde instanties, kan dit aanbod voor veel organisaties een zeer haalbare migratieoptie zijn. De aantrekkingskracht zijn de voordelen van het hebben van beheerde back-ups, ingebouwde HA met een SLA van 99,99%, toegevoegde beveiligingsfuncties en opties, en geen zorgen te hoeven maken over het patchen van een OS of SQL Server-instantie.