SM
Придётся. И через год придётся.
когда версия 7 будет?
Size: a a a
2018 June 09
EG
Причешу - выкину
EG
когда версия 7 будет?
Лицуха на год
EG
Базовая
SM
Лицуха на год
точно. забыл совсем
MA
и после обновления же надо будет это еще раз делать?
необходимость реинсталла присутствует
MP
и после обновления же надо будет это еще раз делать?
Да там на раз все делается. Пару раз попробуешь, потом за минуты будешь ставить
SM
Да там на раз все делается. Пару раз попробуешь, потом за минуты будешь ставить
значит завтра на тестовом попробую)
2018 June 10
SM
никак не могу найти доку как настроить кодек сжатия данных в эластике. может кто направить на путь истинный?
2018 June 12
MP
никак не могу найти доку как настроить кодек сжатия данных в эластике. может кто направить на путь истинный?
увы, сами еще с эти мне разбирались. Но стоит в планах на ближайшее время
MP
значит завтра на тестовом попробую)
удалось раскатать лицуху?
SM
удалось раскатать лицуху?
Я решил что выходные для отдыха) сначала сделаю сжатие, а потом уже и лицуху)
MP
И немного о нашем кластере:
Мы используем кластер из 7 нод с архитектурой hot-warm:
1) две hot дата ноды с 24 ядрами 400Гб оперативки и 1,6Тб места на 15К дисках. На них мы храним оперативные данные, т.е. те индексы в которые идет индексация в данный момент они же как првидло являються и востребованными на чтение, либо не очень объемные но востребованые для чтения индексы.
2) две warm дата ноды с 24 ядрами и 100Гб оперативки и подключенной не самой быстрой хранилкой на 36Тб (поделена на два луна по 18ТБ и каждый лун презентован отдельно каждой warm ноде)
3) одна нода под машин ленинг с 24 ядрами и 400гБ оперативки, пока к сожалению не хватает времени плотно заняться МЛ и нагрузить джобами сервер. Сейчас крутиться пяток джоб, но они довольно легкие.
4) одна мастер нода, виртуалка с 12 ядрами и 20Гб оперативки. НА ней же живет кибана (три штуки), редис на 6гб (используеться как буфер перед логсташем), логсташ который в котором порядка 30 jdbc инпутов, нетфлоу, и еще несколько инпутов из редиса, сумарный рейт событий в нагруженной время около 3000к в секунду с пиками до 8К в сек.
5) одна ингест нода, виртуалка с 4 ядрами и 10Гб оперативки. Логсташ в нее аутпутит все данные.
Три кибаны, смотрят в сторону nginx который раундробином разбрасывает трафик между четырьмя дата нодами.
Собираю логи access web логи с сайтов, php и другие логи приложений, с помощью jdbc собираю статистику и мониторинг с более чем 10ти баз данных, нетфлоу с нескольких железок, логи с haproxy, так же собираю результат работы системы ossec, и есть еще с десяток индексов с данными распарсенными из большого количества xml файлов.
Все это чистится/ роитруется с помощью curator.
Сейчас данных в кластере 8Тб, раньше было больше, но пришлось почистить так как кластер плохо себя чуствовал (это было до введения hot нод). Теперь вот снова наблюдаю за увелеичением хранимых данных и поведением кластера, интересно на сколько выгодным окажеться введение hot нод.
В планах, зарезервировать логсташ, посмотреть в сторону сжатия данных на warm нодах, углубить знания по ML и нагрузить мл ноду полезной нагрузкой.
Мы используем кластер из 7 нод с архитектурой hot-warm:
1) две hot дата ноды с 24 ядрами 400Гб оперативки и 1,6Тб места на 15К дисках. На них мы храним оперативные данные, т.е. те индексы в которые идет индексация в данный момент они же как првидло являються и востребованными на чтение, либо не очень объемные но востребованые для чтения индексы.
2) две warm дата ноды с 24 ядрами и 100Гб оперативки и подключенной не самой быстрой хранилкой на 36Тб (поделена на два луна по 18ТБ и каждый лун презентован отдельно каждой warm ноде)
3) одна нода под машин ленинг с 24 ядрами и 400гБ оперативки, пока к сожалению не хватает времени плотно заняться МЛ и нагрузить джобами сервер. Сейчас крутиться пяток джоб, но они довольно легкие.
4) одна мастер нода, виртуалка с 12 ядрами и 20Гб оперативки. НА ней же живет кибана (три штуки), редис на 6гб (используеться как буфер перед логсташем), логсташ который в котором порядка 30 jdbc инпутов, нетфлоу, и еще несколько инпутов из редиса, сумарный рейт событий в нагруженной время около 3000к в секунду с пиками до 8К в сек.
5) одна ингест нода, виртуалка с 4 ядрами и 10Гб оперативки. Логсташ в нее аутпутит все данные.
Три кибаны, смотрят в сторону nginx который раундробином разбрасывает трафик между четырьмя дата нодами.
Собираю логи access web логи с сайтов, php и другие логи приложений, с помощью jdbc собираю статистику и мониторинг с более чем 10ти баз данных, нетфлоу с нескольких железок, логи с haproxy, так же собираю результат работы системы ossec, и есть еще с десяток индексов с данными распарсенными из большого количества xml файлов.
Все это чистится/ роитруется с помощью curator.
Сейчас данных в кластере 8Тб, раньше было больше, но пришлось почистить так как кластер плохо себя чуствовал (это было до введения hot нод). Теперь вот снова наблюдаю за увелеичением хранимых данных и поведением кластера, интересно на сколько выгодным окажеться введение hot нод.
В планах, зарезервировать логсташ, посмотреть в сторону сжатия данных на warm нодах, углубить знания по ML и нагрузить мл ноду полезной нагрузкой.
MP
Вот немного инфы о нашем скромном кластере ))))
EG
Скромном? Я тоже так хочу!
SM
И немного о нашем кластере:
Мы используем кластер из 7 нод с архитектурой hot-warm:
1) две hot дата ноды с 24 ядрами 400Гб оперативки и 1,6Тб места на 15К дисках. На них мы храним оперативные данные, т.е. те индексы в которые идет индексация в данный момент они же как првидло являються и востребованными на чтение, либо не очень объемные но востребованые для чтения индексы.
2) две warm дата ноды с 24 ядрами и 100Гб оперативки и подключенной не самой быстрой хранилкой на 36Тб (поделена на два луна по 18ТБ и каждый лун презентован отдельно каждой warm ноде)
3) одна нода под машин ленинг с 24 ядрами и 400гБ оперативки, пока к сожалению не хватает времени плотно заняться МЛ и нагрузить джобами сервер. Сейчас крутиться пяток джоб, но они довольно легкие.
4) одна мастер нода, виртуалка с 12 ядрами и 20Гб оперативки. НА ней же живет кибана (три штуки), редис на 6гб (используеться как буфер перед логсташем), логсташ который в котором порядка 30 jdbc инпутов, нетфлоу, и еще несколько инпутов из редиса, сумарный рейт событий в нагруженной время около 3000к в секунду с пиками до 8К в сек.
5) одна ингест нода, виртуалка с 4 ядрами и 10Гб оперативки. Логсташ в нее аутпутит все данные.
Три кибаны, смотрят в сторону nginx который раундробином разбрасывает трафик между четырьмя дата нодами.
Собираю логи access web логи с сайтов, php и другие логи приложений, с помощью jdbc собираю статистику и мониторинг с более чем 10ти баз данных, нетфлоу с нескольких железок, логи с haproxy, так же собираю результат работы системы ossec, и есть еще с десяток индексов с данными распарсенными из большого количества xml файлов.
Все это чистится/ роитруется с помощью curator.
Сейчас данных в кластере 8Тб, раньше было больше, но пришлось почистить так как кластер плохо себя чуствовал (это было до введения hot нод). Теперь вот снова наблюдаю за увелеичением хранимых данных и поведением кластера, интересно на сколько выгодным окажеться введение hot нод.
В планах, зарезервировать логсташ, посмотреть в сторону сжатия данных на warm нодах, углубить знания по ML и нагрузить мл ноду полезной нагрузкой.
Мы используем кластер из 7 нод с архитектурой hot-warm:
1) две hot дата ноды с 24 ядрами 400Гб оперативки и 1,6Тб места на 15К дисках. На них мы храним оперативные данные, т.е. те индексы в которые идет индексация в данный момент они же как првидло являються и востребованными на чтение, либо не очень объемные но востребованые для чтения индексы.
2) две warm дата ноды с 24 ядрами и 100Гб оперативки и подключенной не самой быстрой хранилкой на 36Тб (поделена на два луна по 18ТБ и каждый лун презентован отдельно каждой warm ноде)
3) одна нода под машин ленинг с 24 ядрами и 400гБ оперативки, пока к сожалению не хватает времени плотно заняться МЛ и нагрузить джобами сервер. Сейчас крутиться пяток джоб, но они довольно легкие.
4) одна мастер нода, виртуалка с 12 ядрами и 20Гб оперативки. НА ней же живет кибана (три штуки), редис на 6гб (используеться как буфер перед логсташем), логсташ который в котором порядка 30 jdbc инпутов, нетфлоу, и еще несколько инпутов из редиса, сумарный рейт событий в нагруженной время около 3000к в секунду с пиками до 8К в сек.
5) одна ингест нода, виртуалка с 4 ядрами и 10Гб оперативки. Логсташ в нее аутпутит все данные.
Три кибаны, смотрят в сторону nginx который раундробином разбрасывает трафик между четырьмя дата нодами.
Собираю логи access web логи с сайтов, php и другие логи приложений, с помощью jdbc собираю статистику и мониторинг с более чем 10ти баз данных, нетфлоу с нескольких железок, логи с haproxy, так же собираю результат работы системы ossec, и есть еще с десяток индексов с данными распарсенными из большого количества xml файлов.
Все это чистится/ роитруется с помощью curator.
Сейчас данных в кластере 8Тб, раньше было больше, но пришлось почистить так как кластер плохо себя чуствовал (это было до введения hot нод). Теперь вот снова наблюдаю за увелеичением хранимых данных и поведением кластера, интересно на сколько выгодным окажеться введение hot нод.
В планах, зарезервировать логсташ, посмотреть в сторону сжатия данных на warm нодах, углубить знания по ML и нагрузить мл ноду полезной нагрузкой.
Зачем три кибаны?
MP
Зачем три кибаны?
одна для внутренних юзеров (в режиме рид онли от x-pack), вторая для внешних (в режиме рид онли от x-pack), третья для управления всем хозяйством.
MP
Я решил что выходные для отдыха) сначала сделаю сжатие, а потом уже и лицуху)
сжатием озаботился чтобы место экономить или просто в качестве опытов пока?
SM
одна для внутренних юзеров (в режиме рид онли от x-pack), вторая для внешних (в режиме рид онли от x-pack), третья для управления всем хозяйством.
Однако. О! Задам тебе вопрос в который не врубить мне. У вас кибана на Https?