Failover untuk Load Balancer Jaringan passthrough internal

Anda dapat mengonfigurasi Network Load Balancer passthrough internal untuk mendistribusikan koneksi di antara instance virtual machine (VM) di backend utama, lalu beralih, jika diperlukan, untuk menggunakan backend failover. Failover menyediakan satu metode untuk meningkatkan ketersediaan, sekaligus memberi Anda kontrol yang lebih besar atas cara mengelola beban kerja saat VM backend utama tidak berfungsi.

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

• Ringkasan Load Balancer Jaringan passthrough internal
• Ringkasan health check

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 nanti. 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 memudahkan, contoh di halaman ini menunjukkan grup instance yang tidak dikelola.

Menggunakan grup instance terkelola dengan penskalaan otomatis dan failover dapat menyebabkan kumpulan aktif berulang kali beralih ke failover dan failback antara backend utama dan failover. Google Cloud tidak mencegah Anda mengonfigurasi failover dengan grup instance terkelola karena deployment Anda mungkin 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 tak 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 (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 primer atau semua backend failover.

Catatan: Region Meksiko, Montreal, dan Osaka memiliki tiga zona dalam satu atau dua pusat data fisik. Region ini sedang dalam proses perluasan ke minimal tiga pusat data fisik. Untuk mengetahui informasi selengkapnya, lihat Lokasi Cloud dan SLA Google Cloud Platform. Untuk membantu meningkatkan keandalan workload Anda, pertimbangkan deployment multi-regional.

• 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 internal multi-zona (klik untuk memperbesar).

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

Grup instance dan VM backend

Grup instance tidak terkelola di Load Balancer Jaringan passthrough internal adalah 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 tidak terkelola 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 tentukan sebagai backend utama. VM di backend utama berpartisipasi dalam kumpulan aktif load balancer (dijelaskan di bagian berikutnya), kecuali jika load balancer beralih untuk menggunakan backend failover-nya.

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

Batas

• VM. 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.

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

Kumpulan aktif

Kumpulan aktif adalah kumpulan VM backend tempat Load Balancer Jaringan passthrough internal mengirim koneksi baru. Keanggotaan VM backend dalam kumpulan aktif dihitung secara otomatis berdasarkan backend yang berfungsi dan kondisi yang dapat Anda tentukan, seperti yang dijelaskan dalam Rasio failover.

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

Pembentukan aktif pada 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 sehat ke kumpulan aktif, proses ini disebut failover. Saat Google Cloud membalikkan hal ini, prosesnya disebut failback.

Kebijakan failover

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

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

Rasio failover

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

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

Contoh berikut memperjelas keanggotaan dalam kumpulan aktif. Untuk contoh dengan penghitungan, lihat Contoh failover.

• Rasio failover 1.0 mengharuskan semua VM utama dalam kondisi responsif. Jika setidaknya satu VM utama tidak berfungsi, Google Cloud akan melakukan failover, yang memindahkan VM cadangan ke kumpulan aktif.
• Rasio failover 0.1 mengharuskan setidaknya 10% VM utama berfungsi dengan baik; jika tidak, Google Cloud akan melakukan failover.
• Rasio failover 0.0 berarti Google Cloud hanya melakukan failover jika semua VM utama tidak responsif. Failover tidak terjadi jika setidaknya satu VM utama responsif.

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

Menghentikan 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. Tindakan ini dilakukan sebagai pilihan terakhir. VM cadangan dikecualikan dari distribusi koneksi upaya terakhir ini.

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

Pengosongan koneksi saat failover dan failback

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

• Secara default, pengosongan koneksi diaktifkan. Sesi TCP yang ada dapat dipertahankan di VM backend hingga 300 detik (5 menit), meskipun VM backend menjadi tidak sehat atau tidak berada dalam kumpulan aktif load balancer.

• Anda dapat menonaktifkan pengosongan koneksi selama peristiwa failover dan failback. Menonaktifkan pengosongan koneksi selama failover dan failback memastikan bahwa semua sesi TCP, termasuk yang sudah dibuat, 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 patching pada VM backend. Sebelum melakukan patching, konfigurasikan VM utama Anda agar gagal dalam health check sehingga load balancer melakukan failover. Menonaktifkan pengosongan koneksi memastikan bahwa semua koneksi dipindahkan ke VM cadangan dengan cepat dan sesuai rencana. Hal ini memungkinkan Anda menginstal update dan memulai ulang VM utama tanpa mempertahankan koneksi yang ada. Setelah melakukan patching, Google Cloud dapat melakukan failback jika VM utama dalam jumlah 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 menjadi tujuan untuk semua koneksi, nonaktifkan pengosongan koneksi sehingga beralih dari VM utama ke VM cadangan tidak memungkinkan koneksi yang ada tetap ada di keduanya. Hal ini mengurangi kemungkinan inkonsistensi data dengan hanya mengaktifkan satu VM backend pada waktu tertentu.

Contoh failover

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

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

Backend utama untuk load balancer ini adalah grup instance tidak terkelola ig-a di us-west1-a dan ig-d di us-west1-c. Setiap grup instance berisi dua VM. Keempat VM dari kedua grup instance 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 di us-west1-a dan ig-c di us-west1-c. Setiap grup instance berisi dua VM. Keempat VM dari kedua grup instance adalah VM cadangan:

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

Misalnya, Anda ingin mengonfigurasi kebijakan failover untuk load balancer ini sehingga koneksi baru dikirim ke VM cadangan jika 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 primer yang harus berfungsi dengan baik dengan mengalikan rasio failover dengan jumlah VM primer: 4 × 0.5 = 2

Jika keempat VM utama berfungsi dengan baik, Google Cloud akan mendistribusikan koneksi baru ke semua VM tersebut. Jika VM utama gagal dalam health check:

• Jika vm-a1 dan vm-d1 menjadi tidak responsif, Google Cloud akan mendistribusikan koneksi baru antara dua VM utama yang tersisa dan responsif, vm-a2 dan vm-d2, karena jumlah VM utama yang responsif setidaknya sudah minimum.

• Jika vm-a2 juga gagal dalam health check, sehingga hanya menyisakan satu VM utama yang sehat, vm-d2, Google Cloud akan mengenali bahwa jumlah VM utama yang sehat lebih sedikit dari minimum, sehingga melakukan failover. Kumpulan aktif ditetapkan ke empat VM cadangan yang responsif, dan koneksi baru didistribusikan di antara keempat VM tersebut (di grup instance ig-b dan ig-c). Meskipun vm-d2 tetap responsif, VM tersebut akan dihapus dari kumpulan aktif dan tidak menerima koneksi baru.

• Jika vm-a2 pulih dan lulus health check, Google Cloud akan mengenali bahwa jumlah VM utama yang responsif setidaknya minimal dua, sehingga melakukan failback. 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 pulih 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, dan mendistribusikan koneksi baru di antara ketiga 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.