Exchange 用戶端頻寬預估 – 時區問題…

[アーティクル]
09/14/2012

英文原文已於 2012 年 6 月 20 日星期三發佈

6/22/12 更新 - 本文章及隨附下載檔案已更新。

最新版的 Exchange 用戶端網路頻寬計算器 (可能為英文網頁) 包含了數項更新，而最重要的一項非時區支援莫屬。過去 12 個月來我一直在研究解決時區問題的方法，花了好長一段時間終於想出了一個實用的方案。但在進入正題之前，先讓我們來看看時區的問題究竟是怎麼回事吧。

什麼是時區問題？

我假設每個人都知道時區是什麼，還有它們存在的原因。但如果有人想深入了解有關時區的一切，推薦您閱讀維基百科的文章：

https://en.wikipedia.org/wiki/Time_zone (可能為英文網頁)

有關時區真正的問題，從網路頻寬預估的角度來看，在於我們有時會以共用同一個網路連線或相同的終端服務之使用者作為工作負載的參照模型，然而這些使用者卻來自世界各地。這就形成了一個問題，因為大多數使用者的尖峰流量時刻和他們所在的時區直接相關。

舉例來說，假如我們查看 1000 個使用者組織的平常工作日，我們會看到兩波典型的高峰，一波在早上 10 點左右而且持續 2 小時，另一波在下午 2 點左右而且持續 4 小時。繪製成表，看起來會像這樣：

現在假設我們要針對全球 5 個不同地點的需求建立模型，每處皆支援 1000 名使用者存取一個位於紐約的共用資源。而這個共用資源，就假設它是一個 Exchange 2010 內部部署的前端負載平衡器好了 (為求不同，這回改舉內部部署的例子)。

倫敦 (GMT) = 1000 名使用者
華沙 (GMT+1) = 1000 名使用者
雅加達 (GMT+7) = 1000 名使用者
華盛頓州瑞德蒙市 (GMT-8) = 1000 名使用者
紐約 (GMT-5) = 1000 名使用者

如果我們用傳統的做法為每組使用者的尖峰建立模型，再將它們加在一起，就會得到這樣的結果：

這張圖告訴我們的是，每個擁有 1000 名使用者的站台，在每天尖峰時段需要大約 1.56Mbits/sec 的頻寬，把它們全部相加，就可以得出所有共用紐約之負載平衡器的使用量，結果是 7.81Mbits/sec。這就是我們一直以來為分散的使用者分配頻寬的方法：推算出他們的尖峰需求，然後全部丟進一張表裡加總。

但問題來了，當位於歐洲的使用者要下班回家時，瑞德蒙的使用者才剛起床，而雅加達的使用者正要熄燈睡覺！

如果我們把這些站台所在的時區也列入考量的話，此表將會當下判若兩圖：

我們可在此圖中看出工作負載加總後的流量型態，和我們過去規劃的非常不同。有趣的一點是，我們的尖峰流量現在反而低了許多，只有 3.78Mbits/sec 而已 (我們原本的預估是 7.81Mbits/sec)。整體的流量曲線也和我們原始的估算大相逕庭。

該怎麼解決這個問題呢？

看到上面的圖，您可能已經猜到。沒錯，我們已經增加了網路計算器的功能，現在您可以納入時區的詳細資料了！

我們實際上的做法是拋棄過去只推算尖峰流量的概念，而改以自行提出之流量型態，例如早晨的尖峰時刻在幾點而下午尖峰又在幾點等，而算出一天中每小時的頻寬流量。如此一來，計算器不僅知道您的尖峰流量在何時，還知道當天剩餘時段的使用型態會是如何。我們一旦清楚了這曲線的走勢之後，在加總資料時要考量時區的問題就好辦了。

真有人能用單一合併的方案做到這點嗎？

簡單來說，是的。許多企業都希望盡可能的合併工作負載，條件是設計團隊必須針對非常分散的使用者來規劃服務流量，這些使用者的流量型態往往十分迥異，所在的時區也有所不同。在將工作負載移轉至雲端的情況下，這點尤其普遍。因為 Office 365 只提供單一地區租用地點，所以採用 Office 365 的全球性企業，都必須為從完全不同區域與時區存取服務的眾多使用者 (通常是透過共用的基礎架構) 做好規劃。

我自己也有許多客戶嘗試將多個小的資料中心合併成幾個較大的單位。這些合併的站台必須要能夠處理先前分散的使用者的工作負載。但通常這些使用者都來自不同的時區，因此當我們打算容納他們的工作負載時，必須先了解它們和其他分散式工作負載結合後會是什麼樣貌。

當然，如果您所有的使用者都在同一個時區，就不必考慮這麼多，只要像平常那樣使用計算器就行了。