Высокая доступность кластера Managed Service for OpenSearch

Высокая доступность кластера Managed Service for OpenSearch определяется количеством и расположением хостов с ролью DATA и MANAGER, настройками репликации индексов между зонами доступности, а также состоянием защиты кластера от опасных изменений.

Конфигурация хостов кластераКонфигурация хостов кластера

Кластер Managed Service for OpenSearch состоит из одной или нескольких групп хостов, в которых каждый хост выполняет определенную роль.

Каждая группа хостов OpenSearch может включать хосты с ролями DATA или MANAGER. Если в кластере есть только одна группа OpenSearch, ее хосты совмещают обе роли.

Чтобы кластер обеспечивал высокую доступность и на него распространялось Соглашение об уровне обслуживания (SLA), он должен включать:

1. Два и более хоста с ролью DATA, расположенных в разных зонах доступности. При этом в каждой зоне доступности должно находиться не больше половины хостов с ролью DATA.
2. Три и более хоста с ролью MANAGER, расположенных в разных зонах доступности. При этом в каждой зоне доступности должно находиться не больше половины хостов с ролью MANAGER.

Требование «не больше половины хостов в одной зоне доступности» означает, что при отказе любой из зон доступности в кластере продолжит работать не меньше половины хостов каждой роли, а хосты с ролью MANAGER сохранят кворум, необходимый для выбора мастера. Например:

• два хоста с ролью DATA в двух разных зонах доступности — требование выполняется;
• три хоста с ролью DATA, два из которых расположены в одной зоне доступности, — требование не выполняется;
• три хоста с ролью MANAGER в трех разных зонах доступности — требование выполняется;
• три хоста с ролью MANAGER в двух зонах доступности — требование не выполняется: при отказе зоны с двумя хостами оставшийся хост не сможет обеспечить кворум.

В консоли управления конфигурация кластера по умолчанию предусматривает одну группу OpenSearch, состоящую из трех хостов, расположенных в трех разных зонах доступности. В этой конфигурации хосты выполняют роли DATA и MANAGER.

Настройки репликацииНастройки репликации

В многохостовых кластерах доступна репликация индексов. Чтобы такой кластер обеспечивал высокую доступность и на него распространялось Соглашение об уровне обслуживания (SLA), должны выполняться следующие условия:

1. Каждый индекс в кластере должен иметь хотя бы одну реплику — настройка индекса index.number_of_replicas должна быть больше нуля.

   То же требование действует для настройки кластера cluster.default_number_of_replicas, которая задает число реплик по умолчанию.

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

   Правила размещения шардов (например, настройки index.routing.allocation.* и cluster.routing.allocation.*) не должны:

   • ссылаться на несуществующие зоны доступности или группы хостов;
   • ограничивать размещение всех копий шарда одной зоной доступности;
   • приводить к тому, что первичный шард невозможно разместить ни на одном из хостов кластера.

3. Настройки кластера и индексов не должны приводить к превышению верхнего порога заполнения хранилища (high watermark) на хостах с ролью DATA.

Нулевое число реплик может быть задано не только напрямую при создании или изменении индекса, но и косвенно. Такие настройки тоже нарушают требования к высокой доступности:

• шаблон индекса — обычный или composable — в котором настройка number_of_replicas равна нулю. По такому шаблону будут создаваться индексы без реплик;
• действие replica_count с нулевым числом реплик в политике индекса;
• операция rollover, если новый индекс получит нулевое число реплик из шаблона индекса.

Если в кластере действует расширенная защита, нарушающие перечисленные условия запросы отклоняются с ошибкой.

Подробнее о репликации в разделе Шардирование и репликация в Managed Service for OpenSearch.

Защита кластера от опасных измененийЗащита кластера от опасных изменений

Чтобы кластер нельзя было случайно привести в состояние, в котором он станет недоступен или потеряет данные, Managed Service for OpenSearch блокирует часть запросов к OpenSearch API. Заблокированный запрос завершается ошибкой с описанием причины.

Ограничения действуют для всех пользователей кластера, в том числе для пользователя admin.

Базовые ограниченияБазовые ограничения

Действуют во всех кластерах Managed Service for OpenSearch. Заблокированы:

• Изменение защищенных настроек кластера. Защищены настройки со следующими префиксами:

  • cluster.routing.allocation.disk.watermark.;
  • cluster.fault_detection.follower_check.timeout;
  • cluster.fault_detection.leader_check.timeout;
  • cluster.follower_lag.timeout;
  • cluster.publish.timeout;
  • cluster.snapshot.info.max_concurrent_fetches.

  Изменить эти настройки можно только через техническую поддержку.

• Исключение хостов с ролью MANAGER из голосования при выборе мастера — запрос POST /_cluster/voting_config_exclusions. Чтобы переключить мастер, используйте команду Yandex Cloud CLI yc managed-opensearch cluster switch-master.

• Операции с системными репозиториями резервного копирования yc-automatic-backups и yc-automatic-restore: создание и удаление репозитория, создание и удаление снапшотов в нем. Также защищена одноименная политика Snapshot Management yc-automatic-backups.

Расширенная защитаРасширенная защита

Действует в кластерах, которые соответствуют требованиям к конфигурации хостов. В дополнение к базовым ограничениям блокируются запросы, которые нарушают требования к репликации: создание индекса, изменение настроек индекса, создание шаблона индекса, создание и изменение политики индекса, операция rollover, а также изменение настроек кластера.

Расширенная защита включается автоматически в момент, когда кластер начинает соответствовать требованиям к конфигурации хостов, — например, при создании кластера или при добавлении хостов в существующий кластер. Перед включением сервис анализирует текущее состояние кластера:

• Если нет настроек, нарушающих требования к репликации, расширенная защита включается.
• Если такие настройки есть — например, в кластере уже созданы индексы, шаблоны индексов или политики индексов с нулевым числом реплик, — расширенная защита не включается. Кластер помечается как незащищенный, не считается высокодоступным, и на него не распространяется Соглашение об уровне обслуживания (SLA). Чтобы включить защиту, устраните нарушения и обратитесь в техническую поддержку.

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

Состояние высокой доступности кластера отслеживает инспекция Высокая доступность кластера при отказе зоны.

Проверка настроек кластераПроверка настроек кластера

Чтобы узнать, какие настройки кластера и индексов нарушают требования к высокой доступности, отправьте запрос:

curl \
    --user <имя_пользователя>:<пароль> \
    --cacert ~/.opensearch/root.crt \
    --request POST \
    --header 'Content-Type: application/json' \
    --url 'https://<FQDN_хоста_OpenSearch_с_публичным_доступом>:9200/_plugins/_security/availability_guard/analyze' \
    --data '{}'

Пустое тело запроса {} означает, что будет проверено текущее состояние кластера. Чтобы заранее оценить последствия изменений, передайте в теле запроса одно или несколько полей:

• settings — настройки кластера, которые нужно проверить. Они дополняют текущие настройки кластера и переопределяют совпадающие. Так можно оценить последствия запроса PUT /_cluster/settings до его выполнения.

• excluding_hosts — список FQDN хостов, которые нужно исключить из проверки. Так можно оценить, что произойдет при удалении этих хостов или при отказе зоны доступности, в которой они расположены.

• excluding_indices — список имен индексов, которые нужно исключить из проверки. Поддерживается подстановочный знак *.

• nodes — состав хостов кластера, который нужно проверить вместо фактического. Ключ — имя хоста (поле name в ответе на запрос GET /_cat/nodes?v), значение — объект с полями:

  • roles — список ролей хоста в терминах OpenSearch: data, cluster_manager, ingest, remote_cluster_client или warm. Поле обязательное;
  • attributes — атрибуты хоста, которые используются в правилах размещения шардов, например зона доступности или группа хостов. Актуальные атрибуты хостов кластера можно получить запросом GET /_cat/nodeattrs?v;
  • disk_size — размер хранилища хоста, например 100gb.

  Если задано поле nodes, поле excluding_hosts игнорируется.

Например, чтобы узнать, что произойдет при отказе зоны доступности, исключите из проверки все хосты этой зоны:

curl \
    --user <имя_пользователя>:<пароль> \
    --cacert ~/.opensearch/root.crt \
    --request POST \
    --header 'Content-Type: application/json' \
    --url 'https://<FQDN_хоста_OpenSearch_с_публичным_доступом>:9200/_plugins/_security/availability_guard/analyze' \
    --data '{
        "excluding_hosts": [
            "<FQDN_хоста_1>",
            "<FQDN_хоста_2>"
        ]
    }'

Обнаруженные проблемы перечислены в ответе массива allocation_impacts, причина каждой из них указана в поле reason. Пустой массив означает, что проблем не найдено.

Настройки хранилищаНастройки хранилища

Когда хранилище заполняется на 95%, хосты кластера автоматически переходят в режим read-only. В этом режиме запросы на запись данных завершаются ошибкой. Чтобы избежать ситуаций, когда свободное место на диске заканчивается и кластер становится недоступным для записи:

• настройте алерты в Yandex Monitoring для отслеживания степени заполнения хранилища;
• настройте автоматическое увеличение размера хранилища.

Подробнее об управлении дисковым пространством в Managed Service for OpenSearch.

Настройки обслуживанияНастройки обслуживания

В многохостовых кластерах хосты последовательно проходят техническое обслуживание. Если во время технического обслуживания потребуется перезагрузка хоста, он станет недоступным на это время.

Подробнее о техническом обслуживании в Managed Service for OpenSearch.

Прочие параметры и ограниченияПрочие параметры и ограничения

На доступность кластера также могут влиять:

• настройки резервного копирования;

• тип дисков хранилища;

• класс хостов;

• квоты и лимиты;

• настройки групп безопасности.