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 létre kell hozni a hozzáadott szolgáltatástípus egy példányát 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. A frissítés előtt azonban el kell távolítani az eltávolítandó szolgáltatástípus összes szolgáltatáspéldányát (lásd: Remove-ServiceFabricService).

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

Tervezett állapot nélküli példányleállások, például alkalmazás-/fürtfrissítés vagy csomópont-inaktiválás esetén a kapcsolatok megszakadhatnak, mivel a közzétett végpont a példány leállása után el lesz távolítva, ami kényszerített kapcsolatlezárásokat eredményez.

Ennek elkerülése érdekében konfigurálja a RequestDrain szolgáltatást úgy, hogy a szolgáltatáskonfigurációban egy példány közeli késleltetési időtartamot ad hozzá, hogy a fürtből érkező meglévő kérések leüredjenek a közzétett végpontokon. Ez akkor érhető el, ha 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ésés lehetővé teszi, hogy a meglévő kérések kecsesen leürüljenek, mielőtt a példány ténylegesen leáll. Az ügyfelek értesítést kapnak a végpontváltozásról egy visszahívási függvénnyel a késés indításakor, 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 szolgáltatásvégpontfeloldási API-k értesítési modellel (ServiceNotificationFilterDescription) való használatával származhatnak a végpontok frissítéséhez.

Szolgáltatáskonfiguráció

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

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

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

  • A szolgáltatás az alkalmazásjegyzék alapértelmezett szakaszában való definiálása közben 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-sablonon keresztül 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ásáról, 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állnak.

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 a 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éssések konfigurációit. Ezzel például megadhat egy késleltetést 0 az előre konfigurált frissítési késések kihagyásához.

Feljegyzés

  • A kérések ürítésére szolgáló beállítások nem akadályozhatják meg, hogy az Azure Load Balancer új kéréseket küldjön a lefolyóban lévő végpontoknak.
  • A panaszalapú megoldási mechanizmus nem eredményezi a kérések kecses 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 bővíteni, hogy a ServiceNotificationFilterDescription használatával feliratkozzon a végpontmódosítási értesítésekre.
  • A beállítások nem teljesülnek, ha a frissítés hatástalan, azaz amikor a replikák nem lesznek leküldve a frissítés során.
  • Az InstanceCloseDelayDuration maximális értéke, amely konfigurálható a szolgáltatás leírásában vagy az InstanceCloseDelayDurationSec a frissítés leírásában, nem lehet nagyobb, mint a fürtkonfiguráció FeladatátvételManager.MaxInstanceCloseDelayDurationInSeconds konfigurációja, 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.

Feljegyzés

Ez a funkció konfigurálható a meglévő szolgáltatásokban az 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

Feljegyzés

A Figyelt frissítési mód minden Service Fabric-frissítéshez ajánlott. A 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 állapotban legyen a frissítés előrehaladása során. Ha megsértik az állapotszabályzatokat, akkor 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ásadminisztrátor 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 explicit módon kell folytatni a Resume-ServiceFabricApplicationUpgrade használatával. Ha a felhasználó felfüggeszt egy frissítést, és készen áll a folytatásra, annak frissítési állapota a RollforwardPending (lásd: UpgradeState) állapotot jeleníti meg.

Végül a UnmonitoredAuto mód hasznos 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 bemenetre, és nem történik alkalmazásállapot-szabályzatok kiértékelése.

Frissítés diff csomaggal

A teljes alkalmazáscsomag kiépítése helyett a frissítéseket úgy is végrehajthatja, hogy olyan diff-csomagokat épít ki, amelyek csak a frissített kódot/konfigurációt/adatcsomagokat tartalmazzák, valamint a teljes alkalmazásjegyzéket és a teljes szolgáltatásjegyzéket. A teljes alkalmazáscsomagok csak az alkalmazás fürtbe történő 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.

Az alkalmazásjegyzékben vagy a szolgáltatásjegyzékben található, az alkalmazáscsomagban nem található hivatkozásokat a rendszer automatikusan lecseréli a jelenleg kiosztott verzióra.

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

  • Ha egy nagy alkalmazáscsomag 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 összeállítá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. Diff-csomag használatával csak a módosított fájlokat és a verziót módosító jegyzékfájlokat adja meg.

Ha egy alkalmazást a Visual Studióval frissít, a rendszer automatikusan közzéteszi a diff-csomagokat. Ha manuálisan szeretne létrehozni egy diff csomagot, frissíteni kell az alkalmazásjegyzéket és a szolgáltatásjegyzékeket, de csak a módosított csomagokat kell tartalmaznia a végső alkalmazáscsomagban.

Kezdjük például a következő alkalmazással (a könnyebb érthetőség é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 a következő verzióváltozásokkal rendelkezik:

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 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, majd távolítsa el azokat a kód-/konfiguráció-/adatcsomag-mappákat, amelyeken a verzió nem változott.

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

Néha célszerű módosítani egy Service Fabric-alkalmazás paramétereit a jegyzékverzió módosítása nélkül. Ez kényelmesen elvégezhető az -ApplicationParameter jelölő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 hivatkozásában tekintheti meg.

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 ellenőrizze, hogy az alkalmazás rendelkezik-e 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 Visszagördítés UnmonitoredAuto módban ugyanúgy működik, mint a továbblépés, azzal a kivétellel, hogy az UpgradeReplicaSetCheckTimeout alapértelmezett értéke eltérő – lásd az alkalmazásfrissítési paramétereket. A Visszalépés UnmonitoredManual módban 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 a visszaállítás folytatásához explicit módon újra kell folytatni a Resume-ServiceFabricApplicationUpgrade használatával.

A visszaállítások automatikusan aktiválhatók, ha a frissítés állapotszabályzatait a Rendszer megsérti a visszaállítási hibahiba miatt figyelt módban (lásd az alkalmazásfrissítési paramétereket), vagy explicit módon használja a Start-ServiceFabricApplicationRollback szolgáltatást.

A visszaállítás során az UpgradeReplicaSetCheckTimeout é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 egy alkalmazásfrissítésen a Visual Studióval.

Az alkalmazás PowerShell-lel való frissítése végigvezeti az alkalmazás frissítésén a PowerShell használatával.

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

Az alkalmazásfrissítések kompatibilissé tételéhez ismerje meg, hogyan használhatja az adat szerializálást.

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