SharePoint Server 2013 的容量規劃

發行項
05/31/2024

適用於： yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

本文說明如何規劃 SharePoint Server 2013 伺服器陣列的容量。當您對容量計劃與管理有良好體認與瞭解後，就能將這些知識應用於調整系統大小。「調整大小」一詞意指為解決方案平台選擇及設定適當的資料架構、邏輯與實體拓撲以及硬體。有一系列的容量管理和使用量考慮會影響您應該如何判斷最適當的硬體和組態選項。

閱讀本文之前，應先閱讀SharePoint Server 2013 的容量管理及調整大小概觀。

重要事項

本文中的某些資訊和值是以測試結果和其他與 SharePoint 2010 產品相關的資訊為基礎，而且可能不代表 SharePoint Server 2013 的最終值。

在本文中，我們將說明您應針對自身的環境採取什麼步驟，以開始進行有效的容量管理。每個步驟都需要特定資訊才能成功執行，而且有一組您將在後續步驟中使用的交付專案。這些需求與交付項目將在下文針對每個步驟的介紹中以表格列出。

步驟 1：模型

建立 SharePoint Server 2013 架構環境的模型一開始，請先分析現有的解決方案，並預估您計畫設定之部署的預期需求和目標。首先，您會收集使用者基底、數據需求、延遲和輸送量目標的相關信息，並記錄您想要部署的 SharePoint Server 2013 功能。本節將指出應收集的資料、收集方式，以及這些資料將可如何應用在後續步驟中。

了解預期會有的工作負載與資料集

若要適當調整 SharePoint Server 2013 實作的大小，您必須研究並瞭解解決方案預期要處理的需求特性。瞭解需求需要您能夠描述工作負載特性，例如用戶數目和最常用的作業，以及內容大小和內容發佈等數據集特性。

本節將協助您了解所應收集的一些特定量值與參數，以及可用的收集機制。

工作負載

工作負載描述系統將必須承擔的需求、使用者群以及使用特性。下表提供一些有助於判斷工作負載的重要量值。您可以使用這張表格來記錄所收集到的這些量值。

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

並行使用者 - 最常測量伺服器數位上所執行作業的並行，做為在指定時間範圍中產生要求的不同用戶數目。重要量值是每日平均值以及尖峰負載時期的並行使用者數。
每秒要求數 (RPS) - RPS 是常用的指標，用來描述伺服器數位上以伺服器陣列每秒處理的要求數目表示的需求，但要求類型或大小之間沒有差異。每個組織的使用者群都會產生系統負載，而產生的負載大小取決於組織的獨特使用特性。如需詳細資訊，請參閱詞彙。
每日要求總數 - 每日要求總數是系統需要處理之整體負載的良好指標。在24小時內，除了驗證交握要求 (HTTP 狀態401) 之外，最常測量所有要求。
每日使用者總計 – 使用者總計是系統必須處理之整體負載的另一項重要指標。此度量是 24 小時內唯一用戶的實際數目，而不是組織中的員工總數。

注意事項

每日使用者總計數目可以指出伺服器陣列上的負載增長潛力。例如，如果可能的使用者是 10 萬名員工，則每日 1 萬 5 千名使用者表示隨著使用者的採用情形增加，負載可能日益大幅增長。
工作負載散發 - 根據用戶端與伺服器數位互動的應用程式來瞭解要求的散發，有助於預測移轉至 SharePoint Server 2013 之後的預期趨勢和負載變更。當用戶轉換至較新的用戶端版本，例如 Office 2013，並開始使用新功能時，新的負載模式、RPS 和要求總數預期會成長。針對每個客戶端，我們可以描述在一天的時間範圍中使用它的不同用戶數目，以及用戶端或功能在伺服器上產生的要求總數。

例如，下圖顯示提供一般社交解決方案的即時內部 Microsoft 環境在某一時刻的數據。在此範例中，您可以看到大部分的負載是由搜尋編目程式和一般使用者網頁瀏覽所產生。您也可以觀察 Outlook Social Connector 功能 (6.2% 的要求) 導入大量負載。

估計實際執行時的工作負載

在估計伺服器陣列必須能夠承擔的必要輸送量時，請先估計伺服器陣列中將使用哪些各種不同交易。著重於分析系統將提供的最常用交易，並了解它們的使用頻率，以及有多少使用者。當您稍後驗證伺服器陣列是否可以在生產前測試中承受這類負載時，這項瞭解將協助您。

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

容量 - 工作負載圖表

若要估計預期的工作負載，請收集下列資訊：

識別用戶互動。例如：
- 網頁流覽。
- 檔案下載和上傳。
- 瀏覽器中的 Office Web 應用程式檢視和編輯。
- 共同撰寫互動。
- SharePoint 工作區網站同步處理。
- Outlook 社交連線。
- Outlook 或其他檢視) 中的 RSS 同步 (。
- PowerPoint 廣播。
- OneNote 共用筆記本。
- Excel Service 共用活頁簿。
- Access Service 共用應用程式
如需詳細資訊，請參閱服務和功能。將焦點放在識別對部署而言可能是唯一的互動。辨識這類負載的預期影響。例如，大量使用 InfoPath Forms、Excel Service Calculations 和類似的專用解決方案。
找出系統作業，例如搜尋累加編目、每日備份、設定檔同步計時器工作、Web 分析處理、記錄計時器工作等。
估計下列專案：
- 預期每天使用每個功能的用戶總數。
- 每秒衍生預估並行使用者和高階要求。
您將進行一些假設。例如：
- 呈現並行。
- 每個並行使用者的 RPS 因數，各功能不同
使用本節稍早的工作負載數據表作為您的估計值。請務必專注於尖峰時間，而不是平均輸送量。規劃尖峰活動，可讓您正確調整 SharePoint Server 2013 型解決方案的大小。

如果您有現有的 Office SharePoint Server 2007 解決方案，您可以挖掘 IIS 記錄檔，或尋找其他 Web 監視工具，以進一步瞭解現有解決方案中的一些預期行為。否則，請參閱下一節中的指示以取得詳細數據。如果您不是從現有的解決方案移轉，您應該使用粗略估計來填寫數據表。在後續步驟中，您必須驗證您的假設並調整系統。

分析 SharePoint Server 2013 IIS 記錄檔

您必須從 ULS 和 IIS 記錄中擷取數據，以探索現有 SharePoint Server 2013 部署的重要計量。例如：

作用中用戶數目。
他們使用系統的程度。
要傳入何種要求。
要求源自何種用戶端。

尋找此數據的最簡單方式之一是使用 Log Parser，這是一個功能強大的工具，可從Microsoft免費下載。記錄剖析器可以讀取和寫入許多文字和二進位格式，包括所有 IIS 格式。

您可以在下載記錄剖析器 2.2。https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07

資料集

資料集描述系統中儲存的內容量，以及這些內容在資料存放區中的散佈方式。下表提供一些有助判斷資料集的重要量值。您可以使用這張表格來記錄所收集到的這些量值。

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

內容大小 - 瞭解您預期要儲存在 SharePoint Server 2013 系統中的內容大小，對於規劃和架構系統記憶體，以及適當調整搜尋解決方案大小，以編目和編製此內容索引非常重要。內容大小是以總磁碟空間描述。如果您要從現有的部署移轉內容，您可能會發現識別要移動的總內容大小很簡單。在規劃期間，您應該保留隨著時間成長的空間。
文件總數 - 除了數據主體大小之外，請務必追蹤整體項目數目。在面對由 50 個 2 GB 檔案組成，和由 100,000 個 1 KB 檔案組成的100 GB 資料時，系統的反應方式將有所不同。在大型部署中，單一專案、文件或文件區域的壓力越小，效能就越好。與具有大型檔案的單一大型文檔庫相比，在許多網站和網站集合之間廣泛散發的內容，例如多個較小的檔案，更容易提供。
網站集合大小上限 - 請務必識別您將在 SharePoint Server 2013 中儲存的最大內容單位;通常是組織的需求，可防止您分割該單位的內容。所有網站集合的平均大小和網站集合的估計總數是其他指標，可協助您識別慣用的數據架構。
服務應用程式資料特性 - 除了分析內容存放區的記憶體需求之外，您也應該分析並估計其他 SharePoint Server 2013 存放區的大小，包括：
搜尋索引總大小
配置檔資料庫大小總計，以配置檔存放區中的用戶數目為基礎
根據預期的標籤、同事和活動數目的社交資料庫總大小
中繼資料存放區大小
使用量資料庫大小
Web Analytics 資料庫大小

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

＜步驟 1：模型＞的其中一個交付項目是熟知最符合貴組織需求的效能與可靠性目標。正確設計的 SharePoint Server 2013 解決方案應該能夠達到「四個九」， (99.99%) 運行時間與次秒伺服器回應性。

用來描述伺服器陣列之效能與可靠性的指標可包括：

伺服器可用性：依系統整體運行時間的百分比來描述。您應追蹤任何非預期的停機時間，並將整體可用性與您設定的組織目標進行比較。這些目標通常由數個九個 (描述，也就是 99%、99.9%、99.99%)
伺服器回應性：伺服陣列處理要求所需的時間是追蹤伺服器陣列健康情況的良好指標。此指標命名為 伺服器端延遲。 Tt 通常會使用每日要求 (第 50 個百分位數) 延遲的平均值或中位數。這些目標通常會以秒數或秒數為單位來描述。如果目標是在兩秒內提供頁面，則伺服器端的目標應該以一秒為單位。此提升的效能可讓頁面有時間到達用戶端，並在瀏覽器中轉譯。此外，較長的伺服器回應時間通常表示伺服器數位狀況不良。如果您在伺服器上花費超過一秒的時間來處理大部分的要求，RPS 幾乎無法跟上。
伺服器曲線：另一個值得追蹤的良好伺服器端延遲指標是所有要求中最慢 5% 的行為。較慢的要求通常是在系統負載較高或更常受到使用者與系統互動時較不頻繁活動所影響的要求時，叫用系統的要求;狀況良好的系統也是控制最慢要求的系統。此處的目標類似於伺服器回應性，但若要在伺服器 spikiness 上達到次秒回應，您必須使用許多備用資源來建置系統，以處理負載尖峰。
系統資源使用率：用來追蹤系統健康情況的其他常見指標是系統計數器的集合，指出伺服器數位拓撲中每部伺服器的健康情況。最常追蹤的指標是 %CPU 使用率和可用記憶體;不過，還有數個計數器可協助識別非修復系統;如需詳細資訊，請參閱步驟 5：監視和維護。

步驟 2：設計

既然您已完成收集所需傳遞之解決方案的一些事實或估計值，您就可以開始下一個步驟來設計建議的架構，您預測該架構將能夠維持預期的需求。

此步驟結束時，您應該會得出一份實體拓撲設計和邏輯拓撲配置，供您進一步進行必要的採購。

硬體規格和您配置的電腦數緊密相關，為了處理特定負載，您可以選擇部署的解決方案有數種。通常會使用一組小型的強式機器 (相應增加) 或 (相應放大) 的較大一組小型機器;每個解決方案在容量、備援、電源、成本、空間和其他考慮方面都有其優缺點。

在此步驟，建議您先從決定架構和拓撲開始。定義您計劃如何在每個伺服器數位中設定不同的伺服器陣列和不同的服務，然後在您的設計中挑選每個個別伺服器的硬體規格。您也可以藉由識別預期要部署的硬體規格來執行此程式 (許多組織都受限於特定公司標準) ，然後定義您的架構和拓撲。

使用下表來記錄您的設計參數。包含的數據是範例數據，不會用來調整伺服器數位的大小。其目的是要示範如何將此數據表用於您自己的數據。

角色	類型 (標準或虛擬)	電腦數	Procs	RAM	IOPS 需求	磁碟大小 (作業系統+記錄檔)	資料磁碟機
網頁伺服器	虛擬	4	4 個核心	8	不適用	400 GB	不適用
內容資料庫伺服器	標準	1 個叢集	4 個四核心 2.33 (GHz)	48	2k	400 GB	20 個 300 GB 的磁碟 @ 15K RPM
應用程式伺服器	虛擬	4	4 個核心	16	不適用	400 GB	不適用
搜尋編目目標網頁伺服器	虛擬	1	4 個核心	8	不適用	400 GB	不適用
搜尋查詢伺服器	標準	2	2 個四核心 2.33 (GHz)	32	不適用	400 GB	500 GB
搜尋編目程式伺服器	標準	2	2 個四核心 2.33 (GHz)	16	400	400 GB	不適用
搜尋編目資料庫伺服器	標準	1 個叢集	4 個四核心 2.33 (GHz)	48	4k (針對讀取調整)	100 GB	16 個 150 GB @ 15K RPM 的磁碟
搜尋屬性儲存區資料庫 + 管理資料庫伺服器	標準	1 個叢集	4 個四核心 2.33 (GHz)	48	2 k (針對寫入調整)	100 GB	16 個 150 GB @ 15K RPM 的磁碟

決定起始架構

本節說明如何選擇起始架構。

當您部署 SharePoint Server 2013 時，您可以從各種拓撲中選擇以實作您的解決方案;您可以部署單一伺服器，或將許多伺服器相應放大至具有叢集或鏡像資料庫伺服器的 SharePoint Server 2013 伺服器數位，以及各種服務的離散應用程式伺服器。稍後，您會根據每個角色的需求，根據您的容量、可用性和備援需求，選取硬體組態。

請先審視不同的參考架構，想想您的伺服器陣列適用的結構，決定是否要將解決方案分割為數個伺服器陣列，或是將數個服務 (例如搜尋) 同盟在單一專用伺服器陣列中。如需詳細資訊，請參閱參考架構。

SharePoint Server 2010 技術案例研究

SharePoint Server 2013 的容量管理指引包含許多現有生產環境的技術案例研究，其中提供現有 SharePoint Server 2013 生產環境的詳細描述。 SharePoint Server 2013 專屬的技術案例研究會在可供使用時發佈;現有的 SharePoint Server 2010 案例研究可作為如何針對特定用途設計 SharePoint Server 2013 環境的參考。

在設計 SharePoint Server 2013 解決方案的架構時，您可以使用這些案例研究作為參考，特別是當您找到這些部署特定關鍵差異的描述，類似於您要建構之解決方案的需求和目標時。

這些文件會針對每個所記載的案例研究，說明下列資訊：

規格，例如硬體、伺服器陣列拓撲和設定;
工作負載，包括使用者群和使用狀況特性；
數據集，包括內容大小、內容特性和內容發佈
健康狀況與效能，包括一組記錄到的指標，描述伺服器陣列的可靠性與效能特性

如需詳細資訊，請從＜Performance and capacity technical case studies (SharePoint Server 2010)＞網頁下載相關文件。

選擇硬體

為伺服器陣列中的電腦選擇適當規格十分重要，這可確保您的部署展現適當的可靠性與效能，請務必謹記您應針對尖峰負載和尖峰時間進行規劃，換句話說，當您的伺服器陣列在平均負載情形下執行時，仍應有足夠的資源可用來處理最大預期需求，同時仍符合延遲和輸送量目標。

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

另一個可考慮採用的是虛擬機器。 SharePoint Server 2013 伺服器陣列可以使用虛擬機部署。雖然找不到虛擬化來新增任何效能優勢，但它確實提供管理性優點。不建議將 SQL Server 型電腦虛擬化，但虛擬化 Web 伺服器和應用程式伺服器層可能會有一些好處。如需詳細資訊，請參閱虛擬化規劃 (/previous-versions/office/sharepoint-server-2010/ff607968 (v=office.14) ) 。

如需硬體需求的詳細資訊，請參閱 SharePoint Server 2016 的硬體和軟體需求。

硬體選擇指導方針

選擇處理器

SharePoint Server 2013 僅適用於 64 位處理器。一般而言，處理器越多，就能服務越大的需求。

在 SharePoint Server 2013 中，當您新增更多核心時，個別網頁伺服器會相應增加。在其他因素不變的情況下，伺服器擁有越多核心，便能承擔越多負載。在大型 SharePoint Server 2013 部署中，建議您配置多個可虛擬化) 的 4 核心網頁伺服器 (，或) 網頁伺服器 (8/16/24 核心的更強 (。

應用程式伺服器的處理器容量需求會根據伺服器的角色及其執行的服務而有所不同。某些 SharePoint Server 2013 功能需要比其他功能更高的處理能力。例如，SharePoint Search Service 的運作便高度依賴應用程式伺服器的處理能力。

SQL Server 的處理器容量需求也取決於 SQL Server 計算機裝載的服務資料庫。

選擇記憶體

伺服器需要的記憶體數量不一，取決於伺服器的功能與角色。例如，執行搜尋編目元件的伺服器因為需將文件讀入記憶體中進行處理，所以如果擁有大量記憶體，將能更快速處理資料。利用 SharePoint Server 2013 許多快取功能的網頁伺服器也可能需要更多記憶體。

一般而言，網頁伺服器記憶體需求大幅取決於伺服器陣列中啟用的應用程式集區數，以及所服務的並行要求數。在大部分的生產 SharePoint Server 2013 部署中，建議您在每部網頁伺服器上至少配置 8 GB RAM，針對流量較大或已設定多個應用程式集區進行隔離的部署，建議您使用 16 GB 的 RAM。

應用程式伺服器的記憶體需求也不同;某些 SharePoint Server 2013 功能在應用層上具有比其他功能更高的記憶體需求。在大部分的生產 SharePoint Server 2013 部署中，建議您在每部應用程式伺服器上至少配置 8 GB RAM;當在同一部伺服器上啟用許多應用程式服務，或啟用高度相依於記憶體的服務，例如 Excel Calculation Service 和 SharePoint Server 2013 搜尋服務時，16 GB、32 GB 和 64 GB 應用程式伺服器很常見。

資料庫伺服器的記憶體需求高度取決於資料庫大小。如需為 SQL Server 型電腦選擇記憶體的詳細資訊，請參閱 (SharePoint Server) 的記憶體和 SQL Server 容量規劃和設定。

選擇網路

除了提供給用戶的權益之外，如果用戶端可以透過網路快速存取數據，分散式伺服器陣列就必須具有伺服器間通訊的快速存取權。當您將服務分散到多部伺服器或是將某些服務與其他伺服器陣列結為同盟時，就更是需要如此。伺服器陣列在 Web 伺服器層、應用程式伺服器層和資料庫伺服器層級之間有大量的流量，而網路在某些情況下很容易成為瓶頸，例如處理大型檔案或高負載。

網頁伺服器和應用程式伺服器應設定為至少使用兩張網路介面卡 (NIC)：一張 NIC 負責處理使用者流量，另一張 NIC 負責處理伺服器間的通訊。伺服器間的網路延遲可能對效能產生重大影響。因此，請務必在 Web 伺服器與裝載內容資料庫的 SQL Server 計算機之間維持不到 1 毫秒的網路等待時間。裝載每個服務應用程式資料庫的 SQL Server 型電腦也應該盡可能接近取用的應用程式伺服器。伺服器陣列伺服器之間的網路應至少有 1 Gbps 頻寬。

選擇磁碟及儲存設備

磁碟管理不只是為您的數據提供足夠空間的功能。您必須評估持續的需求和成長，並確定記憶體架構不會使系統變慢。您應該一律確定每個磁碟上至少有 30% 的額外容量，高於您最高的數據需求估計值，為未來的成長留出空間。此外，在大部分實際執行環境中，磁碟速度 (IOps) 對於提供足夠輸送量來滿足伺服器儲存需求相當重要。您必須預估所部署的主要資料庫將需要的流量數量 (IOps)，並配置足夠磁碟來滿足該流量。

如需如何為資料庫伺服器選擇磁碟的詳細資訊，請參閱記憶體和 SQL Server 容量規劃和設定 (SharePoint Server) 。

網頁伺服器和應用程式伺服器也有儲存需求。在大部分實際執行環境中，建議您至少配置 200 GB 磁碟空間來容納作業系統，並配置 150 GB 磁碟空間來容納記錄檔。

步驟 3：試驗、測試和優化

測試和優化階段是有效容量管理的重要元件。在將新架構部署至實際執行環境前，應先測試新架構，並配合監視最佳做法來進行接受度測試，以便確保您設計的架構達到效能與容量目標。如此可讓您事先找出潛在的瓶頸並進行相關最佳化，以免之後在實際部署中影響到使用者。如果您要從 Office SharePoint Server 2007 環境升級，並打算進行架構變更，或是預估新 SharePoint Server 2013 功能的用戶負載，請務必測試以確定新的 SharePoint Server 2013 環境符合效能和容量目標。

測試過環境之後，您可以分析測試結果，判斷應進行哪些變更，才能達到您在＜步驟 1：模型＞中所建立的效能與容量目標。

以下是進入生產階段前的子步驟：

建立測試環境，並讓其模擬您在＜步驟 2：設計＞中所設計的初始架構。
在儲存區中存入您在＜步驟 1：模型＞中找出的資料集或部份資料集。
對系統施加電腦合成的負載，代表您在＜步驟 1：模型＞中找出的工作負載。
執行測試、分析結果，然後對架構進行最佳化。
將最佳化後的架構部署至資料中心，並讓一小群使用者試驗。
分析試驗結果、找出潛在瓶頸，並最佳化架構。如果需要，請重新測試。
部署至生產環境。

測試

測試是建立系統設計能力以支援工作負載和使用特性的重要因素。如需如何測試 SharePoint Server 2013 部署的詳細資訊，請參閱 SharePoint Server 2013 效能測試。

建立測試計劃
建立測試環境
建立測試和工具

部署試驗環境

在您將 SharePoint Server 2013 部署到生產環境之前，請務必先部署試驗環境，並徹底測試伺服器數位，以確定它可以符合預期尖峰負載的容量和效能目標。我們建議試驗環境第一次測試綜合負載，特別是針對大型部署，然後由一小組即時用戶和實時內容強調。使用一小群實際使用者來分析試驗環境的好處是，如此就有機會在完全部署至實際執行環境前，先驗證所假設的使用狀況特性和內容成長趨勢是否正確。

最佳化

如果您無法藉由調整伺服器數位硬體或變更拓撲來達到容量和效能目標，您可能必須考慮修改您的解決方案。例如，如果您最初的需求是以單一伺服器陣列提供共同作業、搜尋和社交功能，則您可能需將某些服務 (如搜尋) 與專門的服務伺服器陣列結成同盟，或是將工作負載分割給多個伺服器陣列。另一個替代方案是部署一個專門的伺服器陣列來提供社交功能，再部署另一個來提供小組共同作業功能。

步驟 4：部署

執行最後一輪測試並確認架構之後，您已選取可達到您在步驟 1：模型中建立的效能和容量目標，您可以將 SharePoint Server 2013 環境部署到生產環境。

適當的導入策略不一，需視環境和狀況而定。雖然 SharePoint Server 2013 部署通常不在本檔的範圍內，但容量規劃練習可能會提供某些建議的活動。範例如下：

部署新的 SharePoint Server 2013 伺服器陣列： 容量規劃練習應該具有 SharePoint Server 2016 設計和部署的引導式和確認計劃。在此情況下，推出將是 SharePoint Server 2013 的第一個廣泛部署。這需要將容量規劃練習期間使用的伺服器和服務移至生產環境或重建。這是最直接的案例，因為現有伺服器數組不需要任何升級或修改。
將 Office SharePoint Server 2007 伺服器陣列升級至 SharePoint Server 2013： 容量規劃練習應該已驗證伺服器數位的設計，該伺服器陣列可符合現有需求並相應增加，以符合增加的需求和 SharePoint Server 2013 伺服器數位的使用量。容量規劃練習的一部分應該包含測試移轉，以驗證升級程式需要多久時間、是否必須修改或取代任何自定義程式碼、是否必須更新任何第三方工具等等。在容量規劃結束時，您應該有經過驗證的設計，並了解升級所需的時間，以及如何透過升級程式進行最佳運作的計劃，例如就地升級，或將內容資料庫移轉至新的伺服器數位。如果您正在進行就地升級，則在容量規劃期間，您可能會發現需要額外的或升級的硬體，以及停機時間的考慮。規劃練習的一部分輸出應該是所需的硬體變更清單，以及先將硬體變更部署至伺服器陣列的詳細計劃。在容量規劃期間驗證的硬體平臺就緒後，您就可以繼續進行升級至 SharePoint Server 2013 的程式。
改善現有 SharePoint Server 2013 伺服器陣列的效能： 容量規劃練習應該已協助您找出目前實作中的瓶頸、規劃減少或消除這些瓶頸的方法，以及驗證符合您 SharePoint Server 2013 服務商務需求的改良實作。有不同的方式可以解決效能問題，像是跨現有硬體重新配置服務、升級現有硬體，或新增更多硬體，以及新增更多服務。您應該在容量規劃練習期間測試和驗證不同的方法，然後根據該測試的結果來設計部署計劃。