CDN - 技術面

要決定使用者應該要到哪組 server 通常有這些方法:

  • GeoDNS
  • Anycast
  • HTTP Redirect (會比較差)

這幾種不衝突,常見的是前兩者搭配著用。將 DNS server IP anycast,當下載者要抓某個 domain 時,近的 server 就會知道大致的區域。再配合 GeoDNS 判斷使用者的 IP address 適合到哪個 node。

不過這些問題對 HiNet 就很麻煩。(留到現場講)

再來就是 reverse proxy cache 所產生的問題,這個部份再想看看要怎麼寫。

CDN - 為什麼要用 CDN

用 CDN 最常見的兩個理由:

  • 速度:下載者可以就近取得檔案。這對於小檔案 (css/javascript) 會有很大的幫助。(也許要解釋瀏覽器 HTTP 的運作,並抓一張 Firebug 的畫面分析?)
  • 效率:因為下載者透過 CDN 下載,可以減少原始 server 的負荷。

另外還有其他的理由:

  • 成本:這個留到會場講。
  • 安全:以分散架構對抗 DDoS 攻擊。

CDN - 什麼是 CDN

剛剛才發現 OSDC.TW 2009 有 50mins 的時間,先把一些資料整理出來,做投影片會比較方便。(大概會做 25mins 的投影片吧)

CDN (Content delivery network) 被稱為「內容傳遞網路」是一種內容快取機制,能提供高效能 (包括使用者以及內容提供者)、高可靠度、低成本的內容傳遞架構。不過,這幾個優點並不一定同時會發生。

以對使用者高效能這點,通常指的是「就近取得檔案」,內容提供者事先將檔案推到全球的 CDN 節點,在台灣的下載者儘量從台灣取得檔案,在日本或香港的下載者也儘量從當地的伺服器取得檔案。

由於在全球有多個節點,所以當某個節點不通時,可以導到次近的節點以達到高可靠度。

對內容提供者高效能的部份,是因為內容提供者不需要在一個 data center 上建立非常粗的水管。舉例來說,如果傳遞需要 100Gbps 的流量,利用 CDN 架構,每個 data center 也許只需要 5Gbps 的流量。由於十個 10Gbps 網路與 100Gbps 網路的成熟度不同,成本也會不相同。

這是 CDN 的一些粗略的概念。

從 Subversion 與 Mercurial 換成 Git

前陣子把公司裡所有的 repository 全部換成 Git 了...

由於 Git 與 Subversion/Mercurial 運作的方法不一樣,換完後也跟著換 Workflow。

原先 Subversion (1.5+) 對 branch 的 Workflow:

  • branchestrunk 兩個目錄,平常測試時都在 trunk 裡測試,測完後 merge 到 branches 再 deploy 到 production 主機上。
  • 缺點是,如果同時要測很多東西,merge 時得自己挑 revision。

用 Subversion 用一陣子,受不了他的速度後,有陣子在評估 Mercurial 與 Git。當時一直搞不定 Git 的 hook,所以就選了 Mercurial,所以有些 repository 用 Mercurial 開發了一陣子...

在 Mercurial 上,local branch 的功能一直沒搞定,所以會轉成 Mercurial 的 repository 都是不需要 local branch 的功能。當時從 Subversion 換 Mercurial 速度快了許多。

最後全部換成 Git 的主要原因是需要 local branch (anonymous branch),branch 的 Workflow 變成:

  • 主程式碼都在 master,所有的新功能 (以項目為單位) 開 branch 發展,最後再 merge 回 master。中央的 server 只放 master branch。

速度比 Mercurial 又快了不少,local branch 也成熟,gitweb 畫面還蠻好看也是主因 (也許會試看看 cgit,畫面看起來也不錯),這次換完後大家都還蠻開心的?

Subversion 轉換成 Git 的工具是 git-svn,把 branch 抓下來後去掉 Subversion 的資訊,直接將 master branch 推上 server。

Mercurial 轉 Git 用的是 fast-export,轉的速度相當快。轉完後要更改 branch 名稱,再將 master branch 推上 server。

Plurk 的 LightCloud

Plurk 前陣子放出 LightCloud,試著解決 Amazon 所提出的 Dynamo 用某些複雜方法解決問題。

比起 Dynamo 的優點是:

  • 使用 Tokyo Cabinet 當底層,這是目前最快的 key-value database 之一,而且檔案也小。
  • 因為使用 Tokyo Cabinet,所以可以用他的 master-master replication 取代 Dynamo 內的 replication,也就是固定以 n = 2 解決問題,以 node 本身的 HA 架構解決 Dynamo 裡面的 consistent 問題。(在 Dynamo 裡透過很多方法解決,變成 eventally consistent)
  • 增加機器造成資料需要移動的問題是把 hash ring 拆成兩個,一個 lookup ring,另外一個 storage ring,用兩次 query 解決。這個部份我看不懂他的解法,還要再找資料看他怎麼解的。

這個架構如果可行 (要看他解決 routing problem 的解法是否可以達到 scalability 特性),那麼就有很多有趣的應用可以在這個架構上跑。(直接當 filesystem 來放資料)

mk-parallel-dump (也是取代 mysqldump 的工具)

maatkit 是一組 MySQL 的工具程式,裡面包括了很多好用的工具。(之前最常用的應該是 mk-table-sync,同步兩台不同機器上的 MySQL 內容)

在「mydumper (取代 mysqldump 的工具)」裡我比較的對象是 mysqldump,但在 mydumper 出來之前,maatkit 就有提供同時 dump 的工具,也就是 mk-parallel-dump

範例除了在上面的頁面裡就有之外,也可以參考:

mk-parallel-dump -h [hostname] -u [username] --gzip --locktables --numthread=8 --databases='[database]' -p [password]

這樣會把 dump 的結果抓到 default 這個目錄下。

mydumper (取代 mysqldump 的工具)

mydumper 是取代 mysqldump 的工具,主要的差異在於 mydumper 會同時對多個 table 備份,效率比 mysqldump 好。

作者的說明文章在這裡:「mydumper」,我也順便做成 ports 了。

可以用 --help 看用法,另外我提供常用的範例指令:

mydumper -h [hostname] -u [username] -p [password] -x '^tracdb\.'

備份檔會放在同一個目錄裡 (export-*),看過範例以及 --help 的說明後,應該不太需要講解。

clang/llvm 能夠編 FreeBSD GENERIC kernel...

看起來 FreeBSD 決定走向 llvm 的路子,而非 NetBSD/OpenBSD 所選的 PCC...

這是從 rafan 的個人板轉自 -current mailing list 的消息,clang/llvm 已經能夠編 FreeBSD GENERIC kernel,並且正常使用:「[ANNOUNCE]: clang/llvm can compile booting FreeBSD kernel on i386/amd64」,目前 make world 的部份也正努力改善中:「Building FreeBSD with clang/llvm」。

目前 FreeBSD 還是跑 GCC 4.2.1 (最後一個 GPLv2 版本,目前 4.2 的分支已經出到 4.2.3 了),在 GENERIC kernel 可以 compile 的消息放出來後,應該會有更多的人加入測試或是跳進來改善。

好久沒看到 FreeBSD 的大動作了...