Неудобно (хоть и не критично), что нужно использовать рестик или борг, вместо того чтобы "просто скопировать файлы"
Плюс к тому и рестик и борг делают дедуп в рамках одного бэкап-архива. Если у вас бэкап двух почти одинаковых БД, то дедупликации не будет (между ними). В случае с ФС дедеп применяется для всех записанных данных.
С другой стороны в borg/restic дедупликация со сжатием может более эффективная, чем дедупликация сжатых файлов на ФС. Так же при бэкапе боргом по сети сначала производится дедупликация (подсчет хэшей блоков), а потом передача измененных блоков данных. Это может быть полезно, так меньше нагружает сеть, она не будет узким местом при терабайтных бэкапах повторяющихся данных, ведь на удаленный сервер будут переданы только изменённые блоки.
Часто в проектах, выросших из маленьких, а не разработанных с нуля под хайлоад, так и бывает: ресурсов на то чтобы переделать "правильно" нет, разработчики пилят для бизнеса новые фичи, которые должны приносить больше денег. Изменить архитектуру невозможно, потому что на это нет ни ресурсов ни желания - все опасаются сломать поток денег. И все серьезные сдвиги в архитектуре происходят только по итогам факапов. А пока факап не случился - бывает и сессии пользователей хранят в базе mysql, постепенно доводя муську до инстанса в 256 ядер с терабайтом ОЗУ.
Бизнес выделит ресурсы на "переделать правильно" когда почувствует, что теряет деньги.
Очень похоже, но есть кардинальное различие: k8spacket использует pcap, то есть перехватывает каждый пакет и передает его в юзерспейс приложения для обработки. В связи с этим, боюсь на настоящих нагрузках такой мониторинг может потреблять больше CPU, чем сами приложения, которые он мониторит.
Если вы упираетесь в одно ядро на существующем редисе и при этом не хотите особо заморачиваться с шардированием редиса в несколько инстансов по разным ядрам - можно просто запустить бинарь keydb-server вместо redis-server на той же конфигурации, и доутилизировать другие ядра (если они есть конечно)
Остальное конечно требует исследований, однозначных ответов "кто лучше" конечно не существует.
Из документации: The base algorithm used to map keys to hash slots is the following (read the next paragraph for the hash tag exception to this rule) HASH_SLOT = CRC16(key) mod 16384
На графиках видно 3 нагруженных мастера (один из них действительно чуть менее нагружен, чем два других) и 6 почти бездействующих реплик.
Шардинг по хэшу ключа позволяет как-то более или менее равномерно распределить ключи между шардами - количественно, но не частоту обращений к ним.
Вероятно есть какие-то ключи, которые заметно более популярны, чем какие-то другие. Или значения ключей заметно большего размера.
Можно пораспределять слоты между шардами (мастерами), как-то их подвигать, чтобы выровнять нагрузку на мастеры. Но я большого смысла не вижу, будут другие ключи - и картинка поменяется.
Использовали 6.3.1 , и она показала лучшую производительность, чем редис 6.0.2 Может не на ядро, но в совокупности на том же железе сервис стал работать лучше. Про issue хороший поинт, может имеет смысл откатиться на 6.2.2, но на данный момент проблем с производительностью не испытываем.
В описанном в статье кейсе в итоге остался Redis Custer ( шарды + реплики), keydb задействовали чтобы выйти за лимит в 1 ядро без перешардирования.
Из документации я так и не понял, как для Keydb Cluster включить active-active (хотя очень хотелось, что-то подобное). Казалось бы, что каждый шард - это мастер с набором реплик, почему бы нет. Но нигде не описано, что такая конфигурация возможна, разе что взять и попробовать.
Вообще, так как из редиса идет в основном чтение, можно на клиенте включать READONLY для запросов чтения. Тогда можно будет читать в том числе из реплик, и таким образом снизить нагрузку на мастеры. Но это нужно дорабатывать приложения, работающие с redis. А режим active-active решил бы эту проблему прозрачно для приложения. Но увы...
Примечательно (а может и очевидно), что агенты потребляют еще больше CPU, в случае если открыть в браузере страницу с визуализацией hubble.
Провели тест на кластере из двух воркер нод 4/8, находящихся физически на двух разных гипервизорах, запуская iperf между подами двух нод. Ключи iperf - bidirectional dualtest в 100 потоков, полоса ограничена физической картой хост машины в 1 Гбит.
Порядок значений потребления cpu агентами с хабблом
Hubble отключен в агентах - 0.5 ядра
Hubble включён в агентах - 4-5 ядер
Hubble включён и в браузере открыт дашборд с неймспейсом iperf, где 2 пода передают друг другу данные (выглядит как квадрат и одна стрелочка) - 7-8 ядер
Я бы сказал что это антипаттерн - писать логи напрямую в систему сбора логов.
Что будет с логами приложения или вообще с приложением, если в какой-то момент не будет работать loki (будет медленно отвечать, не будет вообще отвечать, будет в этот момент перезапускаться и т.д.)?
Скорее всего или приложение будет тормозить на отправке логов, или вообще упадёт, хотя могло бы работать. Да и отправляемый лог пропадёт. Именно поэтому пишут в stdout, который просто пишется на диск в файл. А другой сервис уже этот логотправляет.
Все же если говорить про «просто» и «проще», то удалить файл проще, чем в него что-то добавить.
Конечно вариант с recovery_target более гибкий, но это уже скорее про «восстановление бэкапа на определенную точку времени», а не про «случайно синкнул реплику с мастера, когда не собирался»
Да, можно было указать mirror.nsc.liu.se в /etc/yum.repos.d/CentOS-6-Vault.repo вместо vault.centos.org, и установить нужный пакет, заодно обновить nss. Но то, что существует mirror.nsc.liu.se без редиректа - видимо было обнаружено уже после того, как nss был "починен" с помощью Скачать пакеты на локальную машину по HTTPS, после чего загрузить по SCP/Rsync на удаленную. А вариант с curl в статье указан как альтернатива, чтобы все действия можно было произвести сразу на нужном хосте. Если бы на момент возникновения проблемы было известно, что есть репо без https - вероятно половины истории бы не было - установили пакет foobar и забыли. Так же нужно помнить, что это зеркало пока без https, и в любой момент ситуация может поменяться, так же как это произошло с vault.centos.org. Тогда останется только вариант с scp.
Ну и "сделать прокси" в каждой такой ситуации не проще, чем просто установить нужные пакеты nss, пусть даже через сurl или scp. Просто теперь уже известно какие. Так же "сделать прокси" в сети, где есть только такие устаревшие CentOS - вообще вряд ли получится, у них у всех будет проблема с SSL. То есть делать прокси придется где-то в третьем месте. Я все же за scp в этом случае.
В вашем доме 100 квартир. 80 однокомнатных, 20 трехкомнатных. Один из жильцов дома вывесил опрос "Стоимость обслуживания лифта в доме должны полностью оплачивать собственники трехкомнатных квартир. За / Против". Через день посмотрите результаты опроса (хотите - поквартирно, хотите - поквадратно) К счатью, с лифтом так не получится в силу закона, но могут быть более сложные варианты, когда общественное мнение и здравый смысл расходятся.
Спасибо. Использовал вашу статью как стартовую идею для настройки 2FA через telegram bot (в телеграм отправляется код, при клике на кнопку с кодом попадаешь в вайтлист)
в BBB нельзя четко ответит на вопрос «сколько онлайн конференций может быть».
Сильно зависит от того, что это за конференции
1) используется перезентация или трансляция рабочего стола (презентация это картинка статичная, трансляция стола — это видеопоток каждому участнику)
2) сколько человек одновременно в аудиоконференции с активным микрофоном — только ведущий или «все со всеми»
3) сколько камер подключено — ни одной, только у ведущего, несколько камер, у всех
4) кто видит активные камеры — только модератор видит все камеры, все видят все камеры
5) какое качество выставлено у камер — низкое, среднее, высокое
6) идет ли запись мероприятия
и все эти параметры мультплицируют нагрузку с какими-то коэфициентами. Чем больше функционала используете тем сильнее нагрузка возрастает, в геометрической прогрессии.
Неудобно (хоть и не критично), что нужно использовать рестик или борг, вместо того чтобы "просто скопировать файлы"
Плюс к тому и рестик и борг делают дедуп в рамках одного бэкап-архива. Если у вас бэкап двух почти одинаковых БД, то дедупликации не будет (между ними). В случае с ФС дедеп применяется для всех записанных данных.
С другой стороны в borg/restic дедупликация со сжатием может более эффективная, чем дедупликация сжатых файлов на ФС. Так же при бэкапе боргом по сети сначала производится дедупликация (подсчет хэшей блоков), а потом передача измененных блоков данных. Это может быть полезно, так меньше нагружает сеть, она не будет узким местом при терабайтных бэкапах повторяющихся данных, ведь на удаленный сервер будут переданы только изменённые блоки.
>Главный плюс Терраформа в том, что мы можем использовать унифицированное решение для всех сред
Поделитесь, как вы переносите свою IaC, описанную терраформом, например из AWS в GCP, или в какой-нибудь OpenStack?
Придумал пример: Не было доступов к инфре, пытался взломать несколько месяцев, через пол года получил доступ и закрыл задачу за 5 минут ))
Внимательный рекрутер заметит, что Антон планирует уволиться года через 4, а возможно раньше.
Часто в проектах, выросших из маленьких, а не разработанных с нуля под хайлоад, так и бывает: ресурсов на то чтобы переделать "правильно" нет, разработчики пилят для бизнеса новые фичи, которые должны приносить больше денег. Изменить архитектуру невозможно, потому что на это нет ни ресурсов ни желания - все опасаются сломать поток денег. И все серьезные сдвиги в архитектуре происходят только по итогам факапов. А пока факап не случился - бывает и сессии пользователей хранят в базе mysql, постепенно доводя муську до инстанса в 256 ядер с терабайтом ОЗУ.
Бизнес выделит ресурсы на "переделать правильно" когда почувствует, что теряет деньги.
Ответ на вопрос на самом деле очень простой - наш костыль в эксплуатации почти год, а когда был сделан первый коммит в coroot? Правильно.
Нельзя взять то, чего нет
Очень похоже, но есть кардинальное различие: k8spacket использует pcap, то есть перехватывает каждый пакет и передает его в юзерспейс приложения для обработки. В связи с этим, боюсь на настоящих нагрузках такой мониторинг может потреблять больше CPU, чем сами приложения, которые он мониторит.
Зависит от ситуации наверное.
Если вы упираетесь в одно ядро на существующем редисе и при этом не хотите особо заморачиваться с шардированием редиса в несколько инстансов по разным ядрам - можно просто запустить бинарь keydb-server вместо redis-server на той же конфигурации, и доутилизировать другие ядра (если они есть конечно)
Остальное конечно требует исследований, однозначных ответов "кто лучше" конечно не существует.
Все же поправочка по версиям: redis 6.2.5 -> keydb 6.2.1
Шардинг по хэшу ключа.
Из документации: The base algorithm used to map keys to hash slots is the following (read the next paragraph for the hash tag exception to this rule) HASH_SLOT = CRC16(key) mod 16384
На графиках видно 3 нагруженных мастера (один из них действительно чуть менее нагружен, чем два других) и 6 почти бездействующих реплик.
Шардинг по хэшу ключа позволяет как-то более или менее равномерно распределить ключи между шардами - количественно, но не частоту обращений к ним.
Вероятно есть какие-то ключи, которые заметно более популярны, чем какие-то другие. Или значения ключей заметно большего размера.
Можно пораспределять слоты между шардами (мастерами), как-то их подвигать, чтобы выровнять нагрузку на мастеры. Но я большого смысла не вижу, будут другие ключи - и картинка поменяется.
Использовали 6.3.1 , и она показала лучшую производительность, чем редис 6.0.2 Может не на ядро, но в совокупности на том же железе сервис стал работать лучше.
Про issue хороший поинт, может имеет смысл откатиться на 6.2.2, но на данный момент проблем с производительностью не испытываем.
В описанном в статье кейсе в итоге остался Redis Custer ( шарды + реплики), keydb задействовали чтобы выйти за лимит в 1 ядро без перешардирования.
Из документации я так и не понял, как для Keydb Cluster включить active-active (хотя очень хотелось, что-то подобное). Казалось бы, что каждый шард - это мастер с набором реплик, почему бы нет. Но нигде не описано, что такая конфигурация возможна, разе что взять и попробовать.
Вообще, так как из редиса идет в основном чтение, можно на клиенте включать READONLY для запросов чтения. Тогда можно будет читать в том числе из реплик, и таким образом снизить нагрузку на мастеры. Но это нужно дорабатывать приложения, работающие с redis. А режим active-active решил бы эту проблему прозрачно для приложения. Но увы...
Примечательно (а может и очевидно), что агенты потребляют еще больше CPU, в случае если открыть в браузере страницу с визуализацией hubble.
Провели тест на кластере из двух воркер нод 4/8, находящихся физически на двух разных гипервизорах, запуская iperf между подами двух нод. Ключи iperf - bidirectional dualtest в 100 потоков, полоса ограничена физической картой хост машины в 1 Гбит.
Порядок значений потребления cpu агентами с хабблом
Hubble отключен в агентах - 0.5 ядра
Hubble включён в агентах - 4-5 ядер
Hubble включён и в браузере открыт дашборд с неймспейсом iperf, где 2 пода передают друг другу данные (выглядит как квадрат и одна стрелочка) - 7-8 ядер
Я бы сказал что это антипаттерн - писать логи напрямую в систему сбора логов.
Что будет с логами приложения или вообще с приложением, если в какой-то момент не будет работать loki (будет медленно отвечать, не будет вообще отвечать, будет в этот момент перезапускаться и т.д.)?
Скорее всего или приложение будет тормозить на отправке логов, или вообще упадёт, хотя могло бы работать. Да и отправляемый лог пропадёт. Именно поэтому пишут в stdout, который просто пишется на диск в файл. А другой сервис уже этот логотправляет.
Конечно вариант с recovery_target более гибкий, но это уже скорее про «восстановление бэкапа на определенную точку времени», а не про «случайно синкнул реплику с мастера, когда не собирался»
Да, можно было указать mirror.nsc.liu.se в /etc/yum.repos.d/CentOS-6-Vault.repo вместо vault.centos.org, и установить нужный пакет, заодно обновить nss. Но то, что существует mirror.nsc.liu.se без редиректа - видимо было обнаружено уже после того, как nss был "починен" с помощью Скачать пакеты на локальную машину по HTTPS, после чего загрузить по SCP/Rsync на удаленную. А вариант с curl в статье указан как альтернатива, чтобы все действия можно было произвести сразу на нужном хосте. Если бы на момент возникновения проблемы было известно, что есть репо без https - вероятно половины истории бы не было - установили пакет foobar и забыли. Так же нужно помнить, что это зеркало пока без https, и в любой момент ситуация может поменяться, так же как это произошло с vault.centos.org. Тогда останется только вариант с scp.
Ну и "сделать прокси" в каждой такой ситуации не проще, чем просто установить нужные пакеты nss, пусть даже через сurl или scp. Просто теперь уже известно какие. Так же "сделать прокси" в сети, где есть только такие устаревшие CentOS - вообще вряд ли получится, у них у всех будет проблема с SSL. То есть делать прокси придется где-то в третьем месте. Я все же за scp в этом случае.
В вашем доме 100 квартир. 80 однокомнатных, 20 трехкомнатных. Один из жильцов дома вывесил опрос "Стоимость обслуживания лифта в доме должны полностью оплачивать собственники трехкомнатных квартир. За / Против". Через день посмотрите результаты опроса (хотите - поквартирно, хотите - поквадратно)
К счатью, с лифтом так не получится в силу закона, но могут быть более сложные варианты, когда общественное мнение и здравый смысл расходятся.
Дублирование на случай если одна статья "не взлетит"
Сильно зависит от того, что это за конференции
1) используется перезентация или трансляция рабочего стола (презентация это картинка статичная, трансляция стола — это видеопоток каждому участнику)
2) сколько человек одновременно в аудиоконференции с активным микрофоном — только ведущий или «все со всеми»
3) сколько камер подключено — ни одной, только у ведущего, несколько камер, у всех
4) кто видит активные камеры — только модератор видит все камеры, все видят все камеры
5) какое качество выставлено у камер — низкое, среднее, высокое
6) идет ли запись мероприятия
и все эти параметры мультплицируют нагрузку с какими-то коэфициентами. Чем больше функционала используете тем сильнее нагрузка возрастает, в геометрической прогрессии.