Uygulama yükseltme ile ilgili sorunları giderme
Bu makale, Azure Service Fabric uygulamasını yükseltme ve bunların nasıl çözüleceğini gösteren bazı yaygın sorunları kapsar.
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ü belirleyin.
- 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, Service Fabric FailureAction'ın yükseltmeyi geri alıp almamasına veya askıya almasına bakılmaksızın hatayı algıladığında kullanılabilir.
Hata türünü tanımlama
Get-ServiceFabricApplicationUpgrade çıkışında FailureTimestampUtc, Service Fabric tarafından bir yükseltme hatasının algılandığı ve FailureAction'ın tetiklendiği zaman damgasını (UTC'de) 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 - 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 çıktıda 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ı en yaygın olarak hizmet kullanılabilirliği sorunlarından kaynaklanıyor. 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üyle ilgili olası bir soruna işaret etti. En yaygın sorunlar, açma veya birincil kod yollarına yükseltmedeki hizmet hatalarıdır.
UpgradePhase of PreUpgradeSafetyCheck, yükseltme etki alanını gerçekleştirilmeden önce hazırlarken sorunlar olduğu anlamına gelir. Bu durumda en yaygın sorunlar, birincil kod yollarındaki kapatma veya indirgeme işlemlerindeki hizmet hatalarıdır.
Geçerli UpgradeState RollingBackCompleted olduğundan, özgün yükseltme başarısız olduğunda yükseltmeyi otomatik olarak geri alan 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ı, yükseltme etki alanındaki tüm düğümler yükseltmeyi bitirdikten ve tüm güvenlik denetimlerini geçirdikten sonra meydana gelebilecek çeşitli sorunlar tarafından tetiklenebilir. Bu paragrafı izleyen çıkış, sistem durumu denetimlerinin başarısız olması nedeniyle tipik bir yükseltme hatasıdır. 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 ayrıntılı bir anlayış olmadan bile iki hizmetin iyi durumda olmadığını görebiliriz: fabric:/DemoApp/Svc3 ve fabric:/DemoApp/Svc2, hata durumu raporlarıyla birlikte ("InjectedFault"). Bu örnekte, dört hizmetten ikisi iyi durumda değil ve bu, 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ınan yükseltmeden kurtarma
Geri alma HatasıAction ile, yükseltme başarısız olduğunda otomatik olarak geri döndüğünden kurtarma gerekmez. El ile FailureAction ile çeşitli kurtarma seçenekleri vardır:
- geri alma tetikleme
- Yükseltmenin geri kalanında el ile ilerleyin
- İzlenen yükseltmeyi sürdürme
Start-ServiceFabricApplicationRollback komutu, uygulamayı geri döndürmeye başlamak için istediğiniz zaman kullanılabilir. Komut başarıyla döndürüldüğünde geri alma isteği sisteme kaydedilir ve kısa süre sonra başlatılır.
Resume-ServiceFabricApplicationUpgrade komutu, yükseltmenin geri kalanında el ile, bir kerede bir yükseltme etki alanı ile 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 UpgradeState RollingForwardPending'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 parametrelerinden 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 ilkelerine uymaz
Olası Neden 1:
Service Fabric, sistem durumu değerlendirmesi için tüm yüzdeleri gerçek varlık sayısına (çoğaltmalar, bölümler ve hizmetler gibi) çevirir ve her zaman tüm varlıklara 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 (yaniMath.Ceiling (5*0.21)) izin verir. Bu nedenle, sistem durumu 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, yükseltmeden önce, bir uygulamanın dört hizmet örneği A, B, C ve D varsa, burada hizmet D iyi durumda değildir ancak uygulamayı çok az etkiler. Yükseltme sırasında bilinen iyi durumda olmayan D hizmetini yoksaymak ve maxPercentUnhealthyServices parametresini %25 olarak ayarlamak istiyoruz. Bunun için yalnızca A, B ve C'nin iyi durumda olması gerektiği varsayılır.
Ancak yükseltme sırasında D iyi durumdayken C iyi durumda olmayabilir. 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ğlanmamışsa, 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'sinin ç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 bir şekilde ayarlandığında ne olacağını merak ediyor olabilirsiniz. Örneğin, UpgradeDomainTimeout değerinden küçük bir UpgradeTimeout'nuz olabilir. Bunun yanıtı bir hata döndürülür. UpgradeDomainTimeout, HealthCheckWaitDuration ve HealthCheckRetryTimeout toplamından küçükse veya UpgradeDomainTimeout, HealthCheckWaitDuration 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ği hakkında hızlı bir yenileme aşağıda verilmiştir:
Bir yükseltme etki alanı için yükseltmeler HealthCheckWaitDuration HealthCheckStableDuration + 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 hem sıfırdan farklıysa hem de uygulamanın sistem durumu ileri geri geçişe devam ederse yükseltme, UpgradeDomainTimeout'ta zaman aşımına ugrar. UpgradeDomainTimeout , geçerli yükseltme etki alanı için yükseltme başladıktan sonra 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.