Peningkatan aplikasi Service Fabric: Topik lanjutan

Artikel
08/25/2024

Menambahkan atau menghapus jenis layanan selama peningkatan aplikasi

Jika jenis layanan baru ditambahkan ke aplikasi yang diterbitkan sebagai bagian dari peningkatan, jenis layanan baru ditambahkan ke aplikasi yang disebarkan. Peningkatan tersebut tidak memengaruhi salah satu instans layanan yang sudah menjadi bagian dari aplikasi, tetapi instans jenis layanan yang ditambahkan harus dibuat agar jenis layanan baru aktif (lihat New-ServiceFabricService).

Demikian pula, jenis layanan dapat dihapus dari aplikasi sebagai bagian dari peningkatan. Namun, semua contoh layanan dari jenis layanan yang akan dihapus harus dihapus sebelum melanjutkan peningkatan (lihat Remove-ServiceFabricService).

Hindari penghapusan koneksi selama downtime yang direncanakan layanan stateless

Untuk downtime instans stateless yang direncanakan seperti peningkatan aplikasi/kluster atau penonaktifan node, koneksi dapat dihilangkan saat titik akhir yang diekspos dihapus setelah instans turun, dan ini menghasilkan penutupan koneksi yang kuat.

Untuk menghindari hal ini, konfigurasi fitur RequestDrain dengan menambahkan durasi penundaan penutupan instans dalam konfigurasi layanan guna memungkinkan permintaan yang ada dari dalam kluster untuk mengosongkan titik akhir yang terekspos. Hal ini dicapai saat titik akhir yang diiklankan oleh instans stateless dihapus sebelum penundaan dimulai sebelum menutup instans. Penundaan ini memungkinkan permintaan yang ada untuk mengosongkan dengan lancar sebelum instans benar-benar turun. Klien menerima pemberitahuan tentang perubahan titik akhir oleh fungsi panggilan balik pada saat penundaan dimulai sehingga mereka dapat menyelesaikan kembali titik akhir dan menghindari pengiriman permintaan baru ke instans yang akan turun. Permintaan ini dapat berasal dari klien yang menggunakan Reverse Proxy atau menggunakan api resolusi titik akhir layanan dengan model pemberitahuan (ServiceNotificationFilterDescription)untuk memperbarui titik akhir.

Konfigurasi layanan

Ada beberapa cara untuk mengonfigurasi penundaan di sisi layanan.

Saat membuat layanan baru, tentukan -InstanceCloseDelayDuration:

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

Saat mendefinisikan layanan di bagian default dalam manifes aplikasi, tetapkan properti InstanceCloseDelayDurationSeconds:

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

Saat memperbarui layanan yang ada, tentukan -InstanceCloseDelayDuration:

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

Saat membuat atau memperbarui layanan yang ada melalui templat ARM, tentukan nilai InstanceCloseDelayDuration (versi API minimum yang didukung: 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"
  }
}

Konfigurasi klien

Untuk menerima pemberitahuan bila titik akhir telah berubah, klien harus mendaftarkan panggilan balik, lihat Contoh ServiceNotificationFilterDescription. Pemberitahuan perubahan adalah indikasi bahwa titik akhir telah berubah, klien harus menyelesaikan kembali titik akhir, dan tidak menggunakan titik akhir yang tidak diiklankan lagi, karena titik akhir akan segera turun.

Penimpaan peningkatan opsional

Selain mengatur durasi penundaan default per layanan, Anda juga dapat menimpa penundaan selama peningkatan aplikasi/kluster menggunakan opsi yang sama (InstanceCloseDelayDurationSec) :

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

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

Durasi penundaan yang ditimpa hanya berlaku untuk instans peningkatan yang dipanggil dan tidak mengubah konfigurasi penundaan layanan individual. Misalnya, Anda dapat menggunakan ini guna menentukan penundaan 0 untuk melewati penundaan peningkatan yang telah dikonfigurasi sebelumnya.

Catatan

Pengaturan untuk mengosongkan permintaan tidak akan dapat mencegah Azure Load balancer dari mengirim permintaan baru ke titik akhir yang sedang mengalami pengosongan.
Mekanisme resolusi berbasis keluhan tidak akan mengakibatkan pengosongan permintaan secara lancar karena memicu resolusi layanan setelah kegagalan. Seperti yang dijelaskan sebelumnya, ini seharusnya ditingkatkan untuk membuat langganan pemberitahuan perubahan titik akhir menggunakan ServiceNotificationFilterDescription.
Pengaturan tidak ditingkatkan ketika pemutakhiran adalah replika yang tidak berdampak, yaitu ketika replika tidak akan diturunkan selama pemutakhiran.
Nilai maksimum InstanceCloseDelayDuration yang dapat dikonfigurasi dalam deskripsi layanan atau InstanceCloseDelayDurationSec dalam deskripsi peningkatan tidak boleh lebih besar dari konfigurasi kluster FailoverManager.MaxInstanceCloseDelayDurationInSeconds, yang defaultnya adalah 1800 detik. Untuk memperbarui nilai maksimal, konfigurasi tingkat kluster harus diperbarui. Konfigurasi ini hanya tersedia di runtime versi 9.0 atau versi lebih baru.

Catatan

Fitur ini dapat dikonfigurasi di layanan yang ada menggunakan cmdlet Update-ServiceFabricService atau templat ARM seperti disebutkan di atas ketika versi kode kluster adalah 7.1.XXX atau di atasnya.

Mode peningkatan manual

Catatan

Mode peningkatan Monitored disarankan untuk semua peningkatan Service Fabric. Mode peningkatan UnmonitoredManual hanya boleh dipertimbangkan untuk peningkatan yang gagal atau ditangguhkan.

Dalam mode Monitored, Service Fabric menerapkan kebijakan kesehatan untuk memastikan bahwa aplikasi sehat seiring perkembangan peningkatan. Jika kebijakan kesehatan dilanggar, peningkatan ditangguhkan atau digulirkan kembali secara otomatis, bergantung pada FailureAction yang ditentukan.

Dalam mode UnmonitoredManual, administrator aplikasi memiliki kontrol penuh atas perkembangan peningkatan. Mode ini berguna saat menerapkan kebijakan evaluasi kesehatan kustom atau melakukan peningkatan nonkonvensional untuk melewati pemantauan kesehatan sepenuhnya (misalnya, aplikasi sudah dalam keadaan kehilangan data). Peningkatan yang berjalan dalam mode ini akan menangguhkan dirinya sendiri setelah menyelesaikan setiap UD dan harus secara eksplisit dilanjutkan menggunakan Resume-ServiceFabricApplicationUpgrade. Ketika peningkatan ditangguhkan dan siap untuk dilanjutkan oleh pengguna, status peningkatannya akan menampilkan RollforwardPending (lihat UpgradeState).

Terakhir, mode UnmonitoredAuto berguna untuk melakukan iterasi peningkatan cepat selama pengembangan atau pengujian layanan karena tidak ada input pengguna yang diperlukan dan tidak ada kebijakan kesehatan aplikasi yang dievaluasi.

Peningkatan dengan paket diff

Alih-alih menyediakan paket aplikasi lengkap, peningkatan juga dapat dilakukan dengan menyediakan paket diff yang hanya berisi paket kode/konfigurasi/data yang diperbarui bersama manifes aplikasi lengkap dan manifes layanan lengkap. Paket aplikasi lengkap hanya diperlukan untuk instalasi awal aplikasi ke kluster. Peningkatan berikutnya dapat berasal dari paket aplikasi lengkap atau paket diff.

Setiap referensi dalam manifes aplikasi atau manifes layanan dari paket diff yang tidak dapat ditemukan dalam paket aplikasi secara otomatis diganti dengan versi yang saat ini disediakan.

Skenario untuk menggunakan paket diff adalah:

Ketika Anda memiliki paket aplikasi besar yang mereferensikan beberapa file manifes layanan dan/atau beberapa paket kode, paket konfigurasi, atau paket data.
Saat Anda memiliki sistem penyebaran yang menghasilkan tata letak kompilasi langsung dari proses kompilasi aplikasi Anda. Dalam hal ini, meskipun kode belum berubah, rangkaian yang baru dibangun mendapatkan checksum yang berbeda. Dengan menggunakan paket aplikasi lengkap, Anda harus memperbarui versi pada semua paket kode. Dengan menggunakan paket diff, Anda hanya menyediakan file yang berubah dan file manifes tempat versi berubah.

Saat aplikasi ditingkatkan menggunakan Visual Studio, paket diff akan dipublikasikan secara otomatis. Untuk membuat paket diff secara manual, manifes aplikasi dan manifes layanan harus diperbarui, tetapi hanya paket yang diubah yang harus dimasukkan dalam paket aplikasi akhir.

Misalnya, mari kita mulai dengan aplikasi berikut (nomor versi yang disediakan untuk kemudahan pemahaman):

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

Mari kita asumsikan Anda hanya ingin memperbarui paket kode service1 menggunakan paket diff. Aplikasi terbaru Andai memiliki perubahan versi berikut:

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

Dalam hal ini, Anda memperbarui manifes aplikasi ke 2.0.0 dan manifes layanan untuk service1 untuk mencerminkan pembaruan paket kode. Folder untuk paket aplikasi Anda akan memiliki struktur berikut:

app1/
  service1/
    code/

Dengan kata lain, buat paket aplikasi lengkap secara normal, lalu hapus folder kode/konfigurasi/paket data yang versinya belum berubah.

Meningkatkan parameter aplikasi secara terpisah dari versi

Terkadang, Anda ingin mengubah parameter aplikasi Service Fabric tanpa mengubah versi manifes. Ini dapat dilakukan dengan nyaman menggunakan flag -ApplicationParameter dengan cmdlet Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell. Asumsikan aplikasi Service Fabric dengan properti berikut:

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

Sekarang, tingkatkan aplikasi menggunakan cmdlet Start-ServiceFabricApplicationUpgrade. Contoh ini menunjukkan peningkatan yang dipantau, tetapi peningkatan yang tidak dipantau juga dapat digunakan. Untuk melihat deskripsi lengkap flag yang diterima oleh cmdlet ini, lihat referensi modul Azure Service Fabric PowerShell

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

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

Setelah peningkatan, konfirmasi bahwa aplikasi memiliki parameter terbaru dan versi yang sama:

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

Pengguliran kembali peningkatan aplikasi

Sekalipun dapat digulirkan ke depan dalam salah satu dari tiga mode (Monitored, UnmonitoredAuto, atau UnmonitoredManual), peningkatan hanya dapat digulirkan kembali dalam mode UnmonitoredAuto atau UnmonitoredManual. Pengguliran kembali dalam mode UnmonitoredAuto bekerja dengan cara yang sama seperti menggulir ke depan dengan pengecualian bahwa nilai default UpgradeReplicaSetCheckTimeout berbeda - lihat Parameter Peningkatan Aplikasi. Pengguliran kembali dalam mode UnmonitoredManual bekerja dengan cara yang sama seperti menggulir ke depan - pengguliran kembali akan menangguhkan dirinya sendiri setelah menyelesaikan setiap UD dan harus secara eksplisit dilanjutkan menggunakan Resume-ServiceFabricApplicationUpgrade untuk melanjutkan pengguliran kembali.

Pengguliran kembali dapat dipicu secara otomatis ketika kebijakan kesehatan peningkatan dalam mode Monitored dengan FailureAction dari Pengguliran Kembali dilanggar (lihat Parameter Peningkatan Aplikasi) atau secara eksplisit menggunakan Start-ServiceFabricApplicationRollback.

Selama pengguliran kembali, nilai UpgradeReplicaSetCheckTimeout dan mode masih dapat diubah kapan saja menggunakan Update-ServiceFabricApplicationUpgrade.

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 menggunakan Parameter Peningkatan.

Buat agar peningkatan aplikasi Anda kompatibel dengan mempelajari cara menggunakan Serialisasi Data.

Perbaiki masalah umum dalam peningkatan aplikasi dengan mengacu pada langkah-langkah dalam Pemecahan Masalah Peningkatan Aplikasi.

Bagikan melalui

Peningkatan aplikasi Service Fabric: Topik lanjutan

Menambahkan atau menghapus jenis layanan selama peningkatan aplikasi

Hindari penghapusan koneksi selama downtime yang direncanakan layanan stateless

Konfigurasi layanan

Konfigurasi klien

Penimpaan peningkatan opsional

Mode peningkatan manual

Peningkatan dengan paket diff

Meningkatkan parameter aplikasi secara terpisah dari versi

Pengguliran kembali peningkatan aplikasi

Langkah berikutnya

Saran dan Komentar

Sumber Daya Tambahan: