Instagram 從 AWS 搬到 Facebook 機房

InstagramInstagram Engineering Blog 上宣佈的消息:「Migrating From AWS to FB」。

整個 migration 的過程是採取不停機轉移,所以 effort 比直接停機轉移高很多:

The main blocker to this easy migration was that Facebook’s private IP space conflicts with that of EC2. We had but one route: migrate to Amazon’s Virtual Private Cloud (VPC) first, followed by a subsequent migration to Facebook using Amazon Direct Connect. Amazon’s VPC offered the addressing flexibility necessary to avoid conflicts with Facebook’s private network.

先把整個系統轉移到 Amazon VPC 裡,然後再拉 AWS Direct Connect 串起來,接下來才是慢慢把 instance 轉移到 Facebook 的機房內。

中間也有一些工作:

To provide portability for our provisioning tools, all of the Instagram-specific software now runs inside of a Linux Container (LXC) on the servers in Facebook’s data centers.

所以已經導入 LXC 了...

行動平台上的 Tor browser

在「The problem behind mobile TOR browsers' ip disclosure」測了四個行動平台的 Tor 瀏覽器,其中三個是 Android 上的,一個是 iOS 的。

四個瀏覽器測試的結果中,只有 iOS 上的 Onion Browser (要 USD$0.99) 可以在修改設定後達到最低限度「隱藏 real ip」的標準:

作者的建議是不要在行動平台上有太多期望,隱藏 real ip 只是其中一個環節...

DigitalOcean 新加坡機房支援 IPv6...

DigitalOcean 宣佈新加坡機房 SGP1 支援 IPv6:「Announcing IPv6 Support in Singapore」。

新加坡機房是第一個 DigitalOcean 機房可以上 IPv6 的原因是因為跑新版的架構 XDDD

SGP1 is the first datacenter to have IPv6 support because it is running v1.5 of our backend code base. The new version was completely rewritten from the ground up and provides many benefits over the current v1.0 code.

不過沒看到 IPv6 range,沒辦法測試... (我的 blog 是放在加州,目前還沒有 IPv6 可以玩...)

ARIN 進入 IPv4 Countdown Plan 的第四階段

ARIN 只剩下最後一個 /8 的 IPv4 位置時,將會啟動第四階段的發放機制,而昨天進入這個機制了:「ARIN Enters Phase Four of the IPv4 Countdown Plan」。


出自「ARIN IPv4 Countdown Plan」這頁。

目前的進度是:

  • Phase One began in February 2011 when ARIN received its last /8 from IANA.
  • Phase Two began in September 2012 when ARIN reached three remaining /8 equivalents.
  • Phase Three began in August 2013 when ARIN reached two remaining /8 equivalents.
  • Phase Four began in April 2014 when ARIN reached one remaining /8 equivalent.

不過 IPv6 的進展還是苦哈哈啊...

ptt.cc 偶而會解不出 IP 的問題

Update:感謝正妹 wens 幫忙,現在已經先上 workaround 了,狀況暫時解除...

最近發現 168.95.1.1 有時會找不到 ptt.cc 這個 domain (參考 gist:9995821),原因是 ptt.cc 在 whois 上登記的是:

Name Server: NS0.PTT.CC
Name Server: NS1.PTT.CC
Name Server: NSOUT1.PTT.CC

用 dig 對 cc 的 NS server 查詢也可以確認:

;; AUTHORITY SECTION:
ptt.cc.                 172800  IN      NS      ns0.ptt.cc.
ptt.cc.                 172800  IN      NS      ns1.ptt.cc.
ptt.cc.                 172800  IN      NS      nsout1.ptt.cc.

;; ADDITIONAL SECTION:
ns1.ptt.cc.             172800  IN      A       140.112.172.10
ns0.ptt.cc.             172800  IN      A       140.112.172.16
nsout1.ptt.cc.          172800  IN      A       112.121.80.227

但 ptt.cc 的三台 NS server 上都找不到 nsout1.ptt.cc:

; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.10

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.16

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @112.121.80.227

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600

於是就錯亂了...

可以先解決的方法是先把 nsout1.ptt.cc 加上去,然後再規劃要怎麼修改兩邊的 record (Ptt 這側的 A/NS record,與 cc 的 A/NS record)。

補充一下,ptt2.cc 也有同樣問題。

瀏覽器裡取得 Local IP 位置的方式

whatismybrowser.com 上看到 local IP address 時愣了一下,查了查資料後發現是 WebRTC 的功能:「Local IP discovery with HTML5 WebRTC: Security and privacy risk?」。

如果知道內網的 IP 後,再加上一堆問題設備,hmmm... 能做的事情好多啊 @_@

在「Can I use WebRTC Peer-to-peer connections?」可以看到 Google ChromeFirefox 都支援了...

看了看 chrome://flags 似乎沒解... 來想看看有沒有什麼其他反制的辦法 @_@

Firefox 可以參考「Where can I disable WebRTC and PeerConnection?」這邊提供的方法試看看,不過我沒測過,不知道到底有沒有效...

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)。

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

SNI 支援 (單一 IP 多個 SSL Certificate)

Twitter 上看到 yllan 提到 SSL certificate 的問題:

這是看 client 對 Server Name Indication 的支援程度而決定的。

在維基百科說明中「Browsers with support for TLS server name indication」這段裡面列出來的瀏覽器,可以看出來其實最大的問題就是 Windows XP 上的 IE{6,7,8} 不支援。(但 Windows Vista 以及 Windows 7 的 IE{7,8} 支援 SNI)

手上一時間找不到 Windows XP + IE{6,7,8} 的數量,但 gs.statcounter.com 上有幾個數字可以參考。

首先是台灣 IE8 的用戶數量:

再來是 Windows XP 數量:

以這兩個圖的資料來看,還是不太能用啊... :o

BT Retail 開始實際測試 CGNAT...

英國的 ISP BT Retail 開始測試 CGNAT (Carrier-grade NAT) 了:「BT Begins Customer Tests of Carrier Grade NAT」。

空前但未必是絕後的大型 NAT 計畫,如果 CGNAT 可行,IPv6 會再往後延個好幾年吧...

Update:被 comment 提醒跑去測試,發現中華的 3G 早就是了:(CGNAT 會用 100.64.0.0/10,範圍到 100.127.255.255)

Ping 整個 IPv4 的結果...

目前的電腦與網路已經有能力一次掃完整個 IPv4:「The result of pinging all the Internet IP addresses」。

用 ping 不一定準確,因為目前 Windows 作業系統預設會開啟防火牆,不會接受 ping。不過仍然是個有趣的方法 :p

首先是整個 IPv4 address space 只有 7% 的 IP address 會回應 ICMP ping:

另外有各 /8 的回應數量:

可以看到很多是空的... XD