По поводу дороговизны: в интернете много информации по сравнению стоимости ресурсов DPDK и eBPF. Эта статья не ставит задачу сравнивать эти подходы, они оба хороши в определённых случаях. Нам в условиях большого количества VLAN и транзитного способа обработки трафика использовать eBPF было выгоднее. Но если у вас есть экономический расчет, в частности, для транзитной защиты, будет интересно почитать.
Насчёт скорости разработки: я не знаю с какой конкретно проблемой вы сталкивались, какую задачу решали и почему у вас не получилось. Скорость разработки нас устраивает в пересчете на экономику решения. И еще раз подчеркну: это лишь одна из технологий, которую мы используем в рамках решения.
Под L2 мы имели в виду забивание канала (Amplification), в нашем случае множества каналов. Это то, с чем наша система борется (в числе прочего). Так как мы предоставляем транзитную защиту от DDoS-атак, мы защищаем каналы наших клиентов от переполнения.
Если хотите узнать подробнее про архитектуру нашей защиты, приглашаем вас продолжить дискуссию на наших будущих митапах и linkmetup. Мероприятия будут ближе к концу года. Можете подписаться на наш Telegram — мы обязательно выложим там анонс.
DPDK нам нравится, но для грубой чистки он слишком дорогой. eBPF мы выбрали, потому что он выигрывал по соотношению производительности, скорости разработки и, что самое главное, по итоговой цене (стоимости ресурсов в пересчёте на проходящий трафик). Это решение достаточно эффективно и не требует столько ресурсов, сколько иные подходы для грубой очистки.
Мы развиваем наши системы и способы фильтрации, и возможно, в будущем придём к DPDK как к дополнительному инструменту фильтрации. Сейчас мы думаем в сторону расширения kernel, но пойдем туда или нет — вопрос пока открытый. Это зависит от угроз, стоимости отражения и других факторов.
Проблемы и специфика eBPF нас ограничивает, но мы не планируем зацикливаться на нём. Например, для L7 мы используем другие решения. Для тонкой отчистки применяется более сложный подход, который мы решили не описывать в этой статье, чтобы не перегружать материал. То есть, система уже сейчас не строится только на eBPF, но он дёшево закрыл задачи грубой отчистки трафика.
По поводу L2: тут нужно больше контекста. Наши центры фильтрации располагаются по всему миру у разных операторов. И если коротко, то мы умеем перекидывать трафик в рамках наших anycast-сетей (больше подробностей дать не можем).
По поводу дороговизны: в интернете много информации по сравнению стоимости ресурсов DPDK и eBPF. Эта статья не ставит задачу сравнивать эти подходы, они оба хороши в определённых случаях. Нам в условиях большого количества VLAN и транзитного способа обработки трафика использовать eBPF было выгоднее. Но если у вас есть экономический расчет, в частности, для транзитной защиты, будет интересно почитать.
Насчёт скорости разработки: я не знаю с какой конкретно проблемой вы сталкивались, какую задачу решали и почему у вас не получилось. Скорость разработки нас устраивает в пересчете на экономику решения. И еще раз подчеркну: это лишь одна из технологий, которую мы используем в рамках решения.
Под L2 мы имели в виду забивание канала (Amplification), в нашем случае множества каналов. Это то, с чем наша система борется (в числе прочего). Так как мы предоставляем транзитную защиту от DDoS-атак, мы защищаем каналы наших клиентов от переполнения.
Если хотите узнать подробнее про архитектуру нашей защиты, приглашаем вас продолжить дискуссию на наших будущих митапах и linkmetup. Мероприятия будут ближе к концу года. Можете подписаться на наш Telegram — мы обязательно выложим там анонс.
DPDK нам нравится, но для грубой чистки он слишком дорогой. eBPF мы выбрали, потому что он выигрывал по соотношению производительности, скорости разработки и, что самое главное, по итоговой цене (стоимости ресурсов в пересчёте на проходящий трафик). Это решение достаточно эффективно и не требует столько ресурсов, сколько иные подходы для грубой очистки.
Мы развиваем наши системы и способы фильтрации, и возможно, в будущем придём к DPDK как к дополнительному инструменту фильтрации. Сейчас мы думаем в сторону расширения kernel, но пойдем туда или нет — вопрос пока открытый. Это зависит от угроз, стоимости отражения и других факторов.
Проблемы и специфика eBPF нас ограничивает, но мы не планируем зацикливаться на нём. Например, для L7 мы используем другие решения. Для тонкой отчистки применяется более сложный подход, который мы решили не описывать в этой статье, чтобы не перегружать материал. То есть, система уже сейчас не строится только на eBPF, но он дёшево закрыл задачи грубой отчистки трафика.
По поводу L2: тут нужно больше контекста. Наши центры фильтрации располагаются по всему миру у разных операторов. И если коротко, то мы умеем перекидывать трафик в рамках наших anycast-сетей (больше подробностей дать не можем).