И да full view и не один держит не напрягаясь frr на рядовом железе, проблема в data plane и его задержках при использовании ядра linux, а не в control plane.
Есть подвижки с DPDK и eBPF+XDP но они пока не могут быть применены достаточно широко т.к. это инструменты для разработки, а не готовое решение конкретных задач.
Нет TNSR пощупать не получилось, но щупал ванильный fd.io на самосборе с интеловвми картами — он показал line rate на маршрутизации без NAT и фильтров между 2 10G. TNSR построен на fd.io с рядом оптимизаций так что на базе опыта с fd.io я склонен доверять заявленным показателям.
Cumulus это про коммутаторы пока что, full view он там не переварит.
10G на line rate это проблема если PPS большой, пока его пережёвывает только fd.io поверх DPDK и продукты построенные на нём, например https://www.tnsr.com/
А вот MX и аналоги спокойно справляются.
Стоковое ядро с тюненным sysctl живёт до первого DDoS на 10mpps потом становится весело.
Пока нет, возможно позже.
С самим кумулусом проблем не сильно много, у нас больше проблем с обвязкой управления сетью которая досталась в наследство.
Разница с вендорами — нужно детально понимать как работают все компоненты, что-бы всё было стабильно, впрочем как и с любыми комплексными OSS решениями из мира linux.
Про DPDK и MX разверните пожалуйста.
Если это про fd.io то он IMHO пока больше Фреймворк для создания своего ПО чем продукт который можно в бой пускать.
Если что-то иное — поделитесь пожалуйста тема интересна.
Ну так в том то и вопрос, что стоимость поддержки докера в нашем случае оказалась выше. Не вижу как это может влиять на bus factor.
Docker это всё-таки стандарт, в отличии от самописных скриптов, который со временем разрастаются, поэтому найти на рынке специалистов, которые его знают будет проще.
Это упрощение. Факторов больше чем размер команды, но это конечно один из них.
Основные факторы это:
Сложность проекта
Размер команды
Необходимое значение Time to market
Из них как правило вытекают размер инфраструктуры, которую нужно поддерживать и сложность развёртывания.
Плюс с ростом команды появляется класс проблем, связанный с тестированием всех изменений, которые делаются в проекте, откуда появляется необходимость простого развёртывания нескольких веток по необходимости.
Причём чем быстрее нужно вносить изменения, тем нужнее системы CI/CD, а в большой инфраструктуре сложного проекта docker сильно облегчает процессы тестирования и деплоя, особенно когда серверов не 2 и не 10.
Ну а чем докер принципиально отличается от bash скрипта, Dockerfile это по сути и есть плюс минус bash-скрипт.
Он принципиально отличается от bash, ansible и т.п. тем, что у вас нет предыдущего состояния (точнее оно всегда известно — это состояние образа с которого вы начинаете), поэтому он исключает класс проблем вида «для установки этой библиотеки для этой зависимости, мне сначала нужно откатить предыдущее», а так же ситуации, когда в среде исполнения приложения кто-то из администраторов и разработчиков что-то поправил руками, но не задокументировал и не вписал в тот же ansible.
Другими словами с docker у вас всегда конфигурация системы начинается с чистого листа.
Я не противник докера. Более того я его использую для тестирования bash-скриптов. (Хотя могу и без докера, через vagrant). Но я против бездумного пихания докера и микросервисов в каждый проект.
Определённо, затаскивать в любой проект любую технологию, потому что это «стильно, модно, молодёжно» не стоит.
Но многие приносят docker в проект для более простого решения класса задач, которые вас, как программиста могут не касаться.
В разрезе python / django это может быть установка пакетов, требующих компиляции нативных расширений, когда у вас 50 серверов это становится болезненно и долго — проще один раз собрать docker image, посте чего скачать его на все сервера и запустить тем же ansible.
При использовании ansible без docker он очень быстро разрастается и сложность его понимания и входа для нового DevOps/SRE становится существенной.
Не всё что вам кажется «бездумным пихаением» может быть этим на самом деле, возможно просто с вашей точки зрения это только кажется.
Я выше написал, что изначально докер был в проекте. Так что это не про нашу ситуацию.
Не исключаю, что для вашего проекта эта технология не нужна, а волосы людей, ответственных за поддержку проекта со стороны инфраструктуры вместе с теми, кто отвечает за деплой, мягкие и шелковистые.
Но всё это может быть не так в иных ситуациях.
Да это есть, но не сильно отличается от настройки того-же apache/nginx, делается это один раз и работает потом долго.
Доступ к docker socket в RO, это всё-таки не рут права (RW — можно так назвать).
Бонусом докера является возможность не доставлять те же модули php на конечные машины, это не боль при условии, что у вас один сервер и свежий проект, а когда их несколько и проект требует старый php, которых нет в свежих дистрибутивах, или состав этих модулей периодически меняется.
В таком случае вы получаете сильное упрощение в Operations с не не очень существенным усложнением в Dev.
Кроме того очень простым становится откат и обновление.
А если выйти за рамки php там вообще начинается дивный новый мир.
Может, вопрос в bus-factor данного решения и стоимости поддержки.
Бесспорно, на небольших проектах это имеет место, но при росте сложности проекта и увеличении размера команды такие решения начинают существенно проигрывать тому же докеру.
IMHO сложность использования docker несколько преувеличена.
На моём опыте, большая часть его противников или не хотят изучать технологию, или не хотят ничего менять в своей работе — им и так хорошо и всё устраивает, в том числе много ручных операций и портянки скриптов и/или YAML, т.к. это делает их незаменимыми.
К сожалению аргументированный отказ от docker на основе именно его технических минусов — очень редкое явление, в основном аргументация на уровне «я слышал/читал что это плохо», без личного опыта и понимания технологии.
Для отправки вы такой же самописный сервис используете, который сам ищет почтовые сервера в целевых доменах, общается с ними по smtp и управляет очередью повторов и т.п.?
Я к тому, что прикрутить imap к существующему postfix/exim надежнее и дешевле.
Как вариант, можно ещё просто складывать почту существующим почтовым сервером в mailbox/maildir форматах и просто разбирать файлы.
В таком раскладе не нужно реализовывать проверки spf, dkim и т.п. и в дальнейшем поддерживать этот код, решать проблемы безопасности.
Да, отбойники большинство сервисов шлют или в формате https://tools.ietf.org/html/rfc3464 или используя заголовки X-Failed-Recipients
Rspamd, попробуйте, если ещё не пробовали
И да full view и не один держит не напрягаясь frr на рядовом железе, проблема в data plane и его задержках при использовании ядра linux, а не в control plane.
Есть подвижки с DPDK и eBPF+XDP но они пока не могут быть применены достаточно широко т.к. это инструменты для разработки, а не готовое решение конкретных задач.
Нет TNSR пощупать не получилось, но щупал ванильный fd.io на самосборе с интеловвми картами — он показал line rate на маршрутизации без NAT и фильтров между 2 10G. TNSR построен на fd.io с рядом оптимизаций так что на базе опыта с fd.io я склонен доверять заявленным показателям.
Cumulus это про коммутаторы пока что, full view он там не переварит.
10G на line rate это проблема если PPS большой, пока его пережёвывает только fd.io поверх DPDK и продукты построенные на нём, например https://www.tnsr.com/
А вот MX и аналоги спокойно справляются.
Стоковое ядро с тюненным sysctl живёт до первого DDoS на 10mpps потом становится весело.
Пока нет, возможно позже.
С самим кумулусом проблем не сильно много, у нас больше проблем с обвязкой управления сетью которая досталась в наследство.
Разница с вендорами — нужно детально понимать как работают все компоненты, что-бы всё было стабильно, впрочем как и с любыми комплексными OSS решениями из мира linux.
Какие решения посоветуете?
Именно в разрезе замены MX?
Софт роутер это хорошо, но при скоростях 10G+ становится грустно даже с NAT и просто маршрутизацией уже на средних PPS.
Не тут вопрос был в разрезе именно DPDK.
Просто что вы описали я и так знаю — у меня сеть в ДЦ на white box коммутаторах и Cumulus.
FRR так же активно используем.
Про DPDK и MX разверните пожалуйста.
Если это про fd.io то он IMHO пока больше Фреймворк для создания своего ПО чем продукт который можно в бой пускать.
Если что-то иное — поделитесь пожалуйста тема интересна.
Вам никто не мешает использовать bind mount и не использовать volumes.
Но да в таком раскладе могут быть нюансы.
Docker это всё-таки стандарт, в отличии от самописных скриптов, который со временем разрастаются, поэтому найти на рынке специалистов, которые его знают будет проще.
Основные факторы это:
Из них как правило вытекают размер инфраструктуры, которую нужно поддерживать и сложность развёртывания.
Плюс с ростом команды появляется класс проблем, связанный с тестированием всех изменений, которые делаются в проекте, откуда появляется необходимость простого развёртывания нескольких веток по необходимости.
Причём чем быстрее нужно вносить изменения, тем нужнее системы CI/CD, а в большой инфраструктуре сложного проекта docker сильно облегчает процессы тестирования и деплоя, особенно когда серверов не 2 и не 10.
Он принципиально отличается от bash, ansible и т.п. тем, что у вас нет предыдущего состояния (точнее оно всегда известно — это состояние образа с которого вы начинаете), поэтому он исключает класс проблем вида «для установки этой библиотеки для этой зависимости, мне сначала нужно откатить предыдущее», а так же ситуации, когда в среде исполнения приложения кто-то из администраторов и разработчиков что-то поправил руками, но не задокументировал и не вписал в тот же ansible.
Другими словами с docker у вас всегда конфигурация системы начинается с чистого листа.
Определённо, затаскивать в любой проект любую технологию, потому что это «стильно, модно, молодёжно» не стоит.
Но многие приносят docker в проект для более простого решения класса задач, которые вас, как программиста могут не касаться.
В разрезе python / django это может быть установка пакетов, требующих компиляции нативных расширений, когда у вас 50 серверов это становится болезненно и долго — проще один раз собрать docker image, посте чего скачать его на все сервера и запустить тем же ansible.
При использовании ansible без docker он очень быстро разрастается и сложность его понимания и входа для нового DevOps/SRE становится существенной.
Не всё что вам кажется «бездумным пихаением» может быть этим на самом деле, возможно просто с вашей точки зрения это только кажется.
Не исключаю, что для вашего проекта эта технология не нужна, а волосы людей, ответственных за поддержку проекта со стороны инфраструктуры вместе с теми, кто отвечает за деплой, мягкие и шелковистые.
Но всё это может быть не так в иных ситуациях.
Доступ к docker socket в RO, это всё-таки не рут права (RW — можно так назвать).
Бонусом докера является возможность не доставлять те же модули php на конечные машины, это не боль при условии, что у вас один сервер и свежий проект, а когда их несколько и проект требует старый php, которых нет в свежих дистрибутивах, или состав этих модулей периодически меняется.
В таком случае вы получаете сильное упрощение в Operations с не не очень существенным усложнением в Dev.
Кроме того очень простым становится откат и обновление.
А если выйти за рамки php там вообще начинается дивный новый мир.
Бесспорно, на небольших проектах это имеет место, но при росте сложности проекта и увеличении размера команды такие решения начинают существенно проигрывать тому же докеру.
IMHO сложность использования docker несколько преувеличена.
На моём опыте, большая часть его противников или не хотят изучать технологию, или не хотят ничего менять в своей работе — им и так хорошо и всё устраивает, в том числе много ручных операций и портянки скриптов и/или YAML, т.к. это делает их незаменимыми.
К сожалению аргументированный отказ от docker на основе именно его технических минусов — очень редкое явление, в основном аргументация на уровне «я слышал/читал что это плохо», без личного опыта и понимания технологии.
Посмотрите на Opennebula, возможно она вам подойдёт
Я к тому, что прикрутить imap к существующему postfix/exim надежнее и дешевле.
Как вариант, можно ещё просто складывать почту существующим почтовым сервером в mailbox/maildir форматах и просто разбирать файлы.
В таком раскладе не нужно реализовывать проверки spf, dkim и т.п. и в дальнейшем поддерживать этот код, решать проблемы безопасности.
Да, отбойники большинство сервисов шлют или в формате https://tools.ietf.org/html/rfc3464 или используя заголовки X-Failed-Recipients