Bagikan melalui

Menggunakan Aplikasi Orkestrasi Patch

  • Artikel

Penting

Mulai 30 April 2019, Aplikasi Orkestrasi Patch versi 1.2.* tidak lagi didukung. Pastikan untuk meningkatkan ke versi terbaru.

Aplikasi Orkestrasi Patch (POA) adalah pembungkus di sekitar layanan Manajer Perbaikan Azure Service Fabric, yang memungkinkan penjadwalan patch OS berbasis konfigurasi untuk klaster yang dihosting non-Azure. POA tidak diperlukan untuk klaster yang dihosting non-Azure, tetapi penjadwalan penginstalan patch oleh domain pembaruan diperlukan untuk patch host klaster Service Fabric tanpa menimbulkan waktu henti.

POA adalah aplikasi Service Fabric yang mengotomatiskan patch sistem operasi pada klaster Service Fabric tanpa menimbulkan waktu henti.

POA menyediakan fitur berikut:

  • Penginstalan pembaruan sistem operasi otomatis. Pembaruan sistem operasi diunduh dan diinstal secara otomatis. Node klaster di-boot ulang sesuai keperluan tanpa menimbulkan waktu henti klaster.

  • Patch dan integrasi kesehatan yang sadar klaster. Saat POA menerapkan pembaruan, POA memantau kesehatan node klaster. Node klaster diperbarui satu node pada satu waktu atau satu domain pembaruan pada satu waktu. Jika kesehatan klaster menurun karena proses patch, patch dihentikan untuk mencegah memperburuk masalah.

Detail internal POA

POA terdiri dari subkomponen berikut:

  • Layanan Koordinator: Layanan stateful ini bertanggung jawab untuk:

    • Mengkoordinasikan pekerjaan Windows Update pada seluruh klaster.
    • Menyimpan hasil operasi Windows Update yang diselesaikan.

  • Layanan Agen Node: Layanan stateless ini berjalan pada semua node klaster Service Fabric. Layanan bertanggung jawab untuk:

    • Melakukan Bootstrap Agen Node NTService.
    • Memantau Agen Node NTService.

  • Agen Node NTService: Layanan NT Windows ini berjalan pada tingkat hak istimewa yang lebih tinggi (SISTEM). Sebaliknya, Layanan Agen Node dan Layanan Koordinator berjalan pada tingkat hak istimewa yang lebih rendah (LAYANAN JARINGAN). Layanan bertanggung jawab untuk melakukan pekerjaan Windows Update berikut pada semua node klaster:

    • Menonaktifkan pembaruan Windows otomatis pada node.
    • Mengunduh dan menginstal pembaruan Windows sesuai dengan kebijakan yang telah disediakan pengguna.
    • Merestart komputer setelah penginstalan pembaruan Windows.
    • Mengunggah hasil pembaruan Windows ke Layanan Koordinator.
    • Melaporkan laporan kesehatan jika operasi gagal setelah menghabiskan semua percobaan ulang.

Catatan

POA menggunakan layanan Service Fabric Repair Manager untuk menonaktifkan atau mengaktifkan node dan melakukan pemeriksaan kesehatan. Tugas perbaikan yang dibuat oleh POA melacak kemajuan Windows Update untuk setiap node.

Prasyarat

Catatan

Versi .NET Framework minimum yang diperlukan adalah 4.6.

Mengaktifkan layanan Repair Manager (jika belum berjalan)

POA memerlukan layanan Repair Manager untuk diaktifkan pada klaster.

Klaster Azure

Klaster Azure di tingkat durabilitas perak mengaktifkan layanan Repair Manager secara default. Klaster Azure di tingkat durabilitas emas mungkin atau mungkin tidak mengaktifkan layanan Repair Manager, tergantung pada kapan klaster tersebut dibuat. Klaster Azure di tingkat durabilitas perunggu, secara default, tidak mengaktifkan layanan Repair Manager. Jika layanan sudah diaktifkan, Anda dapat melihatnya berjalan di bagian layanan sistem di Penjelajah Service Fabric.

Portal Azure

Anda dapat mengaktifkan Repair Manager dari portal Azure ketika Anda menyiapkan klaster. Ketika Anda mengonfigurasi klaster, pilih opsi Sertakan Repair Manager di bawah Fitur add-on.

Gambar mengaktifkan Repair Manager dari portal Azure

Model penerapan Azure Resource Manager

Alternatifnya, Anda dapat menggunakan model penerapan Azure Resource Manager untuk mengaktifkan layanan Repair Manager pada klaster Service Fabric yang baru dan yang sudah ada. Dapatkan templat untuk klaster yang ingin Anda terapkan. Anda dapat menggunakan templat sampel atau membuat templat model penerapan Azure Resource Manager kustom.

Untuk mengaktifkan layanan Repair Manager dengan menggunakan templat model penerapan Azure Resource Manager, lakukan hal berikut:

  1. Periksa untuk memastikan bahwa apiVersion diatur ke 2017-07-01-preview untuk sumber daya Microsoft.ServiceFabric/clusters. Jika berbeda, Anda perlu memperbarui apiVersion ke 2017-07-01-preview atau yang lebih baru:

    {
    "apiVersion": "2017-07-01-preview",
    "type": "Microsoft.ServiceFabric/clusters",
    "name": "[parameters('clusterName')]",
    "location": "[parameters('clusterLocation')]",
    ...
}

  2. Aktifkan layanan Repair Manager dengan menambahkan bagian berikut addonFeatures setelah bagian fabricSettings:

    "fabricSettings": [
    ...      
],
"addonFeatures": [
    "RepairManager"
],

  3. Setelah Anda memperbarui templat klaster Anda dengan perubahan ini, terapkan dan biarkan pembaruan selesai. Anda sekarang dapat melihat layanan Repair Manager berjalan di klaster Anda. Ini disebut fabric:/System/RepairManagerService dalam bagian layanan sistem di Service Fabric Explorer.

Klaster lokal mandiri

Untuk mengaktifkan layanan Repair Manager pada klaster Service Fabric yang baru atau yang sudah ada, Anda dapat menggunakan Pengaturan konfigurasi untuk klaster Windows mandiri.

Untuk mengaktifkan layanan Manajer Perbaikan:

  1. Periksa untuk memastikan bahwa apiVersion di Konfigurasi klaster umum diatur ke 04-2017 atau yang lebih baru, seperti yang ditampilkan di sini:

    {
    "name": "SampleCluster",
    "clusterConfigurationVersion": "1.0.0",
    "apiVersion": "04-2017",
    ...
}

  2. Mengaktifkan layanan Repair Manager dengan menambahkan bagian addonFeatures berikut setelah bagian fabricSettings, seperti yang ditampilkan di sini:

    "fabricSettings": [
    ...      
],
"addonFeatures": [
    "RepairManager"
],

  3. Perbarui manifes klaster Anda dengan menggunakan manifes klaster yang diperbarui buat klaster baru atau tingkatkan konfigurasi klaster.

    Setelah klaster berjalan dengan manifes klaster yang diperbarui, Anda dapat melihat layanan Repair Manager yang berjalan di klaster Anda. Ini disebut fabric:/System/RepairManagerService, dan ini berada dalam bagian layanan sistem di Service Fabric Explorer.

Mengonfigurasi pembaruan Windows untuk semua node

Pembaruan Windows otomatis dapat menyebabkan hilangnya ketersediaan, karena beberapa node klaster dapat memulai secara bersamaan. POA, secara default, mencoba menonaktifkan pembaruan Windows otomatis pada setiap node klaster. Namun, jika pengaturan dikelola oleh administrator atau Kebijakan Grup, kami sarankan mengatur kebijakan Windows Update ke "Beri tahu sebelum Mengunduh" secara eksplisit.

Mengunduh paket aplikasi

Untuk mengunduh paket aplikasi, buka halaman rilis Aplikasi Orkestrasi Patch pada GitHub.

Mengonfigurasi perilaku POA

Anda dapat mengonfigurasi perilaku POA untuk memenuhi keperluan Anda. Ganti nilai default dengan meneruskan parameter aplikasi saat Anda membuat atau memperbarui aplikasi. Anda dapat menyediakan parameter aplikasi dengan menentukan ApplicationParameter ke Start-ServiceFabricApplicationUpgrade atau cmdlet New-ServiceFabricApplication.

Parameter Jenis Detail
MaxResultsToCache Long Jumlah maksimum hasil Windows Update yang harus di-cache.

Nilai default adalah 3000, dengan asumsi bahwa:
  - Jumlah node adalah 20.
  - Jumlah pembaruan untuk node per bulan adalah 5.
  - Jumlah hasil per operasi bisa 10.
  - Hasil selama tiga bulan terakhir harus disimpan.
TaskApprovalPolicy Enum
{ NodeWise, UpgradeDomainWise }		 TaskApprovalPolicy menunjukkan kebijakan yang akan digunakan oleh Layanan Koordinator untuk menginstal pembaruan Windows di seluruh node klaster Service Fabric.

Nilai yang diizinkan adalah:
NodeWise: Pembaruan Windows diinstal satu node pada satu waktu.
UpgradeDomainWise: Pembaruan Windows diinstal satu domain pembaruan pada satu waktu. (Sebagian besar, semua node milik domain pembaruan dapat digunakan untuk pembaruan Windows.)

Untuk membantu memutuskan kebijakan mana yang paling cocok untuk klaster Anda, lihat bagian FAQ.
LogsDiskQuotaInMB Long
(Default: 1024)		 Ukuran maksimum log aplikasi orkestrasi patch dalam MB, yang dapat disimpan secara lokal di node.
WUQuery string
(Default: IsInstalled=0)		 Kueri untuk mendapatkan pembaruan Windows. Untuk informasi selengkapnya, lihat WuQuery.
InstallWindowsOSOnlyUpdates Boolean
(default: false)		 Gunakan bendera ini untuk mengontrol pembaruan mana yang harus diunduh dan diinstal. Nilai berikut diperbolehkan
true - Hanya menginstal pembaruan sistem operasi Windows.
false - Menginstal semua pembaruan yang tersedia pada komputer.
WUOperationTimeOutInMinutes Int
(Default: 90)		 Menentukan waktu habis untuk setiap operasi Windows Update (cari atau unduh atau instal). Jika operasi tidak diselesaikan dalam waktu habis yang ditentukan, tindakan ini dibatalkan.
WURescheduleCount Int
(Default: 5)		 Jumlah maksimum dari berapa kali layanan menjadwal ulang pembaruan Windows jika operasi gagal terus-menerus.
WURescheduleTimeInMinutes Int
(Default: 30)		 Interval di mana layanan menjadwal ulang pembaruan Windows jika kegagalan terus berlanjut.
WUFrequency String yang dipisahkan koma (Default: Mingguan, Rabu, 7:00:00) Frekuensi untuk menginstal pembaruan Windows. Format dan nilai yang mungkin adalah:
- Bulanan, DD, HH:MM:SS (contoh: Bulanan, 5, 12:22:32). Nilai yang diizinkan untuk bidang DD (hari) adalah angka dari 1 sampai 28 dan terakhir.
- Mingguan, Hari, HH:MM:SS (contoh: Mingguan, Selasa, 12:22:32)
- Harian, HH:MM:SS (contoh: Harian, 12:22:32)
- MonthlyByWeekAndDay, Minggu, Hari, HH:MM:SS (contoh: MonthlyByWeekAndDay, 2, Jumat, 21:00:00 menunjukkan 21:00 UTC pada Hari Jumat minggu ke-2 setiap bulan)
- None yang menunjukkan bahwa pembaruan Windows tidak boleh dilakukan.

Waktu dalam UTC.
AcceptWindowsUpdateEula Boolean
(Default: true)		 Dengan mengatur bendera ini, aplikasi menerima Perjanjian Lisensi Pengguna Akhir untuk Windows Update atas nama pemilik komputer.

Tip

Jika Anda ingin pembaruan Windows segera terjadi, atur WUFrequency sesuai dengan waktu penerapan aplikasi. Contohnya, Anda memiliki klaster pengujian lima node dan berencana untuk menerapkan aplikasi sekitar pukul 17.00 UTC. Jika Anda berasumsi bahwa peningkatan atau penerapan aplikasi memerlukan waktu paling lama 30 menit, atur WUFrequency sebagai Harian, 17:30:00.

Menyebarkan POA

  1. Selesaikan semua langkah prasyarat untuk menyiapkan klaster.

  2. Menyebarkan POA seperti aplikasi Service Fabric lainnya. Untuk menyebarkannya dengan menggunakan PowerShell, lihat Menyebarkan dan menghapus aplikasi menggunakan PowerShell.

  3. Untuk mengonfigurasi aplikasi pada saat penyebaran, teruskan ApplicationParameter ke cmdlet New-ServiceFabricApplication. Demi kenyamanan Anda, kami telah menyediakan skrip Deploy.ps1 bersama dengan aplikasi. Untuk menggunakan skrip:

    • Sambungkan ke klaster Service Fabric dengan menggunakan Connect-ServiceFabricCluster.
    • Jalankan skrip PowerShell Deploy.ps1 dengan nilai ApplicationParameter yang sesuai.

Catatan

Simpan skrip dan folder aplikasi PatchOrchestrationApplication dalam direktori yang sama.

Meningkatkan POA

Untuk meningkatkan versi POA Anda dengan menggunakan PowerShell, ikuti instruksi dalam peningkatan aplikasi Service Fabric menggunakan PowerShell.

Menghapus POA

Untuk menghapus aplikasi, ikuti instruksi dalam Menerapkan dan menghapus aplikasi menggunakan PowerShell.

Demi kenyamanan Anda, kami telah menyediakan skrip Deploy.ps1 bersama dengan aplikasi. Untuk menggunakan skrip:

  • Sambungkan ke klaster Service Fabric dengan menggunakan Connect-ServiceFabricCluster.
  • Jalankan skrip PowerShell Deploy.ps1

Catatan

Simpan skrip dan folder aplikasi PatchOrchestrationApplication dalam direktori yang sama.

Melihat hasil Windows Update

POA mengekspos REST API untuk menampilkan hasil historis kepada pengguna. Berikut adalah contoh hasil JSON:

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

Bidang JSON dijelaskan dalam tabel berikut:

Bidang Nilai Detail
OperationResult 0 - Berhasil
1 - Berhasil Dengan Kesalahan
2 - Gagal
3 - Dibatalkan
4 - Dibatalkan Dengan waktu habis		 Menunjukkan hasil dari operasi keseluruhan, yang biasanya melibatkan penginstalan dari satu atau lebih pembaruan.
ResultCode Sama seperti OperationResult Bidang ini menunjukkan hasil operasi penginstalan untuk pembaruan individu.
Jenis Operasi 1 - Penginstalan
0 - Cari dan Unduh		 Secara default, Penginstalan adalah satu-satunya OperationType yang ditampilkan dalam hasil.
WindowsUpdateQuery Defaultnya adalah "IsInstalled=0" Kueri Windows Update yang digunakan untuk mencari pembaruan. Untuk informasi selengkapnya, lihat WuQuery.
RebootRequired true - boot ulang diperlukan
false - boot ulang tidak diperlukan		 Menujukkan apakah boot ulang diperlukan untuk menyelesaikan penginstalan pembaruan.
OperationStartTime DateTime Menunjukkan waktu operasi (Pengunduhan/Penginstalan) dimulai.
OperationTime DateTime Menunjukkan waktu operasi (Pengunduhan/Penginstalan) selesai.
Hresult 0 - Berhasil
lainnya - kegagalan		 Menunjukkan alasan kegagalan pembaruan Windows dengan updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

Jika belum ada pembaruan yang dijadwalkan, hasil JSON kosong.

Masuk ke klaster untuk mengkueri hasil Windows Update. Cari tahu alamat IP replikasi untuk alamat utama Layanan Koordinator, dan buka URL berikut dari browser: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Titik akhir REST untuk Layanan Koordinator memiliki port dinamis. Untuk memeriksa URL yang tepat, lihat Service Fabric Explorer. Contohnya, hasil tersedia pada http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults .

Gambar titik akhir REST

Jika proksi cadangan diaktifkan pada klaster, Anda juga dapat mengakses URL dari luar klaster.

Titik akhir yang perlu Anda tekan adalah http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Untuk mengaktifkan proxy cadangan di klaster, ikuti petunjuk di Membalikkan proxy di Azure Service Fabric.

Peringatan

Setelah proxy cadangan dikonfigurasi, semua layanan mikro di klaster yang mengekspos titik akhir HTTP dapat dialamatkan dari luar klaster.

Aktivitas diagnostik dan kesehatan

Bagian ini membahas cara men-debug atau mendiagnosis masalah dengan pembaruan patch melalui POA pada klaster Service Fabric.

Catatan

Untuk mendapatkan banyak dari peningkatan diagnostik mandiri yang dipanggil berikut ini, Anda harus menginstal POA versi 1.4.0 atau yang lebih baru.

Node Agent NTService membuat tugas perbaikan untuk memasang pembaruan pada node. Setiap tugas kemudian disiapkan oleh Layanan Koordinator sesuai dengan kebijakan persetujuan tugas. Terakhir, tugas yang disiapkan disetujui oleh Repair Manager, yang tidak menyetujui tugas apa pun jika cluster dalam keadaan tidak sehat.

Untuk membantu Anda memahami bagaimana pembaruan berlanjut pada sebuah node, mari kita lakukan langkah demi langkah:

  1. NodeAgentNTService, berjalan di setiap node, mencari pembaruan Windows yang tersedia pada waktu yang dijadwalkan. Jika pembaruan tersedia, ia mengunduhnya di node.

  2. Setelah pembaruan diunduh, Node Agent NTService membuat tugas perbaikan yang sesuai untuk node dengan nama POS___<unique_id>. Anda dapat melihat tugas perbaikan ini dengan menggunakan cmdlet Get-ServiceFabricRepairTask atau menggunakan SFX di bagian detail node. Seletah dibuat, tugas perbaikan dengan cepat berpindah ke status Diklaim.

  3. Layanan Koordinator secara berkala mencari tugas perbaikan dalam status Diklaim dan kemudian meningkatkannya ke status Mempersiapkan berdasarkan TaskApprovalPolicy. Jika TaskApprovalPolicy dikonfigurasi menjadi NodeWise, tugas perbaikan yang terkait dengan node disiapkan hanya jika tidak ada tugas perbaikan lain saat ini di status Mempersiapkan, Disetujui, Menjalankan, atau Memulihkan.

    Demikian pula, dalam kasus UpgradeWise TaskApprovalPolicy, ada tugas di status sebelumnya hanya untuk node yang termasuk dalam domain pembaruan yang sama. Setelah tugas perbaikan dipindahkan ke status Mempersiapkan, simpul Service Fabric terkait dinonaktifkan dengan maksud diatur ke restart.

    POA versi 1.4.0 dan acara posting yang lebih baru dengan properti ClusterPatchingStatus di CoordinatorService untuk menampilkan simpul yang sedang ditambal. Pembaruan diinstal di _poanode_0, seperti yang ditunjukkan pada gambar berikut:

    Gambar status penambalan cluster

  4. Setelah simpul dinonaktifkan, tugas perbaikan dipindahkan ke status Menjalankan.

    Catatan

    Simpul yang macet dalam status Dinonaktifkan dapat memblokir tugas perbaikan baru, yang menghentikan operasi penambalan pada klaster.

  5. Ketika tugas perbaikan berada dalam status Menjalankan, penginstalan patch pada simpul tersebut dimulai. Setelah patch diinstal, simpul mungkin atau mungkin tidak di-hidupkan ulang, tergantung pada patchnya. Selanjutnya, tugas perbaikan dipindahkan ke status Memulihkan, yang mengaktifkan kembali simpul tersebut. Tugas perbaikan kemudian ditandai sebagai selesai.

    Dalam POA versi 1.4.0 dan yang lebih baru, Anda dapat menemukan status pembaruan dengan melihat peristiwa kesehatan di NodeAgentService dengan properti WUOperationStatus-<NodeName>. Bagian yang disorot pada gambar berikut menunjukkan status pembaruan Windows pada simpul poanode_0 dan poanode_2:

    Cuplikan layar menunjukkan jendela konsol dari status operasi Windows Update dengan poanode_0 disorot.

    Cuplikan layar menunjukkan jendela konsol dari status operasi Windows Update dengan poanode_1 disorot.

    Anda juga bisa mendapatkan detailnya dengan menggunakan PowerShell. Untuk melakukannya, Anda terhubung ke klaster dan mengambil status tugas perbaikan dengan menggunakanGet-ServiceFabricRepairTask.

    Dalam contoh berikut, tugas "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" dalam statusDownloadComplete. Ini berarti bahwa pembaruan telah diunduh pada simpul ​​poanode_2, dan penginstalan akan dilakukan ketika tugas berpindah ke status Menjalankan.

     D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k = Get-ServiceFabricRepairTask -TaskId "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15"

 D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k.ExecutorData
 {"ExecutorSubState":2,"ExecutorTimeoutInMinutes":90,"RestartRequestedTime":"0001-01-01T00:00:00"}

    Jika masih banyak masalah yang masih ditemukan, masuk ke komputer virtual (VM) atau VM Anda dan pelajari tentang masalah tersebut menggunakan log peristiwa Windows. Tugas perbaikan yang disebutkan sebelumnya hanya dapat dilakukan di substrat pelaksana berikut:

    ExecutorSubState Deskripsi
    Tidak Ada=1 Menyiratkan bahwa tidak ada operasi yang sedang berlangsung pada simpul. Kondisi mungkin sedang dalam transisi.
    DownloadCompleted=2 Menyiratkan bahwa operasi pengunduhan selesai dengan sukses, gagal sebagian, atau gagal.
    InstallationApproved=3 Menyiratkan bahwa operasi pengunduhan telah diselesaikan lebih awal dan Repair Manager telah menyetujui penginstalan.
    InstallationInProgress=4 Sesuai dengan kondisi pelaksanaan tugas perbaikan.
    InstallationCompleted=5 Menyiratkan bahwa penginstalan selesai dengan sukses, berhasil sebagian, atau gagal.
    RestartRequested=6 Menyiratkan bahwa penginstalan patch telah selesai dan ada tindakan restart yang tertunda pada simpul.
    RestartNotNeeded=7 Menyiratkan bahwa restart tidak diperlukan setalah penginstalan patch selesai.
    RestartCompleted=8 Menyiratkan bahwa restart telah selesai dengan sukses.
    OperationCompleted=9 Operasi Windows Update berhasil selesai dengan sukses.
    OperationAborted=10 Menyiratkan bahwa operasi Windows Update dibatalkan.

  6. Dalam POA versi 1.4.0 dan yang lebih baru, ketika upaya pembaruan node selesai, acara dengan properti "WUOperationStatus- [NodeName]" diposting di NodeAgentService untuk memberi tahu Anda ketika upaya berikutnya untuk mengunduh dan menginstal pembaruan Windows akan dimulai. Ini ditampilkan pada gambar berikut:

    Cuplikan layar menunjukkan jendela konsol dari status operasi Windows Update dengan NodeAgentService.

Log diagnostik

Log aplikasi orkestrasi patch dikumpulkan sebagai bagian dari log runtime Service Fabric.

Anda dapat menangkap log dengan menggunakan alat atau saluran diagnostik pilihan Anda. POA menggunakan ID penyedia tetap berikut untuk mencatat kejadian melalui sumber kejadian:

  • e39b723c-590c-4090-abb0-11e3e6616346
  • fc0028ff-bfdc-499f-80dc-ed922c52c5e9
  • 24afa313-0d3b-4c7c-b485-1047fd964b60
  • 05dc046c-60e9-4ef7-965e-91660adffa68

Laporan kesehatan

POA juga menerbitkan laporan kesehatan terhadap Layanan Agen simpul atau Layanan Koordinator dalam skenario berikut:

  • Node Agent NTService tidak aktif

    Jika Node Agent NTService mati pada sebuah simpul, laporan kesehatan tingkat peringatan dibuat terhadap Node Agent Service.

  • Layanan Repair Manager tidak diaktifkan

    Jika layanan Repair Manager tidak ditemukan di klaster, laporan kesehatan tingkat peringatan dibuat untuk Layanan Koordinator.

Tanya jawab umum

Q: Mengapa saya melihat klaster saya dalam status kesalahan saat POA dijalankan?

A: Selama proses instalasi, POA menonaktifkan atau merestart node, yang dapat menyebabkan klaster tidak sehat untuk sementara.

Bergantung pada kebijakan aplikasi, salah satu node bisa tidak berfungsi selama operasi penambalan atau seluruh domain pembaruan bisa turun sekaligus.

Pada akhir penginstalan pembaruan Windows, node diaktifkan kembali setelah restart.

Dalam contoh berikut, klaster pergi ke status kesalahan sementara karena dua node tidak aktif dan kebijakan MaxPercentageUnhealthyNodes telah dilanggar. Kesalahan ini bersifat sementara hingga operasi patching dapat dimulai.

Gambar klaster tidak sehat

Jika masalah terus berlanjut, lihat bagian Pemecahan Masalah.

Q: Apa yang dapat saya lakukan jika POA dalam status peringatan?

A: Periksa untuk melihat apakah laporan kesehatan yang diposting terhadap aplikasi menunjukkan penyebab utama. Biasanya, peringatan tersebut berisi detail masalah. Jika masalahnya hanya sementara, aplikasi diharapkan pulih secara otomatis.

T: Apa yang dapat saya lakukan jika klaster saya tidak sehat dan saya perlu melakukan pembaruan sistem operasi yang mendesak?

J: POA tidak memasang pembaruan saat klaster tidak sehat. Cobalah untuk membawa klaster Anda ke status sehat untuk membuka blokir alur kerja POA.

Q: Haruskah saya menetapkan TaskApprovalPolicy sebagai "NodeWise" atau "UpgradeDomainWise" untuk klaster saya?

A: Pengaturan "UpgradeDomainWise" mempercepat perbaikan klaster secara keseluruhan dengan patching semua node yang termasuk dalam domain pembaruan secara paralel. Selama proses, node yang termasuk dalam seluruh domain pembaruan tidak tersedia (dalam status Dinonaktifkan).

Sebaliknya, aturan "NodeWise" hanya menambal satu node pada satu waktu, yang berarti bahwa penambalan klaster secara keseluruhan mungkin membutuhkan waktu lebih lama. Namun, paling banyak hanya satu node yang tidak akan tersedia (dalam status Nonaktif) selama proses patching.

Jika kluster Anda dapat menyiapkan domain pembaruan dalam nomor N-1 selama siklus patch (dengan N adalah jumlah total domain pembaruan di kluster Anda), Anda dapat menetapkan kebijakan sebagai "UpgradeDomainWise." Jika tidak, atur ke "NodeWise."

Q: Berapa lama waktu yang dibutuhkan untuk menambal node?

A: Menambal node dapat memerlukan waktu dari menit (misalnya, pembaruan definisi Windows Defender) hingga jam (misalnya, pembaruan Kumulatif Windows). Waktu yang diperlukan untuk menambal node sebagian besar bergantung pada:

  • Ukuran pembaruan.
  • Jumlah pembaruan, yang harus diterapkan di jendela patching.
  • Waktu yang diperlukan untuk menginstal pembaruan, reboot node (jika diperlukan), dan selesaikan langkah-langkah instalasi setelah reboot.
  • Kinerja VM atau komputer, dan kondisi jaringan.

Q: Berapa lama waktu yang dibutuhkan untuk menambal seluruh klaster?

A: Waktu yang diperlukan untuk patch seluruh klaster bergantung pada:

  • Waktu yang dibutuhkan untuk menambal node.

  • Kebijakan Layanan Koordinator. Kebijakan default, "NodeWise", menghasilkan patch hanya satu node pada satu waktu, pendekatan yang lebih lambat daripada menggunakan "UpgradeDomainWise."

    Misalnya: Jika sebuah node membutuhkan waktu ~1 jam untuk dipatch, patching klaster 20-node (jenis node yang sama) dengan 5 domain pembaruan, masing-masing berisi 4 node, memerlukan:

    • Untuk "NodeWise": ~20 jam.
    • Untuk "UpgradeDomainWise": ~5 jam.

  • Beban klaster. Setiap operasi patching memerlukan relokasi beban kerja pelanggan ke node lain yang tersedia di klaster. Node yang sedang ditambal akan berada dalam status Menonaktifkan selama ini. Jika klaster berjalan mendekati beban puncak, proses penonaktifan akan memakan waktu lebih lama. Oleh karena itu, proses patching secara keseluruhan mungkin tampak lambat dalam kondisi stres seperti itu.

  • Kegagalan kesehatan klaster selama patching. Setiap degradasi dalam kesehatan klaster akan mengganggu proses patching. Masalah ini akan menambah waktu keseluruhan yang dibutuhkan untuk menambal seluruh klaster.

Q: Mengapa saya melihat beberapa pembaruan dalam hasil Windows Update yang diperoleh melalui REST API, tetapi tidak dalam riwayat Windows Update di komputer?

A: Beberapa pembaruan produk hanya muncul dalam pembaruan atau riwayat tambalan mereka sendiri. Misalnya, pembaruan Windows Defender mungkin atau mungkin tidak ditampilkan dalam riwayat Windows Update di Windows Server 2016.

Q: Dapatkah POA digunakan untuk menambal kelompok dev saya (klaster satu simpul)?

A: Tidak, POA tidak dapat digunakan untuk patch klaster satu node. Batasan ini memang sengaja dibuat, karena layanan sistem Service Fabric atau aplikasi pelanggan lainnya akan menimbulkan waktu henti. Oleh karena itu, pekerjaan perbaikan patch tidak akan pernah mendapatkan persetujuan dari Repair Manager.

Q: Bagaimana cara menambal node klaster di Linux?

A: Untuk mempelajari tentang mengatur pembaruan di Linux, lihat skala komputer virtual Azure menyetel peningkatan versi gambar OS otomatis .

Q: Mengapa siklus pembaruan berlangsung lama?

A: Kueri untuk hasil JSON, masukkan siklus perbarui untuk semua node, dan kemudian Anda dapat mencoba untuk mengetahui waktu yang dibutuhkan dengan perbarui instalasi pada setiap node dengan menggunakan OperationStartTime dan OperationTime (OperationCompletionTime).

Jika ada jendela waktu besar di mana tidak ada pembaruan yang dilakukan, klaster mungkin berada dalam status kesalahan dan, akibatnya, Repair Manager tidak dapat menyetujui tugas perbaikan POA apa pun. Jika penginstalan pembaruan memakan waktu lama pada node mana pun, node tersebut mungkin tidak diperbarui dalam beberapa saat. Banyak pembaruan mungkin menunggu penginstalan, yang dapat mengakibatkan penundaan.

Mungkin juga penambalan node diblokir karena macet dalam status Penonaktifan. Ini biasanya terjadi karena menonaktifkan node dapat menyebabkan situasi kuorum atau kehilangan data.

Q: Mengapa node harus dinonaktifkan saat POA mempatch itu?

A: POA menonaktifkan node dengan maksud Hidupkan ulang, yang menghentikan atau mengalokasikan ulang semua layanan Service Fabric yang berjalan pada node. POA melakukan ini untuk memastikan bahwa aplikasi tidak berakhir menggunakan campuran DLL baru dan lama, jadi sebaiknya jangan mempatch node tanpa menonaktifkannya.

Q: Berapa jumlah maksimum node yang dapat diperbarui dengan menggunakan POA?

A: POA menggunakan Service Fabric Repair Manager untuk membuat tugas perbaikan node untuk pembaruan. Namun, tidak lebih dari 250 tugas perbaikan dapat dilakukan pada saat yang bersamaan. Saat ini, POA membuat tugas perbaikan untuk setiap node pada saat yang sama, sehingga POA dapat memperbarui tidak lebih dari 250 node dalam sebuah klaster.

Penafian

  • POA menerima Perjanjian Lisensi Pengguna Akhir untuk Windows Update atas nama pengguna. Secara opsional, pengaturan dapat dimatikan dalam konfigurasi aplikasi.

  • POA mengumpulkan telemetri untuk melacak penggunaan dan kinerja. Telemetri aplikasi mengikuti aturan telemetri waktu proses Service Fabric (yang diaktifkan secara default).

Pemecahan Masalah

Bagian ini memberikan solusi pemecahan masalah yang mungkin untuk masalah dengan mempatch node.

Node tidak kembali ke kondisi atas

  • Node tersebut mungkin macet dalam status Nonaktif karena:

    • Pemeriksaan keamanan tertunda. Untuk memperbaiki situasi ini, pastikan bahwa tersedia cukup node dalam keadaan sehat.

  • Node mungkin macet dalam status Dinonaktifkan karena:

    • Node dinonaktifkan secara manual.
    • Node dinonaktifkan karena pekerjaan infrastruktur Azure yang sedang berlangsung.
    • Node dinonaktifkan sementara oleh POA untuk patch node.

  • Node mungkin macet dalam keadaan tidak berfungsi karena:

    • Node ditempatkan dalam keadaan tidak berfungsi secara manual.
    • Node sedang menjalani restart (yang mungkin dipicu oleh POA).
    • Node memiliki VM atau komputer yang salah, atau mengalami masalah konektivitas jaringan.

Pembaruan dilewati pada beberapa node

POA mencoba menginstal pembaruan Windows sesuai dengan kebijakan penjadwalan ulang. Layanan mencoba memulihkan node dan melewati pembaruan sesuai dengan kebijakan aplikasi.

Dalam kasus seperti itu, laporan kesehatan tingkat peringatan dibuat terhadap Layanan Agen Node. Hasil Windows Update juga berisi kemungkinan penyebab kegagalan.

Kesehatan klaster mengalami kesalahan saat pembaruan sedang diinstal

Pembaruan Windows yang salah dapat menurunkan kesehatan aplikasi atau klaster pada node tertentu atau memperbarui domain. POA menghentikan operasi Pembaruan Windows berikutnya hingga klaster sehat kembali.

Administrator harus mengintervensi dan menentukan mengapa aplikasi atau klaster menjadi tidak sehat karena Pembaruan Windows.

Catatan rilis POA

Catatan

Untuk POA versi 1.4.0 dan yang lebih baru, Anda dapat menemukan rilis dan catatan rilis di halaman rilis Aplikasi Orkestrasi Patch di GitHub.

Versi 1.1.0

  • Rilis publik

Versi 1.1.1

  • Memperbaiki bug di SetupEntryPoint dari NodeAgentService yang mencegah penginstalan NodeAgentNTService.

Versi 1.2.0

  • Perbaikan bug di sekitar alur kerja restart sistem.
  • Perbaikan bug dalam pembuatan tugas RM karena probe kesehatan selama menyiapkan tugas perbaikan tidak terjadi seperti yang diharapkan.
  • Mengubah mode startup untuk layanan Windows POANodeSvc dari otomatis ke otomatis tertunda.

Versi 1.2.1

  • Perbaikan bug dalam alur kerja skala kecil klaster. Memperkenalkan logika pengumpulan sampah untuk tugas perbaikan POA milik node yang tidak ada.

Versi 1.2.2

  • Beberapa macam perbaikan bug.
  • Binari sekarang ditandai.
  • Menambahkan tautan sfpkg untuk aplikasi.

Versi 1.3.0.1

  • Mengatur InstallWindowsOSOnlyUpdates menjadi salah, sekarang akan menginstal semua pembaruan yang tersedia.
  • Mengubah logika menonaktifkan pembaruan otomatis. Ini memperbaiki bug tempat Pembaruan otomatis tidak dinonaktifkan di Server 2016 dan yang lebih baru.
  • Batasan penempatan berparameterisasi untuk layanan mikro POA untuk kasus penggunaan lanjutan.

Versi 1.3.1

  • Memperbaiki regresi tempat POA 1.3.0 tidak berfungsi di Windows Server 2012 R2 atau yang lebih lama karena kegagalan dalam menonaktifkan pembaruan otomatis.
  • Memperbaiki bug di mana konfigurasi InstallWindowsOSOnlyUpdates selalu dipilih sebagai True.
  • Mengubah nilai default InstallWindowsOSOnlyUpdates menjadi False.

Versi 1.3.2

  • Memperbaiki masalah yang memengaruhi siklus proses patching pada sebuah node, jika terdapat node dengan nama yang merupakan subset dari nama node saat ini. Untuk node seperti itu, ada kemungkinan patching terlewat atau reboot tertunda.