iT邦幫忙

DAY 17
5

高有效性 (High Availability) 初論 30 講系列 第 17

高有效性簡介30篇: GSLB 實作篇 (17)

  • 分享至 

  • xImage
  •  

**無論是 CDN Content Delivery Network 或 GSLB Global Server Load Balance, 第一步靠的就是 DNS 面對不同的使用者導到不同的 IDC 去達成, 這個判斷不是埋在應用程式去判斷, 不然就是靠 Server 來判斷.

而現在判斷的方式也越來越容易做到了:

  1. GeoIP 是最簡單的方式.
  2. 各個 IDC 有個 Echo Server 來做 Ping, 看 Response 或 Hup 來判斷.
  3. 從 Routing 來去算距離與權重 Weight, 以及看流量與價格判斷.**
    當然這些都是基本概念, 但這篇要講的是實作.

無論如何實作, 一定有一個前提, 就是要知道那個使用者來問, 或那個 DNS Server 來問, 然後我們算出最佳的 IDC 回應那個 IP, 而後那個 IDC 應該也是有自己的 SLB 與 Cluster.

所以一定有一個流程就是記錄那個 DNS (Table 1) 來我們 DNS Server 問這個 Domain Name 的 IP, 然後我們判斷出來後給他, 只是這個判斷可能須要一段時間, 若是用 GeoIP 來算就應該很快, 但這個就要先建一個 Table 2:

Table 1: DNS Server IP
Table 2: Geo IP (Country) vs IDC (Array)

當然也要有一個 IDC 列表去記錄那些 IDC, 這理論可以併在 Table 2, 也可以獨立 Tabel 3.

Table 3: IDC List (Array)

若是用 GeoIP 的話, 再怎樣查表速度應該很快, 甚至在某方面連 Table 1 都不須要, 若是用後面的方法, 計算可能須要數秒鐘, 雖然這很快, 但不代表使用者是可以接受的, 因此我們通常會給一個 Default IDC.

Parameter 1: Default IDC

這個 Default IDC 可以是用計算能力最高的, 或是最接近 Primary DB 的 IDC, 這個也不見得是在算之前, 也有可能是無法判斷的狀況用得上.

理論上每一個 IDC 須要去計算回應跟 DNS Server 之間的 IP Routing 或 Response Time/Hups, 這也可能是一個表也可能是一個 Array.

Table 4: IDC Echo Server List (Array)

然後理論上會有幾隻程式:

Program 1: DNS Server
Program 2: Decision Main Program
Program 3: Echo Daemon

通常在後台只要這三隻程式就很夠了, 接下來只是可能要再加一個 Process Control 去用 Batch 去維護這些 Table 的正確性與有效性, 所以通常須要有兩件事:

Parameter 2: Time To Live
Batch 1: Update Latest Result
Column 1: Lastest Update Time

而通常 Program 1 往往是可以用 MyDNS 來去改, 或者是在 SDB 上去加工, 一個是可以很獨立運作, 一個是可以跟 Bind 做結合.

這系統已經做過一次, 當時是部份用 C, 部份是用 Python 完成, 而採用的方式是 MyDNS Solution, 若我再寫一次的話我會採用 SDB 的方式吧.


上一篇
高有效性簡介30篇: DNS in HA (16)
下一篇
高有效性簡介30篇: 書介, DNS and Bind (18)
系列文
高有效性 (High Availability) 初論 30 講30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
食夢黑貘
iT邦研究生 3 級 ‧ 2011-10-27 23:18:11


有人問說為甚麼不放 Source Code 或 SQL Schema, 事實上一放就暴了, 若有興趣的再找我要吧.

我要留言

立即登入留言