Pola penggunaan alamat IP mengambang di Compute Engine

Last reviewed 2024-01-29 UTC

Dokumen ini menjelaskan cara menggunakan pola implementasi alamat IP mengambang saat memigrasikan aplikasi ke Compute Engine dari lingkungan jaringan lokal. Dokumen ini ditujukan untuk engineer jaringan, administrator sistem, dan engineer operasi yang memigrasikan aplikasi ke Google Cloud.

Disebut juga sebagai alamat IP virtual atau bersama, alamat IP mengambang sering digunakan untuk menjadikan lingkungan jaringan lokal sangat tersedia. Dengan menggunakan alamat IP mengambang, Anda dapat meneruskan alamat IP di antara beberapa server fisik atau virtual yang dikonfigurasi secara identik. Praktik ini memungkinkan failover atau mengupgrade software produksi. Namun, Anda tidak dapat langsung mengimplementasikan alamat IP mengambang di lingkungan Compute Engine tanpa mengubah arsitekturnya ke salah satu pola yang dijelaskan dalam dokumen ini.

Repositori GitHub yang menyertai dokumen ini mencakup contoh deployment untuk setiap pola yang dapat Anda deploy secara otomatis menggunakan Terraform.

Alamat IP mengambang di lingkungan lokal

Alamat IP mengambang biasanya digunakan di lingkungan lokal. Contoh kasus penggunaan adalah sebagai berikut:

Ada beberapa cara untuk mengimplementasikan alamat IP mengambang di lingkungan lokal. Server yang berbagi alamat IP mengambang biasanya juga berbagi informasi status melalui mekanisme heartbeat. Mekanisme ini memungkinkan server mengomunikasikan status responsifnya pada satu sama lain; serta memungkinkan server sekunder mengambil alih alamat IP mengambang setelah server utama gagal. Skema ini sering diterapkan menggunakan Virtual Router Redundancy Protocol, tetapi Anda juga dapat menggunakan mekanisme lain yang serupa.

Setelah failover alamat IP dimulai, server yang mengambil alih alamat IP mengambang akan menambahkan alamat tersebut ke antarmuka jaringannya. Server mengumumkan pengambilalihan ini ke perangkat lain menggunakan Lapisan 2 dengan mengirimkan frame Protokol Resolusi Alamat (ARP) yang serampangan. Selain itu, terkadang protokol perutean seperti Open Shortest Path First (OSPF), mengumumkan alamat IP ke router Lapisan 3 upstream.

Diagram berikut menunjukkan penyiapan umum di lingkungan lokal.

Lingkungan lokal yang umum.

Diagram sebelumnya menunjukkan cara server utama dan server sekunder yang terhubung ke switch yang sama bertukar informasi responsivitas melalui mekanisme heartbeat. Jika server primer gagal, server sekunder akan mengirimkan frame ARP serampangan ke switch untuk mengambil alih alamat IP mengambang.

Anda menggunakan penyiapan yang sedikit berbeda dengan solusi load balancing lokal, seperti Load Balancing Jaringan Windows atau Load Balancing Linux dengan respons Server Langsung seperti IPVS. Dalam hal ini, layanan juga mengirimkan frame ARP yang serampangan, tetapi dengan alamat MAC server lain sebagai sumber ARP yang serampangan. Tindakan ini pada dasarnya akan memalsukan frame ARP dan mengambil alih alamat IP sumber server lain.

Tindakan ini dilakukan untuk mendistribusikan muat untuk satu alamat IP di antara server yang berbeda. Namun, penyiapan semacam ini berada di luar cakupan dokumen ini. Dalam hampir semua kasus, saat alamat IP mengambang digunakan untuk load balancing lokal, sebaiknya migrasi ke Cloud Load Balancing.

Tantangan saat memigrasikan alamat IP mengambang ke Compute Engine

Compute Engine menggunakan stack jaringan virtual di jaringan Virtual Private Cloud (VPC) sehingga mekanisme implementasi standar tidak berfungsi tanpa perubahan di Google Cloud. Misalnya, jaringan VPC menangani permintaan ARP di jaringan yang ditentukan oleh software, dan mengabaikan frame ARP yang serampangan. Selain itu, tabel perutean jaringan VPC tidak dapat langsung diubah dengan protokol perutean standar, seperti OSPF atau Border Gateway Protocol (BGP). Mekanisme umum untuk alamat IP mengambang bergantung pada permintaan ARP yang ditangani dengan beralih infrastruktur atau mengandalkan jaringan yang dapat diprogram oleh OSPF atau BGP. Oleh karena itu, alamat IP tidak melakukan failover menggunakan mekanisme ini di Google Cloud. Jika Anda memigrasikan image virtual machine (VM) menggunakan alamat IP mengambang lokal, alamat IP mengambang tidak akan dapat diganti tanpa mengubah aplikasi.

Anda dapat menggunakan jaringan overlay untuk membuat konfigurasi yang memungkinkan komunikasi Lapisan 2 penuh dan pengambilalihan IP melalui permintaan ARP. Namun, penyiapan jaringan overlay adalah hal yang kompleks dan mempersulit pengelolaan resource jaringan Compute Engine. Pendekatan tersebut juga berada di luar cakupan dokumen ini. Sebagai gantinya, dokumen ini menjelaskan pola untuk menerapkan skenario failover di lingkungan jaringan Compute Engine tanpa membuat jaringan overlay.

Untuk mengimplementasikan aplikasi yang sangat tersedia dan andal di Compute Engine, gunakan arsitektur yang diskalakan secara horizontal. Jenis arsitektur ini meminimalkan efek kegagalan node tunggal.

Dokumen ini menjelaskan beberapa pola untuk memigrasikan aplikasi yang sudah ada menggunakan alamat IP mengambang dari infrastruktur lokal ke Compute Engine, termasuk hal berikut:

Menggunakan Alamat IP alias yang berpindah antarinstance VM tidak disarankan sebagai mekanisme failover karena tidak memenuhi persyaratan ketersediaan tinggi. Dalam skenario kegagalan tertentu, seperti peristiwa kegagalan zona, Anda mungkin tidak dapat menghapus alamat IP Alias dari instance. Oleh karena itu, Anda mungkin tidak dapat menambahkannya ke instance lain—sehingga membuat failover tidak mungkin.

Memilih pola untuk kasus penggunaan Anda

Bergantung pada persyaratan Anda, satu atau beberapa pola yang dijelaskan dalam solusi ini mungkin berguna untuk mengimplementasikan alamat IP mengambang di lingkungan lokal.

Pertimbangkan faktor-faktor berikut saat menentukan pola terbaik yang memungkinkan Anda menggunakan aplikasi:

  • Alamat IP eksternal mengambang atau internal mengambang: Sebagian besar aplikasi yang memerlukan alamat IP mengambang menggunakan alamat IP internal mengambang. Hanya sedikit aplikasi yang menggunakan alamat IP eksternal mengambang, karena biasanya traffic ke aplikasi eksternal harus di-load balanced.

    Tabel nanti di bagian ini merekomendasikan pola yang dapat Anda gunakan untuk alamat IP internal mengambang dan untuk alamat IP eksternal mengambang. Untuk kasus penggunaan yang mengandalkan alamat IP internal mengambang, salah satu pola ini mungkin cocok untuk kebutuhan Anda. Namun, sebaiknya kasus penggunaan yang mengandalkan alamat IP eksternal mengambang harus dimigrasikan ke salah satu pola yang menggunakan load balancing.

  • Protokol aplikasi: Jika VM Anda hanya menggunakan TCP dan UDP, Anda dapat menggunakan semua pola dalam tabel. Jika menggunakan protokol lain selain IPv4 untuk terhubung, hanya beberapa pola yang cocok.

  • Kompatibilitas deployment aktif-aktif: Beberapa aplikasi, meskipun menggunakan alamat IP mengambang lokal, dapat bekerja dalam mode deployment aktif-aktif. Kemampuan ini berarti tidak memerlukan failover dari server utama ke server sekunder. Anda memiliki lebih banyak pilihan pola untuk memindahkan aplikasi semacam ini ke Compute Engine. Aplikasi yang hanya memerlukan satu server aplikasi untuk menerima traffic kapan saja tidak kompatibel dengan deployment aktif-aktif. Anda hanya dapat mengimplementasikan aplikasi ini dengan beberapa pola dalam tabel berikut.

  • Perilaku failover setelah VM utama dipulihkan: Saat VM primer asli dipulihkan setelah failover, bergantung pada pola yang digunakan, traffic akan melakukan salah satu dari dua tindakan berikut. VM akan langsung dipindahkan kembali ke VM primer asli atau tetap berada di VM utama baru hingga failover dimulai secara manual atau VM primer baru gagal. Dalam semua kasus, hanya koneksi yang baru dimulai yang akan gagal kembali. Koneksi yang ada akan tetap berada di VM utama yang baru sampai koneksi tersebut ditutup.

  • Kompatibilitas health check: Jika Anda tidak dapat memeriksa apakah aplikasi Anda responsif menggunakan health check Compute Engine, Anda dapat dengan mudah menggunakan beberapa pola yang dijelaskan dalam tabel berikut.

  • Grup instance: Semua pola dengan kompatibilitas health check juga kompatibel dengan grup instance. Untuk membuat ulang instance yang gagal secara otomatis, Anda dapat menggunakan grup instance terkelola dengan autohealing. Jika VM Anda mempertahankan status, Anda dapat menggunakan grup instance terkelola stateful. Jika VM tidak dapat dibuat ulang secara otomatis atau Anda memerlukan failover manual, gunakan grup instance tidak terkelola dan buat ulang VM secara manual selama failover.

  • Mekanisme heartbeat yang ada: Jika penyiapan ketersediaan tinggi untuk aplikasi Anda sudah menggunakan mekanisme heartbeat untuk memicu failover, seperti Heartbeat, Pacemaker, atau Keepalive, Anda dapat menggunakan beberapa pola yang dijelaskan dalam tabel berikut.

Tabel berikut mencantumkan kemampuan pola. Setiap pola dijelaskan di bagian berikut:

Nama pola Alamat IP Protokol yang didukung Mode deployment Failback Kompatibilitas health check aplikasi diperlukan Dapat mengintegrasikan mekanisme heartbeat
Pola yang menggunakan load balancing
Load balancing aktif-aktif Internal atau eksternal Khusus TCP/UDP Aktif-aktif T/A Ya Tidak
Load balancing dengan failover dan health check yang terekspos aplikasi Internal atau eksternal Khusus TCP/UDP Aktif-pasif Segera (kecuali koneksi yang ada) Ya Tidak
Load balancing dengan failover dan health check yang terekspos heartbeat Internal atau eksternal Khusus TCP/UDP Aktif-pasif Dapat Dikonfigurasi Tidak Ya
Pola yang menggunakan rute Google Cloud
Menggunakan rute ECMP Internal Semua protokol IP Aktif-aktif T/A Ya Tidak
Menggunakan rute prioritas yang berbeda Internal Semua protokol IP Aktif-pasif Segera (kecuali koneksi yang ada) Ya Tidak
Menggunakan mekanisme heartbeat untuk beralih rute hop berikutnya Internal Semua protokol IP Aktif-pasif Dapat Dikonfigurasi Tidak Ya
Pola yang menggunakan autohealing
Menggunakan satu instance autohealing Internal Semua protokol IP T/A T/A Ya Tidak

Menentukan pola yang akan digunakan untuk kasus penggunaan Anda mungkin bergantung pada beberapa faktor. Pohon keputusan berikut dapat membantu Anda mempersempit pilihan ke opsi yang sesuai.

Pohon keputusan yang membantu Anda memilih load balancer.

Diagram sebelumnya menjelaskan langkah-langkah berikut:

  1. Apakah satu instance autohealing menyediakan ketersediaan yang cukup baik sesuai kebutuhan Anda?
    1. Jika ya, lihat Menggunakan satu instance autohealing nanti dalam dokumen ini. Autohealing menggunakan mekanisme dalam grup instance VM untuk secara otomatis mengganti instance VM yang rusak.
    2. Jika tidak, lanjutkan ke titik keputusan berikutnya.
  2. Apakah aplikasi Anda memerlukan protokol di atas IPv4 selain TCP dan UDP?
    1. Jika ya, lanjutkan ke titik keputusan berikutnya.
    2. Jika tidak, lanjutkan ke titik keputusan berikutnya.
  3. Dapatkah aplikasi Anda berfungsi dalam mode aktif-aktif?
    1. Jika ya, dan memerlukan protokol selain IPv4 selain TCP dan UDP, lihat Menggunakan rute multijalur (ECMP) yang setara nanti dalam dokumen ini. Rute ECMP mendistribusikan traffic di antara hop berikutnya dari semua kandidat rute.
    2. Jika ya dan tidak memerlukan protokol di atas IPv4 selain TCP dan UDP, lihat Load balancing aktif-aktif nanti dalam dokumen ini. Load balancing aktif yang aktif menggunakan VM Anda sebagai backend untuk load balancer TCP/UDP internal.
    3. Jika tidak – dalam kedua kasus – lanjutkan ke titik keputusan berikutnya.
  4. Dapatkah aplikasi Anda mengekspos health check Google Cloud?
    1. Jika ya dan memerlukan protokol selain IPv4 selain TCP dan UDP, lihat Load balancing dengan health check yang diekspos oleh failover dan health check yang terekspos aplikasi nanti dalam dokumen ini. Load balancing dengan failover dan health check yang terekspos aplikasi menggunakan VM Anda sebagai backend untuk load balancer TCP/UDP internal. Alamat IP ini juga menggunakan alamat IP Load Balancing TCP/UDP Internal sebagai alamat IP virtual.
    2. Jika ya dan tidak memerlukan protokol di atas IPv4 selain TCP dan UDP, lihat Menggunakan rute prioritas yang berbeda nanti dalam dokumen ini. Menggunakan rute prioritas yang berbeda akan membantu memastikan bahwa traffic selalu mengalir ke instance utama, kecuali jika instance tersebut gagal.
    3. Jika tidak dan memerlukan protokol selain IPv4 selain TCP dan UDP, lihat Load balancing dengan health check yang terekspos pada failover dan health check nanti dalam dokumen ini. Dalam load balancing dengan pola health check yang mengekspos failover dan health check, health check tidak diekspos oleh aplikasi itu sendiri, tetapi oleh mekanisme heartbeat yang berjalan di antara kedua VM.
    4. Jika tidak dan operator TIDAK MEMERLUKAN protokol IPv4 selain TCP dan UDP, lihat Menggunakan mekanisme heartbeat untuk mengalihkan hop berikutnya dari rute nanti dalam dokumen ini. Penggunaan mekanisme heartbeat untuk mengalihkan hop berikutnya dari rute berikutnya akan menggunakan satu rute statis dengan hop berikutnya yang mengarah ke instance VM utama.

Pola yang menggunakan load balancing

Biasanya, Anda dapat memigrasikan aplikasi menggunakan alamat IP mengambang ke arsitektur di Google Cloud yang menggunakan Cloud Load Balancing. Anda dapat menggunakan Load Balancer Jaringan passthrough internal, karena opsi ini paling sesuai dengan sebagian besar kasus penggunaan saat layanan yang dimigrasikan lokal hanya ditampilkan secara internal. Opsi load balancing ini digunakan untuk semua contoh di bagian ini dan contoh deployment di GitHub. Jika Anda memiliki klien yang mengakses alamat IP mengambang dari region lain, pilih opsi akses global.

Jika aplikasi Anda berkomunikasi menggunakan protokol di atas IPv4, selain TCP atau UDP, Anda harus memilih pola yang tidak menggunakan load balancing. Pola-pola tersebut akan dijelaskan kemudian dalam dokumen ini.

Jika aplikasi Anda menggunakan HTTP(S), Anda dapat menggunakan Load Balancer Aplikasi internal untuk menerapkan pola aktif-aktif.

Jika layanan yang Anda coba migrasikan tersedia secara eksternal, Anda dapat menerapkan semua pola yang dibahas di bagian ini menggunakan Load Balancer Jaringan passthrough eksternal. Untuk deployment aktif-aktif, Anda juga dapat menggunakan Load Balancer Aplikasi eksternal, proxy TCP, atau Proxy SSL jika aplikasi Anda menggunakan protokol dan port yang didukung oleh opsi load balancing tersebut.

Pertimbangkan perbedaan berikut antara implementasi berbasis alamat IP mengambang lokal dan semua pola berbasis load balancing:

  • Waktu failover: Penyambungan Keepalive dengan ARP yang serampangan di lingkungan lokal mungkin akan gagal melalui alamat IP dalam beberapa detik. Di lingkungan Compute Engine, waktu pemulihan rata-rata dari failover bergantung pada parameter yang Anda tetapkan. Jika instance virtual machine (VM) atau layanan instance VM gagal, traffic rata-rata kegagalan akan bergantung pada parameter health check seperti Check Interval dan Unhealthy Threshold. Dengan parameter ini ditetapkan ke nilai defaultnya, failover biasanya memerlukan waktu 15–20 detik. Anda dapat mengurangi waktu dengan mengurangi parameter value tersebut.

    Di Compute Engine, failover dalam zona atau antarzona memerlukan jumlah waktu yang sama.

  • Protokol dan Port: Dalam penyiapan lokal, alamat IP mengambang menerima semua traffic. Pilih salah satu spesifikasi port berikut di aturan penerusan internal untuk Load Balancer Jaringan passthrough internal:

    • Tentukan minimal satu port dan hingga lima port berdasarkan nomor.
    • Tentukan ALL untuk meneruskan traffic di semua port untuk TCP atau UDP.
    • Gunakan beberapa aturan penerusan dengan alamat IP yang sama untuk meneruskan campuran traffic TCP dan UDP, atau untuk menggunakan lebih dari lima port dengan satu alamat IP:
      • Hanya TCP atau UDP dan 1—5 port: Gunakan satu aturan penerusan.
      • TCP dan UDP serta 1—5 port: Menggunakan beberapa aturan penerusan.
      • 6 port atau lebih dan TCP atau UDP: Gunakan beberapa aturan penerusan.

  • Health check: Lokal, Anda dapat memeriksa responsivitas aplikasi di mesin dengan cara berikut:

Load balancing aktif-aktif

Pada pola load balancing aktif-aktif, VM Anda adalah backend untuk Load Balancer Jaringan passthrough internal. Anda menggunakan alamat IP Load Balancer Jaringan passthrough internal sebagai alamat IP virtual. Traffic didistribusikan secara merata di antara dua backend instance. Traffic yang termasuk dalam sesi yang sama mengarah ke backend instance yang sama seperti yang ditentukan dalam setelan afinitas sesi.

Gunakan pola load balancing aktif-aktif jika aplikasi Anda hanya menggunakan protokol berbasis TCP dan UDP serta tidak memerlukan failover antarkomputer. Gunakan pola dalam skenario ketika aplikasi dapat menjawab permintaan bergantung pada konten permintaan itu sendiri. Jika ada status mesin yang tidak disinkronkan secara konstan, jangan gunakan polanya—misalnya, dalam database primer atau sekunder.

Diagram berikut menunjukkan implementasi pola load balancing aktif-aktif:

Cara klien internal menavigasi pola load balancing aktif-aktif.

Diagram sebelumnya menunjukkan cara klien internal mengakses layanan yang berjalan di dua VM melalui Load Balancer Jaringan passthrough internal. Kedua VM adalah bagian dari grup instance.

Pola load balancing aktif-aktif mengharuskan layanan Anda mengekspos health check menggunakan salah satu protokol health check yang didukung untuk memastikan bahwa hanya VM responsif yang menerima traffic.

Untuk mengetahui contoh implementasi lengkap pola ini, baca contoh deployment dengan Terraform di GitHub.

Load balancing dengan failover dan health check yang terekspos aplikasi

Serupa dengan pola aktif-aktif, load balancing melalui pola health check yang terekspos aplikasi dan failover menggunakan VM Anda sebagai backend untuk Load Balancer Jaringan passthrough internal. Alamat IP ini juga menggunakan alamat IP Load Balancer Jaringan passthrough internal sebagai alamat IP virtual. Untuk memastikan bahwa hanya satu VM yang menerima traffic pada satu waktu, pola ini menerapkan failover untuk Load Balancer Jaringan passthrough internal.

Pola ini direkomendasikan jika aplikasi Anda hanya memiliki traffic TCP atau UDP, tetapi tidak mendukung deployment aktif-aktif. Saat Anda menerapkan pola ini, semua traffic mengalir ke VM utama atau VM failover.

Diagram berikut menunjukkan penerapan load balancing dengan pola failover dan health check yang terekspos aplikasi:

Cara klien internal menavigasi layanan di balik Load Balancer Jaringan passthrough internal.

Diagram sebelumnya menunjukkan cara klien internal mengakses layanan di balik Load Balancer Jaringan passthrough internal. Dua VM berada dalam grup instance terpisah. Satu grup instance ditetapkan sebagai backend utama. Grup instance lainnya ditetapkan sebagai backend failover untuk Load Balancer Jaringan passthrough internal.

Jika layanan pada VM utama menjadi tidak responsif, traffic akan beralih ke grup instance failover. Setelah VM utama kembali responsif, traffic akan otomatis beralih kembali ke layanan backend utama.

Untuk mengetahui contoh implementasi lengkap pola ini, baca contoh deployment dengan Terraform di GitHub.

Load balancing dengan failover dan health check yang terekspos heartbeat

Load balancing dengan pola health check yang mengekspos failover dan health check sama dengan pola sebelumnya. Perbedaannya adalah health check tidak ditampilkan oleh aplikasi itu sendiri, tetapi oleh mekanisme heartbeat yang berjalan di kedua VM.

Diagram berikut menunjukkan penerapan load balancing dengan pola failover dan health check yang terekspos heartbeat:

Cara klien internal mengakses layanan di balik load balancer internal dengan dua VM dalam grup instance yang terpisah.

Diagram ini menunjukkan cara klien internal mengakses layanan di balik load balancer internal. Dua VM berada dalam grup instance terpisah. Satu grup instance ditetapkan sebagai backend utama. Grup instance lainnya ditetapkan sebagai backend failover untuk Load Balancer Jaringan passthrough internal. Keepalived digunakan sebagai mekanisme heartbeat di antara node VM.

Node VM bertukar informasi tentang status layanan menggunakan mekanisme heartbeat yang dipilih. Setiap node VM memeriksa statusnya sendiri dan mengomunikasikan status tersebut ke node jarak jauh. Bergantung pada status node lokal dan status yang diterima oleh node jarak jauh, satu node dipilih sebagai node utama dan satu node dipilih sebagai node cadangan. Anda dapat menggunakan informasi status ini untuk menampilkan hasil health check yang memastikan bahwa node yang dianggap utama dalam mekanisme heartbeat juga menerima traffic dari Load Balancer Jaringan passthrough internal.

Misalnya, dengan Keepalive, Anda dapat memanggil skrip menggunakan variabel konfigurasi notify_master, notify_backup, dan notify_fault yang mengubah status health check. Saat transisi ke status utama (di Keepalive status ini disebut master), Anda dapat memulai aplikasi yang memproses port TCP kustom. Saat bertransisi ke status pencadangan atau kesalahan, Anda dapat menghentikan aplikasi ini. Selanjutnya, health check dapat berupa health check TCP yang berhasil jika port TCP kustom ini terbuka.

Pola ini lebih kompleks daripada pola yang menggunakan failover dengan health check yang diekspos oleh aplikasi. Namun, hal ini memberi Anda lebih banyak kontrol. Misalnya, Anda dapat mengonfigurasinya agar gagal kembali dengan segera atau secara manual sebagai bagian dari implementasi mekanisme heartbeat.

Untuk mengetahui contoh implementasi lengkap dari pola ini yang menggunakan Keepalived, lihat contoh deployment dengan Terraform di GitHub.

Pola yang menggunakan rute Google Cloud

Jika aplikasi Anda menggunakan protokol selain TCP atau UDP di atas IPv4, Anda dapat memigrasikan alamat IP mengambang ke pola berdasarkan rute.

Di bagian ini, penyebutan rute selalu merujuk pada rute Google Cloud yang merupakan bagian dari jaringan VPC. Referensi ke rute statis selalu merujuk pada rute statis di Google Cloud.

Dengan menggunakan salah satu pola ini, Anda dapat menetapkan beberapa rute statis untuk alamat IP tertentu dengan instance yang berbeda sebagai next-hop. Alamat IP ini menjadi alamat IP mengambang yang digunakan semua klien. Alamat IP harus berada di luar semua rentang alamat IP subnet VPC karena rute statis tidak dapat mengganti rute subnet yang ada. Anda harus mengaktifkan penerusan alamat IP pada instance target. Dengan mengaktifkan penerusan alamat IP, Anda dapat menerima traffic untuk alamat IP yang tidak ditetapkan ke instance—dalam hal ini alamat IP mengambang.

Jika Anda ingin rute alamat IP mengambang tersedia dari jaringan VPC yang di-peering, ekspor rute kustom agar rute alamat IP mengambang disebarkan ke semua jaringan VPC peer.

Agar memiliki konektivitas dari jaringan lokal yang terhubung melalui Cloud Interconnect atau Cloud VPN, Anda harus menggunakan pemberitahuan rute alamat IP khusus untuk membuat alamat IP mengambang yang diiklankan secara lokal.

Pola berbasis rute memiliki keuntungan berikut dibandingkan pola berbasis load balancing:

  • Protokol dan Port: Pola berbasis rute berlaku untuk semua traffic yang dikirim ke tujuan tertentu. Pola berbasis load balancing hanya mengizinkan traffic TCP dan UDP.

Pola berbasis rute memiliki kekurangan berikut dibandingkan pola berbasis load balancing:

  • Health check: Health check tidak dapat dilampirkan ke rute Google Cloud. Rute akan digunakan terlepas dari kondisi layanan VM yang mendasarinya. Setiap kali VM berjalan, merutekan traffic akan mengarahkan traffic ke instance meskipun layanan tidak responsif. Melampirkan kebijakan autohealing ke instance tersebut akan menggantikan instance setelah jangka waktu tidak responsif yang Anda tentukan. Namun, setelah instance tersebut dimulai ulang, traffic akan segera dilanjutkan, bahkan sebelum layanan aktif. Kesenjangan layanan ini dapat menyebabkan potensi error layanan saat instance yang tidak responsif masih melayani traffic atau memulai ulang.
  • Waktu failover: Setelah Anda menghapus atau menghentikan instance VM, Compute Engine akan mengabaikan rute statis apa pun yang mengarah ke instance ini. Namun, karena tidak ada health check pada rute, Compute Engine tetap menggunakan rute statis selama instance masih tersedia. Selain itu, penghentian instance memerlukan waktu, sehingga waktu failover jauh lebih tinggi daripada pola berbasis load balancing.
  • Hanya alamat IP mengambang internal: Meskipun Anda dapat mengimplementasikan pola menggunakan load balancing dengan Load Balancer Jaringan passthrough eksternal untuk membuat alamat IP mengambang eksternal, pola berbasis rute hanya berfungsi dengan alamat IP mengambang internal.
  • Pemilihan alamat IP mengambang: Anda dapat menetapkan rute hanya ke alamat IP mengambang internal yang bukan bagian dari subnet apa pun—rute subnet tidak dapat ditimpa di Google Cloud. Lacak alamat IP mengambang ini agar Anda tidak menetapkannya secara tidak sengaja ke jaringan lain.
  • Keterjangkauan rute: Agar alamat IP mengambang internal dapat dijangkau dari jaringan lokal atau jaringan yang di-peering, Anda perlu mendistribusikan rute statis tersebut seperti yang dijelaskan sebelumnya.

Menggunakan perutean equal-cost multipath (ECMP)

Pola rute equal-cost multipath (ECMP) mirip dengan pola load balancing aktif-aktif—traffic didistribusikan secara merata di antara dua backend instance. Saat Anda menggunakan rute statis Google Cloud, ECMP mendistribusikan traffic di antara hop berikutnya dari semua kandidat rute menggunakan hash lima tuple untuk afinitas.

Anda menerapkan pola ini dengan membuat dua rute statis yang memiliki prioritas yang sama dengan instance Compute Engine sebagai next-hop.

Diagram berikut menunjukkan implementasi pola rute ECMP:

Cara klien internal mengakses layanan menggunakan salah satu dari dua rute ECMP.

Diagram sebelumnya menunjukkan cara klien internal mengakses layanan menggunakan salah satu dari dua rute dengan hop berikutnya yang mengarah ke instance VM yang mengimplementasikan layanan tersebut.

Jika layanan pada satu VM tidak responsif, autohealing akan mencoba membuat ulang instance yang tidak responsif. Setelah autohealing menghapus instance, rute yang mengarah ke instance tersebut menjadi tidak aktif sebelum instance baru dibuat. Setelah instance baru ada, rute yang menunjuk ke instance ini segera digunakan secara otomatis dan traffic akan didistribusikan secara merata di antara instance.

Pola rute ECMP mengharuskan layanan Anda mengekspos health check menggunakan protokol yang didukung sehingga autohealing dapat otomatis mengganti VM yang tidak responsif.

Anda dapat menemukan contoh implementasi pola ini menggunakan Terraform di repositori GitHub yang terkait dengan dokumen ini.

Menggunakan rute prioritas yang berbeda

Pola rute prioritas yang berbeda mirip dengan pola sebelumnya, kecuali pola tersebut menggunakan rute statis prioritas yang berbeda, sehingga traffic selalu mengalir ke instance utama, kecuali jika instance tersebut gagal.

Untuk menerapkan pola ini, ikuti langkah-langkah yang sama dalam pola rute ECMP. Saat membuat rute statis, beri rute dengan next-hop yang mengarah ke instance utama dengan nilai prioritas yang lebih rendah (rute utama). Berikan nilai prioritas yang lebih tinggi kepada instance dengan hop berikutnya yang menunjuk ke instance sekunder nilai prioritas lebih tinggi (rute sekunder).

Diagram berikut menunjukkan implementasi berbagai pola rute prioritas: Cara klien internal yang mengakses layanan menggunakan rute utama atau sekunder berdasarkan keadaan jaringan.

Diagram sebelumnya menunjukkan cara klien internal yang mengakses layanan menggunakan rute utama dengan nilai prioritas 500 yang mengarah ke VM 1 sebagai hop berikutnya dalam keadaan normal. Tersedia rute kedua dengan nilai prioritas 1.000 yang mengarah ke VM 2, VM sekunder, sebagai hop berikutnya.

Jika layanan di VM utama menjadi tidak responsif, autohealing akan mencoba membuat ulang instance. Setelah autohealing menghapus instance, dan sebelum instance baru yang dibuatnya muncul, rute utama, dengan instance utama sebagai hop berikutnya, menjadi tidak aktif. Pola tersebut kemudian menggunakan rute dengan instance sekunder sebagai hop berikutnya. Setelah instance utama yang baru muncul, rute utama akan aktif kembali dan semua lalu lintas mengalir ke instance utama tersebut.

Seperti pola sebelumnya, pola rute prioritas yang berbeda mengharuskan layanan Anda mengekspos health check menggunakan protokol yang didukung sehingga autohealing dapat mengganti VM yang tidak responsif secara otomatis.

Anda dapat menemukan contoh implementasi pola ini menggunakan Terraform di repositori GitHub yang menyertai dokumen ini.

Menggunakan mekanisme heartbeat untuk beralih di hop berikutnya dari rute

Jika aplikasi Anda menerapkan mekanisme heartbeat, seperti Keepalived, untuk memantau responsivitas aplikasi, Anda dapat menerapkan pola mekanisme heartbeat untuk mengubah hop berikutnya dari rute statis. Dalam hal ini, Anda hanya menggunakan satu rute statis dengan hop berikutnya yang mengarah ke instance VM utama. Saat failover, mekanisme heartbeat akan mengarahkan hop berikutnya dari rute ke VM sekunder.

Diagram berikut menunjukkan implementasi mekanisme heartbeat untuk mengalihkan pola hop berikutnya pada rute:

Cara klien internal mengakses layanan tempat VM utama dan sekunder bertukar informasi heartbeat.

Diagram sebelumnya menunjukkan cara klien internal mengakses layanan menggunakan rute dengan hop berikutnya yang mengarah ke VM utama. VM utama bertukar informasi heartbeat dengan VM sekunder melalui Keepalived. Pada failover, Keepalived memanggil Cloud Function yang menggunakan panggilan API untuk mengarahkan hop berikutnya ke VM sekunder.

Node menggunakan mekanisme detak jantung yang dipilih untuk bertukar informasi satu sama lain tentang status layanan. Setiap node VM memeriksa statusnya sendiri dan mengomunikasikannya ke node VM jarak jauh. Bergantung pada status node VM lokal dan status yang diterima oleh node jarak jauh, satu node VM dipilih sebagai node utama dan satu node VM dipilih sebagai node cadangan. Setelah menjadi utama, node akan mengarahkan hop berikutnya dari rute untuk alamat IP mengambang ke node itu sendiri. Jika menggunakan Keepalive, Anda dapat memanggil skrip menggunakan variabel konfigurasi notify_master yang menggantikan rute statis menggunakan panggilan API atau Google Cloud CLI.

Mekanisme detak jantung untuk mengalihkan pola hop berikutnya rute tidak mengharuskan VM menjadi bagian dari grup instance. Jika ingin VM otomatis diganti jika gagal, Anda dapat memasukkannya ke dalam grup instance autohealing. Anda juga dapat memperbaiki dan membuat ulang VM yang tidak responsif secara manual.

Memanggil prosedur failover berikut akan memastikan bahwa waktu failover diminimalkan karena traffic beralih setelah satu panggilan API diselesaikan di Langkah 1:

  1. Buat rute statis baru dengan alamat IP mengambang sebagai tujuan dan instance utama baru sebagai hop berikutnya. Rute baru harus memiliki nama rute yang berbeda dan prioritas rute yang lebih rendah (misalnya, 400) dari rute asli.
  2. Hapus rute asli ke VM utama lama.
  3. Buat rute dengan nama dan prioritas yang sama dengan rute yang baru saja Anda hapus. Arahkan ke VM utama baru sebagai hop berikutnya.
  4. Hapus rute statis baru yang Anda buat. Anda tidak membutuhkannya untuk memastikan alur traffic ke VM primer baru.

Karena rute asli diganti, hanya satu rute yang akan aktif pada satu waktu meskipun ada jaringan terpisah.

Menggunakan mekanisme detak jantung untuk mengganti pola prioritas rute, bukan pola berbasis rute lainnya, dapat mengurangi waktu failover. Anda tidak perlu menghapus dan mengganti VM melalui autohealing untuk failover. Selain itu, Anda juga memiliki kontrol lebih besar terkait kapan harus gagal kembali ke server primer asli setelah server utama merespons lagi.

Salah satu kelemahan dari pola ini adalah Anda harus mengelola mekanisme detak jantung sendiri. Mengelola mekanisme dapat menyebabkan lebih banyak kerumitan. Kekurangan lainnya adalah Anda harus memberikan hak istimewa untuk mengubah tabel perutean global ke VM yang menjalankan proses heartbeat atau ke fungsi serverless yang dipanggil dari proses heartbeat. Mengubah tabel perutean global ke fungsi tanpa server lebih aman karena dapat mengurangi cakupan hak istimewa yang diberikan kepada VM. Namun, pendekatan ini lebih kompleks untuk diterapkan.

Untuk mengetahui contoh lengkap implementasi pola ini dengan Keepalived, lihat contoh deployment dengan Terraform di GitHub.

Pola yang menggunakan autohealing

Bergantung pada persyaratan waktu pemulihan, bermigrasi ke instance VM tunggal dapat menjadi opsi yang valid saat menggunakan Compute Engine. Opsi ini tetap berlaku meskipun beberapa server yang menggunakan alamat IP mengambang digunakan secara lokal. Alasan pola ini terkadang dapat digunakan meskipun jumlah VM berkurang adalah karena Anda dapat membuat instance Compute Engine baru dalam hitungan detik atau menit, sementara kegagalan lokal biasanya memerlukan waktu berjam-jam atau bahkan mungkin hari untuk memperbaikinya.

Menggunakan satu instance autohealing

Dengan pola ini, Anda mengandalkan mekanisme autohealing dalam grup instance VM untuk secara otomatis mengganti instance VM yang rusak. Aplikasi ini mengekspos health check dan saat aplikasi tidak responsif, autohealing akan otomatis menggantikan VM.

Diagram berikut menunjukkan penerapan pola instance tunggal autohealing:

Cara klien internal terhubung langsung ke instance Compute Engine.

Diagram sebelumnya menunjukkan cara klien internal terhubung langsung ke instance Compute Engine yang ditempatkan dalam grup instance terkelola dengan ukuran 1 dan dengan autohealing diaktifkan.

Dibandingkan dengan pola yang menggunakan load balancing, pola instance tunggal autohealing memiliki keuntungan berikut:

  • Distribusi traffic: Hanya ada satu instance, sehingga instance tersebut selalu menerima semua traffic.
  • Kemudahan penggunaan: Karena hanya ada satu instance, pola ini yang paling tidak rumit untuk diterapkan.
  • Penghematan biaya: Menggunakan instance VM tunggal, bukan dua, dapat menghemat biaya implementasi menjadi setengahnya.

Namun, pola ini memiliki kekurangan berikut:

  • Waktu failover: Proses ini jauh lebih lambat daripada pola berbasis load balancing. Setelah health check mendeteksi kegagalan mesin, penghapusan dan pembuatan ulang instance yang gagal memerlukan waktu minimal satu menit, tetapi sering kali memerlukan lebih banyak waktu. Pola ini tidak umum di lingkungan produksi. Namun, waktu failover mungkin cukup baik untuk beberapa layanan internal atau eksperimental
  • Reaksi terhadap kegagalan zona: Grup instance terkelola dengan ukuran 1 tidak bertahan jika terjadi kegagalan zona. Untuk merespons kegagalan zona, pertimbangkan untuk menambahkan pemberitahuan Cloud Monitoring saat layanan mengalami kegagalan, dan buat grup instance di zona lain setelah terjadi kegagalan zona. Karena Anda tidak dapat menggunakan alamat IP yang sama dalam kasus ini, gunakan zona pribadi Cloud DNS untuk menangani VM dan mengganti nama DNS ke alamat IP baru.

Anda dapat menemukan contoh implementasi pola ini menggunakan Terraform di repositori GitHub.

Langkah selanjutnya