Facebook 研究用鋰電池當作 UPS 替代方案

Slashdot 上看到「Facebook Testing Lithium-Ion Batteries For Backup Power」,原報導出自「Facebook gives its server racks a Tesla touch」。

這讓我想到之前 Google 也做過類似的架構,不過是用蓄電池:「Google Finally Declassifies Some Key Server Design Secrets」。

上圖右上邊的那個區塊就是蓄電池。

Facebook 會考慮鋰電池是因為 Telsa 的需求使得價錢往下掉,進而考慮將本來的 UPS 換成鋰電池。

AWS 的機房架構

這幾天 Amazon 因為 re:Invent 的關係,放出了不少資料出來,其中看到有 AWS 機房的架構:「Amazon details how it does networking in its data centers」。

有些資料還蠻有趣的,像是這張:

每個 AZ (Availability Zone) 可能會有很多 DC (Data Center),而這些 DC 必須在 0.25ms 內。

AZ 之間是 complete graph 連接,另外對多個不同的 Transit center 出去,以確保其中一個 Transit center 掛掉時仍然有備援。

AZ 之間的 latency 會在 2ms 之間 (如果算來回的話是 300 公里),通常會在 1ms (算來回的話是 150 公里)。

使用者的 AWS Direct Connect 則是接到 Transit center 上。

每個 DC 的機器數量在 50k 到 80k 台左右。

雖然應該用不到,但看這些資料還是蠻有趣的 :p

Galera Cluster 3.x 的設定...

Percona XtraDB Cluster 5.6 用的是 Galera Cluster 3.x 的 patch,所以 Percona 的人寫了一篇介紹 3.x 有哪些設定:「New wsrep_provider_options in Galera 3.x and Percona XtraDB Cluster 5.6」。

看起來來比較有影響的是 gmcast.segment=0,用在跨機房之間的判斷。

看起來應該是同一個機房要設一樣的 gmcast.segment。這個值會用在兩個地方:第一個是跨 segment 的 replication 流量會試著盡可能小。第二個是同步時的 Donor 會優先選擇同機房的節點。

其他的用預設值應該就 okay...

NSA 聽 Google 與 Yahoo! 跨機房的 LAN...

最近幾天揭露的文件顯示 NSA 在監聽 GoogleYahoo! 在內部機房內的通訊:「NSA infiltrates links to Yahoo, Google data centers worldwide, Snowden documents say」。

不是 Google 與 Yahoo! 之間的通訊,而是 Google 自家資料中心之間交換的資料 (以及 Yahoo! 自家資料中心交換的資料),像是這樣:

重點在右半塊的內部通訊內容未必會被加密...

Switch 與 Router 要內建 Wirespeed IPsec 的時代要來臨了嗎... 40Gbps (甚至 100Gbps) 的 IPsec 能力!XDDD