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

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

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

Podobně lze typy služeb z aplikace v rámci upgradu odebrat. Před pokračováním v upgradu je však nutné odebrat všechny instance služby typu služby k odebrání (viz Remove-ServiceFabricService).

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

U plánovaných výpadků bezstavových instancí, jako je upgrade aplikace nebo clusteru nebo deaktivace uzlu, se připojení můžou po výpadku instance odebrat, protože vystavený koncový bod se odebere, což má za následek vynucené uzavření připojení.

Abyste tomu předešli, nakonfigurujte funkci RequestDrain přidáním doby trvání zpoždění uzavření instance v konfiguraci služby tak, aby stávající požadavky z clusteru vyprázdnily na vystavených koncových bodech. Toho dosáhnete tak, že se koncový bod inzerovaný bezstavovou instancí odebere před zahájením zpoždění před ukončením instance. Toto zpoždění umožňuje stávajícím požadavkům řádně vyprázdnit před tím, než instance skutečně klesne. Klienti jsou upozorněni na změnu koncového bodu funkcí zpětného volání v době spuštění zpoždění, aby mohli koncový bod znovu vyřešit a vyhnout se odesílání nových požadavků do instance, která se zpomaluje. Tyto požadavky můžou pocházet z klientů pomocí reverzního proxy serveru nebo pomocí rozhraní API pro překlad koncového bodu služby s modelem oznámení (ServiceNotificationFilterDescription) pro aktualizaci koncových bodů.

Konfigurace služby

Zpoždění na straně služby můžete nakonfigurovat několika způsoby.

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

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

• Při definování služby v oddílu výchozích hodnot 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í, když se koncový bod změnil, klienti by měli zaregistrovat zpětné volání, viz ukázkový popis ServiceNotificationFilterDescription. Oznámení o změnách značí, že se koncové body změnily, klient by měl koncové body znovu přeložit, a nesmí použí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>]

Doba trvání přepsání zpoždění se vztahuje pouze na vyvolanou instanci upgradu a jinak nemění konfigurace zpoždění jednotlivých služeb. Můžete to například použít k určení zpoždění 0 , aby bylo možné přeskočit všechna předkonfigurovaná zpoždění upgradu.

Režim ručního upgradu

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

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

Nakonec je režim UnmonitoredAuto užitečný pro provádění rychlých iterací upgradu během vývoje nebo testování služby, protože se nevyžaduje žádný vstup uživatele a nevyhodnocují se žádné zásady stavu aplikace.

Upgrade s využitím balíčku rozdílu

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

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

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

• 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í balíčky nebo datové balíčky.
• 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, nově sestavená sestavení získají jiný kontrolní součet. Použití úplného balíčku aplikace by vyžadovalo aktualizaci verze pro všechny balíčky kódu. Pomocí balíčku rozdílu zadáte pouze soubory, které se změnily, a soubory manifestu, ve kterých se změnila verze.

Při upgradu aplikace pomocí sady Visual Studio se automaticky publikuje rozdílový balíček. Pokud chcete vytvořit rozdílový balíček ručně, musí se 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 následující aplikací (čísla verzí, která jsou určená pro usnadnění porozumění):

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 jste chtěli aktualizovat pouze balíček kódu služby1 pomocí rozdílového balíčku. Vaše aktualizovaná aplikace má 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 službu Service1 tak, aby odrážel aktualizaci balíčku kódu. Složka balíčku aplikace by měla následující strukturu:

app1/
  service1/
    code/

Jinými slovy, normálně vytvořte kompletní balíček aplikace a pak odeberte všechny složky balíčků kódu/konfigurace/dat, pro které se verze nezměnila.

Upgrade parametrů aplikace nezávisle na verzi

Někdy je žádoucí změnit parametry aplikace Service Fabric beze změny verze manifestu. Můžete to provést pohodlně pomocí příznaku -ApplicationParameter s rutinou PowerShellu 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 můžete použít i nesledovaný upgrade. Úplný popis příznaků přijatých touto rutinou najdete v referenčních informacích k modulu Azure Service Fabric PowerShellu.

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

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

Vrácení zpět je možné aktivovat automaticky, když dojde k porušení zásad stavu upgradu v monitorovaném režimu s chybou 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 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, jak se vaše aplikace upgraduje.

Díky tomu, že se naučíte používat serializaci dat, vaše aplikace upgraduje.

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