Tag: anycast

為了解決 HiNet 到 CloudFlare 機房品質不好而做的掙扎...

前幾天在「TVBS 的 CloudFlare 客製化...」這邊提到這件事情，當天就先隨手測了一些東西。

首先是 CloudFlare 的服務 IP 是互通的，也就是說，我就算拿其他人的 CNAME mapping 來用，只要有送出對應的 Host: 或是 SNI (for HTTPS) 就會通，而 TVBS 當時的 IP address (以及網段) 對於台灣 HiNet 使用者剛好會導到美國機房，還算可以用。

另外 CloudFlare 有提供列表 (文字格式，一行一個網段)，分別是 IPv4 的 https://www.cloudflare.com/ips-v4 以及 IPv6 的 https://www.cloudflare.com/ips-v6。

所以就有幾種組合了，一種是寫 Google Chrome 的 extension 直接改 IP address，不過看了看 JavaScript APIs - Google Chrome 想不出來怎麼寫。

另外一個是先用 iptables 把這些網段的流量導去美國的 CloudFlare 機房。結果這時候發現 HiNet 到 TVBS 已經改回到香港機房了 orz

實際抓了一下發現 188.114.97.100 在巴西機房 (GRU 是 IATA 代碼)，就變成只是測試看看這有沒有用了：

$ curl -x http://188.114.97.100:80/ http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004146.723
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

由於是自己機器出去的封包，不能用 PREROUTING 做，要用 OUTPUT 做：

iptables -t nat -A OUTPUT -d 190.93.240.0/20 -j DNAT --to-destination 188.114.97.100

然後再直接連到 s.plurk.com 就可以看到：

$ curl http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004011.195
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

不過巴西也太遠了點，而且不知道哪天這段 IP 又會被 anycast 進去... orz

TVBS 的 CloudFlare 客製化...

TVBS 網站整個使用 CloudFlare，但針對台灣地區 HiNet 的部份仍然保持使用 anycast，但該段 routing 沒有透過香港機房放進 HiNet，而是很特別的走到了 San Jose 的機房：

  3.|-- SNUH-3202.hinet.net        0.0%    10   10.4  10.5   8.8  16.8   2.2
  4.|-- TPDT-3012.hinet.net        0.0%    10   14.5  14.6  10.6  20.6   3.4
  5.|-- r4102-s2.tp.hinet.net      0.0%    10    9.8  10.0   8.7  10.8   0.5
  6.|-- r4002-s2.tp.hinet.net      0.0%    10   10.8  19.0   8.7  82.1  23.0
  7.|-- r12-pa.us.hinet.net        0.0%    10  137.7 138.4 136.9 139.2   0.3
  8.|-- sjo-b21-link.telia.net     0.0%    10  157.0 156.4 155.7 157.7   0.3
  9.|-- cloudflare-ic-309920-sjo-  0.0%    10  146.9 148.6 145.8 167.4   6.6
 10.|-- 198.41.187.120            10.0%    10  145.7 146.7 137.9 156.9   7.6

國內其他 ISP 則是如同一般的情況，走到了日本機房：

  3.|-- 60-199-236-110.static.tfn  0.0%    10    0.3   0.3   0.3   0.3   0.0
  4.|-- 60-199-255-3.static.tfn.n  0.0%    10    0.3   0.3   0.2   0.3   0.0
  5.|-- 60-199-20-153.static.tfn.  0.0%    10    0.2   2.6   0.2  24.2   7.5
  6.|-- 60-199-3-137.static.tfn.n  0.0%    10    0.3   2.2   0.2  20.1   6.3
  7.|-- 60-199-18-90.static.tfn.n  0.0%    10    0.3   0.3   0.3   0.4   0.0
  8.|-- 60-199-3-222.static.tfn.n  0.0%    10    0.4   0.4   0.4   0.5   0.0
  9.|-- xe-1-0-0.r01.taiptw01.tw.  0.0%    10    0.8   3.1   0.7  23.6   7.2
 10.|-- ae-1.r00.taiptw01.tw.bb.g  0.0%    10    5.6   5.5   0.9  39.1  11.9
 11.|-- as-2.r22.tokyjp01.jp.bb.g  0.0%    10   53.2  52.3  49.3  53.8   1.4
 12.|-- ae-8.r25.tokyjp05.jp.bb.g  0.0%    10   52.5  53.0  50.4  56.4   1.7
 13.|-- ae-2.r01.tokyjp03.jp.bb.g  0.0%    10   54.5  53.1  50.1  55.3   1.8
 14.|-- xe-0-0-0-29.r01.tokyjp03.  0.0%    10   79.5  77.2  73.6  79.5   1.6
 15.|-- 198.41.190.120             0.0%    10   54.8  58.8  49.9  78.7  10.5

  3.|-- h61-192-72-154.seed.net.t  0.0%    10    0.4   0.5   0.4   0.6   0.0
  4.|-- R58-145.seed.net.tw       10.0%    10   13.2   8.4   0.5  42.4  13.6
  5.|-- R59-194.seed.net.tw        0.0%    10   52.5  10.8   0.6  52.5  19.7
  6.|-- xe-4-0-0.r01.taiptw01.tw.  0.0%    10    0.6   0.7   0.6   0.8   0.0
  7.|-- ae-1.r00.taiptw01.tw.bb.g  0.0%    10    0.9   0.9   0.8   1.1   0.0
  8.|-- as-2.r22.tokyjp01.jp.bb.g  0.0%    10   70.8  66.5  49.2 102.1  19.4
  9.|-- ae-8.r24.tokyjp05.jp.bb.g  0.0%    10   54.3  58.2  53.2  76.3   6.8
 10.|-- ae-1.r01.tokyjp03.jp.bb.g  0.0%    10   55.6  54.1  48.9  55.7   2.1
 11.|-- xe-0-0-0-29.r01.tokyjp03.  0.0%    10   55.0  56.8  53.0  59.3   1.9
 12.|-- 198.41.186.120             0.0%    10   55.1  54.8  50.7  58.1   2.0

依照 Netcraft 上的資料 (Site report for www.tvbs.com.tw) 應該是六月的時候換去的：

應該是國內比較有量的網站裡面少數用 CloudFlare 的？其他新聞網站大多都用 Akamai...

EdgeCast 提供的 DNS 服務：EdgeCast Route

Zite 上看到 EdgeCast 也要進入 DNS 服務這個市場了：「CDN Provider EdgeCast Gets Into The DNS Market With Launch Of EdgeCast Route」。

服務的頁面已經公開，並且公開價錢：「Managed DNS Provider | Outsourced DNS Service | Route | EdgeCast」，服務分成三種：

Standard Routing

利用 EdgeCast 的 IP Anycast Network 服務。每百萬個 query 是 USD$0.4 (超過十億個 query 的部份降到半價 USD$0.2)。

Adaptive Availability

除了 IP Anycast Network 外，還可以設定 health check 與 ratio (以達到 load sharing 的功能)。每百萬個 query 是 USD$0.6 (超過十億個 query 的部份降到半價 USD$0.3)。

Advanced Policy Routing

可以依照這些條件分析：GeoIP、GeoCountry、GeoCity、ASN、IP Group、Network Groups、Anycast PoPs 或是 IP Type。每百萬個 query 是 USD$1.5 (超過十億個 query 的部份降到 USD$1)。

另外價錢還有 zone 的部份。前面 50 個 zone 是 USD$50/month (算是低消吧？)，後面每 50 個 zone 是 USD$35/month。而 health check 的部份是每個 USD$0.5/month。

可以設這麼細，而且又取這個名字，算是跟 Amazon Route 53 打對台？不過那個 Geo 系列以及 ASN 的部份看起來不賴啊，以前是自己寫 DNS resolver 處理這部份，把國外流量指到 CDN 上，然後台灣流量放在台灣的機房 (因為 CDN 不一定有台灣機房的 PoP)。

找機會來看看效果如何...

DNS Hosting 的市佔率...

其實就是 Anycast DNS service...

CloudHarmony 在前鎮子發表了 DNS Hosting 的市場佔有率：「DNS Marketshare - Alexa 10,000 + Fortune 500 - May 2013」。

比較有趣的是「Top 20 Alexa Site Changes - Apr 8 to May 6 2013」這段，可以看到很多公司跳去 Cotendo Advanced DNS... 不過我沒看懂從 Akamai 跳到 Cotendo Advanced DNS 是哪招，Contendo 不是被 Akamai 買掉了嗎 XD

AWS Route53 降價、新增巴西 PoP...

公告在這裡：「Amazon Route 53 - Now an Even Better Value」、「Amazon CloudFront & Route 53 - New Edge Location: Brazil」。

Route53 的部份，對於少量使用的人來說，每個 domain 每年的代管價錢從 USD$12 降到 USD$6，而對於大量使用的人來說，更有可能降到 USD$1.2。對於有大量 domain 希望上 Anycast DNS 的人來說是個好消息。

另外一個消息是 AWS 新增巴西的 PoP，是南美的第一個點。包括 CloudFront 以及 Route53 都將受益。不過頻寬費用與 request 費用比之前最貴的東京 20% 以上。如果費用層級再多，AWS 應該要提供可以客製化不同等級的 CDN service (設定只要某些 PoP)，不然花不太下手啊...

DNS Prefetch 的利弊

Simon Willison 轉了一篇文章，提到某個網站用 meta tag 關掉 DNS Prefetch 後，每個月省下 USD$1600：「DNS Prefetching Implications」。

會這麼貴的主要原因在於 DNS Prefetch 是利用「浪費資源」加速，設計上本來就不需要很快的反應時間，所以不應該讓他上昂貴的 Anycast-based DNS service。更何況 Anycast-based DNS service 應該是在整個系統都 tune 到極致後，壓榨最後一丁點效能的武器...

自己架設 DNS server，或是透過 Domain Registar and/or Hosting 公司代管，效果其實都不差。如果想要測試 Anycast-based DNS service，除了 Route53 可以玩看看以外，EasyDNS 也有提供平價的服務 (而且可以是 slave server)，要測試的人可以測看看...

Amazon Web Services 新服務：Route 53

當有多個 Data Center 的時候就應該要做的事情！Amazon 總算是出手了...

Amazon 官方的新聞稿在這：「Amazon Route 53 - The AWS Domain Name Service」，CTO Werner Vogels 的介紹在這：「Expanding the Cloud with DNS - Introducing Amazon Route 53」，產品的介紹頁在這：「Amazon Route 53」。

Route 53 是利用 Amazon 目前已經有的 Data Center (依照 CloudFront 的名單，看起來是同一組機房)，加上 IPv4 Anycast 而提供的 DNS query 服務。以文件裡的範例可以看到使用了四個不同的 domain，分別是 com、net、org 以及 co.uk：

<NameServer>ns-1638.awsdns-12.co.uk</NameServer>
<NameServer>ns-144.awsdns-18.com</NameServer>
<NameServer>ns-781.awsdns-33.net</NameServer>
<NameServer>ns-1478.awsdns-56.org</NameServer>

到幾個不同的點 mtr 可以看出來有用 Anycast，只是還需要調整... 另外，依照文件看起來，暫時不提供 slave server，而必須透過提供的 API 直接改，這點是比較麻煩的地方，不知道 Console 什麼時候要提供介面...

最後來談價錢好了，每個 zone 的基本費用是 USD$1.5/month (包括 1M query/month 的量)，一年也才 USD$18/year...

Route 53 之所以特別，是因為一般人就算有錢也沒辦法架出像樣的 Anycast-based DNS (這要有錢而且有量才做得到)，而之前七月的時候 Cotendo 給的 quote 讓我連回信都懶得回 (雙方認知差距太大)，我記得價錢好像多了好多 0...

這項服務會給自認 Anycast-based DNS 是「加值服務」而撈錢的公司一記重擊... 尤其大家都知道 Amazon Web Services 的東西出來後還是會花時間 tune，服務水準會不斷改善，比起其他公司來的穩定多了...