А чем не устроил Cinder?
Я почему спрашиваю, потому что мне больше нравится использовать OpenStack «из коробки» (как впрочем и многие продукты).
А выбор Ubuntu в качестве примера был взят только потому, что:
Большинство «новичков» используют Ubuntu как дистрибутив для ознакомления с Linux, соответственно для них это будет немного ближе.
На CentOS установка RabbitMQ производится более чем в одну команду. А это может быть камнем преткновения для некоторых из пользователей. Не хотелось на этом акцентировать внимание.
Под рукой были образы только Ubuntu Server и CentOS 7 (который с GUI`ёвым установщиком). Собственно мышки под рукой не оказалось. Вот так вот просто это определило судьбу моего тестового стенда.
Да вам не за что извиняться. Я просто так и не понял что конкретно вы имели в виду:
Вы полностью отказались от HDD на серверах с OpenStack
Вы хотели разместить виртуальные диски Cinder`а в хранилище SAN
Что-то ещё
?
Можете чуть подробнее рассказать?
Следующая статья будет изрядно длинная и, по большому счёту, это будет больше похоже на перевод официальной документации с моими комментариями.
Подумываю разбить её на несколько, но пока не уверен, что это будет правильно.
Т.е. если я правильно Вас понял, то у Вас будут храниться данные сразу в двух местах: неделя-две в ES и + hadoop для текущих и остальных, так? Решение интересное. Запомню на будущее.
Если не секрет, в сторону чего нового смотрите?
Есть ли какая-либо cache-прослойка между дашбордами или клиентом? Мне кажется это изрядно бы разгрузило нагрузку на бд.
Есть ли распараллеливание шардами нагрузки между несколькими хостами?
Так однозначно сложно ответить. Всё зависит от количества Data-нод и производительности этих нод.
Чем больше потоков, тем быстрее.
На тестовом стенде с 2мя Data-нодами тянет 17M (~2Gb) логов в день. Каждая нода по 2 ядра и 2Гб. 2 недели логов тянет хорошо, но начинает напрягаться HDD. Но с учётом того, что ресурсы общие с ещё кучей VM, то весьма хороший результат.
В прочем сложно судить: загружаемые данные более или менее одинаковы.
Всё же дело в плагине. Я кроме mobz/elasticsearch-head плагины не включал (даже shield ибо $$$), но новые master и data машины легко входят в кластер. Licence — сложно даже плагином назвать. Насколько я понял, это «билет в платную поддержку». Не стал углубляться в этом вопросе.
Не знаю насколько это правильно, писать комментарий к посту 2х летней давности, но как сейчас дела обстоят с live-migration в OpenStack? Есть ли способ избежать NFS?
Обработчик filter в logstash имеет свойство жутко «выжирать» CPU, поэтому пришлось его расположить отдельно. Так падение даже всех фильтров не сказывается на заборе логов, только на их отображении.
RabbitMQ как балансировщик нагрузки между фильтрами + очереди. Как-то так. Альтернативу предложили в первом комментарии, будем смотреть.
Заказчик хочет, чтоб система смогла расти от 100мб логов в день, до 1Тб в час (вот ума не приложу где они всё это собираются хранить), так что вариант с Docker не совсем подходит.
К сожалению, «клиент всегда прав». К тому же это логи с 1000 хостов (у клиента), поэтому одно из сообщений потерять может быть весьма критично. Хотя решение на Syslog могло бы быть симпатичным.
Я почему спрашиваю, потому что мне больше нравится использовать OpenStack «из коробки» (как впрочем и многие продукты).
А выбор Ubuntu в качестве примера был взят только потому, что:
Большинство «новичков» используют Ubuntu как дистрибутив для ознакомления с Linux, соответственно для них это будет немного ближе.
На CentOS установка RabbitMQ производится более чем в одну команду. А это может быть камнем преткновения для некоторых из пользователей. Не хотелось на этом акцентировать внимание.
Под рукой были образы только Ubuntu Server и CentOS 7 (который с GUI`ёвым установщиком). Собственно мышки под рукой не оказалось. Вот так вот просто это определило судьбу моего тестового стенда.
Вы полностью отказались от HDD на серверах с OpenStack
Вы хотели разместить виртуальные диски Cinder`а в хранилище SAN
Что-то ещё
?
Можете чуть подробнее рассказать?
Подумываю разбить её на несколько, но пока не уверен, что это будет правильно.
В продакшене лучше конечно же такого не делать.
Есть ли какая-либо cache-прослойка между дашбордами или клиентом? Мне кажется это изрядно бы разгрузило нагрузку на бд.
Есть ли распараллеливание шардами нагрузки между несколькими хостами?
Это я всё больше для себя узнаю :)
Чем больше потоков, тем быстрее.
На тестовом стенде с 2мя Data-нодами тянет 17M (~2Gb) логов в день. Каждая нода по 2 ядра и 2Гб. 2 недели логов тянет хорошо, но начинает напрягаться HDD. Но с учётом того, что ресурсы общие с ещё кучей VM, то весьма хороший результат.
В прочем сложно судить: загружаемые данные более или менее одинаковы.
RabbitMQ как балансировщик нагрузки между фильтрами + очереди. Как-то так. Альтернативу предложили в первом комментарии, будем смотреть.
Заказчик хочет, чтоб система смогла расти от 100мб логов в день, до 1Тб в час (вот ума не приложу где они всё это собираются хранить), так что вариант с Docker не совсем подходит.
Только вышел с больничного, ближайшие пару дней напишу man. А там уже можно будет и Chef-рецепты описать.