Lagringsområden för Azure Arc-aktiverade SQL Managed Instance

Lagring är en viktig komponent i en Azure Arc-aktiverad SQL Managed Instance-distribution (Arc-aktiverad SQL Managed Instance). Att förstå hur de lagringsrelaterade begrepp som beskrivs i det här dokumentet påverkar kubernetes-klusters funktion är en viktig aspekt av val och hantering av lagringsdesign.

I stället för att interagera direkt med underliggande lagring tillhandahåller Kubernetes ett abstraktionslager till olika lagringstekniker via lagringsklasser. Molnleverantörer, maskinvaruleverantörer och andra Kubernetes-hanterade plattformar erbjuder olika StorageClass-alternativ som passar specifika miljöer och implementeringsscenarier.

Arc-aktiverade SQL Managed Instance begränsar eller framtvingar inte användning av lagringsklasser, så det är viktigt att välja rätt lagringsdesign och konfiguration. Lagringsdesignen för Arc-aktiverade SQL Managed Instance är lika viktig som om du valde lagringsenheter för en SQL Server när du kör utan operativsystem eller virtuella datorer. De här alternativen representerar i slutändan dina krav kring RPO, RTO, kapacitet och prestanda.

För Arc-aktiverade SQL Managed Instance distributioner är det viktigt att effektivt planera för lagringsfunktioner och konfiguration för att fungera korrekt. Läs vidare om du vill veta mer om de lagringsrelaterade faktorer som du kan tänka på, följt av rekommendationer för att konfigurera Arc-aktiverade SQL Managed Instance.

Arkitektur

Följande arkitekturdiagram visar den logiska designen för Azure Arc-aktiverade datatjänstkomponenter. Dessa komponenter omfattar en nödvändig Azure Arc-datakontrollant och en eller flera Arc-aktiverade SQL Managed Instance som innehåller databaser som har etablerats som referens. Både Azure Arc-datastyrenheten och Arc-aktiverade SQL Managed Instance tillhandahåller alternativ för säkerhetskopiering av lagringsenheter, som är beroende av Kubernetes-distributions- och lagringsinfrastrukturleverantörer.

Designöverväganden

Följande är överväganden för din lagringsdesign och konfiguration.

Lagringsklasser

Att välja rätt Kubernetes StorageClass och konfiguration för dina Azure Arc-aktiverade datatjänstkomponenter är viktigt för datalagringens prestanda, återhämtning och kapacitet.

StorageClass, PersistentVolume (PV) och PersistentVolumeClaim (PVC) är Kubernetes-resursobjekt som systemet skapar i kubernetes-klustret när du etablerar Azure Arc-aktiverade datatjänstkomponenter.

Alternativen för StorageClass varierar beroende på vad din molnleverantör, maskinvaruleverantör erbjuder och vad Kubernetes-administratören har konfigurerat. PersistentVolumeClaim begär att en PersistentVolume skapas för StorageClass och den begärda storleken. Följande diagram är en referens till relationen mellan dessa Kubernetes-resurser och potentiella alternativ för lagringsklasserna.

PV- och PVC Kubernetes-resurserna konfigureras vid etablering av Azure Arc-datakontrollanten respektive Arc-aktiverade SQL Managed Instance.

Det finns två olika lagringstyper att välja mellan:

• Lokala: En volym som monteras på en lokal lagringsenhet som är ansluten till Kubernetes-noden där podden körs. Den här typen av lagring ger vanligtvis kortare svarstid tillsammans med högre in-/utdataåtgärder per sekund (IOPS) och dataflöde jämfört med fjärr-/delad lagring.
• Fjärr-/delad lagring: Nätverksanslutna lagringsenheter som tenderar att levereras med inbyggd redundans. Vanliga lagringsalternativ är NAS- och SAN-enheter.

Tänk på följande standarder när du väljer en StorageClass. Dessa kriterier skulle också gälla för alla databasservrar som du skulle skapa:

• Prestanda: Dataflödet för in-/utdata för lagringsenheter (I/O) och IOPS bör uppfylla dina databasbehov.
• Läs-/skrivförhållande: Att förstå arbetsbelastningen kan hjälpa dig att välja den maskinvarusupport som passar dina behov bäst med lämpliga kostnader. Tunga skrivarbetsbelastningar kan dra nytta av RAID 0-konfigurationer, medan sällan använda data kan hanteras bäst med hjälp av en SAN-enhetslagring.
• Databasisolering och samplats: Alla databaser på en Arc-aktiverad SQL Managed Instance dela PV, så du kan välja att flytta databaser till separata instanser av Arc-aktiverade SQL Managed Instance och undvika konkurrens om lagringsresurser.
• Kapacitet: Den definierade lagringsstorleken bör uppfylla den framtida kapaciteten för datakontrollanten och databasinstanserna för att undvika att behöva ändra storlek på en PVC. Överväg eventuella lagringsbegränsningar som din valda StorageClass kan ha.
• Åtkomstläge: Lagringsklassprovidrar har olika åtkomstlägen som stöder olika funktioner för hur lagring kan monteras och läsas eller skrivas av poddar. RWX (lässkrivning många) krävs för SQL Backup-volymen.
• Redundans: Replikering av data på det fysiska lagringslagret (RAID) för att stödja sömlös redundans om maskinvarudiskfel inträffar, vilket är separat från redundans på databasnivå som utförs av tillgänglighetsgrupper (AG).

Både Azure Arc Data Controller och Arc-aktiverade SQL Managed Instance Arc-datatjänster ger detaljerade alternativ för att konfigurera olika lagringsklasser för databasdata. Dessa datatjänster tillhandahåller också loggar, vilket ger flexibilitet när du väljer lagringsklasser för att uppfylla behoven.

Datakontrollant

En enda Azure Arc-datakontrollant krävs för ett Kubernetes-kluster som en förutsättning för att skapa instanser av Arc-aktiverade SQL Managed Instance. Mer än en datakontrollant som körs i ett kluster stöds inte.

Azure Arc-datakontrollanten har fyra olika tillståndskänsliga poddar som körs i Kubernetes-klustret: Controller SQL, Controller API, Logs DB och Metrics DB. Varje podd kräver två beständiga volymer för data- och loggvolymerna. Alla datastyrenhetskomponenter kräver en fjärrlagringsklass för att säkerställa datahållbarhet, eftersom själva datakontrollantkomponenterna inte ger datahållbarhet internt.

Tänk på de beräknings- och minnesresurser som Krävs av Azure Arc-datakontrollanten. Följande diagram representerar datastyrenhetens lagrings-, PV- och PVC Kubernetes-resurser.

Standardstorleken för datakontrollantens volym är det rekommenderade minimivärdet. Vilken lagring du använder beror på antalet databaser, hur du använder databaserna och antalet genererade loggar. Azure Arc Data Controller StorageClass är inte känslig för låg svarstid. Trots detta kan användarna se fördelar i Grafana- och Kibana-gränssnitten med snabbare lagring om du har många Arc-aktiverade SQL Managed Instance distributioner i ett kluster. Grafana och Kibana är öppen källkod övervakningsvisualiseringsverktyg som distribuerats med datakontrollanten och etablerats med instrumentpaneler för att visa mått och loggar för Arc-aktiverade SQL Managed Instance.

Etablering av datakontrollant

När du etablerar Azure Arc-datastyrenheten konfigurerar du StorageClass och lagringskapaciteten för både loggar och data. Att konfigurera lagring för både loggar och data gäller sedan för alla åtta PV:er som du skapar för datakontrollantpoddarna. Under etableringen kan du ange en anpassad distributionsmall som åsidosätter standardparametrar som kapacitet, loggkvarhållning och objekt som rör säkerhet, till exempel Kubernetes-tjänsttyper. När etableringen är klar skapas PV- och PVC Kubernetes-objekt.

Det är viktigt att förstå att Lagringsklassen för datakontrollanten inte kan ändras när den har etablerats. Om du inte anger någon StorageClass använder datakontrollanten Kubernetes standardlagringsklass, som kan variera beroende på din Kubernetes-instans eller -provider.

När du avinstallerar Azure Arc-datastyrenheten tas alla beständiga volymer som är associerade med den bort. Arkivera alla Azure Arc-aktiverade datatjänsters kontrollplansloggar som din organisation behöver spara innan datakontrollanten avinstalleras.

Azure Arc-aktiverad SQL Managed Instance

Arc-aktiverade SQL Managed Instance erbjuder två olika nivåer beroende på affärskrav: Generell användning och Affärskritisk. För båda nivåerna är det viktigt att granska de lägsta och högsta Arc-aktiverade SQL Managed Instance gränserna, som kan konfigureras, och se till att det distribuerade Kubernetes-klustret har rätt beräknings- och minneskapacitet.

I scenarier med flera databaser på en viss databasinstans använder alla databaser samma StorageClass, PVC och PV som angetts för den Arc-aktiverade SQL Managed Instance. Det går att ha flera instanser av Arc-aktiverade SQL Managed Instance i ett enda Kubernetes-kluster. Den här konfigurationen möjliggör oberoende beständiga volymer och kan hjälpa till att separera I/O-konkurrens från olika databaser genom att distribuera databaserna till olika instanser av Arc-aktiverade SQL Managed Instance.

I följande tabell beskrivs de olika beständiga volymer som används av varje Arc-aktiverad SQL Managed Instance podd och dess syfte.

Beständiga volymer	Description	Krav för lagringsklass
Data	SQL Database datafiler (.mdf-filer)	Beror på nivå
Dataloggar	SQL Database loggfiler (.ldf-filer)	Beror på nivå
Loggar	SQL-agent, felloggar, spårningsfiler, hälsologgar	Beror på nivå
Säkerhetskopior	SQL Server Säkerhetskopieringsfiler inklusive Fullständig, Diff, Transaktionslogg	Fjärråtkomst, ReadWriteMany-åtkomstläge

Generell användning tjänstnivå

Den Generell användning nivån för Arc-aktiverade SQL Managed Instance måste använda fjärrlagring för databasinstansen så att data förblir tillgängliga för nyligen skapade poddar när en podd misslyckas. Redundans hanteras av Kubernetes-podden och nodorkestrering. Den här konfigurationen är mindre komplex jämfört med Affärskritisk, som använder SQL-tillgänglighetsgrupper och flera Arc-aktiverade SQL Managed Instance repliker. Den enskilda poddkonfigurationen för Generell användning-nivån innebär att du kan minimera mängden lagringsutrymme eftersom du inte behöver duplicera lagringskapaciteten för andra repliker.

Affärskritisk tjänstnivå

Affärskritisk-nivån använder en flera poddmodeller där data och loggvolymer kan lagras på lokala eller fjärranslutna lagringsklasser. Lokala lagringsklasser fungerar vanligtvis bättre när det gäller svarstid och dataflöde eftersom lagringsenheten är direkt kopplad till noden. Fjärrlagring erbjuder vanligtvis inbyggd redundans men har ofta lägre svarstid och dataflöde jämfört med lokal lagring. Tänk på att användning av fler Affärskritisk databasrepliker kräver extra beständiga volymer för data, loggar och dataloggar. Den totala lagringskapacitet som krävs är mycket högre.

Följande diagram visar Affärskritisk lagringskonfiguration för Arc-Enabled SQL Managed Instance med två repliker.

Affärskritisk kan du konfigurera två eller tre sekundära repliker. Redundans hanteras av SQL AlwaysOn-tillgänglighetsgruppen, vilket ger mindre stilleståndstid för uppgraderingar och fel än den Generell användning nivån.

Genom att konfigurera flera repliker med datareplikering i synkront genomförandeläge får du ett bättre skydd mot fel, till exempel en misslyckad podd, nod eller lagringsmaskinvara. Den skyddar mot fel eftersom det finns flera kopior av data på replikerna. Överväg att konfigurera sekundära repliker som utskalningsinstanser som klienter kan ansluta till när de använder den sekundära lyssnarslutpunkten.

Etablering och avinstallation av Azure Arc SQL Managed Instance

När du etablerar Arc-aktiverade SQL Managed Instance har du flexibiliteten att tilldela olika lagringsklasser till var och en av de Arc-aktiverade SQL Managed Instance beständiga volymerna. Du kanske vill ha lagringsalternativ med högre prestanda för Data och DataLogs, men volymerna Loggar och Säkerhetskopiering kan använda mer kostnadseffektiva StorageClass-alternativ för att spara på kostnaderna. I scenarier där du använder lokal lagring ska du se till att volymerna kan landa på olika noder och fysiska lagringsenheter för att undvika konkurrens om disk-I/O. Om data och dataloggar placeras på samma fysiska enhet kan det orsaka konkurrens om lagringsenheten, vilket ger sämre prestanda. Överväg i stället att placera Data och DataLogs på separata lagringsenheter för att parallellisera I/O för både databasdata och loggar.

När du tar bort Arc-aktiverade SQL Managed Instance tas inte dess associerade datorer och datorer bort. Detta säkerställer att du kan komma åt databasfilerna om borttagningen var oavsiktlig.

Designrekommendationer

Följande är rekommendationer för din lagringsdesign och konfiguration.

Lagringsklasser för produktionsarbetsbelastningar

För specifika offentliga moln visas de rekommenderade lagringsklasserna för produktionsarbetsbelastningar i följande tabell.

Leverantör	Verifierad och rekommenderad lagring
Azure Kubernetes Service (AKS)	Azure Managed Disks (Premium-nivå)
Amazon Elastic Kubernetes Service (EKS)	EBS CSI-lagringsdrivrutin
Google (GKE)	Beständiga GCE-diskar

När du väljer en lagringsklass för produktion i lokala scenarier eller scenarier med flera moln kontrollerar du att den kan uppfylla din avsedda lagringskapacitet, IOPS, redundans och dataflödesbehov. Följande avsnitt innehåller fler rekommendationer för dessa scenarier.

Design av datastyrenhet

Välj en fjärransluten, delad StorageClass för att säkerställa datahållbarhet. Om en podd eller nod tas bort kan du säkerhetskopiera podden och ansluta igen till den beständiga volymen. Understrykningen StorageClass måste ge redundans och hög tillgänglighet.

Vi rekommenderar att du använder en anpassad distributionsmall när du skapar en Arc-aktiverad data services-datakontrollant. Med en anpassad mall kan du finjustera lagringsklasser, lagringsstorlek för data och loggar, säkerhet och Kubernetes-tjänsttyper. Du kan anpassa dem efter din miljö och dina företagsbehov. Azure Arc-datastyrenheten kräver totalt åtta beständiga volymer. Den minsta standardkonfigurationen tillåter 15Gi för data och 10Gi för loggar på PV:erna. Konfigurera kapacitet som inte bara uppfyller minimikraven utan som stöder högre tillväxt från att ha många Arc-aktiverade SQL Managed Instance implementeringar som körs i ett kluster. Den här konfigurationen förhindrar behovet av att ändra storlek på datorer i framtiden.

Vi rekommenderar att du väljer en lagringsklass med kortare svarstid om klustret har många databaser och Arc-aktiverade SQL Managed Instance distributioner. Kortare svarstider förbättrar användarupplevelsen i Grafana- och Kibana-gränssnitten.

Migrering av Azure Arc-aktiverad SQL Managed Instance

Vi rekommenderar att du planerar och tar hänsyn till alla nya och befintliga databaser som ingår i migreringen och distributionen av dina Arc-aktiverade SQL Managed Instance. Planering förhindrar behovet av att flytta databaser mellan instanser vid ett senare tillfälle.

Beroende på kubernetes-klusterorganisationen etablerar du Arc-aktiverade SQL Managed Instance distributioner till olika Kubernetes-kluster baserat på behovet av att separera miljöer (icke-prod, prod), regioner och andra affärsfaktorer. Mer rekommendationer finns i designområdet Resursorganisation . När du konfigurerar flera databasinstanser i ett kluster måste du separera upptagna databaser i sin egen instans för att undvika I/O-konkurrens.

Använd nodetiketter för att säkerställa att databasinstanser placeras på separata noder för att distribuera den övergripande I/O-trafiken över flera noder. Se Kubernetes-nodetiketter tillsammans med Kubernetes Node-tillhörighet och etiketter för antitillhörighet för att konfigurera etiketterna. Om du arbetar i en virtualiserad miljö kontrollerar du att I/O är korrekt distribuerad på den fysiska värdnivån.

Planera kapaciteten för Arc-aktiverade SQL Managed Instance för att inkludera lämpliga lagringsstorlekar för data, loggar, dataloggar och säkerhetskopior. När du planerar kapacitet för både aktuella behov och beräknad tillväxt för alla databaser som kommer att finnas på instanserna av Arc-aktiverade SQL Managed Instance, förhindrar det att du behöver ändra storlek på datorerna i framtiden. Välj separata fysiska enheter för Data och DataLogs för att tillåta parallell I/O-aktivitet. Parallell I/O-aktivitet ger bättre prestanda genom att undvika eventuell konkurrens som uppstår när du använder en delad enhet.

Även om det finns flera faktorer som kan diktera distributionen av Affärskritisk- eller Generell användning arc-aktiverade SQL Managed Instance, ger Affärskritisk lokal lagring den lägsta svarstiden och högsta tillgängligheten. I designområdet Arc-aktiverad SQL Managed Instance affärskontinuitet finns rekommendationer kring återställning till tidpunkt, hög tillgänglighet och haveriberedskap. Läs även designområdet arc-aktiverad SQL Managed Instance kostnadsstyrning om du vill veta mer om kostnadskonsekvenserna mellan nivåerna.

Följande underavsnitt ger mer specifika rekommendationer för varje nivå:

Generell användning rekommendationer på tjänstnivå

Vi rekommenderar att du väljer en fjärrlagringsklass med låg latens för beständiga data - och dataloggvolymer för optimala prestanda. Undvik att använda en StorageClass som introducerar nätverkspartitioner, till exempel att ha ett lokalt kluster konfigurerat för att använda en StorageClass som tillhandahålls av Internet för beständiga volymer för säkerhetskopiering och loggar.

Affärskritisk servicenivårekommendationer

Vi rekommenderar att du granskar skillnaderna i tillgänglighetsläge, vilket kräver olika konfigurationer för varje valt läge.

För scenarier med lägsta möjliga svarstidskrav väljer du lokal lagring om det är ett alternativ för Kubernetes-infrastrukturen. De lokala lagringsvolymerna bör landa på olika underliggande lagringsenheter för att undvika konkurrens om disk-I/O och maximera prestanda. Lagringsenheten bör inte ha flera funktioner, till exempel värd för operativsystempartitionen.

För läsintensiva arbetsbelastningar och hög tillgänglighet konfigurerar du flera repliker och konfigurerar dina program eller klienter att använda sekundära repliker som läs- Scale-Out instanser. Sekundära repliker kan inte läsas som standard. du kan konfigurera inställningen.

Övervakning

Vi rekommenderar att du övervakar alla datorer som skapats av Arc-aktiverade datatjänster, inklusive Azure Arc-datakontrollanten och alla instanser av Arc-aktiverade SQL Managed Instance i ett kluster. Ställ in aviseringar för att meddela dig när en PVC närmar sig nära kapacitet. Med meddelande kan du ändra storlek på PVC:en innan du når kapaciteten. För direktanslutna kluster utförs övervakning av datorer och aviseringar av Azure Monitor och Container Insights. När du använder indirekta anslutna kluster utför du övervakning och aviseringar i Grafana och Kibana. Grafana-installationen innehåller instrumentpaneler för Arc-aktiverade SQL Managed Instance-mått och Kubernetes-resurser.

Granska de Arc-aktiverade SQL Managed Instance styrningsområden för fler rekommendationer om övervakning av Arc-aktiverade SQL Managed Instance.

Nästa steg

Mer information om din hybrid- och molnresa med flera moln finns i följande artiklar:

• Granska lagringskonfigurationen för Azure Arc-aktiverade datatjänster.
• Granska de verifierade Kubernetes-distributionerna för Azure Arc-aktiverade datatjänster.
• Läs storleksvägledningen för Azure Arc-aktiverade datatjänster.
• Granska övervakning med Grafana och Kibana för en Arc-aktiverad SQL Managed Instance.
• Upplev Arc-aktiverade SQL Managed Instance automatiserade scenarier med Azure Arc Jumpstart.
• Mer information om Azure Arc finns i Utbildningsvägen för Azure Arc på Microsoft Learn.