Если это будет интегрировано с отдельной переключающей кнопкой в основную ветку — к ценнику пририсуется полнуля. В любом случае, это трата ресурсов впустую, лоуэнд недоверенный сегмент, который соответствует контейнерам массового хостинга, просто не окупит изменение даже при относительно крупной потребности в нем. У контейнерных решений доверенного сегмента (докер) совершенно другие потребности и возможности их реализовать, как правило (к примеру, подключить SDS или полку).
Там чейндж на 2-10 строчек, байты выйдут платиновыми, это помимо поддержки. Поддерживать это у себя — держать ядерного разработчика в пределах доступности, проще и дешевле не пользоваться ядерным блочным шедулером вообще =).
Если появится кто-то с такой необходимостью, я думаю по программе платной разработки для OpenVZ, ее вполне реально получить.
Ценник за разработку-поддержку будет крайне негуманным. К тому же тут есть очень интересный нюанс — контейнеры обычно набиваются на ноду, за счет отсутствия оверхеда на ОС, ksm-подобных механизмов и тому подобного очень-очень плотно, потому ограничения им придется выставлять с очень большим оверкоммитом относительно их реальной доли на ноде => легкость дудоса на бендвиз дисковой подсистемы.
Одна политика шедулинга — можно использовать только ту логику шедулинга, которая предоставляется ядром, она, в целом, оптимальная, но может потребоваться ее кастомизация — к примеру, у вас у клиентов идут длинные берсты, которые шедулером косятся. В эмуляторе делать и поддерживать такие правки намного дешевле.
Насчет дампа — я имел в виду конкретный FIFREEZE при снятии снимка диска, насколько мне известно, его в контейнерные решения не завезли пока что. Понятно, что при снятии еще и памяти за счет приостановки всей сущности целиком снимок выйдет на сто процентов консистентным.
позволю пару ремарок
по пункту 1 — все ок, только линуксовый шедулер предоставляет 1 (одну) политику шедулинга ио в сигруппах для блочных устройств, то есть любая доделка, связанная с, допустим, берстом, выльется в нетривиальный геморрой
по пункту 3 — пока fsfreeze не умеет всовываться в контейнер, это не совсем полноценный бекап, хоть и атомарный, жирная бд может вполне себе не восстановиться из такого бекапа при ряде доп условий
Для контейнерщиков, у кого не плуп, вышло критично, впрочем, у них и так забот хватает — обновлять ядро на каждый ядерный эксплойт с приостановкой обслуживания.
Вопрос «как мне восстановить случайно удаленный сервер?» у облачных хостеров находится на втором месте по популярности после вопроса «я забыл пополнить баланс, как мне восстановить удаленный сервер?». Поэтому практически наверняка для решения проблемы достаточно было связаться со службой поддержки Амазона.
Это пример с одной из VM, обслуживающих другой наш проект — на нее идут отстуки в несколько сотен байт, так что числа почти одинаковые.
Так если сеть построена симметрично и потоков много — что там оптимизировать?
Распределение трафика в ней, ведь пользовательский трафик может быть очень сильно перекошен относительно топологии. Безусловно, чем меньше масштаб, тем меньше и перекосы, потому это не очень очевидно.
Ну так хоть даже netflow можно смотреть на предмет таких же аномалий,
Зачем? Лишний механизм, необходимость прогона всего трафика в хосте… В будущем мы внедрим одно из offload-решений(netmap/dpdk) в vswitch, такие механизмы просто лишатся возможности работать, хост перестанет «видеть» трафик.
Так зачем вам Openflow? Я не понял. Вроде всё усложнили, профита не вижу.
Наоборот, мы отвязались от *всех* протоколов маршрутизации внутри своей сети и существенно упростили управление ей. Со стороны сетевиков, работавших с классическими протоколами большую часть карьеры, это кажется изобретением велосипеда(чем, частично, и является, иначе полной замены не выйдет), а на деле это огромное упрощение, сведение всех сетевых сущностей к единому участку кода в оркестровке. Можете считать это закладкой на будущее — мы можем линейно масштабироваться без каких-либо усилий, вводить дополнительные реактивные (в смысле логики поведения) правила обработки трафика, создавать оверлеи на сколь угодно большом масштабе — плюсы перечислять можно долго. Как было упомянуто в посте, мы стремимся к выстраиванию своей собственной экосистемы во всех стеках — поверьте, это приносит положительные плоды.
Так какой cps, сколько одновременных соединений и сколько стоек на контроллер?
20k/20k (из примера в продакшене), около 0.05 :)
Не вижу связи. Так у вас есть задача выравнивать нагрузку на аплинках, или нет? И кстати, железные свитчи все-таки являются OF форвардерами, или только держат оверлеи? Я как-то не понял.
Пока что нет, мы не сделали полноценный BGP redistribution, задача сводится к оптимизации трафика датацентра. Свичи выполняют, как бы это сказать, совмещенную роль — режим OF работает как оверлейный механизм.
Тестирование чего?
Какого рода аномалии?
Сейчас — очень простые, вида «машина ведет себя не как обычно» — профиль трафика и, при обнаружении каких либо отклонений в «дешевых» анализаторах — переключение на более «дорогие», то есть реактивные правила или заворачивание на тот же IDS. Очень помогает в борьбе со всякого рода зловредами, обожающими пролезать через дырявые движки.
Вы даже не сможете по-человечески детектировать L7 аномалиями
В этом пока что нет нужды, мы не предоставляем такую услугу. Анализ L7 — задача, востребованная энтерпрайзом (предотвращение атак и тому подобное), для самих себя это в лучшем случае помощь от упомянутых зловредов на еще более ранних стадиях, то есть предотвращение заражения.
Да, чуть не забыл — из утверждения про проактивность большей части правил никак не следует отсутствие преимущества централизованного их пересчета, сравнительно с IGP. Проактивность всего лишь шаг к редукции числа правил, а не аналог статической FIB.
1. в стойке — около 1к
2. pps — сотни тысяч на тестах (упираемся в производительность vhost-net на мелких пакетах), в реальности 20k/нода перемалываются с пренебрежимо малой нагрузкой процессора, cps в этом случае те же — трафик идентичен трафику счетчиков.
3. неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики
4. 0 :) у нас за все время из-за опенфлоу была ровно одна авария, связанная с некорректной логикой контроллера, как раз в начале внедрения, занявшая 20 минут времени
5. в целом, если выбросить оверлеи, никакой — на порядки сокращается время тестирования и упрощается выявление аномалий, OF это не волшебная палочка, а просто очередной шаг вперед — касательно того же анализа пакетов — OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором. Сопрягать оркестровку еще и со сторонней IDS — увольте, до момента, когда она будет предоставлять действительно уникальные фичи, это просто расход ресурсов в никуда и инвестиции в производителя этой IDS.
Мы утверждаем, что Openflow к продакшну при грамотном подходе полностью готов — об этом свидетельствует годичный опыт :)
Суперкритикал БД может нехило подфризиться, пока обновляются вызовы. Даже если там обновление kgraft-подобное, все равно тормоза могут быть неприемлемо большими. На мой взгляд, все эти пляски могут быть применимы только как дальшейшее уменьшение даунтайма при апгрейде ядра, с бонусом в виде поднятых в память кешей, для критичных вещей существует HA/state replication :)
Блочные устройства можно размещать на фс, в этом нет проблем. Проблема в том, что хост должен «уметь» эту фс. В случае Ceph гипервизор вообще не знает о том, что первый существует, и это хорошо — можно поставить пачку гиперви или esx хостов и подцепить к хранилищу через iscsi реэкспорт.
Нет, оркестровка полностью самописная. К слову, мы считаем, что все опенсорсные продукты для оркестровки облаков очень сильно недотягивают до нашего уровня в смысле как минимум интегрированности компонент.
Ценник за разработку-поддержку будет крайне негуманным. К тому же тут есть очень интересный нюанс — контейнеры обычно набиваются на ноду, за счет отсутствия оверхеда на ОС, ksm-подобных механизмов и тому подобного очень-очень плотно, потому ограничения им придется выставлять с очень большим оверкоммитом относительно их реальной доли на ноде => легкость дудоса на бендвиз дисковой подсистемы.
Насчет дампа — я имел в виду конкретный FIFREEZE при снятии снимка диска, насколько мне известно, его в контейнерные решения не завезли пока что. Понятно, что при снятии еще и памяти за счет приостановки всей сущности целиком снимок выйдет на сто процентов консистентным.
по пункту 1 — все ок, только линуксовый шедулер предоставляет 1 (одну) политику шедулинга ио в сигруппах для блочных устройств, то есть любая доделка, связанная с, допустим, берстом, выльется в нетривиальный геморрой
по пункту 3 — пока fsfreeze не умеет всовываться в контейнер, это не совсем полноценный бекап, хоть и атомарный, жирная бд может вполне себе не восстановиться из такого бекапа при ряде доп условий
Это пример с одной из VM, обслуживающих другой наш проект — на нее идут отстуки в несколько сотен байт, так что числа почти одинаковые.
Распределение трафика в ней, ведь пользовательский трафик может быть очень сильно перекошен относительно топологии. Безусловно, чем меньше масштаб, тем меньше и перекосы, потому это не очень очевидно.
Зачем? Лишний механизм, необходимость прогона всего трафика в хосте… В будущем мы внедрим одно из offload-решений(netmap/dpdk) в vswitch, такие механизмы просто лишатся возможности работать, хост перестанет «видеть» трафик.
Наоборот, мы отвязались от *всех* протоколов маршрутизации внутри своей сети и существенно упростили управление ей. Со стороны сетевиков, работавших с классическими протоколами большую часть карьеры, это кажется изобретением велосипеда(чем, частично, и является, иначе полной замены не выйдет), а на деле это огромное упрощение, сведение всех сетевых сущностей к единому участку кода в оркестровке. Можете считать это закладкой на будущее — мы можем линейно масштабироваться без каких-либо усилий, вводить дополнительные реактивные (в смысле логики поведения) правила обработки трафика, создавать оверлеи на сколь угодно большом масштабе — плюсы перечислять можно долго. Как было упомянуто в посте, мы стремимся к выстраиванию своей собственной экосистемы во всех стеках — поверьте, это приносит положительные плоды.
20k/20k (из примера в продакшене), около 0.05 :)
Пока что нет, мы не сделали полноценный BGP redistribution, задача сводится к оптимизации трафика датацентра. Свичи выполняют, как бы это сказать, совмещенную роль — режим OF работает как оверлейный механизм.
Сейчас — очень простые, вида «машина ведет себя не как обычно» — профиль трафика и, при обнаружении каких либо отклонений в «дешевых» анализаторах — переключение на более «дорогие», то есть реактивные правила или заворачивание на тот же IDS. Очень помогает в борьбе со всякого рода зловредами, обожающими пролезать через дырявые движки.
В этом пока что нет нужды, мы не предоставляем такую услугу. Анализ L7 — задача, востребованная энтерпрайзом (предотвращение атак и тому подобное), для самих себя это в лучшем случае помощь от упомянутых зловредов на еще более ранних стадиях, то есть предотвращение заражения.
2. pps — сотни тысяч на тестах (упираемся в производительность vhost-net на мелких пакетах), в реальности 20k/нода перемалываются с пренебрежимо малой нагрузкой процессора, cps в этом случае те же — трафик идентичен трафику счетчиков.
3. неудобством сопряжения интеллектуального куска на нодах и всего, что будет находиться выше — выходит сложнее в плане логики
4. 0 :) у нас за все время из-за опенфлоу была ровно одна авария, связанная с некорректной логикой контроллера, как раз в начале внедрения, занявшая 20 минут времени
5. в целом, если выбросить оверлеи, никакой — на порядки сокращается время тестирования и упрощается выявление аномалий, OF это не волшебная палочка, а просто очередной шаг вперед — касательно того же анализа пакетов — OF, в общем случае, не может выступать в роли файрвола в силу своей природы (нет отслеживания состояния соединения), но зато может выступать дешевым классификатором. Сопрягать оркестровку еще и со сторонней IDS — увольте, до момента, когда она будет предоставлять действительно уникальные фичи, это просто расход ресурсов в никуда и инвестиции в производителя этой IDS.
Мы утверждаем, что Openflow к продакшну при грамотном подходе полностью готов — об этом свидетельствует годичный опыт :)