Исправляем статус одиночного сервера ElasticSearch

0
0
0

Зелёный статус для одиночного ElasticSearch

  • Когда мы собеседуем системных администраторов и видим в их резюме упоминание ElasticSearch, мы обязательно задаём им вопрос «какого цвета будет одиночный сервер?»
  • Примерно половина соискателей не понимает его смысла и на этом наше знакомство с ними, как правило, заканчивается (потому что их владение остальными указанными в резюме терминами обычно находится на аналогичном уровне).

Оставшейся половине мы задаём два вопроса:

  • Почему он жёлтый,
  • и как превратить его в зелёный, не создавая кластер?

Цвет означает состояние сервера:

  • Зелёный — всё хорошо.
  • Жёлтый — сервер правильно обрабатывает все запросы на чтение/запись, но есть внутренние проблемы, которые необходимо исправить.
  • Красный — всё плохо.

Как увидеть цвет сервера?

  • Запрос:
curl '127.0.0.1:9200/_cluster/health?pretty=true'
  • Пример ответа:
{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1880,
  "active_shards" : 1880,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 1680,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 52.80898876404494
}

Почему отдельный сервер будет по умолчанию жёлтым?

  • Потому что ElasticSearch является отказоустойчивой системой хранения данных, которая расчитана для запуска не на одном сервере, а на группе (кластере) из нескольких связанных серверов (узлов, “nodes”).
  • В частности, ElasticSearch подразумевает, что при отказе одного узла система должна сохранять полную работоспособность.
  • Для этого система должна состоять из нескольких серверов (минимум — двух, желательно — трёх для предотвращения split brain), и каждая порция данных (т.н. “shard” в терминологии ES) должна храниться в нескольких экземплярах на разных серверах.
  • Один из этих экземпляров ES будет считать первичным (“master shard”), остальные копиями первичного (“replica shards”).
  • В системе из одного сервера ES хранит на нём все “primary shards”, но создавать “replica shards” такой системе будет негде.
  • Поэтому статус в приведённом примере является жёлтым из-за ненулевого значения “unassigned_shards”, которое примерно равно “active_shards”.
  • Небольшая разница между количеством активных и неразмещённых шардов обусловлена тем, что часть служебных индексов является локальной для каждого узла, то есть не должна иметь реплик и не приводит к появлению unassigned shards.
  • Подробнее о том, что такое шарды, зачем они нужны, и какое место занимают между документами и индексами: https://stackoverflow.com/a/49892584/2743554.

Как сделать одиночный сервер зелёным?

  • Сначала узнаем, какие шарды система не сумела разместить:
curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED
  • Теперь посмотрим, к каким индексам они относятся:
curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }'
  • После этого поменяем настройки индексов — уменьшим количество реплик (так называемый Replication Factor) до нуля:
curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }' |
while read idx; do
    curl -XPUT "localhost:9200/$idx/_settings" -H 'Content-Type: application/json' -d '{ "index": { "number_of_replicas": 0 } }'
done
или
curl -sS -XGET '10.233.108.217:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }'
  • И проверим результат:
{
  "cluster_name" : "elasticsearch",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1880,
  "active_shards" : 1880,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

Почему в полночь карета превратится в тыкву сервер снова станет жёлтым?

  • Потому что в ES принято каждые сутки автоматически создавать новый индекс с именем вида “basename-yyyy.mm.dd” из шаблона.
  • Поэтому Replication Factor необходимо уменьшить до нуля не только в существующих индексах, но и в шаблонах, из которых будут создаваться новые индексы.
  • Это делается так:
curl -XPUT "127.0.0.1:9200/_template/all?pretty=true" -H 'Content-Type: application/json' -d \
'{ "template" : "*" , "settings": { "number_of_replicas": 0 } }' 
или
curl -XPUT "10.233.108.217:9200/$idx/_settings" -H 'Content-Type: application/json' -d '{ "index": { "number_of_replicas": 0 } }'
  • После этого постоянный статус одиночного сервера станет зелёным, а жёлтый превратится из «фонового шума» в надёжный показатель проблем, действительно требующих исправления.

Источник: https://cdnnow.ru/blog/esgreen/

Was this helpful?

0 / 0