Тогда же нужно добавить, что данных в таком кластере в два раза меньше. Или памяти нужно в 2 раза больше. Так что выводы по стоимости становятся не такими однозначными.
Лучшая отказоустойчивость — чем больше узлов вы используете в своем кластере, тем надежнее будет ваш кластер. Например, если вы запускаете свой набор данных в кластере из 3 узлов, а один узел деградирует, это 1/3 вашего кластера не работает; но если вы запускаете свой набор данных в кластере из 9 узлов и один узел деградирует, это всего лишь 1/9 вашего кластера не работает.
Наверное надо уточнить что для SSD нужно /loki/api/v1/push проксировать на write ноды. Всё остальное на read.
По поводу retention. Я настроил lifecycle policy на AWS S3 так как я могу его там настроить в зависимости от tenant. Это мне чем то грозит? Кроме запросов в никуда?
теперь посчитайте стоимость датацентра (на самом деле двух если нужен drp) или места под сервера в чужом дц, каналы, сетевое оборудование, ups... SAN если нужен.. Обслуживание..
Один сервер в вакууме дешевле облака.. если что то больше, то надо считать
Тем хуже. Откуда данный попадают в hadoop. есть ли гарантия, что не прилетит сообщение, которое сработает? По мне основная проблема этой уязвимости, что непонятно где и как это может аукнутся.
Как пример в одном стороннем компоненте индексатор почты сделан с помощью эластика с проблемной версией log4j.
Этот вариант не работает в случае использования бекендов типа database с static role и ttl.
Если бизнес логика вынесена на уровень проксирования то апач вам в руки.
не читабельность конфигов haproxy слишком преувеличена.
А так вы увеличили сложность через уменьшение надёжности.
У меня сложилось впечатление, что nginx там ещё что то делает. Типа статику раздаёт. Если это не так то...
ты точно читал причину появления haproxy?
исчезнет двойное проксирование. Улучшится логика работы. Увеличится гибкость.
nginx и haproxy надо местами поменять и всё будет хорошо.
Мы сделали через
--cache-stack=kubernetes
-Djgroups.dns.query=dns-name
dns-name возвращает несколько A записей.
После долгих экспериментов мы остановились на ngnix unit вместо php-fpm в контейнерах.
Тогда же нужно добавить, что данных в таком кластере в два раза меньше. Или памяти нужно в 2 раза больше. Так что выводы по стоимости становятся не такими однозначными.
Лучшая отказоустойчивость — чем больше узлов вы используете в своем кластере, тем надежнее будет ваш кластер. Например, если вы запускаете свой набор данных в кластере из 3 узлов, а один узел деградирует, это 1/3 вашего кластера не работает; но если вы запускаете свой набор данных в кластере из 9 узлов и один узел деградирует, это всего лишь 1/9 вашего кластера не работает.Ну во всём мире это ухудшение отказоустойчивости.
Спасибо. Поиграемся.
Наверное надо уточнить что для SSD нужно /loki/api/v1/push проксировать на write ноды. Всё остальное на read.
По поводу retention. Я настроил lifecycle policy на AWS S3 так как я могу его там настроить в зависимости от tenant. Это мне чем то грозит? Кроме запросов в никуда?
я бы посмотрел на такие расчёты.
теперь посчитайте стоимость датацентра (на самом деле двух если нужен drp) или места под сервера в чужом дц, каналы, сетевое оборудование, ups... SAN если нужен..
Обслуживание..
Один сервер в вакууме дешевле облака.. если что то больше, то надо считать
не надо мне рассказывать про аудиты.
Я предпочитаю верить что моя система уязвима и патчить её чем наоборот
Физически от чего изолирована ваша сеть? Если вы работаете со сферическим конём в вакууме то да вам ничего бояться. Но мне что то не верится
Вы слишком самоуверены
Ну так и кипиш такой только от того, что ни кто не знает где стрельнет и надо выбирать тратить время на анализ или на обновление.
Ну атаки изнутри это гораздо опастнее и не факт, что легче ловится.
Тем хуже. Откуда данный попадают в hadoop. есть ли гарантия, что не прилетит сообщение, которое сработает? По мне основная проблема этой уязвимости, что непонятно где и как это может аукнутся.
Как пример в одном стороннем компоненте индексатор почты сделан с помощью эластика с проблемной версией log4j.