Да много чего по кластеру надо делать, сервис (в его нынешней конфигурации), существует уже восемь месяцев, изменения назрели. Но это буду делать, увы, уже не я.
Миграция шард — да, это головная боль. В среднем миграция данных за одни сутки занимает около 8 часов. И хоть гоняется ночью, но к утреннему росту нагрузки уж еле-еле поспевает.
1. Память для дата-нод выделяли сразу по максимуму — 32 гб. И то не хватает периодически. Была мысль попробовать перейти на 64 гб с использованием другого GC (Shenandoah), но руки не дошли и, боюсь, что уже не дойдут. А вот для клиентских нод (в которые смотрит Kibana), подбирали опытным путем, да. Через некоторое время дошли до 24 гб и на этом остановились.
2. «Какой % памяти на data ноде отдаете под heap? 50%?» — вопроса не понял, уточните, пожалуйста.
3. Это старая конфигурация. Она уже была, когда я пришел в компанию и получил в руки то, что получил. В следующей статье, я рассказывал как кластер переделывался под бОльшую оптимизацию ресурсов. Там я разместил все в LXC контейнеры и на каждый железный сервер влезло 2 дата-ноды + 1 мастер. И средствами LXC контейнеры лимитировались по процессорным ядрам — мастерам отдавалось по чуть-чуть, остальное уходило дата-нодам.
Но и это уже старая конфигурация. Потом я перевел кластер на hot/warm архитектуру и там все опять поменялось :)
Не то чтобы «отказались», а просто не начинали. Интересно было самому в деталях реализации разобраться, прежде чем стандартные инструменты использовать. Но к нему все придет, да.
Не сталкивался, но «в лоб» решил бы через logstash. Завернуть его на один кластер: читать из двух индексов, складывать в один. Главное проверить чтобы маппинги совпадали.
Может есть еще какое-то решение, не уверен.
Есть старое правило из мира Linux:
Если вы видите бумажную книгу по Linux — значит она устарела, как минимум на год. А если эта книга на русском — то на два.
На деньги, сэкономленные от покупки X-Pack для нашей инсталляции Elasticsearch, с нашими объёмами индексирования — вполне можно покупать по Хаммеру в год :)
Я об этом на хайлоаде рассказывал.
Пожалуйста. Весь смысл статьи именно в этом — показать какие основные метрики можно извлечь из недр эластика и что они означают.
А в какой именно мониторинг их заводить — дело хозяйское.
Роман, пользуясь случаем — хотел бы ещё раз поблагодарить за помощь и тестовые прогоны доклада. Ваши советы очень мне помогли. Без них — доклад не получился бы таким, каким получился.
Ну, это не NDA, поэтому про Питер могу рассказать: для безлошадных — каждые 15-20 минут ходит бесплатная развозка (автобус), от м. Площадь Ленина, до Бенуа. Если вы на машине — пропуск на парковку вам дадут как только закончится испытательный срок и освободится место (ибо их всё-таки конечное количество), поэтому в очередь лучше встать заранее. Мне пропуск дали ровно через месяц после окончания испытательного срока.
Миграция шард — да, это головная боль. В среднем миграция данных за одни сутки занимает около 8 часов. И хоть гоняется ночью, но к утреннему росту нагрузки уж еле-еле поспевает.
Записал в книжечку.
По. п.2 — посмотрите на numactl. Возможно там собака зарыта.
2. «Какой % памяти на data ноде отдаете под heap? 50%?» — вопроса не понял, уточните, пожалуйста.
3. Это старая конфигурация. Она уже была, когда я пришел в компанию и получил в руки то, что получил. В следующей статье, я рассказывал как кластер переделывался под бОльшую оптимизацию ресурсов. Там я разместил все в LXC контейнеры и на каждый железный сервер влезло 2 дата-ноды + 1 мастер. И средствами LXC контейнеры лимитировались по процессорным ядрам — мастерам отдавалось по чуть-чуть, остальное уходило дата-нодам.
Но и это уже старая конфигурация. Потом я перевел кластер на hot/warm архитектуру и там все опять поменялось :)
Может есть еще какое-то решение, не уверен.
Если вы видите бумажную книгу по Linux — значит она устарела, как минимум на год. А если эта книга на русском — то на два.
Я об этом на хайлоаде рассказывал.
А в какой именно мониторинг их заводить — дело хозяйское.
Извините, что так долго :(
Грустно, наверное, так жить.