Uygulama yükseltme ile ilgili sorunları giderme
Bu makalede, Azure Service Fabric uygulamasını yükseltme ve bunların nasıl çözüleceğini konu alan bazı yaygın sorunlar ele alınıyor.
Başarısız uygulama yükseltme sorunlarını giderme
Yükseltme başarısız olduğunda , Get-ServiceFabricApplicationUpgrade komutunun çıkışı hata ayıklamaya yönelik ek bilgiler içerir. Aşağıdaki liste ek bilgilerin nasıl kullanılabileceğini belirtir:
- Hata türünü tanımlayın.
- Hatanın nedenini belirleyin.
- Daha fazla araştırma için bir veya daha fazla başarısız bileşeni yalıtma.
Bu bilgiler, FailureAction'ın yükseltmeyi geri almak veya askıya almak olup olmadığına bakılmaksızın Service Fabric hatayı algıladığında kullanılabilir.
Hata türünü belirleme
Get-ServiceFabricApplicationUpgrade çıkışında FailureTimestampUtc, Service Fabric ve FailureAction tarafından bir yükseltme hatasının algılandığı zaman damgasını (UTC olarak) tanımlar. FailureReason, hatanın üç olası üst düzey nedenden birini tanımlar:
- UpgradeDomainTimeout - Belirli bir yükseltme etki alanının tamamlanmasının çok uzun sürdüğünü ve UpgradeDomainTimeout'un süresinin dolduğunu gösterir.
- OverallUpgradeTimeout - Genel yükseltmenin tamamlanmasının çok uzun sürdüğünü ve UpgradeTimeout'un süresinin dolduğunu gösterir.
- HealthCheck - Bir güncelleştirme etki alanını yükselttikten sonra uygulamanın belirtilen sistem durumu ilkelerine göre iyi durumda olmadığını ve HealthCheckRetryTimeout'un süresinin dolduğunu gösterir.
Bu girdiler yalnızca yükseltme başarısız olduğunda ve geri dönmeye başladığında çıkışta gösterilir. Hatanın türüne bağlı olarak daha fazla bilgi görüntülenir.
Yükseltme zaman aşımlarını araştırma
Yükseltme zaman aşımı hatalarının en yaygın nedeni hizmet kullanılabilirliği sorunlarıdır. Bu paragrafın ardından gelen çıkış, hizmet çoğaltmalarının veya örneklerin yeni kod sürümünde başlatılaamamasına neden olan yükseltmelerin tipik bir örneğidir. UpgradeDomainProgressAtFailure alanı, hata anında bekleyen yükseltme çalışmalarının anlık görüntüsünü yakalar.
Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName : fabric:/DemoApp
ApplicationTypeName : DemoAppType
TargetApplicationTypeVersion : v2
ApplicationParameters : {}
StartTimestampUtc : 4/14/2015 9:26:38 PM
FailureTimestampUtc : 4/14/2015 9:27:05 PM
FailureReason : UpgradeDomainTimeout
UpgradeDomainProgressAtFailure : MYUD1
NodeName : Node4
UpgradePhase : PostUpgradeSafetyCheck
PendingSafetyChecks :
WaitForPrimaryPlacement - PartitionId: 744c8d9f-1d26-417e-a60e-cd48f5c098f0
NodeName : Node1
UpgradePhase : PostUpgradeSafetyCheck
PendingSafetyChecks :
WaitForPrimaryPlacement - PartitionId: 4b43f4d8-b26b-424e-9307-7a7a62e79750
UpgradeState : RollingBackCompleted
UpgradeDuration : 00:00:46
CurrentUpgradeDomainDuration : 00:00:00
NextUpgradeDomain :
UpgradeDomainsStatus : { "MYUD1" = "Completed";
"MYUD2" = "Completed";
"MYUD3" = "Completed" }
UpgradeKind : Rolling
RollingUpgradeMode : UnmonitoredAuto
ForceRestart : False
UpgradeReplicaSetCheckTimeout : 00:00:00
Bu örnekte, yükseltme MYUD1 yükseltme etki alanında başarısız oldu ve iki bölüm (744c8d9f-1d26-417e-a60e-cd48f5c098f0 ve 4b43f4d8-b26b-424e-9307-7a7a62e79750) takıldı. Çalışma zamanı Node1 ve Node4 hedef düğümlerine birincil çoğaltmaları (WaitForPrimaryPlacement) yerleştiremediğinden bölümler takıldı.
Get-ServiceFabricNode komutu, bu iki düğümün MYUD1 yükseltme etki alanında olduğunu doğrulamak için kullanılabilir. UpgradePhase, PostUpgradeSafetyCheck ifadesini kullanır. Bu, yükseltme etki alanındaki tüm düğümler yükseltmeyi bitirdikten sonra bu güvenlik denetimlerinin gerçekleştiği anlamına gelir. Tüm bu bilgiler, uygulama kodunun yeni sürümünde olası bir soruna işaret etmektedir. En yaygın sorunlar, birincil kod yollarına açma veya yükseltmedeki hizmet hatalarıdır.
PreUpgradeSafetyCheckUpgradePhase değeri, yükseltme etki alanı gerçekleştirilmeden önce hazırlanırken sorun oluştuğu anlamına gelir. Bu durumda en yaygın sorunlar, birincil kod yollarından kapatma veya indirgeme işlemlerindeki hizmet hatalarıdır.
Geçerli UpgradeStateRollingBackCompleted olduğundan, özgün yükseltme hata durumunda yükseltmeyi otomatik olarak geri alan bir geri alma FailureAction ile gerçekleştirilmelidir. Özgün yükseltme el ile FailureAction ile gerçekleştirildiyse, uygulamanın canlı hata ayıklamasına izin vermek için yükseltme askıya alınmış durumda olur.
Ender durumlarda, sistem geçerli yükseltme etki alanı için tüm çalışmaları tamamlarken genel yükseltme zaman aşımına uğrıyorsa UpgradeDomainProgressAtFailure alanı boş olabilir. Böyle bir durumda UpgradeTimeout ve UpgradeDomainTimeout yükseltme parametre değerlerini artırmayı deneyin ve yükseltmeyi yeniden deneyin.
Sistem durumu denetimi hatalarını araştırma
Sistem durumu denetimi hataları, bir yükseltme etki alanındaki tüm düğümlerin yükseltmeyi tamamlayıp tüm güvenlik denetimlerini geçirmesini tamamladıktan sonra meydana gelebilecek çeşitli sorunlar tarafından tetiklenebilir. Bu paragrafın ardından gelen çıkış, başarısız sistem durumu denetimlerinden kaynaklanan bir yükseltme hatasının tipik bir örneğidir. UnhealthyEvaluations alanı, belirtilen sistem durumu ilkesine göre yükseltme sırasında başarısız olan sistem durumu denetimlerinin anlık görüntüsünü yakalar.
Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName : fabric:/DemoApp
ApplicationTypeName : DemoAppType
TargetApplicationTypeVersion : v4
ApplicationParameters : {}
StartTimestampUtc : 4/24/2015 2:42:31 AM
UpgradeState : RollingForwardPending
UpgradeDuration : 00:00:27
CurrentUpgradeDomainDuration : 00:00:27
NextUpgradeDomain : MYUD2
UpgradeDomainsStatus : { "MYUD1" = "Completed";
"MYUD2" = "Pending";
"MYUD3" = "Pending" }
UnhealthyEvaluations :
Unhealthy services: 50% (2/4), ServiceType='PersistedServiceType', MaxPercentUnhealthyServices=0%.
Unhealthy service: ServiceName='fabric:/DemoApp/Svc3', AggregatedHealthState='Error'.
Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
Unhealthy partition: PartitionId='3a9911f6-a2e5-452d-89a8-09271e7e49a8', AggregatedHealthState='Error'.
Error event: SourceId='Replica', Property='InjectedFault'.
Unhealthy service: ServiceName='fabric:/DemoApp/Svc2', AggregatedHealthState='Error'.
Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
Unhealthy partition: PartitionId='744c8d9f-1d26-417e-a60e-cd48f5c098f0', AggregatedHealthState='Error'.
Error event: SourceId='Replica', Property='InjectedFault'.
UpgradeKind : Rolling
RollingUpgradeMode : Monitored
FailureAction : Manual
ForceRestart : False
UpgradeReplicaSetCheckTimeout : 49710.06:28:15
HealthCheckWaitDuration : 00:00:00
HealthCheckStableDuration : 00:00:10
HealthCheckRetryTimeout : 00:00:10
UpgradeDomainTimeout : 10675199.02:48:05.4775807
UpgradeTimeout : 10675199.02:48:05.4775807
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
Sistem durumu denetimi hatalarını araştırmak için öncelikle Service Fabric sistem durumu modelinin anlaşılması gerekir. Ancak bu kadar kapsamlı bir anlayış olmadan bile iki hizmetin iyi durumda olmadığını görebiliriz: fabric:/DemoApp/Svc3 and fabric:/DemoApp/Svc2, hata durumu raporlarıyla birlikte ("Bu örnekte InjectedFault"). Bu örnekte, dört hizmetten ikisi iyi durumda değildir ve bu da varsayılan %0 iyi durumda olmayan (MaxPercentUnhealthyServices) hedefinin altındadır.
Yükseltme başlatılırken el ile bir FailureAction belirtilerek başarısız olduğunda yükseltme askıya alındı. Bu mod, başka bir işlem yapmadan önce canlı sistemi başarısız durumda araştırmamıza olanak tanır.
Askıya alınmış yükseltmeden kurtarma
Geri alma HatasıAction ile, yükseltme başarısız olduğunda otomatik olarak geri alındığından kurtarma gerekmez. El ile failureaction ile çeşitli kurtarma seçenekleri vardır:
- geri alma tetikleme
- Yükseltmenin geri kalanında el ile devam edin
- İzlenen yükseltmeyi sürdürme
Start-ServiceFabricApplicationRollback komutu, uygulamayı geri almaya başlamak için istediğiniz zaman kullanılabilir. Komut başarıyla döndürdüğünde geri alma isteği sisteme kaydedilir ve kısa süre sonra başlar.
Resume-ServiceFabricApplicationUpgrade komutu, yükseltmenin geri kalanında el ile, tek seferde bir yükseltme etki alanıyla devam etmek için kullanılabilir. Bu modda, sistem tarafından yalnızca güvenlik denetimleri gerçekleştirilir. Başka sistem durumu denetimi yapılmaz. Bu komut yalnızca UpgradeStateRollingForwardPending'i gösterdiğinde kullanılabilir; bu, geçerli yükseltme etki alanının yükseltmeyi tamamladığı ancak bir sonrakinin başlatılmadığı (beklemede) olduğu anlamına gelir.
Update-ServiceFabricApplicationUpgrade komutu, hem güvenlik hem de sistem durumu denetimleri gerçekleştirilerek izlenen yükseltmeyi sürdürmek için kullanılabilir.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
Yükseltme, en son askıya alındığı yükseltme etki alanından devam eder ve öncekiyle aynı yükseltme parametrelerini ve sistem durumu ilkelerini kullanır. Gerekirse, önceki çıktıda gösterilen yükseltme parametreleri ve sistem durumu ilkelerinden herhangi biri, yükseltme devam ettiğinde aynı komutta değiştirilebilir. Bu örnekte, parametreler ve sistem durumu ilkeleri değişmeden yükseltme İzlenen modda sürdürüldü.
Daha fazla sorun giderme
Service Fabric belirtilen sistem durumu ilkelerini izlemez
Olası Neden 1:
Service Fabric, sistem durumu değerlendirmesi için tüm yüzdeleri gerçek varlık sayısına (örneğin, çoğaltmalar, bölümler ve hizmetler) çevirir ve her zaman varlıkların tamamına yuvarlar. Örneğin MaxPercentUnhealthyReplicasPerPartition üst sınırı %21 ise ve beş çoğaltma varsa, Service Fabric en fazla iki iyi durumda olmayan çoğaltmaya (yani)Math.Ceiling (5*0.21) izin verir. Bu nedenle sağlık ilkeleri buna göre ayarlanmalıdır.
Olası Neden 2:
Sistem durumu ilkeleri, belirli hizmet örneklerine değil toplam hizmetlerin yüzdesine göre belirtilir. Örneğin, bir uygulamanın A, B, C ve D olmak üzere dört hizmet örneği varsa yükseltmeden önce D hizmetinin iyi durumda olmadığı ancak uygulamayı çok az etkilediği bir durumdur. Yükseltme sırasında bilinen iyi durumda olmayan D hizmetini yoksaymak ve yalnızca A, B ve C'nin iyi durumda olması gerektiği varsayılarak MaxPercentUnhealthyServices parametresini %25 olarak ayarlamak istiyoruz.
Ancak yükseltme sırasında, C iyi durumda değilken D iyi duruma gelebilir. Hizmetlerin yalnızca %25'i iyi durumda olmadığından yükseltme yine başarılı olabilir. Ancak, C'nin D yerine beklenmedik şekilde iyi durumda olmaması nedeniyle beklenmeyen hatalara neden olabilir. Bu durumda D, A, B ve C'den farklı bir hizmet türü olarak modellenmelidir. Sistem durumu ilkeleri hizmet türüne göre belirtildiğinden, farklı hizmetlere farklı iyi durumda olmayan yüzde eşikleri uygulanabilir.
Uygulama yükseltmesi için bir sistem durumu ilkesi belirtmedim, ancak yükseltme hala hiç belirtmediğim bazı zaman aşımları için başarısız oluyor
Sistem durumu ilkeleri yükseltme isteğine sağlanmazsa, geçerli uygulama sürümünün ApplicationManifest.xml alınır. Örneğin, Application X'i sürüm 1.0'dan sürüm 2.0'a yükseltiyorsanız, için sürüm 1.0'da belirtilen uygulama durumu ilkeleri kullanılır. Yükseltme için farklı bir sistem durumu ilkesi kullanılması gerekiyorsa, ilkenin uygulama yükseltme API çağrısının bir parçası olarak belirtilmesi gerekir. API çağrısının parçası olarak belirtilen ilkeler yalnızca yükseltme sırasında geçerlidir. Yükseltme tamamlandıktan sonra ,ApplicationManifest.xml belirtilen ilkeler kullanılır.
Yanlış zaman aşımları belirtildi
Zaman aşımları tutarsız olarak ayarlandığında ne olacağını merak ediyor olabilirsiniz. Örneğin, UpgradeDomainTimeout değerinden küçük bir UpgradeTimeout'nuz olabilir. Yanıt, bir hata döndürülür. UpgradeDomainTimeoutHealthCheckWaitDuration ve HealthCheckRetryTimeout toplamından küçükse veya UpgradeDomainTimeoutHealthCheckWaitDuration ve HealthCheckStableDuration toplamından küçükse hatalar döndürülür.
Yükseltmelerim çok uzun sürüyor
Yükseltmenin tamamlanma süresi, belirtilen sistem durumu denetimlerine ve zaman aşımlarına bağlıdır. Sistem durumu denetimleri ve zaman aşımları, uygulamanın kopyalanması, dağıtılması ve dengelenmesinin ne kadar sürdüğüne bağlıdır. Zaman aşımlarında çok agresif olmak daha fazla başarısız yükseltme anlamına gelebilir, bu nedenle daha uzun zaman aşımlarıyla muhafazakar bir şekilde başlamanızı öneririz.
Zaman aşımlarının yükseltme süreleriyle nasıl etkileşime geçtiğini gösteren hızlı bir yenileme aşağıda verilmiştir:
Yükseltme etki alanı yükseltmeleri HealthCheckWaitDurationHealthCheckStableDuration + değerinden daha hızlı tamamlanamaz.
Yükseltme hatası HealthCheckWaitDuration + HealthCheckRetryTimeout değerinden daha hızlı gerçekleşemez.
Yükseltme etki alanının yükseltme süresi UpgradeDomainTimeout ile sınırlıdır. HealthCheckRetryTimeout ve HealthCheckStableDuration değerlerinin her ikisi de sıfır değilse ve uygulamanın sistem durumu ileri geri geçişe devam ederse YükseltmeDomainTimeout'ta yükseltme zaman aşımına ugrar. Geçerli yükseltme etki alanı yükseltmesi başladıktan sonra UpgradeDomainTimeout geri saymaya başlar.
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.
Gelişmiş Konular'a başvurarak uygulamanızı yükseltirken gelişmiş işlevleri kullanmayı öğrenin.