Количество узлов AWS Elasticsearch - PullRequest
0 голосов
/ 17 апреля 2020

Я читаю документацию, но, к сожалению, я до сих пор не понимаю одну вещь. При создании домена AWS Elasticsearch мне нужно выбрать «Количество узлов» в разделе «Узлы данных». Если я укажу 3 узла данных и 3-AZ, что это на самом деле означает? enter image description here У меня есть предложения:

  1. Я получу 3 узла с собственными хранилищами (EBS). Один из узлов является основным, а другие 2 являются репликами в разных AZ. Просто скопируйте мастер, чтобы не потерять данные, если мастер-узел сломался.

  2. Я получу 3 узла с собственными хранилищами (EBS). Все они будут работать независимо и на их хранилищах будут разные данные. Таким образом, в то же время данные могут обрабатываться разными узлами и храниться в разных хранилищах.

Похоже, в других AZ должны быть реплики. но тогда я не понимаю, почему у меня разные значения свободного пространства на разных узлах enter image description here

Пожалуйста, объясните, как это работает. Большое спасибо за любую информацию или ссылки.

Ответы [ 2 ]

0 голосов
/ 05 мая 2020

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

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

  • Это означает, что ваши данные и реплики будут доступны в 3AZ, но ни одна из реплик не будет одинаковой. AZ в качестве узла данных. Проверьте эту ссылку. Например, когда вы говорите, что хотите 2 узла данных в 2 AZ. 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, для стабилизации кластера требуется некоторое время. Поэтому, если вы видите больше данных или мастер-узлов, как ожидается, подождите некоторое время и дождитесь стабилизации.

0 голосов
/ 18 апреля 2020

Я не использовал AWS Elasticsearch, но я использовал службу Cloud Elasticsearch.

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

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

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

GET _nodes

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

  • node.roles
  • node.attributes

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

Итак, давайте возьмем его шаг за шагом:

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

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

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

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

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

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

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

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

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

...