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.

Penerimaan dan pelaksanaan perkhidmatan IT dalam Awan memerlukan kaedah berasaskan WAN sebagai pilihan terbaik untuk menyediakan penyelesaian ketersediaan tinggi yang terletak di lokasi geografi. Itulah yang kami panggil Pengimbangan Beban Perkhidmatan Global atau 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 ialah mekanisme pengimbangan beban pada protokol DNS , ia pantas dan boleh dipercayai kerana ia menggunakan protokol UDP dan tindak balas klien hampir dalam masa nyata.

Dalam permintaan DNS yang biasa, contohnya www.zvnlb.net , klien menghantar resolusi permintaan DNS ke pelayan DNS yang dikonfigurasikan setempat (contohnya 8.8.8.8 dan 8.8.4.4 ) dan kemudian sistem klien memilih secara rawak salah satu pelayan untuk dibuat terhadap permintaan dan menghantar pertanyaan.

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

DNS yang digunakan oleh klien, 8.8.8.8 atau 8.8.4.4 dalam kes ini, mengesan bahawa ns1.zvnlb.net dan ns2.zvnlb.net bertanggungjawab terhadap resolusi zon untuk zvnlb.net supaya ia menghantar pertanyaan DNS yang diterima oleh klien (contohnya, apakah alamat IP www.zvnlb.net ?) kepada salah seorang daripadanya.

Salah satu pelayan nama sama ada ns1.zvnlb.net atau ns2.zvnlb.net menerima pertanyaan DNS daripada 8.8.8.8 atau 8.8.4.4 dan kemudian, pelayan nama yang menerima permintaan tersebut, menyemak pelayan yang tersedia untuk hos www.zvnlb.net dan ia akan bertindak balas terhadap pertanyaan DNS dengan senarai pelayan aplikasi yang tersedia untuk melayani aplikasi sebenar untuk hos www.zvnlb.net , justeru maklumat ini akhirnya akan diterima oleh klien.

Sekarang klien akan memilih secara rawak salah satu pelayan aplikasi daripada senarai yang diterima dalam pertanyaan DNS dan ia akan menghantar terus permintaan tersebut kepada aplikasi http://www.zvnlb.net.

Pelayan nama ns1.zvnlb.net (dalam contoh kami, terletak di Frankfurt) dan ns2.zvnlb.net (dalam contoh kami, terletak di Toronto) sedang menyemak status kesihatan aplikasi sebenar hos www.zvnlb.net ( 192.235.113.3 dan 194.23.52.21 dalam kes kami). Jika ns1.zvnlb.net atau ns2.zvnlb.net mengesan sebarang masalah menyemak status kesihatan beberapa pelayan sebenar, maka pelayan yang tidak tersedia akan dinyahaktifkan untuk tempoh tertentu dan alamat IPnya tidak akan disenaraikan dalam pertanyaan DNS sehingga ia tersedia semula.

Rajah berikut menunjukkan trafik DNS yang diterangkan dengan keupayaan 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 RELIANOID Pengimbang Beban merentas dua pusat data di tapak 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.

Sambungkan ke RELIANOID panel web dalam 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.

Setelah ladang dicipta, sila editnya, dan pergi ke tab Zon dan cipta zon DNS yang akan diuruskan oleh modul GSLB, dalam kes ini zvnlb.net , seperti berikut:

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

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

Kemudian, sambung ke RELIANOID panel web dalam 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.

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

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

Seperti kes GSLB dalam Pusat Data 1 , Pelayan Nama n1 dan n2 akan masing-masing menunjuk ke perkhidmatan GSLB dalam Pusat Data 1 dan Pusat Data 2.

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

Pilih pilihan Algoritma Keutamaan: Sambungan sentiasa kepada keutamaan yang paling tersedia dan konfigurasikan perkhidmatan seperti berikut:

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

Ambil perhatian bahawa jika Farm Guardian tidak dikonfigurasikan untuk menggunakan sebarang pemeriksaan kesihatan, perkhidmatan GSLB menggunakan check_tcp lalai pada port TCP yang ditakrifkan dalam medan pemeriksaan kesihatan dalam konfigurasi perkhidmatan.

Untuk mendayakan perkhidmatan baharu, pergi ke zon yang dicipta ( zvnlb.net dalam kes kami) dan cipta Sumber baharu . Kemudian ciptakannya dengan memilih Perkhidmatan baharu seperti yang ditunjukkan di bawah.

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

Pada ketika ini, hos www.zvnlb.net diuruskan oleh modul GSLB dalam mod Keutamaan , jadi semua trafik akan dihantar ke Pusat Data 1 dan kemudian, jika gagal, trafik akan dialihkan ke Pusat Data 2 lain yang tersedia.

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 hos www.zvnlb.net.

pengguna@pelanggan:# hos -t ns zvnlb.net pelayan nama zvnlb.net ns2.zvnlb.net. pelayan nama zvnlb.net ns1.zvnlb.net.

Kedua-dua pelayan nama menggunakan alamat IP maya yang dikonfigurasikan di ladang GSLB.

Sekarang, gunakan pelayan DNS semasa anda untuk menyelesaikan hos (contohnya www ) dalam zon ini:

pengguna@pelanggan:# nslookup www.zvnlb.net Pelayan: 8.8.8.8 Alamat: 8.8.8.8#53 Jawapan tidak berwibawa: Nama: www.zvnlb.net Alamat: 188.166.230.211

Seperti yang ditunjukkan, pada masa ini hos 188.166.230.211 ialah nod aplikasi sebenar yang aktif dalam Pusat Data 1. Sebaik sahaja hos tidak dapat dihubungi (contohnya, perkhidmatan http dalam 188.166.230.211 tergendala) resolusi DNS akan berubah seperti yang ditunjukkan di bawah.

pengguna@pelanggan:# nslookup www.zvnlb.net Pelayan: 8.8.8.8 Alamat: 8.8.8.8#53 Jawapan tidak berwibawa: Nama: www.zvnlb.net Alamat: 139.59.186.84

Sebaik sahaja pelayan aplikasi gagal berfungsi, resolusi DNS akan menukar hos kepada Pusat Data 2. Sebaik sahaja hos dalam Pusat Data 1 diaktifkan, fail-back 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 sedemikian, sila gunakan kaedah perkongsian untuk perkhidmatan GSLB anda yang dipanggil Round Robin Load Balancing seperti yang ditunjukkan dalam contoh untuk perkhidmatan baharu yang dipanggil web :

Sekarang, tambahkannya dalam zon zvnlb.net dan ubah konfigurasi sumber www seperti berikut:

Simpan perubahan dan mulakan semula ladang jika diminta.

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

pengguna@klien:# nslookup www.zvnlb.net Pelayan: 8.8.8.8 Alamat: 8.8.8.8#53 Jawapan tidak berwibawa: Nama: www.zvnlb.net Alamat: 188.166.230.211 Nama: www.zvnlb.net Alamat: 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 Pelayan: 8.8.8.8 Alamat: 8.8.8.8#53 Jawapan tidak berwibawa: Nama: www.zvnlb.net Alamat: 139.59.186.84

Pelayan aplikasi tidak dapat dinyahaktifkan dari senarai tindak balas DNS.

Sebaik sahaja hos 188.166.230.211 tersedia semula, ia akan dimasukkan semula dalam resolusi DNS.

Mewakilkan zon dalam RELIANOID perkhidmatan GSLB #

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

Daftar Host sebagai NamaServer

Mengikuti prosedur yang diberikan, anda perlu mendaftarkan ns1.zvnlb.net dan ns2.zvnlb.net dengan IP yang diberikan.

Mewujudkan subzon khusus untuk GSLB #

Sekiranya tidak mungkin untuk mewakilkan resolusi DNS kepada perkhidmatan GSLB RELIANOID, konfigurasi yang diterangkan di bawah boleh dilakukan. Contoh berikut menunjukkan cara membina a subzone khususnya zvnlb.net yang menunjuk kepada NameServers subzone baru ini dalam perkhidmatan GSLB.

Nod 1 (contohnya ns1.zvnlb.net dengan IP 162.243.5.109 ) dan Nod 2 (contohnya ns2.zvnlb.net dengan IP 178.62.233.104 ) ialah Pelayan Nama yang dikonfigurasikan dan menawarkan perkhidmatan penyelesaian DNS untuk zon zvnlb.net , zon ini berada di bawah perkhidmatan DNS awam Bind9 dan kami ingin menawarkan keupayaan GSLB untuk beberapa hos infrastruktur kami, jadi kami memutuskan untuk mencipta subzon DNS cluster.zvnlb.net dan mengkonfigurasi 2 ladang GSLB seperti Pelayan Nama DNS untuk tujuan ini.

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

Sekarang ikuti bahagian ini Mewakilkan zon dalam RELIANOID perkhidmatan 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 hos bernama www.zvnlb.net pengimbangan beban dalam mod keutamaan dan robin bulat, jadi kami boleh menggunakan semula konfigurasi ini untuk menawarkan keupayaan GSLB kepada Pelayan Nama DNS lain yang tidak menyokong ciri ini secara lalai.

Untuk mencapai konfigurasi ini, kita hanya perlu mencipta Sumber baharu dalam zon DNS yang tidak menyokong pilihan GSLB (contohnya relianoid.io diuruskan oleh Bind9) seperti Nama Kanunikal atau CNAME seperti yang ditunjukkan di bawah:

Sebaik sahaja perubahan digunakan, www.relianoid.io akan menghala ke www.zvnlb.net , tetapi jika resolusi hos www.zvnlb.net berubah, maka secara automatik www.relianoid.io juga akan berubah.

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 boleh digunakan walaupun Perkhidmatan DNS semasa kami tidak menawarkan keupayaan GSLB, hanya memajukan resolusi hos yang diberikan dalam zon bukan GSLB kepada perkhidmatan GSLB dalam RELIANOID Pengimbang Beban.