Upgrade aplikace Service Fabric: Pokročilá témata

  • Článek

Přidání nebo odebrání typů služeb během upgradu aplikace

Pokud je do publikované aplikace přidán nový typ služby v rámci upgradu, přidá se nový typ služby do nasazené aplikace. Takový upgrade nemá vliv na žádné instance služby, které již byly součástí aplikace, ale instance přidané služby musí být vytvořena, aby nový typ služby byl aktivní (viz New-ServiceFabricService).

Podobně lze typy služeb odebrat z aplikace v rámci upgradu. Všechny instance služby typu to-be-removed však musí být odebrány před pokračováním v upgradu (viz Remove-ServiceFabricService).

Vyhněte se výpadkům připojení během plánovaného výpadku bezstavové služby.

V případě plánovaných výpadků bezstavových instancí, jako je upgrade aplikací nebo clusteru nebo deaktivace uzlu, se připojení můžou vyřadit, protože se vystavený koncový bod po výpadku instance odebere, což vede k vynuceným ukončením připojení.

Abyste tomu předešli, nakonfigurujte funkci RequestDrain přidáním doby trvání zpoždění u instance v konfiguraci služby, aby se stávající požadavky z clusteru mohly vyprázdnit z vystavených koncových bodů. Toho se dosahuje tak, že se koncový bod inzerovaný bezstavovou instancí odebere před zahájením zpoždění před uzavřením instance. Toto zpoždění umožňuje, aby se stávající požadavky řádně vyčerpaly předtím, než instance skutečně přestane fungovat. Klienti jsou na změnu koncového bodu upozorněni funkcí zpětného volání v okamžiku spuštění zpoždění, aby mohli koncový bod přeložit a nemuseli odesílat nové požadavky do instance, která nefunguje. Tyto požadavky můžou pocházet od klientů, kteří používají reverzní proxy server nebo rozhraní API pro překlad koncových bodů služby s modelem oznámení (ServiceNotificationFilterDescription) pro aktualizaci koncových bodů.

Konfigurace služeb

Existuje několik způsobů, jak nakonfigurovat zpoždění na straně služby.

  • Při vytváření nové služby zadejte -InstanceCloseDelayDuration:

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

  • Při definování služby v části defaults v manifestu aplikace přiřaďte InstanceCloseDelayDurationSeconds vlastnost :

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

  • Při aktualizaci existující služby zadejte -InstanceCloseDelayDuration:

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

  • Při vytváření nebo aktualizaci existující služby prostřednictvím šablony ARM zadejte InstanceCloseDelayDuration hodnotu (minimální podporovaná verze rozhraní 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"
  }
}

Konfigurace klienta

Pokud chcete dostávat oznámení o změně koncového bodu, klienti by si měli zaregistrovat zpětné volání podle ukázky ServiceNotificationFilterDescription. Oznámení o změně indikuje, že se změnily koncové body, klient by měl koncové body přeložit znovu a nepoužívat koncové body, které se už neinzerují, protože brzy přestanou fungovat.

Volitelná přepsání upgradu

Kromě nastavení výchozí doby zpoždění pro každou službu můžete také přepsat zpoždění během upgradu aplikace nebo clusteru pomocí stejné možnosti (InstanceCloseDelayDurationSec):

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

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

Přepsaná doba zpoždění se vztahuje pouze na vyvolanou instanci upgradu a jinak nemění jednotlivé konfigurace zpoždění služby. Můžete ho například použít k určení zpoždění 0 , aby se přeskočí všechna předkonfigurovaná zpoždění upgradu.

Poznámka

  • Nastavení pro vyprázdnění požadavků nebude moct zabránit nástroji pro vyrovnávání zatížení Azure v odesílání nových požadavků do koncových bodů, které procházejí vyprázdněním.
  • Mechanismus řešení na základě stížností nebude mít za následek řádné vyprázdnění požadavků, protože po selhání aktivuje řešení služby. Jak je popsáno výše, místo toho by se toto nastavení mělo vylepšit a přihlásit se k odběru oznámení o změnách koncových bodů pomocí ServiceNotificationFilterDescription.
  • Nastavení se nedodrží, pokud je upgrade bez dopadu, tj. když během upgradu nebudou repliky vyřazeny.
  • Maximální hodnota InstanceCloseDelayDuration, kterou je možné nakonfigurovat v popisu služby nebo InstanceCloseDelayDurationSec v popisu upgradu, nemůže být větší než hodnota konfigurace clusteru FailoverManager.MaxInstanceCloseDelayDurationInSeconds, která je ve výchozím nastavení 1800 sekund. Pokud chcete aktualizovat maximální hodnotu, je potřeba aktualizovat konfiguraci na úrovni clusteru. Tato konfigurace je k dispozici pouze v modulu runtime verze 9.0 nebo novější.

Poznámka

Tuto funkci je možné nakonfigurovat v existujících službách pomocí rutiny Update-ServiceFabricService nebo šablony ARM, jak je uvedeno výše, pokud je verze kódu clusteru 7.1.XXX nebo vyšší.

Režim ručního upgradu

Poznámka

Režim monitorovaného upgradu se doporučuje pro všechny upgrady Service Fabric. Režim nemonitorovanýmanuální upgrade by se měl brát v úvahu pouze u neúspěšných nebo pozastavených upgradů.

V monitorovaném režimu Service Fabric používá zásady stavu, aby zajistilo, že aplikace bude během upgradu v pořádku. Pokud dojde k porušení zásad stavu, upgrade se buď pozastaví, nebo se automaticky vrátí zpět v závislosti na zadané akci FailureAction.

V režimu NemonitorovanýManual má správce aplikace úplnou kontrolu nad průběhem upgradu. Tento režim je užitečný, když používáte vlastní zásady vyhodnocení stavu nebo provádíte nekonvenční upgrady k úplnému obejití monitorování stavu (např. aplikace už je ve ztrátě dat). Upgrade spuštěný v tomto režimu se po dokončení každého UD pozastaví a musí být explicitně obnoven pomocí Resume-ServiceFabricApplicationUpgrade. Když je upgrade pozastavený a připravený k obnovení uživatelem, jeho stav upgradu se zobrazí RollforwardPending (viz UpgradeState).

Režim UnmonitoredAuto je užitečný pro provádění rychlých iterací upgradu během vývoje nebo testování služby, protože není vyžadován žádný uživatelský vstup a nejsou vyhodnocovány žádné zásady stavu aplikace.

Upgrade s rozdílovým balíčkem

Místo zřizování kompletního balíčku aplikace je možné upgrade provést také zřízením rozdílových balíčků, které obsahují pouze aktualizované balíčky kódu, konfigurace a dat, spolu s úplným manifestem aplikace a kompletními manifesty služby. Kompletní balíčky aplikací se vyžadují jenom pro počáteční instalaci aplikace do clusteru. Následné upgrady můžou být buď z úplných balíčků aplikací, nebo rozdílových balíčků.

Všechny odkazy v manifestu aplikace nebo manifestech služby na rozdílový balíček, který nelze v balíčku aplikace najít, se automaticky nahradí aktuálně zřízenou verzí.

Scénáře použití rozdílového balíčku:

  • Pokud máte velký balíček aplikace, který odkazuje na několik souborů manifestu služby nebo několik balíčků kódu, konfiguračních balíčků nebo balíčků dat.
  • Pokud máte systém nasazení, který generuje rozložení sestavení přímo z procesu sestavení aplikace. V tomto případě, i když se kód nezměnil, získají nově vytvořená sestavení jiný kontrolní součet. Použití úplného balíčku aplikace by vyžadovalo aktualizaci verze ve všech balíčcích kódu. Pomocí rozdílového balíčku zadáte pouze soubory, které se změnily, a soubory manifestu, u kterých se změnila verze.

Při upgradu aplikace pomocí sady Visual Studio se automaticky publikuje rozdílový balíček. Chcete-li ručně vytvořit rozdílový balíček, je třeba aktualizovat manifest aplikace a manifesty služby, ale do konečného balíčku aplikace by měly být zahrnuty pouze změněné balíčky.

Začněme například s následující aplikací (čísla verzí jsou poskytnuta pro snadnější pochopení):

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

Předpokládejme, že chcete aktualizovat pouze balíček kódu service1 pomocí balíčku diff. Vaše aktualizovaná aplikace obsahuje následující změny verze:

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

V tomto případě aktualizujete manifest aplikace na verzi 2.0.0 a manifest služby pro service1 tak, aby odrážel aktualizaci balíčku kódu. Složka pro balíček aplikace by měla následující strukturu:

app1/
  service1/
    code/

Jinými slovy, normálně vytvořte úplný balíček aplikace a pak odeberte všechny složky balíčků s kódem, konfigurací nebo daty, u kterých se verze nezměnila.

Upgrade parametrů aplikace nezávisle na verzi

Někdy je žádoucí změnit parametry aplikace Service Fabric bez změny verze manifestu. Můžete to provést pohodlně pomocí příznaku -ApplicationParameter s rutinou Prostředí PowerShell Start-ServiceFabricApplicationUpgrade Azure Service Fabric. Předpokládejme aplikaci Service Fabric s následujícími vlastnostmi:

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" }

Teď aplikaci upgradujte pomocí rutiny Start-ServiceFabricApplicationUpgrade . Tento příklad ukazuje monitorovaný upgrade, ale dá se použít i nemonitorovaný upgrade. Úplný popis příznaků akceptovaných touto rutinou najdete v referenčních informacích k modulu 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 upgradu ověřte, že má aplikace aktualizované parametry a stejnou verzi:

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" }

Vrácení upgradů aplikací zpět

Zatímco upgrady lze vrátit do dalšího režimu v jednom ze tří režimů (Monitorované, NesledovanéAuto nebo NemonitorovanéManual), lze je vrátit zpět pouze v režimu NeslededAuto nebo NemonitorovanýManual . Vrácení zpět v režimu UnmonitoredAuto funguje stejně jako vrácení vpřed s výjimkou jiné výchozí hodnoty UpgradeReplicaSetCheckTimeout – viz Parametry upgradu aplikace. Vrácení zpět v režimu UnmonitoredManual funguje stejně jako vrácení vpřed – vrácení zpět se po dokončení každého UD pozastaví a musí být explicitně obnoveno pomocí Resume-ServiceFabricApplicationUpgrade , aby bylo možné pokračovat se vrácením zpět.

Vrácení zpět se může aktivovat automaticky, když dojde k porušení zásad stavu upgradu v monitorovaném režimu s chybnou akcívrácení zpět (viz Parametry upgradu aplikace) nebo explicitně pomocí funkce Start-ServiceFabricApplicationRollback.

Během vrácení zpět lze hodnotu UpgradeReplicaSetCheckTimeout a režim stále kdykoli změnit pomocí Update-ServiceFabricApplicationUpgrade.

Další kroky

Upgrade aplikace pomocí sady Visual Studio vás provede upgradem aplikace pomocí sady Visual Studio.

Upgrade aplikace pomocí PowerShellu vás provede upgradem aplikace pomocí PowerShellu.

Pomocí parametrů upgradu můžete řídit způsob upgradu vaší aplikace.

Naučte se používat serializaci dat tak, aby upgrady aplikací byly kompatibilní.

Při řešení běžných problémů s upgrady aplikací postupujte podle kroků v tématu Řešení potíží s upgrady aplikací.