Dela via

Uppgradering av Service Fabric-program: Avancerade ämnen

  • Artikel

Lägga till eller ta bort tjänsttyper under en programuppgradering

Om en ny tjänsttyp läggs till i ett publicerat program som en del av en uppgradering läggs den nya tjänsttypen till i det distribuerade programmet. En sådan uppgradering påverkar inte någon av de tjänstinstanser som redan var en del av programmet, men en instans av tjänsttypen som lades till måste skapas för att den nya tjänsttypen ska vara aktiv (se New-ServiceFabricService).

På samma sätt kan tjänsttyper tas bort från ett program som en del av en uppgradering. Alla tjänstinstanser av tjänsttypen som ska tas bort måste dock tas bort innan du fortsätter med uppgraderingen (se Remove-ServiceFabricService).

Undvik att anslutningen avbryts vid planerat driftstopp för tillståndslös tjänst

Vid planerade tillståndslösa instansavbrott, till exempel program-/klusteruppgradering eller nodinaktivering, kan anslutningar tas bort när den exponerade slutpunkten tas bort när instansen stängs, vilket resulterar i kraftfulla anslutningsavstängningar.

För att undvika detta konfigurerar du RequestDrain-funktionen genom att lägga till en varaktighet för instansens stängningsfördröjning i tjänstkonfigurationen så att befintliga begäranden från klustret kan tömmas på de exponerade slutpunkterna. Detta uppnås eftersom slutpunkten som annonseras av den tillståndslösa instansen tas bort innan fördröjningen startar innan instansen stängs. Den här fördröjningen gör att befintliga begäranden kan tömmas korrekt innan instansen faktiskt kraschar. Klienter meddelas om slutpunktsändringen av en återanropsfunktion när fördröjningen startas, så att de kan matcha slutpunkten igen och undvika att skicka nya begäranden till den instans som slutar fungera. Dessa begäranden kan komma från klienter som använder omvänd proxy eller använder API:er för tjänstslutpunktsmatchning med meddelandemodellen (ServiceNotificationFilterDescription) för uppdatering av slutpunkterna.

Tjänstkonfiguration

Det finns flera sätt att konfigurera fördröjningen på tjänstsidan.

  • När du skapar en ny tjänst anger du en -InstanceCloseDelayDuration:

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

  • När du definierar tjänsten i standardavsnittet i programmanifestet tilldelar du InstanceCloseDelayDurationSeconds egenskapen:

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

  • När du uppdaterar en befintlig tjänst anger du en -InstanceCloseDelayDuration:

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

  • När du skapar eller uppdaterar en befintlig tjänst via ARM-mallen anger du InstanceCloseDelayDuration värdet (lägsta API-version som stöds: 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"
  }
}

Klientkonfiguration

Om du vill få ett meddelande när en slutpunkt har ändrats bör klienter registrera ett återanrop i Exempel på ServiceNotificationFilterDescription. Ändringsmeddelandet är en indikation på att slutpunkterna har ändrats, klienten bör matcha slutpunkterna igen och inte använda slutpunkterna som inte annonseras längre, eftersom de kommer att gå ned snart.

Valfria åsidosättningar för uppgradering

Förutom att ange standardfördröjningsvaraktighet per tjänst kan du också åsidosätta fördröjningen under program-/klusteruppgradering med samma (InstanceCloseDelayDurationSec) alternativ:

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

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

Den åsidosatta fördröjningstiden gäller endast för den anropade uppgraderingsinstansen och ändrar annars inte konfigurationer för enskilda tjänstfördröjningar. Du kan till exempel använda detta för att ange en fördröjning 0 på för att hoppa över eventuella förkonfigurerade uppgraderingsfördröjningar.

Anteckning

  • Inställningarna för att tömma begäranden kan inte hindra Azure Load Balancer från att skicka nya begäranden till de slutpunkter som håller på att tömmas.
  • En klagomålsbaserad lösningsmekanism leder inte till korrekt tömning av begäranden, eftersom den utlöser en tjänstmatchning efter ett fel. Som tidigare beskrivits bör detta i stället utökas för att prenumerera på meddelanden om slutpunktsändring med hjälp av ServiceNotificationFilterDescription.
  • Inställningarna respekteras inte när uppgraderingen är effektlös, dvs. när replikerna inte kommer att tas ned under uppgraderingen.
  • Det maximala värdet för InstanceCloseDelayDuration som kan konfigureras i tjänstbeskrivningen eller InstanceCloseDelayDurationSec i uppgraderingsbeskrivningen får inte vara större än klusterkonfigurationen FailoverManager.MaxInstanceCloseDelayDurationInSeconds, som standard är 1 800 sekunder. Om du vill uppdatera maxvärdet bör konfigurationen på klusternivå uppdateras. Den här konfigurationen är endast tillgänglig i körningsversion 9.0 eller senare.

Anteckning

Den här funktionen kan konfigureras i befintliga tjänster med hjälp av Update-ServiceFabricService cmdlet eller ARM-mallen som nämns ovan, när klusterkodversionen är 7.1.XXX eller senare.

Manuellt uppgraderingsläge

Anteckning

Det övervakade uppgraderingsläget rekommenderas för alla Service Fabric-uppgraderingar. Uppgraderingsläget UnmonitoredManual bör endast övervägas för misslyckade eller pausade uppgraderingar.

I övervakat läge tillämpar Service Fabric hälsoprinciper för att säkerställa att programmet är felfritt när uppgraderingen fortskrider. Om hälsoprinciper överträds pausas uppgraderingen eller återställs automatiskt beroende på den angivna FailureAction.

I oövervakatHanterat läge har programadministratören fullständig kontroll över uppgraderingens förlopp. Det här läget är användbart när du tillämpar anpassade hälsoutvärderingsprinciper eller utför icke-konventionella uppgraderingar för att kringgå hälsoövervakningen helt (t.ex. att programmet redan har dataförlust). En uppgradering som körs i det här läget pausas när varje UD har slutförts och måste återupptas explicit med Resume-ServiceFabricApplicationUpgrade. När en uppgradering pausas och är redo att återupptas av användaren visar uppgraderingstillståndet RollforwardPending (se UpgradeState).

Slutligen är läget UnmonitoredAuto användbart för att utföra snabba uppgraderingsiterationer under tjänstutveckling eller testning eftersom inga användarindata krävs och inga principer för programhälsa utvärderas.

Uppgradera med ett diff-paket

I stället för att etablera ett komplett programpaket kan uppgraderingar också utföras genom etablering av diff-paket som bara innehåller de uppdaterade kod-/konfigurations-/datapaketen tillsammans med det fullständiga programmanifestet och fullständiga tjänstmanifest. Fullständiga programpaket krävs endast för den första installationen av ett program till klustret. Efterföljande uppgraderingar kan antingen komma från fullständiga programpaket eller diff-paket.

Alla referenser i programmanifestet eller tjänstmanifesten för ett diff-paket som inte kan hittas i programpaketet ersätts automatiskt med den aktuella etablerade versionen.

Scenarier för att använda ett diff-paket är:

  • När du har ett stort programpaket som refererar till flera tjänstmanifestfiler och/eller flera kodpaket, konfigurationspaket eller datapaket.
  • När du har ett distributionssystem som genererar bygglayouten direkt från programbyggprocessen. I det här fallet, även om koden inte har ändrats, får nyligen skapade sammansättningar en annan kontrollsumma. Om du använder ett fullständigt programpaket måste du uppdatera versionen för alla kodpaket. Med hjälp av ett diff-paket anger du bara de filer som har ändrats och de manifestfiler där versionen har ändrats.

När ett program uppgraderas med Visual Studio publiceras ett diff-paket automatiskt. Om du vill skapa ett diff-paket manuellt måste programmanifestet och tjänstmanifesten uppdateras, men endast de ändrade paketen ska ingå i det slutliga programpaketet.

Vi börjar till exempel med följande program (versionsnummer som tillhandahålls för att underlätta förståelsen):

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

Anta att du bara ville uppdatera kodpaketet för service1 med hjälp av ett diff-paket. Det uppdaterade programmet har följande versionsändringar:

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

I det här fallet uppdaterar du programmanifestet till 2.0.0 och tjänstmanifestet för service1 för att återspegla uppdateringen av kodpaketet. Mappen för programpaketet skulle ha följande struktur:

app1/
  service1/
    code/

Med andra ord skapar du ett fullständigt programpaket normalt och tar sedan bort alla kod-/konfigurations-/datapaketmappar som versionen inte har ändrats för.

Uppgradera programparametrar oberoende av version

Ibland är det önskvärt att ändra parametrarna för ett Service Fabric-program utan att ändra manifestversionen. Detta kan göras bekvämt med hjälp av flaggan -ApplicationParameter med Azure Service Fabric PowerShell-cmdleten Start-ServiceFabricApplicationUpgrade . Anta ett Service Fabric-program med följande egenskaper:

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

Uppgradera nu programmet med cmdleten Start-ServiceFabricApplicationUpgrade . Det här exemplet visar en övervakad uppgradering, men en oövervakad uppgradering kan också användas. En fullständig beskrivning av flaggor som accepteras av den här cmdleten finns i referensen för Azure Service Fabric PowerShell-modulen

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

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

Efter uppgraderingen bekräftar du att programmet har de uppdaterade parametrarna och samma version:

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

Återställa programuppgraderingar

Uppgraderingar kan flyttas framåt i något av tre lägen (Övervakad, OövervakadAuto eller UnmonitoredManual), men de kan bara återställas i antingen UnmonitoredAuto - eller UnmonitoredManual-läge . Återställning i oövervakatAuto-läge fungerar på samma sätt som att rulla framåt med undantaget att standardvärdet UpgradeReplicaSetCheckTimeout är annorlunda – se Parametrar för programuppgradering. Återställning i unmonitoredManual-läge fungerar på samma sätt som att rulla framåt – återställningen pausas när du har slutfört varje UD och måste uttryckligen återupptas med Resume-ServiceFabricApplicationUpgrade för att fortsätta med återställningen.

Återställningar kan utlösas automatiskt när hälsoprinciperna för en uppgradering i övervakat läge med ett felÅtgärd för återställning överträds (se Parametrar för programuppgradering) eller uttryckligen använder Start-ServiceFabricApplicationRollback.

Under återställningen kan värdet för UpgradeReplicaSetCheckTimeout och läget fortfarande ändras när som helst med Update-ServiceFabricApplicationUpgrade.

Nästa steg

När du uppgraderar ditt program med Visual Studio går vi igenom en programuppgradering med Visual Studio.

När du uppgraderar ditt program med PowerShell går vi igenom en programuppgradering med hjälp av PowerShell.

Kontrollera hur programmet uppgraderas med hjälp av uppgraderingsparametrar.

Gör dina programuppgraderingar kompatibla genom att lära dig hur du använder dataserialisering.

Åtgärda vanliga problem i programuppgraderingar med hjälp av stegen i Felsöka programuppgraderingar.