Координационный узел OpenSearch - это любой узел, который обрабатывает HTTP(S) запросы для кластера, особенно запросы на индексирование и поиск. Каждый узел в кластере способен обрабатывать эти запросы.
Узел является только координирующим (CO) - также часто называемым "выделенным координирующим узлом" - когда он не является узлом данных и/или узлом, имеющим право на мастер. Если в кластере предусмотрены такие узлы, HTTP-клиенты настраиваются таким образом, чтобы все запросы на индексирование, все запросы на поиск или и те, и другие направлялись исключительно на эти узлы.
Основная цель такой схемы - изолировать узлы данных и ведущие узлы от требований к ресурсам, связанным с обработкой этих HTTP(S) запросов.
Преимущества выделенных координационных узлов
Как описано ниже, запросы на индексирование и поиск могут предъявлять к координирующему узлу более высокие требования к куче, чем к узлам данных, которые получают только запросы уровня осколков. Эта потребность еще больше возрастает, если частота запросов достаточно высока и некоторые из них должны быть поставлены в очередь.
В зависимости от размера и сложности запросов также могут возникнуть проблемы с процессором и сетью.
В некоторых сценариях использование узлов CO может обеспечить более низкие максимальные и средние задержки запросов.
Включение узлов CO также может упростить конфигурацию клиентских приложений. По мере добавления в кластер узлов данных клиентская конфигурация (или промежуточный балансировщик нагрузки) может продолжать содержать ссылки только на узлы CO.
Процесс выполнения поисковых запросов
Когда узел получает поисковый запрос, он определяет, какие индексы необходимо запросить, и отправляет запрос в одну копию каждого осколка этих индексов (фаза запроса). Каждый шард возвращает идентификаторы документов и оценки релевантности для документов до "размера".
Координирующий узел объединяет эти ответы, сортирует их по релевантности и извлекает только документы с наибольшим "размером" из тех осколков, которые их сообщили (фаза выборки). Затем они включаются в ответ на исходный поисковый запрос.
Процесс индексирования запросов
Когда узел получает запрос на индексирование документа, он должен направить его сначала на основной шард, а затем на все реплики, где хранится документ. В случае массового запроса на индексирование это должно быть сделано для каждого документа в запросе, и результат каждого отдельного запроса должен отслеживаться, чтобы можно было составить и отправить правильный массовый ответ.
Затраты на добавление только координирующих узлов
Каждый узел любого типа, входящий в кластер OpenSearch, должен хранить актуальную копию состояния кластера. Выбранный ведущий узел отправляет каждое изменение состояния кластера каждому из этих узлов и ждет подтверждения. Таким образом, добавление любого узла означает потенциальное увеличение времени ожидания применения любого изменения.
Более очевидные затраты связаны с выделением дополнительных физических ресурсов для другого экземпляра OpenSearch после определения оптимального дизайна (количество процессоров, объем кучи, пропускная способность сети).
Когда следует использовать выделенные координационные узлы
Кластер должен иметь CO-узлы, когда преимущества перевешивают затраты. Обычно это основано на том, что в существующем развертывании некоторые узлы стали нестабильными (особенно из-за управления кучей), или узлы периодически имеют высокую задержку на запрос из-за смешанной обработки HTTP-запросов и запросов уровня шарда.
Факторы, влияющие на соотношение затрат и выгод от использования CO-узлов, включают, в частности, следующие:
- Количество узлов данных и их размер
- Однородность и сложность документов и поисковых запросов
- Насколько "бурными" являются индексирование и поисковые запросы с течением времени
- Насколько тонко разделен каждый индекс
Однако ни для одного из них не существует конкретных критериев, определяющих, когда использовать CO-узлы, сколько их использовать и какого размера они должны быть. В широко распространенной практике внедрение CO-узлов обычно происходит, когда кластер достигает от 10 до 20 узлов данных, но в некоторых сценариях речь идет о меньшем количестве узлов данных, и нет никакой замены тестированию и мониторингу вашего кластера для определения оптимальной конфигурации. Рекомендуемым способом тестирования является использование тестовой среды, в которой можно оценить производительность запросов/индексации для данной конфигурации кластера.
Как использовать выделенные координирующие узлы
Если вы решили использовать CO-узлы, их должно быть как минимум два (для резервирования), а нагрузка на них должна быть сбалансирована. Узлам потребуется достаточно оперативной памяти для управления фазой сбора запросов, поэтому это будет зависеть от размера и частоты поиска и массового индексирования ответов, которые необходимо собрать.
После того как вы определили необходимый размер дополнительных узлов, обновите их конфигурацию, чтобы назначить роли узлов:
| 1 | node.roles: [ ] |
Разверните и запустите их с помощью тех же методов, что и существующие узлы в целевом кластере.
После того как они присоединятся к кластеру и вы убедитесь, что они принимают запросы, перенастройте все HTTP-клиенты на новые узлы, желательно по принципу круговой выборки.
Остерегайтесь создания нового узкого места
Если вы используете координирующие узлы, остерегайтесь создания нового узкого места. Если вы не создадите достаточного количества координирующих узлов, то можете обнаружить, что у вас недостаточно мощностей для выполнения роли координатора, в результате чего ваши узлы данных будут использоваться не полностью.
Предпочтение маршрутизации шардов
Помните, что если вы хотите побудить кластер направлять поисковые запросы от одного и того же клиента к одним и тем же шардам, чтобы использовать все преимущества кэширования на уровне узлов, вы можете использовать:
| 1 | _search?preference=my-session-id |
Этот параметр работает как для координирующих узлов, так и для стандартных узлов данных.