Service Fabric uygulama yükseltmesi: Gelişmiş konular

Uygulama yükseltmesi sırasında hizmet türleri ekleme veya kaldırma

Yayımlanan bir uygulamaya yükseltmenin bir parçası olarak yeni bir hizmet türü eklenirse, yeni hizmet türü dağıtılan uygulamaya eklenir. Böyle bir yükseltme, zaten uygulamanın parçası olan hizmet örneklerini etkilemez, ancak yeni hizmet türünün etkin olması için eklenen hizmet türünün bir örneğinin oluşturulması gerekir (bkz . New-ServiceFabricService).

Benzer şekilde, hizmet türleri yükseltmenin bir parçası olarak bir uygulamadan kaldırılabilir. Ancak, yükseltmeye devam etmeden önce kaldırılacak hizmet türünün tüm hizmet örnekleri kaldırılmalıdır (bkz . Remove-ServiceFabricService).

Durum bilgisi olmayan hizmet planlı kapalı kalma süresi sırasında bağlantının düşmelerini önleyin

Uygulama/küme yükseltmesi veya düğüm devre dışı bırakma gibi planlanan durum bilgisi olmayan örnek kapalı kalma süreleri için, örnek kapatıldıktan sonra kullanıma sunulan uç nokta kaldırıldıktan sonra bağlantılar bırakılabilir ve bu da bağlantının zorlanmasıyla sonuçlanır.

Bunu önlemek için, küme içinden gelen mevcut isteklerin kullanıma sunulan uç noktaları boşaltmasına izin vermek için hizmet yapılandırmasına bir örnek kapatma gecikme süresi ekleyerek RequestDrain özelliğini yapılandırın. Durum bilgisi olmayan örnek tarafından tanıtılan uç nokta, örneği kapatmadan önce gecikme başlamadan önce kaldırıldığında bu gerçekleştirilir. Bu gecikme, mevcut isteklerin örnek gerçekten kapanmadan önce düzgün bir şekilde boşaltılabilmesini sağlar. İstemcilere gecikmeyi başlatırken bir geri çağırma işlevi tarafından uç nokta değişikliği bildirilir, böylece uç noktayı yeniden çözümleyebilir ve kapanan örneğe yeni istekler göndermekten kaçınabilir. Bu istekler Ters Ara Sunucu kullanan istemcilerden veya uç noktaları güncelleştirmek için bildirim modeliyle (ServiceNotificationFilterDescription) hizmet uç noktası çözümleme API'lerini kullanıyor olabilir.

Servis Yapılandırması

Hizmet tarafında gecikmeyi yapılandırmanın çeşitli yolları vardır.

• Yeni bir hizmet oluştururken bir -InstanceCloseDelayDurationbelirtin:

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

• Uygulama bildirimindeki varsayılanlar bölümünde hizmeti tanımlarken özelliğini atayın InstanceCloseDelayDurationSeconds :

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

• Mevcut bir hizmeti güncelleştirirken bir -InstanceCloseDelayDurationbelirtin:

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

• ARM şablonu aracılığıyla mevcut bir hizmeti oluştururken veya güncelleştirirken değeri belirtin InstanceCloseDelayDuration (desteklenen en düşük API sürümü: 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"
    }
  }
  

İstemci yapılandırması

Uç nokta değiştiğinde bildirim almak için istemcilerin geri çağırma kaydetmesi gerekir. Bkz . Örnek ServiceNotificationFilterDescription. Değişiklik bildirimi, uç noktaların değiştiğini, istemcinin uç noktaları yeniden çözümlemesi ve yakında kapanacağı için artık tanıtılmayan uç noktaları kullanmaması gerektiğinin bir göstergesidir.

İsteğe bağlı yükseltme geçersiz kılmaları

Hizmet başına varsayılan gecikme sürelerini ayarlamaya ek olarak, aynı (InstanceCloseDelayDurationSec) seçeneği kullanarak uygulama/küme yükseltmesi sırasındaki gecikmeyi de geçersiz kılabilirsiniz:

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

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

Geçersiz kılınan gecikme süresi yalnızca çağrılan yükseltme örneği için geçerlidir ve tek tek hizmet gecikmesi yapılandırmalarını değiştirmez. Örneğin, önceden yapılandırılmış yükseltme gecikmelerini 0 atlamak için bir gecikme süresi belirtmek için bunu kullanabilirsiniz.

El ile yükseltme modu

İzleme modunda Service Fabric, yükseltme ilerledikçe uygulamanın iyi durumda olduğundan emin olmak için sistem durumu ilkelerini uygular. Sistem durumu ilkeleri ihlal edilirse, belirtilen FailureAction'a bağlı olarak yükseltme askıya alınır veya otomatik olarak geri alınır.

UnmonitoredManual modunda, uygulama yöneticisi yükseltmenin ilerleme durumu üzerinde tam denetime sahiptir. Bu mod, özel sistem durumu değerlendirme ilkeleri uygularken veya sistem durumu izlemeyi tamamen atlamak için geleneksel olmayan yükseltmeler gerçekleştirirken kullanışlıdır (örn. uygulama zaten veri kaybı içindedir). Bu modda çalışan bir yükseltme, her UD tamamlandıktan sonra kendini askıya alır ve Resume-ServiceFabricApplicationUpgrade kullanılarak açıkça sürdürülmelidir. Yükseltme askıya alınıp kullanıcı tarafından sürdürülmeye hazır olduğunda yükseltme durumu RollforwardPending olarak gösterilir (bkz. UpgradeState).

Son olarak, Kullanıcı girişi gerekmediğinden ve hiçbir uygulama durumu ilkesi değerlendirilmediğinden, UnmonitoredAuto modu hizmet geliştirme veya test sırasında hızlı yükseltme yinelemeleri gerçekleştirmek için kullanışlıdır.

Fark paketiyle yükseltme

Tam bir uygulama paketi sağlamak yerine, yükseltmeler yalnızca güncelleştirilmiş kod/yapılandırma/veri paketlerinin yanı sıra eksiksiz uygulama bildirimi ve eksiksiz hizmet bildirimlerini içeren fark paketleri sağlanarak da gerçekleştirilebilir. Tam uygulama paketleri yalnızca bir uygulamanın kümeye ilk yüklenmesi için gereklidir. Sonraki yükseltmeler tam uygulama paketlerinden veya fark paketlerinden olabilir.

Bir fark paketinin uygulama bildiriminde veya hizmet bildirimlerinde yer alan ve uygulama paketinde bulunmayan tüm başvurular otomatik olarak sağlanan sürümle değiştirilir.

Fark paketi kullanma senaryoları şunlardır:

• Çeşitli hizmet bildirim dosyalarına ve/veya çeşitli kod paketlerine, yapılandırma paketlerine veya veri paketlerine başvuran büyük bir uygulama paketiniz olduğunda.
• Derleme düzenini doğrudan uygulama derleme işleminizden oluşturan bir dağıtım sisteminiz olduğunda. Bu durumda kod değişmemiş olsa da yeni oluşturulan derlemeler farklı bir sağlama toplamı alır. Tam bir uygulama paketi kullanmak için tüm kod paketlerinde sürümü güncelleştirmeniz gerekir. Fark paketi kullanarak yalnızca değiştirilen dosyaları ve sürümün değiştirildiği bildirim dosyalarını sağlarsınız.

Visual Studio kullanılarak bir uygulama yükseltildiğinde, bir fark paketi otomatik olarak yayımlanır. El ile fark paketi oluşturmak için uygulama bildirimi ve hizmet bildirimleri güncelleştirilmelidir, ancak son uygulama paketine yalnızca değiştirilen paketler dahil edilmelidir.

Örneğin, aşağıdaki uygulamayla başlayalım (anlama kolaylığı için sağlanan sürüm numaraları):

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

Fark paketini kullanarak yalnızca service1 kod paketini güncelleştirmek istediğinizi varsayalım. Güncelleştirilmiş uygulamanızda aşağıdaki sürüm değişiklikleri var:

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

Bu durumda, uygulama bildirimini 2.0.0'a ve service1 hizmet bildirimini kod paketi güncelleştirmesini yansıtacak şekilde güncelleştirirsiniz. Uygulama paketinizin klasörü aşağıdaki yapıya sahip olacaktır:

app1/
  service1/
    code/

Başka bir deyişle, normal bir şekilde eksiksiz bir uygulama paketi oluşturun, ardından sürümün değişmediği tüm kod/yapılandırma/veri paketi klasörlerini kaldırın.

Uygulama parametrelerini sürümden bağımsız olarak yükseltme

Bazen bildirim sürümünü değiştirmeden Service Fabric uygulamasının parametrelerini değiştirmek tercih edilir. Bu, Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell cmdlet'i ile -ApplicationParameter bayrağı kullanılarak rahatça yapılabilir. Aşağıdaki özelliklere sahip bir Service Fabric uygulaması varsayın:

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

Şimdi Start-ServiceFabricApplicationUpgrade cmdlet'ini kullanarak uygulamayı yükseltin. Bu örnekte izlenen bir yükseltme gösterilmektedir, ancak izlenmeyen bir yükseltme de kullanılabilir. Bu cmdlet tarafından kabul edilen bayrakların tam açıklamasını görmek için bkz . Azure Service Fabric PowerShell modülü başvurusu

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

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

Yükseltmeden sonra, uygulamanın güncelleştirilmiş parametrelere ve aynı sürüme sahip olduğunu onaylayın:

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

Uygulama yükseltmelerini geri alma

Yükseltmeler üç moddan birinde (monitored, UnmonitoredAuto veya UnmonitoredManual) ileriye doğru getirilebilir ancak yalnızca UnmonitoredAuto veya UnmonitoredManual modunda geri alınabilir. UnmonitoredAuto modunda geri alma işlemi, UpgradeReplicaSetCheckTimeout varsayılan değerinin farklı olması dışında ileri sarma ile aynı şekilde çalışır. Bkz. Uygulama Yükseltme Parametreleri. UnmonitoredManual modunda geri alma, ileri sarma ile aynı şekilde çalışır. Geri alma işlemi her UD tamamlandıktan sonra kendini askıya alır ve geri alma işlemine devam etmek için Resume-ServiceFabricApplicationUpgrade kullanılarak açıkça sürdürülmelidir.

Geri alma işlemleri, Geri Alma Hatasıyla İzlenen modda yükseltmenin sistem durumu ilkeleri ihlal edildiğinde (bkz. Uygulama Yükseltme Parametreleri) veya Start-ServiceFabricApplicationRollback kullanılarak otomatik olarak tetiklenebilir.

Geri alma sırasında UpgradeReplicaSetCheckTimeout ve modun değeri update-ServiceFabricApplicationUpgrade kullanılarak herhangi bir zamanda değiştirilebilir.

Sonraki adımlar

Visual Studio Kullanarak Uygulamanızı Yükseltme, Visual Studio kullanarak uygulama yükseltme işleminde size yol gösterir.

PowerShell Kullanarak Uygulamanızı Yükseltme, PowerShell kullanarak uygulama yükseltme işleminde size yol gösterir.

Yükseltme Parametrelerini kullanarak uygulamanızın yükseltme şeklini kontrol edin.

Veri Serileştirme'yi kullanmayı öğrenerek uygulama yükseltmelerinizi uyumlu hale getirin.

Uygulama Yükseltmelerinde Sorun Giderme makalesindeki adımlara başvurarak uygulama yükseltmelerindeki yaygın sorunları düzeltin.