本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

SharePoint Server 2013 的容量規劃

 

適用版本:SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

上次修改主題的時間:2016-12-16

摘要:了解如何規劃及管理 SharePoint Server 2013 的容量與效能。

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

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

重要事項 重要事項:
本文中的某些資訊與值係得自 SharePoint 2010 產品的測試結果及其他相關資訊,不一定就是 SharePoint Server 2013 的最終值。本文會在有 SharePoint Server 2013 的相關資料可用時,更新為適當的值、相關內容與其他資訊的連結,然後重新發佈。

在本文中,我們將說明您應針對自身的環境採取什麼步驟,以開始進行有效的容量管理。每個步驟都需要有某些必要資訊才能成功執行,且都會產生一組交付項目以供用於下個步驟。這些需求與交付項目將在下文針對每個步驟的介紹中以表格列出。

本文內容:

決定 SharePoint Server 2013 環境所用模型的第一步,是分析現有的解決方案,並估計所要進行的部署應要能滿足的需求與目標。首先,請收集關於使用者群、資料需求、延遲與輸送量目標的資訊,並記載所要部署的 SharePoint Server 功能。本節將指出應收集的資料、收集方式,以及這些資料將可如何應用在後續步驟中。

若要調整 SharePoint Server 2013 實作的適當大小,您必須研究並了解您的解決方案應要能滿足的需求特性。若要了解需求,您必須能夠說明工作負載特性 (例如使用者人數以及最常使用的作業) 和資料集特性 (例如內容大小和內容分佈)。

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

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

 

工作負載特性

平均每日 RPS

 

尖峰時間平均 RPS

 

每日單獨使用者總數

 

每日平均並行使用者

 

尖峰時間的尖峰並行使用者

 

每日要求總數

 

預期工作負載分布

每日要求數

%

網頁瀏覽器 - 搜尋編目

   

網頁瀏覽器 - 一般共同作業互動

   

網頁瀏覽器 - 社交互動

   

網頁瀏覽器 - 一般互動

   

網頁瀏覽器 - Office Web 應用程式

   

Office 用戶端

   

OneNote 用戶端

   

SharePoint Workspace

   

Outlook RSS 同步

   

Outlook Social Connector

   

其他互動 (自訂應用程式/Web 服務)

   
  • 並行使用者 – 若要測量伺服器陣列上同時執行的作業數,最常見的方法就是測量在特定時間範圍內有多少名不同的使用者在產生要求。重要量值是每日平均值以及尖峰負載時期的並行使用者數。

  • 每秒要求數 (RPS) – RPS 是個常用來描述伺服器陣列上之需求的指標,所表達的資訊為伺服器陣列每秒處理的要求數,但要求的類型或大小一概不分。每個組織的使用者群都會產生系統負載,而產生的負載大小取決於組織的獨特使用特性。如需此詞彙的詳細資訊,請參閱<SharePoint Server 2013 的容量管理及調整大小概觀>的<詞彙>一節。

  • 每日要求總計 – 每日要求總計是系統必須處理之整體負載的一項良好指標。此指標最常用於測量 24 小時內除驗證信號交換要求 (HTTP 狀態 401) 外的所有其他要求。

  • 每日使用者總計 – 使用者總計是系統必須處理之整體負載的另一項重要指標。其測量的是 24 小時期間內實際的單獨使用者數目,而非組織中的員工總數。

    注意事項 附註:
    每日使用者總計數目可以指出伺服器陣列上的負載增長潛力。例如,如果可能的使用者是 10 萬名員工,則每日 1 萬 5 千名使用者表示隨著使用者的採用情形增加,負載可能日益大幅增長。
  • 工作負載分佈 – 根據與伺服器陣列互動的用戶端應用程式來了解要求分布,有助預測在移轉至 SharePoint Server 2013 後預期會有的趨勢與負載變更。隨著使用者轉換至較新版本的用戶端 (如 Office 2013) 並開始使用新功能,新的負載模式、RPS 和要求總數都應該會增長。我們可以針對每個用戶端,描述在一天期間內有多少名使用該用戶端的不同使用者,以及該用戶端或功能在伺服器上產生的總要求量。

    例如,下圖顯示提供一般社交解決方案的即時內部 Microsoft 環境在某一時刻的數據。在此例中,您可以看到大部份的負載都是因搜尋編目程式和一般的使用者網頁瀏覽行為而來。您也可以看到,Outlook Social Connector 功能 (佔 6.2% 的要求) 造成了顯著的負載。

    一般每日負載分散要求數目
    注意事項 附註:
    此圖中的資料係收集自 SharePoint Server 2010 環境,並會在有最新資料可用時更新。

在估計伺服器陣列必須能夠承擔的必要輸送量時,請先估計伺服器陣列中將使用哪些各種不同交易。請將重點放在分析系統將需要服務的最常用交易,了解其使用頻率,以及使用者人數。這些資料將有助您在稍後進行實際執行前測試時,驗證伺服器陣列是否能承受這類負載。

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

容量 - 工作負載圖表

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

  • 找出使用者互動行為,例如一般的網頁瀏覽、檔案下載與上傳、瀏覽器中的 Office Web 應用程式檢視與編輯、共同撰寫性的互動、SharePoint Workspace 網站同步、Outlook Social 連線、RSS 同步 (在 Outlook 或其他檢視器中)、PowerPoint 廣播、OneNote 共用筆記本、Excel Service 共用活頁簿、存取服務共用應用程式等等。如需詳細資訊,請參閱<SharePoint Server 2013 的容量管理及調整大小概觀>一文的<服務及功能>一節。請將重點放在找出您要設置的部署將需承擔的獨特互動行為,並認出此類負載預期會帶來的影響,例如大量使用 InfoPath 表單、Excel Service 計算及類似的專門解決方案。

  • 找出系統作業,例如搜尋累加編目、每日備份、設定檔同步計時器工作、Web 分析處理、記錄計時器工作等。

  • 估計每項功能預期每日會有的使用者總數,並推算估計的每秒並行使用者數與每秒高階要求數;您將需要進行一些假設,例如目前的並行程度,以及會隨功能而不同的每個並行使用者 RPS 因素,您應使用本節稍早的工作負載表格進行估算。請務必將重點放在尖峰時間,而非平均輸送量。針對尖峰活動進行規劃後,您正確調整 SharePoint Server 2013 解決方案的大小。

如果您已有 Office SharePoint Server 2007 解決方案,可以深入調查 IIS 記錄檔或使用其他現有 Web 監視工具,以更了解一些預期會有的行為,或者可參閱下節中的指示來獲得更多細節。如果您不是從現有的解決方案移轉,則應以約略估計值填寫表格。在稍後的步驟中,您將需要驗證自己的假設並進行系統調整。

若要探索現有 SharePoint Server 2013 部署的重要量值,例如有多少有效使用者、他們使用系統的頻繁程度、系統收到何種要求,以及要求產生自何種用戶端,就必須擷取 ULS 和 IIS 記錄檔中的資料。取得這些資料的一個最簡單方法,是使用「Log Parser」,這是一項可從 Microsoft 免費下載的強大工具。Log Parser 可以讀寫數種文字與二進位格式,包括所有 IIS 格式。

如需關於如何使用 Log Parser 分析 SharePoint Server 2013 使用量的詳細資訊,請閱讀<分析 Microsoft SharePoint 產品和技術使用量>(http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm)。

您可從 http://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en 下載 Log Parser 2.2。

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

 

物件

資料庫大小 (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 解決方案應該要能夠達到「四個九」(99.99%) 的執行時間以及毫秒內的伺服器回應速度。

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

  • 伺服器可用性 – 通常由系統整體執行時間的百分比來表示。您應追蹤任何非預期的停機時間,並將整體可用性與您設定的組織目標進行比較。目標通常由幾個九來表示 (亦即 99%、99.9%、99.99%)

  • 伺服器回應速度 – 伺服器陣列為了服務要求而花費的時間,是追蹤伺服器陣列健康狀況的良好指標。此指標通常稱為伺服器端延遲,且通常使用所服務之每日要求的平均或中位數 (第 50 個百分位數) 延遲。目標一般以低於一秒的等級或秒表示。請注意,如果貴組織的目標為在兩秒內從 SharePoint Server 2013 獻上頁面,則伺服器端的目標必須是低於一秒的等級,好讓頁面有時間透過網路送達用戶端並呈現在瀏覽器中。此外,如果伺服器回應時間比一秒更長,通常表示伺服器陣列狀況不佳,因為這通常會影響到輸送量,而如果大部分要求皆花費超過一秒的時間在伺服器上,RPS 也很難保持水準

  • 伺服器負載暴增 – 另一個值得追蹤的良好伺服器端延遲指標,是所有要求當中排名前 5% 之最慢要求的行為。要求較慢,通常是因為要求正好在系統負載較高時進入系統,或者 (此原因更常見) 使用者正好在與系統互動,導致系統活動較不頻繁。狀況良好的系統,對於反應最慢的要求也能夠妥善控制。此處的目標類似於伺服器回應速度,但為了達到在伺服器負載暴增期間在一秒內回應的目標,您需讓系統搭載大量的備用資源,以便處理暴增的負載。

  • 系統資源使用率 – 其他常用來追蹤系統健康狀況的指標是一組系統計數器,這些計數器會指出伺服器陣列拓撲中每部伺服器的健康狀況。最常用於追蹤的指標是 % CPU 使用率與可用記憶體,但另外還有幾個計數器可協助找出狀況不佳的系統。如需詳細資訊,請參閱<步驟 5:維護>。

您已針對需要提供的解決方案收集好現況資料或估計值,現在可以進入下個步驟,開始設計預料能夠承擔所預期需求的架構。

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

硬體規格和您配置的電腦數緊密相關,為了處理特定負載,您可以選擇部署的解決方案有數種。常見的用法是使用少數幾部強大電腦 (垂直擴充) 或多部小型電腦 (向外擴充);每種解決方案在容量、備援、電力、成本、空間和其他考量方面各有其優缺點。

在此步驟,建議您先從決定架構和拓撲開始。先定義您要如何配置不同的伺服器陣列以及各伺服器陣列中的不同服務,然後為設計中的每部伺服器選擇適當的硬體規格。您也可以先找出您要部署的硬體規格 (許多組織受限於特定的公司標準),然後再定義架構和拓撲。

請使用下表記錄您的設計參數。表中資料為範例資料,只用來示範如何用此表記錄資料,不應用來決定您的伺服器陣列大小。

 

角色 類型 (標準或虛擬) 電腦數 程序 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 伺服器陣列中部署單一伺服器或向外擴充許多伺服器,其中針對各種不同服務使用叢集或鏡像資料庫伺服器以及專門的應用程式伺服器。稍後,您將根據每個角色的需求,還有您的容量、可用性與備援需求,選擇硬體規格。

請先審視不同的參考架構,想想您的伺服器陣列適用的結構,決定是否要將解決方案分割為數個伺服器陣列,或是將數個服務 (例如搜尋) 同盟在單一專用伺服器陣列中。如需詳細資訊,請參閱<SharePoint Server 2013 的容量管理及調整大小概觀>的<參考架構>一節。

SharePoint Server 2013 的容量管理指引包含一些現有實際執行環境的技術案例研究,詳細說明現有的 SharePoint Server 實際執行環境。一有 SharePoint Server 2013 的相關技術案例研究可用,我們就會加以發佈;現有 SharePoint Server 2010 案例研究可做為您在設計特定用途之 SharePoint Server 環境時的參考。

在設計 SharePoint Server 解決方案的架構時,您可將這些案例研究當做參考,尤其是當您發現這些部署的重要特色描述與您正在架構之解決方案的需求與目標類似時。

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

  • 規格,例如硬體、伺服器陣列拓撲和設定;

  • 工作負載,包括使用者群和使用狀況特性;

  • 資料集,包括內容大小、內容特性和內容分布

  • 健康狀況與效能,包括一組記錄到的指標,描述伺服器陣列的可靠性與效能特性

如需詳細資訊,請從效能與容量技術案例研究 (SharePoint Server 2010)頁面下載相關文件。

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

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

另外還需要考慮使用虛擬的機器。可以使用虛擬機器來部署SharePoint Server伺服器陣列。雖然尚未新增任何效能好處找到虛擬化,它提供可管理性優點。虛擬化 SQL Server 型電腦通常不建議使用,但仍有某些優點,虛擬化的網頁伺服器與應用程式伺服器層。如需詳細資訊,請參閱虛擬化規劃 (https://technet.microsoft.com/en-us/library/71c203cd-7534-47b0-9122-657d72ff0080 (office.14).aspx)。

如需硬體需求的詳細資訊,請參閱<SharePoint 2013 的硬體及軟體需求>。

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

在 SharePoint Server 2013 中,可以在個別網頁伺服器中新增核心來將其垂直擴充。在其他因素不變的情況下,伺服器擁有越多核心,便能承擔越多負載。在大型 SharePoint Server 部署中,建議您配置多部 4 核心網頁伺服器 (可以進行虛擬化) 或少數幾部較強大的 (8/16/24 個核心) 網頁伺服器。

應用程式伺服器的處理器容量需求會根據伺服器與執行服務角色有所不同。一些SharePoint Server功能的需求與其他更大的處理能力。例如 SharePoint 搜尋服務為高度取決於應用程式伺服器的處理能力。

SQL Server 的處理器容量需求也取決於 SQL Server 電腦所裝載的服務資料庫。

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

一般而言,網頁伺服器記憶體需求大幅取決於伺服器陣列中啟用的應用程式集區數,以及所服務的並行要求數。在大多數實際執行 SharePoint Server 部署中,建議您在每部網頁伺服器上至少配置 8 GB RAM,至於流量較大的伺服器,或基於隔離目的而設定了多個應用程式集區的部署環境,則建議配置 16 GB。

應用程式伺服器的記憶體需求也各異;有些 SharePoint Server 功能對於應用程式層的記憶體需求比其他功能更大。在大多數實際執行 SharePoint Server 部署中,建議您在每部應用程式伺服器至少配置 8 GB RAM;16 GB、32 GB 和 64 GB 的應用程式伺服器也很常見,通常是因為同一部伺服器上啟用了許多應用程式服務,或是啟用了高度依賴記憶體的服務 (例如 Excel Calculation Service 和 SharePoint Server Search Service)。

資料庫伺服器的記憶體需求高度取決於資料庫大小。如需為 SQL Server 電腦選擇適當記憶體的詳細資訊,請參閱<規劃及設定儲存設備與 SQL Server 容量 (SharePoint Server 2013)>。

分散式伺服器陣列除了可讓網路上的用戶端快速存取到資料來節省使用者時間之外,也必須讓伺服器間的通訊享有快速存取速度。當您將服務分散到多部伺服器或是將某些服務與其他伺服器陣列結為同盟時,就更是需要如此。在伺服器陣列中,網頁伺服器層、應用程式伺服器層和資料庫伺服器層之間會有顯著流量,因此在處理極大型檔案或極高負載等情形下,網路很容易就會變成整個流程當中的瓶頸。

網頁伺服器和應用程式伺服器應設定為至少使用兩張網路介面卡 (NIC):一張 NIC 負責處理使用者流量,另一張 NIC 負責處理伺服器間的通訊。伺服器間的網路延遲可能對效能產生重大影響。因此,請務必將網頁伺服器與裝載內容資料庫之 SQL Server 電腦間的網路延遲控制在 1 毫秒以內。每個服務應用程式資料庫所在的 SQL Server 電腦也應盡量靠近取用端應用程式伺服器。伺服器陣列伺服器之間的網路應至少有 1 Gbps 頻寬。

所謂磁碟管理不只是在想辦法為資料提供足夠的空間。您必須考慮到後續的需求與成長,確定儲存區架構不會拖慢系統速度。請務必確保每個磁碟上至少具備 30% 的額外容量 (高於預估的最高資料需求),以預留空間來因應未來的成長。此外,在大部分實際執行環境中,磁碟速度 (IOps) 對於提供足夠輸送量來滿足伺服器儲存需求相當重要。您必須預估所部署的主要資料庫將需要的流量數量 (IOps),並配置足夠磁碟來滿足該流量。

如需關於如何為資料庫伺服器選擇適當磁碟的詳細資訊,請參閱<規劃及設定儲存設備與 SQL Server 容量 (SharePoint Server 2013)>。

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

測試及最佳化階段是達到有效容量管理的極重要部份。在將新架構部署至實際執行環境前,應先測試新架構,並配合監視最佳做法來進行接受度測試,以便確保您設計的架構達到效能與容量目標。如此可讓您事先找出潛在的瓶頸並進行相關最佳化,以免之後在實際部署中影響到使用者。如果您是從 Office SharePoint Server 2007 環境升級,並且計劃進行架構變更,或者正在評估新 SharePoint Server 功能的使用者負載,則您更需要進行測試,以確保新的 SharePoint Server 環境將會符合效能與容量目標。

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

以下是在實際執行前,應遵循操作的建議子步驟:

  • 建立測試環境,並讓其模擬您在<步驟 2:設計>中所設計的初始架構。

  • 在儲存區中存入您在<步驟 1:模型>中找出的資料集或部份資料集。

  • 對系統施加電腦合成的負載,代表您在<步驟 1:模型>中找出的工作負載。

  • 執行測試、分析結果,然後對架構進行最佳化。

  • 將最佳化後的架構部署至資料中心,並讓一小群使用者試驗。

  • 分析試驗結果、找出潛在瓶頸,然後對架構進行最佳化。必要時再重新測試一遍。

  • 部署至實際執行環境。

測試是確保您的系統設計能夠支援工作負載與使用狀況特性的重要因素。如需關於如何測試 SharePoint Server 2013 部署的詳細資訊,請參閱<SharePoint Server 2013 的效能測試>。

  • 建立測試計劃

  • 建立測試環境

  • 建立測試和工具

在將 SharePoint Server 2013 部署至實際執行環境前,請務必先部署領先適用環境,並徹底測試伺服器陣列,確定其符合您針對預期的尖峰負載設立的效能與容量目標。建議先以電腦合成的負載來測試試驗環境 (大型部署尤其需要此動作),然後再以一小群實際使用者和實際內容進行負載測試。使用一小群實際使用者來分析試驗環境的好處是,如此就有機會在完全部署至實際執行環境前,先驗證所假設的使用狀況特性和內容成長趨勢是否正確。

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

在執行過最終一回的測試並確認所選擇的架構可以達到您在<步驟 1:模型>中所建立的效能與容量目標後,即可將 SharePoint Server 2013 環境部署至實際執行環境。

適當的導入策略不一,需視環境和狀況而定。雖然 SharePoint Server 部署通常不在本文討論範圍,不過在容量計劃演練中,可能會得出一些建議的活動。以下為一些範例:

  • 部署新的 SharePoint Server 伺服器陣列:容量計劃演練應已為 SharePoint Server 2013 的設計與部署計劃提供了方向指引與確認。在此案例中,導入結果將是首次廣泛部署 SharePoint Server 2013。這將需要將容量計劃演練期間所用的伺服器和服務移動或重建到實際執行環境中。這是最簡單直接的案例,因為不需對現有伺服器陣列進行任何升級或修改。

  • 將 Office SharePoint Server 2007 伺服器陣列升級至 SharePoint Server 2013:容量計劃演練應已驗證伺服器陣列的設計可以符合現有需求,並可垂直擴充以符合 SharePoint Server 2013 伺服器陣列日益增加的需求與使用量。容量計劃演練應有一部分是測試性移轉,以驗證升級程序需耗時多久、是否需修改或取代自訂程式碼、是否需更新第三方工具等等。在容量計劃結束後,您應有一套經過驗證的設計、知道升級程序將耗時多久,並有一套關於如何最有效完成升級程序的計劃,例如就地升級,或移轉內容資料庫至新的伺服器陣列。若要進行就地升級,則在容量計劃期間,您可能會發現需要新增硬體或將硬體升級,並需考量停機時間。從計劃演練得到的成果應包括需要進行的硬體變更清單,以及先將硬體變更部署至伺服器陣列的詳細計劃。在容量計劃期間驗證好的硬體平台準備就緒後,您就可以繼續進行升級至 SharePoint Server 2013 的程序。

  • 提升現有 SharePoint Server 2013 伺服器陣列的效能:容量計劃演練應已協助您找出目前實作中的瓶頸,規劃減輕或去除這些瓶頸的方法,並驗證加強後的實作確實符合您對 SharePoint Server 服務的商業需求。效能問題有各種不同的解決方法,最簡單的像是重新配置服務到各現有硬體、升級現有硬體,或是新增額外硬體及新增額外服務至硬體。應在容量計劃演練期間測試和驗證各種不同的方法後,才根據測試結果設計部署計劃。

為了維持系統效能,您必須監視伺服器以找出潛在的瓶頸。若要能夠有效進行監視,您必須先了解哪些重要指標可以指出伺服器陣列某個部份需要注意,並且知道如何解讀指標。如果您發現伺服器陣列的運作不符合自己所定義的目標,可以調整伺服器陣列,例如新增或移除硬體資源、變更拓撲,或是變更資料儲存方式。

請參閱<監視和維護 SharePoint Server 2013>,看看您可以變更哪些設定來監視早期的環境,以便判斷是否需進行任何變更。請記住,提高監視能力會影響使用狀況資料庫所需要的磁碟空間。等到環境穩定後,就不再需要進行此詳細監視,而您就可以將下列設定回復為其預設設定。

如需關於使用 SharePoint Server 管理中心介面內建健康狀況監視工具進行健康狀況監視與疑難排解的詳細資訊,請閱讀下列文章:

在 SharePoint 2013 中監視健康情況

解決問題與疑難排解(https://technet.microsoft.com/en-us/library/ee748639 (office.14).aspx)

https://technet.microsoft.com/zh-tw/library/ff608068.aspx
顯示: