Dela via

Översikt över hanteringsåtgärder i Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln innehåller en översikt över de olika åtgärder som inträffar när du hanterar Azure SQL Managed Instance. Hanteringsåtgärder är åtgärder som utförs på serverdelen när du skapar, uppdaterar eller tar bort en instans.

En detaljerad beskrivning av stegen och den uppskattade varaktigheten för varje hanteringsåtgärd finns i Varaktighet för hanteringsåtgärder.

Vad är förvaltningsåtgärder?

Hanteringen av Azure SQL Managed Instance omfattar följande åtgärder:

  • Skapa: De åtgärder som inträffar när du först skapar en ny SQL-hanterad instans. Detta omfattar att skapa den underliggande virtuella datorgruppen (VM) och distribuera SQL Database Engine-processen.
  • Uppdatering: Åtgärder som inträffar när du ändrar egenskaperna för en befintlig SQL-hanterad instans, till exempel skalning av beräkning eller lagring, ändring av tjänstnivå eller uppdatering av instanskonfigurationen. Att göra uppdateringar innebär ofta att ändra storlek på den virtuella datorgruppen, förbereda data och sedan överföra till en ny SQL Database Engine-process.
  • Ta bort: Åtgärder som inträffar när du tar bort en befintlig SQL-hanterad instans, inklusive rensning av resurser, till exempel den vm-grupp som är associerad med instansen.

En detaljerad beskrivning av stegen och den uppskattade varaktigheten för varje hanteringsåtgärd finns i Varaktighet för hanteringsåtgärder.

SQL Managed Instance-hanteringsåtgärder utförs genom följande underliggande processer:

  • Gruppåtgärder för virtuell dator (VM): Åtgärder som innebär att skapa och hantera den underliggande VM-grupp som är värd för den SQL-hanterade instansen. Detta inkluderar att ändra storlek på den virtuella datorgruppen, skapa nya VM-grupper och hantera de virtuella datorerna i dessa grupper.
  • Seeding: Initiering och synkronisering av data i SQL Database Engine-processer, vanligtvis för att förbereda för en redundansväxling.
  • Redundansväxling: Åtgärder som ingår i redundansväxla trafik till en annan SQL Database Engine-process, antingen i samma eller i en ny VM-grupp.

Gruppåtgärder för virtuella datorer

För att stödja distributioner i virtuella Azure-nätverk och tillhandahålla isolering och säkerhet för kunder förlitar sig SQL Managed Instance på virtuella kluster. Det virtuella klustret representerar en dedikerad uppsättning isolerade virtuella datorer (VM) som distribuerats i ditt virtuella nätverksundernät och organiserats i VM-grupper. I princip resulterar varje SQL-hanterad instans som distribueras till ett tomt undernät i ett nytt virtuellt kluster som skapar den allra första VM-gruppen.

Efterföljande hanteringsåtgärder på SQL-hanterade instanser kan påverka de underliggande VM-grupperna. Ändringar som påverkar de underliggande VM-grupperna kan påverka varaktigheten för hanteringsåtgärder, eftersom distributionen av fler virtuella datorer till det virtuella klustret medför ett omkostnader som du måste tänka på när du planerar nya distributioner eller uppdateringar av befintliga instanser.

Detaljerad information om arkitekturen för virtuella kluster finns i Arkitektur för virtuella kluster.

Seedning

Seeding spelar en viktig roll i driften av Azure SQL Managed Instance, särskilt under installation och replikering av databaser. Seeding är den process som initierar och synkroniserar data mellan SQL Database Engine-processer, vilket är en viktig del av instanshanteringen. Även om det ofta är det mest tidskrävande steget i långa men lyckade åtgärder, fungerar seeding som en hörnsten för att etablera en felfri och funktionell SQL-hanterad instansmiljö.

För en uppskattad varaktighet för såddaktiviteter, se Varaktighet för hanteringsaktiviteter.

Seeding-processen omfattar vanligtvis följande steg, oavsett tjänstnivå:

  • Initiering: Systemet identifierar käll- och måldatabasen och startar ett antal uppgifter som förbereder SQL Database Engine-processerna för dataöverföring.
  • Dataöverföring: Faktiska datapaket överförs från källan till SQL Database Engine-målprocessen, som innehåller en fullständig eller partiell kopia av databasen, beroende på scenariot.
  • Synkronisering: När den första dataöverföringen är klar synkroniserar systemet eventuella efterföljande uppdateringar eller ändringar genom replikering av transaktionsloggblock för att säkerställa dataintegriteten.
  • Validering och slutförande: Processen slutförs och SQL Database Engine-målprocessen verifieras för att bekräfta lyckad replikering och seeding. Failover sker så att trafiken dirigeras till den nya SQL-databasprocessen.

Det finns ingen data seeding på tjänstnivån Generell användning förutom när du ändrar tjänstnivån till tjänstnivån Affärskritisk . Hanteringsåtgärder på tjänstnivån Generell användning innebär att fjärrlagring från den gamla SQL Database Engine-processen kopplas till den nya SQL Database Engine-processen.

Omvänt kräver tjänstnivån Affärskritisk, utformad för högpresterande arbetsbelastningar, lokal lagring och samberoende för beräknings- och lagringslager. Därför kräver nästan alla åtgärder och scenarion på den här tjänstnivån seeding för att säkerställa datatillgänglighet och konsekvens.

Om seeding utlöses eller inte beror på det specifika scenariot och tjänstnivån, till exempel:

  • Tjänstnivåer för generell användning och nästa generations allmänna användning :
    • Ändras till tjänstnivån Affärskritisk – data måste överföras från fjärrlagringen till den lokala lagring som används på tjänstnivån Generell användning.
    • Aktivera eller inaktivera zonredundans – data måste kopieras till eller från zonredundanta regioner.
  • Affärskritisk tjänstnivå
    • Skalningslagring: Eftersom lagringen är fysiskt ansluten till den lokala datorn måste varje lagringsändring skapa en ny VM-grupp, så data måste överföras från den gamla datorn till den nya datorn (på alla 4 repliker).
    • Skalning av virtuella kärnor: Varje beräkningsskalningsåtgärd kräver att du skapar en ny vm-grupp, så data måste kopieras från den gamla datorn till den nya datorn (på alla 4 repliker).
    • Ändra maskinvaru- eller underhållsfönster: Om det redan finns en VM-grupp i undernätet med en matchande konfiguration ändras storleken på den virtuella datorgruppen. Om det här är en ny konfiguration skapas en ny vm-grupp. Data måste kopieras från den gamla VM-gruppen till den nya VM-gruppen (på alla 4 repliker).
    • Ändra tjänstnivå: Data måste kopieras från lokal lagring till fjärrlagringen som används på tjänstnivån Generell användning.
    • Aktivera eller inaktivera zonredundans – data måste kopieras till eller från zonredundanta regioner.

Såddhastigheter

Följande faktorer påverkar varaktigheten för seedingprocessen:

  • Databasstorlek: Större databaser kräver mer tid för att överföra data och synkronisera mellan SQL Database Engine-processer.
  • Nätverksberoenden: Nätverksbandbredd och svarstid kan avsevärt påverka seedinghastigheter.
  • Säkerhetskopierings- och återställningsåtgärder: Pågående säkerhetskopieringsåtgärder i SQL Database Engine-källprocessen kan påverka förberedelse av data för att skicka till en annan SQL Database Engine-process.
  • Instansarbetsbelastning: Instansarbetsbelastning under seeding kan orsaka begränsning och kraftigt förlänga processen.

De flesta av dessa faktorer ligger utanför din kontroll, men du kan hantera instanstrafik för att avsevärt optimera seeding-hastigheterna. Seeding använder samma instansberäkningsresurser som hanterar instanstrafik. Tung trafik under seeding kan minska tillgängligheten för virtuella kärnor och leda till otillräcklig kapacitet för seeding-processen, vilket orsakar begränsning av resurser.

Hög trafik under seeding kan påverka synkroniseringen eftersom seeding är utformat för att paketera och överföra alla lagrade data i en enda åtgärd. Efterföljande dataändringar i den gamla SQL Database Engine-processen som kommer när seeding har initierats måste, via replikering av transaktionsloggblock, stegvis synkroniseras till den nya SQL Database Engine-processen innan övergång kan ske. Om instansen är hårt belastad kan seeding kämpa med att hålla jämna steg med inkommande data, vilket leder till fördröjningar och potentiella fel i synkroniseringsfasen. Kontinuerlig hög trafik på den gamla SQL Database Engine-processen efter start av seeding kan leda till en situation där synkroniseringsfasen aldrig slutförs, eftersom nya data fortsätter att anlända och måste överföras. Detta kan resultera i en evig cykel av dataöverföring som förhindrar redundansväxling till den nya SQL Database Engine-processen.

För en uppskattad varaktighet för såddaktiviteter, se Varaktighet för hanteringsaktiviteter.

Azure-infrastruktur och meddelanden

Seeding är en process som inte exakt kan kvantifieras eller förutsägas, eftersom den förlitar sig på de delade Azure-tjänsterna. Dataöverföringen och seeding-åtgärderna beror på olika interna Azure-tjänster och infrastrukturer som delas i hela Azure-ekosystemet. Dessa tjänster används av flera andra orelaterade tjänster i Azure. Alla tjänster i Azure-ekosystemet konkurrerar om tillgängliga resurser, vilket leder till variationer i tillfällig tillgänglighet som påverkas av flera faktorer. Microsoft kan tillhandahålla ett intervall där infrastrukturkapaciteten fungerar, men det är svårt att göra exakta förutsägelser.

Övergång vid fel

Instansredundans är det ögonblick då trafik dirigeras från en gammal SQL Database Engine-process till en ny SQL Database Engine-process inom nodgruppen i en VM-grupp som omfattar den SQL Managed Instance. Failover är en viktig del av de flesta hanteringsåtgärder, särskilt vid uppdatering av en instans. Den korta stund av avbrutna anslutningar när trafiken omdirigeras till den nya SQL Database Engine-processen kallas failover.

Din instans är endast otillgänglig under redundansväxlingen när trafiken omdirigeras till den nya SQL Database Engine-processen. På tjänstnivån Affärskritisk är din instans otillgänglig i upp till 20 sekunder, medan din instans kan vara otillgänglig i upp till 2 minuter på tjänstnivån Generell användning . Alla serverdelsåtgärder som utförs för att förbereda för redundans på grund av en hanteringsåtgärd, till exempel att återställa databaser på tjänstnivån Affärskritisk , sker i bakgrunden och påverkar inte tillgängligheten för din instans.

Arkitekturskillnader mellan tjänstnivåer förklaras i djup tillgänglighet.

Hanteringsåtgärders ömsesidiga påverkan

Hanteringsåtgärder på en SQL-hanterad instans kan påverka hanteringsåtgärderna för andra instanser som placeras i samma undernät:

  • Långvariga återställningsåtgärder i ett virtuellt kluster lägger andra åtgärder i samma virtuella kluster på is, till exempel skapa eller skala åtgärder.

    Exempel: Om det finns en tidskrävande återställningsåtgärd, och även en skalningsbegäran som krymper vm-gruppen, tar krympningsbegäran längre tid att slutföra eftersom den väntar på att återställningsåtgärden ska slutföras innan den kan fortsätta.

  • En efterföljande instansskapande- eller skalningsåtgärd spärras av en tidigare initierad instansgenerering eller instansskalning som initierade en storleksändring av vm-gruppen.

    Exempel: Om det finns flera begäranden om att skapa och/eller skala i samma undernät under samma VM-grupp, och en av dem initierar en vm-grupps storleksändring, kommer alla begäranden som skickades 5+ minuter efter att den första åtgärdsbegäran varar längre än förväntat, eftersom dessa begäranden måste vänta tills storleksändringen har slutförts innan den återupptas.

  • Skapa/skala operationer som skickas inom ett 1-minutersfönster behandlas i batch och utförs parallellt.

    Exempel: Endast ett virtuellt klusters storleksändring utförs för alla åtgärder som skickas i ett 1-minutersfönster (mäts från den tidpunkt då den första åtgärdsbegäran skickas). Om en annan begäran skickas mer än 1 minut efter att den första har skickats väntar den på att storleksändringen för det virtuella klustret ska slutföras innan körningen startar.

Viktig

Hanteringsåtgärder som spärras på grund av en annan åtgärd som pågår återupptas automatiskt när villkoren för att fortsätta uppfylls. Ingen användaråtgärd krävs för att återuppta de tillfälligt pausade hanteringsåtgärderna.

Övervaka hanteringsåtgärder

Mer information om hur du övervakar hanteringsåtgärdens förlopp och status finns i Övervakning av hanteringsåtgärder för Azure SQL Managed Instance.

Avbryta hanteringsåtgärder

Information om hur du avbryter hanteringsåtgärden finns i Avbryta hanteringsåtgärder för Azure SQL Managed Instance.

Relaterat innehåll