Memecahkan masalah peningkatan aplikasi
Artikel ini membahas beberapa masalah umum seputar meningkatkan aplikasi Azure Service Fabric dan cara mengatasinya.
Memecahkan masalah peningkatan aplikasi yang gagal
Saat pemutakhiran gagal, output dari perintah Get-ServiceFabricApplicationUpgrade berisi informasi tambahan untuk men-debug kegagalan. Daftar berikut menentukan bagaimana informasi tambahan dapat digunakan:
- Mengidentifikasi jenis kegagalan.
- Mengidentifikasi alasan kegagalan.
- Pisahkan satu atau lebih komponen yang gagal untuk penyelidikan lebih lanjut.
Informasi ini tersedia saat Service Fabric mendeteksi kegagalan terlepas dari apakah FailureAction akan membatalkan atau menangguhkan peningkatan.
Mengidentifikasi jenis kegagalan
Di output Get-ServiceFabricApplicationUpgrade, FailureTimestampUtc mengidentifikasi stempel waktu (dalam UTC) tempat kegagalan peningkatan terdeteksi oleh Service Fabric dan FailureAction dipicu. FailureReason mengidentifikasi salah satu dari tiga potensi penyebab tingkat tinggi dari kegagalan:
- UpgradeDomainTimeout - Menunjukkan bahwa upgrade domain tertentu membutuhkan waktu terlalu lama untuk diselesaikan dan UpgradeDomainTimeout kedaluwarsa.
- OverallUpgradeTimeout - Menunjukkan bahwa peningkatan keseluruhan memakan waktu terlalu lama untuk diselesaikan dan UpgradeTimeout kedaluwarsa.
- HealthCheck - Menunjukkan bahwa setelah meningkatkan domain pembaruan, aplikasi tetap tidak sehat sesuai dengan kebijakan kesehatan yang ditentukan dan HealthCheckRetryTimeout kedaluwarsa.
Entri ini hanya muncul di output saat peningkatan gagal dan mulai bergulir kembali. Informasi lebih lanjut ditampilkan tergantung pada jenis kegagalannya.
Menyelidiki waktu habis peningkatan
Kegagalan waktu habis peningkatan paling sering disebabkan oleh masalah ketersediaan layanan. Output yang mengikuti paragraf ini adalah tipikal dari upgrade tempat replika layanan atau instans gagal dimulai dalam versi kode baru. Bidang UpgradeDomainProgressAtFailure menangkap cuplikan dari setiap pekerjaan peningkatan yang tertunda pada saat kegagalan.
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
Dalam contoh ini, peningkatan gagal pada peningkatan domain MYUD1 dan dua partisi (744c8d9f-1d26-417e-a60e-cd48f5c098f0 dan 4b43f4d8-b26b-424e-9307-7a7a62e79750) macet. Partisi berhenti karena waktu proses tidak dapat menempatkan replika utama (WaitForPrimaryPlacement) pada node target Node1 dan Node4.
Perintah Get-ServiceFabricNode dapat digunakan untuk memverifikasi bahwa kedua node ini berada dalam domain peningkatan versi MYUD1. UpgradePhase menampilkan PostUpgradeSafetyCheck, yang berarti bahwa pemeriksaan keamanan ini dilakukan setelah semua node dalam domain peningkatan versi selesai meningkatkan. Semua informasi ini menunjukkan potensi masalah dengan versi baru kode aplikasi. Masalah yang paling umum adalah kesalahan layanan di buka atau promosi ke jalur kode utama.
UpgradePhase dari PreUpgradeSafetyCheck menunjukkan ada masalah dalam mempersiapkan peningkatan domain sebelum dilakukan. Masalah paling umum dalam kasus ini adalah kesalahan layanan di penutupan atau penurunan pangkat dari jalur kode utama.
UpgradeState saat ini adalah RollingBackCompleted, jadi peningkatan asli harus dilakukan dengan FailureAction rollback, yang secara otomatis mengembalikan peningkatan setelah gagal. Jika peningkatan asli dilakukan dengan FailureAction manual, peningkatan akan berstatus ditangguhkan untuk memungkinkan proses debug langsung aplikasi.
Dalam kasus yang jarang terjadi, bidang UpgradeDomainProgressAtFailure mungkin kosong jika waktu peningkatan secara keseluruhan habis tepat saat sistem menyelesaikan semua pekerjaan untuk domain peningkatan saat ini. Jika ini terjadi, coba tingkatkan nilai parameter peningkatan UpgradeTimeout dan UpgradeDomainTimeout, lalu coba tingkatkan lagi.
Menyelidiki kegagalan pemeriksaan kesehatan
Kegagalan pemeriksaan kesehatan dapat dipicu oleh berbagai masalah yang dapat terjadi setelah semua node dalam peningkatan domain menyelesaikan peningkatan versi dan lolos semua pemeriksaan keamanan. Output setelah paragraf ini adalah tipikal dari kegagalan peningkatan karena pemeriksaan kesehatan yang gagal. Bidang UnhealthyEvaluations menangkap cuplikan pemeriksaan kesehatan yang gagal pada saat peningkatan versi sesuai dengan kebijakan kesehatan yang ditentukan.
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 :
Menyelidiki kegagalan pemeriksaan kesehatan terlebih dahulu membutuhkan pemahaman tentang model kesehatan Service Fabric. Tetapi bahkan tanpa pemahaman yang mendalam, kita dapat melihat bahwa dua layanan tidak sehat: fabric:/DemoApp/Svc3 dan fabric:/DemoApp/Svc2, bersama dengan kesalahan laporan kesehatan ("InjectedFault" dalam kasus ini). Dalam contoh ini, dua dari empat layanan tidak sehat, yang berada di bawah target default 0% tidak sehat (MaxPercentUnhealthyServices).
Peningkatan versi ditangguhkan setelah gagal dengan menentukan manual FailureAction saat memulai peningkatan. Mode ini memungkinkan kami untuk menyelidiki sistem langsung dalam keadaan gagal sebelum mengambil tindakan lebih lanjut.
Memulihkan dari peningkatan yang ditangguhkan
Dengan rollback FailureAction, pemulihan tidak diperlukan karena peningkatan otomatis dibatalkan setelah gagal. Dengan FailureAction manual, ada beberapa opsi pemulihan:
- memicu rollback
- Melanjutkan melalui sisa peningkatan secara manual
- Melanjutkan peningkatan yang dipantau
Perintah Start-ServiceFabricApplicationRollback dapat digunakan kapan saja untuk mulai mengembalikan aplikasi. Setelah perintah berhasil dikembalikan, permintaan rollback telah terdaftar di sistem dan segera dimulai setelahnya.
Perintah Resume-ServiceFabricApplicationUpgrade dapat digunakan untuk melanjutkan melalui sisa peningkatan secara manual, satu peningkatan domain dalam satu waktu. Dalam mode ini, hanya pemeriksaan keamanan yang dilakukan oleh sistem. Tidak ada lagi pemeriksaan kesehatan yang dilakukan. Perintah ini hanya dapat digunakan ketika UpgradeState menampilkan RollingForwardPending, yang berarti bahwa domain peningkatan saat ini telah menyelesaikan peningkatan tetapi yang berikutnya belum dimulai (menunggu keputusan).
Perintah Update-ServiceFabricApplicationUpgrade dapat digunakan untuk melanjutkan peningkatan yang dipantau dengan dilakukan pemeriksaan keamanan dan kesehatan.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
Peningkatan berlanjut dari domain peningkatan yang terakhir kali ditangguhkan dan menggunakan parameter peningkatan dan kebijakan kesehatan yang sama seperti sebelumnya. Jika perlu, salah satu parameter peningkatan dan kebijakan kesehatan yang ditampilkan di output sebelumnya dapat diubah dalam perintah yang sama saat peningkatan dilanjutkan. Dalam contoh ini, peningkatan dilanjutkan dalam mode dipantau, dengan parameter dan kebijakan kesehatan tidak berubah.
Pemecahan masalah lanjutan
Service Fabric tidak mengikuti kebijakan kesehatan yang ditentukan
Kemungkinan Penyebab 1:
Service Fabric menerjemahkan semua persentase menjadi jumlah entitas yang sebenarnya (misalnya, replika, partisi, dan layanan) untuk evaluasi kesehatan dan selalu dibulatkan ke seluruh entitas. Misalnya, jika maksimum MaxPercentUnhealthyReplicasPerPartition adalah 21% dan ada lima replika, maka Service Fabric mengizinkan hingga dua replika tidak sehat (yaitu, Math.Ceiling (5*0.21)). Oleh karena itu, kebijakan kesehatan harus ditetapkan dengan tepat.
Kemungkinan Penyebab 2:
Kebijakan kesehatan ditentukan dalam persentase total layanan dan bukan contoh layanan spesifik. Misalnya, sebelum peningkatan, jika aplikasi memiliki empat contoh layanan A, B, C, dan D, di mana layanan D tidak sehat tetapi dengan sedikit dampak pada aplikasi. Kita ingin mengabaikan layanan tidak sehat D yang diketahui selama peningkatan dan menyetel parameter MaxPercentUnhealthyServices menjadi 25%, dengan asumsi hanya A, B, dan C yang harus sehat.
Namun, selama peningkatan, D mungkin menjadi sehat sementara C menjadi tidak sehat. Peningkatan akan tetap berhasil karena hanya 25% layanan yang tidak sehat. Namun, ini mungkin mengakibatkan kesalahan tak terduga karena C tiba-tiba tidak sehat, bukan D. Dalam situasi ini, D harus dimodelkan sebagai jenis layanan yang berbeda dari A, B, dan C. Karena kebijakan kesehatan ditentukan per jenis layanan, ambang persentase tidak sehat yang berbeda dapat diterapkan ke berbagai layanan.
Saya tidak menentukan kebijakan kesehatan untuk peningkatan aplikasi, namun peningkatan masih gagal untuk beberapa waktu habis yang tidak pernah saya tentukan
Jika kebijakan kesehatan tidak disediakan untuk permintaan peningkatan, kebijakan kesehatan itu diambil dari ApplicationManifest.xml versi aplikasi saat ini. Misalnya, jika Anda meningkatkan Aplikasi X dari versi 1.0 ke versi 2.0, kebijakan kesehatan aplikasi yang ditentukan untuk versi 1.0 akan digunakan. Jika kebijakan kesehatan yang berbeda harus digunakan untuk peningkatan, maka kebijakan tersebut perlu ditetapkan sebagai bagian dari panggilan API peningkatan aplikasi. Kebijakan yang ditentukan sebagai bagian dari panggilan API hanya berlaku selama peningkatan. Setelah peningkatan selesai, kebijakan yang ditentukan di ApplicationManifest.xml digunakan.
Waktu habis yang salah ditentukan
Anda mungkin penasaran tentang apa yang terjadi jika waktu habis ditetapkan secara tidak konsisten. Misalnya, Anda mungkin memiliki UpgradeTimeout yang kurang dari UpgradeDomainTimeout. Jawabannya adalah bahwa kesalahan dikembalikan. Kesalahan dikembalikan jika UpgradeDomainTimeout kurang dari jumlah HealthCheckWaitDuration dan HealthCheckRetryTimeout, atau jika UpgradeDomainTimeout kurang dari jumlah HealthCheckWaitDuration dan HealthCheckStableDuration.
Peningkatan saya memakan waktu terlalu lama
Waktu penyelesaian upgrade tergantung pada pemeriksaan kesehatan dan waktu habis yang ditentukan. Pemeriksaan kesehatan dan waktu habis bergantung pada berapa lama waktu yang diperlukan untuk menyalin, menerapkan, dan menstabilkan aplikasi. Menjadi terlalu agresif dengan waktu habis mungkin berarti lebih banyak peningkatan yang gagal, jadi kami merekomendasikan untuk memulai secara konservatif dengan waktu habis yang lebih lama.
Berikut adalah penyegar singkat tentang bagaimana waktu habis berinteraksi dengan waktu peningkatan:
Peningkatan untuk domain peningkatan tidak dapat diselesaikan lebih cepat dari HealthCheckWaitDuration + HealthCheckStableDuration.
Kegagalan peningkatan tidak dapat terjadi lebih cepat dari HealthCheckWaitDuration + HealthCheckRetryTimeout.
Waktu peningkatan untuk domain peningkatan dibatasi oleh UpgradeDomainTimeout. Jika HealthCheckRetryTimeout dan HealthCheckStableDuration keduanya bukan nol dan kesehatan aplikasi terus berpindah-pindah, maka peningkatan pada akhirnya akan kehabisan waktu pada UpgradeDomainTimeout. UpgradeDomainTimeout mulai menghitung mundur setelah peningkatan versi domain saat ini dimulai.
Langkah berikutnya
Meningkatkan Aplikasi Anda Menggunakan Visual Studio memandu Anda melalui peningkatan aplikasi menggunakan Visual Studio.
Meningkatkan Aplikasi Anda Menggunakan PowerShell memandu Anda melalui peningkatan aplikasi menggunakan PowerShell.
Kontrol cara aplikasi ditingkatkan dengan menggunakan Parameter Peningkatan.
Buat peningkatan aplikasi kompatibel dengan mempelajari cara menggunakan Serialisasi Data.
Pelajari cara menggunakan fungsionalitas lanjutan saat meningkatkan aplikasi dengan merujuk ke Topik Lanjutan.