Комментарии 18
интересно, но мало ...
какие планы на развитие технологий есть? вы просто следуете за желаниями клиентов и всё? а что-нибудь принципиально новое клиентам можете/хотите предложить?
Я бы не сказал, что это можно назвать «просто следуете за желаниями клиентов». Тут ведь всё довольно сложно: есть пожелания по конкретным фичам, а есть большой блок, связанный с определением потребностей клиентов, которые они и сами не всегда могут осознавать и связывать с Kubernetes-платформой, — и насколько то, что рождается в результате выявления подобных скрытых потребностей, можно назвать «просто следуете за желаниями клиентов» (это вопрос о терминологии, по сути)? Из интересного — есть вот такое, например — система виртуализации: https://habr.com/ru/companies/flant/articles/715426. Просто «принципиально новое» — это из какой категории (тут тоже вопрос о терминологии)?:) Из разряда «было колесо — а сделали космолет и заселили Марс» или что-то попроще — вроде того, на что я дал ссылку?
вы просто следуете за желаниями клиентов и всё?
Как минимум есть ещё фактор «наши собственные желания» в смысле подхода к инфраструктуре. Например, в этой статье упомянут проект «своего докера», который был актуален для того, чтобы делать хостинг можно было удобно и эффективно — для нас, не для клиента, у которого «сайт просто работает» (но быстро, стабильно и так далее).
Аналогично: появление Kubernetes ответило на те наши внутренние потребности в смысле эксплуатации (управления, автоматизации, …) инфраструктуры, что уже сформировались на тот момент (и у нас, и у сообщества). Поэтому запрыгнуть в этот вагон было очевидным ходом [вместо развития своего изобретения очень ограниченными силами] — благо, тут и Open Source, и Linux, и т.п. А теперь, если посмотреть на эту нашу внутреннюю кухню (что там в инфраструктуре крутится) с другой стороны, клиентской, то именно она и позволила обеспечить нечто «принципиально новое»: быстрые выкаты, отказоустойчивость и т.п. — по сравнению с технологиями, которые были до этого.
А если смотреть на других клиентов — уже не покупателей готовой услуги, а на пользователей продукта, авторами которого мы стали, — то как раз Deckhouse стремится принести «принципиально новый» опыт работы с очень сложным Kubernetes, делая её максимально доступной. Но да, это по-прежнему Kubernetes, потому что в настоящий момент индустриальный стандарт. Уж тем более — для enterprise, который вообще не такой быстрый, чтобы уже сегодня думать о следующем.
Кстати почему мимир а не хайповый виктория метрикс?
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
С учетом этих нюансов, мы сделали выбор в пользу Mimir.
Есть сравнение Mimir и Victoriametrics - https://victoriametrics.com/blog/mimir-benchmark/
Резюме
В этом бенчмарке было два раунда тестов.
В первом раунде Miami и Victoria Metrics работали с одинаковой нагрузкой и на одном и том же оборудовании. Контрольными результатами были следующие:
VictoriaMetrics использует на 1,7 процессора меньше при той же рабочей нагрузке;
VictoriaMetrics использует в 5 раз меньше оперативной памяти для того же количества активных серий;
VictoriaMetrics использует в 3 раза меньше места для хранения данных, собранных в течение 24 часов во время тестирования.
Во втором раунде нагрузка была увеличена в 5 раз с использованием того же оборудования. У Mimir было недостаточно ресурсов, чтобы справиться с нагрузкой, поэтому была доступна только статистика VictoriaMetrics.
Привет! Это отличная статья, и ребята проделали большую работу. Но всегда есть нюансы. Мы еще не проводили детальный анализ статьи, но есть пара моментов, которые делают ее не так однозначной:
Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0. Версия 2.4 внесла существенные изменения, которые, по нашим замерам, сокращают потребление ресурсов на 30-40%.
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В Mimir данные хранятся на дисках vmStorage, а в Mimir используется S3. Например, при использовании replication factor 3, в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства. Это основано на реальных данных нашего проекта, где мы используем Ceph S3 с replication factor 3.
В статье проводится бенчмарк в течение одних суток, но вряд ли Mimir и Victoriametrics используются для хранения данных такого маленького периода. Кроме того, учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
* п3 В Vm данные хранятся на дисках vmStorage.
Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0
Версии VM и Mimir были актуальными на момент бенчмарка. Вы тестировали оба решения или выбор был сделан только на основе статей и документации?
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В статье достаточно много времени уделяется object storage. Но я не понимаю как использование S3 может в положительном ключе влиять на производительность по сравнению с более быстрыми и доступными локальными дисками?
в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства
Вы имеете в виду 3.5TB были сжаты в 3TB? Если это так, то в VM можете ожидать 1TB согласно цифрам из бенчмарка.
В статье проводится бенчмарк в течение одних суток
Валидное замечание. Время бенчмарка, к сожалению, ограничено его стоимостью.
учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
Аналогично работает слияние и рекомпрессия данных в VictoriaMetrics. Данные могут сжиматься вплоть до 1 месяца.
Версии VM и Mimir были актуальными на момент бенчмарка. Вы тестировали оба решения или выбор был сделан только на основе статей и документации?
Да, вы правы, я упустил дату статьи.
На тот момент, когда мы принимали решение, Mimir еще не существовал, и мы выбирали между Victoria Metrics и Cortex. В процессе мы изучили документацию, провели различные тесты, включая нагрузочные, и изучили кодовую базу основных претендентов. При сопоставимых результатах по скорости ответа и записи, и потреблению ресурсов для нас решающим фактором стало отсутствие механизма решардирования данных в Victoria Metrics.
В статье достаточно много времени уделяется object storage. Но я не понимаю как использование S3 может в положительном ключе влиять на производительность по сравнению с более быстрыми и доступными локальными дисками?
Недостаточно, там не указаны значения для задержки для запросв и размера канала, хотя и говорится об использовании Google Cloud Storage. В случае с Mimir – S3 это ключевой компонент, аналогично дискам victoria metrics. Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?
Вы имеете в виду 3.5TB были сжаты в 3TB? Если это так, то в VM можете ожидать 1TB согласно цифрам из бенчмарка.
Нет, смотрите, для обеспечения высокой доступности данных необходимо их хранить в нескольких копиях. В случае с VM данные записываются на несколько vmStorage, а в случае с Mimir - на несколько ingester. Важный момент заключается в том, что данные, записанные в несколько vmStorage, остаются там навсегда, тогда как ingester выгружает их в S3, после чего происходит дедубликация данных (три блока сливаются в один). Чтобы обеспечить высокую доступность данных, необходима репликация на уровне хранения в S3. Поскольку мы используем собственный S3, вопрос репликации остается актуальным для нас. В итоге, для хранения 3 ТБ метрик в S3 мы используем 3,5 ТБ дискового пространства с учетом трехкратной репликации.
Аналогично работает слияние и рекомпрессия данных в VictoriaMetrics. Данные могут сжиматься вплоть до 1 месяца.
Да, но есть нюансы. Как я писал выше, данные в VM хранятся на локальных дисках, и там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один. Возможен только вертикальный мердж данных по времени.
Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?
Но при каких условиях S3 будет быстрее для запросов на чтение по сравнению с local storage?
там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один
Вы можете сказать сколько в среднем байт на точку данных требуется в вашей инсталляции? Я думаю, так будет проще рассуждать про сжатие.
Но при каких условиях S3 будет быстрее для запросов на чтение по сравнению с local storage?
Если мы сравниваем одну и туже систему, то ответ будет – никогда. Если сравниваем разные системы, то зависит от систем. Мое замечание заключалось в том, что если сравниваешь производительность двух систем и одна хранит данные на локальном SSD, а вторая хранит данные в S3 с letensy 1 сек, то вторая будет заведомо в проигрышной позиции.
Вы можете сказать сколько в среднем байт на точку данных требуется в вашей инсталляции? Я думаю, так будет проще рассуждать про сжатие.
У нас нет такой информации, мы никогда не замеряли это. И это не супер просто посчитать, так как нет данных по количеству точек в mimir.
В общем, что бы ответить на все эти вопросы, мы думаем сделать обширный тест, продолжительностью несколько недель, с замерами на разных этапах и красивыми картинками, и конечно же, опубликовать результаты.
Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/.
Рекомендую читателям ознакомится и с ответом: https://valyala.medium.com/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87
Можете подробнее рассказать как именно это влияет на вас?
На собесе продолжаете brainfuck спрашивать?)
Флант, вы молодцы. Но вот бы вы ещё дизайнера поменяли) Логотипы ваших продуктов и дизайн сайта как-то уж слишком просты и пресны. А хочется, чтобы ваш бренд был узнаваем во всем мире и привлекал внимание даже просто визуально)
15 лет «Фланта»: переход от сервисной компании к продуктовой, покупка внешнего продукта, вера в Open Source