Traffic Director dengan grup endpoint jaringan konektivitas hybrid

Traffic Director mendukung lingkungan yang berada di luar Google Cloud, termasuk pusat data lokal dan cloud publik lainnya yang dapat Anda jangkau menggunakan konektivitas hybrid.

Anda mengonfigurasi Traffic Director sehingga mesh layanan dapat mengirim traffic ke endpoint yang berada di luar Google Cloud. Endpoint ini mencakup hal berikut:

  • Load balancer lokal.
  • Aplikasi server pada instance virtual machine (VM) di cloud lain.
  • Tujuan lain mana pun yang dapat Anda jangkau dengan konektivitas hybrid dan yang dapat dijangkau dengan alamat IP dan port.

Tambahkan alamat IP dan port setiap endpoint ke grup endpoint jaringan konektivitas hybrid (NEG). NEG konektivitas hybrid adalah jenis NON_GCP_PRIVATE_IP_PORT.

Dukungan Traffic Director untuk layanan lokal dan multi-cloud memungkinkan Anda melakukan hal berikut:

  • Arahkan traffic secara global, termasuk ke endpoint layanan lokal dan multi-cloud.
  • Menghadirkan manfaat Traffic Director dan mesh layanan—termasuk kemampuan seperti penemuan layanan dan pengelolaan traffic lanjutan—ke layanan yang berjalan di infrastruktur Anda yang sudah ada di luar Google Cloud.
  • Menggabungkan kemampuan Traffic Director dengan Cloud Load Balancing untuk menghadirkan layanan jaringan Google Cloud ke multi-lingkungan.

NEG konektivitas hybrid (NON_GCP_PRIVATE_IP_PORT NEG) tidak didukung dengan klien gRPC tanpa proxy.

Kasus penggunaan

Traffic Director dapat mengonfigurasi jaringan antara layanan berbasis VM dan berbasis container di berbagai lingkungan, termasuk:

  • Google Cloud
  • Pusat data lokal
  • Cloud publik lainnya

Merutekan traffic mesh ke lokasi lokal atau cloud lain

Kasus penggunaan paling sederhana untuk fitur ini adalah pemilihan rute traffic. Aplikasi Anda menjalankan proxy Traffic Director Envoy . Traffic Director memberi tahu klien tentang layanan Anda dan endpoint setiap layanan.

Mengarahkan traffic mesh ke lokasi lokal atau cloud lain.
Mengarahkan traffic mesh ke lokasi lokal atau cloud lainnya (klik untuk memperbesar)

Pada diagram sebelumnya, saat aplikasi Anda mengirim permintaan ke layanan on-prem, klien Traffic Director akan memeriksa permintaan keluar dan memperbarui tujuannya. Tujuan ditetapkan ke endpoint yang terkait dengan layanan on-prem (dalam hal ini, 10.2.0.1). Permintaan kemudian akan melalui Cloud VPN atau Cloud Interconnect ke tujuan yang dimaksud.

Jika perlu menambahkan lebih banyak endpoint, Anda akan memperbarui Traffic Director untuk menambahkannya ke layanan Anda. Anda tidak perlu mengubah kode aplikasi.

Memigrasikan layanan lokal yang ada ke Google Cloud

Dengan mengirimkan traffic ke endpoint non-Google Cloud, Anda dapat merutekan traffic ke lingkungan lain. Anda dapat menggabungkan kemampuan ini dengan pengelolaan traffic lanjutan untuk memigrasikan layanan antarlingkungan.

Bermigrasi dari lokasi lokal ke Google Cloud.
Bermigrasi dari lokasi lokal ke Google Cloud (klik untuk memperbesar)

Diagram sebelumnya memperluas pola sebelumnya. Daripada mengonfigurasi Traffic Director untuk mengirim semua traffic ke layanan on-prem, Anda dapat mengonfigurasi Traffic Director untuk menggunakan pembagian traffic berbasis bobot guna membagi traffic di dua layanan.

Pembagian traffic memungkinkan Anda memulai dengan mengirimkan 0% traffic ke layanan cloud dan 100% ke layanan on-prem. Anda kemudian dapat secara bertahap meningkatkan proporsi traffic yang dikirim ke layanan cloud. Terakhir, Anda akan mengirim 100% traffic ke layanan cloud, dan Anda dapat menghentikan layanan on-prem.

Layanan edge jaringan Google Cloud untuk deployment lokal dan multi-cloud

Terakhir, Anda dapat menggabungkan fungsi ini dengan solusi jaringan Google Cloud yang sudah ada. Google Cloud menawarkan berbagai layanan jaringan, seperti load balancing eksternal global dengan Google Cloud Armor untuk perlindungan distributed denial of service (DDoS), yang dapat Anda gunakan dengan Traffic Director untuk menghadirkan kemampuan baru ke layanan lokal atau multi-cloud Anda. Yang paling penting, Anda tidak perlu mengekspos layanan lokal atau multi-cloud ini ke internet publik.

Deployment yang mencakup berbagai lingkungan.
Deployment yang mencakup beberapa lingkungan (klik untuk memperbesar)

Pada diagram sebelumnya, traffic dari klien di internet publik memasuki jaringan Google Cloud dari load balancer Google Cloud, seperti Load Balancer Aplikasi eksternal global kami. Saat traffic mencapai load balancer, Anda dapat menerapkan layanan edge jaringan, seperti perlindungan DDoS Google Cloud Armor atau autentikasi pengguna Identity-Aware Proxy (IAP). Untuk mengetahui informasi selengkapnya, lihat Layanan edge jaringan untuk deployment multi-lingkungan.

Setelah Anda menerapkan layanan ini, traffic akan berhenti sejenak di Google Cloud, tempat aplikasi atau proxy mandiri (yang dikonfigurasi oleh Traffic Director) meneruskan traffic di Cloud VPN atau Cloud Interconnect ke layanan lokal Anda.

Resource dan arsitektur Google Cloud

Bagian ini memberikan informasi latar belakang tentang resource Google Cloud yang dapat Anda gunakan untuk menyediakan mesh layanan yang dikelola Traffic Director untuk lingkungan lokal dan multi-cloud.

Diagram berikut menggambarkan resource Google Cloud yang memungkinkan dukungan layanan lokal dan multi-cloud untuk Traffic Director. Resource utamanya adalah NEG dan endpoint jaringannya. Resource lainnya adalah resource yang Anda konfigurasi sebagai bagian dari penyiapan Traffic Director standar. Untuk mempermudah, diagram tidak menampilkan opsi seperti beberapa layanan backend global.

Resource Compute Engine untuk layanan lokal dan multi-cloud.
Resource Compute Engine untuk layanan lokal dan multi-cloud (klik untuk memperbesar)

Saat mengonfigurasi Traffic Director, Anda menggunakan resource API layanan backend global untuk membuat layanan. Layanan adalah konstruksi logis yang menggabungkan hal berikut:

  1. Kebijakan yang akan diterapkan saat klien mencoba mengirim traffic ke layanan.
  2. Satu atau beberapa backend atau endpoint yang menangani traffic yang ditujukan untuk layanan.

Layanan lokal dan multi-cloud sama seperti layanan lain yang dikonfigurasi Traffic Director. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hybrid untuk mengonfigurasi endpoint layanan ini. NEG ini memiliki jenis endpoint jaringan yang ditetapkan ke NON_GCP_PRIVATE_IP_PORT. Endpoint yang Anda tambahkan ke NEG konektivitas hybrid harus berupa kombinasi IP:port yang valid dan dapat dijangkau oleh klien Anda—misalnya, melalui konektivitas hybrid seperti Cloud VPN atau Cloud Interconnect.

Setiap NEG memiliki jenis endpoint jaringan dan hanya dapat berisi endpoint jaringan dari jenis yang sama. Jenis ini menentukan hal berikut:

  • Tujuan tempat layanan Anda dapat mengirimkan traffic.
  • Perilaku pemeriksaan kesehatan.

Saat membuat NEG, konfigurasikan sebagai berikut sehingga Anda dapat mengirim traffic ke tujuan lokal atau multi-cloud.

  • Tetapkan jenis endpoint jaringan ke NON_GCP_PRIVATE_IP_PORT. Ini mewakili alamat IP yang dapat dijangkau. Jika alamat IP ini berada di infrastruktur lokal atau di penyedia cloud lain, alamat tersebut harus dapat dijangkau dari Google Cloud menggunakan konektivitas hybrid, seperti konektivitas yang disediakan oleh Cloud VPN atau Cloud Interconnect.
  • Tentukan zona Google Cloud yang meminimalkan jarak geografis antara Google Cloud dan lingkungan lokal atau multi-cloud Anda. Misalnya, jika menghosting layanan di lingkungan lokal di Frankfurt, Jerman, Anda dapat menentukan zona Google Cloud europe-west3-a saat membuat NEG.

Perilaku health check untuk endpoint jaringan jenis ini berbeda dengan perilaku health check untuk jenis endpoint jaringan lainnya. Meskipun jenis endpoint jaringan lainnya menggunakan sistem health check terpusat Google Cloud, endpoint jaringan NON_GCP_PRIVATE_IP_PORT menggunakan mekanisme health check terdistribusi Envoy. Untuk mengetahui detail selengkapnya, lihat bagian Batasan dan pertimbangan lainnya.

Pertimbangan konektivitas dan jaringan

Klien Traffic Director Anda, seperti proxy Envoy, harus dapat terhubung ke Traffic Director di trafficdirector.googleapis.com:443. Jika Anda kehilangan konektivitas ke bidang kontrol Traffic Director, hal berikut akan terjadi:

  • Klien Traffic Director yang ada tidak dapat menerima pembaruan konfigurasi dari Traffic Director. Mereka akan terus beroperasi berdasarkan konfigurasinya saat ini.
  • Klien Traffic Director baru tidak dapat terhubung ke Traffic Director. Mereka tidak dapat menggunakan mesh layanan hingga konektivitas terhubung kembali.

Jika Anda ingin mengirim traffic antara Google Cloud dan lingkungan lokal atau multi-cloud, lingkungan tersebut harus terhubung melalui konektivitas hybrid. Sebaiknya gunakan koneksi ketersediaan tinggi yang diaktifkan oleh Cloud VPN atau Cloud Interconnect.

Alamat IP dan rentang alamat IP subnet Google Cloud, cloud lainnya, dan lokal tidak boleh tumpang-tindih.

Batasan dan pertimbangan lainnya

Berikut adalah batasan penggunaan NEG konektivitas hybrid.

Setelan proxyBind

Anda hanya dapat menetapkan nilai proxyBind saat membuat targetHttpProxy. Anda tidak dapat memperbarui targetHttpProxy yang sudah ada.

Konektivitas dan gangguan pada konektivitas

Untuk mengetahui detail tentang persyaratan dan batasan konektivitas, lihat bagian Pertimbangan konektivitas dan jaringan.

Jenis backend campuran

Layanan backend dapat memiliki backend VM atau NEG. Jika layanan backend memiliki backend NEG, semua NEG harus berisi jenis endpoint jaringan yang sama. Anda tidak dapat memiliki layanan backend dengan beberapa NEG, yang masing-masing memiliki jenis endpoint yang berbeda.

Peta URL dapat memiliki aturan host yang di-resolve ke berbagai layanan backend. Anda mungkin memiliki layanan backend dengan NEG konektivitas hybrid saja (dengan endpoint lokal) dan layanan backend dengan NEG mandiri (dengan endpoint GKE). Peta URL dapat berisi aturan, misalnya, pemisahan traffic berbasis bobot, yang membagi traffic di setiap layanan backend ini.

Menggunakan NEG dengan endpoint jenis NON_GCP_PRIVATE_IP_PORT dengan backend Google Cloud

Anda dapat membuat layanan backend dengan NEG konektivitas hybrid yang mengarah ke backend di Google Cloud. Namun, kami tidak merekomendasikan pola ini karena NEG konektivitas hybrid tidak mendapatkan manfaat dari pemeriksaan kondisi terpusat. Untuk penjelasan tentang health check terpusat dan health check terdistribusi, lihat bagian Health check.

Pendaftaran endpoint

Jika ingin menambahkan endpoint ke NEG, Anda harus memperbarui NEG. Hal ini dapat dilakukan secara manual atau diotomatiskan dengan menggunakan Google Cloud NEG REST API atau Google Cloud CLI.

Saat instance layanan baru dimulai, Anda dapat menggunakan Google Cloud API untuk mendaftarkan instance tersebut dengan NEG yang dikonfigurasi. Saat menggunakan grup instance terkelola (MIG) atau GKE (di Google Cloud), pengontrol MIG atau NEG secara otomatis menangani pendaftaran endpoint.

Health check

Saat Anda menggunakan NEG konektivitas hybrid, perilaku health check berbeda dengan perilaku health check terpusat standar dalam hal berikut:

  • Untuk endpoint jaringan jenis NON_GCP_PRIVATE_IP_PORT, Traffic Director akan mengonfigurasi kliennya untuk menggunakan bidang data guna menangani health check. Untuk menghindari pengiriman permintaan ke backend yang tidak responsif, instance Envoy melakukan health check sendiri dan menggunakan mekanismenya sendiri.
  • Karena bidang data Anda menangani health check, Anda tidak dapat menggunakan Konsol Google Cloud, API, atau Google Cloud CLI untuk mengambil status health check.

Dalam praktiknya, menggunakan NON_GCP_PRIVATE_IP_PORT berarti hal berikut:

  • Karena setiap klien Traffic Director menangani health check secara terdistribusi, Anda mungkin melihat peningkatan traffic jaringan karena health check. Peningkatan ini bergantung pada jumlah klien Traffic Director dan jumlah endpoint yang diperlukan setiap klien untuk health check. Contoh:
    • Saat Anda menambahkan endpoint lain ke NEG konektivitas hybrid, klien Traffic Director yang ada mungkin akan mulai melakukan health check pada endpoint dalam NEG konektivitas hybrid.
    • Saat Anda menambahkan instance lain ke mesh layanan (misalnya, instance VM yang menjalankan kode aplikasi Anda serta klien Traffic Director), instance baru mungkin akan mulai memeriksa endpoint di NEG konektivitas hybrid.
    • Traffic jaringan karena health check meningkat pada rasio kuadrat (O(n^2)).

Jaringan VPC

Mesh layanan diidentifikasi secara unik berdasarkan nama jaringan Virtual Private Cloud (VPC). Klien Traffic Director menerima konfigurasi dari Traffic Director berdasarkan jaringan VPC yang ditentukan dalam konfigurasi bootstrap. Oleh karena itu, meskipun mesh Anda sepenuhnya berada di luar pusat data Google Cloud, Anda harus memberikan nama jaringan VPC yang valid dalam konfigurasi bootstrap.

Akun layanan

Dalam Google Cloud, bootstrap Envoy default dikonfigurasi untuk membaca informasi akun layanan dari salah satu atau kedua lingkungan deployment Compute Engine dan GKE. Saat menjalankan operasi di luar Google Cloud, Anda harus secara eksplisit menentukan akun layanan, nama jaringan, dan nomor project di bootstrap Envoy Anda. Akun layanan ini harus memiliki izin yang memadai untuk terhubung dengan Traffic Director API.

Langkah selanjutnya