Azure SQL Database Managed Instance blev allmänt tillgänglig i slutet av 2018. Sedan dess har många organisationer börjat migrera till Managed Instance för fördelarna med en hanterad miljö. Organisationer drar fördel av att ha hanterade säkerhetskopior, massor av inbyggda säkerhetsfunktioner, en upptids-SLA på 99,99 % och en alltid uppdaterad miljö där de inte längre är ansvariga för att patcha SQL Server eller operativsystemet.
En storlek gör det inte passar alltid alla. Managed Instance tillhandahåller två nivåer för prestanda. Det Allmänna syftet tier är designad för applikationer med typiska prestanda- och I/O-latenskrav och ger inbyggd HA. Affärskritiken tier är designad för applikationer som kräver låg I/O-latens och högre HA-krav. Business Critical tillhandahåller också två oläsbara sekundärer och en läsbar sekundär. Den läsbara sekundära är ett utmärkt sätt att fördela arbetsbelastningen från den primära, vilket kan sänka tjänstenivån som krävs för den primära – vilket minskar de totala utgifterna för instansen.
När Managed Instance först släpptes kunde du välja mellan Gen4- och Gen5-processorer. Gen4 beskrivs fortfarande i dokumentationen, men det här alternativet är för det mesta inte tillgängligt nu. För den här artikeln kommer jag bara att täcka konfigurationer med Gen5-processorer.
Varje servicenivå stöder allt från 4 till 80 logiska processorer – även känd som virtuella kärnor eller vCores. Minne tilldelas cirka 5,1 GB per vCore. General Purpose ger upp till 8 TB högpresterande Azure Blob-lagring, medan Business Critical ger upp till 4 TB supersnabb lokal SSD-lagring.
Minne
Med bara 5,1 GB minne per vCore kan en instans med färre vCores kämpa. Alternativen för vCore-konfigurationer är 4, 8, 16, 24, 32, 40, 64 och 80 vCores. Om du räknar ut vart och ett av vCore-alternativen ((number of vCores) × (5.1 GB) ), får du följande kombinationer av kärna/minne:
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 0.För många organisationer som jag har hjälpt till att gå från lokal till Managed Instance, har jag sett en betydande minskning av minnet. Typiska konfigurationer på plats skulle vara 4 vCores och 32 GB minne, eller 8 vCores och 64 GB. Båda står för mer än 30 % minskning av minnet. Om instansen redan var under minnespress kan detta orsaka problem. I de flesta fall har vi kunnat optimera den lokala instansen för att hjälpa till att lindra minnestrycket innan vi flyttade till Managed Instance, men i några fall var kunden tvungen att välja en högre vCore-instans för att lindra minnestrycket .
Lagring
Förvaring är lite svårare att planera och ta hänsyn till, på grund av att man måste ta hänsyn till flera faktorer. För lagring måste du ta hänsyn till det totala lagringsbehovet för både lagringsstorlek och I/O-behov. Hur många GB eller TB behövs för SQL Server-instansen och hur snabb måste lagringen vara? Hur många IOPS och hur mycket genomströmning använder den lokala instansen? För det måste du basera din nuvarande arbetsbelastning med hjälp av perfmon för att fånga medelvärde och max MB/s och/eller ta ögonblicksbilder av sys.dm_io_virtual_file_stats för att fånga genomströmningsanvändning. Detta ger dig en uppfattning om vilken typ av I/O och genomströmning du behöver i den nya miljön. Flera kunder som jag har arbetat med har missat denna viktiga del av migrationsplaneringen och har stött på prestandaproblem på grund av att de valt en instansnivå som inte stödde deras arbetsbelastning.
Detta är avgörande för baslinjen eftersom det med lokala servrar är vanligt att ha lagring från ett supersnabbt SAN med hög genomströmningskapacitet till mindre virtuella maskiner. I Azure bestäms dina IOPS- och genomströmningsgränser av storleken på beräkningsnoden, och i fallet med Manage Instance bestäms det av antalet tilldelade vCores. För allmänna ändamål finns det en gräns på 30-40k IOPS per instans eller 500 upp till 12 500 IOPS per fil beroende på filstorleken. Genomströmningen per fil är också baserad på storlek som sträcker sig från 100 MiB/s för upp till 128 GB filer och upp till 480 MiB/s för 4 TB och större filer. I Business Critical sträcker sig IOPS från 5,5 000 till 110 000 per instans eller 1 375 IOPS per vCore.
Konsumenter måste också ta hänsyn till loggskrivkapacitet för instansen. General Purpose är 3 MB/s per vCore med ett max på 22MB/s för instansen och Business Critical är 4 MB/s per vCore med ett max på 48 MB/s för hela instansen. Enligt min erfarenhet av att arbeta med kunder har många vida överskridit dessa gränser för skrivkapacitet. För vissa har det varit en showstopper, och för andra har de kunnat optimera och modifiera sitt system för att minska belastningen.
Förutom att behöva känna till övergripande genomströmning och I/O-krav, är lagringsstorleken också kopplad till antalet valda vCores. För allmänt ändamål:
4 vCores =2 TB max 8 - 80 vCores =8 TB maxFör affärskritiska:
4 – 16 vCores =1 TB 24 vCores =2 TB 32 - 80 vCores =4 TBFör General Purpose, när du väl kommer till 8 vCores, kan du maxa ut den tillgängliga lagringen, vilket fungerar bra för dem som bara behöver General Purpose. Men när du behöver Business Critical kan saker och ting vara mer utmanande. Jag har arbetat med många kunder som har flera TB:er allokerade till virtuella datorer med 4, 8, 16 och 24 logiska processorer. För någon av dessa kunder skulle de behöva flytta upp minst 32 vCores bara för att uppfylla deras lagringskrav, ett kostsamt alternativ. Azure SQL Database har ett liknande problem med maximal databasstorlek, och Microsoft kom med ett Hyperscale-alternativ. Vi förväntar oss att detta kommer att bli ett alternativ för Managed Instance någon gång för att ta itu med lagringsgränserna på liknande sätt.
Storleken på tempdb är också korrelerad till antalet vCores. I General Purpose-nivån får du 24 GB per vCore (upp till 1 920 GB) för datafilerna, med en tempdb-loggfilstorleksgräns på 120 GB. För Business Critical-nivån kan tempdb växa hela vägen upp till den för närvarande tillgängliga instanslagringsstorleken.
OLTP i minnet
För de som för närvarande utnyttjar In-Memory OLTP (eller planerar att göra det), notera att det bara stöds i tjänstenivån Business Critical. Mängden tillgängligt utrymme för In-Memory-tabeller begränsas också av 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 =90,10 GB 89,10 GBSlutsats
När du planerar en migrering till Azure SQL Managed Instance finns det flera överväganden att ta hänsyn till innan du bestämmer dig för att migrera. Först måste du till fullo förstå dina krav på minne, CPU och lagring, eftersom detta kommer att avgöra storleken på instansen. Lika viktigt är att veta vad dina I/O-krav för lagring är. IOPS och genomströmning för General Purpose-nivån är direkt kopplade till vCores och storleken på databasfilerna. För Business Critical är det kopplat till antalet vCores. Om du har en mycket I/O-intensiv arbetsbelastning är Business Critical den mer tilltalande tjänstenivån på grund av att den ger högre IOPS- och genomströmningssiffror. Utmaningen med Business Critical är den lägre lagringskapaciteten och stöder endast 1 TB för hela instansen upp till 16 vCores.
Med korrekt planering och eventuell dekonsolidering av större instanser till mindre hanterade instanser kan detta erbjudande vara ett mycket genomförbart migreringsalternativ för många organisationer. Överklagandet är fördelarna med att ha hanterade säkerhetskopior, inbyggd HA med ett SLA på 99,99 %, tillagda säkerhetsfunktioner och alternativ och att inte behöva oroa sig för att patcha en OS- eller SQL Server-instans.