Arsitektur load balancing global menggunakan kebijakan perutean DNS

Last reviewed 2023-01-04 UTC

Dokumen ini menjelaskan cara menggabungkan beberapa load balancer regional dengan kebijakan perutean DNS Google untuk membuat arsitektur load balancing global. Dokumen ini ditujukan untuk insinyur jaringan, arsitek solusi, dan profesional operasi. Anda dianggap memiliki pengetahuan dasar tentang Google Compute Engine dan sudah memahami konsep jaringan seperti load balancer dan pencarian DNS.

Pengantar

Saat mem-build layanan global yang diimplementasikan sebagai aplikasi yang berjalan di beberapa region, Anda dapat menggunakan geolokasi kebijakan perutean DNS agar memiliki endpoint DNS global untuk regional Anda load balancer. Dalam pendekatan ini, Anda membuat endpoint global yang mengarahkan traffic ke layanan lokal terdekat.

Bergantung pada jenis load balancer yang digunakan, Anda mungkin dapat mencapai skenario ini dengan opsi load balancing berbasis proxy global. Namun, untuk beberapa kasus penggunaan, Anda harus menggunakan produk load balancing regional—misalnya, jika layanan Anda menyalurkan traffic UDP. Kebijakan perutean DNS geolokasi juga dapat membantu penyediaan endpoint DNS tunggal untuk aplikasi campuran yang menggunakan Google Cloud bersama penyedia layanan cloud lainnya atau bersama deployment lokal.

Arsitektur

Diagram berikut menunjukkan contoh arsitektur yang menggunakan tiga load balancing regional di tiga region berbeda. Region digabungkan menggunakan kebijakan perutean DNS.

Arsitektur tempat Cloud DNS mengarahkan traffic ke load balancer internal regional berdasarkan lokasi klien.

Diagram sebelumnya menunjukkan cara klien di Oregon, Jerman, dan Singapura melakukan pencarian DNS ke Cloud DNS untuk www.example.com. Permintaan dirutekan ke load balancer regional yang dekat dengan setiap klien untuk menjangkau aplikasi yang dihosting di tiga region berbeda.

Kasus penggunaan untuk kebijakan perutean DNS geolokasi

Bagian ini membahas kasus penggunaan berikut untuk menggunakan kebijakan perutean DNS geolokasi untuk membuat layanan global dari beberapa load balancing regional:

Layanan internal yang dapat diakses dan didistribusikan secara global
Endpoint DNS global untuk layanan eksternal yang mendukung TCP dan UDP
Endpoint DNS global untuk layanan hybrid

Layanan internal yang dapat diakses dan didistribusikan secara global

Anda dapat membuat layanan internal yang dapat diakses secara global dan terdistribusi secara global dengan menggabungkan beberapa load balancer internal regional menggunakan kebijakan perutean DNS geolokasi. Anda dapat menggunakan Load Balancer Jaringan passthrough internal atau Load Balancer Aplikasi internal. Tanpa kebijakan pemilihan rute DNS, Load Balancer Aplikasi internal hanya dapat menggunakan endpoint regional. Dengan Load Balancer Jaringan passthrough internal yang menggunakan akses global, Anda dapat menyediakan layanan secara global; dalam hal ini, backend hanya bisa berada di satu region. Namun, saat menggunakan kebijakan perutean DNS, Anda dapat memiliki backend di beberapa region.

Diagram berikut menampilkan arsitektur ini:

Arsitektur untuk klien internal tempat Cloud DNS mengirimkan traffic ke instance Load Balancer Jaringan passthrough internal yang berada di region tempat klien berada.

Diagram sebelumnya menunjukkan cara klien internal di beberapa region me-resolve service.corp.example.com menggunakan Cloud DNS. Klien selalu menerima respons yang memiliki alamat IP milik Load Balancer Jaringan passthrough internal yang ada di region klien. Load balancer mengarah ke aplikasi yang berada di region yang sama. (Dalam contoh ini, aplikasi berjalan di Google Kubernetes Engine (GKE), tetapi itu bukan kondisi yang diperlukan.) Klien mengirim traffic aplikasi ke instance lokal aplikasi, tetapi semua menggunakan endpoint DNS service.corp.example.com yang sama.

Anda dapat membuat konfigurasi ini menggunakan langkah-langkah berikut:

Anda membuat load balancer internal di setiap region. Jika menggunakan Load Balancer Jaringan passthrough internal, Anda harus mengaktifkan akses global untuk memastikan bahwa klien dari region lain dapat terhubung ke layanan.
Anda membuat kebijakan perutean DNS. Dalam kebijakan ini, Anda menetapkan jenis ke GEO dan menetapkan nilai --routing-policy-data ke daftar region target yang dipetakan ke load balancer internal yang terkait. Anda dapat membuat penyiapan yang diilustrasikan dalam diagram menggunakan perintah berikut:
```
gcloud beta dns record-sets create service.corp.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \
    --enable-health-checking
```

Dalam contoh ini, data dibuat dengan nilai TTL selama 30 detik untuk memastikan bahwa klien sering memperbarui data DNS jika kebijakan berubah.

Saat Anda menggunakan kebijakan perutean DNS, setiap klien akan menerima respons DNS yang berisi alamat IP load balancer internal dalam region. Jika berada di luar region tempat load balancer internal ditentukan, klien akan menerima alamat IP load balancer internal yang berada di region terdekat.

Kebijakan perutean DNS mengarahkan traffic berdasarkan region load balancer internal terdekat. Jika lebih dari 80% backend di region tersebut tidak responsif, dan jika Anda menggunakan fitur health check dengan kebijakan pemilihan rute DNS geografis, traffic akan gagal di seluruh region.

Jika tidak mewajibkan failover antar-region, Anda dapat mengubah perintah seperti berikut:

Hapus flag --enable-health-checking.
Ganti nama setiap aturan penerusan untuk load balancer internal dengan alamat IP-nya.

Endpoint global untuk layanan eksternal yang mendukung TCP dan UDP

Anda juga dapat membuat endpoint DNS global untuk layanan eksternal dengan menggabungkan beberapa load balancer eksternal regional menggunakan kebijakan perutean DNS geolokasi. Kasus penggunaan yang paling umum adalah menggunakan Load Balancer Jaringan passthrough eksternal untuk aplikasi berbasis TCP atau UDP. Pendekatan ini sangat berguna untuk aplikasi yang menggunakan UDP, karena tidak ada opsi load balancing global yang tersedia di Google Cloud untuk UDP.

Untuk aplikasi yang menggunakan traffic TCP yang didukung oleh Load Balancer Jaringan proxy eksternal atau Load Balancer Aplikasi eksternal , Anda mungkin dapat menggunakan instance load balancer global tersebut, bukan menggunakan endpoint DNS. Load balancer ini menyediakan load balancing lintas region menggunakan anycast, yang menyediakan satu alamat IP sebagai frontend untuk semua instance backend Anda.

Keuntungan menggunakan opsi load balancing global dibandingkan endpoint DNS adalah sebagai berikut:

Failover langsung dilakukan. Failover terjadi tanpa perubahan yang terlihat dalam alur traffic dari sisi pengguna.
Pemilihan rute internet menentukan target load balancing. Protokol {i>routing<i} internet meneruskan traffic berdasarkan jalur terpendek, bukan Cloud DNS yang memilih lokasi target.
Load Balancing Lintas Region Load balancing global Google mendukung failover lintas-region. Sebaliknya, tidak ada health check dengan kebijakan perutean DNS saat Anda menggunakan Load Balancer Jaringan passthrough eksternal.

Oleh karena itu, sebaiknya gunakan opsi load balancing global Google saat aplikasi Anda berbasis TCP dan didukung oleh produk tersebut.

Diagram berikut menunjukkan arsitektur yang menggunakan endpoint DNS global:

Arsitektur untuk klien eksternal tempat klien mendapatkan alamat IP untuk instance Load Balancer Jaringan passthrough internal yang berada di region tempat klien.

Diagram sebelumnya menunjukkan cara klien eksternal di beberapa region me-resolve www.example.com menggunakan Cloud DNS. Klien menerima respons dengan alamat IP yang termasuk dalam load balancer TCP/UDP jaringan yang ada di region klien. Selanjutnya, klien dapat terhubung ke aplikasi yang berjalan di region yang sama. Setiap klien mengirimkan traffic aplikasi ke instance lokal layanan, tetapi semuanya menggunakan endpoint DNS www.example.com yang sama.

Anda dapat membuat konfigurasi ini menggunakan langkah-langkah berikut:

Anda membuat load balancer TCP/UDP jaringan di setiap region.
Anda membuat kebijakan perutean DNS. Dalam kebijakan ini, Anda menetapkan jenis ke GEO dan menetapkan nilai --routing-policy-data ke daftar region target yang dipetakan ke load balancer TCP/UDP jaringan yang sesuai. Anda dapat membuat penyiapan yang diilustrasikan dalam diagram menggunakan perintah berikut:
```
gcloud dns record-sets create www.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
```

Setelah kebijakan ini diterapkan, saat klien membuat permintaan DNS, setiap klien menerima respons DNS yang berisi alamat IP Load Balancer Jaringan passthrough eksternal yang berada di region yang paling dekat dengan klien tersebut.

Endpoint global www.example.com tidak dapat digunakan untuk melakukan failover secara otomatis untuk traffic antar-region, karena saat Anda menggunakan Load Balancer Jaringan passthrough eksternal, tidak ada health check. Anda bertanggung jawab untuk memicu failover secara manual dengan mengubah data DNS.

Kasus penggunaan lain yang dapat ditangani dengan pendekatan ini adalah Anda memiliki aplikasi yang menggunakan HTTP(S) dengan persyaratan regional untuk data, tetapi masih ingin menyalurkan data menggunakan endpoint global. Anda dapat menerapkan skenario ini dengan menggabungkan beberapa instance Load Balancer Aplikasi eksternal regional menggunakan kebijakan perutean DNS geolokasi. Jika tidak memiliki persyaratan regional, Anda dapat menggunakan Load Balancer Aplikasi eksternal global.

Endpoint DNS global untuk layanan hybrid

Dalam beberapa kasus, Anda dapat memberikan endpoint tunggal untuk aplikasi campuran dengan menggunakan kebijakan perutean DNS geolokasi.

Diagram berikut menampilkan arsitektur ini:

Arsitektur untuk skenario hybrid dengan Cloud DNS mengirimkan traffic ke instance Load Balancer Jaringan passthrough internal untuk klien yang berada di Asia dan Amerika Serikat, serta ke load balancer lokal untuk klien yang berada di Eropa.

Diagram sebelumnya menunjukkan cara klien eksternal di beberapa region me-resolve www.example.com menggunakan Cloud DNS. Cloud DNS mengarahkan pengguna internet di Asia dan AS ke alamat IP yang termasuk dalam load balancer TCP/UDP jaringan yang berada di region yang dekat dengan mereka. Aplikasi yang ditunjuk oleh load balancing sedang berjalan di GKE di region yang sama. Untuk pengguna internet di Eropa, Cloud DNS menampilkan alamat IP yang mengarah ke load balancer di pusat data lokal Eropa, dengan aplikasi yang dihosting di GKE di VMware. (Dalam contoh ini, aplikasi berjalan di GKE di VMware dan GKE, tetapi itu bukan kondisi yang diperlukan.)

Anda dapat membuat konfigurasi ini menggunakan langkah-langkah berikut:

Anda membuat load balancer TCP/UDP jaringan dan load balancer lokal di setiap region.
Anda membuat kebijakan pemilihan rute DNS. Dalam kebijakan ini, Anda menetapkan jenis ke GEO dan menetapkan nilai --routing-policy-data ke daftar region target yang dipetakan ke load balancer TCP/UDP jaringan yang sesuai. Anda dapat membuat penyiapan yang diilustrasikan dalam diagram menggunakan perintah berikut:
```
gcloud dns record-sets create www.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
```

Dengan menyetel tanda --routing-policy-data, Anda dapat membuat Cloud DNS menampilkan alamat IP yang berbeda berdasarkan region Google Cloud terdekat. Namun, Anda tidak dapat merutekan traffic berdasarkan negara atau wilayah geografis klien yang tepat. Pada contoh sebelumnya, sebagian besar pengguna dikirim ke sebuah region atau ke pusat data lokal yang ada di benua mereka. Namun, algoritma yang digunakan Cloud DNS untuk menentukan region Google Cloud terdekat mungkin tidak sesuai dengan batas negara atau geografi tertentu. Oleh karena itu, Anda tidak dapat menggunakan kebijakan perutean DNS geolokasi untuk kasus penggunaan kepatuhan.

Kasus penggunaan lain yang memerlukan lebih banyak perincian daripada perincian tingkat benua yang ditunjukkan dalam contoh ini tidak mungkin dilakukan dengan pendekatan campuran ini. Misalnya, jika Anda memiliki pusat data lokal di negara yang tidak memiliki region Google Cloud, Anda tidak dapat mengirim traffic secara lokal untuk pengguna dari negara atau region tersebut —Anda hanya dapat mengonfigurasi load balancer untuk menampilkan alamat IP berdasarkan region Google Cloud terdekat. Jika ingin membatasi atau merutekan traffic berdasarkan lokasi geografis atau negara yang tepat, Anda dapat menggunakan penyedia pihak ketiga yang menawarkan layanan load balancing server global (GSLB) berbasis DNS.

Langkah selanjutnya

Mengelola kebijakan pemilihan rute DNS.
Praktik terbaik DNS.
Fitur load balancer.
Mengoptimalkan latensi aplikasi dengan load balancing.
Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.