Zarządzanie konserwacją i aktualizacjami usług przy użyciu harmonogramów konserwacji
Funkcja harmonogramu konserwacji integruje powiadomienia o planowanej konserwacji kondycji usługi, monitor kontroli kondycji zasobów i usługę planowania konserwacji dla puli SQL usługi Synapse (magazynu danych) w usłudze Azure Synapse Analytics.
Należy użyć harmonogramu konserwacji, aby wybrać przedział czasu, gdy jest wygodny do otrzymywania nowych funkcji, uaktualnień i poprawek. Należy wybrać podstawowe i pomocnicze okno obsługi w ciągu siedmiu dni. Każde okno musi należeć do oddzielnych zakresów dni.
Można na przykład zaplanować główne okno od soboty 22:00 do niedzieli 01:00, a następnie zaplanować dodatkowe okno od środy 19:00 do 22:00. Jeśli nie można wykonać konserwacji podczas podstawowego okna obsługi, spróbuje wykonać konserwację ponownie podczas pomocniczego okna obsługi. Konserwacja usługi może wystąpić czasami zarówno w oknach podstawowych, jak i pomocniczych. Aby zapewnić szybkie ukończenie wszystkich operacji konserwacji, dw400c i niższe warstwy magazynu danych mogą zakończyć konserwację poza wyznaczonym oknem obsługi.
Wszystkie nowo utworzone wystąpienia magazynu danych będą miały zdefiniowany przez system harmonogram konserwacji zastosowany podczas wdrażania. Harmonogram można edytować natychmiast po zakończeniu wdrażania.
Podczas wybierania okna obsługi należy wybrać godzinę rozpoczęcia i ustawić maksymalny czas trwania. "Maksymalny czas trwania okna obsługi" określa przedział czasu, w którym będą wykonywane zadania konserwacji. Ten przedział czasu może wynosić od trzech (3) do ośmiu (8) godzin, z minimalnym wymaganiem wynoszącym trzy (3) godziny. W tym okresie magazyn danych będzie tymczasowo w trybie offline, ponieważ dedykowana pula zostanie przeniesiona do uaktualnionej pojemności przy użyciu procesu podobnego do wstrzymywania/wznawiania. W typowych warunkach ta operacja zostanie ukończona znacznie poniżej 30 minut, ale należy pamiętać, że w niektórych przypadkach może to potrwać dłużej. Jeśli na przykład po rozpoczęciu konserwacji istnieją aktywne transakcje, zostaną one anulowane i wycofane, co może spowodować opóźnienia w przywracaniu usługi online. Aby zapobiec tej sytuacji, zalecamy upewnienie się, że na początku okna konserwacji nie są aktywne żadne długoterminowe transakcje.
Wszystkie operacje konserwacji powinny zakończyć się w określonych oknach obsługi, chyba że będziemy musieli wdrożyć aktualizację z uwzględnieniem czasu. Jeśli magazyn danych jest wstrzymany podczas zaplanowanej konserwacji, zostanie zaktualizowany podczas operacji wznawiania. Otrzymasz powiadomienie natychmiast po zakończeniu konserwacji magazynu danych.
Uwaga
- Okna obsługi nie mają zastosowania w przypadku dw400c lub niższych poziomów wydajności. Mogą one być poddawane konserwacji w dowolnym momencie.
- DW400c i niższe mogą napotkać wiele krótkich strat w łączności w różnych momentach w oknie obsługi.
Monitorowanie i alerty
Integracja z powiadomieniami usługi Service Health i monitorem kontroli kondycji zasobów umożliwia klientom informowanie o zbliżających się działaniach konserwacyjnych. Ta automatyzacja korzysta z usługi Azure Monitor. Możesz zdecydować, jak chcesz otrzymywać powiadomienia o zbliżających się zdarzeniach konserwacji. Ponadto możesz wybrać, które zautomatyzowane przepływy pomogą Ci zarządzać przestojami i zminimalizować wpływ operacyjny.
Uwaga
Powiadomienie o 24-godzinnym wyprzedzeniu poprzedza wszystkie zdarzenia konserwacji. W przypadku, gdy jest wymagane wdrożenie aktualizacji o krytycznym czasie, zaawansowane czasy powiadomień mogą być znacznie zmniejszone. Może do tego dojść poza określonym oknem obsługi ze względu na krytyczne znaczenie aktualizacji.
Jeśli otrzymasz powiadomienie z wyprzedzeniem dotyczące planowanej konserwacji, lecz konserwacji nie można przeprowadzić w okresie zawartym w powiadomieniu, otrzymasz powiadomienie dotyczące anulowania. Konserwacja zostanie wznowiona w następnym zaplanowanym okresie konserwacji.
Wszystkie aktywne zdarzenia konserwacji są wyświetlane w sekcji Service Health — planowana konserwacja. Historia usługi Service Health zawiera pełny rekord przeszłych zdarzeń. Konserwację można monitorować za pośrednictwem pulpitu nawigacyjnego portalu sprawdzania kondycji usługi Azure podczas aktywnego zdarzenia.
Dostępność harmonogramu konserwacji
Nawet jeśli planowanie konserwacji nie jest dostępne w wybranym regionie, możesz wyświetlać i edytować harmonogram konserwacji w dowolnym momencie. Gdy planowanie konserwacji stanie się dostępne w Twoim regionie, zidentyfikowany harmonogram natychmiast stanie się aktywny w puli SQL usługi Synapse.
Wyświetlanie harmonogramu konserwacji
Domyślnie wszystkie nowo utworzone wystąpienia magazynu danych mają osiem godzin podstawowe i pomocnicze okno obsługi stosowane podczas wdrażania. Jak wskazano powyżej, można zmienić okna po zakończeniu wdrażania. Żadne czynności konserwacyjne nie będą przeprowadzane poza oknami obsługi bez wcześniejszego powiadomienia.
Aby wyświetlić harmonogram konserwacji zastosowany do puli SQL usługi Synapse, wykonaj następujące kroki:
- Zaloguj się w witrynie Azure Portal.
- Wybierz pulę SQL usługi Synapse, którą chcesz wyświetlić.
- Wybrana pula SQL usługi Synapse zostanie otwarta w bloku przeglądu. Harmonogram konserwacji zastosowany do magazynu danych jest wyświetlany poniżej harmonogramu konserwacji.
Pomiń lub zmień harmonogram konserwacji
Aby zapewnić zgodność z najnowszymi wymogami bezpieczeństwa, nie możemy uwzględnić próśb o pominięcie lub opóźnienie tych aktualizacji. Jednak w zależności od sytuacji może istnieć kilka możliwości dostosowania okna obsługi w bieżącym cyklu:
Jeśli otrzymasz powiadomienie o oczekującej konserwacji i potrzebujesz więcej czasu na zakończenie zadań lub powiadomienie zespołu, możesz zmienić czas rozpoczęcia okna obsługi, o ile zrobisz to przed rozpoczęciem zdefiniowanego okna obsługi. Spowoduje to, że okno zostanie przesunięte do przodu w czasie w ramach cyklu.
Możesz ręcznie wyzwolić konserwację, wstrzymując i wznawiając (lub skalując) dedykowaną pulę SQL po rozpoczęciu cyklu, dla którego odebrano powiadomienie "Oczekujące". Weekendowy cykl konserwacji rozpoczyna się w sobotę o 00:00 UTC. Cykl konserwacji w tygodniu rozpoczyna się we wtorek o godzinie 12:00 UTC.
Mimo że wymagamy co najmniej 3 godzin okna, w typowych warunkach ta operacja zostanie ukończona w nieco poniżej 30 minut. Należy jednak pamiętać, że w niektórych przypadkach może to potrwać dłużej. Jeśli na przykład po rozpoczęciu konserwacji istnieją aktywne transakcje, zostaną one anulowane i wycofane, co może spowodować opóźnienia w przywracaniu usługi online. Aby zapobiec tej sytuacji, zalecamy upewnienie się, że na początku okna konserwacji nie są aktywne żadne długoterminowe transakcje.
Uwaga
- Jeśli zmienisz okno na czas rozpoczęcia wcześniejszy od aktualnego czasu, konserwacja zostanie uruchomiona natychmiast, a jeśli w momencie rozpoczęcia konserwacji będą aktywne transakcje, zostaną one przerwane i wycofane.
- Po zakończeniu wstrzymywania i wznawiania operacji w celu rozpoczęcia konserwacji zamiast otrzymania powiadomienia potwierdzającego zakończenie konserwacji, otrzymasz powiadomienie, że została ona anulowana.
- Jeśli używasz DW400c lub starszego, chociaż możesz zmienić harmonogram konserwacji, nie będzie on przestrzegany, ponieważ jest to niższy poziom wydajności. Jak wspomniano wcześniej, te warstwy magazynów danych można poddać konserwacji w dowolnym momencie cyklu konserwacji.
Identyfikowanie okien podstawowych i pomocniczych
Okna podstawowe i pomocnicze muszą mieć oddzielne zakresy dni. Przykładem jest podstawowe okno wtorek–czwartek i pomocnicze okno sobotnie–niedziela. Terminy "Primary" i "Secondary" powinny być traktowane odpowiednio jako "Window 1" i "Window 2". Oznacza to, że jeden z okien można pobrać w dowolnej kolejności wdrażania uaktualnień konserwacji.
Aby zmienić harmonogram konserwacji puli SQL usługi Synapse, wykonaj następujące kroki:
Zaloguj się w witrynie Azure Portal.
Wybierz pulę SQL usługi Synapse, którą chcesz zaktualizować. Strona zostanie otwarta w bloku przeglądu. Otwórz stronę ustawień harmonogramu konserwacji, wybierając link Podsumowanie harmonogramu konserwacji w bloku przeglądu. Możesz też wybrać opcję Harmonogram konserwacji w menu zasobów po lewej stronie.
Zidentyfikuj preferowany zakres dni dla podstawowego okna obsługi, korzystając z opcji w górnej części strony. Ten wybór określa, czy okno podstawowe będzie występować w dni powszednie, czy w weekend. Wybór spowoduje zaktualizowanie wartości listy rozwijanej. W wersji zapoznawczej niektóre regiony mogą jeszcze nie obsługiwać pełnego zestawu dostępnych opcji Dzień .
Wybierz preferowane okna obsługi podstawowej i pomocniczej, korzystając z pól listy rozwijanej:
- Dzień: Preferowany dzień przeprowadzania konserwacji w wybranym oknie.
- Godzina rozpoczęcia: preferowany czas rozpoczęcia okna obsługi.
- Przedział czasu: preferowany czas trwania przedziału czasu.
Obszar Podsumowanie harmonogramu w dolnej części bloku jest aktualizowany na podstawie wybranych wartości.
Wybierz pozycję Zapisz. Zostanie wyświetlony komunikat z potwierdzeniem, że nowy harmonogram jest teraz aktywny.
W dowolnym momencie możesz zaktualizować opcje Dzień, Godzina rozpoczęcia, Godzina (w tym domyślne okno 8-godzinne). Jeśli zapisujesz harmonogram w regionie, który nie obsługuje planowania konserwacji, zostanie wyświetlony następujący komunikat. Ustawienia są zapisywane i aktywne, gdy funkcja stanie się dostępna w wybranym regionie.
Często zadawane pytania
Jaka jest oczekiwana częstotliwość konserwacji.
Konserwacja może wystąpić więcej niż raz w miesiącu, ponieważ konserwacja może obejmować aktualizacje systemu operacyjnego, poprawki zabezpieczeń i sterowniki, wewnętrzne aktualizacje infrastruktury platformy Azure oraz poprawki i aktualizacje usługi DW. Każdy klient ma dwa razy tygodniowy harmonogram cykli konserwacji między sobotą a niedzielą i wtorek–czwartek.
Jakie zmiany zostały wprowadzone po zakończeniu konserwacji, mimo że wersja mojej dedykowanej puli SQL pozostała taka sama?
Po ukończeniu aktualizacji konserwacyjnej wersja puli SQL może pozostać niezmieniona. Dzieje się tak, ponieważ konserwacja może obejmować aktualizacje systemu operacyjnego, poprawki zabezpieczeń i sterowniki, wewnętrzne aktualizacje infrastruktury platformy Azure oraz poprawki i aktualizacje usługi DW. Tylko wtedy, gdy aktualizacja lub poprawka usługi Synapse DW zostanie uwzględniona w konserwacji, zostanie wyświetlona zmiana wersji dedykowanej puli SQL.
Czy można uaktualnić wersję dedykowanej puli SQL na żądanie?
- Nie, planowana konserwacja obejmuje zarządzanie dedykowanymi pulami SQL. Może jednak istnieć kilka opcji wyzwalania konserwacji po rozpoczęciu cyklu, w zależności od sytuacji. Sprawdzanie pominięcia lub zmiany harmonogramu konserwacji
- Należy pamiętać, że dedykowana pula SQL jest funkcją PaaS (Platform as a Service). Oznacza to, że Microsoft Azure obsługuje wszelkiego rodzaju zadania związane z usługą, takie jak infrastruktura, utrzymanie, aktualizacje i skalowalność. Zaplanowana konserwacja może być śledzona przez ustawienie alertu/powiadomienia, aby otrzymywać informacje o zbliżających się działaniach konserwacyjnych.
Jakie zmiany należy wprowadzić przed ukończeniem lub po zakończeniu konserwacji dedykowanej puli SQL?
- Podczas konserwacji usługa zostanie krótko przełączony w tryb offline, podobnie jak w przypadku wstrzymania, wznowienia lub operacji skalowania. Zazwyczaj ogólna operacja konserwacji jest wykonywana znacznie poniżej 30 minut. Jednak może to potrwać nieco dłużej, w zależności od aktywności bazy danych w oknie obsługi. Zalecamy wstrzymanie operacji ETL, aktualizacji tabel, a zwłaszcza operacji transakcyjnych, aby uniknąć dłuższej niż zwykle konserwacji. Na przykład:
- Jeśli wystąpienie jest bardzo zajęte w zaplanowanym oknie, szczególnie w przypadku częstej aktualizacji i usuwania, operacja konserwacji może trwać dłużej niż zwykle. Aby zmniejszyć prawdopodobieństwo rozszerzonej konserwacji, zalecamy ograniczenie działań do większości zapytań tylko do odczytu względem bazy danych, jeśli to możliwe, a zwłaszcza unikanie długotrwałych zapytań transakcyjnych (zobacz następny element).
- Jeśli po rozpoczęciu konserwacji istnieją aktywne transakcje, są one anulowane i wycofane, co może powodować opóźnienia w przywracaniu usługi online. Aby zapobiec tej sytuacji, zalecamy upewnienie się, że na początku okna konserwacji nie są aktywne żadne długoterminowe transakcje.
Zostaliśmy powiadomieni o zbliżającej się zaplanowanej konserwacji dedykowanej puli SQL o identyfikatorze śledzenia 0000-000, ale została ona następnie anulowana lub przełożona. Co spowodowało anulowanie lub zmianę terminu konserwacji?
Istnieją różne czynniki, które mogą prowadzić do anulowania zaplanowanej konserwacji, w tym akcji, takich jak:
- Wstrzymując lub skalując operacje po otrzymaniu oczekującego powiadomienia o konserwacji podczas inicjowania cyklu.
- Jeśli celujesz w różnych cele poziomu usług (SLO) podczas cyklu konserwacji, takie jak przejście z poziomu dowolnego celu slo wyższego niż DW400c, a następnie skalowanie z powrotem do celu slo niższego lub równego DW400c lub odwrotnie, może wystąpić anulowanie. Dzieje się tak, ponieważ okna obsługi nie mają zastosowania do poziomu wydajności DW400c lub niższego poziomu wydajności i mogą być poddawane konserwacji w dowolnym momencie.
- Wewnętrzne czynniki infrastruktury, takie jak rzeczywiste zmiany planowania planowanej konserwacji przez zespół wydań.
- Konserwacja może zostać anulowana lub zaplanowana ponownie, jeśli monitorowanie wewnętrzne wykryje, że konserwacja trwa dłużej niż oczekiwano. Konserwacja musi zostać ukończona w ramach umów dotyczących poziomu usług (SLA) zdefiniowanych przez ustawienia okna obsługi klienta.
Czy istnieją jakieś najlepsze rozwiązania, które należy wziąć pod uwagę w przypadku obciążenia w oknie obsługi?
- Tak, jeśli to możliwe, wstrzymaj wszystkie obciążenia transakcyjne i ETL w zaplanowanym interwale konserwacji, aby uniknąć błędów lub opóźnień w przywracaniu usługi online. Długotrwałe operacje transakcyjne należy wykonać przed nadchodzącym okresem konserwacji.
- Aby obciążenia były odporne na przerwy spowodowane przez operacje konserwacji, należy użyć logiki ponawiania zarówno dla poziomów połączenia, jak i polecenia (zapytania), stosując dłuższe interwały ponawiania prób i/lub więcej prób, aby wytrzymać rozszerzoną utratę połączenia, która może wydłużyć się do lub więcej niż 30 minut w niektórych przypadkach.
Następne kroki
- Dowiedz się więcej o tworzeniu, wyświetlaniu i zarządzaniu alertami przy użyciu usługi Azure Monitor.
- Dowiedz się więcej o akcjach elementu webhook dla reguł alertów dziennika.
- Dowiedz się więcej o tworzeniu grup akcji i zarządzaniu nimi.
- Dowiedz się więcej o usłudze Azure Service Health.