Megosztás a következőn keresztül:

Service Fabric-alkalmazás frissítése: Speciális témakörök

  • Cikk

Szolgáltatástípusok hozzáadása vagy eltávolítása egy alkalmazásfrissítés során

Ha egy frissítés részeként új szolgáltatástípust ad hozzá egy közzétett alkalmazáshoz, akkor az új szolgáltatástípus hozzá lesz adva az üzembe helyezett alkalmazáshoz. Az ilyen frissítés nem érinti az alkalmazás részét képező szolgáltatáspéldányokat, de a hozzáadott szolgáltatástípus egy példányát létre kell hozni ahhoz, hogy az új szolgáltatástípus aktív legyen (lásd: New-ServiceFabricService).

Hasonlóképpen, a szolgáltatástípusok el is távolíthatók egy alkalmazásból a frissítés részeként. Az eltávolítandó szolgáltatástípus összes szolgáltatáspéldányát azonban el kell távolítani a frissítés előtt (lásd: Remove-ServiceFabricService).

A kapcsolat megszakadásának elkerülése az állapot nélküli szolgáltatás tervezett leállásakor

A tervezett állapot nélküli példányleállások, például az alkalmazás/fürt frissítése vagy a csomópont inaktiválása esetén a kapcsolatok megszakadhatnak, mivel a közzétett végpont a példány leállása után törlődik, ami kényszerített kapcsolatlezárásokat eredményez.

Ennek elkerülése érdekében konfigurálja a RequestDrain szolgáltatást úgy, hogy hozzáad egy példány közeli késleltetési időtartamot a szolgáltatáskonfigurációban, hogy a fürtből érkező meglévő kérések kiüríthetők legyenek a közzétett végpontokon. Ez úgy érhető el, hogy az állapot nélküli példány által meghirdetett végpont el lesz távolítva, mielőtt a késés elindul a példány bezárása előtt. Ez a késleltetés lehetővé teszi, hogy a meglévő kérések türelmesen ürítse ki a példány tényleges leállását. Az ügyfelek a késés indításakor értesítést kapnak a végpont módosításáról egy visszahívási függvénnyel, hogy újra feloldhassák a végpontot, és ne küldjenek új kéréseket a leálló példánynak. Ezek a kérések a fordított proxyt használó ügyfelektől vagy a végpontok frissítésére szolgáló értesítési modell (ServiceNotificationFilterDescription) szolgáltatásvégpontfeloldási API-jait használó ügyfelektől származhatnak.

Szolgáltatáskonfiguráció

A késést többféleképpen is konfigurálhatja a szolgáltatásoldalon.

  • Új szolgáltatás létrehozásakor adja meg a következőt -InstanceCloseDelayDuration:

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

  • Miközben a szolgáltatást az alkalmazásjegyzék alapértelmezett szakaszában definiálja, rendelje hozzá a tulajdonságot InstanceCloseDelayDurationSeconds :

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

  • Meglévő szolgáltatás frissítésekor adja meg a következőt -InstanceCloseDelayDuration:

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

  • Meglévő szolgáltatás ARM-sablonnal történő létrehozásakor vagy frissítésekor adja meg az InstanceCloseDelayDuration értéket (minimálisan támogatott API-verzió: 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"
  }
}

Ügyfél-konfiguráció

Ha értesítést szeretne kapni egy végpont módosításakor, az ügyfeleknek visszahívást kell regisztrálniuk, lásd: ServiceNotificationFilterDescription minta. A változásértesítés azt jelzi, hogy a végpontok megváltoztak, az ügyfélnek újra fel kell oldania a végpontokat, és nem kell használnia a már nem meghirdetett végpontokat, mivel hamarosan le fognak menni.

Választható frissítési felülbírálások

A szolgáltatásonkénti alapértelmezett késleltetési időtartamok beállítása mellett az alkalmazás/fürt frissítése során jelentkező késést is felülbírálhatja ugyanazzal a (InstanceCloseDelayDurationSec) beállítással:

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

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

A felülírt késleltetési időtartam csak a meghívott frissítési példányra vonatkozik, és más módon nem módosítja az egyes szolgáltatáskésésési konfigurációkat. Ezzel például megadhat egy késleltetést 0 az előre konfigurált frissítési késések kihagyásához.

Megjegyzés

  • A kérések kiürítésére szolgáló beállítások nem fogják tudni megakadályozni, hogy az Azure Load Balancer új kéréseket küldjön a kiürítés alatt álló végpontoknak.
  • A panaszalapú megoldási mechanizmus nem eredményezi a kérések türelmes kiürítését, mivel hiba után szolgáltatásmegoldást indít el. A korábban leírtaknak megfelelően ezt tovább kell javítani, hogy feliratkozzon a végpontmódosítási értesítésekre a ServiceNotificationFilterDescription használatával.
  • A beállítások nem teljesülnek, ha a frissítés hatástalan, azaz amikor a replikák nem lesznek lehozva a frissítés során.
  • A szolgáltatás leírásában konfigurálható InstanceCloseDelayDurationSec maximális értéke vagy a frissítési leírásban szereplő InstanceCloseDelayDurationSec értéke nem lehet nagyobb, mint a fürtkonfigurálás FailoverManager.MaxInstanceCloseDelayDurationInSeconds értéke, amely alapértelmezés szerint 1800 másodperc. A maximális érték frissítéséhez frissíteni kell a fürtszintű konfigurációt. Ez a konfiguráció csak a futtatókörnyezet 9.0-s vagy újabb verziójában érhető el.

Megjegyzés

Ez a funkció a meglévő szolgáltatásokban konfigurálható Update-ServiceFabricService parancsmaggal vagy a fent említett ARM-sablonnal, ha a fürtkód verziója 7.1.XXX vagy annál magasabb.

Manuális frissítési mód

Megjegyzés

A Figyelt frissítési mód minden Service Fabric-frissítéshez ajánlott. Az UnmonitoredManual frissítési módot csak a sikertelen vagy felfüggesztett frissítések esetében szabad figyelembe venni.

Figyelt módban a Service Fabric állapotszabályzatokat alkalmaz annak biztosítására, hogy az alkalmazás kifogástalan állapotú legyen a frissítés előrehaladásával. Ha az állapotszabályzatok sérülnek, a rendszer felfüggeszti vagy automatikusan visszaállítja a frissítést a megadott FailureAction függvénytől függően.

UnmonitoredManual módban az alkalmazás rendszergazdája teljes mértékben szabályozhatja a frissítés előrehaladását. Ez a mód akkor hasznos, ha egyéni állapotértékelési szabályzatokat alkalmaz, vagy nem hagyományos frissítéseket hajt végre az állapotfigyelés teljes megkerülése érdekében (például az alkalmazás már adatvesztésben van). Az ebben a módban futó frissítés az egyes UD-k befejezése után felfüggeszti magát, és a Resume-ServiceFabricApplicationUpgrade használatával explicit módon kell folytatni. Ha a felhasználó felfüggeszti a frissítést, és készen áll a folytatásra, a frissítés állapota a RollforwardPending ( Frissítési állapot) állapotot jeleníti meg.

Végül a UnmonitoredAuto mód hasznos a gyors frissítési iterációk végrehajtásához a szolgáltatásfejlesztés vagy tesztelés során, mivel nincs szükség felhasználói bevitelre, és nem történik alkalmazásállapot-szabályzatok kiértékelése.

Frissítés diff csomaggal

Ahelyett, hogy egy teljes alkalmazáscsomagot építenénk ki, a frissítéseket úgy is végrehajthatjuk, hogy olyan diff csomagokat építünk ki, amelyek csak a frissített kódot/konfigurációt/adatcsomagokat tartalmazzák a teljes alkalmazásjegyzékkel és a teljes szolgáltatásjegyzékkel együtt. A teljes alkalmazáscsomagok csak az alkalmazás fürtre való kezdeti telepítéséhez szükségesek. A későbbi frissítések teljes alkalmazáscsomagokból vagy diff csomagokból származhatnak.

A rendszer automatikusan lecseréli az alkalmazáscsomagban nem található diff csomag alkalmazásjegyzékében vagy szolgáltatásjegyzékében szereplő hivatkozásokat a jelenleg kiépített verzióra.

A diff-csomagok használatának forgatókönyvei a következők:

  • Ha nagy méretű alkalmazáscsomaggal rendelkezik, amely több szolgáltatásjegyzékfájlra és/vagy több kódcsomagra, konfigurációs csomagra vagy adatcsomagra hivatkozik.
  • Ha olyan központi telepítési rendszerrel rendelkezik, amely közvetlenül az alkalmazás buildelési folyamatából hozza létre a buildelrendezést. Ebben az esetben annak ellenére, hogy a kód nem változott, az újonnan létrehozott szerelvények eltérő ellenőrzőösszeget kapnak. A teljes alkalmazáscsomag használatához frissítenie kell a verziót az összes kódcsomagon. A diff csomag használatával csak a módosított fájlokat és azokat a jegyzékfájlokat adja meg, amelyekben a verzió megváltozott.

Ha egy alkalmazást a Visual Studióval frissít, a rendszer automatikusan közzéteszi a diff csomagot. A diff csomag manuális létrehozásához frissíteni kell az alkalmazásjegyzéket és a szolgáltatásjegyzékeket, de csak a módosított csomagokat kell belefoglalni a végső alkalmazáscsomagba.

Kezdjük például a következő alkalmazással (a könnyebb megértés érdekében megadott verziószámokkal):

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

Tegyük fel, hogy csak a service1 kódcsomagját szeretné frissíteni egy diff csomag használatával. A frissített alkalmazás verzióváltozásai a következők:

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

Ebben az esetben az alkalmazásjegyzéket a 2.0.0-ra, a service1 szolgáltatásjegyzékét pedig a kódcsomag frissítésének megfelelően frissíti. Az alkalmazáscsomag mappája a következő struktúrával rendelkezik:

app1/
  service1/
    code/

Más szóval hozzon létre egy teljes alkalmazáscsomagot általában, majd távolítsa el azokat a kód-/konfiguráció-/adatcsomag-mappákat, amelyek verziószáma nem változott.

Alkalmazásparaméterek frissítése a verziótól függetlenül

Néha kívánatos a Service Fabric-alkalmazások paramétereinek módosítása a jegyzékverzió módosítása nélkül. Ez kényelmesen elvégezhető az -ApplicationParameter jelzővel a Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell-parancsmaggal. Tegyük fel, hogy egy Service Fabric-alkalmazás a következő tulajdonságokkal rendelkezik:

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

Most frissítse az alkalmazást a Start-ServiceFabricApplicationUpgrade parancsmaggal. Ez a példa egy figyelt frissítést mutat be, de nem figyelt frissítés is használható. A parancsmag által elfogadott jelzők teljes leírását az Azure Service Fabric PowerShell-modul referenciájában találja.

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

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

A frissítés után győződjön meg arról, hogy az alkalmazás rendelkezik a frissített paraméterekkel és ugyanazzal a verzióval:

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

Alkalmazásfrissítések visszaállítása

Bár a frissítések három módban (Monitorozott, UnmonitoredAuto vagy UnmonitoredManual) terjeszthetők elő, ezek csak UnmonitoredAuto vagy UnmonitoredManual módban állíthatók vissza. A Nem figyeltAuto módban történő visszagördülés ugyanúgy működik, mint az előregördülés, azzal a kivétellel, hogy az UpgradeReplicaSetCheckTimeout alapértelmezett értéke eltérő – lásd: Alkalmazásfrissítési paraméterek. A Nem figyeltManual módba való visszagörgetés ugyanúgy működik, mint a visszaállítás – a visszaállítás az egyes UD-k befejezése után felfüggeszti magát, és explicit módon újra kell folytatni a Resume-ServiceFabricApplicationUpgrade használatával a visszaállítás folytatásához.

A visszaállítások automatikusan aktiválhatók, ha a rendszer megsérti a felügyelt módban a visszaállítás sikertelenségét jelző frissítés állapotszabályzatait (lásd: Alkalmazásfrissítési paraméterek), vagy explicit módon használja a Start-ServiceFabricApplicationRollback szolgáltatást.

A visszaállítás során az UpdateReplicaSetCheckTimeout és a mód értéke bármikor módosítható az Update-ServiceFabricApplicationUpgrade használatával.

Következő lépések

Az alkalmazás Visual Studio használatával történő frissítése végigvezeti a Visual Studióval végzett alkalmazásfrissítésen.

Az alkalmazás PowerShell-lel történő frissítése végigvezeti a PowerShell használatával végzett alkalmazásfrissítésen.

A frissítési paraméterek használatával szabályozhatja az alkalmazás frissítési módját.

Az adatszializálás használatának elsajátításával kompatibilissé teheti az alkalmazásfrissítéseket.

Az alkalmazásfrissítések gyakori problémáinak megoldásához kövesse az alkalmazásfrissítések hibaelhárítása című témakör lépéseit.