Köpmodell för vKärna – Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln granskar köpmodellen för virtuella kärnor för Azure SQL Managed Instance.

Överblick

En virtuell kärna (virtuell kärna) representerar en logisk processor och ger dig möjlighet att välja maskinvarans fysiska egenskaper (till exempel antalet kärnor, minnet och lagringsstorleken). Den vCore-baserade inköpsmodellen ger dig flexibilitet, kontroll, transparens för individuell resursförbrukning och ett enkelt sätt att översätta lokala arbetsbelastningskrav till molnet. Den här modellen optimerar priset och låter dig välja beräknings-, minnes- och lagringsresurser baserat på dina arbetsbelastningsbehov.

I den vCore-baserade inköpsmodellen beror dina kostnader på valet och användningen av:

• Tjänstnivå
• Maskinvarukonfiguration
• Beräkningsresurser (antalet virtuella kärnor och mängden minne)
• Reserverad databaslagring
• Faktisk lagring av säkerhetskopior

Köpmodellen för virtuell kärna (vCore) som används av Azure SQL Managed Instance ger följande fördelar:

• Kontroll över maskinvarukonfigurationen för att bättre matcha beräknings- och minneskraven för arbetsbelastningen.
• Prisrabatter för Azure Hybrid Benefit (AHB) och Reserved Instance (RI).
• Större transparens i maskinvaruinformationen som driver beräkning, vilket underlättar planeringen för migreringar från lokala distributioner.
• Högre skalningskornighet med flera tillgängliga beräkningsstorlekar.

Beräkna

SQL Managed Instance-beräkning tillhandahåller en viss mängd beräkningsresurser som kontinuerligt tillhandahålls oavsett arbetsbelastning, och debiterar för de provisionerade resurserna till ett fast pris per timme.

Eftersom ytterligare tre repliker automatiskt allokeras på tjänstnivån Affärskritisk är priset ungefär 2,7 gånger högre än det är på tjänstnivån Generell användning. På samma sätt återspeglar det högre lagringspriset per GB på tjänstnivån Affärskritisk de högre I/O-gränserna och den lokala SSD-lagringens kortare svarstid.

För instanser på tjänstnivån Generell användning är det möjligt att spara på beräknings- och licenskostnader genom att stoppa din instans när du inte använder den. Granska Stoppa och starta en instans för att lära dig mer.

Data- och logglagring

Följande faktorer påverkar mängden lagringsutrymme som används för data och loggfiler och gäller för nivåerna Generell användning och Affärskritisk.

• På tjänstnivån Generell användning använder tempdb lokal SSD-lagring och den här lagringskostnaden ingår i priset för virtuell kärna.
• På tjänstnivån Affärskritisk delar tempdb lokal SSD-lagring med data och loggfiler, och tempdb lagringskostnad ingår i vCore-priset.
• Den maximala lagringsstorleken för en SQL Managed Instance måste anges i multiplar på 32 GB.

Om du vill övervaka den totala förbrukade instanslagringsstorleken för SQL Managed Instance använder du måttet storage_space_used_mb. Om du vill övervaka den aktuella allokerade och använda lagringsstorleken för enskilda data och loggfiler i en databas med hjälp av T-SQL använder du sys.database_files-vyn och funktionen FILEPROPERTY(... , "SpaceUsed").

Lagring av säkerhetskopior

Lagring för databassäkerhetskopior allokeras för att stödja funktionerna i SQL Managed Instance. Den här lagringen är separat från data- och loggfillagring och faktureras separat.

• återställning till en specifik tidpunkt (PITR): Lagringsåtgången beror på hur snabbt databasen ändras och den kvarhållningsperiod som konfigurerats för säkerhetskopior. Du kan konfigurera en separat kvarhållningsperiod för varje databas mellan 1 och 35 dagar för SQL Managed Instance. En lagringsmängd för säkerhetskopiering som är lika med den konfigurerade maximala datastorleken tillhandahålls utan extra kostnad.
• långsiktig kvarhållning (LTR): Du har möjlighet att konfigurera långsiktig kvarhållning av fullständiga säkerhetskopior i upp till 10 år. Den konfiguration du väljer avgör hur mycket lagringsutrymme som ska användas för LTR-säkerhetskopieringar.

Tjänstnivåer

Tjänstnivån definierar vanligtvis lagringsarkitektur, utrymmes- och I/O-gränser och alternativ för affärskontinuitet som rör tillgänglighet och haveriberedskap.

Azure SQL Managed Instance har två tjänstnivåer:

• Allmänt ändamål. Du kan välja att använda den uppgraderade nästa generations tjänstnivå för generell användning (förhandsversion).
• Affärskritisk.

En detaljerad jämförelse mellan tjänstnivåer finns i resursgränser, men använd följande tabell för en kort översikt:

Generell användning

Arkitekturmodellen för tjänstnivån Generell användning baseras på en uppdelning av beräkning och lagring. Den här arkitekturmodellen förlitar sig på hög tillgänglighet och tillförlitlighet för Azure Blob Storage som transparent replikerar databasfiler och garanterar ingen dataförlust om underliggande infrastrukturfel inträffar.

Följande bild visar fyra noder i standardarkitekturmodellen med de avgränsade beräknings- och lagringsskikten.

I arkitekturmodellen för tjänstnivån Generell användning finns det två lager:

• Ett tillståndslöst beräkningslager som kör sqlservr.exe processen och som endast innehåller tillfälliga och cachelagrade data (till exempel plancache, buffertpool, kolumnlagringspool). Den här tillståndslösa noden drivs av Azure Service Fabric som initierar processen, kontrollerar nodens hälsotillstånd och utför redundansväxling till en annan plats om det behövs.
• Ett tillståndskänsligt datalager med databasfiler (.mdf/.ldf) som lagras i Azure Blob Storage. Azure Blob-lagring garanterar att det inte kommer att förekomma någon förlust av data för någon post som lagras i någon databasfil. Azure Storage har inbyggd datatillgänglighet/redundans som säkerställer att varje post i loggfilen eller sidan i datafilen bevaras även om processen kraschar.

När databasmotorn eller operativsystemet uppgraderas misslyckas en del av den underliggande infrastrukturen, eller om något kritiskt problem identifieras i sqlservr.exe processen, flyttar Azure Service Fabric den tillståndslösa processen till en annan tillståndslös beräkningsnod. Det finns en uppsättning reservnoder som väntar på att köra ny beräkningstjänst vid en failover av den primära noden för att minimera failovertid. Data i Azure Storage-lagret påverkas inte och data-/loggfiler kopplas till den nyligen initierade processen. Den här processen garanterar 99,99% tillgänglighet som standard. Det kan uppstå prestandapåverkan på tunga arbetsbelastningar som är under flygning på grund av övergångstiden och det faktum att den nya noden börjar med kall cache.

När du ska välja den här tjänstnivån

Tjänstnivån Generell användning är standardtjänstnivån i Azure SQL Managed Instance som utformats för de flesta allmänna arbetsbelastningar. Om du behöver en fullständigt hanterad databasmotor med standard-SLA och lagringssvarstid mellan 5 och 10 ms är nivån Generell användning alternativet för dig.

Nästa generations allmänna syfte

Tjänstnivån Allmän användning för nästa generation är en arkitektonisk uppgradering av den nuvarande tjänstnivån Allmän Användning som erbjuder följande viktiga egenskaper:

• Utformad för företag med högre prestandakrav samtidigt som den erbjuder samma baslinjekostnad som tjänstnivån Generell användning
• Betydande uppgraderingar av prestanda, skalbarhet och resursflexitet över tjänstnivån Generell användning
• Använder hanterade diskar i stället för sidblobar, vilket drastiskt förbättrar måtten för lagringsprestanda
• 3 kostnadsfria IOPS för varje GB reserverad lagring
• Stöd för upp till 500 databaser per instans och en maximal lagringsstorlek på 32 TB

Eftersom tjänstnivån Nästa generations generell användning är en uppgradering till den befintliga tjänstnivån Generell användning, oavsett vilken tjänstnivå din instans använder, återspeglar faktureringsutdraget generell användning tjänstnivå.

Arkitekturmodell

Tjänstnivån Nästa generations generell användning är en uppgradering till den befintliga tjänstnivån Generell användning som använder ett uppgraderat fjärrlagringslager för att lagra instansdata och loggfiler på hanterade diskar i stället för sidblobbar. Det innebär att uppgraderingen av tjänstnivån Nästa generations generell användning ger snabbare lagringsfördröjning, IOPS och dataflöde än den befintliga tjänstnivån Generell användning, med ökade gränser för lagring, antalet virtuella kärnor och det maximala antalet databaser. Eftersom prestandakvoterna delas av hela instansen behöver du inte längre ändra storlek på enskilda filer för att förbättra deras prestanda. Baslinjekostnaden för tjänstnivån Nästa generations generell användning är samma som tjänstnivån Generell användning, men du kan använda skjutreglage för att öka I/O-prestanda, som sedan faktureras separat.

Nästa generations tjänstnivå för allmän användning hjälper till att minska kostnaderna genom att erbjuda kostnadsfria IOPS vid en takt av tre IOPS per GB reserverad lagring. Priset för lagringen inkluderar minsta IOPS. Om du överskrider minimivärdet debiteras du enligt följande: 1 IOPS = lagringspris (per region) dividerat med tre.

Till exempel:

• Om 1 GB lagringsutrymme kostar 0,115, då 1 IOPS = 0,115/3 = 0,038 per IOPS.
• En instans på 1 024 GB tar emot 3 072 IOPS kostnadsfritt. Du kan välja att öka din IOPS upp till VM-gränsen mot en extra kostnad.

När du ska välja den här tjänstnivån

Välj den här tjänstnivån om ditt företag är budgetorienterat, men prestandamåtten och gränserna för tjänstnivån Generell användning är otillräckliga.

De viktigaste orsakerna till varför du bör välja tjänstnivån Nästa generations generell användning i stället för nivån Generell användning är:

• Bättre prestanda för samma baslinjekostnad
• Förbättrad svarstid, dataflöde och IOPS
• Större lagringskapacitet
• Mer flexibilitet för din beräkning
• Du behöver över 100 databaser för en enda instans
• Du behöver mer än 16 TB reserverad lagring

Affärskritisk

Affärskritisk tjänstnivåmodell baseras på ett kluster med databasmotorprocesser. Den här arkitekturmodellen förlitar sig på ett kvorum med alltid tillgängliga databasmotornoder för att minimera prestandapåverkan på din arbetsbelastning, även under underhållsaktiviteter. Azure uppgraderar och korrigerar det underliggande operativsystemet, drivrutinerna och SQL Server-databasmotorn transparent, med minimal stilleståndstid för slutanvändare.

I den affärskritiska modellen integreras beräkning och lagring på varje nod. Replikering av data mellan databasmotorprocesser på varje nod i ett kluster med fyra noder ger hög tillgänglighet, där varje nod använder lokalt ansluten SSD som datalagring.

Både SQL Server-databasmotorprocessen och underliggande .mdf/.ldf-filer placeras på samma nod med lokalt ansluten SSD-lagring som ger låg svarstid till din arbetsbelastning. Hög tillgänglighet implementeras med hjälp av teknik som liknar SQL Server AlwaysOn-tillgänglighetsgrupper.

Varje instans är ett kluster av databasmotornoder som innehåller kopior av alla databaser på en instans, med en primär databas tillgänglig för kundarbetsbelastningar och tre sekundära databaser som innehåller kopior av data, redo för redundans. Den primära noden skickar ständigt ändringar till de sekundära noderna för att säkerställa att data är tillgängliga på sekundära repliker om den primära noden av någon anledning misslyckas.

Redundans hanteras av SQL Server-databasmotorn – en sekundär replik blir den primära noden och en ny sekundär replik skapas för att säkerställa att det finns tillräckligt med noder i klustret. Arbetsbelastningen omdirigeras automatiskt till den nya primära noden.

Dessutom har det affärskritiska klustret en inbyggd funktionen Läs utskalning som tillhandahåller en kostnadsfri skrivskyddad replik som används för att köra skrivskyddade frågor (till exempel rapporter) som inte påverkar arbetsbelastningens prestanda på din primära replik.

När du ska välja den här tjänstnivån

Tjänstnivån Affärskritisk är utformad för program som kräver svar med låg svarstid från den underliggande SSD-lagringen (1–2 ms i genomsnitt), snabbare återställning om den underliggande infrastrukturen misslyckas eller behöver avlasta rapporter, analyser och skrivskyddade frågor till den kostnadsfria läsbara sekundära repliken i den primära databasen.

De viktigaste orsakerna till varför du bör välja tjänstnivån Affärskritisk i stället för tjänstnivån Generell användning är:

• krav på låg I/O-svarstid – arbetsbelastningar som behöver ett snabbt svar från lagringsskiktet (1–2 millisekunder i genomsnitt) bör använda nivån Affärskritisk.
• Arbetsbelastning med rapportfrågor och analytiska frågor som kan omdirigeras till den kostnadsfria, sekundära skrivskyddade repliken.
• Högre återhämtning och snabbare återställning från fel. Om det uppstår systemfel tas databaserna på den primära instansen offline, och en av de sekundära replikerna blir omedelbart den nya skriv- och läsbara primära instansen, redo att bearbeta förfrågningar. Databasmotorn behöver inte analysera och göra om transaktioner från loggfilen eller läsa in data i minnesbuffertar.
• Avancerat datakorruptionsskydd. Eftersom nivån Affärskritisk använder databasrepliker i bakgrunden drar tjänsten nytta av automatisk sidreparation som är tillgänglig med speglingsteknik och tillgänglighetsgrupper för att motverka datakorruption. Om en replik inte kan läsa en sida på grund av ett dataintegritetsproblem hämtas en ny kopia av sidan från en annan replik och ersätter den olästa sidan utan dataförlust eller kundavbrott. Den här funktionen är tillgänglig på nivån Generell användning om den hanterade instansen har en geo-sekundär replik.
• Högre tillgänglighet – Affärskritiskt nivå i en konfiguration med flera tillgänglighetszoner ger motståndskraft mot zonstopp och ett Servicenivåavtal (SLA) med högre tillgänglighet.
• Snabb geo-återställning – Om en redundansgrupp har konfigurerats har nivån Affärskritisk ett garanterat mål för återställningspunkt (RPO) på 5 sekunder och mål för återställningstid (RTO) på 30 sekunder i 100% distribuerade timmar.

När du anger tjänstnivå i mallar eller skript tillhandahålls nivån med dess namn. Följande tabell gäller:

Hög tillgänglighet

Som standard uppnår Azure SQL Managed Instance tillgänglighet genom lokal redundans, vilket gör din instans tillgänglig under underhållsåtgärder, problem med avbrott i datacenter och andra problem med SQL-databasmotorn. Men för att minimera ett potentiellt avbrott i en hel zon som påverkar dina data kan du uppnå hög tillgänglighet genom att aktivera zonredundans. Utan zonredundans sker felövergångar lokalt i samma datacenter, vilket kan resultera i att din instans inte är tillgänglig tills avbrott har lösts. Det enda sättet att återställa är genom en haveriberedskapslösning, exempelvis genom en redundansgruppeller en geografisk återställning av en georedundant säkerhetskopia.

Maskinvarukonfigurationer

Maskinvarukonfigurationsalternativ i modellen med virtuella kärnor inkluderar standardserier (Gen5), premiumserier och minnesoptimerade premiumserier. Maskinvarukonfiguration definierar vanligtvis beräknings- och minnesgränser och andra egenskaper som påverkar arbetsbelastningens prestanda.

Mer information om maskinvarukonfigurationsspecifika och begränsningar finns i Maskinvarukonfigurationsegenskaper.

I vyn sys.dm_user_db_resource_governance dynamisk hantering visas maskinvarugenerering för instanser med Intel® SP-8160-processorer (Skylake) som Gen6, medan maskinvarugenerering för instanser med Intel® 8272CL (Cascade Lake) visas som Gen7. Intel® 8370C-processorer (Ice Lake) som används av premiumserier och minnesoptimerade premiumserie-maskinvarugenerationer visas som Gen8. Resursgränser för alla Gen5-instanser (standardserie) är desamma oavsett processortyp (Broadwell, Skylake eller Cascade Lake).

Välj en maskinvarukonfiguration

Du kan välja maskinvarukonfiguration när instansen skapas, eller så kan du ändra maskinvaran för en befintlig instans.

Välj maskinvarukonfiguration när du skapar en SQL Managed Instance-

Detaljerad information finns i Skapa en SQL Managed Instance-.

På fliken Grundläggande väljer du länken Konfigurera databas i avsnittet Compute + Storage och väljer sedan önskad maskinvara:

Så här ändrar du maskinvara för en befintlig SQL Managed Instance-

Set-AzSqlInstance -Name "managedinstance1" -ResourceGroupName "ResourceGroup01" -ComputeGeneration Gen5

az sql mi update -g mygroup -n myinstance --family Gen5

När du anger maskinvaruparameter i mallar eller skript tillhandahålls maskinvaran med hjälp av dess namn. Följande tabell gäller:

SKU-namn

Maskinvarutillgänglighet

Standard-serien (Gen5) och Premium-serien

Maskinvara i Standard-serien (Gen5) och Premium-serien finns i alla offentliga regioner över hela världen.

Minnesoptimerad premium-seriemaskinvara finns i förhandsversion och har begränsad regional tillgänglighet. Mer information finns i resursbegränsningar för Azure SQL Managed Instance.

Relaterat innehåll

• Skapa en SQL-hanterad instans med azure-portalen
• sidan för prissättning av Azure SQL Managed Instance för enskild instans
• prissidan för Azure SQL Managed Instance-pooler
• vCore-baserade resursgränser för Azure SQL Managed Instance