Количество узлов AWS Elasticsearch

Я не использовал AWS Elasticsearch, но использовал сервис Cloud Elasticsearch.

Когда вы используете 3 AZ (зоны доступности), это означает, что ваш кластер будет использовать 3 зоны, чтобы сделать его устойчивым. Если в одной зоне есть проблемы, то и узлы в этой зоне тоже будут иметь проблемы.

Как упоминается в разделе описания, вам необходимо указать число, кратное 3, если вы выберете 3 AZ. Если у вас 3 узла, то в каждой АЗ будет одна зона. Если в одной зоне есть проблемы, то этот узел вышел из строя, два оставшихся должны будут оттуда подцепиться.

Теперь, чтобы ответить на ваш вопрос. Что вы получаете с этими конфигурациями. Вы можете проверить это сами. Используйте это через kibana или любой HTTP-клиент

GET _nodes

Проверьте разделы:

• узлы.роли
• узлы.атрибуты

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

Итак, давайте пошагово:

• Вам нужно четное количество мастер-узлов, чтобы избежать проблемы разделения мозга. .
• Вам нужно более одного узла в вашем кластере, чтобы сделать его устойчивым (если узел недоступен).

Объединив эти два, вы получите минимальное требование в 3 узла (пока нет упоминания о зонах).

Но иметь один мастер и два узла данных не получится. Вам необходимо иметь 3 ноды, отвечающие требованиям мастера. Таким образом, если у вас есть один отключенный узел, два других могут сформировать кворум и проголосовать за нового мастера, поэтому ваш кластер будет работать с двумя узлами. Но для того, чтобы это работало, вам нужно настроить основные сегменты и сегменты реплик таким образом, чтобы любые два из ваших узлов могли хранить все ваши данные.

Примеры (для простоты у нас только один индекс):

1. 1 основной, 2 реплики. Каждый узел содержит один сегмент, который составляет 100% данных.
2. 3 основных, 1 реплика. Каждый узел будет содержать один основной узел и одну реплику (33 % — основной, 33 % — реплика). Два объединенных узла (что также является минимумом для формирования кворума) будут хранить все ваши данные (и некоторые другие).

У вас может быть больше комбинаций, но вы поняли идею.

Как видите, конфигурация сегмента должна соответствовать вашему количеству и типу узлов (мастер-приемлемые, только данные и т. д.).

Теперь, если вы добавите зоны доступности, вы решите проблему проблемной зоны. Если ваш кластер целиком находился в одной зоне (3 узла в одном узле), то, если эта зона была проблемной, весь ваш кластер отсутствует.

Если вы настроили один главный узел и два узла данных (которые не имеют права на роль главного), наличие 3 зон доступности (или даже 3 узлов) не сильно повлияет на отказоустойчивость, поскольку, если главный узел выйдет из строя, ваш кластер не сможет выбрать новый. и он будет отключен до тех пор, пока главный узел снова не заработает. Теперь для той же настройки, если узел данных выходит из строя, тогда, если ваши осколки настроены таким образом, что существует избыточность (это означает, что два оставшихся узла имеют все данные, если они объединены), тогда он будет работать нормально.

Ваши ответы должны охватывать следующие три пункта.

If i specify 3 data nodes and 3-AZ, what it actually means?

• Это означает, что ваши данные и реплики будут доступны в трех зонах доступности, при этом ни одна реплика не будет находиться в той же зоне доступности, что и узел данных. Проверьте эта ссылка. Например, когда вы говорите, что хотите 2 узла данных в 2 зонах доступности. DN1 будет сохранен (скажем) в AZ1, а его реплика будет храниться в AZ2. DN2 будет в AZ2, а его реплика — в AZ1.

It looks like in other AZ's should be replicas. but then I don't understand why I have different values of free space on different nodes

• Это связано с тем, что когда вы предоставляете AWS Elasticsearch некоторый объем хранилища, кластер делит указанное пространство хранения на все узлы данных. Если вы укажете 100 ГБ хранилища в кластере с 2 узлами данных, пространство хранения будет разделено поровну на все узлы данных, т. е. два узла данных с 50 ГБ доступного пространства хранения на каждом.

• Иногда вы увидите больше узлов, чем вы указали в кластере. Мне потребовалось некоторое время, чтобы понять это поведение. Причина этого в том, что при обновлении этих конфигураций на AWS ES требуется некоторое время для стабилизации кластера. Поэтому, если вы видите больше данных или мастер-узлов, как и ожидалось, подождите некоторое время и подождите, пока они стабилизируются.

Спасибо всем за помощь. Чтобы понять, сколько места доступно/выделено, выполните следующие запросы:

GET /_cat/allocation?v
GET /_cat/indices?v
GET /_cat/shards?v

Итак, если я создаю 3 узла, а затем создаю 3 разных узла с отдельными хранилищами, они не являются репликами. Одни данные хранятся в одном узле, другие — в другом.