Failover untuk Load Balancer Jaringan passthrough internal

Anda dapat mengonfigurasi Load Balancer Jaringan passthrough internal untuk mendistribusikan koneksi antar-instance mesin virtual (VM) di backend utama, lalu beralih, jika diperlukan, ke backend failover. Failover menyediakan salah satu metode untuk meningkatkan ketersediaan, sekaligus memberi Anda kontrol lebih besar untuk mengelola beban kerja saat VM backend utama Anda tidak responsif.

Halaman ini menjelaskan konsep dan persyaratan khusus failover untuk Load Balancer Jaringan passthrough internal. Pastikan Anda memahami informasi konseptual di artikel berikut sebelum mengonfigurasi failover untuk Load Balancer Jaringan passthrough internal:

Konsep ini penting untuk dipahami karena mengonfigurasi failover akan mengubah algoritma distribusi traffic standar Load Balancer Jaringan passthrough internal.

Secara default, saat Anda menambahkan backend ke layanan backend Load Balancer Jaringan passthrough internal, backend tersebut adalah backend utama. Anda dapat menetapkan backend sebagai backend failover saat menambahkannya ke layanan backend load balancer, atau dengan mengedit layanan backend di lain waktu. Backend failover hanya menerima koneksi dari load balancer setelah rasio VM utama yang dapat dikonfigurasi tidak lulus health check.

Grup instance yang didukung

Grup instance terkelola dan tidak terkelola didukung sebagai backend. Untuk mempermudah, contoh di halaman ini menunjukkan grup instance tidak terkelola.

Menggunakan grup instance terkelola dengan penskalaan otomatis dan failover dapat menyebabkan kumpulan aktif mengalami failover dan failover berulang kali antara backend utama dan failover. Google Cloud tidak mencegah Anda mengonfigurasi failover dengan grup instance terkelola karena deployment Anda mungkin akan mendapatkan manfaat dari penyiapan ini.

Arsitektur

Contoh sederhana berikut menggambarkan Load Balancer Jaringan passthrough internal dengan satu backend utama dan satu backend failover.

Backend utama adalah grup instance tidak terkelola di us-west1-a.
Backend failover adalah grup instance tidak terkelola yang berbeda di us-west1-c.

Contoh failover untuk Load Balancer Jaringan passthrough internal. — Contoh failover untuk Load Balancer Jaringan passthrough internal (klik untuk memperbesar).

Contoh berikutnya menggambarkan Load Balancer Jaringan passthrough internal dengan dua backend utama dan dua backend failover, yang keduanya didistribusikan di antara dua zona di region us-west1. Konfigurasi ini meningkatkan keandalan karena tidak bergantung pada satu zona untuk semua backend utama atau semua failover.

Backend utama adalah grup instance tidak terkelola ig-a dan ig-d.
Backend failover adalah grup instance tidak terkelola ig-b dan ig-c.

Failover Load Balancer Jaringan passthrough multi-zona. — Failover Load Balancer Jaringan passthrough internal multi-zona (klik untuk memperbesar).

Selama failover, kedua backend utama akan menjadi tidak aktif, sedangkan VM yang responsif di kedua backend failover akan aktif. Untuk penjelasan lengkap tentang cara kerja failover dalam contoh ini, lihat contoh Failover.

Grup instance backend dan VM

Grup instance yang tidak terkelola di Load Balancer Jaringan passthrough internal dapat berupa backend utama atau backend failover. Anda dapat menetapkan backend sebagai backend failover pada saat menambahkannya ke layanan backend atau dengan mengedit backend setelah menambahkannya. Jika tidak, grup instance yang tidak dikelola akan menjadi grup utama secara default.

Anda dapat mengonfigurasi beberapa backend utama dan beberapa backend failover dalam satu Load Balancer Jaringan passthrough internal dengan menambahkannya ke layanan backend load balancer.

VM utama adalah anggota grup instance yang telah Anda tetapkan sebagai backend utama. VM di backend utama berpartisipasi dalam kumpulan aktif load balancer (dijelaskan di bagian berikutnya), kecuali jika load balancer beralih menggunakan backend failover-nya.

VM cadangan adalah anggota grup instance yang telah Anda tetapkan sebagai backend failover. VM di backend failover berpartisipasi dalam kumpulan aktif load balancer saat VM utama menjadi tidak responsif. Jumlah VM tidak responsif yang memicu failover adalah persentase yang dapat dikonfigurasi.

Batas

Pesan Suara. Anda dapat memiliki hingga 250 VM di kumpulan aktif. Dengan kata lain, grup instance backend utama Anda dapat memiliki total hingga 250 VM utama, dan grup instance backend failover Anda dapat memiliki total hingga 250 VM cadangan.
Grup instance tidak terkelola. Anda dapat memiliki hingga 50 grup instance backend utama dan hingga 50 grup instance backend failover.

Sebagai contoh, deployment maksimum mungkin memiliki 5 backend utama dan 5 backend failover, dengan setiap grup instance berisi 50 VM.

Kolam aktif

Kumpulan aktif adalah kumpulan VM backend yang menjadi tujuan pengiriman koneksi baru oleh Load Balancer Jaringan passthrough internal. Keanggotaan VM backend dalam kumpulan aktif dikomputasi secara otomatis berdasarkan backend yang responsif dan kondisi yang dapat Anda tentukan, seperti yang dijelaskan dalam Rasio failover.

Kumpulan aktif tidak pernah menggabungkan VM utama dan VM cadangan. Contoh berikut menjelaskan kemungkinan keanggotaan. Selama failover, kumpulan aktif hanya berisi VM cadangan. Selama operasi normal (failback), kumpulan aktif hanya berisi VM utama.

Kumpulan aktif saat failover dan failover. — Kumpulan aktif saat failover dan failback (klik untuk memperbesar).

Failover dan failback

Failover dan failback adalah proses otomatis yang mengalihkan VM backend ke dalam atau keluar dari kumpulan aktif load balancer. Saat Google Cloud menghapus VM utama dari kumpulan aktif dan menambahkan VM failover yang responsif ke kumpulan aktif, prosesnya disebut failover. Saat Google Cloud membalikkan hal ini, proses ini disebut failback.

Kebijakan failover

Kebijakan failover adalah kumpulan parameter yang digunakan Google Cloud untuk failover dan failover. Setiap Load Balancer Jaringan passthrough internal memiliki satu kebijakan failover yang memiliki beberapa setelan:

Rasio failover
Menurunkan traffic saat semua VM backend tidak responsif
Pengosongan koneksi saat failover dan failback

Rasio failover

Rasio failoveryang dapat dikonfigurasi menentukan kapan Google Cloud melakukan failover atau failover, yang mengubah keanggotaan di kumpulan aktif. Rasionya dapat dari 0.0 hingga 1.0, inklusif. Jika Anda tidak menentukan rasio failover, Google Cloud akan menggunakan nilai default 0.0. Sebaiknya tetapkan rasio failover ke angka yang sesuai untuk kasus penggunaan Anda, bukan mengandalkan nilai default ini.

Kondisi	VM dalam kumpulan aktif
Rasio failover (x) `!= 0.0`. Rasio VM utama yang responsif `>= x`. Rasio failover (x) `= 0.0`. Jumlah VM utama yang responsif `> 0`.	Semua VM utama yang responsif
Jika setidaknya satu VM cadangan responsif dan: Rasio failover (x) `!= 0.0`. Rasio VM utama yang responsif `< x`. Rasio failover `= 0.0`. Jumlah VM utama yang responsif `= 0`.	Semua VM pencadangan yang responsif
Saat semua VM utama dan semua VM cadangan tidak responsif dan Anda belum mengonfigurasi load balancer untuk menurunkan traffic dalam situasi ini.	Semua VM utama, sebagai upaya terakhir

Contoh berikut menjelaskan keanggotaan dalam kumpulan aktif. Untuk contoh penghitungan, lihat contoh Failover.

Rasio failover sebesar 1.0 mengharuskan semua VM utama responsif. Jika setidaknya satu VM utama menjadi tidak responsif, Google Cloud akan melakukan failover, yang akan memindahkan VM cadangan ke kumpulan aktif.
Rasio failover 0.1 mengharuskan setidaknya 10% VM utama responsif; jika tidak, Google Cloud akan menjalankan failover.
Rasio failover 0.0 berarti Google Cloud melakukan failover hanya saat semua VM utama tidak responsif. Failover tidak terjadi jika setidaknya satu VM utama responsif.

Load Balancer Jaringan passthrough internal mendistribusikan koneksi di antara VM di kumpulan aktif sesuai dengan algoritma distribusi traffic.

Menurunkan traffic saat semua VM backend tidak responsif

Secara default, jika semua VM utama dan cadangan tidak responsif, Google Cloud akan mendistribusikan koneksi baru hanya di antara VM utama. Ini adalah upaya terakhir. VM cadangan dikecualikan dari distribusi koneksi terakhir ini.

Jika mau, Anda dapat mengonfigurasi Load Balancer Jaringan passthrough internal untuk menghentikan koneksi baru saat semua VM utama dan cadangan tidak responsif.

Pengosongan koneksi saat failover dan failback

Pengosongan koneksi memungkinkan sesi TCP yang ada tetap aktif hingga jangka waktu yang dapat dikonfigurasi bahkan setelah VM backend tidak responsif. Jika protokol untuk load balancer Anda adalah TCP, hal berikut berlaku:

Secara default, pengosongan koneksi diaktifkan. Sesi TCP yang ada dapat bertahan di VM backend hingga 300 detik (5 menit), meskipun VM backend menjadi tidak responsif atau tidak berada dalam kumpulan aktif load balancer.
Anda dapat menonaktifkan pengosongan koneksi selama peristiwa failover dan failover. Menonaktifkan pengosongan koneksi selama failover dan failback memastikan bahwa semua sesi TCP, termasuk yang sudah ada, dihentikan dengan cepat. Koneksi ke VM backend mungkin ditutup dengan paket reset TCP.

Menonaktifkan pengosongan koneksi saat failover dan failback berguna untuk skenario seperti berikut:

Melakukan patch pada VM backend. Sebelum menerapkan patch, konfigurasikan VM utama Anda untuk gagal dalam health check, sehingga load balancer menjalankan failover. Dengan menonaktifkan pengosongan koneksi, Anda dapat memastikan semua koneksi dipindahkan ke VM cadangan dengan cepat dan terencana. Dengan begitu, Anda dapat menginstal update dan memulai ulang VM utama tanpa mempertahankan koneksi yang ada. Setelah melakukan patching, Google Cloud dapat melakukan failover saat sejumlah VM utama yang memadai (sebagaimana ditentukan oleh rasio failover) lulus health check.
VM backend tunggal untuk konsistensi data. Jika Anda perlu memastikan bahwa hanya satu VM utama yang merupakan tujuan untuk semua koneksi, nonaktifkan pengosongan koneksi sehingga beralih dari VM utama ke VM cadangan tidak memungkinkan koneksi yang ada bertahan di keduanya. Hal ini mengurangi kemungkinan inkonsistensi data dengan hanya membuat satu VM backend aktif pada satu waktu tertentu.

Contoh failover

Contoh berikut menjelaskan perilaku failover untuk contoh Load Balancer Jaringan passthrough internal multi-zona yang ditampilkan di bagian arsitektur.

Backend utama untuk load balancer ini adalah grup instance tidak terkelola ig-a dalam us-west1-a dan ig-d di us-west1-c. Setiap grup instance berisi dua VM. Keempat VM dari kedua grup instance tersebut adalah VM utama:

vm-a1 di ig-a
vm-a2 di ig-a
vm-d1 di ig-d
vm-d2 di ig-d

Backend failover untuk load balancer ini adalah grup instance tidak terkelola ig-b dalam us-west1-a dan ig-c di us-west1-c. Setiap grup instance berisi dua VM. Keempat VM dari kedua grup instance tersebut adalah VM cadangan:

vm-b1 di ig-b
vm-b2 di ig-b
vm-c1 di ig-c
vm-c2 di ig-c

Misalkan Anda ingin mengonfigurasi kebijakan failover untuk load balancer ini sehingga koneksi baru dikirim ke VM cadangan saat jumlah VM utama yang responsif kurang dari dua. Untuk melakukannya, tetapkan rasio failover ke 0.5 (50%). Google Cloud menggunakan rasio failover untuk menghitung jumlah minimum VM utama yang harus responsif dengan mengalikan rasio failover dengan jumlah VM utama: 4 × 0.5 = 2

Jika keempat VM utama responsif, Google Cloud akan mendistribusikan koneksi baru ke semua VM tersebut. Jika VM utama gagal health check:

Jika vm-a1 dan vm-d1 tidak responsif, Google Cloud akan mendistribusikan koneksi baru antara dua VM utama responsif yang tersisa, vm-a2 dan vm-d2, karena jumlah VM utama yang responsif setidaknya minimal.
Jika vm-a2 juga gagal dalam health check, sehingga hanya menyisakan satu VM utama yang responsif, vm-d2, Google Cloud menyadari bahwa jumlah VM utama yang responsif kurang dari minimum, sehingga akan menjalankan failover. Kumpulan aktif ditetapkan ke empat VM cadangan yang responsif, dan koneksi baru didistribusikan di antara keempat VM tersebut (dalam grup instance ig-b dan ig-c). Meskipun vm-d2 tetap responsif, VM ini akan dihapus dari kumpulan aktif dan tidak menerima koneksi baru.
Jika vm-a2 berhasil pulih dan lulus health check, Google Cloud akan mengetahui bahwa jumlah VM utama yang responsif minimal berjumlah dua, sehingga melakukan failover. Kumpulan aktif ditetapkan ke dua VM utama yang responsif, vm-a2 dan vm-d2, dan koneksi baru didistribusikan di antara keduanya. Semua VM cadangan akan dihapus dari kumpulan aktif.
Saat VM utama lainnya memulihkan dan lulus health check, Google Cloud akan menambahkannya ke kumpulan aktif. Misalnya, jika vm-a1 menjadi responsif, Google Cloud akan menetapkan kumpulan aktif ke tiga VM utama yang responsif, vm-a1, vm-a2, dan vm-d2, serta mendistribusikan koneksi baru di antara VM tersebut.

Langkah selanjutnya

Untuk mengonfigurasi dan menguji Load Balancer Jaringan passthrough internal yang menggunakan failover, lihat Mengonfigurasi failover untuk Load Balancer Jaringan passthrough internal.
Untuk mengonfigurasi dan menguji Load Balancer Jaringan passthrough internal, lihat Menyiapkan Load Balancer Jaringan passthrough internal.
Untuk memecahkan masalah failover dengan Load Balancer Jaringan passthrough internal, lihat Memecahkan masalah Load Balancer Jaringan passthrough internal.