2015-06-12 2 views
2

Прошу прощения, что это, вероятно, некий широкий вопрос, но я еще не нашел решение этой проблемы.Стратегия сохранения данных узла для динамических кластеров Elasticsearch

Я пытаюсь запустить кластер Elasticsearch на Mesos через Marathon с контейнерами докеров. Поэтому я построил Docker image, который может запускаться на марафоне и динамически масштабироваться через интерфейс или API.

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

Дело в том, что Марафон решает, где (на котором ведется Мезос), узлы запускаются, поэтому с моей точки зрения не предсказуемо, если все данные доступны для «новых» узлов при перезагрузке, когда я пытаюсь сохранить данные для хостов Docker через объемы докеров.

Единственное, что приходит на ум, являются:

  • Использование распределенной файловой системы, как HDFS или NFS, с установленными объемами либо на хосте Докер или самих изображений Докер. Тем не менее, это оставит вопрос о том, как загружать все данные во время запуска нового кластера, если «старый» кластер имел, например, 8 узлов, а новый имеет только 4.

  • Использованиеиз Elasticsearch для сохранения в общий диск где-то в сети. Я предполагаю, что у этого будут штрафы за производительность ...

Есть ли другой способ приблизиться к этому? Есть ли рекомендации? К сожалению, я не нашел хорошего ресурса по этой теме. Заранее большое спасибо.

+1

Elasticsearch и NFS не самые лучшие друзья ;-). Вы не хотите запускать свой кластер в NFS, он слишком медленный, и Elasticsearch работает лучше, если скорость хранения лучше. Если вы представите сеть в этом уравнении, вы попадете в беду. Я понятия не имею о Докере или Мезосе. Но я точно рекомендую против NFS. Используйте моментальный снимок/восстановление. –

+0

@AndreiStefan Большое спасибо за понимание NFS.Действительно ли API-интерфейс моментального снимка - это способ, если у нас есть 100 ГБ данных? – Tobi

+0

Последующие снимки являются инкрементальными. Итак, первый снимок займет некоторое время, но остальные снимки должны занимать меньше места и меньше времени. 100 ГБ данных в общей сложности или 100 ГБ только для праймериз (без реплик)? Также обратите внимание, что «incremental» означает инкрементное значение на уровне файла, а не уровень документа. –

ответ

1

Elasticsearch и NFS не самые лучшие друзья ;-). Вы не хотите запускать свой кластер в NFS, он слишком медленный, и Elasticsearch работает лучше, если скорость хранения лучше. Если вы представите сеть в этом уравнении, вы попадете в беду. Я понятия не имею о Докере или Мезосе. Но я точно рекомендую против NFS. Используйте моментальный снимок/восстановление.

Первый снимок займет некоторое время, но остальные снимки должны занимать меньше места и меньше времени. Также обратите внимание, что «incremental» означает инкрементное значение на уровне файла, а не уровень документа.

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

+0

Еще раз спасибо за вашу помощь! – Tobi

0

Лучший способ запустить Elasticsearch на Mesos - использовать специализированную среду Mesos. Первое усилие в этой области - https://github.com/mesosphere/elasticsearch-mesos. В настоящее время разрабатывается проект, который находится в стадии разработки: https://github.com/mesos/elasticsearch. Я не знаю, что такое статус, но вы можете попробовать.

+0

Спасибо за ваш ответ. Первый проект, который вы связали, более или менее мертв, второй проект, который вы связали, в настоящее время находится в активном развитии IMHO ... Я не вижу точно, где последний «лучше», чем работает с изображениями Докера в марафоне, но, возможно, вы можете дать некоторые подробности об этом. Я думаю, что гораздо более гибкий (и легкий) запуск марафона относительно масштабирования и т. Д., Но это только мой личный взгляд. – Tobi

+0

Наличие специализированной структуры дает вам большую гибкость в течение всей жизни ваших задач (= elasticsearch nodes) и позволяет управлять ими вместе как группа. Например, вы можете иметь набор проверок и автомасштабировать свой ансамбль elasticsearch. Вы правы в статусах обоих проектов, однако я бы посоветовал вам использовать второй и в конечном итоге внести свой вклад в это:) – rukletsov