Dokumen ini menjelaskan cara grup instance terkelola (MIG) menyediakan ketersediaan tinggi aplikasi Anda dengan memperbaiki VM yang gagal dan tidak responsif dalam grup.
MIG menjaga aplikasi Anda tetap aktif dan tersedia dengan mempertahankan jumlah VM yang berjalan dalam grup secara proaktif. Jika VM dalam grup tidak aktif, MIG akan memperbaiki VM dengan membuat ulang VM guna mengembalikan VM ke layanan dengan cara berikut:
- Otomatis memperbaiki VM yang gagal: Jika VM gagal atau dihapus oleh tindakan yang tidak dimulai oleh MIG, MIG akan otomatis memperbaiki VM yang gagal. Dalam dokumen ini, lihat Memperbaiki VM yang gagal secara otomatis.
- Memperbaiki VM berdasarkan health check aplikasi: Cara opsional untuk lebih meningkatkan ketersediaan tinggi dengan memperbaiki VM yang tidak responsif. Jika Anda mengonfigurasi health check berbasis aplikasi dan aplikasi Anda gagal melewati health check, MIG akan menandai VM tersebut sebagai tidak responsif dan memperbaikinya. Memperbaiki VM berdasarkan health check aplikasi juga disebut autohealing. Dalam dokumen ini, lihat Memperbaiki VM berdasarkan health check aplikasi.
Memperbaiki secara otomatis VM yang gagal
Jika VM dalam MIG gagal, MIG akan otomatis memperbaiki VM yang gagal dengan membuat ulang VM. VM bisa gagal karena alasan berikut:
- Penyebab tak terduga seperti kegagalan hardware.
- Tindakan yang tidak dimulai oleh MIG, seperti berikut:
- Preemption dari Spot VM.
- Peristiwa pemeliharaan infrastruktur saat instance VM tidak ditetapkan untuk migrasi langsung.
- Tindakan yang dilakukan langsung di VM menggunakan halaman konsol instance VM, perintah gcloud CLI
instances
, atauinstances
resource API. Misalnya, menghentikan VM dalam grup menggunakan metodeinstances.stop
atau perintahgcloud compute instances stop
akan memicu perbaikan.
Jika MIG sengaja menghentikan VM—misalnya, saat autoscaler menghapus VM—MIG tidak akan memperbaiki VM tersebut.
Memperbaiki VM berdasarkan health check aplikasi
Selain perbaikan otomatis pada VM yang gagal, Anda mungkin ingin memperbaiki VM jika aplikasi yang berjalan pada VM berhenti berfungsi, error, atau kehabisan memori. Untuk memastikan aplikasi merespons seperti yang diharapkan, Anda dapat mengonfigurasi health check berbasis aplikasi.
Health check berbasis aplikasi secara berkala memverifikasi bahwa aplikasi Anda di setiap VM di MIG merespons seperti yang diharapkan. Jika aplikasi pada VM tidak merespons, MIG akan menandai VM tersebut sebagai tidak responsif. MIG kemudian akan memperbaiki VM yang tidak responsif. Memperbaiki VM berdasarkan health check aplikasi disebut autohealing.
Untuk memastikan bahwa MIG tetap menjalankan subset VM-nya, grup tidak akan melakukan pemulihan otomatis semua VM-nya secara serentak. Hal ini berguna jika, misalnya, health check yang salah memicu perbaikan yang tidak perlu, aturan firewall yang salah dikonfigurasi mencegah health check memeriksa VM, atau ada masalah konektivitas jaringan atau infrastruktur yang salah mengidentifikasi VM yang sehat sebagai tidak responsif. Namun, jika MIG zona hanya memiliki satu VM, atau MIG regional hanya memiliki satu VM per zona, MIG akan melakukan autohealing pada VM ini saat tidak responsif.
Kebijakan auto-healing
Setiap MIG memiliki kebijakan autohealing, tempat Anda dapat mengonfigurasi health check dan juga menetapkan penundaan awal. Penundaan awal adalah waktu yang diperlukan VM baru untuk melakukan inisialisasi dan menjalankan skrip startup-nya. Timer penundaan awal dimulai saat MIG mengubah kolom currentAction
VM menjadi VERIFYING
. Selama periode penundaan awal VM, MIG mengabaikan health check yang gagal karena VM mungkin berada dalam proses startup. Tindakan ini mencegah MIG membuat ulang VM sebelum waktunya. Jika health check menerima respons yang responsif selama penundaan awal, ini menunjukkan bahwa proses startup telah selesai dan VM sudah siap.
Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi kebijakan autohealing, lihat Menyiapkan health check dan autohealing aplikasi.
Memantau perubahan status respons aplikasi
Jika telah mengonfigurasi health check berbasis aplikasi di MIG, Anda dapat memeriksa status respons setiap VM di MIG. Untuk mengetahui informasi selengkapnya, lihat Memeriksa apakah VM responsif atau tidak.
Anda juga dapat memantau perubahan status respons VM. Untuk mengetahui informasi selengkapnya, lihat Memantau perubahan status kondisi.
Harga
Saat Anda menyiapkan health check berbasis aplikasi, Compute Engine secara default akan menulis entri log setiap kali status kondisi instance terkelola berubah. Cloud Logging memberikan alokasi gratis per bulan. Setelah jumlahnya terlampaui, logging akan ditagih berdasarkan volume data. Untuk menghindari biaya, Anda dapat menonaktifkan log perubahan status respons.
Perilaku selama perbaikan
Bagian berikut menjelaskan perilaku selama perbaikan otomatis dan perbaikan berdasarkan health check aplikasi.
Info terbaru terkait perbaikan
Secara default, selama perbaikan, MIG membuat ulang VM menggunakan template instance asli yang digunakan untuk membuat VM. Misalnya, jika VM dibuat menggunakan instance-template-a
, lalu Anda mengupdate MIG untuk menggunakan instance-template-b
dalam mode OPPORTUNISTIC
, MIG masih menggunakan instance-template-a
untuk membuat ulang VM.
Jika ingin MIG menggunakan template instance dan konfigurasi per instance terbaru selama perbaikan VM, Anda dapat mengonfigurasi grup untuk menerapkan update konfigurasi selama perbaikan.
Penanganan disk
Selama perbaikan, saat membuat ulang VM berdasarkan template-nya, MIG menangani berbagai jenis disk secara berbeda. Beberapa konfigurasi disk dapat menyebabkan perbaikan gagal saat mencoba membuat ulang VM.
Jenis disk | autodelete |
Perilaku selama perbaikan |
---|---|---|
Persistent disk baru | true |
Disk dibuat ulang seperti yang ditentukan dalam template instance. Setiap data yang ditulis ke disk tersebut akan hilang saat disk dan VM-nya dibuat ulang. |
Persistent disk baru | false |
Disk dipertahankan dan dipasang ulang saat MIG membuat ulang VM. |
Persistent disk yang ada | true |
Disk lama dihapus. Operasi pembuatan ulang VM gagal karena Compute Engine tidak dapat memasang kembali disk yang telah dihapus ke VM. Namun, untuk disk baca/tulis yang ada, MIG hanya dapat memiliki maksimal satu VM karena satu persistent disk tidak dapat dipasang ke beberapa VM dalam mode baca/tulis. |
Persistent disk yang ada | false |
Disk lama dipasang kembali seperti yang ditentukan dalam template instance. Data di disk akan dipertahankan. Namun, untuk disk baca/tulis yang ada, MIG hanya dapat memiliki maksimal satu VM karena satu persistent disk tidak dapat dipasang ke beberapa VM dalam mode baca/tulis. |
SSD lokal baru | T/A | Disk dibuat ulang seperti yang ditentukan dalam template instance. Data di SSD lokal akan hilang saat VM dibuat ulang atau dihapus. |
MIG tidak menginstal ulang disk yang tidak ditentukan dalam template instance atau konfigurasi per instance, seperti disk yang Anda instal ke VM secara manual setelah VM dibuat.
Untuk mempertahankan data penting yang ditulis ke disk, lakukan tindakan pencegahan, seperti berikut:
- Ambil snapshot persistent disk secara rutin.
- Ekspor data ke sumber lain, seperti Cloud Storage.
- Konfigurasi persist disk stateful.
Jika VM Anda memiliki setelan penting yang ingin dipertahankan, Google juga merekomendasikan agar Anda menggunakan image kustom di template instance Anda. Image kustom berisi setelan kustom yang Anda butuhkan. Saat Anda menentukan image kustom di template instance, MIG akan membuat ulang VM menggunakan image kustom yang berisi setelan kustom yang Anda butuhkan.
Menonaktifkan reparasi
Anda dapat menonaktifkan perbaikan yang dilakukan secara otomatis oleh MIG. Saat Anda menonaktifkan perbaikan, perbaikan VM yang gagal dan perbaikan berdasarkan health check aplikasi akan dinonaktifkan.
Anda mungkin ingin menonaktifkan perbaikan di MIG dalam skenario seperti berikut:
- Untuk menyelidiki atau men-debug VM yang gagal tanpa gangguan dari perbaikan otomatis.
- Untuk memperbaiki VM secara manual atau menerapkan logika perbaikan Anda sendiri.
- Untuk mencegah pendaftaran VM baru saat tugas batch sedang berlangsung.
- Untuk mengamati status respons aplikasi tanpa memperbaiki VM yang tidak responsif.
- Untuk menyesuaikan konfigurasi health check tanpa perbaikan yang memicu salah.
Jika Anda menonaktifkan perbaikan, MIG tidak akan melakukan tindakan apa pun jika VM dalam grup gagal atau menjadi tidak sehat. VM yang gagal dan tidak responsif akan tetap berada dalam grup dan
target jumlah VM yang berjalan di MIG (targetSize
) tetap sama.
Jika jenis update MIG ditetapkan ke proactive
dan template instance baru tersedia, MIG akan mencoba mengupdate VM yang gagal dan tidak responsif.
Jika Anda telah mengonfigurasi health check berbasis aplikasi, menonaktifkan perbaikan tidak akan memengaruhi fungsi health check. Health check terus menyelidiki aplikasi dan memberikan status kondisi VM. Hal ini memungkinkan Anda memantau status respons aplikasi sekaligus mencegah MIG memperbaiki VM yang tidak responsif.
Jika MIG adalah bagian dari layanan backend load balancer dan Anda menonaktifkan perbaikan di MIG, VM yang gagal dan tidak responsif yang tidak diperbaiki tidak akan merespons health check load balancer. Jika jumlah VM yang gagal atau tidak responsif di MIG meningkat, load balancer dapat mengurangi traffic ke MIG tersebut atau beralih ke backend lain, jika dikonfigurasi. Saat VM yang gagal tersedia lagi, load balancer akan melanjutkan traffic ke MIG.
Untuk mengetahui informasi selengkapnya, lihat Menonaktifkan perbaikan di MIG.
Langkah selanjutnya
- Siapkan health check dan autohealing berbasis aplikasi.
- Periksa apakah perbaikan dinonaktifkan di MIG.
- Menerapkan update konfigurasi selama perbaikan.