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