Изменение топологии корпоративного поиска для большего содержимого и пользователей в SharePoint
ОБЛАСТЬ ПРИМЕНЕНИЯ:
2013 2016 2019 Subscription Edition 
SharePoint в Microsoft 365
Со временем большинство размер сред поиска увеличивается, как с точки зрения объема контента, так и числа пользователей. В некоторый момент емкости и производительности вашей архитектуры поиска становится недостаточно для среда поиска. Чтобы справиться с этим, необходимо масштабировать топологию архитектуры поиска.
Изменение топологии (эта статья)
Реализация измененной топологии (Управление топологией поиска в SharePoint Server)
Знакомы ли вы с компонентами системы поиска в SharePoint Server и как они взаимодействуют? Прочитав обзор архитектуры поиска в SharePoint Server и архитектуры поиска для SharePoint Server 2016 (или архитектуры поиска для SharePoint Server 2013), прежде чем начать работу, вы познакомитесь с архитектурой поиска, компонентами поиска, базами данных поиска и топологией поиска.
В этой статье мы покажем вам, как изменить топологию поиска.
После выполнения этих действий вы узнаете:
сколько типов компонентов поиска и баз данных поиска требуется для вашей топологии;
на каких серверах приложений и баз данных следует развернуть каждый компонент поиска;
какие аппаратные ресурсы необходимы каждому серверу приложений и баз данных.
Действие 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 запросов в секунду. Если в ферме SharePoint Server 2016 имеется до 20 миллионов элементов, скорее всего, вам подойдет небольшая ферма поиска. При скорости 50 документов в секунду первый полный обход 20 миллионов элементов занимает 110 часов.
Средняя ферма поиска
Мы определили, что эта архитектура поиска может выполнять обход контента со скоростью 20 документов в секунду и обрабатывать порядка 80 запросов в секунду. Если у вас есть от 20 до 80 миллионов элементов в ферме 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. Серверу узла также требуется свободное дисковое пространство для диагностических целей, например для ведения журнала, отладки и создания дампов памяти по выполняемым ежедневно операциям, а также для файла подкачки. Как правило, 80 ГБ дискового пространства достаточно для операционной системы Windows Server и программных файлов SharePoint Server.
Увеличьте объем хранилища для пространства журналов SQL каждого сервера базы данных. Если не настроить сервер базы данных для частого резервного копирования баз данных, пространство журнала SQL использует много хранилища. Дополнительные сведения о планировании баз данных SQL см. в статье Storage and SQL Server capacity planning and configuration (SharePoint Server).
Минимальный объем хранилища, необходимый для базы данных отчетов аналитики, может быть разным. Это связано с тем, что объем хранилища зависит от того, как пользователи взаимодействуют с SharePoint Server. Если взаимодействие происходит часто, обычно требуется хранить больше событий. Узнайте, какой объем хранилища текущая архитектура поиска использует для базы данных аналитики, и назначьте по крайней мере этот объем переработанной топологии.
Минимальные аппаратные ресурсы, необходимые для малой фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.
| Сервер | На узле | Хранилище | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами обработки запросов и индексирования. | 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 ГБ ОЗУ и четыре ядра ЦП.
3SharePoint Server 2016 также позволяет использовать хранилище размером 250 ГБ, 16 ГБ ОЗУ и четыре ядра ЦП, но каждый компонент индекса может содержать только 10 миллионов элементов, а ферма поиска поддерживает только тот же объем содержимого, что и ферма поиска SharePoint Server 2013.
Минимальные аппаратные ресурсы, необходимые для средней фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.
| Сервер | На узле | Хранилище | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами обработки запросов и индексирования. | 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 ГБ ОЗУ и четыре ядра ЦП.
3SharePoint Server 2016 также позволяет использовать хранилище размером 250 ГБ, 16 ГБ ОЗУ и четыре ядра ЦП, но каждый компонент индекса может содержать только 10 миллионов элементов, а ферма поиска поддерживает только тот же объем содержимого, что и ферма поиска SharePoint Server 2013.
Минимальные аппаратные ресурсы, необходимые для большой фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.
| Сервер | На узле | Хранилище | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами обработки запросов и индексирования. | 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 ГБ ОЗУ и четыре ядра ЦП.
3SharePoint Server 2016 также позволяет использовать хранилище размером 250 ГБ, 16 ГБ ОЗУ и четыре ядра ЦП, но каждый компонент индекса может содержать только 10 миллионов элементов, а ферма поиска поддерживает только тот же объем содержимого, что и ферма поиска SharePoint Server 2013.
Минимальные аппаратные ресурсы для очень большой фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных. Этот пример фермы можно создать только с SharePoint Server 2016.
| Сервер | На узле | Хранилище | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами индексирования. | 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 на каждом сервере.
Установите несколько избыточных сетевых подключений на каждом сервере.
Установите несколько избыточных источников питания с независимой разводкой или источники бесперебойного питания для каждого сервера.
Все примеры архитектур поиска размещают избыточные компоненты поиска на независимых серверах. В этих примерах самый правый узел в каждой паре является резервным. Вот архитектура большого поиска с выделенными избыточными узлами:
