Aggiornamento dell'applicazione di Service Fabric: argomenti avanzati

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 dell'applicazione/cluster o la disattivazione dei nodi, le connessioni possono essere eliminate quando l'endpoint esposto viene rimosso dopo che l'istanza diventa inattiva e ciò 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. Questo risultato viene ottenuto quando l'endpoint annunciato dall'istanza senza stato viene rimosso prima dell'inizio del ritardo prima di chiudere l'istanza. Questo ritardo consente alle richieste esistenti di svuotarsi normalmente prima che l'istanza venga effettivamente disattivata. 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 di Resource Manager, 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 è stato modificato, i client devono registrare un callback, vedere Sample ServiceNotificationFilterDescription. La notifica di modifica indica che gli endpoint sono stati modificati, il client deve risolvere nuovamente gli endpoint e non usare più gli endpoint che non vengono più annunciati, perché verranno disattivati a breve.

Override facoltativi dell'aggiornamento

Oltre a impostare durate di ritardo predefinite per servizio, è anche possibile eseguire l'override del ritardo durante l'aggiornamento dell'applicazione/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 le singole configurazioni di ritardo del servizio. Ad esempio, è possibile usare questa opzione per specificare un ritardo di 0 per ignorare eventuali ritardi di aggiornamento preconfigurati.

Modalità di aggiornamento manuale

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

Aggiornare ora l'applicazione usando il cmdlet Start-ServiceFabricApplicationUpgrade . In questo esempio viene illustrato 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 l’aggiornamento dell'applicazione tramite Parametri di aggiornamento.

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

Risolvere problemi comuni negli aggiornamenti dell'applicazione facendo riferimento ai passaggi elencati in Risoluzione dei problemi relativi agli aggiornamenti dell'applicazione .