Aggiornamento dell'applicazione di Service Fabric: Argomenti avanzati

  • Articolo

Aggiungere o rimuovere tipi di servizio durante un aggiornamento dell'applicazione

Se si aggiunge un nuovo tipo di servizio a un'applicazione pubblicata nel corso di un aggiornamento, il nuovo tipo di servizio viene aggiunto all'applicazione distribuita. Tale aggiornamento non influisce sulle istanze del servizio che facevano già parte dell'applicazione, ma è necessario creare un'istanza del tipo di servizio che è stato aggiunto per consentire l'attivazione del nuovo tipo di servizio (vedere New-ServiceFabricService).

Analogamente, i tipi di servizio possono essere rimossi da un'applicazione durante un aggiornamento. Tuttavia, prima di procedere con l'aggiornamento è necessario rimuovere tutte le istanze del tipo di servizio da rimuovere (vedere Remove-ServiceFabricService).

Evitare interruzioni della connessione durante i tempi di inattività pianificati del servizio senza stato

Per i tempi di inattività pianificati dell'istanza senza stato, ad esempio l'aggiornamento di applicazioni/cluster o la disattivazione dei nodi, le connessioni possono essere eliminate quando l'endpoint esposto viene rimosso dopo che l'istanza diventa inattiva, il che comporta la chiusura forzata della connessione.

Per evitare questo problema, configurare la funzionalità RequestDrain aggiungendo una durata di ritardo di chiusura dell'istanza nella configurazione del servizio per consentire alle richieste esistenti dall'interno del cluster di svuotare gli endpoint esposti. Questa operazione viene ottenuta quando l'endpoint annunciato dall'istanza senza stato viene rimosso prima dell'avvio del ritardo prima della chiusura dell'istanza. Questo ritardo consente alle richieste esistenti di svuotare normalmente prima che l'istanza diventi effettivamente inattiva. I client ricevono una notifica della modifica dell'endpoint da una funzione di callback al momento dell'avvio del ritardo, in modo che possano risolvere nuovamente l'endpoint ed evitare l'invio di nuove richieste all'istanza inattiva. Queste richieste possono essere provenienti dai client che usano il proxy inverso o usando l'API di risoluzione degli endpoint di servizio con il modello di notifica (ServiceNotificationFilterDescription) per l'aggiornamento degli endpoint.

Configurazione del servizio

Esistono diversi modi per configurare il ritardo sul lato servizio.

  • Quando si crea un nuovo servizio, specificare :-InstanceCloseDelayDuration

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

  • Durante la definizione del servizio nella sezione predefinite nel manifesto dell'applicazione, assegnare la InstanceCloseDelayDurationSeconds proprietà :

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

  • Quando si aggiorna un servizio esistente, specificare :-InstanceCloseDelayDuration

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

  • Quando si crea o si aggiorna un servizio esistente tramite il modello arm, specificare il InstanceCloseDelayDuration valore (versione minima dell'API supportata: 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"
  }
}

Configurazione del client

Per ricevere una notifica quando un endpoint è cambiato, i client devono registrare un callback, vedere Sample ServiceNotificationFilterDescription. La notifica di modifica indica che gli endpoint sono stati modificati, il client deve risolvere di nuovo gli endpoint e non usare gli endpoint che non vengono più annunciati, perché non verranno più disattivati.

Sostituzioni di aggiornamento facoltative

Oltre a impostare le durate di ritardo predefinite per servizio, è anche possibile eseguire l'override del ritardo durante l'aggiornamento dell'applicazione o del cluster usando la stessa opzione (InstanceCloseDelayDurationSec):

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

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

La durata del ritardo sottoposto a override si applica solo all'istanza di aggiornamento richiamata e non modifica in caso contrario le singole configurazioni di ritardo del servizio. Ad esempio, è possibile usarlo per specificare un ritardo di 0 per ignorare eventuali ritardi di aggiornamento preconfigurati.

Nota

  • Le impostazioni per svuotare le richieste non saranno in grado di impedire al servizio di bilanciamento del carico di Azure di inviare nuove richieste agli endpoint in fase di svuotamento.
  • Un meccanismo di risoluzione basato su reclami non comporterà un normale svuotamento delle richieste, perché attiva una risoluzione del servizio dopo un errore. Come descritto in precedenza, questa operazione dovrebbe invece essere migliorata per sottoscrivere le notifiche di modifica dell'endpoint usando ServiceNotificationFilterDescription.
  • Le impostazioni non vengono rispettate quando l'aggiornamento è senza impatto, ad esempio quando le repliche non verranno disattivate durante l'aggiornamento.
  • Il valore massimo di InstanceCloseDelayDuration che può essere configurato nella descrizione del servizio o instanceCloseDelayDurationSec nella descrizione dell'aggiornamento non può essere maggiore della configurazione del cluster FailoverManager.MaxInstanceCloseDelayDurationInSeconds, che per impostazione predefinita è 1800 secondi. Per aggiornare il valore massimo, è necessario aggiornare la configurazione a livello di cluster. Questa configurazione è disponibile solo nel runtime versione 9.0 o successiva.

Nota

Questa funzionalità può essere configurata nei servizi esistenti usando Update-ServiceFabricService cmdlet o il modello di Resource Manager come indicato in precedenza, quando la versione del codice del cluster è 7.1.XXX o versione successiva.

Modalità di aggiornamento manuale

Nota

Per tutti gli aggiornamenti di Service Fabric è consigliabile usare la modalità di aggiornamento Monitored. La modalità di aggiornamentoUnmonitoredManual deve essere presa in considerazione solo per gli aggiornamenti non riusciti e sospesi.

In modalità Monitored Service Fabric applica criteri specifici per assicurare l'integrità dell'applicazione durante l'avanzamento dell'aggiornamento. Se i criteri di integrità non vengono rispettati, l'aggiornamento viene sospeso oppure viene eseguito il rollback automatico dell'operazione, a seconda dell'opzione specificata in FailureAction.

In modalità UnmonitoredManual l'amministratore dell'applicazione ha il controllo completo sull'avanzamento dell'aggiornamento. Questa modalità è utile quando si applicano criteri di valutazione dell'integrità personalizzati o quando si eseguono aggiornamenti non convenzionali per escludere completamente il monitoraggio dello stato (ad esempio, l'applicazione ha già perso dati). Un aggiornamento in esecuzione in questa modalità viene sospeso automaticamente al termine di ogni UD e deve essere ripreso in modo esplicito usando Resume-ServiceFabricApplicationUpgrade. Quando un aggiornamento sospeso è pronto per essere ripreso dall'utente, lo stato corrispondente sarà RollforwardPending (vedere UpgradeState).

Infine, la modalità UnmonitoredAuto è utile per l'esecuzione di iterazioni di aggiornamento rapide durante lo sviluppo o il test del servizio, poiché non è richiesto alcun input da parte dell'utente e non viene valutato alcun criterio di integrità dell'applicazione.

Aggiornare con un pacchetto Diff

Anziché con il provisioning di un pacchetto dell'applicazione completo, gli aggiornamenti possono essere eseguiti anche con il provisioning di pacchetti diff che contengono solo i pacchetti di codice/configurazione/dati aggiornati insieme al manifesto completo dell'applicazione e ai manifesti completi del servizio. I pacchetti dell'applicazione completi sono necessari solo per l'installazione iniziale di un'applicazione nel cluster. Gli aggiornamenti successivi possono essere eseguiti da pacchetti dell'applicazione completi o da pacchetti diff.

Qualsiasi riferimento nel manifesto dell'applicazione o nei manifesti del servizio di un pacchetto diff che non è presente nel pacchetto dell'applicazione viene automaticamente sostituito con la versione di cui è stato eseguito il provisioning.

Di seguito sono indicati gli scenari adatti per l'uso di un pacchetto diff:

  • Quando si ha un pacchetto dell'applicazione di grandi dimensioni che fa riferimento a più file manifesto del servizio e/o a più pacchetti di codice, configurazione o dati.
  • Quando si ha un sistema di distribuzione che genera il layout della build direttamente dal processo di compilazione dell'applicazione. In questo caso, anche se il codice è rimasto invariato, i nuovi assembly compilati avranno un checksum diverso. L'uso del pacchetto applicazione completo richiederebbe l'aggiornamento della versione in tutti i pacchetti di codice. Usando un pacchetto Diff invece è necessario fornire soltanto i file che sono stati modificati e i file manifesto in cui è cambiata la versione.

Quando si aggiorna un'applicazione tramite Visual Studio, viene pubblicato un pacchetto diff automaticamente. Per creare un pacchetto diff manualmente, è necessario aggiornare il manifesto dell'applicazione e i manifesti del servizio, ma solo i pacchetti modificati devono essere inclusi nel pacchetto finale dell'applicazione.

Si supponga, ad esempio, di iniziare con la seguente applicazione (vengono specificati i numeri di versione per facilitare la comprensione):

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

A questo punto, si supponga di voler aggiornare solo il pacchetto di codice di service1 usando un pacchetto diff. L'applicazione aggiornata presenta le modifiche di versione seguenti:

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 questo caso, il manifesto dell'applicazione viene aggiornato alla versione 2.0.0 e il manifesto del servizio per service1 viene aggiornato in modo da riflettere l'aggiornamento del pacchetto di codice. La cartella per il pacchetto dell'applicazione sarebbe simile alla seguente:

app1/
  service1/
    code/

In altre parole, si crea un pacchetto completo dell'applicazione nel modo consueto e quindi si rimuovono le cartelle dei pacchetti di codice/configurazione/dati delle quali non è stata modificata la versione.

Aggiornare i parametri dell'applicazione indipendentemente dalla versione

In alcuni casi, è consigliabile modificare i parametri di un'applicazione di Service Fabric senza modificare la versione del manifesto. A tale scopo, è possibile usare il flag -ApplicationParameter con il cmdlet PowerShell start-ServiceFabricApplicationUpgrade di Azure Service Fabric. Si supponga che un'applicazione di Service Fabric abbia le proprietà seguenti:

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

A questo punto, aggiornare l'applicazione usando il cmdlet Start-ServiceFabricApplicationUpgrade . Questo esempio mostra un aggiornamento monitorato, ma è anche possibile usare un aggiornamento non monitorato. Per visualizzare una descrizione completa dei flag accettati da questo cmdlet, vedere le informazioni di riferimento sul modulo PowerShell di Azure Service Fabric

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

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

Dopo l'aggiornamento, verificare che l'applicazione abbia i parametri aggiornati e la stessa versione:

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

Eseguire il rollback degli aggiornamenti dell'applicazione

Mentre il roll forward degli aggiornamenti può essere eseguito in tre modalità (Monitored, UnmonitoredAuto o UnmonitoredManual), il rollback può essere eseguito solo in modalità UnmonitoredAuto o UnmonitoredManual. Il rollback in modalità UnmonitoredAuto funziona esattamente come il roll forward, tranne per il fatto che il valore predefinito di UpgradeReplicaSetCheckTimeout è diverso. Vedere Parametri di aggiornamento di un'applicazione. Il rollback in modalità UnmonitoredManual funziona esattamente come il roll forward. Il rollback viene sospeso automaticamente al termine di ogni UD e, per continuare, deve essere ripreso in modo esplicito usando Resume-ServiceFabricApplicationUpgrade.

Le operazioni di rollback possono essere attivate automaticamente quando non vengono rispettati i criteri di integrità di un aggiornamento in modalità Monitored con FailureAction impostato su Rollback (vedere Parametri di aggiornamento di un'applicazione) oppure in modo esplicito usando Start-ServiceFabricApplicationRollback.

Durante il rollback, il valore di UpgradeReplicaSetCheckTimeout e la modalità possono essere comunque modificati in qualsiasi momento usando Update-ServiceFabricApplicationUpgrade.

Passaggi successivi

Esercitazione sull'aggiornamento di un'applicazione di Service Fabric tramite Visual Studio descrive la procedura di aggiornamento di un'applicazione con Visual Studio.

Aggiornamento di un'applicazione mediante PowerShell descrive la procedura di aggiornamento di un'applicazione tramite PowerShell.

Controllare il modo in cui l'applicazione viene aggiornata usando i parametri di aggiornamento.

Rendere compatibili gli aggiornamenti dell'applicazione imparando a usare la serializzazione dei dati.

Risolvere i problemi comuni negli aggiornamenti delle applicazioni facendo riferimento alla procedura descritta in Risoluzione dei problemi relativi agli aggiornamenti delle applicazioni.