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 den tjänsttyp som ska tas bort måste dock tas bort innan du fortsätter med uppgraderingen (se Remove-ServiceFabricService).

Undvik att anslutningen avbryts under den tillståndslösa tjänstens planerade stilleståndstid

För planerade tillståndslösa instansavbrott, till exempel program-/klusteruppgradering eller nodinaktivering, kan anslutningarna tas bort när den exponerade slutpunkten tas bort när instansen har gått ned, vilket resulterar i kraftfulla anslutningsstängningar.

Undvik detta genom att konfigurera funktionen RequestDrain genom att lägga till en varaktighet för fördröjning av instansen 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 börjar innan instansen stängs. Den här fördröjningen gör det möjligt för befintliga begäranden att tömmas korrekt innan instansen faktiskt går ner. Klienter meddelas om slutpunktsändringen av en motringningsfunktion när fördröjningen startas, så att de kan lösa slutpunkten igen och undvika att skicka nya begäranden till den instans som går ned. Dessa begäranden kan komma från klienter som använder omvänd proxy eller med hjälp av api:erna 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 ExempeltjänstNotificationFilterDescription. Ä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 snart kommer att gå ned.

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>]

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

Kommentar

  • Inställningarna för att tömma begäranden kan inte hindra Azure Load balancer från att skicka nya begäranden till slutpunkterna som håller på att tömmas.
  • En mekanism för klagomålsbaserad lösning resulterar inte i en korrekt tömning av begäranden, eftersom den utlöser en tjänstmatchning efter ett fel. Som vi beskrev tidigare bör detta i stället utökas för att prenumerera på meddelanden om slutpunktsändring med hjälp av ServiceNotificationFilterDescription.
  • Inställningarna uppfylls inte när uppgraderingen är en effektlös, dvs. när replikerna inte 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 1800 sekunder. Om du vill uppdatera maxvärdet bör konfigurationen på klusternivå uppdateras. Den här konfigurationen är endast tillgänglig i körningsversionen 9.0 eller senare.

Kommentar

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

Manuellt uppgraderingsläge

Kommentar

Läget Övervakad uppgradering 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 läget UnmonitoredManual 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 är i dataförlust). En uppgradering som körs i det här läget pausar sig själv när du har slutfört varje UD och måste uttryckligen återupptas med Resume-ServiceFabricApplicationUpgrade. När en uppgradering pausas och är redo att återupptas av användaren visas RollforwardPending (se UpgradeState).

Slutligen är läget UnmonitoredAuto användbart för att utföra iterationer för snabb uppgradering 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 endast 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 i 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 för närvarande 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 din programversionsprocess. I det här fallet, även om koden inte har ändrats, får nybyggda sammansättningar en annan kontrollsumma. Om du använder ett fullständigt programpaket måste du uppdatera versionen på 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 uppdatering av kodpaketet. Mappen för programpaketet skulle ha följande struktur:

app1/
  service1/
    code/

Skapa med andra ord ett fullständigt programpaket normalt och ta 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 PowerShell-cmdleten Start-ServiceFabricApplicationUpgrade Azure Service Fabric. Anta att ett Service Fabric-program har 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 hjälp av 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 godkänts av den här cmdleten finns i modulreferensen för 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

När du har uppgraderat kontrollerar 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

Även om uppgraderingar kan rullas framåt i något av tre lägen (Övervakad, UnmonitoredAuto eller UnmonitoredManual), kan de bara återställas i antingen UnmonitoredAuto - eller UnmonitoredManual-läge . Att återställa i läget UnmonitoredAuto fungerar på samma sätt som att rulla framåt med undantaget att standardvärdet UpgradeReplicaSetCheckTimeout är annorlunda – se Programuppgraderingsparametrar. Återställningen tillbaka i läget UnmonitoredManual 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 av återställning överträds (se Programuppgraderingsparametrar) eller explicit 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 får du hjälp med en programuppgradering med Hjälp av Visual Studio.

När du uppgraderar ditt program med PowerShell får du hjälp med 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 data serialisering.

Åtgärda vanliga problem i programuppgraderingar genom att referera till stegen i Felsöka programuppgraderingar.