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 wystąpień bezstanowych, 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ęcia połączenia.

Aby tego uniknąć, należy skonfigurować funkcję RequestDrain , dodając czas trwania opóźnienia zamknięcia wystąpienia w konfiguracji usługi, aby umożliwić opróżnianie istniejących żądań z klastra na uwidocznionych punktach końcowych. Jest to osiągane, ponieważ punkt końcowy anonsowany przez wystąpienie bezstanowe jest usuwany 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 uruchamiania 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ć z 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 domyślnej 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ć powiadomienie 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 ustawiania domyślnych czasów trwania opóźnień na usługę 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ć tego polecenia, 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 przechodzą opróżnianie.
• Mechanizm rozwiązywania skarg oparty na skargach nie spowoduje bezproblemowego opróżniania żądań, ponieważ wyzwala rozwiązanie usługi po awarii. Zgodnie z wcześniejszym opisem należy ją ulepszyć, aby subskrybować powiadomienia o zmianie punktu końcowego przy użyciu skryptu ServiceNotificationFilterDescription.
• Ustawienia nie są honorowane, 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ę poziomu 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 uaktualniania ręcznego

Uwaga

Tryb monitorowanego 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 w miarę postępu uaktualniania. Jeśli zasady kondycji zostaną naruszone, uaktualnienie zostanie wstrzymane 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 przeprowadzania niekonwencjonanych uaktualnień w celu całkowitego obejścia monitorowania kondycji (np. aplikacja jest już w przypadku utraty danych). Uaktualnienie uruchomione w tym trybie zostanie wstrzymane po ukończeniu każdego ud i musi zostać jawnie wznowione przy użyciu wznawiania usługi Resume-ServiceFabricApplicationUpgrade. Gdy uaktualnienie zostanie zawieszone i będzie gotowe do wznowienia przez użytkownika, jego stan uaktualnienia będzie pokazywany jako RollforwardPending (zobacz UpgradeState).

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

Uaktualnianie za pomocą 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. Pełne 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óżnic.

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

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

• Jeśli masz duży pakiet aplikacji odwołujący 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 aktualizacji 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 została zmieniona.

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

Na przykład zacznijmy 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 manifestu 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, zwykle utwórz kompletny pakiet aplikacji, 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 azure Service Fabric PowerShell. 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 azure Service Fabric PowerShell

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

Podczas gdy uaktualnienia można przerzucać do przodu w jednym z trzech trybów (Monitored, UnmonitoredAuto lub UnmonitoredManual), można je wycofać tylko w trybie UnmonitoredAuto lub UnmonitoredManual. Wycofywanie w trybie UnmonitoredAuto działa tak samo jak w przypadku stopniowego przesyłania dalej z wyjątkiem, że wartość domyślna upgradeReplicaSetCheckTimeout jest inna — zobacz Parametry uaktualniania aplikacji. Wycofywanie w trybie niemonitorowanymManual działa tak samo jak w przypadku wycofywania — wycofywanie zostanie wstrzymane po zakończeniu każdego ud 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 niepowodzeniem 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.

Uaktualnij aplikacje, ucząc się, jak używać serializacji danych.

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