Uaktualnianie i aktualizowanie klastrów usługi Azure Service Fabric

  • Artykuł

Klaster usługi Azure Service Fabric jest zasobem, którego jesteś właścicielem, ale jest częściowo zarządzany przez firmę Microsoft. W tym artykule opisano opcje aktualizowania klastra usługi Azure Service Fabric i sposobu ich aktualizowania.

Automatyczne i ręczne uaktualnienia

Niezwykle ważne jest zapewnienie, że klaster usługi Service Fabric zawsze korzysta z obsługiwanej wersji środowiska uruchomieniowego. Za każdym razem, gdy firma Microsoft ogłasza wydanie nowej wersji usługi Service Fabric, poprzednia wersja jest oznaczona do zakończenia wsparcia po upływie co najmniej 60 dni od tej daty. Nowe wersje są ogłaszane na blogu zespołu usługi Service Fabric.

Czternaście dni przed wygaśnięciem wydania klastra jest generowane zdarzenie kondycji, które umieszcza klaster w stanie Kondycja ostrzeżenia . Klaster pozostaje w stanie ostrzeżenia do momentu uaktualnienia do obsługiwanej wersji środowiska uruchomieniowego.

Możesz ustawić klaster tak, aby odbierał automatyczne uaktualnienia usługi Service Fabric w miarę ich wydawania przez firmę Microsoft. Możesz też ręcznie wybrać jedną z listy aktualnie obsługiwanych wersji. Te opcje są dostępne w sekcji Uaktualnienia sieci szkieletowej zasobu klastra usługi Service Fabric.

Wybierz pozycję Automatyczne lub Ręczne uaktualnienia w sekcji

Możesz również ustawić tryb uaktualniania klastra i wybrać wersję środowiska uruchomieniowego przy użyciu szablonu Resource Manager.

Automatyczne uaktualnienia są zalecanym trybem uaktualniania, ponieważ ta opcja zapewnia, że klaster pozostaje w obsługiwanym stanie i korzysta z najnowszych poprawek i funkcji, a jednocześnie umożliwia planowanie aktualizacji w sposób, który jest najmniej uciążliwy dla obciążeń przy użyciu strategii wdrażania falowego .

Uwaga

Jeśli zmienisz istniejący klaster na tryb automatyczny, klaster zostanie zarejestrowany w następnym okresie uaktualniania, począwszy od nowej wersji. Nowe wersje są ogłaszane na blogu zespołu usługi Service Fabric. Na okres uaktualniania wybierana jest najwyższa możliwa ścieżka uaktualnienia. Zobacz obsługiwane wersje. Tryb ręcznego uaktualniania wyzwala natychmiastowe uaktualnienie.

Wdrażanie falowe na potrzeby automatycznych uaktualnień

W przypadku wdrożenia falowego można zminimalizować zakłócenia uaktualniania do klastra, wybierając poziom dojrzałości uaktualnienia, w zależności od obciążenia. Można na przykład skonfigurować potok testowy —>etap —>etap wdrożenia fala produkcyjna dla różnych klastrów usługi Service Fabric, aby przetestować zgodność uaktualnienia środowiska uruchomieniowego przed zastosowaniem go do obciążeń produkcyjnych.

Aby wyrazić zgodę na wdrożenie falowe, określ jedną z następujących wartości falowych dla klastra (w szablonie wdrożenia):

  • Wave 0: klastry są aktualizowane zaraz po wydaniu nowej kompilacji usługi Service Fabric. Przeznaczony dla klastrów testowych/deweloperskich.
  • Fala 1: Klastry są aktualizowane jeden tydzień (siedem dni) po wydaniu nowej kompilacji. Przeznaczony dla klastrów wstępnie prod/przejściowych.
  • Fala 2: Klastry są aktualizowane dwa tygodnie (14 dni) po wydaniu nowej kompilacji. Przeznaczony dla klastrów produkcyjnych.

Możesz zarejestrować się w celu otrzymywania powiadomień e-mail z linkami, aby uzyskać dalszą pomoc, jeśli uaktualnienie klastra zakończy się niepowodzeniem. Aby rozpocząć pracę , zobacz Wdrażanie na platformie Wave, aby uzyskać informacje o automatycznych uaktualnieniach .

Fazy automatycznego uaktualniania

Firma Microsoft utrzymuje kod i konfigurację środowiska uruchomieniowego usługi Service Fabric działającą w klastrze platformy Azure. Przeprowadzamy automatyczne monitorowanie uaktualnień oprogramowania zgodnie z potrzebami. Te uaktualnienia mogą być kodem, konfiguracją lub obydwoma. Aby zminimalizować wpływ tych uaktualnień na aplikacje, są one wykonywane w następujących fazach:

Faza 1. Uaktualnienie jest wykonywane przy użyciu wszystkich zasad kondycji klastra

W tej fazie uaktualnienia są kontynuowane po jednej domenie uaktualnienia, a aplikacje uruchomione w klastrze będą nadal działać bez żadnych przestojów. Zasady kondycji klastra (dla kondycji węzła i kondycji aplikacji) są zgodne podczas uaktualniania.

Jeśli zasady kondycji klastra nie zostaną spełnione, uaktualnienie zostanie wycofane i zostanie wysłana wiadomość e-mail do właściciela subskrypcji. Wiadomość e-mail zawiera następujące informacje:

  • Powiadomienie, że musieliśmy wycofać uaktualnienie klastra.
  • Sugerowane działania naprawcze, jeśli istnieją.
  • Liczba dni (n) do czasu wykonania fazy 2.

Spróbujemy wykonać to samo uaktualnienie jeszcze kilka razy w przypadku niepowodzenia uaktualnień ze względów infrastruktury. Po upływie n dni od daty wysłania wiadomości e-mail przechodzimy do fazy 2.

Jeśli zasady kondycji klastra zostaną spełnione, uaktualnienie zostanie uznane za pomyślne i oznaczone jako ukończone. Taka sytuacja może wystąpić podczas początkowego uaktualnienia lub dowolnego ponownego uruchomienia uaktualnienia w tej fazie. Nie ma potwierdzenia pomyślnego uruchomienia wiadomości e-mail, aby uniknąć wysyłania nadmiernych wiadomości e-mail. Odbieranie wiadomości e-mail oznacza wyjątek od normalnych operacji. Oczekujemy, że większość uaktualnień klastra zakończy się pomyślnie bez wpływu na dostępność aplikacji.

Faza 2. Uaktualnienie jest wykonywane tylko przy użyciu domyślnych zasad kondycji

Zasady kondycji w tej fazie są ustawiane w taki sposób, że liczba aplikacji, które były w dobrej kondycji na początku uaktualnienia, pozostaje taka sama podczas procesu uaktualniania. Podobnie jak w fazie 1, uaktualnienia fazy 2 kontynuują jedną domenę uaktualniania jednocześnie, a aplikacje uruchomione w klastrze będą nadal działać bez żadnych przestojów. Zasady kondycji klastra (kombinacja kondycji węzła i kondycja wszystkich aplikacji uruchomionych w klastrze) są zgodne podczas uaktualniania.

Jeśli zasady kondycji klastra nie zostaną spełnione, uaktualnienie zostanie wycofane. Następnie do właściciela subskrypcji zostanie wysłana wiadomość e-mail. Wiadomość e-mail zawiera następujące informacje:

  • Powiadomienie, że musieliśmy wycofać uaktualnienie klastra.
  • Sugerowane działania naprawcze, jeśli istnieją.
  • Liczba dni (n) do czasu wykonania fazy 3.

Spróbujemy wykonać to samo uaktualnienie jeszcze kilka razy w przypadku niepowodzenia uaktualnień ze względów infrastruktury. Wiadomość e-mail z przypomnieniem jest wysyłana kilka dni przed upływem n dni. Po upływie n dni od daty wysłania wiadomości e-mail przejdziemy do fazy 3. Wiadomości e-mail wysyłane w fazie 2 muszą być traktowane poważnie i należy podjąć działania naprawcze.

Jeśli zasady kondycji klastra zostaną spełnione, uaktualnienie zostanie uznane za pomyślne i oznaczone jako ukończone. Może się to zdarzyć podczas początkowego uaktualnienia lub dowolnego ponownego uruchomienia uaktualnienia w tej fazie. Nie ma potwierdzenia pomyślnego uruchomienia wiadomości e-mail.

Faza 3. Uaktualnienie jest wykonywane przy użyciu agresywnych zasad kondycji

Te zasady kondycji w tej fazie są przeznaczone do ukończenia uaktualniania, a nie kondycji aplikacji. W tej fazie kończy się kilka uaktualnień klastra. Jeśli klaster przechodzi do tej fazy, istnieje prawdopodobieństwo, że aplikacja stanie się w złej kondycji i/lub utraci dostępność.

Podobnie jak w przypadku pozostałych dwóch faz, uaktualnienia fazy 3 są kontynuowane po jednej domenie uaktualnienia naraz.

Jeśli zasady kondycji klastra nie zostaną spełnione, uaktualnienie zostanie wycofane. Spróbujemy wykonać to samo uaktualnienie jeszcze kilka razy w przypadku niepowodzenia uaktualnień ze względów infrastruktury. Następnie klaster zostanie przypięty, aby nie otrzymywać już pomocy technicznej i/lub uaktualnień.

Wiadomość e-mail z informacjami jest wysyłana do właściciela subskrypcji wraz z akcjami zaradczymi. Nie oczekujemy, że żadne klastry przejdą do stanu, w którym faza 3 zakończyła się niepowodzeniem.

Jeśli zasady kondycji klastra zostaną spełnione, uaktualnienie zostanie uznane za pomyślne i oznaczone jako ukończone. Może się to zdarzyć podczas początkowego uaktualnienia lub dowolnego ponownego uruchomienia uaktualnienia w tej fazie. Nie ma potwierdzenia pomyślnego uruchomienia wiadomości e-mail.

Zasady niestandardowe dla uaktualnień ręcznych

Można określić zasady niestandardowe na potrzeby ręcznych uaktualnień klastra. Te zasady są stosowane za każdym razem, gdy wybierasz nową wersję środowiska uruchomieniowego, co wyzwala system w celu rozpoczęcia uaktualniania klastra. Jeśli zasady nie zostaną zastąpione, zostaną użyte wartości domyślne. Aby uzyskać więcej informacji, zobacz Ustawianie niestandardowych policji na potrzeby ręcznych uaktualnień.

Inne aktualizacje klastra

Poza uaktualnieniem środowiska uruchomieniowego może być konieczne wykonanie wielu innych akcji, aby zapewnić aktualność klastra, w tym następujące czynności:

Zarządzanie certyfikatami

Usługa Service Fabric używa certyfikatów serwera X.509 , które są określone podczas tworzenia klastra w celu zabezpieczenia komunikacji między węzłami klastra i uwierzytelniania klientów. Możesz dodawać, aktualizować lub usuwać certyfikaty dla klastra i klienta w Azure Portal lub przy użyciu programu PowerShell/interfejsu wiersza polecenia platformy Azure. Aby dowiedzieć się więcej, przeczytaj artykuł Dodawanie lub usuwanie certyfikatów

Otwieranie portów aplikacji

Porty aplikacji można zmienić, zmieniając właściwości zasobu Load Balancer skojarzone z typem węzła. Możesz użyć Azure Portal lub użyć programu PowerShell/interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji, zobacz Otwieranie portów aplikacji dla klastra.

Definiowanie właściwości węzła

Czasami warto upewnić się, że niektóre obciążenia działają tylko na niektórych typach węzłów w klastrze. Na przykład niektóre obciążenia mogą wymagać procesorów GPU lub dysków SSD, podczas gdy inne mogą nie. Dla każdego z typów węzłów w klastrze można dodać niestandardowe właściwości węzła do węzłów klastra. Ograniczenia umieszczania to instrukcje dołączone do poszczególnych usług, które wybierają co najmniej jedną właściwości węzła. Ograniczenia umieszczania określają, gdzie powinny być uruchamiane usługi.

Aby uzyskać szczegółowe informacje na temat używania ograniczeń umieszczania, właściwości węzła i sposobu ich definiowania, przeczytaj właściwości węzła i ograniczenia umieszczania.

Dodawanie metryk pojemności

Dla każdego z typów węzłów można dodać niestandardowe metryki pojemności, które mają być używane w aplikacjach do raportowania obciążenia. Aby uzyskać szczegółowe informacje na temat używania metryk pojemności do raportowania obciążenia, zapoznaj się z dokumentami klastra usługi Service Fabric Resource Manager opisującym klasteri metryki i obciążenie.

Dostosowywanie ustawień klastra

W klastrze można dostosować wiele różnych ustawień konfiguracji, takich jak poziom niezawodności właściwości klastra i węzła. Aby uzyskać więcej informacji, przeczytaj ustawienia sieci szkieletowej klastra usługi Service Fabric.

Uaktualnianie obrazów systemu operacyjnego dla węzłów klastra

Włączenie automatycznych uaktualnień obrazów systemu operacyjnego dla węzłów klastra usługi Service Fabric jest najlepszym rozwiązaniem. W tym celu należy wykonać kilka wymagań dotyczących klastra i kroków. Inną opcją jest użycie aplikacji Patch Orchestration Application (POA), aplikacji usługi Service Fabric, która automatyzuje stosowanie poprawek systemu operacyjnego w klastrze usługi Service Fabric bez przestojów. Aby dowiedzieć się więcej o tych opcjach, zobacz Patch the Windows operating system in your Service Fabric cluster (Stosowanie poprawek systemu operacyjnego Windows w klastrze usługi Service Fabric).

Następne kroki