Turn on multi-session support это про разные аккаунты в разных табах? Уже ввели. Имя бакета так себе аргумент.. вернее даже совсем не аргумент. тестирование создание eks... ну да надо... но тестировать всё равно надо...
А про то что цель амазона это страдания пользователей вообще бред. Цель амазона зарабатывание денег и отправка пользователей к консультантам в цель не входит.
Тогда же нужно добавить, что данных в таком кластере в два раза меньше. Или памяти нужно в 2 раза больше. Так что выводы по стоимости становятся не такими однозначными.
Лучшая отказоустойчивость — чем больше узлов вы используете в своем кластере, тем надежнее будет ваш кластер. Например, если вы запускаете свой набор данных в кластере из 3 узлов, а один узел деградирует, это 1/3 вашего кластера не работает; но если вы запускаете свой набор данных в кластере из 9 узлов и один узел деградирует, это всего лишь 1/9 вашего кластера не работает.
Наверное надо уточнить что для SSD нужно /loki/api/v1/push проксировать на write ноды. Всё остальное на read.
По поводу retention. Я настроил lifecycle policy на AWS S3 так как я могу его там настроить в зависимости от tenant. Это мне чем то грозит? Кроме запросов в никуда?
ха ха ха. оставим Макиавелли в стороне.
Ты знаешь как сделать всем пользователям удобно??? Что ты тогда делаешь на хабре? таких как ты ждут в самых больших комппаниях мира.
Turn on multi-session support это про разные аккаунты в разных табах? Уже ввели.
Имя бакета так себе аргумент.. вернее даже совсем не аргумент.
тестирование создание eks... ну да надо... но тестировать всё равно надо...
А про то что цель амазона это страдания пользователей вообще бред. Цель амазона зарабатывание денег и отправка пользователей к консультантам в цель не входит.
Ну во первых не мог.
Во вторых "можно Gigabyte привезти" и есть контакты это всё неопределённо.
Я тут более популярную систему жду полгода а дедлайны подходят
нет ни какой разницы.
Проблема не в цене. Проблема в доступности. Я не смог найти поставщика который продаст пару тройку серверов. x86 доступен здесь и сейчас
смотря что вам привычно. Мы на гравитрон и Ampere давно першли везде где могли. Исключение винда и ibm mq.
Такой доступный, что простым смертным не купить.
Этот вариант не работает в случае использования бекендов типа 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. Это мне чем то грозит? Кроме запросов в никуда?