Кросс-кластерный поиск в Elasticsearch позволяет пользователям выполнять запрос на нескольких кластерах, осуществляя один поисковый запрос между одним или несколькими удаленными кластерами. Например, с помощью кросс-кластерного поиска пользователи могут фильтровать и анализировать журналы, хранящиеся на кластерах в нескольких центрах обработки данных.
Кросс-кластерный поиск позволяет выполнять единые поисковые запросы по всем настроенным кластерам, при этом пользователи могут настраивать несколько удаленных кластеров, расположенных в различных географических точках и у различных провайдеров. Отправьте поисковый запрос с локального кластера и получите ответы от всех подключенных удаленных кластеров.
Кросс-кластерный поиск в Elasticsearch
Для осуществления кросс-кластерного поиска в Elasticsearch необходимо, чтобы развернутые системы были версии 6.7.x или более поздней и были совместимы. Для выполнения кросс-кластерного поиска необходимо настроить удаленные кластеры таким образом, чтобы между ними можно было установить соединение. Кроме того, они должны доверять друг другу.
Необходимые условия для выполнения кросс-кластерного поиска в Elasticsearch
1. Для выполнения кросс-кластерного поиска необходимы удаленные кластеры. Убедитесь, что кросс-кластерный поиск поддерживается конфигурацией удаленного кластера. Для регистрации удаленного кластера подключите локальный кластер к узлам удаленного кластера, используя режим прокси или sniff (по умолчанию). Далее настройте привилегии для кросс-кластерного поиска.
- Режим Sniff является режимом соединения по умолчанию. Для создания кластера в режиме sniff необходимо использовать имя и список начальных узлов. После регистрации удаленного кластера выбирается до трех шлюзовых узлов, которые будут участвовать в запросах удаленного кластера, а состояние кластера получается от одного из начальных узлов. Для работы этого режима локальный кластер должен иметь доступ к опубликованным адресам узла-шлюза. Версии удаленных узлов должны быть совместимы с версией кластера, в котором они зарегистрированы. По умолчанию в качестве шлюзового узла может выступать любой узел, не имеющий права мастера - следует помнить, что выделенные мастер-узлы никогда не выбираются в качестве шлюзовых узлов. Установив для параметра cluster.remote.node.attr.gateway значение true, пользователь может указать, какие узлы будут выступать в качестве шлюзовых узлов кластера.
- Удаленный кластер создается в режиме прокси с использованием имени и одного прокси-адреса. При регистрации удаленного кластера к IP-адресу прокси открывается настраиваемое количество сокетных соединений. Эти соединения должны быть перенаправлены на удаленный кластер через прокси. Для работы в режиме прокси удаленные узлы кластера не должны иметь доступных опубликованных адресов. Режим прокси должен быть настроен, поскольку он не является режимом соединения по умолчанию. Версия кластера, в котором зарегистрированы удаленные узлы, должна быть совместима с версиями удаленных узлов.
2. Роль узла remote_cluster_client необходима для локального координирующего узла.
1 | node.roles: [ remote_cluster_client ] |
3. При использовании режима sniff локальному координирующему узлу должно быть разрешено подключение как к seed, так и к шлюзовым узлам удаленного кластера. Также рекомендуется использовать шлюзовые узлы, которые могут выступать в качестве координирующих узлов (часть этих шлюзовых узлов может выступать в качестве начальных узлов).
4. При использовании режима прокси локальный координирующий узел должен подключаться к настроенному адресу proxy_address. Соединения со шлюзом и координирующими узлами удаленного кластера должны маршрутизироваться прокси-сервером по этому адресу.
5. Для кросс-кластерного поиска на локальном и удаленном кластерах необходимы разные привилегии безопасности.
Для роли кросс-кластерного поиска на удаленном кластере необходимы привилегии read и read_cross_cluster для целевых индексов. Аутентифицирующий пользователь должен иметь привилегию run_as на удаленном кластере, если запросы будут выполняться от имени других пользователей.
Роль remote-search необходима пользователю только на локальном кластере, с которого начинается кросс-кластерный поиск. Привилегии роли могут быть пустыми. Для создания роли remote-search на локальном кластере используется следующий запрос:
1 2 | POST /_security/role/remote-search {} |
Создайте пользователя на локальном кластере и назначьте ему роль удаленного поиска после того, как роль удаленного поиска будет создана на каждом кластере. Этот пользователь должен быть создан только на локальном кластере. Роль remote-search позволяет пользователям осуществлять поиск на разных кластерах.
При использовании Kibana для поиска по нескольким кластерам доступ пользователя к потокам данных и индексам на удаленных кластерах регулируется двухэтапной процедурой авторизации. Кластер, с которым связана Kibana, является локальным, и сначала он выясняет, есть ли у пользователя разрешение на доступ к удаленным кластерам. Затем удаленный кластер определяет, есть ли у пользователя доступ к заданным потокам данных и индексам. Для настройки необходимо назначить пользователям Kibana локальную роль с правами чтения индексов удаленных кластеров, чтобы предоставить им доступ к удаленным кластерам. В удаленном кластере укажите потоки данных и индексы в виде <имя_удаленного_кластера>:<цель>. Для предоставления пользователям доступа на чтение к удаленным потокам данных и индексам на удаленных кластерах должна быть создана соответствующая роль, предоставляющая привилегию read_cross_cluster с доступом к соответствующим потокам данных и индексам.
Настройка удаленных кластеров в Elasticsearch
Ниже приведен пример API-запроса на обновление настроек кластера для добавления в настройки кластера трех удаленных кластеров: cluster_one, cluster_two и cluster_three. Теперь эти три кластера будут являться удаленными кластерами для кластера, выполняющего данный API-запрос.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | PUT _cluster/settings { "persistent": { "cluster": { "remote": { "cluster_one": { "seeds": [ "10.0.0.1:9302" ] }, "cluster_two": { "seeds": [ "10.0.0.1:9301" ] }, "cluster_three": { "seeds": [ "10.0.0.1:9300" ] } } } } } |
Начиная с версии 7.7.0 пользователи также могут настраивать удаленные кластеры в Kibana.
Пример кросс-кластерного поиска в Elasticsearch
Для поиска индекса на удаленном кластере необходимо префикснуть имя индекса с именем удаленного кластера, как показано в примере ниже. Уточните потоки данных и индексы на удаленном кластере как <имя_удаленного_кластера>:<цель> в поисковом запросе.
1 2 3 4 5 6 7 8 | GET cluster_two:books/_search { "query": { "match": { "title": "Deep learning" } } } |
В приведенном выше примере в индексе books на кластере cluster_two будут искаться книги с названием "Deep learning".
Чтобы выполнить поиск по нескольким кластерам, просто перечислите имена кластеров и индексы, как показано в примере ниже:
1 2 3 4 5 6 7 8 | GET books,ABC_cluster:books,cluster_*:books/_search { "query": { "match": { "title": "Deep learning" } } } |
В приведенном примере поиск по индексу books будет выполняться в локальном кластере ABC_cluster, а также во всех кластерах, название которых начинается с "cluster_", например, cluster_one, cluster_two и cluster_three. В именах удаленных кластеров можно использовать подстановочные знаки.
Все результаты, полученные по удаленному индексу, в теле поискового ответа будут иметь префикс с именем удаленного кластера в поле _index, как показано в следующем результате предыдущего запроса. Если имя кластера не включено в параметр _index документа, то документ был создан локально. См. ниже:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | "hits": [ { "_index": " ABC_cluster:books", "_id": "3s1CKnIBCLh5xF6i4Y2g", "_score": 4.8329377, "_source": { "title": "Deep learning", ... } }, { "_index": " books", "_id": "Mc1CKmISCLh8xF6i7Y", "_score": 4.561167, "_source": { "title": "Deep learning", ... } }, |
Если удаленный кластер, включенный в запрос, выдает ошибку или недоступен, то кросс-кластерный поиск по умолчанию завершится неудачно. Чтобы сделать определенный удаленный кластер необязательным для кросс-кластерного поиска, используйте параметр skip_unavailable cluster. В API-запросе на обновление параметров кластера пользователи могут изменить настройки кластера, установив параметр skip_unavailable в значение true, как показано в примере ниже:
1 2 3 4 5 6 | PUT _cluster/settings { "persistent": { "cluster.remote.ABC_cluster.skip_unavailable": true } } |
После выполнения приведенного выше API-запроса, если кластер ABC_cluster недоступен или отключен при кросс-кластерном поиске, то совпадающие документы из этого кластера не будут включены в конечные результаты, возвращаемые Elasticsearch.
Если параметр skip_unavailable равен true, то при кросс-кластерном поиске кластер будет пропущен, если какой-либо из узлов удаленного кластера не работает во время поиска. Счетчик всех пропущенных кластеров содержится в значении _cluster.skipped ответа. Также будут проигнорированы все ошибки, которые могли быть возвращены удаленным кластером, например, ошибки, связанные с недоступными шардами или индексами. Это может быть связано с такими параметрами поиска, как ignore_unavailable и allow_no_indices. Кроме того, параметр allow_partial_search_results и связанная с ним кластерная настройка search.default_allow_partial_results будут игнорироваться при поиске на удаленном кластере. В результате поиск на удаленном кластере может давать только частичные результаты.
Любые сетевые задержки могут замедлить работу кросс-кластерного поиска, так как при этом требуется отправка запросов на удаленные кластеры. Кросс-кластерный поиск предлагает два способа борьбы с сетевыми задержками для предотвращения задержки поиска:
Минимизация количества сетевых обходов
По умолчанию Elasticsearch минимизирует количество сетевых обходов между удаленными кластерами. При этом уменьшается влияние сетевых задержек на скорость поиска. Для длинных поисковых запросов, таких как запросы, включающие прокрутку или внутренние просмотры, Elasticsearch не может минимизировать количество сетевых обходов.
Не минимизируйте сетевые обходы
Elasticsearch отправляет множество исходящих и входящих запросов на каждый удаленный кластер для поисковых запросов, содержащих прокрутку или внутренние совпадения. Установив для параметра ccs_minimize_roundtrips значение false, можно выбрать и этот вариант. Этот метод, хотя и работает зачастую медленнее, может быть эффективен в сетях с низкой задержкой.
Elasticsearch позволяет выполнять поиск от локальных кластеров к удаленным кластерам, на которых работают: более ранняя минорная версия, идентичная версия и более новая минорная версия в той же мажорной версии. Например, локальный кластер 7.17 может искать в любом удаленном кластере 7. x, таком как 7.15, 7.17 и 7.18. Кроме того, Elasticsearch позволяет выполнять поиск от локального кластера, на котором установлена самая актуальная минорная версия основной версии, до удаленного кластера, на котором установлена любая минорная версия основной версии, следующая за ней. Например, локальный кластер 7.17 может искать на любом удаленном кластере 8. x.
Поддерживаются только те функции, которые присутствуют в каждом искомом кластере. Использование неподдерживаемых функций на удаленном кластере приведет к непредсказуемому поведению. Если пользователь выберет неподдерживаемую конфигурацию, кросс-кластерный поиск все равно может быть успешным. Elasticsearch не тестирует и не гарантирует поведение таких типов поиска.
Замечания по кросс-кластерному поиску в Elasticsearch
Безопасность должна быть включена и настроена как на локальном, так и на удаленном кластере. Суперпользователь Elasticsearch на локальном кластере, например, пользователь elastic, получает полный доступ на чтение к удаленным кластерам при подключении к локальным кластерам. Для безопасного использования межкластерного поиска необходимо включить защиту на всех связанных кластерах и установить на каждом узле защиту транспортного уровня (TLS), по крайней мере, на транспортном уровне.
Более того, удаленный кластер теоретически может быть захвачен локальным администратором на уровне операционной системы, имеющим достаточный доступ к конфигурационным файлам Elasticsearch и закрытым ключам. Убедитесь, что ваш план безопасности охватывает безопасность на уровне операционной системы как для локальных, так и для удаленных кластеров.
Для поиска по кластерам пользователям больше не требуется использовать специальный шаблон развертывания кросс-кластерного поиска. При использовании стека версии 6.7 и выше пользователи могут настраивать удаленные кластеры по любому шаблону, выполняя поиск по ним. Шаблон межкластерного поиска был снят с производства. Существующие развертывания, созданные с использованием этого шаблона, не будут затронуты данной модификацией, однако перед обновлением до основной версии 8.0 их необходимо переключить на другой шаблон.
Параметр ccs_minimize_roundtrips не поддерживается API для поиска векторных плиток, так как он всегда минимизирует обход сети.
Когда обход сети не минимизируется, поиск выполняется так, как если бы все данные находились в кластере координирующего узла. Рекомендуется обновить параметры кластерного уровня, ограничивающие поиск, такие как action.search.shard_count.limit, pre_filter_shard_size и max_concurrent_shard_requests. Поиск может быть проигнорирован, если эти ограничения установлены слишком низко.
Запуск одной и той же версии Elasticsearch в каждом кластере - это самый простой способ гарантировать, что кластеры обеспечивают кросс-кластерный поиск. Если необходимо, чтобы на кластерах работали разные версии, пользователи могут выделить отдельный кластер для кросс-кластерного поиска.
Для поиска в других кластерах необходимо поддерживать этот кластер в актуальном состоянии. Например, если у пользователя есть кластеры 7.17 и 8.x, можно использовать отдельный кластер 7.17 в качестве локального кластера для кросс-кластерного поиска. Не следует выделять в каждом кластере более одной младшей версии. Это позволяет выполнять кросс-кластерный поиск, используя любой кластер в качестве локального.
При выполнении скользящего обновления на локальном кластере пользователи все еще могут осуществлять поиск на удаленном кластере. Однако шлюзовой узел удаленного кластера должен поддерживать версии "upgrade from" и "upgrade to" локального координирующего узла.
Использование различных версий Elasticsearch в одном кластере после завершения обновления не рекомендуется.