Изменение топологии поиска в корпоративной среде для большего объема контента и числа пользователей в SharePoint 2016

 

**Применимо к:**SharePoint Server 2016

**Последнее изменение раздела:**2017-09-08

Сводка. Узнайте, как изменить топологию архитектуры корпоративного поиска для поддержки роста объема контента, увеличения числа пользователей или и того, и другого.

Со временем большинство размер сред поиска увеличивается, как с точки зрения объема контента, так и числа пользователей. В некоторый момент емкости и производительности вашей архитектуры поиска становится недостаточно для среда поиска. Чтобы справиться с этим, необходимо масштабировать топологию архитектуры поиска.

1. Изменение топологии (эта статья)

2. Реализация измененной топологии (Управление топологией поиска в SharePoint Server)

Знаете ли вы о компонентах системы поиска в SharePoint Server и их взаимодействии? Чтобы ознакомиться с архитектурой, компонентами, базами данных и топологией поиска, прочитайте статьи Обзор архитектуры поиска в SharePoint Server и Архитектуры поиска для SharePoint Server 2016 (или Архитектуры поиска для SharePoint Server 2013).

В этой статье мы пошагово опишем, как переработать топологию поиска.

• Действие 1. Определение объема имеющегося контента.

• Действие 2. Определение целевого размера архитектуры поиска

• Действие 3. Требования к оборудованию, которые необходимо учитывать.

После выполнения этих действий вы узнаете:

• сколько типов компонентов поиска и баз данных поиска требуется для вашей топологии;

• на каких серверах приложений и баз данных следует развернуть каждый компонент поиска;

• какие аппаратные ресурсы необходимы каждому серверу приложений и баз данных.

Действие 1. Определение объема имеющегося контента.

Объем контента в индексе поиска влияет на то, какие ресурсы необходимо размещать в ферме. Определите, сколько элементов доступно для поиска в существующей среде поиска. Это число можно найти на странице Администрирование поиска в Веб-сайт центра администрирования SharePoint. Чтобы открыть страницу администрирования поиска, щелкните Управление приложениями-службами в Центр администрирования и выберите имя приложения-службы поиска.

Приблизительно определите, насколько число доступных для поиска элементов увеличится в ближайшие 12 месяцев и спроектируйте топологию поиска на основе этого показателя. Например, если у вас 8 000 000 индексируемых элементов и вы ожидаете, что объем контента увеличится на 50 % в ближайшие 12 месяцев, следует спроектировать топологию для 12 000 000 элементов, доступных для поиска.

Действие 2. Определение целевого размера архитектуры поиска

Не всегда легко оценить, насколько большой или малой должна быть архитектура. Размер архитектуры поиска зависит от объема контента, скорости обхода контента, пропускной способности запросов и требуемого уровня высокой доступности. Существуют примеры архитектур поиска, протестированные корпорацией Майкрософт, которые мы рекомендуем использовать в качестве основы для вашей фермы. Сравните текущую архитектуру поиска с примерами архитектур поиска и определите, какой из них больше всего похож на вашу текущую архитектуру. Затем выберите пример архитектуры, до которой вы будете выполнять масштабирование. Выбор примера архитектуры поиска зависит от того, какой объем контента должен поддерживать поиск.

Объем контента (SharePoint 2016)	Пример архитектуры поиска	Объем контента (SharePoint 2013)
0–20 млн элементов	Малая ферма поиска	0–10 млн элементов
0–80 млн элементов	Средняя ферма поиска	0–40 млн элементов
0–200 млн элементов	Большая ферма поиска	0–100 млн элементов
0–500 млн элементов	Очень большая ферма поиска	Не поддерживается

Несмотря на то что в этих примерах архитектуры поиска используются виртуальные машины, вы можете использовать как физические серверы, так и виртуальные машины согласно стратегии общего решения SharePoint Server архитектуры поиска.

Малая ферма поиска

Мы определили, что эта архитектура поиска может выполнять обход контента со скоростью 10 документов в секунду и обрабатывать порядка 20 запросов в секунду. Если у вас до 50 млн элементов в ферме SharePoint Server 2016, вероятно, наиболее подходящий вариант для вас — малая ферма поиска. При скорости 50 документов в секунду первый полный обход 20 миллионов элементов занимает 110 часов.

Средняя ферма поиска

Мы определили, что эта архитектура поиска может выполнять обход контента со скоростью 20 документов в секунду и обрабатывать порядка 80 запросов в секунду. Если у вас от 100 до 10 млн элементов в ферме SharePoint Server 2016, вероятно, наиболее подходящий вариант для вас — средняя ферма поиска. При скорости 200 документов в секунду первый полный обход 80 миллионов элементов занимает 280 часов.

Большая ферма поиска

Мы определили, что эта архитектура поиска может выполнять обход контента со скоростью 200 документов в секунду и обрабатывать порядка 10 запросов в секунду. Если у вас от 80 до 200 млн элементов в ферме SharePoint Server 2016, вероятно, наиболее подходящий вариант для вас — большая ферма поиска. При скорости 200 документов в секунду первый полный обход 200 миллионов элементов занимает 280 часов.

Очень большая ферма поиска

Корпорация Майкрософт протестировала эту архитектуру поиска и определила, что она позволяет выполнять обход контента со скоростью 300–500 документов в секунду и обрабатывать порядка 10 запросов в секунду. Архитектуру фермы поиска такого размера поддерживает только SharePoint Server 2016. Если у вас до 500 миллионов элементов, советуем взять за основу очень большую ферму поиска. При скорости 500 документов в секунду первый полный обход 500 миллионов элементов занимает примерно 300 часов.

Чтобы ферма поиска такого размера работала как следует, ее необходимо тщательно спланировать и настроить. Рекомендуем обратиться за помощью к специалисту. Кроме того, важно спланировать резервное копирование и восстановление фермы поиска такого размера в случае серьезного сбоя в центре обработки данных. Рекомендуем выполнять учебное резервное копирование и восстановление.

Действие 3. Требования к оборудованию, которые необходимо учитывать.

Теперь, когда вы определили объем контента и выбрали новую топологию, необходимо спланировать необходимое оборудование, как описано в этом разделе.

• Выбор между физическими и виртуальными серверами

• Выбор аппаратных ресурсов для серверов узлов

  • Общее хранилище

  • Минимальные аппаратные ресурсы, необходимые для малой фермы поиска

  • Минимальные аппаратные ресурсы, необходимые для средней фермы поиска

  • Минимальные аппаратные ресурсы, необходимые для большой фермы поиска

• Планирование производительности хранилища

  • Выбор типа хранилища

  • Требования к количеству операций ввода-вывода в секунду для компонента поиска

  • Требования к количеству операций ввода-вывода в секунду для базы данных поиска

• Выбор способа поддержки высокой доступности архитектурой поиска

Выбор между физическими и виртуальными серверами

Когда вы изначально планировали архитектуру поиска, вы решили использовать физические серверы, виртуальные машины или их комбинацию. Подумайте, по-прежнему ли верно это решение. Например, если вы переходите со средней архитектуры поиска на крупную архитектуру, управлять растущим числом серверов будет проще при использовании виртуальных машин. Обратите внимание, что хотя виртуальной средой и проще управлять, уровень ее производительности иногда может быть меньше, чем у физической среды. На физическом сервере могут размещаться больше компонентов поиска, чем на виртуальном. Полезные сведения см. в статье Обзор виртуализации и архитектур фермы для SharePoint 2013.

Примеры архитектур малых, средних, больших и очень больших ферм поиска работают на виртуальных машинах, но они также могут работать и на физических серверах. В примерах архитектур фермы просто переместите компоненты поиска с виртуальных машин на сервер узла и удалите виртуальные машины. На каждом физическом сервере может размещаться до четырех компонентов индекса, но только один компонент поиска другого типа. Если вы, например, измените архитектуру средней фермы поиска для применения физических серверов, на узле E будут размещены два компонента обработки контента. Вам необходимо убрать один из них. Это сработает, так как обработка и обход контента, а также обработка данных аналитики зависят от объема доступных ресурсов, а не числа компонентов обработки контента.

Выбор аппаратных ресурсов для серверов узлов

Каждому компоненту и каждой базе данных поиска требуется минимальный объем аппаратных ресурсов хост-сервера для нормальной работы. Но чем больше аппаратных ресурсов у вас есть, тем выше будет производительность вашей архитектуры поиска. Поэтому рекомендуется использовать объем ресурсов больше минимального. Необходимые каждому компоненту поиска ресурсы зависят от рабочей нагрузки, которая в основном определяется скоростью обхода, скоростью запросов и числом индексируемых элементов.

Например, при размещении виртуальных машин в Windows Server 2008 R2 с пакетом обновления 1 (SP1) можно использовать больше четырех ядер ЦП на каждую виртуальную машину. При использовании Windows Server 2012 и более новых версий, на виртуальную машину можно применять восемь и более ядер ЦП. Затем можно реализовать горизонтальное масштабирование, добавив число ядер для каждой виртуальной машины, вместо вертикального масштабирования (увеличения числа виртуальных машин). Настраивайте серверы или виртуальные машины, на которых размещаются одинаковые компоненты поиска, с одинаковыми аппаратными ресурсами. Используем в качестве примера компонент индекса. Если разделы индекса размещаются на виртуальных машинах, производительностью всей архитектуры поиска определяется производительностью самой медленной виртуальной машины.

Общие ресурсы хранилища

Убедитесь, что в каждом сервере узла имеется достаточный объем дискового пространства для базовой установки операционной системы Windows Server и для программных файлов SharePoint Server. Серверу узла также требуется свободное дисковое пространство для диагностических целей, например для ведения журнала, отладки и создания дампов памяти по выполняемым ежедневно операциям, а также для файла подкачки. Обычно для операционной системы Windows Server и программных файлов SharePoint Server достаточно 80 ГБ дискового пространства.

Увеличьте объем хранилища для пространства журналов SQL каждого сервера базы данных. Если на сервере баз данных не настроено частое резервное копирование баз данных, пространство журналов SQL занимает много места. Дополнительные сведения о планировании баз данных SQL см. в статье Настройка и планирование загрузки SQL Server и хранилища (SharePoint Server).

Минимальный объем, необходимый базе данных отчетов аналитики, может быть различным. Это связано с тем, что объем хранилища зависит от того, как пользователи взаимодействуют с SharePoint Server. Если взаимодействие происходит часто, обычно требуется хранить больше событий. Узнайте, какой объем хранилища текущая архитектура поиска использует для базы данных аналитики, и назначьте по крайней мере этот объем переработанной топологии.

Минимальные аппаратные ресурсы, необходимые для малой фермы поиска

В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами обработки запросов и индексирования.	A, B	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений с компонентами обхода контента, администрирования поиска, аналитики и обработки контента.	A, B	200 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Сервер баз данных со всеми базами данных поиска.	C, D	100 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

2С SharePoint Server 2013 минимальный объем ресурсов — 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора.

3С SharePoint Server 2016 можно также использовать 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора, но в этом случае любой индексированный компонент сможет вместить не более 10 миллионов элементов, а в ферме поиска будет поддерживаться такой же объем контента как в ферме поиска SharePoint Server 2013.

Минимальные аппаратные ресурсы, необходимые для средней фермы поиска

В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами обработки запросов и индексирования.	A, B, C, D	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений, содержащий компонент индекса.	A, B, C, D	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений с компонентами аналитики и обработки контента.	E, F	300 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Сервер приложений с компонентами обхода контента, администрирования поиска и обработки контента.	E, F	100 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Сервер баз данных со всеми базами данных поиска.	G, H	400 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

2С SharePoint Server 2013 минимальный объем ресурсов — 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора.

3С SharePoint Server 2016 можно также использовать 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора, но в этом случае любой индексированный компонент сможет вместить не более 10 миллионов элементов, а в ферме поиска будет поддерживаться такой же объем контента как в ферме поиска SharePoint Server 2013.

Минимальные аппаратные ресурсы, необходимые для большой фермы поиска

В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами обработки запросов и индексирования.	A, B, C, D, E, G, H	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений, содержащий компонент индекса.	A, B, C, D, E, F, G, H, I, J	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений с компонентами аналитики и обработки контента.	K, L, M, N	300 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы приложений с компонентами обхода контента и администрирования поиска	K, L	100 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы баз данных с базами данных поиска.	O, P, Q, R	500 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

2С SharePoint Server 2013 минимальный объем ресурсов — 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора.

3С SharePoint Server 2016 можно также использовать 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора, но в этом случае любой индексированный компонент сможет вместить не более 10 миллионов элементов, а в ферме поиска будет поддерживаться такой же объем контента как в ферме поиска SharePoint Server 2013.

Минимальные аппаратные ресурсы для очень большой фермы поиска

В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных. Этот пример фермы можно создать только при использовании SharePoint Server 2016.

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами индексирования.	A-X	500 ГБ	32 ГБ	1,8 ГГц, 8 ядер	1 Гбит/с
Сервер приложений с компонентами обработки запросов и индексирования.	Y, Z	500 ГБ	32 ГБ	1,8 ГГц, 8 ядер	1 Гбит/с
Серверы приложений с компонентами обхода контента, администрирования поиска или обработки контента	AA-AF	100 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы приложений с компонентами обработки аналитики	AG, AH	800 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы баз данных с базами данных поиска	AI-AL	500 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

Планирование производительности хранилища

Скорость работы хранилища влияет на производительность поиска. Убедитесь, что имеющееся у вас хранилище работает достаточно быстро и способно обрабатывать трафик от компонентов и баз данных поиска. Скорость работы дисков измеряется количеством операций ввода-вывода в секунду (IOPS).

Способ доставки данных от компонентов поиска и операционной системы в рамках хранилища влияет на производительность поиска. Для получения хороших результатов можно сделать следующее.

• Разделить файлы операционной системы Windows Server, файлы программ SharePoint Server и журналы диагностики между тремя отдельными томами или разделами хранилища с нормальной производительностью.

• Храните данные компонентов поиска в отдельном томе или разделе хранилища. Кроме того, компоненты индекса необходимо хранить на томах с высокой производительностью.

  Примечание

  Вы можете выбрать настраиваемое расположение для данных компонента поиска при установке SharePoint Server на узле. Любой компонент поиска на узле, которому требуется хранить данных, будет хранить их в указанном расположении. Чтобы изменить его, необходимо переустановить SharePoint Server.

Выбор типа хранилища

Обзор архитектур хранилищ и типов дисков см. в статье Планирование и настройка мощности хранилища и SQL Server (SharePoint Server 2013). Для серверов, на которых размещены базы данных поиска или компоненты индекса, обработки данных аналитики либо администрирования поиска, необходимы хранилища, обеспечивающие малые задержки и достаточное количество операций ввода-вывода в секунду. В приведенных ниже таблицах показано, какое количество операций ввода-вывода в секунду необходимо для работы этих компонентов и баз данных поиска.

При развертывании общего хранилища, например SAN или NAS пиковая нагрузка на диски для одного компонента поиска обычно совпадает с пиковой нагрузкой на диски для другого компонента поиска. Чтобы определить количество операций ввода-вывода в секунду общего хранилища, необходимое для работы поиска, следует вычислить сумму количества операций ввода-вывода в секунду, необходимого для каждого из этих компонентов.

Требования к количеству операций ввода-вывода в секунду для компонента поиска

Имя компонента	Сведения о компоненте	Требуемое количество операций ввода-вывода в секунду	Использование отдельного тома или раздела хранилища
Компонент индекса	Использует хранилище при объединении индекса и при обработке запросов и ответах на них.	300 операций ввода-вывода в секунду для чтения блоков размером 64 КБ в случайном порядке. 100 операций ввода-вывода в секунду для записи блоков размером 256 КБ в случайном порядке. 200 МБ/с для последовательного чтения. 200 МБ/с последовательной записи.	Да
Компонент аналитики	Выполняет локальный анализ данных путем массовой обработки.	Нет	Да
Компонент обхода	Выполняет локальное хранение загруженного контента перед отправкой его на компонент обработки контента. Хранилище ограничено пропускной способностью сети.	Нет	Да

Требования к количеству операций ввода-вывода в секунду для базы данных поиска

Имя базы данных	Требуемое количество операций ввода-вывода в секунду	Типичная нагрузка на подсистему ввода-вывода.
База данных обхода	Количество операций ввода-вывода в секунду варьируется от среднего до большого	Скорость обхода контента составляет 10 операций ввода-вывода на 1 документ в секунду.
База данных ссылок	Среднее количество операций ввода-вывода в секунду	10 операций ввода-вывода в секунду на 1 млн элементов в индексе поиска.
База данных администрирования поиска	Малое количество операций ввода-вывода в секунду	Неприменимо.
База данных отчетов аналитики	Среднее количество операций ввода-вывода в секунду	Неприменимо.

Выбор способа поддержки высокой доступности архитектурой поиска

Если вы не знакомы со стратегиями высокого уровня доступности, следующая статья станет отличным подспорьем: Создание архитектуры и стратегии обеспечения высокой доступности для SharePoint Server. При размещении избыточных компонентов и баз данных поиска в отдельных отказоустойчивых доменах сбой одной части фермы не выводит из строя службу полностью. Но производительность поиска ухудшится, так как компоненты поиска больше не смогут распределять нагрузку между собой. Чтобы снизить шансы на потерю сервера, рекомендуется улучшить локальную избыточность. Для каждого хост-сервера в архитектуре поиска выполните следующие действия.

• Используйте хранилище RAID на каждом сервере.

• Установите несколько избыточных сетевых подключений на каждом сервере.

• Установите несколько избыточных источников питания с независимой разводкой или источники бесперебойного питания для каждого сервера.

Все примеры архитектур поиска размещают избыточные компоненты поиска на независимых серверах. В этих примерах самый правый узел в каждой паре является резервным. Вот пример масштабной архитектуры поиска с избыточными узлами: