Bagaimana Perkhidmatan Mengimbangi Beban Global GSLB berfungsi

DIPOS oleh Zevenet | 16 Januari 2018

Gambaran Keseluruhan GSLB

Pada masa kini, ketersediaan perkhidmatan IT yang tinggi adalah satu kemestian dan itulah sebabnya syarikat dan organisasi membangunkan sistem pengkomputeran yang diedarkan di seluruh dunia dan perkhidmatan tuan rumah di lebih dari satu Pusat Data, kerana menawarkan faedah berikut:

Toleransi kesalahan: apabila perkhidmatan yang dihoskan di pusat data gagal, perkhidmatan tersebut berjalan di mana-mana tapak lain yang tersedia.
Pemulihan pusat data automatik: apabila satu pusat data gagal, perkhidmatan tersebut akan dialihkan secara automatik ke pusat data lain yang tersedia.
Imbasan Beban: lalu lintas boleh dioptimumkan dengan mengagihkan beban di antara semua tapak yang ada yang dapat meningkatkan kependaman dan membuat penghantaran perkhidmatan lebih cepat.
Latihan yang lebih baik: trafik aplikasi pelanggan secara langsung dengan pelayan sebenar, tidak perlu melepasi semua data aplikasi melalui pengimbang beban.

Penerapan dan pelaksanaan perkhidmatan IT dalam Awan memerlukan kaedah berdasarkan WAN adalah pilihan terbaik untuk menyediakan penyelesaian ketersediaan tinggi Geo-located. Inilah yang kita panggil Pengimbangan Beban Perkhidmatan Global or GSLB.

Bila menggunakan GSLB

Perkhidmatan GSLB disyorkan untuk digunakan untuk kes penggunaan berikut:

Syarikat yang menjadi tuan rumah perkhidmatan mereka di lebih daripada satu pusat data melalui WAN.
Syarikat yang memerlukan untuk mewujudkan ketersediaan perkhidmatan atau pusat data yang tinggi.
Penyedia Perkhidmatan Internet untuk mencipta perkhidmatan imbasan beban inbound untuk digunakan oleh pengguna mereka.

Pasti, apabila diperlukan untuk berkongsi pengguna dan lalu lintas antara pelayan di seluruh dunia tanpa titik kegagalan GSLB adalah penyelesaian yang tepat.

Bagaimanakah kerja GSLB

GSLB adalah mekanisme pengimbangan beban DNS protokol, ia cepat dan boleh dipercayai kerana ia menggunakan UDP protokol dan tindak balas pelanggan hampir dalam masa nyata.

Dalam permintaan DNS biasa, sebagai contoh www.zvnlb.net, klien menghantar resolusi permintaan DNS ke pelayan DNS dikonfigurasi setempat (contohnya 8.8.8.8 dan 8.8.4.4 ) dan kemudian sistem klien memilih secara rawak salah satu pelayan untuk membuat permintaan dan menghantar pertanyaan.

Pelayan DNS yang dipilih menerima permintaan daripada klien (contohnya, apakah alamat IP dari www.zvnlb.net? ) dan pelayan DNS dikonfigurasi setempat cuba mencari siapa yang bertanggungjawab untuk menyelesaikan zon DNS zvnlb.net.

DNS yang digunakan oleh pelanggan, 8.8.8.8 or 8.8.4.4 dalam kes ini, mengesannya ns1.zvnlb.net dan ns2.zvnlb.net bertanggungjawab terhadap resolusi zon untuk zvnlb.net jadi mereka menghantar pertanyaan DNS yang diterima oleh klien (contohnya, apakah alamat IP www.zvnlb.net? ) kepada salah seorang daripada mereka.

Salah satu pelayan nama sama ada ns1.zvnlb.net or ns2.zvnlb.net menerima pertanyaan DNS daripada 8.8.8.8 or 8.8.4.4 dan kemudian, pelayan nama yang menerima permintaan itu, semak pelayan yang tersedia untuk tuan rumah www.zvnlb.net dan ia akan bertindak balas terhadap pertanyaan DNS dengan senarai pelayan aplikasi yang tersedia untuk menyampaikan permohonan sebenar untuk tuan rumah www.zvnlb.net, maka maklumat ini akhirnya akan diterima oleh klien.

Kini klien akan memilih salah satu pelayan aplikasi secara rawak dari senarai yang diterima dalam pertanyaan DNS dan ia akan menghantar permintaan secara langsung ke aplikasi http://www.zvnlb.net.

Pelayan nama ns1.zvnlb.net (dalam contoh kami, terletak di Frankfurt) dan ns2.zvnlb.net (dalam contoh kami, yang terletak di Toronto) sentiasa menyemak status kesihatan aplikasi sebenar tuan rumah www.zvnlb.net (192.235.113.3 dan 194.23.52.21 dalam kes kami). Jika ns1.zvnlb.net or ns2.zvnlb.net mengesan sebarang masalah menyemak status kesihatan sesetengah pelayan sebenar, maka pelayan tidak tersedia akan dinyahaktifkan untuk masa tertentu dan alamat IPnya tidak akan disenaraikan dalam pertanyaan DNS sehingga ia tersedia lagi.

Rajah berikut menunjukkan trafik DNS yang diterangkan dengan keupayaan GSLB.

Trafik DNS dengan ciri GSLB

Mengkonfigurasi GSLB untuk Pemulihan Bencana pusat data

Konfigurasi ini disyorkan untuk perkhidmatan yang memerlukan ketersediaan Pusat Data untuk Pemulihan Bencana, jadi jika semua perkhidmatan syarikat tertentu berada dalam satu pusat data dan pusat data tersebut gagal maka sistem akan memindahkan semua perkhidmatan yang terkena ke pusat data yang tersedia .

Sila ikuti contoh sebenar konfigurasi GSLB untuk membina pusat data pasif aktif untuk Pemulihan Bencana.

Kami telah mengerahkan dua Zevenet Load Balancers di dua pusat data di laman web yang berbeza, Frankfurt 159.89.7.124 dan Toronto 159.203.12.35 dan kami mempunyai perkhidmatan web yang bertindak balas terhadap tuan rumah DNS www.zvnlb.net, dikonfigurasi dalam Pusat Data 1 dan Pusat Data 2. Reka bentuk seni bina ini akan membenarkan untuk menghantar semua trafik pelanggan ke Pusat Data 1 tetapi jika gagal, maka ia akan mengalihkan pelanggan ke Pusat Data 2.

Untuk mencapai konfigurasi ini ikuti prosedur di bawah.

Sambung ke panel web Zevenet di Pusat Data 1 (Frankfurt untuk kes kami), klik di menu utama GSLB modul dan buat yang baru Ladang, dalam contoh kita akan dipanggil DNS1-Frankfurt di dalam port maya 53.

mewujudkan ladang GSLB dalam satu pusat data

Apabila ladang dibuat, sila edit, dan pergi ke tab zon dan buat zon DNS yang akan diuruskan oleh modul GSLB, dalam kes ini zvnlb.net, seperti berikut:

Buat zon GSLB di pusat data pertama

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

Zon edit GSLB di pusat data pertama

Perhatikan bahawa ns1 dan ns2 adalah Pelayan Nama yang bertanggungjawab terhadap resolusi DNS untuk zon tersebut zvnlb.net (dalam kes kami, satu perkhidmatan GSLB di Frankfurt dan satu lagi di Toronto).

Kemudian, sambung ke panel web Zevenet di Pusat Data 2, dalam menu utama pilih GSLB dan buat yang baru Ladang, dalam kes kita akan dipanggil DNS2-Toronto di dalam port maya 53.

mewujudkan ladang GSLB di pusat data DR kedua

Edit ladang GSLB baru dan pergi ke tab zon, buat di sini zon DNS yang akan diuruskan oleh perkhidmatan GSLB ini zvnlb.net seperti berikut:

mengkonfigurasi zon GSLB di pusat data kedua

Sebaik sahaja zon baru ini diwujudkan sila buat konfigurasi pertama seperti berikut:

Zon edit GSLB di Toronto

Seperti halnya GSLB di Malaysia Pusat Data 1, Pelayan Nama n1 dan n2 akan menunjuk kepada perkhidmatan GSLB dalam kedua-duanya Pusat Data 1 dan Pusat Data 2, Masing-masing.

Kemudian klik pada tab Perkhidmatan Kami dan buat perkhidmatan baru, contohnya webpriority:

mewujudkan perkhidmatan GSLB dengan keutamaan

Pilih Algoritma pilihan Keutamaan: Sambungan selalu menjadi yang paling penting dan konfigurasikan perkhidmatan seperti berikut:

Prioriti Perkhidmatan sunting GSLB

Mulakan semula ladang untuk menerapkan perubahan. Diperlukan untuk menerapkan konfigurasi perkhidmatan GSLB yang sama di kedua pusat data.

Perhatikan bahawa jika Penjaga Ladang tidak dikonfigurasi untuk memohon pemeriksaan kesihatan, perkhidmatan GSLB menggunakan lalai check_tcp ke port TCP yang ditakrifkan dalam medan cek kesihatan dalam konfigurasi perkhidmatan.

Untuk mendayakan perkhidmatan baru, pergi ke zon yang dibuat (zvnlb.net dalam kes kita) dan buat yang baru Sumber. Kemudian buatnya dengan memilih yang baru Servis seperti yang ditunjukkan di bawah.

GSLB menggunakan Keutamaan Perkhidmatan

Akhirnya, simpan perubahan. Diperlukan untuk menerapkan konfigurasi ini di kedua Pusat Data.

Pada ketika ini, tuan rumah www.zvnlb.net diuruskan oleh modul GSLB di Keutamaan mod, jadi semua lalu lintas akan dihantar ke Pusat Data 1 dan kemudian, jika gagal, lalu lintas akan dialihkan ke yang lain yang tersedia Pusat Data 2.

TTL telah dikonfigurasi menjadi 5, ini adalah jenis tarikh luput yang dimasukkan ke dalam catatan DNS. TTL berfungsi untuk memberitahu pelayan rekursif atau penyelesai tempatan berapa lama ia harus menyimpan catatan tersebut dalam cache. Oleh itu, nilai yang lebih rendah dikonfigurasikan dengan lebih cepat perubahan dikesan.

Memohon kaedah ini, kami dapat menambah pusat data sebanyak yang diperlukan dengan memasukkan pelayan Nama baru dengan perkhidmatan GSLB.

Permintaan DNS berikut menunjukkan konfigurasi Nameservers untuk zvnlb.net dan resolusi DNS untuk tuan rumah 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-dua pelayan nama menggunakan alamat IP maya yang dikonfigurasikan di ladang GSLB.

Sekarang, gunakan pelayan DNS semasa anda untuk menyelesaikan host (contohnya www) di zon 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, kini hos 188.166.230.211 adalah nod aplikasi sebenar yang aktif dalam Pusat Data 1. Sebaik sahaja tuan rumah tidak dapat dijangkau (contohnya, perkhidmatan http di 188.166.230.211 turun) resolusi DNS akan berubah seperti yang ditunjukkan di bawah.

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

Sebaik sahaja pelayan aplikasi gagal, resolusi DNS akan mengubah tuan rumah kepada Pusat Data 2. Setelah tuan rumah di Pusat Data 1 adalah gagal kembali akan digunakan secara automatik.

Mengkonfigurasi GSLB untuk pusat data aktif-aktif

Ketersediaan yang tinggi dengan keutamaan mod adalah pilihan yang baik untuk sistem Pemulihan Bencana tetapi Pusat Data sandaran yang digunakan untuk pemulihan tidak mempunyai penggunaan yang terlalu banyak, jadi biasanya lebih efisien untuk memuatkan keseimbangan semua lalu lintas antara data yang tersedia pusat-pusat.

Untuk kes seperti itu, sila gunakan kaedah perkongsian untuk perkhidmatan GSLB anda dipanggil Round Robin Load Balancing seperti yang ditunjukkan dalam contoh untuk perkhidmatan baru yang dipanggil web:

mewujudkan perkhidmatan GSLB dengan pusat data aktif dan aktif

Sekarang, masukkannya di zon zvnlb.net dan ubah konfigurasi sumber www seperti berikut:

mewujudkan sumber dns untuk perkhidmatan GSLB dengan pusingan robin

Simpan perubahan dan mulakan semula ladang jika diminta.

Untuk mengujinya, cuba selesaikan tuan rumah www.zvnlb.net dan output akan kelihatan seperti yang ditunjukkan:

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 bahawa resolver DNS mengembalikan kedua-dua pelayan aplikasi dan bukannya seperti kes pemulihan Bencana.

Apabila hos mempunyai kegagalan, resolusi DNS akan berubah secara automatik. Lihat di bawah apa yang berlaku.

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

Pelayan aplikasi tidak dapat dinyahaktifkan dari senarai tindak balas DNS.

Sebaik sahaja tuan rumah 188.166.230.211 tersedia lagi, ia akan dimasukkan semula dalam resolusi DNS.

Melantik zon dalam perkhidmatan Zevenet GSLB

Dalam kes zon awam (contohnya zvnlb.net) yang memberikan perkhidmatan GSLB sebagai penyelesai pelayan nama yang perlu dikenali oleh pelayan DNS awam untuk domain tersebut, maka ia wajib mendaftarkan alamat IP awam yang digunakan oleh perkhidmatan GSLB di pendaftar domain anda (seperti NameCheap, Goddady atau yang lain) . Pautan berikut menerangkan cara mendaftar IP GSLB sebagai NameServers dalam Prosedur Pendaftar Domain.

Daftar Host sebagai NamaServer

Berikutan prosedur yang diberikan, anda perlu mendaftar ns1.zvnlb.net dan ns2.zvnlb.net dengan IP yang diberikan.

Mewujudkan subzon khusus untuk GSLB

Sekiranya tidak mungkin untuk menyerahkan resolusi DNS ke perkhidmatan GSLB Zevenet, konfigurasi yang dijelaskan di bawah dapat dilakukan. Contoh berikut menunjukkan cara membina a subzone untuk zvnlb.net yang menunjuk kepada NameServers subzone baru ini dalam perkhidmatan 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 pelayan nama yang dikonfigurasikan dan menawarkan perkhidmatan resolusi DNS untuk zon tersebut zvnlb.net, zon ini berada di bawah perkhidmatan DNS awam Bind9 dan kami ingin menawarkan keupayaan GSLB untuk sesetengah tuan rumah infrastruktur kami, jadi kami memutuskan untuk membuat subzone DNS cluster.zvnlb.net dan konfigurasi ladang 2 GSLB seperti DNS Nameservers untuk tujuan ini.

Kami telah mencipta subzone untuk domain kami cluster.zvnlb.net dalam pelayan DNS Bind9 kami seperti berikut:

Buat subnet DNS bind9

Sekarang ikuti bahagian ini Melantik zon dalam perkhidmatan Zevenet GSLB untuk memastikan 159.89.7.124 dan 159.203.12.35 dalam contoh kami sebagai pelayan nama yang dikenali untuk zon cluster.zvnlb.net oleh pelayan DNS awam.

Kemudian, anda boleh menggunakan konfigurasi seperti yang dijelaskan untuk domain zvnlb.net dalam bahagian di atas Mengkonfigurasi GSLB untuk pemulihan bencana pusat data.

Menunjuk Hos di DNS kita sendiri merujuk kepada perkhidmatan GSLB

Dalam bahagian sebelumnya, kami telah mencipta tuan rumah yang dinamakan www.zvnlb.net load balancing dalam mod keutamaan dan round robin, jadi kami dapat menggunakan semula konfigurasi ini untuk menawarkan kemampuan GSLB ke DNS Nameserver lain yang tidak menyokong ciri ini secara lalai.

Untuk mencapai konfigurasi ini, kita hanya perlu membuat yang baru Sumber di zon DNS yang tidak menyokong pilihan GSLB (misalnya zevenet.io diuruskan oleh Bind9) seperti a Nama Kanunikal or CNAME seperti yang ditunjukkan di bawah:

Mewujudkan CNAME ke zon GSLB

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

Ambil perhatian bahawa contoh ini dilakukan dalam pelayan DNS Bind9 tetapi Nama Kanaan atau CNAMES adalah konfigurasi hos DNS yang disokong oleh pelaksanaan perkhidmatan pelayan DNS.

Penjelasan ringkas ini menunjukkan bahawa perkhidmatan GSLB dapat digunakan walaupun Perkhidmatan DNS kami sekarang tidak menawarkan kemampuan GSLB, hanya meneruskan penerusan resolusi host yang diberikan di zon bukan GSLB ke perkhidmatan GSLB di Zevenet Load Balancer.

Berkongsi pada:

Dokumentasi di bawah syarat-syarat Lesen Dokumentasi Bebas GNU.

Adakah artikel ini berguna?

Artikel yang berkaitan