Upgrade van Service Fabric-toepassing: geavanceerde onderwerpen

  • Artikel

Servicetypen toevoegen of verwijderen tijdens een toepassingsupgrade

Als 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 de service-exemplaren die al deel uitmaakten van de toepassing, maar er moet een exemplaar van het toegevoegde servicetype 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).

Voorkomen dat de verbinding wordt verbroken tijdens geplande downtime van stateless service

Voor downtime van geplande stateless exemplaren, zoals een upgrade van een toepassing/cluster of het deactiveren van knooppunten, kunnen verbindingen worden verbroken wanneer het blootgestelde eindpunt wordt verwijderd nadat het exemplaar uitvalt, wat resulteert in gedwongen afsluitingen van de verbinding.

Als u dit wilt voorkomen, configureert u de functie RequestDrain door een vertragingsduur voor het sluiten van een exemplaar toe te voegen in de serviceconfiguratie, zodat bestaande aanvragen vanuit het cluster op de blootgestelde eindpunten kunnen worden leeggelopen. Dit wordt bereikt wanneer het eindpunt dat door het staatloze exemplaar wordt geadverteerd, wordt verwijderd voordat de vertraging begint voordat het exemplaar wordt gesloten. Door deze vertraging kunnen bestaande aanvragen probleemloos worden leeggelopen voordat het exemplaar daadwerkelijk uitvalt. Clients worden op de hoogte gebracht van de eindpuntwijziging door een callback-functie op het moment dat de vertraging wordt gestart, zodat ze het eindpunt opnieuw kunnen oplossen en kunnen voorkomen dat nieuwe aanvragen worden verzonden naar het exemplaar dat uitvalt. Deze aanvragen kunnen afkomstig zijn van clients die gebruikmaken van omgekeerde proxy of api's voor het oplossen van service-eindpunten 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 -InstanceCloseDelayDurationop:

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

  • Wijs tijdens het definiëren van de service in de sectie standaardinstellingen in het toepassingsmanifest de eigenschap toe InstanceCloseDelayDurationSeconds :

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

  • Wanneer u een bestaande service bijwerkt, geeft u een op -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 VoorbeeldserviceNotificationFilterDescription. De wijzigingsmelding is een indicatie dat de eindpunten zijn gewijzigd, dat de client de eindpunten opnieuw moet omzetten en niet de eindpunten moet gebruiken die niet meer worden geadverteerd, omdat deze binnenkort niet meer worden weergegeven.

Optionele upgradeoverschrijvingen

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

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

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

De overschreven vertragingsduur is alleen van toepassing op het aangeroepen upgrade-exemplaar en wijzigt op geen enkele andere wijze de configuratie van afzonderlijke servicevertragingen. U kunt dit bijvoorbeeld gebruiken om een vertraging van 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 worden verwijderd.
  • Een op klachten gebaseerd oplossingsmechanisme leidt niet tot een probleemloze afvoer van aanvragen, omdat het een serviceoplossing activeert na een fout. Zoals eerder beschreven, moet dit in plaats daarvan worden verbeterd om u te abonneren op de meldingen voor eindpuntwijziging met behulp van ServiceNotificationFilterDescription.
  • De instellingen worden niet gehonoreerd wanneer de upgrade impactloos is, dat wil zeggen wanneer de replica's niet worden uitgeschakeld 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 maximumwaarde 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 Update-ServiceFabricService cmdlet of de ARM-sjabloon zoals hierboven vermeld, wanneer de versie van de clustercode 7.1.XXX of hoger is.

Handmatige upgrademodus

Notitie

De modus Bewaakte upgrade wordt aanbevolen voor alle Service Fabric-upgrades. De modus UnmonitoredManual upgrade moet 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 tijdens de upgrade. Als het statusbeleid wordt geschonden, wordt de upgrade onderbroken of automatisch teruggedraaid, afhankelijk van de opgegeven FailureAction.

In de modus UnmonitoredManual heeft de toepassingsbeheerder volledige controle over de voortgang van de upgrade. Deze modus is handig bij het toepassen van aangepast beleid voor statusevaluatie of het uitvoeren van niet-conventionele upgrades om de statuscontrole volledig te omzeilen (bijvoorbeeld dat de toepassing al gegevensverlies heeft). Een upgrade die in deze modus wordt uitgevoerd, wordt onderbroken nadat elke UD is voltooid en moet expliciet worden hervat met behulp van 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 de service, 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-/config-/gegevenspakketten bevatten, samen met het volledige toepassingsmanifest en volledige servicemanifesten. Volledige toepassingspakketten zijn alleen vereist voor de eerste installatie van een toepassing op het cluster. Volgende upgrades kunnen afkomstig zijn van volledige toepassingspakketten of van diff-pakketten.

Verwijzingen in het toepassingsmanifest of servicemanifest van een diff-pakket die niet in het toepassingspakket kunnen 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 servicemanifestbestanden en/of meerdere 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 nieuw gebouwde assembly's, hoewel de code niet is gewijzigd, een andere controlesom. 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 er 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 opgegeven voor een beter begrip):

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 dan de volgende structuur:

app1/
  service1/
    code/

Met andere woorden: maak normaal een volledig toepassingspakket en verwijder vervolgens alle mappen met code-/configuratie-/gegevenspakketten 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 eenvoudig worden gedaan met behulp van de vlag -ApplicationParameter met de PowerShell-cmdlet Start-ServiceFabricApplicationUpgrade Azure Service Fabric. Ga uit van een Service Fabric-toepassing met de volgende eigenschappen:

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

Voer nu een upgrade uit van 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 Azure Service Fabric PowerShell-modulereferentie voor een volledige beschrijving van de 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 in een van de drie modi (Monitor, UnmonitoredAuto of UnmonitoredManual) vooruit kunnen worden gerold, kunnen ze alleen worden teruggedraaid in de modus UnmonitoredAuto of UnmonitoredManual . Terugdraaien in de modus Niet-bewaaktauto werkt op dezelfde manier als vooruitrollen, met de uitzondering dat de standaardwaarde van UpgradeReplicaSetCheckTimeout anders is. Zie Parameters voor toepassingsupgrade. Terugdraaien in de modus UnmonitoredManual werkt op dezelfde manier als het terugdraaien: het terugdraaien wordt onderbroken na het voltooien van elke UD en moet expliciet worden hervat met Resume-ServiceFabricApplicationUpgrade om door te gaan met het terugdraaien.

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 behulp van Start-ServiceFabricApplicationRollback.

Tijdens het terugdraaien kunnen de waarde van UpgradeReplicaSetCheckTimeout en de modus nog steeds worden gewijzigd met behulp van Update-ServiceFabricApplicationUpgrade.

Volgende stappen

Uw toepassing upgraden met Visual Studio begeleidt u bij het uitvoeren van een toepassingsupgrade met behulp van Visual Studio.

Uw toepassing upgraden met PowerShell helpt u bij het uitvoeren van een toepassingsupgrade met behulp van PowerShell.

Bepaal hoe uw toepassing wordt bijgewerkt met behulp van upgradeparameters.

Maak uw toepassingsupgrades compatibel door te leren hoe u gegevensserialisatie gebruikt.

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