Share via


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

英文原文已於 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 的全球性企業,都必須為很大一部分從完全不同區域與時區存取服務的使用者 (通常是透過共用的基礎架構) 做好規劃。

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

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

使用新的時區功能

好的,現在您發生了一個需要處理時區問題的情況,但是這個新功能到底怎麼用呢?

要緊的事先來,我們得先設定好輸入工作表上的 [TimeZone 設定表格] (TimeZone Configuration)。這裡所輸入的參數會決定用以結合工作負載的流量曲線輪廓。此處的值必須符合貴公司的平均用量型態,我一般會查看一下運作 Exchange Server 的效能資料,再問問客戶他們對使用者工作型態的想法,還有尖峰時段會落在哪裡。

表格

輸入工作表完成後,我們來到用戶端混合計算工作表。在這裡有兩個新的地方要設定時區資料。

首先是 [模型時區] (Model Timezone),這代表我們要規劃之資源的時區,比方說網路連結或負載平衡器。在先前的範例中,您可以看到我把模型時區設為 GMT-5,也就是我們的負載平衡器所在位置 (紐約) 的時區。

接著我們可以看到有一個新的欄,叫做 [時區] (TimeZone)。這代表個別站台相對於 GMT 的時區 (我是英國人,習慣用 GMT,如果有很多人抱怨的話,未來也是可以改成 UTC 啦)。

表格

推算的結果會顯示在一張圖表裡,位於前面提到的用戶端混合計算表格底下。此表內的數值是 Mbits/sec 表示,代表一天當中每小時的預估網路用量。

額外的小功能

另一個很棒的功能是計算器會提供一張表格,可讓您複製到信箱角色計算器中,協助預測 DAG 網路複製。

看到網路計算機中預測表 (用戶端混合計算工作表) 的右手邊,您會發現一張含有當天每小時百分比變化的表格,如果您將它複製到剪貼簿…

圖形

然後在信箱伺服器角色計算器中捲到這張輸入工作表的最底部,您會看到一張專門是 [記錄複寫設定] (Log Replication Configuration) 的表格。請將網路計算機的數據貼到這張表上。

表格

這樣就行了,信箱伺服器角色計算機現在可以估算出 DAG 複製所需的頻寬,並將貴公司的資料和時區都考慮在內!

結論

希望這項新功能可幫助各位更準確地估算自己的網路頻寬需求;雖然不是所有的部署都得這麼做,但對於飽受此問題困擾的大型企業架構,我希望這項時區功能能夠幫到您。

請繼續給予我們您寶貴的意見,正面或負面的都好,請寄至 netcalc@microsoft.com。我們非常期待收到您的回音!

Neil Johnson
MCS 英國,資深顧問

這是翻譯後的部落格文章。英文原文請參閱 Exchange Client Bandwidth Prediction – the time zone problem…