SharePoint Server 2010 的容量規劃

發行項
03/03/2017

適用版本： SharePoint Server 2010

上次修改主題的時間： 2016-11-30

本文說明如何規劃 Microsoft SharePoint Server 2010 伺服器陣列的容量。對容量規劃及管理有良好認識與了解，能讓您將知識應用到調整系統大小這方面。「調整大小」是一個詞彙，用指對適當資料架構、邏輯與實體拓撲以及解決方案平台硬體的選擇和設定。在您判定何謂最適合的硬體及設定選項時，有一些會影響決定的容量管理及使用考量。

閱讀本文之前，您應該先閱讀＜SharePoint Server 2010 的容量管理與縮放概觀＞。

本文說明要針對環境執行有效容量管理，您該採取的步驟。每個步驟都需要特定的資訊以利成功執行，及一組可交付項目，讓您於後續步驟中使用。每個步驟的需求與可交付項目都列在表格中。

本文內容：

步驟 1：模型
步驟 2：設計
步驟 3：試驗、測試與最佳化
步驟 4：部署
步驟 5：監視與維護

步驟 1：模型

首先您要分析目前解決方案、評估預期的需求，並規劃建立部署要達成的目標後，才能規劃 SharePoint Server 2010 型環境。一開始您需要收集使用者群、資料需求、延遲與輸送量目標的相關資訊，並記錄下想要部署的 SharePoint Server 功能。本節可協助您了解要收集哪些資料、如何收集以及如何用在後續步驟中。

了解您預期的工作量與資料集

若要適當調整 SharePoint Server 2010 實作的大小，您需要研究並了解解決方案預期要處理的需求特性。了解需求在於您必須能清楚說明工作量特性 (如使用者數目及最常使用的操作) 與資料集特性 (如內容大小及內容散佈)。

本節能協助您了解一些必須收集的特定評量與參數，以及收集這些資訊的機制。

工作量

工作量說明系統的維持需求、使用者群以及使用特性。下表提供一些對判定工作量有所助益的主要評量，收集資訊時，您可使用此表格來記錄評量。

工作量特性	值
平均每日 RPS
尖峰時間平均 RPS
每日單獨使用者總數
每日並行使用者的平均人數
尖峰時間尖峰並行使用者
每日要求總數
預期的工作量散佈	每日要求數目
網頁瀏覽器 - 搜尋編目
網頁瀏覽器 - 一般共同作業互動
網頁瀏覽器 - 社交互動
網頁瀏覽器 - 一般互動
網頁瀏覽器 - Office Web Apps
Office 用戶端
OneNote 用戶端
SharePoint Workspace
Outlook RSS 同步處理
Outlook Social Connector
其他互動 (自訂應用程式/Web 服務)

並行使用者 – 一般最常見的方法是利用不同使用者在給定時間範圍內產生的要求，來測量伺服器陣列上執行的並行操作。主要的評量是看每日平均值以及尖峰時間並行使用者。
每秒要求數目 (RPS) – RPS 是用來說明伺服器陣列上的需求之常用指標，其表示伺服器陣列每秒處理的要求數，但與要求類型或大小沒有什麼區別。每個組織的使用者群會產生的系統負載比例，是與組織獨特的使用特性息息相關。請參閱 SharePoint Server 2010 的容量管理與縮放概觀中的＜詞彙＞一節，以取得這個詞彙的詳細資訊。
每日要求總數 – 每日要求總數是衡量系統需要處理之總負載的一個很好的指標。最常用的方式是測量所有要求，除了超過 24 小時的驗證握手要求 (HTTP status 401) 以外。
每日使用者總數 - 使用者總數是衡量系統需要處理之總負載的另一個主要指標。這是測量在 24 小時中，唯一使用者的實際數目，而不是組織的總員工數目。

注意

每日使用者總數能指出伺服器陣列上的負載成長潛力。例如，若可能的使用者數目是 100,000 個員工，而每日使用者為 15,000 人，這表示過一段時間，隨著使用者採用增加，其負載可能會大幅增加。
工作量散佈 – 了解與伺服器陣列互動的用戶端應用程式之要求散佈，對移轉至 SharePoint Server 2010 之後的預期趨勢與變更預測很有幫助。當使用者切換至更新的用戶端版本，如 Office 2010，並開始使用新的功能與新負載模式時，RPS 和總要求數都預期會成長。針對每個用戶端，我們能說明在一天某時段中的不同使用者數目，以及伺服器上用戶端或功能產生的總要求數目。

例如，下圖顯示實際內部 Microsoft 環境在使用一般社交解決方案的大概情況。在此範例中，您可以看到負載的主要部分都是由搜尋編目程式與一般使用者網頁瀏覽所產生。您亦可發現到新的 Outlook Social Connector 功能也造成了 6.2% 之要求的大幅負載。

一般每日負載分散要求數目

評估實際作業工作量

在評估伺服器陣列能維持所需的輸送量時，首先要評估伺服器陣列中會使用的交易混合情況。請著重在分析系統要提供的最常用交易、了解其使用的頻率以及使用者數量。這可協助您稍後在實際執行前的測試中，驗證伺服器陣列是否能維持這樣的負載。

下圖說明系統工作量與負載的關係：

容量 - 工作負載圖表

若要評估預期的工作量，請收集下列資訊：

識別使用者互動，如一般網頁瀏覽、檔案下載與上傳、Office Web Application 瀏覽器中的檢視及編輯、共同撰寫互動、SharePoint Workspace 網站同步處理、Outlook Social Connections、RSS 同步處理 (Outlook 或其他檢視器)、PowerPoint 廣播、OneNote 共用筆記本、Excel Service 共用活頁簿、Access Service 共用應用程式等等。請參閱 SharePoint Server 2010 的容量管理與縮放概觀文章中＜服務與功能＞一節，以取得詳細資訊。請著重在識別對部署較獨特的互動，並衡量該負載可能造成的影響，例如是否大幅使用 InfoPath Forms、Excel Service Calculations 與類似的專用解決方案。
識別如搜尋累加編目、每日備份、設定檔同步處理、計時器工作、Web Analytics 處理、記錄計時器工作等等的系統作業。
評估預期將使用每項功能的每日使用者總數，推算評估的並行使用者與概略的每秒要求數目。您需要做一些假設，如目前的並行性及不同功能中每個並行使用者的 RPS 因素，您應該使用本節稍早的工作量表格來評估。您應著重在尖峰時間，而不是平均輸送量。針對尖峰活動做好規劃，您才能適當調整 SharePoint Server 2010 型解決方案的大小。

若已有現有的 Office SharePoint Server 2007 解決方案，您可以探索 IIS 記錄檔或查看擁有的其他 Web 監視工具，以更清楚地了解現有解決方案的部分預期行為，您亦可查看下節中的指示以取得更詳細之資訊。若您不是從現有解決方案進行移轉，則可使用概略評估填妥下表。在之後的步驟中，您將需要驗證這些假設並調整系統。

分析 SharePoint Server 2010 IIS 記錄檔

若要探索現有 SharePoint Server 2010 部署的主要評量，如有多少作用中的使用者、他們使用系統的程度、會傳入哪種要求及要求是源自哪種用戶端，就必須從 ULS 和 IIS 記錄檔擷取資料。其中一個擷取資料最簡單的方法是使用記錄剖析器，且您可免費從 Microsoft 下載這個強大的工具。記錄剖析器能讀取並寫入包括所有 IIS 格式的多種文字及二進位格式。

如需如何使用記錄剖析器分析 SharePoint Server 2010 的詳細資訊，請閱讀分析 Microsoft SharePoint 產品及技術使用 (可能為英文網頁) (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en)。

您可於 https://www.microsoft.com/download/en/details.aspx?id=24659 (可能為英文網頁) 下載記錄剖析器 2.2。

資料集

資料集是說明系統中儲存的內容量，以及其如何散佈至資料儲存區。下表提供一些能協助您判定資料集的主要評量。在收集資訊時，您可以使用這個表格來記錄評量。

物件	值
資料庫大小 (GB)
內容資料庫數目
網站集合數目
Web 應用程式數目
網站數目
搜尋索引大小 (項目數目)
文件數目
清單數目
網站平均大小
最大網站大小
使用者設定檔數目

內容大小 – 了解預期儲存在 SharePoint Server 2010 系統中的內容大小，對規劃及架構系統儲存，以及適當調整會編目及索引該內容的搜尋解決方案大小很有幫助。內容大小是用總磁碟空間量來表示。若您從現有部署來移轉內容，要識別出要移動的總大小很簡單，不過在規劃時仍要依據預測趨勢預留未來的成長空間。
文件總數目 – 除了資料主體大小，追蹤總共項目數目也重要。因為以 100 GB 的資料來說，是由 50 個 2 GB 檔案組成跟由 100,000 個 1 KB 檔案組成，系統的反應是截然不同的。在大型部署中，單一項目、文件或文件區域上的壓力愈小，效能就愈高。散佈廣泛的內容，如分佈於多個網站及網站集合的多個小檔案，會比含有大型檔案的一個大型文件庫使用起來更容易。
網站集合大小上限 – 識別您將儲存於 SharePoint Server 2010 中的最大內容單位是很重要的一環，通常這些內容單位是因為組織需求所以無法分割。您亦可使用所有網站集合的平均大小及網站集合的估算總數做為額外的指標，協助您找出所偏好的資料架構。
服務應用程式資料特性 – 除了分析內容儲存區的儲存需要外，您應該分析並評估 SharePoint Server 2010 儲存區的大小，包括：
搜尋索引的總大小
設定檔資料庫總大小是以設定檔儲存中的使用者數目而定
社交資料庫總大小是以預期的標記、同事及活動數目而定
中繼資料儲存區大小
使用狀況資料庫大小
Web Analytics 資料庫大小

如需如何評估資料庫大小的詳細資訊，請參閱規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)。

設定伺服器陣列效能與可靠性目標

步驟 1：模型中的一個可交付項目就是良好地了解最符合組織需求的效能與可靠性目標。適當設計的 SharePoint Server 解決方案應能在一秒內的伺服器回應中達到「四個 9」(99.99%) 的執行時間。

用來說明伺服器陣列的效能與可靠性指標包括：

伺服器可用性 – 會以百分比方式指出系統可用的整體執行時間。您應追蹤任何未預期的停機時間，並將整體的可用性與您所設定的組織目標進行比較。目標通常以 9 組成的數字表示 (例如 99%、99.9%、99.99%)
伺服器回應 – 伺服器陣列提供要求所需的時間，是追蹤伺服器陣列狀況的良好指標。這樣的指標通常稱為伺服器端延遲，且通常使用每日提供要求的平均或中等 (第 50 個百分位數) 延遲。目標通常是用次秒或秒來表示。請注意，若您的組織設定目標必須在兩秒內提供 SharePoint Server 2010 的頁面，則伺服器端的目標就必須加入頁面經由網路抵達用戶端，以及在瀏覽器中呈現的秒數。此外，一般來說較長的伺服器回應時間代表伺服器陣列狀況不佳，且通常會對輸送量造成衝擊，若您在伺服器的大多數要求都要花超過一秒，RPS 就跟不上
伺服器暴增 – 另一個不錯且值得追蹤的伺服器延遲指標是所有要求中最慢的 5% 之行為。慢速要求通常是指在系統負載量大的時候發來的要求，或通常是因為受不常用活動衝擊導致的要求，這些活動是使用者與系統互動時發生的，不過，狀況良好的系統即使有最慢的要求，也能掌控得很好。此處的目標與伺服器回應類似，但要達到小於一秒的伺服器暴增回應，您將需要建立許多備用資源，以應對負載的暴增。
系統資源使用 – 另外一個用來追蹤系統狀況的常用指標是系統計數器的集合，其可指出伺服器陣列拓撲中每個伺服器的狀況。最常使用的追蹤指標是 % CPU 使用量及可用記憶體；不過，還有若干其他計數器可用來協助識別狀況不佳的系統，如需更詳細的資訊，請參閱步驟 5：維護。

步驟 2：設計

現在您已完成所要交付之解決方案的實際狀況或評估狀況的收集工作，可以接著設計您認為足以支撐預期需求的建議架構。

在這個步驟的最後，您應已具備實體拓撲的設計以及邏輯拓撲的版面配置，因此可以進行各項必要採購。

硬體規格及您版面配置的機器數目息息相關，若要處理特定負載，有許多種解決方案可供您選擇部署。通常可以使用少量的強大機器 (垂直擴充) 或大量的小型機器 (向外延展)；每個解決方案在容量、備援、能力、成本、空間與其他考量上都有其優勢和劣勢。

建議您在這步驟的一開始先判定架構與拓撲。定義出您規劃如何為不同伺服器陣列及每個伺服器陣列中的不同服務來做版面配置，然後為設計中的個別伺服器挑選硬體規格。就這個程序來說，您也可以找出預期要部署的硬體規格 (許多組織會受限於符合公司特定標準)，然後再定義架構與拓撲。

請使用下表來記錄您的設計參數，表中包括的資料是資料範例，您不應以此做為調整伺服器大小的基準。本範例的目的是示範如何使用這個表格來記錄資料。

角色	類型 (標準或虛擬)	機器數目	處理器	RAM	IOPS 需求	磁碟大小 OS+Log	資料磁碟機
網頁伺服器	虛擬	4	4 核心	8	無	400 GB	無
內容資料庫伺服器	標準	1 個叢集	四個四核心 2.33 (GHz)	48	2k	400 GB	20 個 300 GB 磁碟 @ 15K RPM
應用程式伺服器	虛擬	4	4 核心	16	無	400 GB	無
搜尋編目目標網頁伺服器	虛擬	1	4 核心	8	無	400 GB	無
搜尋查詢伺服器	標準	2	雙四核心 2.33 (GHz)	32	無	400 GB	500 GB
搜尋編目程式伺服器	標準	2	雙四核心 2.33 (GHz)	16	400	400 GB	無
搜尋編目資料庫伺服器	標準	1 個叢集	四個四核心 2.33 (GHz)	48	4k (為讀取而調整)	100 GB	16 個 150GB @ 15K RPM 磁碟
搜尋屬性儲存資料庫 + 管理資料庫伺服器	標準	1 個叢集	四個四核心 2.33 (GHz)	48	2k (為寫入而調整)	100 GB	16 個 150GB @ 15K RPM 磁碟

判定您的架構起點

本節說明如何選取架構起點。

當您部署 SharePoint Server 2010 時，您可從廣泛的拓撲中選擇實作解決方案；您可以部署單一伺服器或向外延展許多伺服器至 SharePoint Server 伺服器陣列，而其中具備叢集或鏡像資料庫伺服器以及各種服務的應用程式伺服器。稍後您將依據每個角色的需求，以容量、可用性及備援需求為基礎來選取硬體設定。

您可先檢閱不同參考架構，再構想出伺服器陣列結構，決定是否要將解決方案分割至多個伺服器陣列，或聯盟部分服務，如在專屬伺服器陣列上搜尋。請參閱 SharePoint Server 2010 的容量管理與縮放概觀中的＜參考架構＞一節，以取得詳細資訊。

SharePoint Server 2010 技術案例研究

SharePoint Server 2010 容量管理指導包括大量現有實際執行環境的技術案例研究，並呈現現有 SharePoint Server 型實際執行環境的詳細說明。額外的技術案例研究會隨時間發佈；這些指導僅為如何設計特定用途的 SharePoint Server 型實際執行環境之參考。

在設計 SharePoint Server 解決方案架構時，您可以參考這些案例研究，尤其當這些部署特定關鍵差異的說明與您要架構的解決方案需求及目標類似時。

這些文件提供各項案例研究記錄的下列資訊：

規格：如硬體、伺服器陣列拓撲及設定；
工作量：包括使用者群及使用特性；
資料集：包括內容大小、內容特性與內容散佈
狀況和效能：包括一組說明伺服器陣列的可靠性及效能特性等記錄的指標

如需詳細資訊，請至效能與容量技術案例研究 (可能為英文網頁) 頁面 (https://technet.microsoft.com/zh-tw/library/cc261716.aspx (可能為英文網頁)) 下載相關文件。

選取硬體

為伺服器陣列選取適當規格的機器是確保您部署的適當可靠性與效能之重要步驟，只要謹記一個主要概念，那就是您應該為尖峰負載與尖峰時間做規劃；如此一來，當伺服器陣列在平均負載環境中運作時，就能有足夠的資源來應對最大的預期需求，同時還能達到延遲與輸送量目標。

伺服器的核心容量與效能硬體功能會反應在四個主要類別：處理能力、磁碟效能、網路容量及系統的記憶體功能。

另一件要考慮的事是使用虛擬機器。SharePoint Server 伺服器陣列可使用虛擬機器進行部署。此法雖不會增加任何效能益處，卻有助於管理。一般不建議您使用虛擬 SQL 伺服器型電腦，但虛擬化網頁伺服器及應用程式層級應會有些助益。如需詳細資訊，請參閱虛擬化規劃 (https://technet.microsoft.com/zh-tw/library/ff607968.aspx)。

硬體選擇準則

選擇處理器

SharePoint Server 2010 僅適用於 64 位元處理器。一般來說，處理器愈多，愈能提供更高的需求。

在 SharePoint Server 2010 中，當您新增更多核心時 (我們最多測試過 24 核心)，個別的網頁伺服器將會擴充；愈多核心，則伺服器可維持更高的負載，其他部分則都是一樣的。我們會建議在大型 SharePoint Server 部署中，配置多個 4 核心網頁伺服器 (亦可虛擬化)，或較少數但更強大的 (8/16/24 核心) 網頁伺服器。

應用程式伺服器的處理器容量需求會隨伺服器角色與執行的服務而有所差異。有些 SharePoint Server 功能需要較強大的處理能力，例如。SharePoint Search Service 就非常依賴應用程式伺服器的處理能力。如需 SharePoint Server 功能與服務之資源需求的詳細資訊，請參閱＜SharePoint Server 2010 的容量管理與縮放概觀＞一文中的＜服務與功能＞章節。

SQL Server 的處理器容量需求亦與 SQL Server 型電腦所主控的服務資料庫息息相關。如需每個資料庫的一般行為與需求之詳細資訊，請參閱規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)。

選擇記憶體

伺服器依據伺服器功能與角色，會需要不同的記憶體量。例如，執行搜尋編目元件的伺服器若有較大的記憶體量，則可更快速地處理資料，因為文件是讀進記憶體中進行處理的。而利用許多 SharePoint Server 2010 快取功能的網頁伺服器也需要更多的記憶體。

一般來說，網頁伺服器記憶體需求與伺服器陣列中啟用的應用程式集區數目，及提供的並行要求數目高度相關。在大多數的實際作業 SharePoint Server 部署中，建議於每個網頁伺服器配置至少 8 GB RAM，而伺服器若屬於較高流量或具備多應用程式集區隔離設定之部署則建議配置 16 GB。

應用程式伺服器的記憶體需求亦各異，有些 SharePoint Server 功能，跟其他功能相較，對應用程式層級有較高的記憶體需求。在大多數的實際作業 SharePoint Server 部署中，建議於每個網頁伺服器配置至少 8 GB RAM，而當同部伺服器上啟用很多應用程式服務，或服務高度依賴記憶體時 (如啟用 Excel Calculation Service 及 SharePoint Server Search Service)，16 GB、32 GB 及 64 GB 應用程式伺服器也是很普遍的。

資料庫伺服器的記憶體需求與資料庫大小關係密切。如需為 SQL Server 型電腦選擇記憶體的詳細資訊，請參閱規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)。

選擇網路

若想讓使用者在使用上更加便利，除了用戶端要有快速的網路資料存取能力，分散式伺服器陣列也必須在伺服器間的通訊上有快速的存取能力。當您將服務分散至多部伺服器，或是將部分服務聯盟到其他伺服器陣列時更是如此。跨網頁伺服器層級、應用程式伺服器層級及資料庫伺服器層級中伺服器陣列的流量很大，因此在某些情況下，如處理非常大的檔案或極高負載時，網路有可能成為瓶頸。

網頁伺服器及應用程式伺服器應設定為至少配有兩張網路介面卡 (NIC)：一張 NIC 處理使用者流量，另一張處理伺服器間的通訊。伺服器間的網路延遲可能會對效能產生極大衝擊，因此在網頁伺服器與主控內容資料庫的 SQL Server 型電腦間的網路延遲應小於 1 毫秒。而主控每個服務應用程式資料庫的 SQL Server 型電腦亦應儘可能與使用的應用程式伺服器接近。伺服器陣列伺服器間的網路應至少有 1 Gbps 的頻寬。

選擇磁碟與儲存區

磁碟管理功能不只是為資料提供足夠的空間這麼單純。您必須評估持續的需求和成長，並確定儲存架構不會讓系統速度變慢。您應該總是為每個磁碟保留至少高於您最高資料需求評估之 30% 的額外容量，以預留未來成長的空間。此外，在大多數的實際執行環境中，磁碟速度 (IOps) 對提供足夠輸送量及滿足伺服器儲存需求扮演了很重要的角色。您必須評估部署中主要資料庫需要的流量 (IOps)，並配置足夠的磁碟來滿足流量。

如需如何選擇資料庫伺服器磁碟的詳細資訊，請參閱規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)。

網頁及應用程式伺服器也都有儲存需求。在大多數的實際執行環境中，建議您配置至少 200 GB 的 OS 與暫存磁碟空間及 150 GB 的記錄磁碟空間。

步驟 3：試驗、測試與最佳化

測試及最佳化階段在有效的容量管理中是很重要的一環。在將新架構部署至實際執行環境前，應先應先測試新架構，並搭配下列最佳監視作法執行接受度測試，以確保所設計的架構能夠達到效能與容量目標。如此才能於潛在的瓶頸影響到實際部署的使用者前，讓您將其識別出來並最佳化。若是從 Office SharePoint Server 2007 環境升級，並打算變更架構，或正在評估 SharePoint Server 新功能的使用者負載，則測試對於採用 SharePoint Server 的新環境能否達到預定的效能與容量目標即格外重要。

一旦測試過環境，即可分析測試結果並判定為了達到您在步驟 1：模型中建立的效能與容量目標，還需要做哪些變更。

這些是建議您在實際執行前應執行的子步驟：

建立測試環境，模擬您在＜步驟 2：設計＞中設計的初始架構。
以您在＜步驟 1：模型＞中識別的資料集或資料集部分填入存放區。
以代表您在＜步驟 1：模型＞中識別之工作量的綜合負載對系統施壓。
執行測試、分析結果，然後最佳化架構。
在資料中心部署經過最佳化的架構，然後導入少量使用者進行試驗。
分析試驗結果、識別潛在瓶頸，然後最佳化架構。請在必要時重新測試。
部署至實際執行環境。

測試

測試是建立系統設計能力以支援工作量及使用特性的重要因素。請參閱 SharePoint Server 2010 效能測試以取得測試 SharePoint Server 2010 部署相關的詳細資訊。

訂立測試計畫
建立測試環境
建立測試及工具

部署試驗環境

在將 SharePoint Server 2010 部署至實際執行環境前，您應先部署試驗環境並完整測試伺服器陣列，以確定其能達到您預期之尖峰負載的容量與效能目標。建議您先用針對大型部署的綜合負載來測試試驗環境，然後再增加一小組實際使用者與實際內容。搭配一小組實際使用者分析試驗環境的好處是您可以先驗證之前對使用特性與內容成長的部分假設，再完全進入實際作業。

最佳化

若擴充伺服器陣列硬體或變更拓撲都無法達到容量與效能目標時，您可能要考慮修改解決方案。例如，若您一開始只需要一個伺服器陣列進行共同作業、搜尋及社交，即可能需要將部分服務 (如搜尋) 聯盟至專用的服務伺服器陣列，或將工作量分散到更多伺服器陣列。另外一種替代方式則是部署一個伺服器陣列專門用於社交，再部署另一個伺服器陣列用於小組共同作業。

步驟 4：部署

一旦您已執行最後一輪的測試並確認所選的架構可達到您在步驟 1：模型所建立的性能與容量目標時，您就可以將 SharePoint Server 2010 型環境部署至實際作業中。

適當的導入策略依據環境和情況而有所不同。雖然 SharePoint Server 部署通常不在本文件範圍之內，但還是有些建議的活動可用來做容量規劃練習。以下為一些範例：

**部署新的 SharePoint Server 伺服器陣列：**在設計及部署 SharePoint Server 2010 時，應指導容量規劃練習並確認規劃。在這種情況下，導入通常是初步的 SharePoint Server 2010 廣泛部署。這需要將容量規劃練習期間使用的伺服器與服務，移動或重建至實際作業中。而這是最直接的案例，因為其中現有的伺服器陣列不需任何升級或修改。
**將 Office SharePoint Server 2007 伺服器陣列升級至 SharePoint Server 2010：**容量規劃練習應驗證伺服器陣列設計可符合現有要求，並可擴充以滿足增加的需求與 SharePoint Server 2010 伺服器陣列的使用。容量規劃練習的一部分應包括測試移轉，以驗證升級程序要花多長時間、是否需要修改或取代任何自訂程式碼、是否要更新任何協力廠商工具等等。在容量規劃完成時，您應該已經驗證您的設計，並了解升級所需要的時間，並規劃了最佳的升級作法，如就地升級，或是將內容資料庫移轉至新的伺服器陣列。若要就地升級，則在容量規劃期間，應已清楚會需要額外或升級的硬體，以及停機時間的考量。部分從規劃練習的輸出應包括所需的硬體變更清單，和初次將硬體變更部署至伺服器陣列的詳細規劃。一旦已在容量規劃期間驗證完畢的硬體平台就緒後，您就可以進展到升級至 SharePoint Server 2010 的程序。
**提升現有 SharePoint Server 2010 伺服器陣列的效能：**容量規劃練習應已協助您識別目前實作中的瓶頸，想出減少或避免這些瓶頸的方法，並驗證改良的實作能符合 SharePoint Server 服務的商務需求。要解決效能問題有不同的方法，如重新配置現有硬體的服務、升級現有硬體或新增額外硬體並新增額外服務至該硬體等。您應在容量規劃練習期間測試與驗證不同的方法，然後再依據該測試結果產出部署規劃。

步驟 5：監視與維護

您必須監視伺服器並識別潛在的瓶頸以維護系統效能。在能有效監視前，您必須了解主要的指標，才能看出哪部分的伺服器陣列需要特別注意，並清楚如何解讀這些指標。若您發現伺服器陣列的作業沒有達到定義的目標，可以新增或移除硬體資源、修改拓撲或變更資料儲存方式，來調整伺服器陣列。

請參閱監視及維護 SharePoint Server 2010 以取得設定清單，其中包括您能在早期階段中修改以監視環境的設定，可協助您判斷是否需要進行任何變更。請注意，提高監視性能會影響您對您使用狀況資料庫所需的磁碟空間量。一旦環境穩定而不再需要詳細監視時，您可能會想要將下列設定回復為預設值。

如需使用 SharePoint Server 管理中心介面內建之狀況監視工具，來監視狀況與疑難排解的詳細資訊，請閱讀下列文章：

狀況監視 (SharePoint Server 2010)

解決問題與疑難排解 (https://technet.microsoft.com/zh-tw/library/ee748639.aspx)

共用方式為