Share via


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

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

Bir yükseltmenin parçası olarak yayımlanmış bir uygulamaya yeni bir hizmet türü eklenirse, yeni hizmet türü dağıtılan uygulamaya eklenir. Böyle bir yükseltme, uygulamanın zaten 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 bir yükseltmenin 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 kesintiye uğramasını önleme

Uygulama/küme yükseltmesi veya düğüm devre dışı bırakma gibi planlı durum bilgisi olmayan örnek kapalı kalma süreleri için, örnek kapandı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ümenin 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ığından bu elde edilir. 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.

Hizmet 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 bildiriminin defaults 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 gecikme yapılandırmalarını değiştirmez. Örneğin, önceden yapılandırılmış yükseltme gecikmelerini atlamak için bir gecikme 0 belirtmek için bunu kullanabilirsiniz.

Not

  • İstekleri boşaltma ayarları, Azure Load balancer'ın boşaltılan uç noktalara yeni istekler göndermesini engelleyemez.
  • Bir şikayet tabanlı çözüm mekanizması, bir hatadan sonra hizmet çözümünü tetiklediğinden isteklerin düzgün bir şekilde boşaltılmasıyla sonuçlanmaz. Daha önce açıklandığı gibi, bunun yerine ServiceNotificationFilterDescription kullanarak uç nokta değişiklik bildirimlerine abone olacak şekilde iyileştirilmelidir.
  • Yükseltme, yükseltme sırasında çoğaltmaların indirilmemesi gibi etkisiz bir ayar olduğunda ayarlara dikkat edilmez.
  • Hizmet açıklamasında yapılandırılabilir InstanceCloseDelayDuration veya yükseltme açıklamasındaki InstanceCloseDelayDurationSec maksimum değeri, varsayılan olarak 1800 saniye olan FailoverManager.MaxInstanceCloseDelayDurationInSeconds küme yapılandırmasından büyük olamaz. En yüksek değeri güncelleştirmek için küme düzeyi yapılandırmasının güncelleştirilmesi gerekir. Bu yapılandırma yalnızca çalışma zamanı 9.0 veya sonraki bir sürümde kullanılabilir.

Not

Bu özellik, küme kodu sürümü 7.1.XXX veya üzeri olduğunda, yukarıda belirtildiği gibi Update-ServiceFabricService cmdlet'i veya ARM şablonu kullanılarak mevcut hizmetlerde yapılandırılabilir.

El ile yükseltme modu

Not

tüm Service Fabric yükseltmeleri için İzlenen yükseltme modu önerilir. UnmonitoredManual yükseltme modu yalnızca başarısız veya askıya alınmış yükseltmeler için dikkate alınmalıdır.

İ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, yükseltme askıya alınır veya belirtilen FailureAction'a bağlı olarak 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 yararlıdır (örn. uygulama zaten veri kaybındadır). 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. Bir yükseltme askıya alınıp kullanıcı tarafından sürdürülmeye hazır olduğunda yükseltme durumu RollforwardPending'i gösterir (bkz . UpgradeState).

Son olarak UnmonitoredAuto modu, kullanıcı girişi gerekmediğinden ve hiçbir uygulama durumu ilkesi değerlendirilmediğinden hizmet geliştirme veya test sırasında hızlı yükseltme yinelemeleri gerçekleştirmek için yararlı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.

Uygulama paketinde bulunamaz bir fark paketinin uygulama bildirimindeki veya hizmet bildirimlerindeki başvurular otomatik olarak şu anda 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ştiği bildirim dosyalarını sağlarsınız.

Bir uygulama Visual Studio kullanılarak yükseltildiğinde, 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 eklenmelidir.

Ö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 paketi kullanarak yalnızca service1 kod paketini güncelleştirmek istediğinizi varsayalım. Güncelleştirilmiş uygulamanız aşağıdaki sürüm değişikliklerine sahip:

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 şekilde eksiksiz bir uygulama paketi oluşturun, ardından sürümün değişmediği 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 getirilse de, bunlar yalnızca UnmonitoredAuto veya UnmonitoredManual modunda geri alınabiliyor. UnmonitoredAuto modunda geri alma işlemi, UpgradeReplicaSetCheckTimeout varsayılan değerinin farklı olması dışında ileri sarmayla aynı şekilde çalışır. Bkz. Uygulama Yükseltme Parametreleri. UnmonitoredManual modunda geri alma, ileri sarmayla 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 İşlemi Başarısız Olduğunda İzlenen modda yükseltmenin sistem durumu ilkeleri ihlal edildiğinde (bkz. Uygulama Yükseltme Parametreleri) veya Açıkça Start-ServiceFabricApplicationRollback kullanıldığında geri alma işlemleri otomatik olarak tetiklenebilir.

Geri alma sırasında UpgradeReplicaSetCheckTimeout değeri ve mod herhangi bir zamanda Update-ServiceFabricApplicationUpgrade kullanılarak 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.

Uygulamanızı PowerShell kullanarak 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ükseltmeleriyle İlgili Sorunları Giderme bölümündeki adımlara başvurarak uygulama yükseltmelerindeki yaygın sorunları düzeltin.