Okno obsługi w usłudze Azure SQL Managed Instance
Dotyczy: 
Azure SQL Managed Instance
Funkcja okna obsługi umożliwia skonfigurowanie harmonogramu konserwacji dla zasobów usługi Azure SQL Managed Instance , dzięki czemu zdarzenia konserwacji wpływające na przewidywalne i mniej zakłócające obciążenie.
Uwaga
Funkcja okna obsługi chroni tylko przed zaplanowanym wpływem na uaktualnienia lub zaplanowaną konserwację. Nie chroni przed wszystkimi przyczynami trybu failover; wyjątki, które mogą powodować krótkie przerwy w połączeniu poza oknem obsługi, obejmują awarie sprzętowe i inne rekonfiguracje.
Powiadomienia z wyprzedzeniem umożliwiają klientom skonfigurowanie powiadomień wysyłanych z wyprzedzeniem do 24 godzin przed każdym zaplanowanym zdarzeniem.
Omówienie
Platforma Azure okresowo wykonuje planowaną konserwację zasobów wystąpienia zarządzanego SQL. Podczas zdarzenia konserwacji wystąpienia zarządzane SQL są w pełni dostępne, ale mogą podlegać krótkiej rekonfiguracji w ramach umów dotyczących poziomu usług dostępności (SLA) dla wystąpienia zarządzanego SQL.
Okno obsługi jest przeznaczone dla obciążeń produkcyjnych, które nie są odporne na ponowne konfiguracje wystąpień i nie mogą pochłaniać krótkich przerw w połączeniach spowodowanych przez zdarzenia planowanej konserwacji. Wybierając preferowane okno obsługi, można zminimalizować wpływ planowanej konserwacji , planując jego wystąpienie poza godzinami pracy szczytu. Odporne obciążenia i obciążenia nieprodukcyjne mogą polegać na domyślnych zasadach konserwacji usługi Azure SQL.
Okno obsługi jest bezpłatne i można je skonfigurować podczas tworzenia lub dla istniejących zasobów. Można ją skonfigurować przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia lub interfejsu API platformy Azure.
Ważne
Konfigurowanie okna obsługi jest długotrwałą operacją asynchroniczną, podobną do zmiany warstwy usługi zasobu Azure SQL. Zasób jest dostępny podczas operacji, z wyjątkiem krótkiej rekonfiguracji, która występuje na końcu operacji i zazwyczaj trwa do 8 sekund nawet w przypadku przerwanych długotrwałych transakcji. Aby zminimalizować wpływ ponownej konfiguracji, należy wykonać operację poza godzinami szczytu.
Uzyskiwanie większej przewidywalności przy użyciu okna obsługi
Domyślnie zasady konserwacji usługi Azure SQL blokują najbardziej wpływające aktualizacje w okresie od 8:00 do 5pm czasu lokalnego każdego dnia , aby uniknąć zakłóceń w typowych godzinach pracy szczytu. Czas lokalny jest określany przez lokalizację regionu świadczenia usługi Azure, który hostuje zasób i może obserwować czas letni zgodnie z lokalną definicją strefy czasowej.
Podczas konserwacji bazy danych pozostają dostępne, ale niektóre aktualizacje mogą wymagać przejścia w tryb failover. Domyślne okno obsługi systemu (od 17:00 do 8:00) ogranicza większość działań do tej pory, ale pilne aktualizacje mogą wystąpić poza nim. Aby upewnić się, że wszystkie aktualizacje są wykonywane tylko w oknie obsługi, wybierz opcję inną niż domyślna.
Okno aktualizacji konserwacji można dostosować do czasu odpowiedniego dla zasobów usługi Azure SQL, wybierając spośród dwóch nie domyślnych miejsc okien obsługi:
- Okno dni powszednie : od 10:00 do 18:00 czasu lokalnego, poniedziałek - czwartek
- Okno weekendowe : od 10:00 do 18:00 czasu lokalnego, piątek - niedziela
Wymienione dni okna obsługi wskazują dzień początkowy każdego ośmiogodzinnego okna obsługi. Na przykład "10:00 do 6:00 czasu lokalnego, poniedziałek – czwartek" oznacza, że okna obsługi zaczynają się o godzinie 10:00 czasu lokalnego każdego dnia (od poniedziałku do czwartku) i zakończyć o 6:00 czasu lokalnego następnego dnia (wtorek do piątku).
Po wybraniu okna obsługi i zakończeniu konfiguracji usługi planowana konserwacja odbywa się tylko w wybranym oknie. Zdarzenia konserwacji zwykle są wykonywane w jednym oknie, ale niektóre z nich mogą obejmować co najmniej dwa sąsiadujące okna.
Ważne
Usługa Azure SQL Managed Instance jest zgodna z bezpieczną praktyką wdrażania, w której sparowane regiony platformy Azure nie są wdrażane w tym samym czasie. Nie można jednak przewidzieć, który region zostanie uaktualniony jako pierwszy, więc kolejność wdrożenia nie jest gwarantowana. Czasami wystąpienie podstawowe zostanie uaktualnione jako pierwsze, a czasami będzie pomocnicze.
W sytuacjach, w których wystąpienie zarządzane SQL ma grupy trybu failover, a grupy nie są zgodne z parowaniem regionów świadczenia usługi Azure, należy wybrać różne harmonogramy okien obsługi dla podstawowego i pomocniczego wystąpienia zarządzanego SQL. Możesz na przykład wybrać okno obsługi dzień powszedni dla pomocniczego obszaru geograficznego i okna obsługi weekendowej dla wystąpienia zarządzanego SQL podstawowego obszaru geograficznego.
W bardzo rzadkich sytuacjach, w których każde odroczenie akcji może spowodować poważny wpływ, na przykład zastosowanie krytycznej poprawki zabezpieczeń, skonfigurowane okno obsługi może zostać tymczasowo zastąpione.
Powiadomienia z wyprzedzeniem
Powiadomienia o konserwacji można skonfigurować tak, aby otrzymywać alerty o nadchodzących zdarzeniach planowanej konserwacji dla usługi Azure SQL Managed Instance. Alerty są dostarczane z wyprzedzeniem 24 godziny przed otwarciem okna obsługi i na końcu okna obsługi. Aby uzyskać więcej informacji, zobacz Powiadomienia z wyprzedzeniem.
Dostępność funkcji
Obsługiwane typy subskrypcji
Konfigurowanie i używanie okna obsługi jest dostępne dla następujących typów ofert: Płatność zgodnie z rzeczywistym użyciem, Dostawca rozwiązań w chmurze (CSP), Microsoft Umowa Enterprise lub Umowa z Klientem Microsoft.
Oferty ograniczone tylko do użycia tworzenia i testowania nie kwalifikują się (na przykład płatność zgodnie z rzeczywistym użyciem — tworzenie i testowanie lub tworzenie i testowanie w przedsiębiorstwie).
Uwaga
Oferta platformy Azure to typ posiadanej subskrypcji platformy Azure. Ofertami platformy Azure są na przykład subskrypcja ze stawkami płatności zgodnie z rzeczywistym użyciem, Azure w ramach programu licencjonowania Open i Visual Studio Enterprise. Każda oferta lub plan mają różne warunki i korzyści. Twoja oferta lub plan jest wyświetlana w przeglądzie subskrypcji. Aby uzyskać więcej informacji na temat przełączania subskrypcji na inną ofertę, zobacz Zmienianie subskrypcji platformy Azure na inną ofertę.
Obsługiwane cele poziomu usług
Wybranie okna obsługi innego niż domyślne jest dostępne we wszystkich obiektach SLO z wyjątkiem pul usługi Azure SQL Managed Instance.
Obsługa regionów usługi Azure SQL Managed Instance dla okien obsługi
Wybranie okna obsługi dla usługi Azure SQL Managed Instance innego niż domyślne jest dostępne we wszystkich regionach.
Konserwacja bramy
W usłudze Azure SQL Managed Instance węzły bramy są hostowane w klastrze wirtualnym i mają to samo okno obsługi co wystąpienie zarządzane SQL.
Ważne
Zaleca się stosowanie zasad połączenia przekierowania w celu zminimalizowania liczby zakłóceń podczas zdarzenia konserwacji, zobacz typy połączeń.
Zagadnienia dotyczące usługi Azure SQL Managed Instance
Usługa Azure SQL Managed Instance składa się ze składników usługi hostowanych w dedykowanym zestawie izolowanych maszyn wirtualnych, które działają w podsieci sieci wirtualnej klienta. Te maszyny wirtualne są zorganizowane w grupach w celu utworzenia klastra wirtualnego, który może hostować wiele wystąpień zarządzanych. Ponieważ okno obsługi skonfigurowane dla wystąpień w tej samej podsieci może mieć wpływ na liczbę grup maszyn wirtualnych w ramach operacji zarządzania klastrem wirtualnym i klastrem wirtualnym, przed skonfigurowaniem okna obsługi należy wziąć pod uwagę kilka kwestii.
Konfiguracja okna obsługi to długotrwała operacja
Wszystkie wystąpienia hostowane w tej samej grupie maszyn wirtualnych współużytkuje to samo okno obsługi. Domyślnie wszystkie wystąpienia zarządzane są hostowane w grupie z domyślnym oknem obsługi. W przypadku określenia innego okna obsługi podczas tworzenia wystąpienia lub po jego utworzeniu wystąpienie zostanie umieszczone w oddzielnej grupie maszyn z odpowiednim oknem obsługi. Jeśli taka grupa nie istnieje w klastrze, zostanie utworzona nowa grupa, która będzie obsługiwać nową konfigurację wystąpienia. Jeśli skonfigurujesz dodatkowe wystąpienia w klastrze wirtualnym tak, aby korzystały z tego samego okna obsługi, te wystąpienia zostaną również dodane do grupy, co oznacza, że zmiana rozmiaru grupy może być konieczna. Dodanie wystąpień do nowej grupy maszyn i zmiana rozmiaru istniejących grup maszyn może zwiększyć czas trwania operacji w celu skonfigurowania okna obsługi.
Oczekiwany czas trwania konfigurowania okna obsługi dla wystąpienia zarządzanego można obliczyć przy użyciu szacowanego czasu trwania operacji zarządzania wystąpieniami.
Ważne
Podczas konfigurowania okna obsługi ostatni krok operacji wymaga ponownej konfiguracji wystąpienia, które zwykle trwa do 8 sekund, nawet jeśli przerywa długotrwałe transakcje. Aby zminimalizować wpływ, skonfiguruj okno obsługi poza godzinami pracy szczytu.
Wymagania dotyczące przestrzeni adresów IP
Każda nowa grupa maszyn wirtualnych w podsieci wymaga dodatkowych adresów IP zgodnie z alokacją adresu IP klastra wirtualnego. Zmiana okna obsługi dla istniejącego wystąpienia zarządzanego wymaga również tymczasowej dodatkowej pojemności adresu IP, podobnie jak podczas skalowania liczby rdzeni wirtualnych dla odpowiedniej warstwy usługi.
Zmiana adresu IP
Konfigurowanie lub zmienianie okna obsługi zmienia adres IP wystąpienia na inny adres IP w zakresie adresów IP podsieci.
Ważne
Upewnij się, że sieciowa grupa zabezpieczeń i reguły zapory nie blokują ruchu danych po zmianie adresu IP.
Serializacja operacji zarządzania klastrem wirtualnym
Operacje wpływające na klaster wirtualny, takie jak uaktualnienia usług lub zmiana rozmiaru klastra wirtualnego (na przykład dodawanie nowych lub usuwanie nieużywanych węzłów obliczeniowych), są serializowane. W związku z tym nowa operacja klastra wirtualnego nie może rozpocząć się do momentu zakończenia poprzedniej operacji. Jeśli okno obsługi zostanie zamknięte przed zakończeniem trwającej operacji konserwacji, trwa konserwacja zostanie wstrzymana do następnego okna obsługi. Inne operacje zarządzania przesłane w tym czasie są również wstrzymane i wznawiane podczas lub po następnym oknie obsługi po zakończeniu oryginalnej trwającej operacji konserwacji. Operacja konserwacji nie jest często wykonywana dłużej niż pojedyncze okno obsługi dla grupy maszyn wirtualnych w klastrze, ale może się zdarzyć w przypadku bardzo złożonych operacji konserwacji.
Serializacja operacji zarządzania klastrem wirtualnym jest ogólnym zachowaniem, które ma zastosowanie również do domyślnych zasad konserwacji. Podczas konfigurowania harmonogramu okna obsługi okres między dwoma sąsiednimi oknami może potrwać kilka dni. Chociaż rzadko, jeśli operacja konserwacji obejmuje dwa okna, nowo przesłane operacje mogą być wstrzymane przez kilka dni, potencjalnie blokujące operacje, które wymagają dodatkowych węzłów obliczeniowych, takich jak utworzenie nowego lub zmiana rozmiaru istniejącego wystąpienia.
Pobieranie listy zdarzeń konserwacji
Azure Resource Graph to usługa platformy Azure przeznaczona do rozszerzania usługi Azure Resource Management. Eksplorator usługi Azure Resource Graph zapewnia wydajną i wydajną eksplorację zasobów z możliwością wykonywania zapytań na dużą skalę w danym zestawie subskrypcji, dzięki czemu można efektywnie zarządzać środowiskiem.
Eksplorator usługi Azure Resource Graph umożliwia wykonywanie zapytań dotyczących zdarzeń konserwacji. Aby zapoznać się z wprowadzeniem do uruchamiania tych zapytań, zobacz Szybki start: uruchamianie pierwszego zapytania Resource Graph przy użyciu Eksploratora usługi Azure Resource Graph.
Aby sprawdzić zdarzenia konserwacji dla wszystkich wystąpień zarządzanych SQL w ramach subskrypcji, użyj następującego przykładowego zapytania w Eksploratorze usługi Azure Resource Graph:
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
Aby uzyskać pełną dokumentację przykładowych zapytań i sposobu ich używania w różnych narzędziach, takich jak program PowerShell lub interfejs wiersza polecenia platformy Azure, odwiedź stronę Przykładowe zapytania usługi Azure Resource Graph dotyczące usługi Azure Service Health.