Ikhtisar GSLB

Saat ini, ketersediaan tinggi layanan TI adalah suatu keharusan dan itulah alasan perusahaan dan organisasi mengembangkan sistem komputasi yang didistribusikan di seluruh dunia dan menjadi tuan rumah layanan di lebih dari satu Pusat Data, karena menawarkan manfaat berikut:

Toleransi kesalahan: ketika layanan yang di-host di pusat data gagal, layanan akan berjalan di salah satu situs lain yang tersedia.
Pemulihan pusat data otomatis: ketika satu pusat data gagal, layanan dialihkan secara otomatis ke pusat data lain yang tersedia.
Penyeimbang beban: lalu lintas dapat dioptimalkan dengan mendistribusikan beban di antara semua situs yang tersedia meningkatkan latensi dan membuat pengiriman layanan lebih cepat.
Latensi yang Ditingkatkan: lalu lintas aplikasi klien secara langsung dengan server nyata, tidak perlu untuk melewatkan semua data aplikasi melalui load balancer.

Adopsi dan implementasi layanan TI di Cloud mensyaratkan bahwa metode berdasarkan WAN adalah opsi terbaik untuk memberikan solusi ketersediaan tinggi yang berlokasi di Geo. Itulah yang kami sebut Penyeimbangan Beban Layanan Global or GSLB.

Kapan menggunakan GSLB

Layanan GSLB disarankan untuk digunakan untuk kasus penggunaan berikut:

Perusahaan yang meng-host layanan mereka di lebih dari satu pusat data melalui WAN.
Perusahaan yang mengharuskan untuk membuat ketersediaan layanan atau pusat data yang tinggi.
Penyedia Layanan Internet untuk membuat layanan penyeimbangan beban masuk untuk digunakan oleh pengguna mereka.

Pastinya, ketika diperlukan untuk berbagi pengguna dan lalu lintas antar server di seluruh dunia tanpa titik kegagalan, GSLB adalah solusi yang tepat.

Bagaimana cara kerja GSLB

GSLB adalah mekanisme penyeimbangan beban DNS protokol, cepat dan dapat diandalkan karena digunakan UDP protokol dan respons klien hampir secara real time.

Dalam permintaan DNS yang umum, misalnya www.zvnlb.net, klien mengirimkan resolusi permintaan DNS ke server DNS lokal yang dikonfigurasi (misalnya 8.8.8.8 serta 8.8.4.4 ) dan kemudian sistem klien memilih secara acak salah satu server untuk melawan permintaan dan untuk mengirim permintaan.

Server DNS yang dipilih menerima permintaan dari klien (misalnya, apa alamat IP untuk www.zvnlb.net? ) dan server DNS lokal yang dikonfigurasi mencoba untuk menemukan siapa yang bertanggung jawab untuk menyelesaikan zona DNS zvnlb.net.

DNS yang digunakan oleh klien, 8.8.8.8 or 8.8.4.4 dalam hal ini, mendeteksi itu ns1.zvnlb.net serta ns2.zvnlb.net bertanggung jawab atas resolusi zona untuk zvnlb.net jadi mereka mengirim permintaan DNS yang diterima oleh klien (misalnya, apa alamat IP dari www.zvnlb.net? ) ke salah satu dari mereka.

Salah satu server nama ns1.zvnlb.net or ns2.zvnlb.net menerima permintaan DNS dari 8.8.8.8 or 8.8.4.4 dan kemudian, server nama yang menerima permintaan, memeriksa server yang tersedia untuk tuan rumah www.zvnlb.net dan itu akan menanggapi permintaan DNS dengan daftar server aplikasi yang tersedia untuk melayani aplikasi nyata untuk tuan rumah www.zvnlb.net, maka informasi ini akhirnya akan diterima oleh klien.

Sekarang klien akan memilih secara acak salah satu server aplikasi dari daftar yang diterima dalam permintaan DNS dan itu akan mengirim langsung permintaan ke aplikasi http://www.zvnlb.net.

Server nama ns1.zvnlb.net (dalam contoh kami, berlokasi di Frankfurt) dan ns2.zvnlb.net (dalam contoh kami, berlokasi di Toronto) terus memeriksa status kesehatan aplikasi sebenarnya dari tuan rumah www.zvnlb.net (192.235.113.3 serta 194.23.52.21 dalam kasus kami). Jika ns1.zvnlb.net or ns2.zvnlb.net mendeteksi masalah memeriksa status kesehatan beberapa server sebenarnya, maka server yang tidak tersedia akan dinonaktifkan untuk waktu tertentu dan alamat IP-nya tidak akan terdaftar dalam permintaan DNS sampai tersedia kembali.

Diagram berikut menunjukkan lalu lintas DNS yang dijelaskan dengan kemampuan GSLB.

Mengkonfigurasi GSLB untuk Pemulihan Bencana pusat data

Konfigurasi ini direkomendasikan untuk layanan yang membutuhkan ketersediaan tinggi Pusat Data untuk Pemulihan Bencana, jadi jika semua layanan perusahaan tertentu berada dalam satu pusat data dan pusat data tersebut gagal maka sistem akan memindahkan semua layanan yang terkena dampak ke pusat data lain yang tersedia .

Ikuti contoh nyata dari konfigurasi GSLB ini untuk membangun pusat data pasif-aktif untuk Pemulihan Bencana.

Kami telah menyebarkan dua Zevenet Load Balancers di dua pusat data di berbagai situs, Frankfurt 159.89.7.124 dan Toronto 159.203.12.35 dan kami memiliki layanan web yang menanggapi host DNS www.zvnlb.net, dikonfigurasi dalam Pusat Data 1 serta Pusat Data 2. Desain arsitektur ini akan memungkinkan untuk mengirim semua lalu lintas klien ke Internet Pusat Data 1 tetapi jika gagal maka pengalihan klien ke Pusat Data 2.

Untuk mencapai konfigurasi ini ikuti prosedur di bawah ini.

Hubungkan ke panel web Zevenet di Pusat Data 1 (Frankfurt untuk kasus kami), klik di menu utama GSLB modul dan buat yang baru Tanah pertanian, dalam contoh kita akan dipanggil DNS1-Frankfurt di port virtual 53.

Setelah peternakan dibuat, harap edit, dan buka tab zona dan buat zona DNS yang akan dikelola oleh modul GSLB, dalam hal ini zvnlb.net, sebagai berikut:

Setelah zona ini dibuat, buat konfigurasi pertama seperti yang ditunjukkan di bawah ini:

Perhatikan bahwa ns1 serta ns2 adalah Name Server yang bertanggung jawab atas resolusi DNS untuk zona tersebut zvnlb.net (dalam kasus kami, satu layanan GSLB di Frankfurt dan lainnya di Toronto).

Kemudian, sambungkan ke panel web Zevenet di Pusat Data 2, di menu utama pilih GSLB dan buat yang baru Tanah pertanian, dalam kasus kami akan dipanggil DNS2-Toronto di port virtual 53.

Edit peternakan GSLB baru dan buka tab zona, buat di sini zona DNS yang akan dikelola oleh layanan GSLB ini untuk zvnlb.net sebagai berikut:

Setelah zona baru ini dibuat, harap buat konfigurasi pertama sebagai berikut:

Seperti halnya GSLB di Pusat Data 1, Server Nama n1 serta n2 akan menunjuk ke layanan GSLB di keduanya Pusat Data 1 serta Pusat Data 2, Masing-masing.

Kemudian klik pada tab Layanan dan buat layanan baru, misalnya prioritas web:

Pilih Algoritma Option Prioritas: Koneksi selalu ke yang paling prio tersedia dan konfigurasikan layanan sebagai berikut:

Mulai ulang pertanian untuk menerapkan perubahan. Diperlukan untuk menerapkan konfigurasi layanan GSLB yang sama di kedua pusat data.

Perhatikan bahwa jika Penjaga Pertanian tidak dikonfigurasikan untuk menerapkan pemeriksaan kesehatan apa pun, layanan GSLB menggunakan standar check_tcp ke port TCP yang ditentukan dalam bidang pemeriksaan kesehatan dalam konfigurasi layanan.

Untuk mengaktifkan layanan baru, pergi ke zona yang dibuat (zvnlb.net dalam kasus kami) dan buat yang baru Sumber. Kemudian buat dengan memilih yang baru Jasa seperti yang ditunjukkan di bawah ini.

Terakhir, simpan perubahannya. Ini diperlukan untuk menerapkan konfigurasi ini di kedua Pusat Data.

Pada titik ini, tuan rumah www.zvnlb.net dikelola oleh modul GSLB di Prioritas mode, sehingga semua lalu lintas akan dikirim ke Pusat Data 1 dan kemudian, jika gagal, lalu lintas akan dialihkan ke yang lain yang tersedia Pusat Data 2.

TTL telah dikonfigurasi ke 5, itu adalah semacam tanggal kedaluwarsa yang dimasukkan pada catatan DNS. TTL berfungsi untuk memberi tahu server rekursif atau penyelesai lokal berapa lama ia harus menyimpan catatan tersebut dalam cache-nya. Jadi nilai yang lebih rendah dikonfigurasi lebih cepat perubahannya terdeteksi.

Menerapkan metode ini, kami dapat menambahkan sebanyak mungkin pusat data dengan memasukkan Server Nama baru dengan layanan GSLB.

Permintaan DNS berikut menunjukkan konfigurasi server nama untuk zvnlb.net dan resolusi DNS untuk host www.zvnlb.net.

user@client:# host -t ns zvnlb.net
zvnlb.net name server ns2.zvnlb.net.
zvnlb.net name server ns1.zvnlb.net.

Kedua server nama menggunakan alamat IP virtual yang dikonfigurasi di pertanian GSLB.

Sekarang, gunakan server DNS Anda saat ini untuk menyelesaikan host (misalnya www) di zona ini:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211

Seperti yang ditunjukkan, saat ini tuan rumah 188.166.230.211 adalah simpul aplikasi nyata aktif di Pusat Data 1. Segera tuan rumah tidak dapat dijangkau (misalnya, layanan http di 188.166.230.211 sedang down) resolusi DNS akan berubah seperti yang ditunjukkan di bawah ini.

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Segera setelah server aplikasi gagal, resolusi DNS akan mengubah host ke Pusat Data 2. Setelah tuan rumah di Pusat Data 1 terserah gagal-kembali akan diterapkan secara otomatis.

Mengkonfigurasi GSLB untuk pusat data aktif-aktif

Ketersediaan tinggi dengan prioritas mode adalah pilihan yang baik untuk sistem Pemulihan Bencana tetapi Pusat Data cadangan yang digunakan untuk pemulihan tidak memiliki terlalu banyak penggunaan, jadi biasanya lebih efisien untuk memuat keseimbangan semua lalu lintas di antara data yang tersedia pusat.

Untuk kasus seperti itu, silakan gunakan metode berbagi untuk layanan GSLB Anda yang disebut Round Robin Load Balancing seperti yang ditunjukkan dalam contoh untuk layanan baru bernama jaringan:

Sekarang, tambahkan di zona zvnlb.net dan ubah konfigurasi sumber daya www sebagai berikut:

Simpan perubahan dan mulai ulang tambak jika diminta.

Untuk mengujinya, cobalah untuk menyelesaikan host www.zvnlb.net dan hasilnya akan terlihat seperti ini:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211
Name:	www.zvnlb.net
Address: 139.59.186.84

Perhatikan bahwa resolver DNS mengembalikan kedua server aplikasi, bukan yang seperti kasus Disaster Recovery.

Setelah host mengalami kegagalan, resolusi DNS akan berubah secara otomatis. Lihat di bawah ini apa yang terjadi.

root@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Server aplikasi yang tidak tersedia dinonaktifkan dari daftar respons DNS.

Begitu tuan rumah 188.166.230.211 tersedia lagi, itu akan dimasukkan kembali dalam resolusi DNS.

Mendelegasikan zona dalam layanan Zevenet GSLB

Dalam kasus zona publik (misalnya zvnlb.net) yang memberikan layanan GSLB sebagai resolver server nama yang perlu dikenali oleh server DNS publik untuk domain tersebut, kemudian diperlukan untuk mendaftarkan alamat IP publik yang digunakan oleh layanan GSLB di pencatatan domain Anda (seperti NameCheap, Goddady, atau lainnya) . Tautan berikut menjelaskan cara mendaftarkan IP GSLB sebagai Server Nama dalam Prosedur Registrar Domain.

Daftarkan Host sebagai NameServer

Mengikuti prosedur yang diberikan Anda harus mendaftar ns1.zvnlb.net serta ns2.zvnlb.net dengan IP yang diberikan.

Membuat subzone khusus untuk GSLB

Seandainya tidak mungkin mendelegasikan resolusi DNS ke layanan GSLB Zevenet, konfigurasi yang dijelaskan di bawah ini dapat dilakukan. Contoh berikut menunjukkan cara membuat file subzone untuk zvnlb.net yang menunjuk ke NameServers dari subzone baru ini di layanan GSLB.

Node 1 (sebagai contoh ns1.zvnlb.net dengan IP 162.243.5.109) Dan Node 2 (sebagai contoh ns2.zvnlb.net dengan IP 178.62.233.104) adalah server nama yang dikonfigurasikan dan menawarkan layanan resolusi DNS untuk zona tersebut zvnlb.net, zona ini berada di bawah layanan DNS publik Bind9 dan kami ingin menawarkan kemampuan GSLB untuk beberapa host infrastruktur kami, jadi kami memutuskan untuk membuat subzone DNS cluster.zvnlb.net dan konfigurasikan peternakan 2 GSLB seperti DNS Nameservers untuk tujuan ini.

Kami telah membuat subzone untuk domain kami cluster.zvnlb.net di Server DNS Bind9 kami sebagai berikut:

Sekarang ikuti bagian ini Mendelegasikan zona dalam layanan Zevenet GSLB untuk menjaga 159.89.7.124 serta 159.203.12.35 dalam contoh kami sebagai server nama yang dikenal untuk zona tersebut cluster.zvnlb.net oleh Server DNS publik.

Kemudian, Anda dapat menerapkan konfigurasi seperti dijelaskan untuk domain zvnlb.net pada bagian di atas Mengkonfigurasi GSLB untuk pemulihan bencana pusat data.

Menunjuk Host di DNS kami sendiri yang dirujuk ke layanan GSLB

Di bagian sebelumnya kami telah membuat host bernama www.zvnlb.net load balancing dalam mode prioritas dan round robin, sehingga kami dapat menggunakan kembali konfigurasi ini untuk menawarkan kemampuan GSLB ke DNS Nameserver lain yang tidak mendukung fitur ini secara default.

Untuk mencapai konfigurasi ini, kita hanya perlu membuat yang baru Sumber di zona DNS yang tidak mendukung opsi GSLB (misalnya zevenet.io dikelola oleh Bind9) seperti a Nama Kanonik or CNAME seperti yang ditunjukkan di bawah ini:

Setelah perubahan diterapkan, www.zevenet.io akan menunjuk ke www.zvnlb.net, tetapi jika resolusi tuan rumah www.zvnlb.net berubah secara otomatis www.zevenet.io akan berubah juga.

Perhatikan bahwa contoh ini dilakukan di server DNS Bind9 tetapi Nama Canonical atau CNAMES adalah konfigurasi host DNS yang didukung oleh implementasi layanan server DNS.

Penjelasan sederhana ini menunjukkan bahwa layanan GSLB dapat digunakan meskipun Layanan DNS kami saat ini tidak menawarkan kemampuan GSLB, hanya meneruskan resolusi dari host yang diberikan di zona non GSLB ke layanan GSLB di Zevenet Load Balancer.