在 SharePoint Server 2016 中規劃企業搜尋架構Plan enterprise search architecture in SharePoint Server 2016

摘要:了解如何規劃企業搜尋架構。Summary: Learn how to plan an enterprise search architecture.

設定企業搜尋架構前,有太一些事項需要小心規劃。逐步解說,我們將協助您規劃小型、 中型、 大型或額外的大型企業搜尋架構。Before you set up your enterprise search architecture, there are quite a few things that require careful planning. Step by step, we'll help you to plan a small, a medium, large, or an extra large-size enterprise search architecture.

所熟悉的 SharePoint Server 與互動的方式中的搜尋系統的元件閱讀Overview of SharePoint Server 中的搜尋架構SharePoint Server 2016 的搜尋架構(或SharePoint Server 2013 搜尋架構) 取得升級之前,您將熟悉搜尋架構、 搜尋元件、 搜尋資料庫和搜尋拓撲。規劃搜尋架構時,以下是一些建議有關應考量的事項:Are you familiar with the components of the search system in SharePoint Server, and how they interact? By reading Overview of search architecture in SharePoint Server and Search architectures for SharePoint Server 2016 (or Search architectures for SharePoint Server 2013) before you get going, you'll become familiar with search architecture, search components, search databases, and the search topology. When planning a search architecture, here are some suggestions about what to consider:

  1. 步驟 1:我有多少內容?Step 1: How much content do I have?

  2. 步驟 2: 大小搜尋架構為何多少內容?Step 2: What size search architecture for how much content?

  3. 步驟 3:我應該要知道哪些硬體需求?Step 3: Which hardware requirements should I be aware of?

  4. 步驟 4:如何檢查我的搜尋架構是否執行良好?Step 4: How to check that my search architecture performs well?

步驟 1:我有多少內容?Step 1: How much content do I have?

在搜尋索引中有多少內容會影響裝載伺服器陣列時需要什麼資源。請預估您打算要讓多少項目可供搜尋。以下是一些項目的範例:文件、網頁、SharePoint 清單項目以及影像。請記住,SharePoint 清單中的每個項目各算一個項目。The volume of content that you have in your search index affects what resources you need to host the farm. Work out approximately the number of items that you plan on making searchable. Here are some examples of items: documents, web pages, SharePoint list entries, and images. Remember that each entry in a SharePoint list counts as one item.

得出一個數字時,請乘以您預期該內容在未來 12 個月的成長倍數。When you have established a figure, multiply it by what you think the expected growth of that content will be over the next 12 months.

例如,如果您一開始有 12,000 個已編到索引中的項目,且預期該內容會在未來 12 個月成長為 3 倍,則您應該規劃 36,000 個可搜尋的項目。For example, if you're starting out with 12,000 indexed items, and you expect the volume of that content to triple over the next 12 months. You should plan for 36,000 searchable items.

步驟 2:用多大的搜尋架構容納多少內容?Step 2: What size search architecture for how much content?

它不一定容易評估方式大或小,讓您的搜尋架構。搜尋架構的大小取決於您的內容、 編目率、 的查詢輸出量及您需要的高可用性的層級的量。有我們建議使用做為基礎來規劃您自己的伺服器陣列的範例搜尋架構。您選擇範例搜尋架構取決於有多少內容可供搜尋:It's not always easy to assess how big or small to make your search architecture. The size of your search architecture depends on the volume of your content, the crawl rate, the query throughput, and the level of high availability that you require. There are sample search architectures that we advise using as a basis to plan your own farm. The sample search architecture that you choose depends on how much content has to be searchable:

磁碟區的內容 (SharePoint 2016)Volume of content (SharePoint 2016) 範例搜尋架構Sample search architecture 磁碟區的內容 (SharePoint 2013)Volume of content (SharePoint 2013)
0 至 2,000 萬個項目0-20 million items 小型搜尋伺服器陣列Small search farm 0 至 1,000 萬個項目0-10 million items
0 至 8,000 萬個項目0-80 million items 中型搜尋伺服器陣列Medium search farm 0 至 4,000 萬個項目0-40 million items
0 至 2 億個項目0-200 million items 大型搜尋伺服器陣列Large search farm 0 至 1 億個項目0-100 million items
0 至 5 億個項目0-500 million items 特大型搜尋伺服器陣列Extra large search farm 不支援Not supported

雖然這些範例搜尋架構使用虛擬機器,您可以使用實體伺服器與虛擬機器根據您的搜尋架構整體 SharePoint Server solution 策略。Although these sample search architectures use virtual machines, you can use both physical servers and virtual machines according to the strategy of the overall SharePoint Server solution of your search architecture.

小型搜尋伺服器陣列Small search farm

我們已估計此搜尋架構可編目 50 每秒文件,並以每秒 10 個查詢順序做。如果您在 SharePoint Server 2016 伺服器陣列中有最多 20 個萬個項目,小型搜尋伺服器陣列可能會讓您最合適的伺服器陣列。每秒 50 文件的編目率、 延長搜尋 110 小時中第一次的完整編目的編目 20 萬個項目。We've estimated that this search architecture can crawl 50 documents per second, and serve in the order of 10 queries per second. If you have up to 20 million items in a SharePoint Server 2016 farm, the small search farm will probably be the most suitable farm for you. With a crawl rate of 50 documents per second, it takes search 110 hours to crawl 20 million items in the first full crawl.

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

中型搜尋伺服器陣列Medium search farm

我們已估計此搜尋架構可編目 100 每秒文件,並以每秒 10 個查詢順序做。如果您在 SharePoint Server 2016 伺服器陣列中的 20%和 80 萬個項目之間,中型搜尋伺服器陣列可能會讓您最合適的伺服器陣列。每秒 200 文件的編目率、 延長搜尋 280 小時中第一次的完整編目的編目 80 萬個項目。We've estimated that this search architecture can crawl 100 documents per second, and serve in the order of 10 queries per second. If you have between 20 and 80 million items in a SharePoint Server 2016 farm, the medium search farm will probably be the most suitable farm for you. With a crawl rate of 200 documents per second, it takes search 280 hours to crawl 80 million items in the first full crawl.

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

大型搜尋伺服器陣列Large search farm

我們已估計此搜尋架構可編目 200 每秒文件,並以每秒 10 個查詢順序做。如果您在 SharePoint Server 2016 伺服器陣列中 80 和 200 萬個項目之間,大型搜尋伺服器陣列可能會讓您最合適的伺服器陣列。每秒 200 文件的編目率、 延長搜尋 280 小時中第一次的完整編目的編目 200 萬個項目。We've estimated that this search architecture can crawl 200 documents per second, and serve in the order of 10 queries per second. If you have between 80 and 200 million items in a SharePoint Server 2016 farm, the large search farm will probably be the most suitable farm for you. With a crawl rate of 200 documents per second, it takes search 280 hours to crawl 200 million items in the first full crawl.

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

特大型搜尋伺服器陣列Extra large search farm

Microsoft 測試此搜尋架構與可以編目 300-500 位每秒文件,並以每秒 10 個查詢順序做為單位。SharePoint Server 2016 支援此大小搜尋架構。如果您有最多 500 萬個項目,類似於非常大的搜尋伺服器陣列的伺服器陣列會是很好的起點。每秒的文件 500 編目率、 延長搜尋大約 300 小時中第一次的完整編目的編目 500 萬個項目。Microsoft tested this search architecture and measured that it can crawl 300-500 documents per second, and serve in the order of 10 queries per second. Only SharePoint Server 2016 supports this size search architecture. If you have up to 500 million items, a farm similar to the extra large search farm is a good starting point. With a crawl rate of 500 documents per second, it takes search about 300 hours to crawl 500 million items in the first full crawl.

建立此大小的搜尋伺服器陣列需要謹慎規劃及調整伺服器陣列,以取得您想要的效能。您可能會發現有用 seek 專家指導。它也務必規劃如何備份及還原的這個大小、 搜尋伺服器陣列及如何如果您的資料中心有主要中斷復原伺服器陣列。我們建議您練習備份、 還原及復原。Creating a search farm of this size requires you to carefully plan and tune the farm to get the performance you want. You might find it advantageous to seek expert guidance. It's also important to plan how to back up and restore a search farm of this size, and how to recover the farm if your data center has a major outage. We recommend that you practice backup, restore and recovery.

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

步驟 3:我應該要知道哪些硬體需求?Step 3: Which hardware requirements should I be aware of?

現在,您已經決定內容數量並選擇範例搜尋架構,下一步是規劃您需要的硬體,此將在本節說明:Now that you've determined the volume of your content and chosen a sample search architecture, the next step is to plan the hardware you'll need, as described in this section:

選擇以實體或虛擬的方式執行伺服器Choose to run the servers physically or virtually

如果您使用其中一個我們已評估您的架構,然後您將執行您的搜尋架構的虛擬機器上。請注意且更輕鬆地管理虛擬環境,雖然其效能層級有時可稍微低於之實體的環境。實體伺服器可裝載多個搜尋元件的同一部伺服器與虛擬伺服器。您可在伺服器陣列虛擬化及 SharePoint 2013 的架構概觀找到實用的指導。If you're using one of the architectures that we've estimated for you, then you'll be running your search architecture on virtual machines. Note also that although a virtual environment is easier to manage, its performance level can sometimes be slightly lower than that of a physical environment. A physical server can host more search components on the same server than a virtual server. You'll find useful guidance in Overview of farm virtualization and architectures for SharePoint 2013.

它也可在實體伺服器上執行您的搜尋架構。範例伺服器陣列架構、 中只從虛擬機器移動搜尋元件的主機伺服器,並採取離開虛擬機器。每個實體伺服器可主控最多四個索引元件,但僅有一個搜尋元件的每個類型。如果您例如變更使用實體伺服器的中型範例搜尋架構時,您可以找到主機 E.上有兩個內容處理元件解決方案是需要離開一種內容處理元件。這項措施因為編目、 內容處理及分析處理取決於可用資源,而非數內容處理元件的數量。It's also possible to run your search architecture on physical servers. In the sample farm architectures, just move the search components from the virtual machines to the host server and take away the virtual machines. Each physical server can host up to four index components, but only one of each type of the other search components. If you for example change the medium sample search architecture to use physical servers, you'll find that you have two content processing components on Host E. The solution is to take away one of the content processing components. This works because crawling, processing of content, and processing of analytics depend on the amount of resources that are available, not the number of content processing components.

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

選擇主機伺服器的硬體資源Choose hardware resources for the host servers

每個搜尋元件和搜尋資料庫都需要主機伺服器的最少硬體資源數量,才能執行良好。但是,您擁有的硬體資源越多,搜尋架構的效能就越好。因此,數量最好高於最少硬體資源數量。每個搜尋元件所需的資源取決於工作量,大部分會視編目率、查詢率和索引項目數目而定。Each search component and search database requires a minimum amount of hardware resources from the host server to perform well. But, the more hardware resources you have, the better the performance of your search architecture will be. So it's a good idea to have more than the minimum amount of hardware resources. The resources each search component requires depends on the workload, mostly determined by the crawl rate, the query rate, and the number of indexed items.

例如,在 Windows Server 2008 R2 Service Pack 1 (SP1) 上裝載虛擬機器時,每部虛擬機器無法使用四個以上的 CPU 核心。使用 Windows Server 2012 或更新版本,您可以每部虛擬機器使用八個以上的 CPU 核心。然後,您可以每部虛擬機器擴充更多 CPU 核心,而非垂直擴充更多虛擬機器。請設定裝載相同搜尋元件的伺服器或虛擬機器,且硬體資源相同。我們將使用索引元件做為範例。在虛擬機器上裝載索引分割區時,效能最弱的虛擬機器會決定整體搜尋架構的效能。For example, when hosting virtual machines on Windows Server 2008 R2 Service Pack 1 (SP1), you can't use more than four CPU cores per virtual machine. With Windows Server 2012 or newer, you use eight or more CPU cores per virtual machine. Then you can scale out with more CPU cores for each virtual machine instead of scaling up with more virtual machines. Set up servers or virtual machines that host the same search components, with the same hardware resources. Let's use the index component as an example. When you host index partitions on virtual machines, the virtual machine with the weakest performance determines the performance of the overall search architecture.

一般儲存空間General storage

請確定每個主機伺服器具有足夠的磁碟空間的基本安裝的 Windows Server 作業系統和 SharePoint Server 程式檔。診斷記錄、 偵錯時,例如主機伺服器也需要的可用硬碟空間和建立記憶體傾印,日常作業,以及分頁檔案。一般而言,80 GB 的磁碟空間是足夠的 Windows Server 作業系統和 SharePoint Server 程式檔。Make sure that each host server has enough disk space for the base installation of the Windows Server operating system and for the SharePoint Server program files. The host server also needs free hard disk space for diagnostics such as logging, debugging, and creating memory dumps, for daily operations, and for the page file. Normally, 80 GB of disk space is enough for the Windows Server operating system and for the SharePoint Server program files.

新增 SQL 記錄檔的空間每部資料庫伺服器的儲存空間。如果您不需要設定通常備份資料庫的資料庫伺服器、 SQL 記錄檔空間使用大量的存放區。如需如何規劃 SQL 資料庫的詳細資訊,請參閱Storage and SQL Server capacity planning and configuration (SharePoint Server)。Add storage for the SQL log space for each database server. If you don't set the database server to back up the databases often, the SQL log space uses lots of storage. For more information about how to plan SQL databases, see Storage and SQL Server capacity planning and configuration (SharePoint Server) .

分析報表資料庫需要最低儲存空間可能會有所不同。這是因為的儲存量取決於在使用者與 SharePoint Server 的互動方式。當使用者經常互動時,通常有個以上的事件存放區。檢查您目前的搜尋架構使用分析資料庫儲存空間量並至少指派此經過重新設計拓撲。The minimum storage that the analytics reporting database requires can vary. This is because the amount of storage depends on how users interact with SharePoint Server. When users interact frequently, there usually are more events to store. Check the amount of storage your current search architecture uses for the analytics database, and assign at least this amount for your redesigned topology.

小型搜尋伺服器陣列的最低硬體資源Minimum hardware resources for the small search farm

此表格顯示每部應用程式伺服器或資料庫伺服器所需的最少硬體資源數量。This table shows the minimum amount of hardware resources that each application server or database server needs.

伺服器Server 在主機上On host 儲存Storage RAMRAM 處理器1Processor1 網路頻寬Network bandwidth
具有查詢處理和索引元件的應用程式伺服器。Application server that has query processing and index components. A、BA, B 500 GB2 3500 GB2,3 32 GB2 332 GB2,3 1.8 GHz CPU 核心2,3 x 81.8 GHz 8x CPU cores2,3 1 Gbps1 Gbps
具有編目、搜尋管理、分析及內容處理元件的應用程式伺服器。Application server that has crawl, search administration, analytics and content processing components. A、BA, B 200 GB200 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有所有搜尋資料庫的資料庫伺服器。Database server that has all search databases. C、DC, D 100 GB100 GB 16 GB16 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。1The number of CPU cores is specified here, not the number of CPU threads.

2與 SharePoint Server 2013 所需的資源的最少數量是 500 GB RAM、 16 GB RAM、 以及四個 CPU 核心。2With SharePoint Server 2013 the minimum amount of resources needed are 500 GB RAM, 16 GB RAM, and four CPU cores.

3您也可以使用 SharePoint Server 2016 與 500 GB 儲存空間、 16 GB RAM、 及四核心 CPU、 但然後每個索引元件只可以保留 10 萬個項目及搜尋伺服器陣列僅支援相同的內容量為 SharePoint Server 2013 搜尋伺服器陣列。3With SharePoint Server 2016 you can also use 500 GB storage, 16 GB RAM, and four CPU cores, but then each index component can only hold 10 million items and the search farm only supports the same volume of content as a SharePoint Server 2013 search farm.

中型搜尋伺服器陣列的最低硬體資源Minimum hardware resources for the medium search farm

此表格顯示每部應用程式伺服器或資料庫伺服器所需的最少硬體資源數量。This table shows the minimum amount of hardware resources that each application server or database server needs.

伺服器Server 在主機上On host 儲存Storage RAMRAM 處理器1Processor1 網路頻寬Network bandwidth
具有查詢處理和索引元件的應用程式伺服器。Application server that has query processing and index components. A、B、C、DA, B, C, D 500 GB2 3500 GB2,3 32 GB2 332 GB2,3 1.8 GHz CPU 核心2,3 x 81.8 GHz 8x CPU cores2,3 1 Gbps1 Gbps
具有索引元件的應用程式伺服器。Application server that has an index component. A、B、C、DA, B, C, D 500 GB2 3500 GB2,3 32 GB2 332 GB2,3 1.8 GHz CPU 核心2,3 x 81.8 GHz 8x CPU cores2,3 1 Gbps1 Gbps
具有分析和內容處理元件的應用程式伺服器。Application server that has analytics and content processing components. E、FE, F 300 GB300 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有編目、搜尋管理及內容處理元件的應用程式伺服器。Application server that has crawl, search administration, and content processing components. E、FE, F 100 GB100 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有所有搜尋資料庫的資料庫伺服器。Database server that has all search databases. G、HG, H 400 GB400 GB 16 GB16 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。1The number of CPU cores is specified here, not the number of CPU threads.

2與 SharePoint Server 2013 所需的資源的最少數量是 500 GB RAM、 16 GB RAM、 以及四個 CPU 核心。2With SharePoint Server 2013 the minimum amount of resources needed are 500 GB RAM, 16 GB RAM, and four CPU cores.

3您也可以使用 SharePoint Server 2016 與 500 GB 儲存空間、 16 GB RAM、 及四核心 CPU、 但然後每個索引元件只可以保留 10 萬個項目及搜尋伺服器陣列僅支援相同的內容量為 SharePoint Server 2013 搜尋伺服器陣列。3With SharePoint Server 2016 you can also use 500 GB storage, 16 GB RAM, and four CPU cores, but then each index component can only hold 10 million items and the search farm only supports the same volume of content as a SharePoint Server 2013 search farm.

大型搜尋伺服器陣列的最低硬體資源Minimum hardware resources for the large search farm

此表格顯示每部應用程式伺服器或資料庫伺服器所需的最少硬體資源數量。This table shows the minimum amount of hardware resources that each application server or database server needs.

伺服器Server 在主機上On host 儲存Storage RAMRAM 處理器1Processor1 網路頻寬Network bandwidth
具有查詢處理和索引元件的應用程式伺服器。Application server that has query processing and index components. A、B、C、D、E、G、HA, B, C, D, E, G, H 500 GB2、 3500 GB2, 3 32 GB2、 332 GB2, 3 1.8 GHz 8 x CPU 核心2,31.8 GHz 8x CPU cores2, 3 1 Gbps1 Gbps
具有索引元件的應用程式伺服器。Application server that has an index component. A、B、C、D、E、F、G、H、I、JA, B, C, D, E, F, G, H, I, J 500 GB2、 3500 GB2, 3 32 GB2、 332 GB2, 3 1.8 GHz 8 x CPU 核心2,31.8 GHz 8x CPU cores2, 3 1 Gbps1 Gbps
具有分析和內容處理元件的應用程式伺服器。Application servers that have analytics and content processing components K、L、M、NK, L, M, N 300 GB300 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有編目和搜尋管理元件的應用程式伺服器Application servers that have crawl and search administration components K、LK, L 100 GB100 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有搜尋資料庫的資料庫伺服器Database server that have search databases O、P、Q、RO, P, Q, R 500 GB500 GB 16 GB16 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。1The number of CPU cores is specified here, not the number of CPU threads.

2與 SharePoint Server 2013 所需的資源的最少數量是 500 GB RAM、 16 GB RAM、 以及四個 CPU 核心。2With SharePoint Server 2013 the minimum amount of resources needed are 500 GB RAM, 16 GB RAM, and four CPU cores.

3您也可以使用 SharePoint Server 2016 與 500 GB 儲存空間、 16 GB RAM、 及四核心 CPU、 但然後每個索引元件只可以保留 10 萬個項目及搜尋伺服器陣列僅支援相同的內容量為 SharePoint Server 2013 搜尋伺服器陣列。3With SharePoint Server 2016 you can also use 500 GB storage, 16 GB RAM, and four CPU cores, but then each index component can only hold 10 million items and the search farm only supports the same volume of content as a SharePoint Server 2013 search farm.

特大型搜尋伺服器陣列的最低硬體資源Minimum hardware resources for the extra large search farm

此表說明每個應用程式伺服器或資料庫伺服器所需的硬體資源的最少數量。您只可以建立與 SharePoint Server 2016 此範例伺服器陣列。This table shows the minimum amount of hardware resources that each application server or database server needs. You can only build this sample farm with SharePoint Server 2016.

伺服器Server 在主機上On host 儲存Storage RAMRAM 處理器1Processor1 網路頻寬Network bandwidth
具有索引元件的應用程式伺服器。Application server that has index components. A-XA-X 500 GB500 GB 32 GB32 GB 1.8 GHz 8x CPU 核心1.8 GHz 8x CPU cores 1 Gbps1 Gbps
具有查詢處理和索引元件的應用程式伺服器。Application server that has query processing and index components. Y、ZY, Z 500 GB500 GB 32 GB32 GB 1.8 GHz 8x CPU 核心1.8 GHz 8x CPU cores 1 Gbps1 Gbps
具有編目、搜尋管理或內容處理元件的應用程式伺服器Application servers that have crawl, search administration, or content processing components AA-AFAA-AF 100 GB100 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有分析處理元件的應用程式伺服器Application servers that have analytics processing components AG、AHAG, AH 800 GB800 GB 8 GB8 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps
具有搜尋資料庫的資料庫伺服器Database servers that have search databases AI-ALAI-AL 500 GB500 GB 16 GB16 GB 1.8 GHz 4x CPU 核心1.8 GHz 4x CPU cores 1 Gbps1 Gbps

1CPU 核心數這裡,而非 CPU 執行緒數。1The number of CPU cores is specified here, not the number of CPU threads.

規劃儲存效能Plan storage performance

儲存空間的速度會影響搜尋效能。請確定您的儲存空間速度足以處理來自搜尋元件和資料庫的流量。磁碟速度是以每秒 I/O 作業數 (IOPS) 來測量。The speed of the storage affects the search performance. Make sure that the storage you have is fast enough to handle the traffic from the search components and databases. Disk speed is measured in I/O operations per second (IOPS).

您決定將搜尋元件資料與作業系統資料分散在儲存空間中的方式,會影響搜尋效能。您不妨:The way you decide to distribute data from the search components and from the operating system across your storage, has an impact on search performance. It's a good idea to:

  • Windows Server 作業系統檔案、 SharePoint Server 程式檔案和診斷記錄分割三個不同的儲存磁碟區或分割區的一般效能。Split the Windows Server operating system files, the SharePoint Server program files, and diagnostics logs across three separate storage volumes or partitions with normal performance.

  • 將搜尋元件資料另外儲存在一個高效能的儲存磁碟區或磁碟分割。Store the search component data on a separate storage volume or partition with high performance.

    注意

    您可以在主機上安裝 SharePoint Server 時設定自訂搜尋元件資料的位置。儲存資料,需要在主機上的任何搜尋元件會將它儲存在此位置。若要變更此位置之後,必須在該主機上重新安裝 SharePoint Server。You can set a custom location for search component data when you install SharePoint Server on a host. Any search component on the host that needs to store data, stores it in this location. To change this location later, you have to reinstall SharePoint Server on that host.

選擇儲存設備Choose storage

如需儲存架構和磁碟類型的概觀,請參閱Storage and SQL Server 容量規劃及設定 (SharePoint Server)。主控的索引或分析處理元件或搜尋資料庫的伺服器需要可維持低延遲的儲存空間同時提供足夠的 I/O 操作每秒 (IOPS)。下表顯示多少 IOPS 每個搜尋元件和資料庫需要。For an overview of storage architectures and disk types, see Storage and SQL Server capacity planning and configuration (SharePoint Server). The servers that host the index or analytics processing components, or search databases, require storage that can maintain low latency, while providing sufficient I/O operations per second (IOPS). The following tables show how many IOPS each of these search components and databases require.

如果您部署共用儲存設備 (例如 SAN/NAS),一個搜尋元件的尖峰磁碟負載通常會跟其他搜尋元件的尖峰磁碟負載同時發生。若要得到搜尋作業需要從共用儲存設備得到的 IOPS 數,您需要將這每個元件的 IOPS 相加。If you deploy shared storage like SAN/NAS, the peak disk load of one search component typically coincides with the peak disk load of another search component. To get the number of IOPS search requires from the shared storage, you need to add up the IOPS requirement of each of these components.

搜尋元件 IOPS 需求Search component IOPS requirements

元件名稱Component name 元件詳細資料Component details IOPS 需求IOPS requirements 使用個別儲存磁碟區/磁碟分割Use of separate storage volume/partition
索引元件Index component 合併索引及處理和回應查詢時使用儲存設備。Uses storage when merging the index and when handling and responding to queries. 300 IOPS 用於 64 KB 隨機讀取。300 IOPS for 64 KB random reads.
100 IOPS 用於 256 KB 隨機寫入。100 IOPS for 256 KB random writes.
200 MB/s 用於循序讀取。200 MB/s for sequential reads.
200 MB/s 用於循序寫入。200 MB/s for sequential writes.
Yes
分析元件Analytics component 在本機以大量處理方式分析資料。Analyzes data locally, in bulk processing. No Yes
編目元件Crawl component 在將下載的內容傳送至內容處理元件之前,先將該內容儲存到本機。儲存空間受限於網路頻寬。Stores downloaded content locally, before it sends it to a content processing component. Storage is limited by network bandwidth. No Yes

搜尋資料庫 IOPS 需求Search database IOPS requirements

資料庫名稱Database name IOPS 需求IOPS requirements I/O 子系統的一般負載。Typical load on I/O subsystem.
編目資料庫Crawl database 中至高 IOPSMedium to high IOPS 每秒每文件10 IOPS (DPS) 編目率。10 IOPS per 1 document per second (DPS) crawl rate.
連結資料庫Link database 中 IOPSMedium IOPS 搜尋索引中每 100 萬個項目 10 IOPS。10 IOPS per 1 million items in the search index.
搜尋管理資料庫Search administration database 低 IOPSLow IOPS 不適用。Not applicable.
分析報表資料庫Analytics reporting database 中 IOPSMedium IOPS 不適用。Not applicable.

選擇您的搜尋架構如何支援高可用性Choose how your search architecture supports high availability

如果您不熟悉高可用性策略時,以下是可讓您從著手文章:為 SharePoint Server 打造高可用性架構和策略。您的搜尋架構支援高可用性時您架設備援搜尋元件和個別的容錯網域上的資料庫。範例搜尋架構的所有主控在獨立伺服器上的備援搜尋元件。If you aren't familiar with high availability strategies, here's an article that will get you started: Create a high availability architecture and strategy for SharePoint Server. Your search architecture supports high availability when you host redundant search components and databases on separate fault domains. All of the sample search architectures host redundant search components on independent servers.

對於搜尋架構中的每個備援主機伺服器,您應該規劃安裝:For each redundant host server in your search architecture, you should plan to install:

  1. 備援網路Redundant networking

  2. 備援電源供應器,配有獨立電線或不斷電供應系統 (UPS)。Redundant power supplies with independent wiring or an uninterruptable power supply (UPS).

步驟 4:如何檢查我的搜尋架構是否執行良好?Step 4: How to check that my search architecture performs well?

將搜尋架構部署至實際執行環境之前,您必須檢查該搜尋架構是否執行良好。以下是待做事項的檢查清單:Before you deploy your search architecture to a production environment, you'll need to check that it performs well. Here's a checklist of what to do:

  1. 測試索引元件是否使用具有足夠 IOPS 的儲存 I/O 子系統。請參閱<測試儲存 I/O 子系統>。Test that the index components use a storage I/O subsystem that has enough IOPS. See Test the storage I/O subsystem.

  2. 將搜尋架構部署至試驗環境。請確定試驗環境足以代表實際執行環境。Deploy the search architecture to a pilot environment. Make sure that the pilot environment is representative of the production environment.

  3. 測試試驗環境的搜尋效能。請參閱<測試搜尋效能Test the search performance of the pilot environment. See Test the search performance

如 SharePoint 中進行測試的一般概觀,請參閱Performance testing for SharePoint Server 2013For an overview of testing in general in SharePoint , see Performance testing for SharePoint Server 2013.

測試儲存 I/O 子系統Test the storage I/O subsystem

若要測試儲存 I/O 子系統,請執行最重要的磁碟作業並測量 IOPS。您可以使用 SQLIO 工具來執行這些測試。請參閱<SQLIO 磁碟子系統性能測試工具>。To test the storage I/O subsystem, run the most important disk operations and measure the IOPS. You can use the SQLIO tool to run these tests. See SQLIO Disk Subsystem Benchmark Tool.

設定測試環境Set up the test environment

您不需要設定的整個搜尋架構,或安裝 SharePoint Server。它是足夠的設定會產生儲存 I/O 子系統的真實感化工作負載的測試環境。You don't need to set up the whole search architecture, or install SharePoint Server. It's enough to set up a test environment that produces a realistic workload for the storage I/O subsystem.

請考量本機儲存設備的案例。例如,如果在中型搜尋伺服器陣列中的主機 A 使用本機磁碟,您必須安裝兩個虛擬機器,並且同時在這兩個虛擬機器上執行磁碟作業測試。Let's consider the case for local storage. For example, if host A in the medium search farm uses a local disk, you need to install the two virtual machines and run the disk operation tests on both virtual machines at the same time.

對於共用儲存空間您需要不同的設定。例如,如果中型搜尋伺服器陣列中所有索引元件的工作負載,加上其他不相關的工作負載,都共用相同的儲存空間,則您必須:You need a different set-up for shared storage. If for example the workload from all the index components in the medium search farm plus other unrelated workloads share the same storage, you need to:

  1. 將 8 個虛擬機器安裝在主機 A、B、C 及 D 上,並且設定不相關工作負載的來源。Install the eight virtual machines in host A, B, C, and D, and set up the sources of the unrelated workloads.

  2. 確定當您在主機 A、B、C 及 D 中的所有虛擬機器上執行同時磁碟作業測試時,不相關的工作負載也會套用至共用儲存空間。Make sure that the unrelated workload is applied to the shared storage at the same time as you run simultaneous disk operation tests on all the virtual machines in host A, B, D, and D.

建立測試檔案Create a test file

  1. 建立 1 GB 測試檔案,方法是使用 sqlio.exe -t32 -s1 -b256 1g 命令。此命令會建立名為 "1g" 的檔案。Create a 1 GB test file by using the command sqlio.exe -t32 -s1 -b256 1g. This command creates a file named "1g".

  2. 將測試檔案儲存至您要測試的儲存裝置。例如:在中型伺服器陣列中的主機 A 硬碟上。Save the test file on the storage device that you want to test. For example: on the hard disk of Host A in the medium farm.

  3. 將測試檔案串接至很大的測試檔案。例如:256 GB,使用 copy 1g+1g+1g+…+1g testfile 命令。Concatenate the test file to a sufficiently large test file. For example: 256 GB, with the command copy 1g+1g+1g+…+1g testfile.

  4. 重新啟動伺服器。這樣可以確保快取不會扭曲測試結果。Restart the server. This will ensure that caching does not skew the test results.

執行測試Run tests

您不妨測量:It's a good idea to measure:

  • 中型隨機存取的效能 (請參閱下文的測試號碼 1 和 2)。The performance of medium sized random accesses (see test number one and two below).

  • 大型傳輸的讀取和寫入輸送量 (請參閱下文的測試號碼 3 和 4)。Read and write throughput for large transfers (see test number three and four below).

下表顯示您應該用來執行每項測試的 SQLIO 命令。所有命令皆假設目前目錄中存在 "testfile"。每項測試皆執行 300 秒。The table below shows the SQLIO commands that you should use to run each test. All the commands assume that the "testfile" exists in the current directory. Each test runs for 300 seconds.

測試號碼Test number 範圍Scope 命令Command
11 64 KB 讀取 [IOPS]64 KB read [IOPS] sqlio.exe -kR -t4 -o25 -b64 -frandom -s300 testfile
22 256 KB 寫入 [IOPS]256 KB write [IOPS] sqlio.exe -kW -t4 -o25 -b256 -frandom -s300 testfile
33 100 MB 讀取 [MB/s]100 MB read [MB/s] sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile
44 100 MB 寫入 [MB/s]100 MB write [MB/s] sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 testfile

本機磁碟儲存的範例結果Example results for local disk storage

下表中的範例結果顯示,在新增測試檔案之前,部署中至少有 50% 的磁碟子系統容量已在使用中。The sample results in the table below show a deployment where at least 50 percent of the disk subsystem capacity was in use before adding the test file.

磁碟控制器和磁碟轉軸對於這些結果有強烈影響。The disk controller and the spindles of the disk strongly influence these results.

如果您在空白磁碟上測試,則會得到更好的結果,因為測試檔案將位於跨所有轉軸的最佳軌道上 (Short Stroking)。如此可提升效能最高達兩三倍。如果您測試的硬碟對於未初始化的儲存空間 (或全部都是零的儲存空間,例如動態 VHD/VHDX 檔案) 能夠進行最佳的跳離存取,則您將得到超乎現實的優良結果。在此情況下,請使用包含實際資料的超大型測試檔案,而非使用 SQLIO 命令產生虛構測試檔案。If you test on empty disks, you'll get elevated results because the test file will be in the most optimal tracks across all spindles (short stroking). This can increase performance by up to two or three times. You'll get unrealistically high results if you test a hard disk that optimizes away accesses on uninitialized storage space, or storage containing all zeros, for example dynamic VHD/VHDX files. In this case, use a very large test file that contains real data, rather than generating a synthetic test file using SQLIO commands.

磁碟配置Disk layout 測試 1Test 1 測試 2Test 2 測試 3Test 3 測試 4Test 4
一般作業期間建議的最低 IOPSRecommended minimum IOPS during ordinary operations 300300 100100 200 個200 200 個200
4x 1 TB 7200 RPM NLSAS,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)4x 1 TB 7200 RPM NLSAS in RAID5 on Dell H710 RAID controller (64kB stripe size, 64kB block size) 11811181 206206 284284 296296
8x 1TB 7200 RPM NLSAS,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)8x 1TB 7200 RPM NLSAS in RAID5 on Dell H710 RAID controller (64kB stripe size, 64kB block size) 20822082 337337 610610 645645
16x 1TB 7200 RPM NLSAS,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)16x 1TB 7200 RPM NLSAS in RAID5 on Dell H710 RAID controller (64kB stripe size, 64kB block size) 37633763 595595 11731173 11811181
16x 1TB 7200 RPM NLSAS,採用 RAID50 (2x8),位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)16x 1TB 7200 RPM NLSAS in RAID50 (2x8) on Dell H710 RAID controller (64kB stripe size, 64kB block size) 36133613 545545 11391139 11641164
16x 1TB 7200 RPM NLSAS,採用 RAID10,位於 Dell H710 RAID 控制器 (256kB 等量磁碟區大小,64kB 區塊大小)16x 1TB 7200 RPM NLSAS in RAID10 on Dell H710 RAID controller (256kB stripe size, 64kB block size) 40304030 11461146 970970 775775
4x SmartStorage Optimus 800GB SSD,採用 RAID5,位於 Dell H710 RAID 控制器 (64kB 等量磁碟區大小,64kB 區塊大小)4x SmartStorage Optimus 800GB SSDs in RAID5 on Dell H710 RAID controller (64kB stripe size, 64kB block size) 3238532385 37813781 17141714 13191319
4x SmartStorage Optimus 800GB SSD,採用 RAID0,位於 Dell H710 RAID 控制器 (256kB 等量磁碟區大小,64kB 區塊大小)4x SmartStorage Optimus 800GB SSDs in RAID0 on Dell H710 RAID controller (256kB stripe size, 64kB block size) 3174731747 71497149 16431643 17981798

測試搜尋效能Test the search performance

以下是測試搜尋架構時的該做事項檢查清單:Here's a checklist of what to do to test your search architecture:

  1. 選擇要用來執行測試的內容Choose content to run tests on

  2. 選擇要用來測試查詢效能的字詞和片語Choose terms and phrases to test query performance

  3. 測量搜尋效能Measure search performance

選擇要用來執行測試的內容Choose content to run tests on

請選擇可充分代表您正式運作之內容的內容。如果您選擇的內容只是因為測試目的而存在,請確定您有不同類型的項目,而不是重複多次的同個項目。這麼做的原因在於查詢處理器會花時間偵測重複項目,如此會影響搜尋效能,而導致最終無法充分代表實際執行環境。Choose content that represents your production content well. If you choose content that's only there for test purposes, make sure you've got different types of items, not just one item that you've duplicated many times. The reason for this is that the query processor will spend time detecting duplicated items, which will affect search performance, and your results won't be representative of a production environment.

請設定一或多個內容來源來編目內容。確認您具有必要的使用者帳戶和網路存取權。Set up one or more content sources to crawl the content. Verify that you have the required user account and network access.

選擇要用來測試查詢效能的字詞和片語Choose terms and phrases to test query performance

您從查詢得到的結果數稱為重新叫用。The number of results you get for a query is called the recall.

若要測試查詢效能,您需要建立一組來作為查詢字詞和片語。或者,收集查詢從現有的安裝。請確定組中包含的字詞和片語中具有低重新叫用與高的重新叫用,並確認已與環境相關的字詞和片語。To test query performance, you'll first need to create a set of terms and phrases to use as queries. Alternatively, collect queries from an existing installation. Make sure that the set contains terms and phrases that have low recall and high recall, and that the terms and phrases are relevant to your environment.

範例Examples

  • 如果您在產品目錄中搜尋產品號碼,通常每個產品只有一個號碼。因此,您很快就會得到搜尋結果。這就是低重新叫用。If you search for a product number in a product catalog, it's likely that there's only one number for one product. Therefore, you'll get your search results fast. This is low recall.

  • 如果您在公司內部網路上搜尋某個常用字詞 (像是 "presentation"),您可能會得到許多結果,而且得到結果所花的時間較長。這就是高重新叫用。If you search for a common term like "presentation" on a company intranet, it's likely that you'll get many results, and it may take longer to get them. This is high recall.

  • 例如,如果您的內容跟人力資源有關,請使用這個領域的相關搜尋字詞。If, for example, your content is related to human resources, use search terms that relate to this area.

測量搜尋效能Measure search performance

SharePoint Server 收集搜尋效能測量編目狀況報告及查詢狀況報告。您可以在管理中心的 [搜尋管理下找到這些報告。SharePoint Server collects search performance measurements in the Crawl Health Reports and Query Health Reports. You can find these reports in Central Administration, under Search Administration.

您不妨先以虛構負載來測量搜尋效能,再以一小組實際使用者和實際內容的負載來測量搜尋效能。當您使用實際使用者和實際內容時,可以觀察搜尋架構的表現。如果內容增加的速度比預計更快,或許值得考慮改換大一級的搜尋架構。或者,如果使用者的用量比預期更多,建議您增加分析資料庫的儲存空間量。It's a good idea to measure search performance first with a synthetic load, and then with a small set of live users, and live content. When you use live users and live content, you can observe how the search architecture is performing. If your content increases faster than you intended, it might be worth considering using the next size search architecture. Or, if your users are more active than anticipated, then we suggest that you increase the amount of storage space of the analytics database.