容量規劃
上次修改主題的時間： 2011-01-07
容量規劃需求是以建議的 Office Communications Server 2007 R2 使用者模型為基礎。本節將說明這些使用者模型，並提供可協助您為組織執行容量規劃的資訊。
使用者模型
本節中的使用者模型是本節稍後將會說明的容量規劃需求和建議的基礎。
Office Communications Server 使用者模型
下表說明 Office Communications Server 的使用者模型。
表 1. Office Communications Server 的使用者模型
| 類別 | 描述 |
|---|---|
用戶端分佈情況 |
30% 的用戶端執行 Office Communicator 2007 用戶端，包括 Communicator Web Access (2007 版本) 或 Communicator Mobile (2007 版本) 70% 的用戶端執行 Office Communicator 2007 R2、2007 R2 版的 Communicator Mobile 或 Communicator Web Access；100% 的用戶端執行 Live Meeting 用戶端 |
遠端使用者分佈情形 |
90% 的使用者是內部連線 10% 的使用者透過 Edge Server 與 Director (建議使用) 連線 |
連絡人分佈情形 |
平均 80 位連絡人位於行動裝置上 平均 50 位連絡人位於其他裝置上 70% 的連絡人在組織內 10% 的企業使用者為遠端使用者 10% 的連絡人為同盟連絡人 10% 的連絡人為公用 IM 連絡人 |
IM 工作階段 |
每小時每位使用者 2 個 IM 工作階段 每個工作階段 10 個立即訊息 平均訊息大小為 400 位元組 多方 IM 工作階段平均 3 人參與 |
下表將說明會議模型，用來做為本節稍後所述的容量規劃需求和建議的基礎。
表 2. 會議模型
| 類別 | 描述 |
|---|---|
排定的會議與「立即開會」的會議 |
每個類別的 50%。 |
會議並行 |
工作時間內會有 5% 的使用者在開會。 |
會議媒體分佈情況 |
15%：透過協力廠商音訊會議提供者的 PSTN 音訊、PowerPoint。 10%：透過協力廠商音訊會議提供者的 PSTN 音訊、應用程式共用。 15%：群組 IM 加上通訊群組整合。 10%：僅限 PSTN 音訊電話撥入式會議。 10%：VoIP 音訊、PSTN 電話撥入式會議、PowerPoint。 25%：VoIP 音訊、PSTN 撥入和視訊、應用程式共用。 5%：VoIP 音訊、PSTN 撥入、IM 和應用程式共用。 10%：VoIP 音訊、PSTN 撥入、視訊、IM。 |
會議參與者分佈情形 |
在使用會議服務員以及 VoIP 音訊和 PSTN 撥入音訊組合的會議中，VoIP 使用者和以電話撥入的使用者是 2 比 1。 針對應用程式共用，有兩種應用程式共用類型：持續性共用物件模型 (PSOM) 使用 Web 會議伺服器的持續性共用物件模型 (PSOM) 應用程式共用，和以新的應用程式共用伺服器為基礎的遠端桌面通訊協定 (RDP) 應用程式共用。此使用者模型假定 80% 的臨時決定會議使用 RDP 應用程式共用，20% 使用 PSOM 應用程式共用。針對已排定會議，此使用者模型假定 PSOM 和 RDP 應用程式共用的使用率各佔 50%。 假設：有一位參與者的會議不使用 RDP 應用程式共用。針對有兩位參與者的已排定會議，此模型假定 20% 採 RDP 應用程式共用。針對臨時決定的會議，此模型假定 10% 採 RDP 應用程式共用。 25% 遠端存取。 15% 匿名。 10% 同盟。 50% 內部。 |
下表將說明會議內容大小模型，用來做為本節稍後所述的容量規劃需求和建議的基礎。
表 3. 會議內容大小模型
| 內容類型 | 平均大小 | 執行個體數目 |
|---|---|---|
多媒體內容 (Flash、Windows Media Player) |
50 MB |
1 |
PowerPoint |
20 MB |
2 |
其他 Microsoft Office Document Imaging (MODI) 文件 |
10 MB |
3 |
講義 |
5 MB |
1 |
Communicator Web Access 模型
Communicator Web Access 使用模式是以 Office Communicator 使用模式為基礎，而且包括下列假設。
表 4. Communicator Web Access 使用情況
| 說明 | 值 |
|---|---|
使用者總數 |
5,000 加上執行桌面共用的 120 位使用者 |
執行桌面共用的使用者 |
120 (20 個會議) |
連絡人清單中內部使用者的百分比 |
70% |
舊版使用者的百分比 |
30% |
每位使用者的平均連絡人數目 |
50 |
每位使用者的連絡人數目上限 |
260 |
每位使用者的連絡人數目下限 |
1 |
每位使用者每天登入的時數 |
12 |
每位使用者每天的目前狀態更新次數 |
82 |
每位使用者每天進行的立即訊息交談數目 |
12 |
每位使用者每天進行的立即訊息會議數目 |
1 |
每個會議 (對等式) 每位使用者傳送的立即訊息數目 |
10 |
立即訊息傳送率 |
每分鐘 1 個 |
每小時的立即訊息工作階段數目 |
2 |
多方工作階段的平均參與者人數 |
3 |
在特定時間點同時參與會議的使用者人數 |
的使用者總數的 5% |
每天每位使用者的目前狀態查詢次數 |
60 |
每天的使用者搜尋次數 |
12 |
每天每位使用者的連絡人變更次數 |
13 |
同時使用桌面共用的使用者百分比 |
2% |
桌面共用會議中的使用者人數上限 |
6 |
桌面共用會議持續期間 |
1 小時 |
下表列出有關桌面共用模型的資訊。
表 5. 桌面共用模型
| 說明 | 值 |
|---|---|
檢視共用桌面的使用者 |
100 |
共用其桌面的使用者 |
20 |
會議數目 |
20 |
小型會議的大小 |
2 |
中型會議的大小 |
3 |
大型會議的大小 |
6 |
最大型會議的大小 |
6 |
小型會議的百分比 |
10 |
中型會議的百分比 |
15 |
大型會議的百分比 |
70 |
最大型會議的百分比 |
5 |
會議期間 |
1 小時 |
每天交談數目 |
24 |
上一個表中的使用模型是以 Proliant 的測試為基礎。
回應群組服務使用者模型
下表將說明建議的回應群組服務使用者模型，用來做為本節稍後所述的容量規劃需求和建議的基礎。
此模型假定：
- 使用預設的等候音樂檔案。
- 使用英文。
表 6. 回應群組服務使用者模型
| 元件 | 每個 Enterprise 部署 | 每個 Standard Edition Server |
|---|---|---|
作用中的代理程式 (正式和非正式) |
1,200 |
1,200 |
標準回應群組數目 |
450 |
150 |
使用的佇列數目 |
每個群組搜尋有 1 個唯一佇列、單層互動回應群組有 2 個 |
每個群組搜尋有 1 個唯一佇列、單層互動回應群組有 2 個 |
路由方法在群組上的分佈情形 |
平行路由：40% 最長閒置時間：40% 序列：10% 循環配置資源：10% |
平行路由：40% 最長閒置時間：40% 序列：10% 循環配置資源：10% |
在互動語音回應系統 (IVR) 中使用語音辨識之工作流程與 IVR 中只使用複頻式訊號 (DTMF) 之工作流程的百分比 |
語音辨識/文字轉語音 (SR/TTS) + DTMF：50% DTMF：50% |
SR/TTS + DTMF：50% DTMF：50% |
群組搜尋數目 (混合 50% 的簡單和 50% 的複雜群組搜尋) |
600 |
300 |
每個群組的平均代理程式數目 |
10 個代理程式 |
10 個代理程式 |
代理程式所屬的平均群組數目 |
兩個群組 |
兩個群組 |
每個佇列的群組數目 (平均) |
90%：一個群組 10%：兩個群組 |
90%：一個群組 10%：兩個群組 |
同時回應群組電話的數目 |
480 |
60 |
通話平均等候時間 (IVR 部分 + 等候音樂) |
30 秒 |
30 秒 |
有專員回應的平均通話時間 |
3 分鐘 |
3 分鐘 |
一天內正式專員登入/登出週期數目 (根據每天 8 小時) |
4 |
4 |
容量規劃需求和建議
下表提供可協助進行組織的容量規劃的資訊。
表 7. 每個拓撲支援的使用者人數上限
| 拓撲 | 所需的伺服器 | 支援的使用者人數上限 |
|---|---|---|
Standard Edition server |
一部 Standard Edition Server |
5,000 |
Enterprise Pool、合併設定 |
八部執行所有伺服器角色的 Enterprise Edition 前端伺服器 一部後端 SQL Server |
100,000 .gif "Dd425159.note(zh-tw,office.13).gif") 附註：
如果只部署 IM 和目前狀態，在八部「前端伺服器」和一部執行 Microsoft SQL Server 資料庫軟體之 16 核心電腦的環境中，Office Communications Server 2007 R2 可支援 200,000 個用戶端端點，每個端點都是一個用戶端程式，例如 Communicator。後端資料庫必須在四向處理器、四核心或八向處理器、雙核心、2.0 GHz+ 電腦上執行。
|
封存伺服器 |
一部封存伺服器 |
300,000 |
監控伺服器 |
一部監控伺服器 |
200,000 |
Group Chat 伺服器 |
三個群組交談伺服器 |
60,000 (每個伺服器 20,000)。 附註：
您必須針對增加的伺服器及使用者支援部署QFE 1。
|
Edge Server 拓撲假定總共有 10% 的使用者人數會從內部網路以外地方連線進來。下表說明下列每一個 Edge Server 角色與拓撲所支援的用戶端連線數目上限。
表 8. Edge Server 拓撲支援的用戶端數目上限
| 拓撲 | 支援的效能 |
|---|---|
Edge Server |
Access Edge Service：5,000 個 Access Edge Service 用戶端連線 Web Conferencing Edge service：1,000 個用戶端連線 A/V Edge Service：500 個同時連線的音訊/視訊 (A/V) 工作階段 |
如需外部存取，建議您部署 Director。
表 9. Communicator Web Access 容量
| 效能衡量標準 | Communicator Web Access 顯示狀態和 IM、Communicator Mobile for Java、搜尋，以及桌面共用 |
|---|---|
使用者人數 |
5,000 位使用者 120 位同時使用桌面共用的使用者 |
| 附註： |
|---|
| 電腦設定：2.3 GHz CPU、8.0 GB 記憶體、8 處理器、停用 Kernel SSL、ASP NET 1.5 要求佇限制為 1.5 * 伺服器的同時使用者數目、HTTPS 連線、不與其他虛擬伺服器或 Office Communications Server 共同配置、16 GB 虛擬記憶體、Communicator Web Access 記錄 (零售追蹤) 設定為關閉 |
| 附註： |
|---|
| 電腦設定：3.0 GHz CPU、1.0 GB 記憶體、100 Mbps 網路、80 GB 硬碟、Internet Explorer 7.0 瀏覽器、Microsoft Windows XP SP2 作業系統、1280x1024 顯示器 |
表 10. 儲存磁碟容量規劃
| 儲存磁碟 | 每次讀取的平均磁碟位元組和每次寫入的平均磁碟位元組 (100,000 位使用者) | 磁碟讀取和寫入速度 (以秒計，100,000 位使用者) |
|---|---|---|
Enterprise Pool 後端資料磁碟 |
讀取：0 寫入：2,180 |
讀取：0 寫入：158.3 |
Enterprise Pool RTC 記錄檔 |
讀取：0 寫入：832 |
讀取：0 寫入：216.2 |
Enterprise Pool RTCdyn 記錄檔 |
讀取：996 寫入：2,289 |
讀取：0.002 寫入：561.3 |
封存記錄檔磁碟 |
讀取：0 寫入：3,783 |
讀取：0 寫入：110.1 |
封存資料檔案磁碟 |
讀取：761 寫入：3,532 |
讀取：0.091 寫入：38.7 |
監控 (QoE 和 CDR) 資料記錄檔磁碟 |
讀取：8,192 寫入：6,213 |
讀取：85.5 寫入：193.1 |
表 11. 封存和監控資料庫儲存容量規劃
| 元件 | 資料庫每小時平均成長容量 | 使用假設 |
|---|---|---|
封存資料庫 |
每 100,000 個端點每小時 636 MB |
根據每秒 320 個訊息、每個訊息 400 位元組 |
監控資料庫 |
CDR：每小時 162 MB (100,000 個端點) QoE：每小時 482 MB (100,000 個端點) |
假設用戶端未建立視訊通話的 QoE 資料 |
表 12. 群組交談容量規劃
| 聊天室使用情況 | 使用者連線率 | 訊息率 |
|---|---|---|
每位使用者參與 30 個聊天室 每個聊天室有 30 位參與者 |
每部伺服器每秒啟動兩個使用者連線 |
每秒 40 個訊息 (所有聊天室) |
| 附註： |
|---|
| 聊天室可支援 30 位以上的參與者，而「群組交談」用戶端可支援 30 個以上的聊天室。然而，聊天室中參與者人數眾多可能會影響伺服器效能。聊天室的測試設定上限為 1,000 位參與者。 參與者眾多的聊天室數目，應低於己建立之聊天室總數的 10%。 |
| 附註： |
|---|
更新的群組交談容量規劃說明文件及容量規劃試算表皆可從 Microsoft 下載中心免費下載：
|
表 13. 持續性共用物件模型 (PSOM) 應用程式的應用程式共用容量規劃
| 應用程式共用的使用情況 | 傳送與接收 (KBps) | 處理器時間 | 每位使用者的平均頻率使用 (Kbps) |
|---|---|---|---|
15 個會議，90 位使用者 |
收到：1,370 (2,728 尖峰時) 傳送：6,370 (12,315 尖峰時) |
平均：8.5 尖峰時：24.4 |
每個共用者傳送：713.57 每個檢視者接收：552.92 |
表 14. 中繼伺服器容量規劃
| Computer |
|---|
90% 內部使用者，10% 外部/遠端使用者 |
雙處理器、雙核心、3.0 GHz CPU 加上 4 GB 記憶體和 2 x 1 Gbps 網路介面卡 |
雙處理器、四核心、2.3 GHz CPU 加上 4 GB 記憶體和 2 x 1 Gbps 網路介面卡 |
100% 外部/遠端使用者 |
雙處理器、雙核心、3.0 GHz CPU 加上 4 GB 記憶體和 2 x 1 GB 網路介面卡 |
雙處理器、四核心、2.3 GHz CPU 加上 4 GB 記憶體和 2 x 1 GB 網路介面卡 |
| 附註： |
|---|
| 在上面的表中，CPU 使用率是假設為容量的 75%。 「中繼伺服器」的調整數目要視使用者的位置而定，主要是使用者與「中繼伺服器」之間的距離。對於位在內部網路外的使用者，媒體堆疊會使用較低的位元率，這會大幅影響效能。 |
在規劃 Address Book Server 的容量時，需要規劃 Address Book Server 資料庫和通訊錄 Web 查詢服務資料庫的大小、下載檔案的大小，以及將會存取通訊錄 Web 查詢服務的 Office Communicator Mobile for Windows 用戶端數目。
Address Book Server 資料庫所使用的磁碟大小，以及 Address Book Server 建立下載檔案之處的檔案伺服器所使用的磁碟大小，主要視必須儲存的連絡人數目而定。(檔案伺服器也可儲存其他資料。如需詳細資訊，請參閱「儲存需求」中的「資料夾」一節)。估計 Address Book Server 將會儲存在資料庫和下載檔案中的連絡人數目的方法之一，就是假設每位使用者都有兩個連絡人物件。因此，您可以將組織中的使用者人數乘以二，來估計 Address Book Server 的儲存需求。
- 通訊錄下載檔案大小的一般假設：
- 100,000 位連絡人、2.5 GB 儲存區供下載檔案使用 (根據每位員工有兩位連絡人)
- 100,000 位員工、5 GB 儲存區供下載檔案使用
- 通訊錄 Web 查詢資料庫大小的一般假設：
- 100,000 位連絡人、1.5 GB 儲存區
- 1 GB 供資料庫記錄檔使用
表 15. Enterprise Pool 的通訊錄 Web 查詢服務效能
| 使用者人數 | 行動裝置數目上限 | 通訊錄資料庫中的項目數 | 每秒查詢數 | 使用情況附註 |
|---|---|---|---|---|
總計：100,000 啟用語音功能：30,000 |
18,000 (60% 啟用語音功能的使用者) |
300,000 |
平均：17.7 尖峰時間：26.55 |
八個前端伺服器 30% 的使用者已啟用整合通訊。 每秒 100 筆查詢對效能的影響最小。 |
表 16. 音訊/視訊容量規劃
| 媒體 | 轉碼器 | 平均頻寬 (Kbps) | 估計的資料流活動 (%) | 最大頻寬 (Kbps) |
|---|---|---|---|---|
寬頻音訊 |
RTAudio |
34.8 |
61 |
57 |
寬頻音訊 |
Siren |
22.2 |
43 |
51.6 |
窄頻音訊 |
RTAudio |
25.9 |
65 |
39.8 |
視訊 |
RTVideo |
258.3 |
82 |
350 |
全景視訊 |
RTVideo |
220.5 |
70 |
350 |
- 上述是媒體資料流的寬頻數字，除了實際編碼媒體之外，還包含框架處理、加密和 IP 路由資訊的所有額外負荷。
- 平均轉碼器頻寬值是根據測量值，以及基於一般活動層級值而衍生出的最大理論頻寬。音訊活動層級的計算包含資料流中的語音活動。視訊活動層級的計算包含視訊影像中的運動量。
- 「RT 音訊窄頻」的活動層級較高一點，以允許 PSTN 閘道對 Office Communications Server VoIP 至 PSTN 電話，進行不盡理想的「語音活動偵測」。如果部署的 PSTN 閘道上未啟用語音活動偵測，此數字應該再增加 15%。
- 「全景視訊」活動層級比一般視訊資料流低，因為在全景影像中背景區的相對比例較高。
媒體頻寬需求和建議
對於基本媒體閘道而言，閘道與「中繼伺服器」之間的頻寬需求為每通並行電話 80 Kbps。將這個數字乘以每一個閘道的連接埠數目，就是在中繼伺服器的閘道端所需頻寬的合理預估值。在 Office Communications Server 端，頻寬需求則低許多。
設定「中繼伺服器」時，您應接受預設的媒體連接埠閘道範圍 (60,000 到 64,000)。減少連接埠範圍會大幅降低伺服器容量，所以只有在特定的原因下，才能由熟知媒體連接埠需求和案例的管理員來執行。基於這個原因，不建議您更改預設連接埠範圍。
高頻寬流量 (如語音和視訊) 容易對尚未適當佈建的網路造成壓力。將媒體流量限制為已知的連接埠範圍，可讓這類問題的疑難排解變得容易許多。
行動資料頻寬需求
一天 8 小時的行動裝置存取需要約 1 MB 的頻寬。這是以下列使用情況為計算基礎：
- 一個通訊群組加上 15 位使用者
- 連絡人清單中 80 位成員，每小時每位使用者有四次目前狀態更新
- 一位已標記的連絡人一小時有四次目前狀態更新
- 每天 12 通電話，每小時 1 通電話 (每隔兩小時有 1 通來電和 1 通撥出電話)
- 每通電話兩分鐘
- 使用者已登入一個其他端點 (例如 Office Communicator 或桌上電話)
- 每隔兩小時一個 IM 工作階段
- 傳出和傳入的 IM 是相等的 (1:1)