Uaktualnianie aplikacji usługi Service Fabric: Tematy zaawansowane

Dodawanie lub usuwanie typów usług podczas uaktualniania aplikacji

Jeśli nowy typ usługi zostanie dodany do opublikowanej aplikacji w ramach uaktualnienia, nowy typ usługi zostanie dodany do wdrożonej aplikacji. Takie uaktualnienie nie ma wpływu na żadne wystąpienia usługi, które były już częścią aplikacji, ale wystąpienie dodanego typu usługi musi zostać utworzone, aby nowy typ usługi był aktywny (zobacz New-ServiceFabricService).

Podobnie typy usług można usunąć z aplikacji w ramach uaktualnienia. Jednak przed kontynuowaniem uaktualniania należy usunąć wszystkie wystąpienia usługi typu usługi do usunięcia (zobacz Remove-ServiceFabricService).

Unikaj przerywania połączeń podczas planowanych przestojów usługi bezstanowej

W przypadku planowanych przestojów bezstanowych wystąpień, takich jak uaktualnianie aplikacji/klastra lub dezaktywacja węzła, połączenia mogą zostać usunięte, ponieważ uwidoczniony punkt końcowy zostanie usunięty po awarii wystąpienia, co powoduje wymuszone zamknięcie połączenia.

Aby tego uniknąć, skonfiguruj funkcję RequestDrain , dodając czas trwania opóźnienia zamknięcia wystąpienia w konfiguracji usługi, aby zezwolić istniejącym żądaniom z klastra na opróżnianie uwidocznionych punktów końcowych. Jest to osiągane w miarę usuwania punktu końcowego anonsowanego przez wystąpienie bezstanowe przed rozpoczęciem opóźnienia przed zamknięciem wystąpienia. To opóźnienie umożliwia bezproblemowe opróżnianie istniejących żądań, zanim wystąpienie rzeczywiście ulegnie awarii. Klienci są powiadamiani o zmianie punktu końcowego przez funkcję wywołania zwrotnego w momencie rozpoczęcia opóźnienia, dzięki czemu mogą ponownie rozpoznać punkt końcowy i uniknąć wysyłania nowych żądań do wystąpienia, które spada. Te żądania mogą pochodzić od klientów przy użyciu zwrotnego serwera proxy lub interfejsu API rozpoznawania punktów końcowych usługi z modelem powiadomień (ServiceNotificationFilterDescription) w celu zaktualizowania punktów końcowych.

Konfiguracja usługi

Istnieje kilka sposobów konfigurowania opóźnienia po stronie usługi.

• Podczas tworzenia nowej usługi określ wartość -InstanceCloseDelayDuration:

  New-ServiceFabricService -Stateless [-ServiceName] <Uri> -InstanceCloseDelayDuration <TimeSpan>
  

• Podczas definiowania usługi w sekcji wartości domyślnych w manifeście aplikacji przypisz InstanceCloseDelayDurationSeconds właściwość:

        <StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]" InstanceCloseDelayDurationSeconds="15">
            <SingletonPartition />
        </StatelessService>
  

• Podczas aktualizowania istniejącej usługi określ wartość -InstanceCloseDelayDuration:

  Update-ServiceFabricService [-Stateless] [-ServiceName] <Uri> [-InstanceCloseDelayDuration <TimeSpan>]`
  

• Podczas tworzenia lub aktualizowania istniejącej usługi za pomocą szablonu usługi ARM określ InstanceCloseDelayDuration wartość (minimalna obsługiwana wersja interfejsu API: 2020-03-01):

  {
    "apiVersion": "2020-03-01",
    "type": "Microsoft.ServiceFabric/clusters/applications/services",
    "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
    "location": "[variables('clusterLocation')]",
    "dependsOn": [
      "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
    ],
    "properties": {
      "provisioningState": "Default",
      "serviceKind": "Stateless",
      "serviceTypeName": "[parameters('serviceTypeName')]",
      "instanceCount": "-1",
      "partitionDescription": {
        "partitionScheme": "Singleton"
      },
      "serviceLoadMetrics": [],
      "servicePlacementPolicies": [],
      "defaultMoveCost": "",
      "instanceCloseDelayDuration": "00:00:30.0"
    }
  }
  

Konfiguracja klientów

Aby otrzymywać powiadomienia po zmianie punktu końcowego, klienci powinni zarejestrować wywołanie zwrotne, zobacz Przykład ServiceNotificationFilterDescription. Powiadomienie o zmianie oznacza, że punkty końcowe uległy zmianie, klient powinien ponownie rozpoznać punkty końcowe i nie używać punktów końcowych, które nie są już anonsowane, ponieważ wkrótce spadną.

Opcjonalne przesłonięcia uaktualnienia

Oprócz ustawienia domyślnych czasów trwania opóźnień dla usługi można również zastąpić opóźnienie podczas uaktualniania aplikacji/klastra przy użyciu tej samej opcji (InstanceCloseDelayDurationSec):

Start-ServiceFabricApplicationUpgrade [-ApplicationName] <Uri> [-ApplicationTypeVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Start-ServiceFabricClusterUpgrade [-CodePackageVersion] <String> [-ClusterManifestVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Przesłonięć czas trwania opóźnienia dotyczy tylko wywołanego wystąpienia uaktualnienia i nie zmienia konfiguracji opóźnień poszczególnych usług. Można na przykład użyć tej funkcji, aby określić opóźnienie 0 w celu pominięcia wszelkich wstępnie skonfigurowanych opóźnień uaktualniania.

Uwaga

• Ustawienia opróżniania żądań nie będą mogły uniemożliwić modułowi równoważenia obciążenia platformy Azure wysyłanie nowych żądań do punktów końcowych, które są w trakcie opróżniania.
• Mechanizm rozwiązywania skarg nie spowoduje bezproblemowego opróżniania żądań, ponieważ wyzwala rozwiązanie usługi po awarii. Zgodnie z wcześniejszym opisem należy je ulepszyć, aby subskrybować powiadomienia o zmianie punktu końcowego przy użyciu klasy ServiceNotificationFilterDescription.
• Ustawienia nie są uznawane, gdy uaktualnienie jest bez wpływu, tj. gdy repliki nie zostaną wyłączone podczas uaktualniania.
• Maksymalna wartość klasy InstanceCloseDelayDuration, którą można skonfigurować w opisie usługi lub parametru InstanceCloseDelayDurationSec w opisie uaktualnienia, nie może być większa niż konfiguracja klastra FailoverManager.MaxInstanceCloseDelayDurationInSeconds, która domyślnie wynosi 1800 sekund. Aby zaktualizować maksymalną wartość, należy zaktualizować konfigurację na poziomie klastra. Ta konfiguracja jest dostępna tylko w środowisku uruchomieniowym w wersji 9.0 lub nowszej.

Uwaga

Tę funkcję można skonfigurować w istniejących usługach przy użyciu polecenia cmdlet Update-ServiceFabricService lub szablonu usługi ARM, jak wspomniano powyżej, gdy wersja kodu klastra jest 7.1.XXX lub nowsza.

Tryb ręcznego uaktualniania

Uwaga

Tryb monitorowania uaktualniania jest zalecany dla wszystkich uaktualnień usługi Service Fabric. Tryb uaktualniania NiemonitorowanyManual powinien być brany pod uwagę tylko w przypadku nieudanych lub zawieszonych uaktualnień.

W trybie monitorowym usługa Service Fabric stosuje zasady kondycji, aby upewnić się, że aplikacja jest w dobrej kondycji podczas postępu uaktualniania. Jeśli zasady kondycji zostaną naruszone, uaktualnienie zostanie zawieszone lub automatycznie wycofane w zależności od określonego błęduAction.

W trybie niemonitorowanymManual administrator aplikacji ma całkowitą kontrolę nad postępem uaktualniania. Ten tryb jest przydatny podczas stosowania niestandardowych zasad oceny kondycji lub wykonywania niekonwencjonanych uaktualnień w celu całkowitego obejścia monitorowania kondycji (np. aplikacja jest już w utracie danych). Uaktualnienie uruchomione w tym trybie zostanie wstrzymane po zakończeniu każdego jednostki zdefiniowanej przez użytkownika i musi zostać jawnie wznowione przy użyciu klasy Resume-ServiceFabricApplicationUpgrade. Gdy uaktualnienie zostanie zawieszone i będzie gotowe do wznowienia przez użytkownika, jego stan uaktualnienia będzie wyświetlany jako RollforwardPending (zobacz UpgradeState).

Na koniec tryb UnmonitoredAuto jest przydatny do przeprowadzania szybkich iteracji uaktualniania podczas tworzenia lub testowania usługi, ponieważ żadne dane wejściowe użytkownika nie są wymagane i nie są oceniane żadne zasady kondycji aplikacji.

Uaktualnianie przy użyciu pakietu różnicowego

Zamiast aprowizować kompletny pakiet aplikacji, uaktualnienia mogą być również wykonywane przez aprowizowanie pakietów różnic, które zawierają tylko zaktualizowane pakiety kodu/konfiguracji/danych wraz z kompletnym manifestem aplikacji i kompletnymi manifestami usługi. Kompletne pakiety aplikacji są wymagane tylko do początkowej instalacji aplikacji w klastrze. Kolejne uaktualnienia mogą pochodzić z kompletnych pakietów aplikacji lub pakietów różnicowych.

Wszelkie odwołania w manifeście aplikacji lub manifeście usługi pakietu różnicowego, którego nie można znaleźć w pakiecie aplikacji, są automatycznie zastępowane aktualnie aprowizowaną wersją.

Scenariusze korzystania z pakietu różnic są następujące:

• Jeśli masz duży pakiet aplikacji, który odwołuje się do kilku plików manifestu usługi i/lub kilku pakietów kodu, pakietów konfiguracji lub pakietów danych.
• Jeśli masz system wdrażania, który generuje układ kompilacji bezpośrednio z procesu kompilacji aplikacji. W takim przypadku, mimo że kod nie uległ zmianie, nowo utworzone zestawy uzyskują inną sumę kontrolną. Użycie pełnego pakietu aplikacji wymaga zaktualizowania wersji we wszystkich pakietach kodu. Używając pakietu różnicowego, należy podać tylko pliki, które uległy zmianie i pliki manifestu, w których wersja uległa zmianie.

Po uaktualnieniu aplikacji przy użyciu programu Visual Studio pakiet różnicowy jest publikowany automatycznie. Aby ręcznie utworzyć pakiet różnicowy, manifest aplikacji i manifesty usługi muszą zostać zaktualizowane, ale tylko zmienione pakiety powinny zostać uwzględnione w końcowym pakiecie aplikacji.

Zacznijmy na przykład od następującej aplikacji (numery wersji podane w celu ułatwienia zrozumienia):

app1           1.0.0
  service1     1.0.0
    code       1.0.0
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

Załóżmy, że chcesz zaktualizować tylko pakiet kodu usługi Service1 przy użyciu pakietu różnicowego. Zaktualizowana aplikacja ma następujące zmiany wersji:

app1           2.0.0      <-- new version
  service1     2.0.0      <-- new version
    code       2.0.0      <-- new version
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

W takim przypadku zaktualizujesz manifest aplikacji do wersji 2.0.0 i manifest usługi dla usługi Service1, aby odzwierciedlić aktualizację pakietu kodu. Folder pakietu aplikacji będzie miał następującą strukturę:

app1/
  service1/
    code/

Innymi słowy, utwórz cały pakiet aplikacji normalnie, a następnie usuń wszystkie foldery kodu/konfiguracji/pakietu danych, dla których wersja nie została zmieniona.

Uaktualnianie parametrów aplikacji niezależnie od wersji

Czasami pożądane jest zmianę parametrów aplikacji usługi Service Fabric bez zmiany wersji manifestu. Można to zrobić wygodnie, używając flagi -ApplicationParameter z poleceniem cmdlet Start-ServiceFabricApplicationUpgrade programu PowerShell usługi Azure Service Fabric. Załóżmy, że aplikacja usługi Service Fabric ma następujące właściwości:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "1"; "NewParameter" = "testBefore" }

Teraz uaktualnij aplikację przy użyciu polecenia cmdlet Start-ServiceFabricApplicationUpgrade . W tym przykładzie przedstawiono monitorowane uaktualnienie, ale można również użyć niemonitorowanego uaktualnienia. Aby wyświetlić pełny opis flag akceptowanych przez to polecenie cmdlet, zobacz dokumentację modułu Programu PowerShell usługi Azure Service Fabric

PS C:\> $appParams = @{ "ImportantParameter" = "2"; "NewParameter" = "testAfter"}

PS C:\> Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/Application1 -ApplicationTypeVers
ion 1.0.0 -ApplicationParameter $appParams -Monitored

Po uaktualnieniu upewnij się, że aplikacja ma zaktualizowane parametry i tę samą wersję:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "2"; "NewParameter" = "testAfter" }

Wycofywanie uaktualnień aplikacji

Uaktualnienia można przerzucać do przodu w jednym z trzech trybów (Monitored, UnmonitoredAuto lub UnmonitoredManual), ale można je wycofać tylko w trybie UnmonitoredAuto lub UnmonitoredManual. Wycofywanie w trybie UnmonitoredAuto działa tak samo jak w przypadku przejścia do przodu z wyjątkiem, że domyślna wartość UpgradeReplicaSetCheckTimeout jest inna — zobacz Parametry uaktualniania aplikacji. Wycofywanie w trybie niemonitorowanymManual działa tak samo jak w przypadku wycofywania do przodu — wycofanie zostanie wstrzymane po zakończeniu każdego użytkownika i musi zostać jawnie wznowione przy użyciu funkcji Resume-ServiceFabricApplicationUpgrade, aby kontynuować wycofywanie .

Wycofywanie można wyzwalać automatycznie, gdy zasady kondycji uaktualnienia w trybie monitorowanym z funkcją FailureAction wycofywania są naruszane (zobacz Parametry uaktualniania aplikacji) lub jawnie przy użyciu polecenia Start-ServiceFabricApplicationRollback.

Podczas wycofywania wartość UpgradeReplicaSetCheckTimeout i tryb nadal można zmienić w dowolnym momencie przy użyciu polecenia Update-ServiceFabricApplicationUpgrade.

Następne kroki

Uaktualnianie aplikacji przy użyciu programu Visual Studio przeprowadzi Cię przez proces uaktualniania aplikacji przy użyciu programu Visual Studio.

Uaktualnianie aplikacji przy użyciu programu PowerShell przeprowadzi Cię przez proces uaktualniania aplikacji przy użyciu programu PowerShell.

Kontrolowanie sposobu uaktualniania aplikacji przy użyciu parametrów uaktualniania.

Uściślij zgodność aplikacji, ucząc się, jak używać serializacji danych.

Rozwiąż typowe problemy z uaktualnieniami aplikacji, korzystając z kroków opisanych w temacie Rozwiązywanie problemów z uaktualnieniami aplikacji.