Omówienie operacji zarządzania w usłudze Azure SQL Managed Instance

2025-06-19

Ten artykuł zawiera omówienie różnych operacji występujących podczas zarządzania usługą Azure SQL Managed Instance. Operacje zarządzania to operacje wykonywane na zapleczu podczas tworzenia, aktualizowania lub usuwania wystąpienia.

Aby uzyskać szczegółowy opis kroków i szacowany czas trwania każdej operacji zarządzania, zapoznaj się z tematem Czas trwania operacji zarządzania.

Co to są operacje zarządzania?

Zarządzanie usługą Azure SQL Managed Instance obejmuje następujące operacje:

Utwórz: operacje wykonywane podczas pierwszego tworzenia nowego wystąpienia zarządzanego SQL. Obejmuje to tworzenie bazowej grupy maszyn wirtualnych oraz wdrażanie procesu Silnika Bazy Danych SQL.
Aktualizacja: operacje występujące podczas zmiany właściwości istniejącego wystąpienia zarządzanego SQL, takiego jak skalowanie zasobów obliczeniowych lub magazynu, zmiana warstwy usługi lub aktualizowanie konfiguracji wystąpienia. Wprowadzanie aktualizacji często obejmuje zmianę rozmiaru grupy maszyn wirtualnych, a także rozmieszczanie danych, a następnie przechodzenie w tryb failover do nowego procesu aparatu bazy danych SQL.
Usuń: operacje występujące podczas usuwania istniejącego wystąpienia zarządzanego SQL, w tym czyszczenie zasobów, takich jak grupa maszyn wirtualnych skojarzona z wystąpieniem.

Aby uzyskać szczegółowy opis kroków i szacowany czas trwania każdej operacji zarządzania, zapoznaj się z tematem Czas trwania operacji zarządzania.

Operacje zarządzania usługą SQL Managed Instance są wykonywane za pomocą następujących podstawowych procesów:

Operacje grupy maszyny wirtualnej: operacje obejmujące tworzenie podstawowej grupy maszyn wirtualnych hostujących wystąpienie zarządzane SQL i zarządzanie nimi. Obejmuje to zmianę rozmiaru grupy maszyn wirtualnych, tworzenie nowych grup maszyn wirtualnych i zarządzanie maszynami wirtualnymi w ramach tych grup.
Zasiew: inicjowanie i synchronizacja danych w procesach silnika bazy danych SQL, zwykle w celu przygotowania do przejścia w tryb failover.
Failover: operacje związane z przełączaniem ruchu do innego silnika bazy danych SQL, w tej samej lub nowej grupie maszyn wirtualnych.

Operacje grupy maszyn wirtualnych

Aby obsługiwać wdrożenia w sieciach wirtualnych platformy Azure i zapewnić klientom izolację i zabezpieczenia, usługa SQL Managed Instance opiera się na klastrach wirtualnych. Klaster wirtualny reprezentuje dedykowany zestaw izolowanych maszyn wirtualnych wdrożonych w podsieci sieci wirtualnej i zorganizowany w ramach grup maszyn wirtualnych. Zasadniczo każde wystąpienie zarządzane SQL wdrożone w pustej podsieci powoduje utworzenie nowego klastra wirtualnego, który tworzy pierwszą grupę maszyn wirtualnych.

Kolejne operacje zarządzania w wystąpieniach zarządzanych SQL mogą mieć wpływ na bazowe grupy maszyn wirtualnych. Zmiany wpływające na bazowe grupy maszyn wirtualnych mogą mieć wpływ na czas trwania operacji zarządzania, ponieważ wdrażanie większej liczby maszyn wirtualnych w klastrze wirtualnym wiąże się z obciążeniem, które należy wziąć pod uwagę podczas planowania nowych wdrożeń lub aktualizacji istniejących wystąpień.

Aby uzyskać szczegółowe informacje na temat architektury klastra wirtualnego, zobacz Architektura klastra wirtualnego.

Siewu

Inicjowanie odgrywa kluczową rolę w działaniu usługi Azure SQL Managed Instance, szczególnie podczas konfigurowania i replikacji baz danych. Inicjalizacja to proces, który inicjuje i synchronizuje dane między procesami silnika bazy danych SQL, co jest kluczową częścią zarządzania wystąpieniami. Chociaż często najbardziej czasochłonny krok w długich, ale udanych operacjach, inicjalizacja służy jako fundament do ustanowienia zdrowego i funkcjonalnego środowiska zarządzanej instancji SQL.

Szacowany czas trwania operacji zasiewu można znaleźć w sekcji Czas trwania operacji zarządzania.

Proces inicjalizacji zwykle obejmuje następujące etapy, niezależnie od poziomu usługi:

Inicjowanie: system identyfikuje źródłową i docelową bazę danych i uruchamia wiele zadań, które przygotowują aparat bazy danych SQL do transferu danych.
Transfer danych: rzeczywiste pakiety danych są przesyłane ze źródła do docelowego procesu aparatu bazy danych SQL, który obejmuje pełną lub częściową kopię bazy danych w zależności od scenariusza.
Synchronizacja: po zakończeniu początkowego transferu danych system synchronizuje wszelkie kolejne aktualizacje lub zmiany za pośrednictwem replikacji bloków dziennika transakcji w celu zapewnienia integralności danych.
Walidacja i finalizacja: Proces jest sfinalizowany, a docelowy proces silnika bazy danych SQL jest weryfikowany, aby potwierdzić pomyślną replikację i inicjowanie. Przejście w tryb failover odbywa się tak, aby ruch był kierowany do nowego procesu aparatu bazy danych SQL.

W warstwie usługi Ogólnego przeznaczenia nie ma inicjowania danych, z wyjątkiem zmiany na warstwę Biznes Krytyczny. Operacje zarządzania w warstwie usługi Ogólnego przeznaczenia obejmują odłączanie magazynu zdalnego od starego procesu aparatu bazy danych SQL i dołączanie go do nowego procesu aparatu bazy danych SQL.

Z drugiej strony warstwa usługi Krytyczne dla działania firmy , przeznaczona dla obciążeń o wysokiej wydajności, wymaga magazynu lokalnego oraz współzależności warstw obliczeniowych i magazynowych. W związku z tym prawie każda operacja i scenariusz w tej warstwie usługi wymaga rozmieszczania danych w celu zapewnienia dostępności i spójności danych.

Czy uruchomienie inicjowania zależy od konkretnego scenariusza i poziomu usługi, na przykład:

Warstwy usług Ogólnego przeznaczenia i Next-Gen Ogólnego przeznaczenia :
- Zmiana warstwy usługi Biznes Krytyczny — dane muszą być przesyłane z magazynu zdalnego do magazynu lokalnego używanego w warstwie usługi Ogólnego przeznaczenia.
- Włączanie lub wyłączanie strefowej nadmiarowości — dane muszą być kopiowane do lub z regionów z nadmiarowością strefową.
Warstwa usługi Krytyczne dla działania firmy:
- Skalowanie magazynu: ponieważ magazyn jest fizycznie dołączony do maszyny lokalnej, każda zmiana magazynu wymaga utworzenia nowej grupy maszyn wirtualnych, więc dane muszą być przesyłane ze starej maszyny do nowej maszyny (na wszystkich 4 replikach).
- Skalowanie rdzeni wirtualnych: każda operacja skalowania obliczeń wymaga utworzenia nowej grupy maszyn wirtualnych, więc dane muszą zostać skopiowane ze starej maszyny do nowej maszyny (we wszystkich 4 replikach).
- Zmiana sprzętu lub okna obsługi: jeśli grupa maszyn wirtualnych już istnieje w podsieci z zgodną konfiguracją, ta grupa maszyn wirtualnych zostanie zmieniona. Jeśli jest to nowa konfiguracja, zostanie utworzona nowa grupa maszyn wirtualnych. Dane muszą być kopiowane ze starej grupy maszyn wirtualnych do nowej grupy maszyn wirtualnych (we wszystkich 4 replikach).
- Zmiana warstwy usługi: dane muszą być kopiowane z magazynu lokalnego do magazynu zdalnego używanego w warstwie usługi Ogólnego przeznaczenia.
- Włączanie lub wyłączanie strefowej nadmiarowości — dane muszą być kopiowane do lub z regionów z nadmiarowością strefową.

Prędkości wysiewania

Następujące czynniki wpływają na czas trwania procesu siewu:

Rozmiar bazy danych: większe bazy danych wymagają więcej czasu na przesyłanie danych i synchronizowanie ich w procesach aparatu bazy danych SQL.
Zależności sieciowe: przepustowość sieci i opóźnienie mogą znacząco wpływać na szybkość udostępniania.
Operacje tworzenia i przywracania kopii zapasowych: Trwające operacje tworzenia kopii zapasowej w źródłowym procesie aparatu bazy danych SQL mogą mieć wpływ na przygotowanie danych do wysłania do innego procesu aparatu bazy danych SQL.
Obciążenie wystąpienia: Obciążenie wystąpienia podczas inicjalizacji może spowodować ograniczenie przepustowości i poważnie przedłużyć proces.

Większość z tych czynników wykracza poza twoją kontrolę, ale możesz zarządzać ruchem instancji, aby znacznie zoptymalizować szybkość rozpowszechniania. Serwer seedowania używa tych samych zasobów obliczeniowych jednostki, które zarządzają ruchem jednostki. Duży ruch podczas siewu może zmniejszyć dostępność vCore, co prowadzi do niewystarczającej pojemności procesu siewu, powodując ograniczenie przepustowości.

Duży ruch podczas seedingu może mieć wpływ na synchronizację, ponieważ seeding jest zaprojektowany do tworzenia pakietów i przesyłania wszystkich aktualnie przechowywanych danych w ramach jednej operacji. Kolejne zmiany danych w starym procesie aparatu bazy danych SQL, które docierają po zainicjowaniu inicjacji, muszą zostać zsynchronizowane z nowym procesem aparatu bazy danych SQL w sposób przyrostowy za pośrednictwem replikacji bloku dziennika transakcji przed przejściem w tryb failover. Jeśli wystąpienie jest silnie obciążone, inicjalizacja może mieć trudności z nadążaniem za danymi przychodzącymi, co prowadzi do opóźnień i potencjalnych awarii w fazie synchronizacji. Ciągły duży ruch w starym procesie silnika bazy danych SQL po rozpoczęciu inicjalizacji może prowadzić do sytuacji, w której faza synchronizacji nigdy nie zostanie zakończona, ponieważ nowe dane ciągle napływają i muszą być przesyłane. Może to skutkować nieustannym cyklem przesyłania danych, który uniemożliwia przejście w tryb failover do nowego procesu silnika bazy danych SQL.

Szacowany czas trwania operacji zasiewu można znaleźć w sekcji Czas trwania operacji zarządzania.

Infrastruktura i powiadomienia dotyczące platformy Azure

Rozsiewanie to proces, który nie może być dokładnie określony ani ściśle przewidywany, ponieważ opiera się na udostępnionych usługach Azure. Operacje transferu i rozmieszczania danych zależą od różnych wewnętrznych usług i infrastruktury platformy Azure, które są współużytkowane przez cały ekosystem platformy Azure. Te usługi są używane przez wiele innych niepowiązanych usług na platformie Azure. Wszystkie usługi w ekosystemie platformy Azure konkurują o dostępne zasoby, co prowadzi do wahań w chwilowej dostępności, na którą wpływa wiele czynników. Chociaż firma Microsoft może zapewnić zakres, w którym działa pojemność infrastruktury, dokładne przewidywania są trudne.

Przełączenie awaryjne

Przełączenie awaryjne wystąpienia to moment, w którym ruch jest kierowany ze starego procesu silnika bazy danych SQL do nowego procesu silnika bazy danych SQL w grupie węzłów maszyn wirtualnych obejmującej zarządzane wystąpienie SQL. Tryb failover jest kluczową częścią większości operacji zarządzania, zwłaszcza podczas aktualizowania wystąpienia. Krótki moment przerwania połączeń w trakcie przekierowywania ruchu do nowego procesu silnika bazy danych SQL jest określany jako failover.

Wystąpienie jest niedostępne tylko w trakcie przełączania na tryb failover, gdy ruch jest przekierowywany do nowego procesu silnika bazy danych SQL. W warstwie usługi Krytyczne dla działania firmy wystąpienie jest niedostępne przez maksymalnie 20 sekund, podczas gdy w warstwie usługi Ogólnego przeznaczenia wystąpienie może być niedostępne przez maksymalnie 2 minuty. Wszystkie operacje zaplecza, które mają zostać przygotowane do przejścia w tryb failover z powodu operacji zarządzania, takich jak ponowne wdrażanie baz danych w warstwie usługi Krytyczne dla działania firmy , są wykonywane w tle i nie wpływają na dostępność wystąpienia.

Różnice w architekturze między warstwami usług są szczegółowo wyjaśnione w dostępności.

Operacje zarządzania o wpływie krzyżowym

Operacje zarządzania w wystąpieniu zarządzanym SQL mogą mieć wpływ na operacje zarządzania innymi wystąpieniami umieszczonymi w tej samej podsieci:

Długotrwałe operacje przywracania w klastrze wirtualnym powodują wstrzymanie innych operacji w tym samym klastrze wirtualnym, takich jak operacje tworzenia lub skalowania.

Przykład: Jeśli istnieje długotrwała operacja przywracania, a także żądanie skalowania, które zmniejsza grupę maszyn wirtualnych, żądanie zmniejszania trwa dłużej, ponieważ czeka na zakończenie operacji przywracania, zanim będzie można kontynuować.
Kolejna operacja tworzenia lub skalowania wystąpienia jest wstrzymana przez wcześniej zainicjowane tworzenie wystąpienia lub skalowanie wystąpienia, które zainicjowało zmianę rozmiaru grupy maszyn wirtualnych.

Przykład: Jeśli istnieje wiele żądań tworzenia i/lub skalowania w tej samej podsieci w tej samej grupie maszyn wirtualnych, a jeden z nich inicjuje zmianę rozmiaru grupy maszyn wirtualnych, wszystkie żądania przesłane przez 5+ minuty po początkowym żądaniu operacji trwają dłużej niż oczekiwano, ponieważ te żądania muszą czekać na ukończenie zmiany rozmiaru przed wznowieniem.
Operacje tworzenia/skalowania przesyłane w 1-minutowym oknie są grupowane w pakiety i wykonywane równolegle.

Przykład: Dokonywana jest tylko jedna zmiana rozmiaru klastra wirtualnego dla wszystkich operacji przesłanych w 1-minutowym oknie czasowym (mierzone od momentu przesłania pierwszego żądania operacji). Jeśli kolejne żądanie zostanie przesłane więcej niż 1 minutę po przesłaniu pierwszego, czeka na zakończenie zmiany rozmiaru klastra wirtualnego przed rozpoczęciem jego wykonywania.

Ważne

Operacje zarządzania, które są wstrzymane z powodu innej operacji, która jest w toku, są automatycznie wznawiane po spełnieniu warunków kontynuowania. Do wznowienia tymczasowo wstrzymanych operacji zarządzania nie jest konieczna żadna akcja użytkownika.

Monitorowanie operacji zarządzania

Aby dowiedzieć się, jak monitorować postęp i stan operacji zarządzania, zobacz Monitorowanie operacji zarządzania usługą Azure SQL Managed Instance.

Anulowanie operacji zarządzania

Aby dowiedzieć się, jak anulować operację zarządzania, zobacz Anulowanie operacji zarządzania usługą Azure SQL Managed Instance.