行動容量規劃
上次修改主題的時間： 2011-12-05
判斷您需要用於行動性的容量，是預估行動性使用情況、測量目前容量、規劃額外容量以及監控效能關鍵指標的反覆程序。下圖顯示有關容量規劃的階段，以及各階段的相關因素。
行動容量規劃工作流程
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
本節說明您在預估行動性使用情況時，需要考量的因素，並指引您如何判斷部署行動性所需的大小。
如需監控使用情況及效能指標的詳細資訊，請參閱下列資訊：
如需監控伺服器記憶體的詳細資訊，請參閱＜監控伺服器記憶體容量限制＞。
如需監控行動性使用情況的詳細資訊，請參閱＜監控 Mobility Service 使用量＞。
如需監控 IIS 追蹤記錄檔的詳細資訊，請參閱＜監控 IIS 要求的追蹤記錄檔＞。
如需您可以用來監控行動性之效能計數器的詳細資訊，請參閱＜行動效能計數器＞。
如需設定 Mobility Service 以獲得高效能的詳細資訊，請參閱＜設定高效能的 Mobility Service＞。
影響容量的因素
針對執行 Microsoft Lync Server 2010 Mobility Service 的 前端伺服器 進行容量規劃時，有三個影響因素：
使用者模型
行動裝置特性
可用的 RAM
使用者模型
本節描述的使用者模型為行動性的容量規劃測量和建議提供基礎。
每位使用者的平均連絡人數目
| 連絡人類別 | 每位使用者的平均數 |
|---|---|
所有連絡人 |
80 |
企業連絡人 |
64 |
同盟連絡人 |
8 |
PIC 連絡人 |
6 |
通訊群組 |
2 |
最常使用的連絡人 |
15 |
最近使用的連絡人 |
10 |
每位使用者的每日活動
| 每日活動 | 工作時間內的數目 | 工作時間外的數目 |
|---|---|---|
登入行動應用程式 |
10 |
2 |
通話數 |
10 |
2 |
通話持續時間 |
每通電話 2 分鐘 |
每通電話 2 分鐘 |
會議 |
每星期 1 次 |
0 |
每次會議的參加人數 |
<10 |
0 |
狀態記事變更 |
1 |
0 |
連絡人卡片檢視次數 |
6 |
1 |
連絡人清單檢視次數 |
9 |
1 |
捲動整個連絡人清單 |
3 |
0 |
全域通訊清單 (GAL) 搜尋 |
5* |
- |
手動更新目前狀態 |
0.5 |
0 |
每個連絡人的目前狀態更新總數 |
6 |
0 |
來電轉接 |
0.5 |
0 |
立即訊息 (IM) 工作階段數 |
3 |
1 |
IM 工作階段持續時間 |
每個工作階段 6 分鐘；每 30 秒 1 則訊息 |
每個工作階段 6 分鐘；每 30 秒 1 則訊息 |
行事曆查閱 (連線至 Exchange Web 服務) |
11 |
3 |
* GAL 搜尋數 = 每天 1 次手動搜尋 + 立即訊息和通話中途的自動搜尋。也就是 1 + 2 (立即訊息) + 2 (通話) =5。
行動裝置特性
支援行動性的行動裝置會執行各種作業系統。當使用者切換至不同應用程式時，作業系統用來管理應用程式的方式會影響容量規劃。作業系統可分為下列兩種容量規劃類別：
啟用背景 當使用者在 Apple 和 Windows Phone 行動裝置上切換至不同行動應用程式時，Lync 2010 行動應用程式會進入背景，並失去與 Lync Server 2010 的連線。推入通知或是當使用者手動將應用程式帶到前景時，會重新啟動行動應用程式。
自動連線 當使用者在 Android 和 Nokia 行動裝置上切換至不同行動應用程式時，只要使用者保持登入，Lync 2010 行動應用程式就會保持連線至 Lync Server 2010。
Android 和 Nokia 行動裝置會在伺服器上建立較大的負載，因為就算使用者沒有使用行動應用程式，還是會保持連線至伺服器。
可用記憶體
本節稍後說明的大小調整指引將會協助您定義行動性所需的記憶體數量。若要判斷伺服器上可用的實體記憶體數量，請使用 [Memory]、[Available Mbytes] 效能計數器。此效能計數器會指出可用來執行程序的實體記憶體數量 (MB)。如果可用來執行程序的記憶體數量少於實體記憶體總數的百分之五 (5%)，則伺服器的記憶體不足，會導致分頁增加。
大小調整指引
Mobility Service 在 前端伺服器 上會使用額外的記憶體、程序或資源，以及網路資源。當您規劃容量時，必須了解行動負載對前端集區的影響，並決定是否需要為行動負載增加硬體。請使用下表中的大小調整範例來幫助判斷您是否需要以及需要多少額外硬體。
表格中的範例是以某些公式和假設為基礎。這些公式和假設使用下列定義：
AC 代表持續在使用者模型中連線的行動應用程式數目。
BE 代表在使用者模型中為背景啟用的行動應用程式數目。
公式和假設如下：
目標記憶體 (TM) (MB) = 164 + (AC * 534 + BE * 400) / 1024。
TM 是最小必要記憶體。
在使用上述使用者模型的情況下，連接至前端集區的連線數為 AC * 2 + BE * .20。
當伺服器上沒有記憶體壓力時，測量的記憶體可能會較高 (高達每個端點 1 MB)。如果使用者模型較積極 (例如有較多的音訊/視訊 (A/V) 通話或連絡人等等)，目標記憶體會較高。
每秒建立的連線數小於或等於每 1,000 個使用者每秒 30 個。此數字取決於硬體負載平衡器上的連線共用設定，以及保持運作 (keep-alive) 設定。
下表顯示針對使用者模型中有 50% 自動連線使用者的大小調整範例。
大小調整範例
| 使用者數目 | 記憶體 (MB) | 平均 CPU | 最大 CPU |
|---|---|---|---|
1,000 |
620.05 |
1% |
2.5% |
2,000 |
1076.11 |
6% |
8% |
3,000 |
1532.16 |
14% |
18% |
4,000 |
1988.22 |
14% |
18% |
5,000 |
2444.27 |
14% |
18% |
狀況範例
下列範例顯示大小調整指引如何套用至虛構的大型企業，以及配備兩部伺服器的前端集區。
大型企業
Contoso 已跨三個集區部署了 75,000 個使用者，每個集區中有四個 前端伺服器。Contoso 計劃要為 30,000 個使用者啟用行動服務。
在規劃階段期間，Contoso 系統管理員擷取下列資料：
每個前端伺服器有 3 GB 的可用記憶體。
CPU 使用量低於 60%。
所有使用者都有 iPhone 或 Windows Phone 行動裝置。
Contoso 的使用者模型類似本節先前描述的容量規劃使用者模型。
每部伺服器所需的記憶體下限為 164 + 2500 * 400 / 1024 = 1133 MB。當有記憶體可用時，可能會將較多的記憶體配置給行動應用程式，因為記憶體會依需要釋出，最高 2.7 GB。無論是哪一種情況，Contoso 都不需要升級前端伺服器硬體。
.gif "note") 附註： |
|---|
| 行動 CPU 使用量的目標是平均 10%。Contoso 在接近 70% 的伺服器限制時，需要監控 CPU 處理器時間。 |
前端集區 配備兩部伺服器
Contoso 已在配備兩部伺服器的前端集區中部署 8,000 個使用者。Contoso 計劃要為為所有使用者啟用行動服務。
在規劃階段期間，Contoso 系統管理員擷取下列資料：
每個前端伺服器有 2.5 GB 的可用記憶體。
CPU 使用量低於 60%。
所有使用者都有 Nokia 或 Android 行動裝置。
Contoso 的使用者模型類似本節先前描述的容量規劃使用者模型。
每部伺服器所需的記憶體下限為 164 + 4000 * 534 / 1024 = 2242 MB。理論上，伺服器可以支援負載。不過，如果兩部伺服器之間發生容錯移轉，伺服器就不支援負載。此外，行動 CPU 使用量將會高於 10%，而且會達到伺服器 70% 的 CPU 限制。
在此情況下，建議要增加伺服器至集區。新的負載分散為每個前端伺服器 2667 (也就是 8000/3) 個使用者。額外的行動成本為 2667 * 534 / 1024 = 1390 MB。
增加伺服器之後，在發生伺服器失敗的事件時，集區中的三部伺服器會各自多接受 1,300 個使用者，而負載中增加 600 MB。在新的負載分散中，CPU 使用量也會維持在低於 70% 的伺服器限制。