Когда инфру вы арендуете «дядя» и так знает метрики платформы вашего сервера. Node exporter хоть и богат на метрики, но не умеет считать электричество/показывать какие блоки питания подключены/температуры с датчиков входа/выхода потока воздуха.
Тогда резонный вопрос: не тяжело ли VPP обрабатывать ACL от десятков тысяч хостов? Каким образом распределяется нагрузка north-south и south-north? Как «размазываете» правила между и как они мигрируют в случае миграции ВМ или другого ворклоада?
Слабо представляется первая тема, не могли бы конкретизировать? Трафик в любом случае доедет до compute.
VPP очень производительный и выделить условно 1 ядро (уверен что так сейчас и делаете) не составит большого расхода, с учетом что на compute нодах он все равно запущен, прогнать несколько ACL не составит большого труда.
Чем обусловлен выбор border хостов на границе сети, вместо того чтобы роутить трафик прямо на compute ноды из мира условным evpn? В связке с isolcpu для vpp это будет довольно эффективно + нет точки отказа в виде бордер хоста.
Не связано с выносом, но как эхо всей ситуации, да.
Теперь у органов внимание на mirhosting, обвиняют во всем плохом против всего хорошего. Не хватает только громких заявлений о защите детей.
Датацентр nLighten по собственной инициативе закрыл доступ сотрудников mirhosting к стойкам. NL и DE фактически оказались в заложниках руководства nLighten.
Есть резервный план, как только ребята высвободят железо, то скорее всего поеду сам перевозить в резервный датацентр.
Как вы это представляете? Клиенты мирхостинга не могут подавать иск к nlighten по одной простой причине: цод им ничего не продавал и не предоставлял. Как говорят мудрецы: «клиент моего клиента не мой клиент».
Я не уверен как это будет выглядеть юридически: клиенты мирхостинга вместе с ними подают иск к nlighten? Если юристы вдруг мимопроходят, то пните как это может выглядеть
На Mirhosting нет никаких ограничений. Совсем. Вообще. То что сделал цод называется самодеятельностью. Интересно, что думают другие клиенты относительно молодой сети датацентра :) в Европе пока что институт репутации работает вроде как. Будем посмотреть.
Это создало очень опасный прецедент, который выйдет в Европе боком кому угодно не один раз.
Вы просто не умеете это готовить (с) никто не заставляет тащить 44 компонента (и никогда не заставлял), опенстак отлично работает из коробки тем же набором из 4: neutron, nova, glance, cinder (опционально).
Можно обойти sr-iov через оффлоад роутинга с помощью XDP (то есть вся маршрутизация входящего/исходящего трафика) будет производиться в рамках одного XDP скрипта. Если это "жирные" compute по типу эпиков с 128+ ядрами должно сильно помочь. Все равно есть подозрение что всплывут другие болячки.
Изучали ли новую планируемую интеграцию BGP прямо в OVN?
Как справились с растущим irq при маршрутизации на хосте? В отличие от топорного L2 гипервизор одновременно становится и некст-хопом, что вызывает накладные расходы на маршрутизацию. Да, это лишь правила чтобы трафик к /32 заворачивался на отдельный бридж от ovs, но тем не менее. На мелких масштабах это не заметно, но затем IRQ становится слоном в комнате, которого невозможно игнорировать.
Возможное решение- роутить на стороне OVN (дополнительный кластер на каждой ноде, что позволит вынести роутинг в другой слой и подключить dpdk и/или offload фичи сетевой карты). В этом подходе возникает другая проблема: невозможность использовать ECMP. Возможный выход из ситуации: sr-iov и отдавать часть nic в ovs и часть оставить для контроплейна, но такой подход еще не тестировал. Или вовсе ставить дополнительный NIC в каждый сервер, но это совсем другая история.
Как вы планируете решать проблему с масштабируемостью CoreDHCP, который хранит весь конфиг в файле, не говоря об атомарности изменений, которые а облаке происходят практически 24/7/365. Будто бы in-memory вариант или какой-то коннектор к условному редису был бы более эффективен и масштабируемый
Проект крутой, команда молодцы! Такой вопрос: есть ли доки по добавлению своих сервисов, которых пока еще нет в packages/apps? Кроме сурсов так и не нашел
Ритейлеры пока не расширяли (сейчас 1 год от импортера), однако, деградировавший процессор 14 серии взяли на диагностику в АСЦ и с заключением выполнили возврат в полном размере спустя полгода после покупки. Каких-либо пробуксовок не было. Проц покупался на мегамаркете
Когда инфру вы арендуете «дядя» и так знает метрики платформы вашего сервера. Node exporter хоть и богат на метрики, но не умеет считать электричество/показывать какие блоки питания подключены/температуры с датчиков входа/выхода потока воздуха.
Тогда резонный вопрос: не тяжело ли VPP обрабатывать ACL от десятков тысяч хостов? Каким образом распределяется нагрузка north-south и south-north? Как «размазываете» правила между и как они мигрируют в случае миграции ВМ или другого ворклоада?
Слабо представляется первая тема, не могли бы конкретизировать? Трафик в любом случае доедет до compute.
VPP очень производительный и выделить условно 1 ядро (уверен что так сейчас и делаете) не составит большого расхода, с учетом что на compute нодах он все равно запущен, прогнать несколько ACL не составит большого труда.
Чем обусловлен выбор border хостов на границе сети, вместо того чтобы роутить трафик прямо на compute ноды из мира условным evpn? В связке с isolcpu для vpp это будет довольно эффективно + нет точки отказа в виде бордер хоста.
Не связано с выносом, но как эхо всей ситуации, да.
Теперь у органов внимание на mirhosting, обвиняют во всем плохом против всего хорошего. Не хватает только громких заявлений о защите детей.
Датацентр nLighten по собственной инициативе закрыл доступ сотрудников mirhosting к стойкам. NL и DE фактически оказались в заложниках руководства nLighten.
Есть резервный план, как только ребята высвободят железо, то скорее всего поеду сам перевозить в резервный датацентр.
Как вы это представляете? Клиенты мирхостинга не могут подавать иск к nlighten по одной простой причине: цод им ничего не продавал и не предоставлял. Как говорят мудрецы: «клиент моего клиента не мой клиент».
Я не уверен как это будет выглядеть юридически: клиенты мирхостинга вместе с ними подают иск к nlighten? Если юристы вдруг мимопроходят, то пните как это может выглядеть
На Mirhosting нет никаких ограничений. Совсем. Вообще. То что сделал цод называется самодеятельностью. Интересно, что думают другие клиенты относительно молодой сети датацентра :) в Европе пока что институт репутации работает вроде как. Будем посмотреть.
Это создало очень опасный прецедент, который выйдет в Европе боком кому угодно не один раз.
Temporal крайне хорош, но тут не ту задачу решают. Скорее не задачу, а причесывают паттерны
Вы просто не умеете это готовить (с) никто не заставляет тащить 44 компонента (и никогда не заставлял), опенстак отлично работает из коробки тем же набором из 4: neutron, nova, glance, cinder (опционально).
Насколько целесообразно юзать Kafka + ZK в конце 2025?
Можно обойти sr-iov через оффлоад роутинга с помощью XDP (то есть вся маршрутизация входящего/исходящего трафика) будет производиться в рамках одного XDP скрипта. Если это "жирные" compute по типу эпиков с 128+ ядрами должно сильно помочь. Все равно есть подозрение что всплывут другие болячки.
ovn-bgp-agent использовался?
Изучали ли новую планируемую интеграцию BGP прямо в OVN?
Как справились с растущим irq при маршрутизации на хосте? В отличие от топорного L2 гипервизор одновременно становится и некст-хопом, что вызывает накладные расходы на маршрутизацию. Да, это лишь правила чтобы трафик к /32 заворачивался на отдельный бридж от ovs, но тем не менее. На мелких масштабах это не заметно, но затем IRQ становится слоном в комнате, которого невозможно игнорировать.
Возможное решение- роутить на стороне OVN (дополнительный кластер на каждой ноде, что позволит вынести роутинг в другой слой и подключить dpdk и/или offload фичи сетевой карты). В этом подходе возникает другая проблема: невозможность использовать ECMP. Возможный выход из ситуации: sr-iov и отдавать часть nic в ovs и часть оставить для контроплейна, но такой подход еще не тестировал. Или вовсе ставить дополнительный NIC в каждый сервер, но это совсем другая история.
Как вы планируете решать проблему с масштабируемостью CoreDHCP, который хранит весь конфиг в файле, не говоря об атомарности изменений, которые а облаке происходят практически 24/7/365. Будто бы in-memory вариант или какой-то коннектор к условному редису был бы более эффективен и масштабируемый
TF изначально довольно монструозный и + отсутствует часть фич в отличие от VPP. Со старта проще взять что-то небольшое и заставить это работать.
Проект крутой, команда молодцы! Такой вопрос: есть ли доки по добавлению своих сервисов, которых пока еще нет в packages/apps? Кроме сурсов так и не нашел
Открываете запрос в поддержку, они попросят его отправить в АСЦ и после заключения делают возврат. Проходил через это, заняло около 3 недель.
Ритейлеры пока не расширяли (сейчас 1 год от импортера), однако, деградировавший процессор 14 серии взяли на диагностику в АСЦ и с заключением выполнили возврат в полном размере спустя полгода после покупки. Каких-либо пробуксовок не было. Проц покупался на мегамаркете
Именно о возможных действиях злоумышленника, так как талос больше позиционируется как абстрагированный от ручного управления дистрибутив
Как сильно изменился бы ход действий, работая k8s на базе того же Talos без SSH и каких-либо «внешних» простых способов управления?
Жду когда снова все будут заряжать воду у телевизоров по всей стране. Поглядеть вживую и можно уезжать