Какая рекомендуемая настройка для кластера Elasticsearch, который содержит данные в масштабе ТБ и выше?

Я автор Apache Mesos Elasticsearch Framework. Я бы порекомендовал вам попробовать все эти подходы и выбрать тот, с которым у вас больше всего опыта. А когда дело доходит до производительности, убедитесь, что у вас есть требования к производительности, а затем проведите тесты. Есть и другие вещи, которые следует учитывать. Кого я коснусь в вопросах.

1. Elasticsearch Framework для мезо является наиболее устойчивым из этих четырех вариантов. Узлы Elasticsearch запускаются как задачи Mesos. Если какая-либо из задач терпит неудачу (аппаратный или программный сбой), они перезапускаются где-нибудь в другом месте кластера Mesos. Если вы хотите добавить узлы (для увеличения производительности) или удалить узлы (для уменьшения использования ресурсов), это так же просто, как отправить однострочный запрос curl. Данные очень безопасны. Конфигурация по умолчанию (может быть переопределена) реплицирует все данные на все узлы. Таким образом, кластер может пережить катастрофическое событие и остаться с одним узлом без потери данных. Вы также можете использовать любой подключаемый модуль томов Docker для записи данных на внешний том, чтобы, если задачи умирают, данные по-прежнему содержатся в облачных томах. Есть еще несколько функций, посетите веб-сайт. Также посмотрите видео на YouTube-канале Container Solutions. Мы также разрабатываем инструменты, упрощающие разработку, см. minimesos.

2. Это вполне разумно, но вы должны подумать, как бы вы организовали свой кластер. А что произойдет, если один или несколько контейнеров умрут? Сможете ли вы перенести эту потерю? Если да, то это может быть лучшим вариантом для DevOps (т.е. вы можете реплицировать и тестировать кластер, который выглядит как настоящий).

3. Это единственный вариант, против которого я был бы. Это было бы хорошо для разработки, но вы столкнулись бы с серьезной проблемой производительности в производственной среде. У вас потенциально может быть виртуальная машина полного стека (бродячая) внутри другой виртуальной машины (облака). Накладные расходы не нужны. Ссылка 1, Ссылка 2.

4. Это официальный метод, рекомендованный Elastic, который, вероятно, обеспечит максимальную производительность для данной конфигурации оборудования. Но поскольку это статические развертывания: а) большая часть ресурсов машины будет потрачена впустую (неиспользуемая ОЗУ / ЦП и т. Д.), Б) существует значительная (особенно в крупных организациях!) Задержка в предоставлении новых экземпляров (по сравнению с одним api) и c) в случае сбоя экземпляра он не будет заменен и не будет исправлен, пока кто-то его не исправит (сравните с автоматическим переключением на другой ресурс). Если ваши требования к Elasticsearch исправлены, вам не нужна гибкость, подобная DevOps, и вы не возражаете против простоя, то это, вероятно, самый простой метод (но убедитесь, что вы правильно настроили конфигурацию ES!).

Так что, если бы это был я, то я бы подумал о докерированной установке для тестирования, небольших POC и, возможно, очень небольших производственных задачах. Что-то большее, тогда я бы каждый раз выбирал вариант Mesos Elasticsearch.

У моей компании есть более или менее те же вопросы, но, возможно, чуть позже, когда дело доходит до POC и т. Д.

В настоящее время мы запускаем 3-узловой кластер ES на Mesos 0.27.1 через Marathon с собственный образ Docker. Мы монтируем хост-тома (пути) в контейнеры, что означает, что вы можете смонтировать, например, том Ceph на хосте Mesos Slave. Но это как-то довольно ручной процесс. На мой взгляд, самая большая проблема - это безопасность данных, потому что по умолчанию данные хранятся только на самом хосте, и поведение, когда приложение масштабируется в Marathon (должны использоваться ограничения, так что только один узел запускается на Mesos Раб и т. Д.).

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

Я скоро еще раз попробую фреймворк Mesos. Мне особенно нравится возможность установить --externalVolumeDriver, что означало бы, что теперь мы, вероятно, можем использовать драйвер тома Docker RBD (поскольку мы используем Ceph) ...