Delen via

Service Fabric-toepassingsupgrade: geavanceerde onderwerpen

  • Artikel

Servicetypen toevoegen of verwijderen tijdens een toepassingsupgrade

Als er een nieuw servicetype wordt toegevoegd aan een gepubliceerde toepassing als onderdeel van een upgrade, wordt het nieuwe servicetype toegevoegd aan de geïmplementeerde toepassing. Een dergelijke upgrade heeft geen invloed op een van de service-exemplaren die al deel uitmaken van de toepassing, maar een exemplaar van het servicetype dat is toegevoegd, moet worden gemaakt om het nieuwe servicetype actief te maken (zie New-ServiceFabricService).

Op dezelfde manier kunnen servicetypen uit een toepassing worden verwijderd als onderdeel van een upgrade. Alle service-exemplaren van het te-verwijderen servicetype moeten echter worden verwijderd voordat u doorgaat met de upgrade (zie Remove-ServiceFabricService).

Vermijd uitval van verbindingen tijdens geplande downtime van stateless service

Voor downtime van geplande staatloze instanties, zoals het upgraden van toepassingen/clusters of het deactiveren van knooppunten, kunnen verbindingen worden verwijderd wanneer het blootgestelde eindpunt wordt verwijderd nadat het exemplaar uitvalt, wat resulteert in forcering van de verbinding.

U kunt dit voorkomen door de functie RequestDrain te configureren door een vertragingsduur voor het sluiten van een exemplaar toe te voegen in de serviceconfiguratie, zodat bestaande aanvragen vanuit het cluster kunnen worden leeggelopen op de weergegeven eindpunten. Dit wordt bereikt omdat het eindpunt dat door het staatloze exemplaar wordt aangekondigd, wordt verwijderd voordat de vertraging begint voordat het exemplaar wordt gesloten. Met deze vertraging kunnen bestaande aanvragen probleemloos leeglopen voordat het exemplaar daadwerkelijk uitvalt. Clients worden op het moment van het starten van de vertraging op de hoogte gesteld van de wijziging van het eindpunt door een callback-functie, zodat ze het eindpunt opnieuw kunnen oplossen en geen nieuwe aanvragen naar het exemplaar kunnen verzenden. Deze aanvragen kunnen afkomstig zijn van clients die reverse proxy gebruiken of api's voor service-eindpuntomzetting gebruiken met het meldingsmodel (ServiceNotificationFilterDescription) voor het bijwerken van de eindpunten.

Serviceconfiguratie

Er zijn verschillende manieren om de vertraging aan de servicezijde te configureren.

  • Geef bij het maken van een nieuwe service een -InstanceCloseDelayDuration:

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

  • Wijs de eigenschap toe tijdens het definiëren van de service in de standaardsectie in het toepassingsmanifestInstanceCloseDelayDurationSeconds:

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

  • Wanneer u een bestaande service bijwerkt, geeft u een -InstanceCloseDelayDuration:

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

  • Wanneer u een bestaande service maakt of bijwerkt via de ARM-sjabloon, geeft u de InstanceCloseDelayDuration waarde op (minimaal ondersteunde API-versie: 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"
  }
}

Clientconfiguratie

Als u een melding wilt ontvangen wanneer een eindpunt is gewijzigd, moeten clients een callback registreren, zie Sample ServiceNotificationFilterDescription. De wijzigingsmelding is een indicatie dat de eindpunten zijn gewijzigd, dat de client de eindpunten opnieuw moet oplossen en niet de eindpunten gebruikt die niet meer worden geadverteerd, omdat ze binnenkort omlaag gaan.

Optionele upgrade-onderdrukkingen

Naast het instellen van de standaardvertragingsduur per service, kunt u de vertraging ook overschrijven tijdens de upgrade van een toepassing/cluster met dezelfde optie (InstanceCloseDelayDurationSec):

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

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

De vertraagde vertragingsduur is alleen van toepassing op het aangeroepen upgrade-exemplaar en wijzigt anders geen configuraties voor afzonderlijke servicevertragingen. U kunt dit bijvoorbeeld gebruiken om een vertraging 0 op te geven om eventuele vooraf geconfigureerde upgradevertragingen over te slaan.

Notitie

  • De instellingen voor het leegmaken van aanvragen kunnen niet voorkomen dat de Azure Load Balancer nieuwe aanvragen verzendt naar de eindpunten die leeglopen.
  • Een oplossingsmechanisme op basis van een klacht leidt niet tot een probleemloze afvoer van aanvragen, omdat er na een fout een serviceomzetting wordt geactiveerd. Zoals eerder beschreven, moet dit in plaats daarvan worden uitgebreid om u te abonneren op de meldingen voor eindpuntwijziging met behulp van ServiceNotificationFilterDescription.
  • De instellingen worden niet gehonoreerd wanneer de upgrade een impactloos is, bijvoorbeeld wanneer de replica's niet worden onderbroken tijdens de upgrade.
  • De maximale waarde van InstanceCloseDelayDuration die kan worden geconfigureerd in de servicebeschrijving of de InstanceCloseDelayDurationSec in de beschrijving van de upgrade kan niet groter zijn dan clusterconfiguratie FailoverManager.MaxInstanceCloseDelayDurationInSeconds, die standaard 1800 seconden is. Als u de maximale waarde wilt bijwerken, moet de configuratie op clusterniveau worden bijgewerkt. Deze configuratie is alleen beschikbaar in runtimeversie 9.0 of hoger.

Notitie

Deze functie kan worden geconfigureerd in bestaande services met behulp van de cmdlet Update-ServiceFabricService of de ARM-sjabloon zoals hierboven vermeld, wanneer de versie van de clustercode 7.1.XXX of hoger is.

Handmatige upgrademodus

Notitie

De bewaakte upgrademodus wordt aanbevolen voor alle Service Fabric-upgrades. De modus UnmonitoredManual upgrade mag alleen worden overwogen voor mislukte of onderbroken upgrades.

In de bewaakte modus past Service Fabric statusbeleid toe om ervoor te zorgen dat de toepassing in orde is wanneer de upgrade vordert. Als het statusbeleid wordt geschonden, wordt de upgrade onderbroken of automatisch teruggedraaid, afhankelijk van de opgegeven FailureAction.

In de modus UnmonitoredManual heeft de toepassingsbeheerder de totale controle over de voortgang van de upgrade. Deze modus is handig bij het toepassen van aangepaste beleidsregels voor statusevaluatie of het uitvoeren van niet-conventionele upgrades om statuscontrole volledig te omzeilen (bijvoorbeeld de toepassing is al in gegevensverlies). Een upgrade die in deze modus wordt uitgevoerd, wordt onderbroken nadat elke UD is voltooid en moet expliciet worden hervat met Resume-ServiceFabricApplicationUpgrade. Wanneer een upgrade is onderbroken en klaar is om te worden hervat door de gebruiker, wordt de upgradestatus RollforwardPending weergegeven (zie UpgradeState).

Ten slotte is de modus UnmonitoredAuto handig voor het uitvoeren van snelle upgrade-iteraties tijdens het ontwikkelen of testen van services, omdat er geen gebruikersinvoer is vereist en er geen toepassingsstatusbeleid wordt geëvalueerd.

Upgraden met een diff-pakket

In plaats van een volledig toepassingspakket in te richten, kunnen upgrades ook worden uitgevoerd door diff-pakketten in te richten die alleen de bijgewerkte code/configuratie/gegevenspakketten bevatten, samen met het volledige toepassingsmanifest en volledige servicemanifesten. Volledige toepassingspakketten zijn alleen vereist voor de eerste installatie van een toepassing in het cluster. Volgende upgrades kunnen afkomstig zijn van volledige toepassingspakketten of diff-pakketten.

Verwijzingen in het toepassingsmanifest of servicemanifest van een diff-pakket dat niet in het toepassingspakket kan worden gevonden, worden automatisch vervangen door de momenteel ingerichte versie.

Scenario's voor het gebruik van een diff-pakket zijn:

  • Wanneer u een groot toepassingspakket hebt dat verwijst naar verschillende manifestbestanden van de service en/of verschillende codepakketten, configuratiepakketten of gegevenspakketten.
  • Wanneer u een implementatiesysteem hebt dat de build-indeling rechtstreeks vanuit het buildproces van uw toepassing genereert. In dit geval krijgen nieuwe assembly's een andere controlesom, ook al is de code niet gewijzigd. Als u een volledig toepassingspakket gebruikt, moet u de versie voor alle codepakketten bijwerken. Met behulp van een diff-pakket geeft u alleen de bestanden op die zijn gewijzigd en de manifestbestanden waarin de versie is gewijzigd.

Wanneer een toepassing wordt bijgewerkt met Visual Studio, wordt automatisch een diff-pakket gepubliceerd. Als u handmatig een diff-pakket wilt maken, moeten het toepassingsmanifest en de servicemanifesten worden bijgewerkt, maar alleen de gewijzigde pakketten moeten worden opgenomen in het uiteindelijke toepassingspakket.

Laten we bijvoorbeeld beginnen met de volgende toepassing (versienummers die voor een beter begrip zijn opgegeven):

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

Stel dat u alleen het codepakket van service1 wilt bijwerken met behulp van een diff-pakket. De bijgewerkte toepassing heeft de volgende versiewijzigingen:

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

In dit geval werkt u het toepassingsmanifest bij naar 2.0.0 en het servicemanifest voor service1 om de codepakketupdate weer te geven. De map voor uw toepassingspakket heeft de volgende structuur:

app1/
  service1/
    code/

Met andere woorden, maak normaal een volledig toepassingspakket en verwijder vervolgens alle code-/configuratie-/gegevenspakketmappen waarvoor de versie niet is gewijzigd.

Toepassingsparameters onafhankelijk van versie upgraden

Soms is het wenselijk om de parameters van een Service Fabric-toepassing te wijzigen zonder de manifestversie te wijzigen. Dit kan handig worden gedaan met behulp van de vlag -ApplicationParameter met de Cmdlet Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell. Stel dat een Service Fabric-toepassing de volgende eigenschappen heeft:

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

Upgrade nu de toepassing met behulp van de cmdlet Start-ServiceFabricApplicationUpgrade . In dit voorbeeld ziet u een bewaakte upgrade, maar er kan ook een niet-bewaakte upgrade worden gebruikt. Zie de naslaginformatie over de Azure Service Fabric PowerShell-module voor een volledige beschrijving van vlaggen die door deze cmdlet worden geaccepteerd

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

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

Controleer na de upgrade of de toepassing de bijgewerkte parameters en dezelfde versie heeft:

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

Toepassingsupgrades terugdraaien

Hoewel upgrades kunnen worden doorgestuurd in een van de drie modi (Bewaakt, UnmonitoredAuto of UnmonitoredManual), kunnen ze alleen worden teruggedraaid in de modus UnmonitoredAuto of UnmonitoredManual. Terugdraaien in unmonitoredAuto-modus werkt op dezelfde manier als het doorsturen met de uitzondering dat de standaardwaarde van UpgradeReplicaSetCheckTimeout anders is. Zie Parameters voor toepassingsupgrade. Terugdraaien in unmonitoredManual-modus werkt op dezelfde manier als het terugdraaien. De terugdraaiactie wordt onderbroken na het voltooien van elke UD en moet expliciet worden hervat met Resume-ServiceFabricApplicationUpgrade om door te gaan met de terugdraaiactie.

Terugdraaiacties kunnen automatisch worden geactiveerd wanneer het statusbeleid van een upgrade in de bewaakte modus met een FailureAction of Rollback wordt geschonden (zie Parameters voor toepassingsupgrade) of expliciet met Start-ServiceFabricApplicationRollback.

Tijdens het terugdraaien kan de waarde van UpgradeReplicaSetCheckTimeout en de modus op elk gewenst moment worden gewijzigd met behulp van Update-ServiceFabricApplicationUpgrade.

Volgende stappen

Als u uw toepassing bijwerken met Visual Studio , wordt u begeleid bij het uitvoeren van een toepassingsupgrade met behulp van Visual Studio.

Als u uw toepassing bijwerkt met Behulp van PowerShell , wordt u begeleid bij het uitvoeren van een toepassingsupgrade met behulp van PowerShell.

Bepalen hoe uw toepassing wordt bijgewerkt met behulp van upgradeparameters.

Zorg ervoor dat uw toepassing compatibel is door te leren hoe u gegevensserialisatie gebruikt.

Los veelvoorkomende problemen in toepassingsupgrades op door te verwijzen naar de stappen in Het oplossen van problemen met toepassingsupgrades.