Pemeliharaan untuk mesin virtual di Azure

Berlaku untuk: ✔️ Mesin virtual Linux ✔️ Mesin virtual Windows ✔️ Set skala fleksibel ✔️ Set skala seragam

Azure secara berkala memperbarui platformnya untuk meningkatkan keandalan, performa, dan keamanan infrastruktur host untuk mesin virtual. Tujuan pembaruan ini mulai dari mem-patch komponen perangkat lunak di lingkungan hosting hingga meningkatkan komponen jaringan atau menonaktifkan perangkat keras.

Pembaruan jarang memengaruhi VM yang dihosting. Saat pembaruan berpengaruh, Azure memilih metode berdampak paling minimum untuk pembaruan:

• Jika pembaruan tidak memerlukan reboot, VM dijeda saat host diperbarui, atau VM dimigrasikan langsung ke host yang sudah diperbarui.
• Jika pemeliharaan memerlukan boot ulang, Anda akan diberitahu tentang pemeliharaan terencana. Azure juga menyediakan jendela waktu yang dapat Anda gunakan untuk memulai pemeliharaan mandiri, pada waktu yang sesuai untuk Anda. Jendela pemeliharaan mandiri biasanya 35 hari (untuk mesin Host) kecuali jika pemeliharaannya mendesak. Azure berinvestasi dalam teknologi untuk mengurangi jumlah kasus pemeliharaan platform terencana mengharuskan VM untuk di-boot ulang. Untuk instruksi tentang mengelola pemeliharaan terencana, lihat Menangani pemberitahuan pemeliharaan terencana menggunakan Azure CLI, PowerShell, atau portal.

Halaman ini menjelaskan cara Azure melakukan kedua jenis pemeliharaan. Untuk informasi selengkapnya tentang kejadian yang tidak direncanakan (ketidaktersediaan), lihat Mengelola ketersediaan VM untuk Windows atau artikel terkait untuk Linux.

Dalam VM, Anda bisa mendapatkan pemberitahuan tentang pemeliharaan yang akan datang dengan menggunakan Kejadian Terjadwal untuk Windows atau untuk Linux.

Pemeliharaan yang tidak memerlukan boot ulang

Sebagian besar pembaruan platform tidak memengaruhi VM pelanggan. Saat pembaruan tanpa dampak tidak dimungkinkan, Azure memilih mekanisme pembaruan yang paling tidak berdampak pada VM pelanggan.

Ketika pemeliharaan yang berdampak pada VM diperlukan, hal tersebut hampir selalu dilakukan melalui jeda VM selama kurang dari 10 detik. Dalam keadaan yang jarang terjadi, tidak lebih dari sekali setiap 18 bulan untuk ukuran VM tujuan umum, Azure menggunakan mekanisme yang akan menjeda VM selama sekitar 30 detik. Setelah operasi jeda, jam VM secara otomatis disinkronkan saat dilanjutkan.

Pemeliharaan yang mempertahankan memori berfungsi untuk lebih dari 90 persen VM Azure. Ini tidak berfungsi untuk seri G, L, N, dan H. Untuk informasi selengkapnya, lihat ukuran VM mana yang mendukung pemeliharaan yang mempertahankan memori. Azure semakin menggunakan teknologi migrasi langsung dan meningkatkan mekanisme pemeliharaan yang mempertahankan memori untuk mengurangi durasi jeda.

Operasi pemeliharaan ini yang tidak memerlukan boot ulang diterapkan pada satu domain kesalahan pada satu waktu. Mereka akan berhenti jika menerima sinyal peringatan terkait kesehatan dari alat pemantauan platform. Operasi pemeliharaan yang tidak memerlukan boot ulang dapat terjadi secara bersamaan di wilayah atau Zona Ketersediaan yang telah berkaitan. Untuk perubahan tertentu, deployment biasanya dilakukan secara berurutan antar Availability Zone dan antar pasangan Region, tetapi dapat terjadi tumpang tindih pada tahap akhir.

Jenis pembaruan ini dapat memengaruhi beberapa aplikasi. Ketika VM dimigrasikan langsung ke host yang berbeda, beberapa beban kerja sensitif mungkin menunjukkan sedikit penurunan performa dalam beberapa menit menjelang jeda VM. Untuk mempersiapkan pemeliharaan VM dan mengurangi dampak selama pemeliharaan Azure, cobalah menggunakan Kejadian Terjadwal untuk Windows atau Linux untuk aplikasi tersebut.

Untuk kontrol yang lebih besar pada semua aktivitas pemeliharaan termasuk pembaruan tanpa dampak dan tanpa booting ulang, Anda dapat membuat fitur Konfigurasi Pemeliharaan. Membuat Konfigurasi Pemeliharaan memberi Anda opsi untuk melewati semua pembaruan platform dan menerapkan pembaruan sesuai waktu pilihan Anda. Untuk informasi selengkapnya, lihat Mengelola pembaruan platform dengan Konfigurasi Pemeliharaan.

Migrasi langsung

Migrasi langsung adalah operasi yang tidak memerlukan boot ulang dan yang mempertahankan memori untuk VM. Ini menyebabkan jeda atau pembekuan, yang biasanya berlangsung tidak lebih dari 5 detik. Kecuali untuk seri G, L, N, dan H, semua VM infrastruktur sebagai layanan (IaaS), memenuhi syarat untuk migrasi langsung. Migrasi langsung tersedia pada sebagian besar SKU Seri M. VM yang memenuhi syarat mewakili lebih dari 90 persen VM IaaS yang disebarkan ke armada Azure.

Catatan

Anda tidak akan menerima pemberitahuan di portal Microsoft Azure untuk operasi migrasi langsung yang dicoba atau tidak memerlukan boot ulang. Untuk melihat daftar migrasi live yang tidak memerlukan mulai ulang, jalankan kueri untuk peristiwa terjadwal.

Migrasi langsung dilakukan berdasarkan upaya terbaik. Dalam beberapa kasus yang jarang terjadi, migrasi langsung mungkin tidak berhasil dan VM akan dijadwalkan untuk pemulihan layanan, jika diperlukan, sebelum pemberitahuan. Migrasi langsung bukan operasi yang dijamin.

Platform Azure memicu migrasi langsung dalam skenario berikut:

• Pemeliharaan terencana
• Kegagalan perangkat keras
• Pengoptimalan alokasi

Beberapa skenario pemeliharaan terencana menggunakan migrasi langsung, dan Anda dapat menggunakan Kejadian Terjadwal untuk mengetahui terlebih dahulu kapan operasi migrasi langsung akan dimulai.

Migrasi langsung juga dapat digunakan untuk memindahkan VM saat algoritma Azure Machine Learning memprediksi kegagalan perangkat keras yang akan datang atau pengoptimalan alokasi VM. Untuk informasi selengkapnya tentang pemodelan prediktif yang mendeteksi instans perangkat keras yang terdegradasi, lihat Meningkatkan ketahanan VM Azure dengan pembelajaran mesin prediktif dan migrasi langsung. Pemberitahuan migrasi langsung muncul di portal Microsoft Azure di log Kesehatan Monitor dan Layanan serta di Kejadian Terjadwal jika Anda menggunakan layanan ini.

Ketahanan koneksi TCP selama migrasi langsung

Aplikasi yang mempertahankan koneksi TCP berumur lama, seperti server database, broker pesan, dan lapisan cache, dapat mengalami gangguan koneksi selama migrasi live. Meskipun jeda VM biasanya di bawah 5 detik, perilaku tumpukan TCP selama dan setelah jeda dapat memperpanjang waktu pemulihan tingkat aplikasi jika tidak ditangani.

Bagaimana migrasi langsung memengaruhi koneksi TCP:

• Selama jeda, segmen TCP dalam penerbangan tidak diakui oleh VM yang bermigrasi.
• Sisi pengiriman (pemeriksaan kesehatan klien atau load balancer) memulai transmisi ulang TCP dengan backoff eksponensial.
• Azure Standard Load Balancer mengirimkan RST TCP ke koneksi diam yang melebihi batas waktu diam yang dikonfigurasi. Namun, untuk koneksi aktif dengan data dalam penerbangan, load balancer tidak mengirim TCP RST selama jeda migrasi. Koneksi tetap terbuka tetapi tidak responsif, dan klien tidak memiliki sinyal kegagalan segera.
• Tanpa penyetelan tingkat aplikasi, perilaku transmisi ulang TCP default (tcp_retries2 = 15 di Linux) dapat menunda deteksi kegagalan koneksi sekitar 15 menit.

Important

Dampaknya bervariasi secara signifikan berdasarkan default sistem operasi. Pada Linux, tcp_retries2 secara default bernilai 15, sehingga diperlukan sekitar 15 menit sebelum koneksi yang terputus terdeteksi. Pada Windows, TcpMaxDataRetransmissions default ke 5, yang membatasi waktu deteksi menjadi sekitar 25-50 detik tanpa penyetelan apa pun. Mitigasi yang dijelaskan dalam artikel ini paling penting untuk beban kerja berbasis Linux.

Catatan

Untuk beban kerja HTTP/1.1, dampaknya biasanya terbatas: hanya permintaan dalam penerbangan saat migrasi terpengaruh, dan karena klien HTTP/1.1 tidak melakukan alur melalui koneksi tetap aktif, mereka pulih dengan cepat dengan membuka koneksi baru untuk permintaan berikutnya. Untuk HTTP/2, radius ledakan lebih lebar karena beberapa aliran bersamaan berbagi satu koneksi TCP.

Ketika load balancer beroperasi dalam mode passthrough L4 TLS, load balancer tidak dapat memeriksa, mencoba kembali, atau menyuntikkan respons kesalahan ke dalam aliran terenkripsi. Dalam konfigurasi ini, klien bertanggung jawab sepenuhnya untuk mendeteksi dan memulihkan dari koneksi yang terhenti.

Kurangi radius ledakan dengan penyebaran multi-instans:

Sebelum menerapkan mitigasi tingkat TCP, pertimbangkan garis besar arsitektur. Migrasi langsung hanya memengaruhi satu VM dalam satu waktu di dalam set ketersediaan atau kumpulan skala mesin virtual. Menyebarkan koneksi di beberapa instans backend membatasi dampak peristiwa migrasi tunggal apa pun:

• Kumpulan skala dengan tiga instans berarti bahwa setiap peristiwa migrasi memengaruhi paling banyak sepertiga dari koneksi aktif.
• Penerapan di seluruh Zona Ketersediaan memastikan migrasi antarzona tidak saling tumpang tindih.
• Klien dengan kumpulan koneksi yang didistribusikan di beberapa backend pulih lebih cepat karena koneksi yang tidak terpengaruh terus melayani permintaan segera.

Saat VM dijeda, probe kesehatan Azure Standard Load Balancer terhadap backend yang dijeda juga gagal. Penyeimbang beban menandai backend sebagai tidak sehat dalam waktu sekitar 10 detik (dua kegagalan probe berturut-turut pada interval default 5 detik) dan berhenti merutekan koneksi baru ke backend tersebut. Kondisi ini berarti koneksi baru dilindungi secara alami. Mitigasi TCP yang dijelaskan dalam artikel ini membahas koneksi yang sudah ada yang sudah dibuat sebelum migrasi dimulai.

Mitigasi yang direkomendasikan:

Mitigasi berikut ini saling melengkapi. Saat diimplementasikan bersama-sama, mereka mengurangi dampak peristiwa migrasi langsung dari menit waktu henti potensial ke detik pemulihan otomatis.

Prioritas	Mitigation	Usaha	Dampak
1	Atur TCP_USER_TIMEOUT pada tingkat soket	Low	Mengurangi deteksi koneksi mati dari ~15 menit menjadi 30 detik
2	Berlangganan Peristiwa Terjadwal	Medium	Memungkinkan pengosongan koneksi secara proaktif sebelum pembekuan terjadi
3	Sesuaikan parameter pertahanan koneksi TCP	Low	Mendeteksi koneksi tidak aktif yang menjadi kedaluwarsa setelah migrasi
4	Menerapkan logika percobaan ulang di sisi klien	Medium	Memberikan ketahanan terlepas dari akar penyebabnya

Mitigasi 1: TCP_USER_TIMEOUT (deteksi tercepat)

TCP_USER_TIMEOUT mengontrol berapa lama kernel menunggu pengakuan data yang dikirimkan sebelum menyatakan koneksi mati. Mengatur ini menjadi 30 detik (30000 md) per soket secara signifikan mengurangi waktu deteksi.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Atau, kurangi jumlah transmisi ulang di seluruh sistem:

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Tip

Atur TCP_USER_TIMEOUT pada tingkat SDK atau soket daripada di seluruh sistem. Nilai 30 detik adalah titik awal yang baik. Nilai di bawah 10 detik dapat menyebabkan hasil positif palsu saat jaringan mengalami jitter normal.

pertimbangan Windows:

Opsi TCP_USER_TIMEOUT soket khusus untuk Linux. Pada Windows, perilaku transmisi ulang TCP dikontrol secara berbeda:

• Windows secara bawaan menetapkan 5 kali pengiriman ulang (TcpMaxDataRetransmissions), yang sudah memberikan sekitar 25-50 detik waktu untuk mendeteksi tanpa penyesuaian apa pun.
• Untuk lebih mengurangi waktu deteksi pada Windows, sesuaikan registri:

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

Dengan TcpMaxDataRetransmissions diatur ke 3, waktu deteksi berkurang menjadi sekitar 10-20 detik tergantung pada batas waktu pengiriman ulang awal.

Catatan

Tidak seperti Linux, Windows tidak menyediakan padanan TCP_USER_TIMEOUT per soket. Pengaturan registri berlaku untuk semua koneksi TCP pada sistem. Untuk kontrol terperinci pada Windows, andalkan batas waktu tingkat aplikasi dan pemeriksaan kesehatan (Mitigasi 4).

Mitigasi 2: Peristiwa Terjadwal (pengurasan proaktif)

Layanan Peristiwa Terjadwal memberikan pemberitahuan terlebih dahulu sebelum migrasi langsung dimulai. Aplikasi dapat memantau event Freeze dan secara proaktif mengosongkan koneksi sebelum jeda terjadi.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Peristiwa migrasi langsung muncul sebagai:

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Saat sebuah peristiwa Freeze terdeteksi:

1. Berhenti menerima koneksi baru pada simpul yang terpengaruh.
2. Hentikan koneksi yang ada secara bertahap (beri sinyal kepada klien untuk menyambung kembali ke simpul lain).
3. Tunggu hingga operasi dalam penerbangan selesai dengan batas waktu terikat.
4. Secara opsional, konfirmasikan event dengan mengirimkan kembali EventId.

Catatan

Periode pemberitahuan sebelumnya biasanya 15 menit tetapi bisa sesingkat 30 detik dalam kasus yang jarang terjadi. Frekuensi polling satu kali per detik disarankan untuk beban kerja produksi.

Mitigasi 3: Penyetelan keepalive TCP

Pemeriksaan keepalive TCP mendeteksi koneksi yang menganggur setelah peristiwa migrasi:

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Dengan pengaturan ini, koneksi idle yang sudah usang terdeteksi dalam 60 detik (30 + 10 x 3). Pemeriksaan keepalive juga dihitung sebagai aktivitas untuk batas waktu diam Standard Load Balancer, mencegah load balancer kehabisan waktu koneksi diam secara independen.

Mitigasi 4: Logika percobaan ulang di sisi klien

Logika rekoneksi dan coba lagi tingkat aplikasi memastikan pemulihan terlepas dari metode deteksi kegagalan:

1. Mendeteksi kesalahan koneksi (batas waktu, RST, atau koneksi ditolak).
2. Tutup sambungan mati dan hapus dari kumpulan koneksi.
3. Buka koneksi baru ke node yang sama atau berbeda.
4. Ulangi operasi tersebut dengan backoff eksponensial.

Untuk SDK database dan kumpulan koneksi, aktifkan pemeriksaan kesehatan berkala (misalnya, ping ringan setiap 10-15 detik) untuk memvalidasi koneksi secara proaktif.

Konfigurasi kumpulan koneksi:

Kumpulan koneksi yang mempertahankan koneksi berumur panjang mendapat manfaat dari pengaturan masa pakai maksimum. Pengaturan ini memaksa daur ulang koneksi berkala, memastikan tidak ada satu koneksi pun yang mengakumulasi risiko tidak terbatas dari peristiwa migrasi di masa mendatang:

Teknologi Pool	Setting	Nilai yang Direkomendasikan
HikariCP (Java)	maxLifetime	1800000 (30 menit)
PgBouncer	server_lifetime	1800 (30 menit)
Pergi database/sql	SetConnMaxLifetime	30 * waktu. Menit
Node.js (pg Pool)	idleTimeoutMillis	30000 (penghapusan saat idle 30 detik; masa aktif maksimum memerlukan logika khusus)
.NET SqlConnection	String koneksi: Connection Lifetime	1800 (30 menit)

Mengatur masa pakai maksimum 30 menit berarti bahwa bahkan tanpa pemeriksaan kesehatan aktif, koneksi secara alami diganti sebelum mereka dapat mengakumulasi periode panjang keusangan yang tidak terdeteksi.

Pemantauan dan pengamatan:

Untuk mendeteksi dan mengukur dampak peristiwa migrasi langsung pada koneksi TCP, gunakan pendekatan berikut:

• Metrik ketersediaan VM Azure Monitor (Pratinjau): Turun menjadi 0 selama VM dijeda. Buat aturan peringatan pada VmAvailabilityMetric dengan ambang batas kurang dari 1 untuk mendeteksi kejadian migrasi.
• Log Aktivitas Peristiwa Terjadwal: Peristiwa migrasi langsung muncul di Log Aktivitas di bawah penyedia Microsoft.Compute dengan nama operasi Microsoft.Compute/virtualMachines/liveMigration/action atau sebagai peristiwa Freeze saat kueri dilakukan melalui Layanan Metadata.
• Tingkat kesalahan koneksi tingkat aplikasi: Pantau reset koneksi TCP, batas waktu, dan jumlah koneksi ulang dalam metrik aplikasi Anda. Lonjakan kesalahan koneksi yang berkorelasi dengan penurunan Ketersediaan VM mengonfirmasi dampak migrasi.
• Penghitung transmisi ulang TCP: Di Linux, pantau /proc/net/netstat bidang TCPTimeouts atau gunakan ss -ti untuk mengamati jumlah pengiriman ulang pada soket individual. Peningkatan retransmisi selama jendela pemeliharaan yang telah diketahui menunjukkan bahwa koneksi terdampak.

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

Menetapkan garis besar untuk metrik ini selama operasi normal membuatnya mudah untuk mengukur dampak peristiwa migrasi dan memvalidasi bahwa mitigasi Anda berfungsi seperti yang diharapkan.

Beban kerja dengan toleransi nol untuk gangguan migrasi langsung

Untuk beban kerja yang tidak dapat mentolerir gangguan apa pun dari migrasi langsung, pertimbangkan untuk menggunakan host khusus Azure dengan Konfigurasi Pemeliharaan. Dedicated Host memberi Anda kendali atas kapan pemeliharaan pada level host dilakukan, sehingga menghilangkan peristiwa live migration yang tidak terduga.

Pemeliharaan yang memerlukan boot ulang

Dalam kasus yang jarang terjadi dengan VM yang perlu di-boot ulang untuk pemeliharaan terencana, Anda akan diberi tahu terlebih dahulu. Pemeliharaan terencana memiliki dua fase: fase layanan mandiri dan fase pemeliharaan terjadwal.

Selama fase layanan mandiri, yang biasanya berlangsung empat minggu, Anda memulai pemeliharaan pada VM Anda. Sebagai bagian dari layanan mandiri, Anda dapat mengajukan kueri ke setiap VM untuk melihat statusnya dan hasil permintaan pemeliharaan terakhir Anda.

Catatan

Untuk seri VM yang tidak mendukung Migrasi Langsung, data disk lokal (sementara) dapat hilang selama peristiwa pemeliharaan. Lihat setiap seri VM individual untuk informasi dukungan Migrasi Langsung.

Ketika Anda memulai pemeliharaan layanan mandiri, VM Anda dipindahkan ke node yang sudah diperbarui. Karena VM disebarkan ulang, disk sementara hilang dan alamat IP dinamis publik yang terkait dengan antarmuka jaringan virtual diperbarui.

Operasi akan berhenti, VM tidak akan diperbarui, dan Anda akan mendapatkan opsi untuk mencoba kembali pemeliharaan layanan mandiri jika ada kesalahan yang muncul selama pemeliharaan layanan mandiri.

Ketika fase layanan mandiri berakhir, fase pemeliharaan terjadwal akan dimulai. Selama fase ini, Anda tetap dapat mengajukan kueri untuk fase pemeliharaan, tetapi Anda tidak dapat memulai pemeliharaan sendiri.

Untuk informasi selengkapnya tentang mengelola pemeliharaan yang memerlukan boot ulang, lihat Menangani pemberitahuan pemeliharaan terencana menggunakan Azure CLI, PowerShell, atau portal.

Pertimbangan ketersediaan selama pemeliharaan terjadwal

Jika Anda memutuskan untuk menunggu sampai fase pemeliharaan terjadwal, ada beberapa hal yang harus Anda pertimbangkan untuk mempertahankan ketersediaan tertinggi VM Anda.

Wilayah berpasangan

Setiap wilayah Azure dipasangkan dengan wilayah lain di sekitar geografis yang sama. Bersama-sama, kedua wilayah tersebut membentuk pasangan wilayah. Selama fase pemeliharaan terjadwal, Azure hanya memperbarui VM di satu wilayah dari pasangan wilayah. Misalnya, saat memperbarui VM di US Tengah Utara, Azure tidak memperbarui VM apa pun di US Tengah Selatan secara bersamaan. Namun, wilayah lain seperti Eropa Utara dapat berada di bawah pemeliharaan pada saat yang sama dengan US Timur. Memahami cara kerja pasangan wilayah dapat membantu Anda mendistribusikan VM Anda dengan lebih baik di seluruh wilayah. Untuk informasi selengkapnya, lihat pasangan wilayah Azure.

Zona ketersediaan

Zona Ketersediaan adalah lokasi fisik yang unik dalam wilayah Azure. Setiap zonanya terdiri dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Untuk memastikan ketahanan, ada minimal tiga zona terpisah di semua wilayah yang diaktifkan.

Zona ketersediaan adalah kombinasi dari domain kesalahan dan domain pembaruan. Jika Anda membuat tiga VM atau lebih di tiga zona dalam satu wilayah Azure, VM Anda akan didistribusikan secara efektif ke tiga domain kesalahan dan tiga domain pembaruan. Platform Azure mengenali distribusi ini di seluruh domain pembaruan untuk memastikan bahwa VM di zona yang berbeda tidak diperbarui pada saat yang sama.

Setiap pembaruan infrastruktur diluncurkan dari satu zona ke zona lainnya dalam satu wilayah. Namun, Anda dapat menjalankan penyebaran di Zona 1 dan menjalankan penyebaran yang berbeda di Zona 2 pada waktu yang sama. Penyebaran tidak diserialisasikan secara keseluruhan. Namun, satu deployment yang memerlukan reboot hanya diterapkan ke satu zona pada satu waktu untuk mengurangi risiko. Secara umum, jika memungkinkan pembaruan yang memerlukan boot ulang harus dihindari, dan Azure mencoba menggunakan Migrasi Langsung atau memberikan kontrol kepada pelanggan.

Kumpulan skala mesin virtual

Set skala mesin virtual dalam mode orkestrasi Fleksibel merupakan sumber daya komputasi Azure yang memungkinkan Anda menggabungkan skalabilitas set skala mesin virtual dalam mode orkestrasi Seragam dengan jaminan ketersediaan regional dari set ketersediaan.

Dengan orkestrasi Fleksibel, Anda dapat memilih apakah instans Anda tersebar di beberapa zona, atau tersebar di seluruh domain kesalahan dalam satu wilayah.

Set ketersediaan dan set skala seragam

Saat menerapkan beban kerja di VM Azure, Anda dapat membuat VM dalam set ketersediaan untuk memberikan ketersediaan tinggi pada aplikasi Anda. Dengan menggunakan set ketersediaan, Anda dapat memastikan bahwa selama kejadian ketidaktersediaan atau pemeliharaan yang memerlukan boot ulang, setidaknya ada satu VM yang tersedia.

Dalam satu set ketersediaan, masing-masing VM tersebar di hingga 20 domain pembaruan. Selama pemeliharaan terjadwal, hanya satu domain pembaruan yang diperbarui pada waktu tertentu. Domain pembaruan tidak selalu diperbarui secara berurutan.

Kumpulan skala mesin virtual dalam mode orkestrasi Uniform adalah sumber daya komputasi Azure yang dapat Anda gunakan untuk menerapkan dan mengelola kumpulan VM identik sebagai sumber daya tunggal. Kumpulan skala secara otomatis disebarkan di seluruh UD, layaknya VM dalam set ketersediaan. Seperti halnya set ketersediaan, saat Anda menggunakan set skala seragam, hanya satu UD yang diperbarui dalam satu waktu selama pemeliharaan terjadwal.

Untuk informasi selengkapnya tentang menyiapkan VM Anda untuk ketersediaan tinggi, lihat Mengelola ketersediaan VM Anda untuk Windows atau artikel terkait untuk Linux.

Langkah berikutnya

Untuk mengelola pemeliharaan terencana, gunakan Azure CLI, Azure PowerShell, atau portal.