Artikel ini menjelaskan praktik terbaik tentang cara membangun azure Spot Virtual Machines. Ini termasuk skenario contoh yang dapat disebarkan. Komputer virtual spot (VM spot) menyediakan akses ke kapasitas komputasi dengan harga lebih rendah daripada VM reguler. Diskon ini menjadikan mereka pilihan yang baik untuk organisasi yang ingin mengoptimalkan biaya. Tapi tabungan datang dengan trade-off. Spot VM dapat dikeluarkan kapan saja, yang berarti bahwa mereka kehilangan akses ke sumber daya komputasi. Beban kerja yang berjalan pada VM spot harus dapat menangani gangguan ini dalam komputasi. Beban kerja yang tepat dan mekanisme orkestrasi yang fleksibel adalah kunci keberhasilan. Rekomendasi berikut menjelaskan cara membangun VM spot.
Memahami VM spot
Pada tingkat teknis, VM spot sama dengan VM reguler. Mereka menggunakan gambar, perangkat keras, dan disk yang sama yang diterjemahkan ke performa yang sama. Perbedaan utama antara VM spot dan VM reguler adalah prioritas dan ketersediaannya. VM spot tidak memiliki prioritas untuk mengakses kapasitas komputasi, dan mereka tidak memiliki jaminan ketersediaan setelah mereka mengakses kapasitas komputasi tersebut.
Tidak ada akses prioritas. VM reguler memiliki akses prioritas ke kapasitas komputasi. Mereka mengakses kapasitas komputasi ketika mereka memintanya. Namun, VM spot hanya disebarkan ketika ada kapasitas komputasi cadangan. Dan mereka hanya terus berjalan ketika VM biasa tidak memerlukan perangkat keras yang mendasarinya.
Tidak ada jaminan ketersediaan. VM spot tidak memiliki jaminan ketersediaan atau perjanjian tingkat layanan (SLA). VM spot dapat segera kehilangan akses ke kapasitas komputasi, atau kapan saja setelah penyebaran atau pengeluaran. Spot VM lebih murah karena dapat dikeluarkan. Ketika Azure membutuhkan kapasitas komputasi kembali, pemberitahuan pengeluaran dikirim dan mengeluarkan VM spot. Azure memberikan pemberitahuan minimal 30 detik sebelum pengeluaran aktual terjadi. Untuk informasi selengkapnya, lihat Terus memantaupengeluaran .
Memahami harga VM spot
VM spot dapat mencapai 90% lebih murah daripada VM bayar sesuai pemakaian reguler. Diskon bervariasi berdasarkan permintaan, ukuran VM, wilayah penyebaran, dan sistem operasi. Untuk mendapatkan perkiraan penghematan biaya, lihat alat harga Azure Spot Virtual Machines dan gambaran umum harga Spot Virtual Machines. Anda juga dapat mengkueri API harga ritel Azure untuk secara terprogram mendapatkan harga spot untuk SKU apa pun.
Memahami beban kerja yang dapat diinterupsi
Spot VM sangat ideal untuk beban kerja yang dapat diinterupsi, yang berbagi beberapa karakteristik umum. Beban kerja yang dapat diinterupsi memiliki batasan minimal hingga tidak ada waktu, prioritas organisasi yang rendah, dan waktu pemrosesan yang singkat. Mereka menjalankan proses yang dapat berhenti tiba-tiba dan dilanjutkan nanti tanpa merugikan proses organisasi penting. Contoh beban kerja yang dapat diinterupsi adalah aplikasi pemrosesan batch, analitik data, dan beban kerja yang membuat integrasi berkelanjutan dan agen penyebaran berkelanjutan untuk lingkungan nonproduksi. Fitur-fitur ini dibandingkan dengan beban kerja reguler atau misi penting yang memiliki SLA, sesi lekat, dan data stateful.
Anda dapat menggunakan VM spot dalam beban kerja yang tidak dapat diinterupsi, tetapi seharusnya bukan satu-satunya sumber kapasitas komputasi. Gunakan VM reguler sebanyak yang Anda butuhkan untuk memenuhi persyaratan waktu aktif Anda.
Memahami pengeluaran
VM spot tidak memiliki SLA setelah pembuatan, dan mereka dapat kehilangan akses ke komputasi kapan saja. Kami menyebut komputasi ini kehilangan pengeluaran. Komputasi pasokan dan permintaan mendorong pengeluaran. Ketika permintaan untuk ukuran VM tertentu melebihi tingkat tertentu, Azure mengeluarkan VM spot untuk membuat komputasi tersedia untuk VM reguler. Permintaan spesifik lokasi. Misalnya, peningkatan permintaan di wilayah A tidak memengaruhi VM spot di wilayah B.
Spot VM memiliki dua opsi konfigurasi yang memengaruhi pengeluaran. Konfigurasi ini adalah jenis pengeluaran dan kebijakan pengeluaran VM spot. Anda mengatur konfigurasi ini saat membuat VM spot. Jenis pengeluaran mendefinisikan kondisi pengeluaran. Kebijakan pengeluaran menentukan apa yang dilakukan pengeluaran pada VM spot Anda.
Jenis pengeluaran
Perubahan kapasitas atau perubahan harga menyebabkan pengeluaran. Cara perubahan kapasitas dan harga memengaruhi VM spot tergantung pada jenis pengeluaran yang Anda pilih saat VM dibuat. Jenis pengeluaran mendefinisikan kondisi pengeluaran. Jenis pengeluaran pengeluaran khusus kapasitas dan harga atau pengeluaran kapasitas.
Pengeluaran khusus kapasitas: Jenis pengeluaran ini memicu pengeluaran ketika kelebihan kapasitas komputasi tidak lagi tersedia. Secara default, harga dibatasi pada tarif bayar sesuai penggunaan. Gunakan jenis pengeluaran ini ketika Anda tidak ingin membayar lebih dari harga VM bayar sesuai pemakaian.
Pengeluaran harga atau kapasitas: Jenis pengeluaran ini memiliki dua pemicu. Azure mengeluarkan VM spot ketika kelebihan kapasitas komputasi tidak lagi tersedia atau biaya VM melebihi harga maksimum yang Anda tetapkan. Jenis pengeluaran ini memungkinkan Anda untuk menetapkan harga maksimum yang jauh di bawah harga bayar sesuai penggunaan. Gunakan jenis pengeluaran ini untuk mengatur batas harga Anda sendiri.
Kebijakan pengeluaran
Kebijakan pengeluaran yang Anda pilih untuk VM spot memengaruhi orkestrasinya. Orkestrasi adalah proses penanganan pengeluaran dan dibahas nanti dalam artikel ini. Kebijakan pengeluaran adalah kebijakan Hentikan/Batalkan alokasi dan kebijakan Hapus.
kebijakan Stop/Deallocate: Kebijakan Stop/Deallocate sangat ideal ketika beban kerja dapat menunggu kapasitas rilis dalam lokasi dan jenis VM yang sama. Kebijakan Hentikan/Batalkan alokasi menghentikan VM dan mengakhiri sewanya dengan perangkat keras yang mendasar. Menghentikan dan membatalkan alokasi VM spot sama dengan menghentikan dan membatalkan alokasi VM biasa. VM tetap dapat diakses di Azure, dan Anda dapat memulai ulang VM yang sama nanti. VM kehilangan kapasitas komputasi dan alamat IP nonstatis dengan kebijakan Stop/Deallocate. Namun, disk data VM tetap ada dan terus dikenakan biaya. VM juga menempati inti dalam langganan. VM tidak dapat dipindahkan dari wilayah atau zonanya bahkan ketika dihentikan atau dibatalkan alokasinya. Untuk informasi selengkapnya, lihat Status daya danpenagihan .
Hapus kebijakan: Gunakan kebijakan Hapus jika beban kerja dapat mengubah lokasi atau ukuran VM. Mengubah lokasi atau ukuran VM memungkinkan VM untuk menyebarkan ulang lebih cepat. Kebijakan Hapus menghapus VM dan disk data apa pun. VM tidak menempati inti dalam langganan. Untuk informasi selengkapnya, lihat kebijakan Pengeluaran .
Desain untuk orkestrasi fleksibel
Orkestrasi adalah proses mengganti VM spot setelah pengeluaran. Ini adalah fondasi untuk membangun beban kerja yang dapat diinterupsi dengan andal. Sistem orkestrasi yang baik memiliki fleksibilitas bawaan. Fleksibilitas berarti merancang orkestrasi Anda untuk memiliki opsi, menggunakan beberapa ukuran VM, menyebarkan ke berbagai wilayah, memiliki kesadaran pengeluaran, dan memperhitungkan skenario pengeluaran yang berbeda untuk meningkatkan keandalan dan kecepatan beban kerja.
Desain untuk kecepatan
Untuk beban kerja yang berjalan pada VM spot, kapasitas komputasi sangat penting. Karena potensi pengeluaran, pastikan Anda memahami waktu komputasi yang dialokasikan sehingga Anda dapat membuat keputusan desain berdasarkan informasi yang memprioritaskan kecepatan beban kerja. Umumnya, Anda harus mengoptimalkan waktu komputasi yang Anda miliki. Buat gambar VM yang memiliki semua perangkat lunak yang diperlukan yang telah diinstal sebelumnya. Perangkat lunak yang telah diinstal sebelumnya membantu meminimalkan waktu antara pengeluaran dan aplikasi yang beroperasi penuh. Hindari menggunakan waktu komputasi pada proses yang tidak berkontribusi pada tujuan beban kerja. Misalnya, beban kerja untuk analitik data harus memfokuskan sebagian besar waktu komputasinya pada pemrosesan data dan sesedikitan mungkin waktu pada pengumpulan metadata pengeluaran. Hilangkan proses yang tidak penting dari aplikasi Anda.
Menggunakan beberapa ukuran dan lokasi VM
Untuk meningkatkan fleksibilitas, buat orkestrasi untuk menggunakan beberapa jenis dan ukuran VM. Tujuannya adalah untuk memberikan opsi orkestrasi Anda untuk menggantikan VM yang dikeluarkan. Azure memiliki berbagai jenis dan ukuran VM yang menyediakan kemampuan serupa dengan harga yang hampir sama. Filter untuk vCPU atau inti minimum, RAM minimum untuk VM, dan harga maksimum. Proses ini membantu Anda menemukan beberapa VM yang sesuai dengan anggaran Anda dan memiliki daya yang cukup untuk menjalankan beban kerja Anda.
Setiap jenis VM memiliki tingkat pengeluaran yang dinyatakan sebagai rentang persentase, seperti 0%-5%, 5%-10%, 10%-15%, 15%-20%, atau 20+%. Tingkat pengeluaran dapat bervariasi di seluruh wilayah. Anda mungkin menemukan tingkat pengeluaran yang lebih baik untuk jenis VM yang sama di wilayah yang berbeda. Anda dapat menemukan tingkat pengeluaran untuk setiap jenis VM di portal di bawah tab Dasar. Di samping Ukuran, pilih Lihat riwayat harga atau Lihat semua ukuran. Anda juga dapat secara terprogram mendapatkan data VM spot dengan menggunakan Azure Resource Graph.
Dalam sistem orkestrasi Anda, pertimbangkan untuk menggunakan fitur skor penempatan spot untuk mengevaluasi kemungkinan keberhasilan untuk penyebaran spot individual.
Untuk informasi selengkapnya, lihat sumber daya berikut ini:
- tingkat Pengeluaran
- Resource Graph
- skor penempatan Spot
Menggunakan kebijakan pengeluaran yang paling fleksibel
Kebijakan pengeluaran VM spot yang dikeluarkan memengaruhi proses penggantian. Misalnya, kebijakan Hapus lebih fleksibel daripada kebijakan Stop/Deallocate.
Pertimbangkan kebijakan Hapus terlebih dahulu: Gunakan kebijakan Hapus jika beban kerja Anda dapat menanganinya. Penghapusan memungkinkan orkestrasi untuk menyebarkan VM spot pengganti ke zona dan wilayah baru. Fleksibilitas penyebaran ini dapat membantu beban kerja Anda menemukan kapasitas komputasi cadangan lebih cepat daripada VM yang dihentikan atau dibatalkan alokasinya. VM yang dihentikan atau dibatalkan alokasinya harus menunggu kapasitas komputasi cadangan di zona yang sama tempat VM dibuat. Untuk kebijakan Hapus, Anda memerlukan proses eksternal untuk memantau pengeluaran dan mengatur penyebaran ke berbagai wilayah, menggunakan SKU VM yang berbeda, atau keduanya.
Memahami kebijakan Stop/Deallocate: Kebijakan Stop/Deallocate memiliki lebih sedikit fleksibilitas daripada kebijakan Hapus. VM spot harus tetap berada di wilayah dan zona yang sama. Anda tidak dapat memindahkan VM yang dihentikan atau dibatalkan alokasinya ke lokasi lain. Karena VM memiliki lokasi tetap, Anda memerlukan sesuatu untuk merealokasi VM ketika kapasitas komputasi tersedia. Tidak ada cara untuk memprediksi ketersediaan kapasitas komputasi. Jadi Anda harus menggunakan alur jadwal otomatis untuk mencoba penyebaran ulang setelah pengeluaran. Pengeluaran harus memicu alur jadwal, dan upaya penyebaran ulang harus terus memeriksa kapasitas komputasi hingga tersedia.
Kebijakan | Kapan menggunakan kebijakan |
---|---|
Menghapus kebijakan | - Komputasi dan data Ephemeral - Tidak ingin membayar disk data - Anggaran minimal |
Hentikan/Batalkan alokasi kebijakan | - Membutuhkan ukuran VM tertentu - Tidak dapat mengubah lokasi - Proses penginstalan aplikasi yang panjang - Waktu tunggu tak terbatas - Tidak didorong oleh penghematan biaya saja |
Terus memantau pengeluaran
Pemantauan adalah kunci keandalan beban kerja pada VM spot. Spot VM tidak memiliki SLA setelah pembuatan dan dapat dikeluarkan kapan saja. Cara terbaik untuk meningkatkan keandalan beban kerja pada VM spot adalah dengan mengantisipasi kapan mereka akan dikeluarkan. Jika Anda memiliki informasi ini, Anda dapat mencoba penonaktifan beban kerja yang anggun dan memicu otomatisasi untuk mengatur penggantian.
Gunakan Peristiwa Terjadwal: Gunakan layanan Peristiwa Terjadwal untuk setiap VM. Azure mengirim sinyal ke VM saat pemeliharaan infrastruktur akan memengaruhinya. Pengeluaran memenuhi syarat sebagai pemeliharaan infrastruktur. Azure mengirimkan sinyal
Preempt
ke semua VM minimal 30 detik sebelum dikeluarkan. Layanan Peristiwa Terjadwal memungkinkan Anda mengambil sinyalPreempt
ini dengan mengkueri titik akhir di alamat IP statis dan tidak dapat dialihkan169.254.169.254
.Menggunakan kueri yang sering: Kueri titik akhir Peristiwa Terjadwal cukup sering untuk mengatur pematian yang anggun. Anda dapat mengkueri titik akhir Peristiwa Terjadwal hingga setiap detik, tetapi frekuensi satu detik mungkin tidak diperlukan untuk semua kasus penggunaan. Kueri ini harus berasal dari aplikasi yang berjalan di VM spot. Kueri tidak bisa berasal dari sumber eksternal. Akibatnya, kueri menggunakan kapasitas komputasi VM dan mencuri daya pemrosesan dari beban kerja utama. Anda perlu menyeimbangkan prioritas yang bersaing untuk memenuhi situasi spesifik Anda.
Mengotomatiskan orkestrasi: Setelah Anda mengumpulkan sinyal
Preempt
, orkestrasi Anda harus bertindak berdasarkan sinyal tersebut. Mengingat batasan waktu, sinyalPreempt
harus mencoba mematikan beban kerja Anda dengan anggun dan memulai proses otomatis yang menggantikan VM spot. Untuk informasi selengkapnya, lihat sumber daya berikut ini:- Peristiwa Terjadwal
- jenis peristiwa terjadwal
- frekuensi kueri titik akhir
- Peristiwa Terjadwal
Membangun sistem penyebaran
Orkestrasi Anda memerlukan alur otomatis untuk menyebarkan VM spot baru setelah pengeluaran. Alur harus berjalan di luar beban kerja yang dapat diinterupsi untuk membantu memastikan permanen. Alur penyebaran harus berfungsi sesuai dengan kebijakan pengeluaran yang Anda pilih untuk VM spot Anda.
Untuk kebijakan Hapus, kami sarankan Anda membuat alur yang menggunakan ukuran dan penyebaran VM yang berbeda ke wilayah yang berbeda. Untuk kebijakan Hentikan/Batalkan alokasi, alur penyebaran memerlukan dua tindakan yang berbeda. Untuk pembuatan awal VM, alur perlu menyebarkan VM ukuran yang tepat ke lokasi yang tepat. Untuk VM yang dikeluarkan, alur perlu mencoba menghidupkan ulang VM hingga berfungsi. Kombinasi pemberitahuan Azure Monitor dan fungsi Azure adalah salah satu cara untuk mengotomatiskan sistem penyebaran. Alur dapat menggunakan templat bicep. Mereka deklaratif dan idempotensi dan mewakili praktik terbaik untuk penyebaran infrastruktur.
Bersiap untuk pengeluaran segera
Dimungkinkan bagi Azure untuk mengeluarkan VM spot segera setelah Anda membuatnya dan sebelum beban kerja Anda berjalan. Dalam beberapa kasus, mungkin ada kapasitas yang cukup untuk membuat VM spot, tetapi tidak akan bertahan lama. VM spot tidak memiliki jaminan ketersediaan, atau SLA, setelah pembuatan. Orkestrasi Anda perlu memperhitungkan pengeluaran segera. Sinyal Preempt
memberikan pemberitahuan minimal 30 detik sebelumnya tentang pengeluaran.
Masukkan pemeriksaan kesehatan VM ke dalam orkestrasi Anda untuk mempersiapkan pengeluaran segera. Orkestrasi untuk pengeluaran segera tidak dapat bergantung pada sinyal Preempt
Peristiwa Terjadwal. Hanya VM itu sendiri yang dapat mengkueri sinyal Preempt
, dan tidak ada cukup waktu untuk memulai aplikasi, mengkueri titik akhir Peristiwa Terjadwal, dan mematikan dengan anggun. Jadi pemeriksaan kesehatan perlu berada di luar lingkungan beban kerja. Pemeriksaan kesehatan perlu memantau status VM spot dan memulai alur penyebaran untuk menggantikan VM spot ketika status berubah menjadi membatalkan alokasi atau berhenti.
Merencanakan beberapa pengeluaran simultan
Jika Anda menjalankan kluster VM spot, arsitek beban kerja untuk menahan beberapa pengeluaran simultan. Beberapa VM spot dalam beban kerja dapat dikeluarkan secara bersamaan. Pengeluaran simultan dari beberapa VM dapat memengaruhi throughput aplikasi. Untuk mencegah situasi ini, alur penyebaran Anda harus dapat mengumpulkan sinyal dari beberapa VM dan menyebarkan beberapa VM pengganti secara bersamaan.
Desain untuk pematian yang anggun
Proses matikan VM harus kurang dari 30 detik dan memungkinkan VM Anda dimatikan sebelum pengeluaran. Jumlah waktu yang harus dimatikan tergantung pada seberapa sering beban kerja Anda mengkueri titik akhir Peristiwa Terjadwal. Semakin sering Anda mengkueri titik akhir, semakin lama proses pematian dapat berlangsung. Proses matikan harus melepaskan sumber daya, mengosongkan koneksi, dan menghapus log peristiwa. Anda harus membuat dan menyimpan titik pemeriksaan secara teratur untuk mempertahankan konteks dan membangun strategi pemulihan yang lebih efisien. Titik pemeriksaan hanyalah informasi tentang proses atau transaksi apa yang perlu dimulai VM berikutnya. Mereka harus menunjukkan apakah VM harus dilanjutkan di mana VM sebelumnya pergi atau jika VM baru harus mengembalikan perubahan dan memulai seluruh proses lagi. Simpan titik pemeriksaan di luar lingkungan VM spot, seperti di akun penyimpanan.
Menguji orkestrasi
Simulasikan peristiwa pengeluaran untuk menguji orkestrasi di lingkungan dev/test. Untuk informasi selengkapnya, lihat Simulasikanpengeluaran .
Merancang beban kerja idempogen
Kami menyarankan agar Anda merancang beban kerja yang idempotensi. Hasil pemrosesan peristiwa lebih dari satu kali harus sama dengan memprosesnya sekali. Pengeluaran dapat mengakibatkan pematian paksa, meskipun ada upaya untuk memastikan pematian yang lancar. Pematian paksa dapat mengakhiri proses sebelum selesai. Beban kerja idempotensi dapat menerima pesan yang sama lebih dari satu kali tanpa mengubah hasilnya. Untuk informasi selengkapnya, lihat Idempotency.
Menggunakan periode pemanasan aplikasi
Sebagian besar beban kerja yang dapat diinterupsi menjalankan aplikasi. Aplikasi membutuhkan waktu untuk menginstal dan memulai. Mereka juga membutuhkan waktu untuk terhubung ke penyimpanan eksternal dan mengumpulkan informasi dari titik pemeriksaan. Memiliki periode pemanasan aplikasi sebelum Anda mengizinkannya untuk mulai memproses. Selama periode pemanasan, aplikasi harus memulai, membangun koneksi, dan bersiap untuk berkontribusi. Hanya izinkan aplikasi untuk mulai memproses data setelah Anda memvalidasi kesehatan aplikasi.
Mengonfigurasi identitas terkelola yang ditetapkan pengguna
Tetapkan identitas terkelola yang ditetapkan pengguna untuk menyederhanakan proses autentikasi dan otorisasi. Identitas terkelola yang ditetapkan pengguna memungkinkan Anda menghindari memasukkan kredensial dalam kode dan tidak terkait dengan satu sumber daya seperti identitas terkelola yang ditetapkan sistem. Identitas terkelola yang ditetapkan pengguna berisi izin dan token akses dari ID Microsoft Entra yang dapat digunakan kembali dan ditetapkan untuk melihat VM selama orkestrasi. Konsistensi token di seluruh VM spot membantu menyederhanakan orkestrasi dan menyederhanakan akses ke sumber daya beban kerja yang dimiliki VM spot.
Jika Anda menggunakan identitas terkelola yang ditetapkan sistem, VM spot baru mungkin mendapatkan token akses yang berbeda dari ID Microsoft Entra. Jika Anda perlu menggunakan identitas terkelola yang ditetapkan sistem, buat beban kerja tahan terhadap respons 403 Forbidden Error
. Orkestrasi Anda perlu mendapatkan token dari ID Microsoft Entra dengan izin yang tepat. Untuk informasi selengkapnya, lihat identitas terkelola .
Contoh skenario
Skenario contoh menyebarkan aplikasi pemrosesan antrean yang memenuhi syarat sebagai beban kerja yang dapat diinterupsi. Skrip dalam skenario berfungsi sebagai contoh. Skenario ini memandu Anda melalui dorongan manual satu kali untuk menyebarkan sumber daya. Implementasi ini tidak memiliki alur penyebaran. Namun, alur penyebaran sangat penting untuk mengotomatiskan proses orkestra. Diagram berikut menunjukkan arsitektur skenario contoh.
Unduh file Visio arsitektur ini.
Alur kerja berikut ini sesuai dengan diagram sebelumnya:
definisi aplikasi VM: Definisi aplikasi VM dibuat di galeri komputasi Azure. Ini mendefinisikan nama aplikasi, lokasi, sistem operasi, dan metadata. Versi aplikasi adalah versi bernomor dari definisi aplikasi VM. Versi aplikasi mewakili aplikasi VM. Ini harus berada di wilayah yang sama dengan VM spot. Versi aplikasi menautkan ke paket aplikasi sumber di akun penyimpanan.
Akun penyimpanan: Akun penyimpanan menyimpan paket aplikasi sumber. Dalam arsitektur ini, ini adalah file tar terkompresi bernama
worker-0.1.0.tar.gz
. Ini berisi dua file. Satu file adalah skrip bashorchestrate.sh
yang menginstal aplikasi pekerja .NET.Spot VM: VM spot disebarkan. Ini harus berada di wilayah yang sama dengan versi aplikasi. Ini mengunduh
worker-0.1.0.tar.gz
ke VM setelah penyebaran. Templat bicep menyebarkan gambar Ubuntu pada VM keluarga standar. Konfigurasi ini memenuhi kebutuhan aplikasi ini dan bukan rekomendasi umum untuk aplikasi Anda.Antrean Penyimpanan: Layanan lain yang berjalan di pekerja .NET berisi logika antrean pesan. MICROSOFT Entra ID memberikan akses VM spot ke antrean penyimpanan di Azure Queue Storage dengan identitas yang ditetapkan pengguna dengan menggunakan kontrol akses berbasis peran.
aplikasi pekerja .NET: Skrip
orchestrate.sh
menginstal aplikasi pekerja .NET yang menjalankan dua layanan latar belakang. Layanan pertama meminta titik akhir Peristiwa Terjadwal, mencari sinyalPreempt
, dan mengirim sinyal ini ke layanan kedua. Layanan kedua memproses pesan dari antrean penyimpanan dan mendengarkan sinyalPreempt
dari layanan pertama. Ketika layanan kedua menerima sinyal, layanan tersebut mengganggu pemrosesan antrean penyimpanan dan mulai dimatikan.Titik akhir Peristiwa Terjadwal Kueri: Permintaan API dikirim ke alamat IP statis yang tidak dapat dialihkan
169.254.169.254
. Permintaan API meminta titik akhir Peristiwa Terjadwal untuk sinyal pemeliharaan infrastruktur.Application Insights: Arsitektur menggunakan Application Insights hanya untuk tujuan pembelajaran. Ini bukan komponen penting dari orkestrasi beban kerja yang dapat diinterupsi, tetapi memungkinkan Anda untuk memvalidasi telemetri dari aplikasi pekerja .NET. Aplikasi pekerja .NET mengirimkan telemetri ke Application Insights. Untuk informasi selengkapnya, lihat Mengaktifkan metrik langsung dari aplikasi .NET.
Sebarkan skenario ini
Ada repositori GitHub yang disebut beban kerja yang dapat diinterupsi di spot yang memiliki templat, skrip, dan instruksi langkah demi langkah untuk menyebarkan arsitektur ini.