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

在 SharePoint Server 2013 中規劃企業搜尋架構

 

適用版本:SharePoint Server 2013

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

摘要:了解如何規劃小型、中型或大型企業搜尋架構。

在您設定企業搜尋架構之前,有一些項目需要仔細規劃。我們將會逐步協助您規劃小型、中型或大型企業搜尋架構。

您是否熟悉 SharePoint 2013 中的搜尋系統元件,以及它們彼此互動的方式?在繼續之前,請閱讀<SharePoint Server 2013 的搜尋概觀>和<SharePoint Server 2013 的搜尋架構>,熟悉搜尋架構、搜尋元件、搜尋資料庫以及搜尋拓撲。以下是一些規劃搜尋架構時建議考量的事項:

步驟 1:我有多少內容?

步驟 2:有多大的搜尋架構適合多少的內容?

步驟 3:我應該要知道哪些硬體需求?

步驟 4:如何檢查我的搜尋架構是否執行良好?

在搜尋索引中有多少內容會影響裝載伺服器陣列時需要什麼資源。請預估您打算要讓多少項目可供搜尋。以下是一些項目的範例:文件、網頁、SharePoint 清單項目以及影像。請記住,SharePoint 清單中的每個項目各算一個項目。

得出一個數字時,請乘以您預期該內容在未來 12 個月的成長倍數。

例如,如果您一開始有 12,000 個已編到索引中的項目,且預期該內容會在未來 12 個月成長為 3 倍,則您應該規劃 36,000 個可搜尋的項目。

評估要建立多大的搜尋架構有時候並不簡單。搜尋架構的大小取決於內容量、編目率、查詢輸送量以及您需要的高可用性層級。Microsoft 已測試過範例搜尋架構,建議您使用這些範例作為規劃自家伺服器陣列的基礎。您選擇的範例搜尋架構視要讓多少內容可供搜尋而定:

 

內容量 範例搜尋架構

0 至 1 千萬個項目

小型搜尋伺服器陣列

1 千萬至 4 千萬個項目

中型搜尋伺服器陣列

4 千萬至 1 億個項目

大型搜尋伺服器陣列

雖然這些範例搜尋架構使用虛擬機器,但是您可以根據搜尋架構整體的 SharePoint 2013 解決方案策略,使用實體伺服器和虛擬機器。

如果您有不超過 1 千萬個項目,小型搜尋伺服器陣列最適合您。Microsoft 測試了此搜尋架構,測量到它可以每秒編目 50 份文件,並每秒服務 10 個查詢。在每秒 50 份文件的編目率下,首次完整編目需搜尋 55 個小時來編目 1 千萬個項目。

小型企業搜尋架構範例中伺服器和搜尋元件的圖表

如果您有 1 千萬至 4 千萬個項目,中型搜尋伺服器陣列最適合您。Microsoft 測試了此搜尋架構,測量到它可以每秒編目 100 份文件,並每秒服務 10 個查詢。在每秒 100 份文件的編目率下,首次完整編目需搜尋 110 個小時來編目 4 千萬個項目。

中型企業搜尋架構範例中伺服器和搜尋元件的圖表

如果您有 4 千萬至 1 億個項目,大型搜尋伺服器陣列最適合您。Microsoft 測試了此搜尋架構,測量到它可以每秒編目 200 份文件,並每秒服務 10 個查詢。在每秒 200 份文件的編目率下,首次完整編目需搜尋 140 個小時來編目 1 億個項目。

在大型企業搜尋架構範例中伺服器和搜尋元件的圖表

現在,您已經決定內容數量並選擇範例搜尋架構,下一步是規劃您需要的硬體,此將在本節說明:

如果您使用其中一個小型、 中型或大型我們還測試您的架構,然後您將執行您的搜尋架構的虛擬機器上。請注意雖然更輕鬆地管理虛擬環境即其效能層級有時可以比在實體環境的較低。實體伺服器可裝載多個搜尋元件的同一部伺服器的虛擬伺服器比。可在SharePoint 2013 的伺服器陣列虛擬化及架構概觀中找到有用的指引。它也可在實體伺服器上執行您的搜尋架構。 範例伺服器陣列架構、 中只從虛擬機器移動搜尋元件的主機伺服器,並採取離開虛擬機器。每個實體伺服器可主控最多四個索引元件,但僅有一個搜尋元件的每個類型。如果您例如變更使用實體伺服器的中型範例搜尋架構時,您可以找到主機 E.上有兩個內容處理元件解決方案是需要離開其中的內容處理元件。這項措施因為內容處理的資源數量可用、 未內容處理元件數目而定。

選擇以實體或虛擬的方式執行伺服器

每個搜尋元件和搜尋資料庫都需要主機伺服器的最少硬體資源數量,才能執行良好。但是,您擁有的硬體資源越多,搜尋架構的效能就越好。因此,數量最好高於最少硬體資源數量。每個搜尋元件所需的資源取決於工作量,大部分會視編目率、查詢率和索引項目數目而定。

例如,在 Windows Server 2008 R2 Service Pack 1 (SP1) 上裝載虛擬機器時,每部虛擬機器無法使用四個以上的 CPU 核心。使用 Windows Server 2012 或更新版本,您可以每部虛擬機器使用八個以上的 CPU 核心。然後,您可以每部虛擬機器擴充更多 CPU 核心,而非垂直擴充更多虛擬機器。請設定裝載相同搜尋元件的伺服器或虛擬機器,且硬體資源相同。我們將使用索引元件做為範例。在虛擬機器上裝載索引分割區時,效能最弱的虛擬機器會決定整體搜尋架構的效能。

分析報告資料庫所需的最少儲存體會不同。原因是儲存磁碟區取決於使用者如何與 SharePoint 2013 互動。使用者互動頻繁時,通常會儲存更多事件。請檢查目前搜尋架構用於分析資料庫的儲存體數量,並至少針對已重新設計的拓撲指派此數量。

確定每個主機伺服器具有足夠的磁碟空間可以容納 Windows Server 作業系統和 SharePoint 2013 程式檔案的基本安裝。主機伺服器也需要可用的硬碟空間來進行日常作業和頁面檔案的診斷,例如記錄、偵錯及建立記憶體傾印。通常 80 GB 的磁碟空間即已夠 Windows Server 作業系統和 SharePoint 2013 程式檔案使用。

請新增儲存體,供每部資料庫伺服器的 SQL 記錄空間使用。如果您未設定資料庫伺服器經常備份資料庫,則 SQL 記錄空間會使用許多儲存體。如需如何規劃 SQL 資料庫的詳細資訊,請參閱規劃及設定儲存設備與 SQL Server 容量 (SharePoint Server 2013)

此表格顯示每部應用程式伺服器或資料庫伺服器所需的最少硬體資源數量。

 

伺服器 在主機上 儲存 RAM Processor1 網路頻寬

具有查詢處理和索引元件的應用程式伺服器。

A、B

500 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有編目、搜尋管理、分析及內容處理元件的應用程式伺服器。

A、B

200 GB

8 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有所有搜尋資料庫的資料庫伺服器。

C、D

100 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。

此表格顯示每部應用程式伺服器或資料庫伺服器所需的最少硬體資源數量。

 

伺服器 在主機上 儲存 RAM Processor1 網路頻寬

具有查詢處理和索引元件的應用程式伺服器。

A、B、C、D

500 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有索引元件的應用程式伺服器。

A、B、C、D

500 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有分析和內容處理元件的應用程式伺服器。

E、F

300 GB

8 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有編目、搜尋管理及內容處理元件的應用程式伺服器。

E、F

100 GB

8 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有所有搜尋資料庫的資料庫伺服器。

G、H

400 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。

此表格顯示每部應用程式伺服器或資料庫伺服器所需的最少硬體資源數量。

 

伺服器 在主機上 儲存 RAM Processor1 網路頻寬

具有查詢處理和索引元件的應用程式伺服器。

A、B、C、D、E、G、H

500 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有索引元件的應用程式伺服器。

A、B、C、D、E、F、G、H、I、J

500 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有分析和內容處理元件的應用程式伺服器。

K、L、M、N

300 GB

8 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有編目和搜尋管理元件的應用程式伺服器

K、L

100 GB

8 GB

1.8 GHz 4x CPU 核心

1 Gbps

具有搜尋資料庫的資料庫伺服器

O、P、Q、R

500 GB

16 GB

1.8 GHz 4x CPU 核心

1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。

儲存空間的速度會影響搜尋效能。請確定您的儲存空間速度足以處理來自搜尋元件和資料庫的流量。磁碟速度是以每秒 I/O 作業數 (IOPS) 來測量。

您決定將搜尋元件資料與作業系統資料分散在儲存空間中的方式,會影響搜尋效能。您不妨:

  • 跨三個不同的儲存磁碟區或分割區的一般效能分割Windows Server作業系統檔案、 SharePoint 2013程式檔案及診斷記錄檔。

  • 將搜尋元件資料另外儲存在一個高效能的儲存磁碟區或磁碟分割。

    注意事項 附註:
    您可以在主機上安裝SharePoint 2013時設定自訂搜尋元件資料的位置。儲存資料,需要在主機上的任何搜尋元件會將它儲存在此位置。若要變更此位置之後,必須重新SharePoint 2013安裝該主機上。

如需的儲存架構和磁碟類型的概觀,請參閱 < Storage and SQL Server 容量規劃及設定 (SharePoint Server 2013)。主機索引、 分析處理和搜尋管理元件或搜尋資料庫需要可同時提供足夠的每 I/O 操作維持低延遲的存放區的伺服器第二個 (IOPS)。下表顯示多少 IOPS 每個搜尋元件和資料庫需要。

如果您部署共用儲存設備 (例如 SAN/NAS),一個搜尋元件的尖峰磁碟負載通常會跟其他搜尋元件的尖峰磁碟負載同時發生。若要得到搜尋作業需要從共用儲存設備得到的 IOPS 數,您需要將這每個元件的 IOPS 相加。

 

元件名稱 元件詳細資料 IOPS 需求 使用個別儲存磁碟區/磁碟分割

索引元件

合併索引及處理和回應查詢時使用儲存設備。

  • 300 IOPS 用於 64 KB 隨機讀取。

  • 100 IOPS 用於 256 KB 隨機寫入。

  • 200 MB/s 用於循序讀取。

  • 200 MB/s 用於循序寫入。

分析元件

在本機以大量處理方式分析資料。

編目元件

在將下載的內容傳送至內容處理元件之前,先將該內容儲存到本機。儲存空間受限於網路頻寬。

 

資料庫名稱 IOPS 需求 I/O 子系統的一般負載。

編目資料庫

中至高 IOPS

每秒每文件10 IOPS (DPS) 編目率。

連結資料庫

中 IOPS

搜尋索引中每 100 萬個項目 10 IOPS。

搜尋管理資料庫

低 IOPS

不適用。

分析報表資料庫

中 IOPS

不適用。

如果您不熟悉高可用性策略,以下是入門文章:<為 SharePoint 2013 打造高可用性架構和策略>。將備援的搜尋元件與資料庫裝載於不同容錯網域時,搜尋架構就可支援高可用性。所有範例搜尋架構都將備援的搜尋元件裝載於獨立伺服器上。

對於搜尋架構中的每個備援主機伺服器,您應該規劃安裝:

  1. 備援網路

  2. 備援電源供應器,配有獨立電線或不斷電供應系統 (UPS)。

將搜尋架構部署至實際執行環境之前,您必須檢查該搜尋架構是否執行良好。以下是待做事項的檢查清單:

  1. 測試索引元件是否使用具有足夠 IOPS 的儲存 I/O 子系統。請參閱<測試儲存 I/O 子系統>。

  2. 將搜尋架構部署至試驗環境。請確定試驗環境足以代表實際執行環境。

  3. 測試試驗環境的搜尋效能。請參閱<測試搜尋效能

如需在 SharePoint 2013 中進行測試的一般概觀,請參閱<SharePoint Server 2013 的效能測試>。

若要測試儲存 I/O 子系統、 執行的最重要的磁碟作業並測量 IOPS。您可以使用 SQLIO 工具來執行這些測試。請參閱SQLIO 磁碟子系統基準工具

您不需要設定整個搜尋架構,也不需要安裝 SharePoint 2013。只要設定會產生儲存 I/O 子系統真實工作負載的測試環境即可。

請考量本機儲存設備的案例。例如,如果在中型搜尋伺服器陣列中的主機 A 使用本機磁碟,您必須安裝兩個虛擬機器,並且同時在這兩個虛擬機器上執行磁碟作業測試。

對於共用儲存空間您需要不同的設定。例如,如果中型搜尋伺服器陣列中所有索引元件的工作負載,加上其他不相關的工作負載,都共用相同的儲存空間,則您必須:

  1. 將 8 個虛擬機器安裝在主機 A、B、C 及 D 上,並且設定不相關工作負載的來源。

  2. 確定當您在主機 A、B、C 及 D 中的所有虛擬機器上執行同時磁碟作業測試時,不相關的工作負載也會套用至共用儲存空間。

  1. 建立 1 GB 測試檔案,方法是使用 sqlio.exe -t32 -s1 -b256 1g 命令。此命令會建立名為 "1g" 的檔案。

  2. 將測試檔案儲存至您要測試的儲存裝置。例如:在中型伺服器陣列中的主機 A 硬碟上。

  3. 將測試檔案串接至很大的測試檔案。例如:256 GB,使用 copy 1g+1g+1g+...+1g testfile 命令。

  4. 重新啟動伺服器。這樣可以確保快取不會扭曲測試結果。

您不妨測量:

  • 中型隨機存取的效能 (請參閱下文的測試號碼 1 和 2)。

  • 大型傳輸的讀取和寫入輸送量 (請參閱下文的測試號碼 3 和 4)。

下表顯示您應該用來執行每項測試的 SQLIO 命令。所有命令皆假設目前目錄中存在 "testfile"。每項測試皆執行 300 秒。

 

測試號碼 範圍 命令

1

64 KB 讀取 [IOPS]

sqlio.exe -kR -t4 -o25 -b64 -frandom -s300 testfile

2

256 KB 寫入 [IOPS]

sqlio.exe -kW -t4 -o25 -b256 -frandom -s300 testfile

3

100 MB 讀取 [MB/s]

sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile

4

100 MB 寫入 [MB/s]

sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 testfile

下表中的範例結果顯示,在新增測試檔案之前,部署中至少有 50% 的磁碟子系統容量已在使用中。

磁碟控制器和磁碟轉軸對於這些結果有強烈影響。

如果您在空白磁碟上測試,則會得到更好的結果,因為測試檔案將位於跨所有轉軸的最佳軌道上 (Short Stroking)。如此可提升效能最高達兩三倍。如果您測試的硬碟對於未初始化的儲存空間 (或全部都是零的儲存空間,例如動態 VHD/VHDX 檔案) 能夠進行最佳的跳離存取,則您將得到超乎現實的優良結果。在此情況下,請使用包含實際資料的超大型測試檔案,而非使用 SQLIO 命令產生虛構測試檔案。

 

磁碟配置

測試 1

測試 2

測試 3

測試 4

一般作業期間建議的最低 IOPS

300

100

200

200

4x 1 TB 7200 RPM NLSAS,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)

1181

206

284

296

8x 1TB 7200 RPM NLSAS,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)

2082

337

610

645

16x 1TB 7200 RPM NLSAS,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)

3763

595

1173

1181

16x 1TB 7200 RPM NLSAS,採用 RAID50 (2x8),位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)

3613

545

1139

1164

16x 1TB 7200 RPM NLSAS,採用 RAID10,位於 Dell H710 RAID 控制器 (256kB 等量磁碟區大小,64kB 區塊大小)

4030

1146

970

775

4x SmartStorage Optimus 800GB SSD,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)

32385

3781

1714

1319

4x SmartStorage Optimus 800GB SSD,採用 RAID0,位於 Dell H710 RAID 控制器 (256kB 等量磁碟區大小,64kB 區塊大小)

31747

7149

1643

1798

以下是測試搜尋架構時的該做事項檢查清單:

  1. 選擇要用來執行測試的內容

  2. 選擇要用來測試查詢效能的字詞和片語

  3. 測量搜尋效能

請選擇可充分代表您正式運作之內容的內容。如果您選擇的內容只是因為測試目的而存在,請確定您有不同類型的項目,而不是重複多次的同個項目。這麼做的原因在於查詢處理器會花時間偵測重複項目,如此會影響搜尋效能,而導致最終無法充分代表實際執行環境。

請設定一或多個內容來源來編目內容。確認您具有必要的使用者帳戶和網路存取權。

您從查詢得到的結果數稱為重新叫用。

為了測試查詢效能,您必須先建立一組要當成查詢的字詞和片語。請確定其中包含低重新叫用和高重新叫用的字詞和片語,且這些字詞和片語與您的環境相關。

  • 如果您在產品目錄中搜尋產品號碼,通常每個產品只有一個號碼。因此,您很快就會得到搜尋結果。這就是低重新叫用。

  • 如果您在公司內部網路上搜尋某個常用字詞 (像是 "presentation"),您可能會得到許多結果,而且得到結果所花的時間較長。這就是高重新叫用。

  • 例如,如果您的內容跟人力資源有關,請使用這個領域的相關搜尋字詞。

SharePoint 2013 會將效能測量結果收集在「編目狀況報告」和「查詢狀況報告」中。您可以在管理中心的 [搜尋管理] 底下找到這些報告。

您不妨先以虛構負載來測量搜尋效能,再以一小組實際使用者和實際內容的負載來測量搜尋效能。當您使用實際使用者和實際內容時,可以觀察搜尋架構的表現。如果內容增加的速度比預計更快,或許值得考慮改換大一級的搜尋架構。或者,如果使用者使用的分析比預期更多,建議您增加分析資料庫的儲存空間量。

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