Dalam artikel ini, kami menguraikan praktik terbaik untuk membangun komputer virtual (VM) spot Azure dan menyertakan skenario contoh yang dapat disebarkan. VM Spot menyediakan akses ke kapasitas komputasi dengan diskon signifikan ke VM reguler. Diskon ini menjadikan mereka solusi yang menarik bagi organisasi yang ingin mengoptimalkan biaya, tetapi penghematannya dilengkapi dengan kondisi. VM spot dapat kehilangan akses ke komputasi kapan saja. Kami menyebut proses ini sebagai pengeluaran. Beban kerja yang berjalan di VM spot harus dapat menangani gangguan ini dalam komputasi. Beban kerja yang tepat dan mekanisme orkestrasi yang fleksibel adalah kunci keberhasilan. Berikut adalah rekomendasi kami untuk membangun VM lokal.
Memahami komputer virtual spot
Pada tingkat teknis, VM spot sama dengan VM biasa. Mereka menggunakan gambar, perangkat keras, dan disk yang sama yang diterjemahkan ke performa yang sama. Perbedaan antara VM spot dan reguler turun ke prioritas dan ketersediaan. VM spot tidak memiliki prioritas untuk mengakses kapasitas komputasi, dan mereka tidak memiliki jaminan ketersediaan setelah mengakses kapasitas komputasi tersebut. Mari kita bahas prioritas dan ketersediaan secara lebih rinci.
Tidak ada akses prioritas. VM reguler memiliki akses prioritas ke kapasitas komputasi. Mereka mengakses kapasitas komputasi setiap kali mereka memintanya. Spot VM, di sisi lain, hanya menyebarkan ketika ada kapasitas komputasi cadangan, dan mereka hanya tetap berjalan ketika VM biasa tidak memerlukan perangkat keras yang mendasar.
Tidak ada jaminan ketersediaan. VM spot tidak memiliki jaminan ketersediaan apa pun. Mereka tidak memiliki perjanjian tingkat layanan (SLA). VM spot dapat kehilangan akses ke kapasitas komputasi segera atau kapan saja setelah penyebaran (pengeluaran). Spot VM lebih murah karena kemungkinan pengeluaran. Setiap kali 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 memantau pengeluaran dalam artikel ini.
Memahami harga komputer virtual spot
VM spot bisa hingga 90 persen lebih murah daripada VM reguler (bayar sesuai pemakaian). Diskon bervariasi berdasarkan permintaan, ukuran VM, wilayah penyebaran, dan sistem operasi. Kami sarankan Anda menggunakan alat harga Azure Spot VM untuk mendapatkan perkiraan penghematan biaya. Untuk informasi selengkapnya, lihat:
Anda juga dapat mengkueri API harga ritel Azure untuk mendapatkan harga spot secara terprogram untuk setiap SKU yang menarik.
Memahami beban kerja yang dapat diinterupsi
Beban kerja yang dapat diinterupsi adalah kasus penggunaan terbaik untuk VM spot. Beban kerja yang dapat diinterupsi memiliki beberapa karakteristik umum. Mereka memiliki batasan minimal hingga tidak ada waktu, prioritas organisasi yang rendah, dan waktu pemrosesan 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 agen penyebaran berkelanjutan integrasi berkelanjutan untuk lingkungan non-produksi. Fitur-fitur ini berbeda dengan beban kerja reguler atau penting misi yang memiliki perjanjian tingkat layanan (SLA), sesi lekat, dan data stateful. Tabel menyediakan contoh untuk kedua jenis beban kerja.
| Fitur beban kerja yang dapat diinterupsi | Fitur beban kerja reguler | |
|---|---|---|
| Fitur | Batasan minimal hingga tidak ada waktu Prioritas organisasi rendah Waktu pemrosesan singkat |
Perjanjian tingkat layanan (SLA) Persyaratan sesi tempel Beban kerja berstatus |
Anda dapat menggunakan VM spot dalam beban kerja yang tidak dapat diinterupsi, tetapi seharusnya tidak menjadi satu sumber kapasitas komputasi. Gunakan VM reguler sebanyak yang Anda butuhkan untuk memenuhi persyaratan waktu aktif Anda.
Memahami pengeluaran
VM spot tidak memiliki perjanjian tingkat layanan (SLA) setelah dibuat dan dapat kehilangan akses ke komputasi kapan saja. Kami menyebutnya kehilangan komputasi ini sebagai 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. Peningkatan permintaan di wilayah A tidak akan memengaruhi VM spot di wilayah B.
Spot VM memiliki dua opsi konfigurasi yang memengaruhi pengeluaran. Konfigurasi ini adalah "jenis pengeluaran" dan "kebijakan pengeluaran" dari VM spot. Anda mengatur konfigurasi ini saat membuat VM spot. "Jenis pengeluaran" mendefinisikan kondisi pengeluaran. "Kebijakan pengeluaran" menentukan apa yang dilakukan pengeluaran ke VM spot Anda. Mari kita atasi kedua pilihan konfigurasi.
Jenis pengeluaran
Pengeluaran disebabkan oleh perubahan kapasitas atau perubahan harga. Cara ini memengaruhi VM spot tergantung pada jenis pengeluaran yang dipilih saat VM dibuat. Jenis pengeluaran mendefinisikan kondisi pengeluaran. Jenis pengeluaran adalah "pengeluaran hanya kapasitas" dan "pengeluaran harga atau kapasitas".
Pengeluaran kapasitas saja: Jenis pengeluaran ini memicu pengeluaran ketika kapasitas komputasi berlebih hilang. Secara default, harga dibatasi pada tarif bayar sesuai penggunaan. Gunakan jenis pengeluaran ini ketika Anda bersedia membayar hingga harga VM bayar sesuai pemakaian.
Pengeluaran harga atau kapasitas: Jenis pengeluaran ini memiliki dua pemicu. Azure mengeluarkan VM spot ketika kapasitas komputasi berlebih hilang atau biaya VM melebihi harga maksimum yang Anda tetapkan. Jenis pengeluaran ini memungkinkan Anda untuk menetapkan harga maksimum di bawah harga bayar sesuai penggunaan. Gunakan jenis pengeluaran ini untuk mengatur batas harga Anda sendiri.
Kebijakan pengeluaran
Kebijakan pengeluaran yang dipilih untuk VM spot memengaruhi orkestrasinya. Dengan orkestrasi, kita berarti proses penanganan pengeluaran. Kami membahas orkestrasi secara rinci nanti. Kebijakan pengeluaran adalah "Kebijakan Berhenti/Batalkan Alokasi" dan "Hapus kebijakan".
Kebijakan Hentikan/Batalkan alokasi: Kebijakan pengeluaran Berhenti/Batalkan alokasi adalah yang terbaik 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. Dengan kebijakan Stop/Deallocate, VM kehilangan kapasitas komputasi dan alamat IP non-statis. Namun, disk data VM tetap ada dan masih dikenakan biaya. VM juga menempati inti dalam langganan. VM tidak dapat dipindahkan dari wilayah atau zonanya bahkan ketika dihentikan/dibatalkan alokasinya. Untuk informasi selengkapnya, lihat status daya dan penagihan VM.
Hapus kebijakan: Gunakan "Hapus kebijakan" jika beban kerja dapat mengubah lokasi atau ukuran VM. Mengubah lokasi dan/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 tentang kebijakan pengeluaran, lihat kebijakan pengeluaran.
Desain untuk orkestrasi fleksibel
Orkestrasi adalah proses mengganti VM spot setelah pengeluaran. Ini adalah fondasi membangun beban kerja yang dapat diinterupsi dengan andal. Sistem orkestrasi yang baik memiliki fleksibilitas bawaan. Secara fleksibilitas, kami berarti merancang orkestrasi Anda untuk memiliki opsi, menggunakan beberapa ukuran VM, menyebarkan ke berbagai wilayah, mengetahui pengeluaran, dan memperhitungkan skenario pengeluaran yang berbeda untuk meningkatkan keandalan dan kecepatan beban kerja.
Di bawah ini kami telah menguraikan rekomendasi untuk membantu Anda merancang orkestrasi fleksibel untuk beban kerja anda yang dapat diinterupsi.
Desain untuk kecepatan
Untuk beban kerja yang berjalan di VM spot, kapasitas komputasi adalah harta karun. Potensi pengeluaran yang segera harus meningkatkan apresiasi Anda atas waktu komputasi yang dialokasikan dan harus diterjemahkan ke keputusan desain yang bermakna yang memprioritaskan kecepatan beban kerja. Secara umum, sebaiknya optimalkan waktu komputasi yang Anda miliki. Anda harus membangun gambar VM dengan semua perangkat lunak yang diperlukan yang telah diinstal sebelumnya. Perangkat lunak yang telah diinstal sebelumnya akan membantu meminimalkan waktu antara pengeluaran dan aplikasi yang berjalan sepenuhnya. Anda ingin menghindari penggunaan waktu komputasi pada proses yang tidak berkontribusi pada tujuan beban kerja. Beban kerja untuk analitik data, misalnya, harus memfokuskan sebagian besar waktu komputasi pada pemrosesan data dan sesedikitan mungkin pada pengumpulan metadata pengeluaran. Hilangkan proses yang tidak penting dari aplikasi Anda.
Menggunakan beberapa ukuran dan lokasi VM
Sebaiknya bangun orkestrasi untuk menggunakan beberapa jenis dan ukuran VM untuk meningkatkan fleksibilitas. 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 sama. Anda harus memfilter VM min vCPU/Cores dan/atau min RAM, dan harga maksimum untuk menemukan beberapa VM yang memiliki kekuatan untuk menjalankan beban kerja Anda dan sesuai dengan anggaran Anda. Setiap jenis VM memiliki tingkat pengeluaran yang dinyatakan sebagai rentang persentase (0-5%, 5-10%, 10-15%, 15-20%, 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". Pilih tautan "Ukuran" ("Lihat riwayat harga" atau "Lihat semua ukuran"). Anda juga dapat secara terprogram mendapatkan data VM spot menggunakan Azure Resource Graph. Untuk informasi selengkapnya, lihat:
Menggunakan kebijakan pengeluaran yang paling fleksibel
Kebijakan pengeluaran VM spot yang dikeluarkan memengaruhi proses penggantian. Kebijakan penghapusan lebih fleksibel daripada kebijakan pengeluaran yang dihentikan/dibatalkan alokasinya.
Pertimbangkan kebijakan penghapusan terlebih dahulu: Sebaiknya gunakan kebijakan penghapusan 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/dibatalkan alokasinya. VM yang dihentikan/dibatalkan alokasinya harus menunggu kapasitas komputasi cadangan di zona yang sama tempat VM dibuat. Untuk kebijakan penghapusan, Anda memerlukan proses untuk memantau pengeluaran yang berada di luar aplikasi dan mengatur penyebaran ke wilayah yang berbeda dan/atau dengan SKU VM yang berbeda.
Pahami kebijakan yang dihentikan/dibatalkan alokasinya: Kebijakan yang dihentikan/dibatalkan alokasinya memiliki lebih sedikit fleksibilitas daripada kebijakan penghapusan. VM spot harus tetap berada di wilayah dan zona yang sama. Anda tidak dapat memindahkan VM yang dihentikan/dibatalkan alokasinya ke lokasi lain. Karena VM memiliki lokasi tetap, Anda akan memerlukan sesuatu untuk merealokasi VM ketika kapasitas komputasi tersedia. Tidak ada cara untuk memprediksi kapan kapasitas komputasi akan tersedia. Jadi sebaiknya gunakan 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 | |
|---|---|---|
| Hapus | Komputasi dan data Ephemeral Tidak ingin membayar disk data Anggaran minimal |
|
| Dihentikan/Dibatalkan Alokasinya | 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. Dengan informasi ini, Anda dapat mencoba penonaktifan beban kerja yang anggun dan memicu otomatisasi yang mengatur penggantian.
Gunakan Peristiwa Terjadwal: Sebaiknya gunakan layanan Peristiwa Terjadwal untuk setiap VM. Azure mengirimkan sinyal ke VM saat akan dipengaruhi oleh pemeliharaan infrastruktur. Pengeluaran memenuhi syarat sebagai pemeliharaan infrastruktur. Azure mengirimkan Preempt sinyal ke semua VM minimal 30 detik sebelum dikeluarkan. Layanan bernama Peristiwa Jadwal memungkinkan Anda mengambil sinyal ini Preempt dengan mengkueri titik akhir di alamat 169.254.169.254IP statis yang tidak dapat dirutekan .
Gunakan kueri yang sering: Sebaiknya kueri titik akhir Peristiwa Jadwal 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 akan menggunakan kapasitas komputasi VM dan mencuri daya pemrosesan dari beban kerja utama. Anda harus menyeimbangkan prioritas bersaing tersebut untuk memenuhi situasi spesifik Anda.
Mengotomatiskan orkestrasi: Setelah Anda mengumpulkan sinyal, orkestrasi Anda harus bertindak berdasarkan sinyal tersebut Preempt . Mengingat batasan waktu, Preempt sinyal harus mencoba mematikan beban kerja Anda dengan anggun dan memulai proses otomatis yang menggantikan VM spot. Untuk informasi selengkapnya, lihat:
Membangun sistem penyebaran
Orkestrasi Anda memerlukan alur otomatis untuk menyebarkan VM spot baru saat dikeluarkan. Alur harus berjalan di luar beban kerja yang dapat diinterupsi itu sendiri untuk memastikan permanen. Cara kerja alur penyebaran tergantung pada kebijakan pengeluaran yang Anda pilih untuk VM spot Anda.
Untuk kebijakan penghapusan, sebaiknya buat alur yang menggunakan ukuran VM dan penyebaran yang berbeda ke wilayah yang berbeda. Untuk kebijakan berhenti/batal dialokasikan, alur penyebaran akan 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 Azure Functions adalah salah satu dari beberapa 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
Ada kemungkinan bahwa VM spot Anda akan ditunjuk untuk pengeluaran segera setelah dibuat dan bahkan sebelum beban kerja Anda dijalankan. Hanya karena ada kapasitas untuk membuat VM spot, tidak berarti itu akan bertahan. VM spot tidak memiliki jaminan ketersediaan (SLA) setelah pembuatan. Orkestrasi Anda perlu memperhitungkan pengeluaran segera. Sinyal Preempt masih akan memberikan pemberitahuan minimal 30 detik sebelumnya tentang pengeluaran.
Sebaiknya masukkan pemeriksaan kesehatan VM ke dalam orkestrasi Anda untuk mempersiapkan pengeluaran segera. Orkestrasi untuk pengeluaran segera tidak dapat mengandalkan sinyal Peristiwa Preempt Jadwal. Hanya VM itu sendiri yang dapat mengkueri Preempt sinyal, dan tidak ada cukup waktu untuk memulai aplikasi, mengkueri titik akhir Peristiwa Jadwal, dan mematikan dengan baik. Jadi pemeriksaan kesehatan perlu berada di luar lingkungan beban kerja. Pemeriksaan kesehatan perlu mengawasi status VM spot dan memulai alur penyebaran untuk mengganti VM spot ketika status berubah menjadi batal dialokasikan atau dihentikan.
Merencanakan beberapa pengeluaran simultan
Jika Anda menjalankan kluster VM spot, Anda harus merancang 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 menghindari 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 matikan. Proses matikan harus melepaskan sumber daya, mengosongkan koneksi, dan menghapus log peristiwa. Anda harus secara teratur membuat dan menyimpan titik pemeriksaan untuk menyimpan 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 ditinggalkan atau jika VM baru harus mengembalikan perubahan dan memulai seluruh proses lagi. Anda harus menyimpan titik pemeriksaan di luar lingkungan VM spot. Akun penyimpanan akan berfungsi.
Menguji orkestrasi
Sebaiknya simulasikan peristiwa pengeluaran untuk menguji orkestrasi di lingkungan dev/test. Untuk informasi selengkapnya, lihat mensimulasikan pengeluaran.
Merancang beban kerja idempogen
Sebaiknya rancang beban kerja yang idempotensi. Hasil pemrosesan peristiwa lebih dari sekali harus sama dengan memprosesnya sekali. Pengeluaran dapat menyebabkan 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 sekali dan hasilnya tetap sama. Untuk informasi selengkapnya, lihat idempotensi.
Menggunakan periode pemanasan aplikasi
Sebagian besar beban kerja yang dapat diinterupsi menjalankan aplikasi. Aplikasi membutuhkan waktu untuk menginstal dan waktu untuk boot. Mereka membutuhkan waktu untuk menyambungkan ke penyimpanan eksternal dan mengumpulkan informasi dari titik pemeriksaan. Sebaiknya lakukan periode pemanasan aplikasi sebelum mengizinkannya untuk mulai memproses. Selama periode pemanasan, aplikasi harus melakukan booting, menghubungkan, dan bersiap untuk berkontribusi. Anda seharusnya hanya mengizinkan aplikasi untuk mulai memproses data setelah memvalidasi kesehatan aplikasi.
Mengonfigurasi identitas terkelola yang ditetapkan pengguna
Sebaiknya gunakan identitas terkelola yang ditetapkan pengguna untuk menyederhanakan proses autentikasi dan otorisasi. Identitas terkelola yang ditetapkan pengguna memungkinkan untuk 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 akses ke sumber daya beban kerja yang dimiliki VM spot.
Dengan 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, sebaiknya buat beban kerja tahan terhadap 403 Forbidden Error respons. Orkestrasi Anda harus 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 ilustrasi. Skenario ini memancang Anda melalui pendorongan manual satu kali untuk menyebarkan sumber daya. Kami belum menyediakan alur penyebaran dengan implementasi ini. Tetapi alur penyebaran sangat penting untuk mengotomatiskan proses orkestra. Diagram mengilustrasikan arsitektur skenario contoh.
Catatan berikut menjelaskan aspek utama arsitektur:
- Definisi aplikasi VM: Definisi aplikasi VM dibuat di Azure Compute Gallery. Ini mendefinisikan nama aplikasi, lokasi, sistem operasi, dan metadata. Versi aplikasi adalah versi bernomor dari definisi aplikasi VM. Versi aplikasi adalah instans dari 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 adalahorchestrate.shskrip bash 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.gzke 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 dengan identitas yang ditetapkan pengguna menggunakan RBAC.
- Aplikasi pekerja .Net: Skrip orchestrate.sh menginstal aplikasi pekerja .NET yang menjalankan dua layanan latar belakang. Layanan pertama meminta titik akhir Peristiwa Jadwal dan mencari
Preemptsinyal dan mengirim sinyal ini ke layanan kedua. Layanan kedua memproses pesan dari antrean penyimpanan dan mendengarkanPreemptsinyal 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 dirutekan 169.254.169.254. Permintaan API meminta titik akhir Peristiwa Terjadwal untuk sinyal pemeliharaan infrastruktur.
- Application Insights: Arsitektur hanya menggunakan Application Insights untuk tujuan pembelajaran. Ini bukan komponen penting dari orkestrasi beban kerja yang dapat diinterupsi. Kami telah menyertakannya sebagai cara bagi Anda untuk memvalidasi telemetri dari aplikasi pekerja .NET. Kami telah mengonfigurasi aplikasi pekerja .NET untuk mengirim telemetri ke Application Insights. Untuk informasi selengkapnya, lihat mengaktifkan metrik langsung dari aplikasi .NET.
Menyebarkan skenario ini
Kami membuat repositori GitHub yang disebut beban kerja yang dapat diinterupsi di tempat dengan templat, skrip, dan instruksi langkah demi langkah untuk menyebarkan arsitektur ini. Anda akan menemukan detail teknis selengkapnya tentang arsitektur dan artefak rekayasa di repositori ini.
Langkah selanjutnya
Untuk informasi selengkapnya tentang Spot Virtual Machines, lihat Azure Spot Virtual Machines.