Коллеги, FPGA в сетевых железках у нас встречаются чаще, чем кажется 🙂
В «Цифровых решениях» мы тоже активно используем FPGA — например, в брокере сетевых пакетов и балансировщике нагрузки. Последний, к слову, можно применять для кластеризации NGFW, что как раз перекликается с темой статьи.
Считается хеш, и часть полей пакета хранится для обработки коллизий. Полностью алгоритм мы не раскрываем. Напишите на почту задачу, и вместе определим, подходит он вам или нет. С учетом того, что разработка целиком наша, можем, при целесообразности, откорректировать.
То есть и последний тезис об отсутствии мониторинга российских даркнетов оказался несостоятельным. Ведь если этим занимаются отдельные компании с отдельным продуктом, то и заслуги впшей в жтом нет и ваш балансировщик просто лишён части функциональности. Рекламировать это как преимущество - ну, особый дар - на Жигулях вам никогда не разобьёт нос подушка безопасности. Ведь у Жигулей нет этих подушек!
Позвольте уточнить: в статье речь идёт не об отдельных продуктах, а о предынтегрированном решении, где аппаратный балансировщик и WAF работают как единый комплекс. Именно решение в целом, с учётом всех компонентов и их взаимодействия, обеспечивает заявленную функциональность — включая анализ локальных угроз, устойчивость к отказам и производительность. Если продолжать автомобильную аналогию — любой современный автомобиль собирается из модулей разных производителей: тормозная система — одного, электроника — другого, шины — третьего. Но потребитель покупает не комплектующие, а целостное транспортное средство, за которое отвечает автопроизводитель. И именно он гарантирует, что все части работают слаженно. Так и здесь: наша задача — не просто предоставить железо, а собрать и сопровождать надёжную платформу, в которую уже интегрированы балансировка, отказоустойчивость и защита веб-приложений.
Означает ли это, что вы утверждаете, что с помощью "западных решений" это невозможно сделать?
Нет, мы не утверждаем, что западные балансировщики не умеют распределять трафик. Это, безусловно, зрелые решения с широкими возможностями. Наш тезис в другом: мы предлагаем альтернативный подход, в котором специализированный аппаратный балансировщик и адаптированный под российские реалии WAF работают как единое решение. Такой прединтегрированный формат позволяет быстрее внедрять, проще сопровождать и учитывать локальные особенности — технические, нормативные и организационные. Речь не о том, что «там не умеют», а о том, что мы по-другому расставили приоритеты и собрали решение под задачи, актуальные для отечественного рынка.
То есть вашей заслуги в этом нет, а подключить стороннюю подсистему можно при использовании любого балансировшика? В чём же ваше преимущество?
Да, теоретически никто не запрещает подключить стороннюю систему защиты к любому балансировщику — как и собрать автомобиль из деталей разных производителей. Но ключевое отличие — в уровне интеграции, зрелости связки и ответственности за конечный результат. Мы —производитель первого полноценного аппаратного балансировщика нагрузки на российском рынке, и одна из наших ключевых задач — развитие экосистемы прединтегрированных решений совместно с российскими разработчиками ИБ-систем. Это означает:
заранее протестированную и оптимизированную связку,
готовые сценарии внедрения,
совместную техническую поддержку,
развитие функциональности с учётом локальных реалий и обратной связи от клиентов.
То есть строим совместно с партнёрами комплексные решения, в которых каждый компонент усиливает другой. Именно это и даёт конечному заказчику реальное преимущество — в скорости внедрения, удобстве эксплуатации и устойчивости к атакам, актуальным для российских систем.
Кажется, я понял посыл. Ваше устройство, получается, оптимизировано для DPI. Да, в этом случае, риторика противопоставления "вражеской" технике мало подходящей для цензурирования трафика, действительно оправдана. Для специфической аудитории. Да, наверное, целевой :(
Благодарим за ваш отклик. Хотим уточнить: наше устройство является аппаратным балансировщиком нагрузки и оптимизировано именно под задачи высокопроизводительной балансировки трафика. Оно не связано с функциями фильтрации, цензурирования или интеграции с системами типа СОРМ. Речь в статье шла о технических аспектах построения решения по защите веб-приложений, а не о контроле контента или передаче данных в сторонние системы наблюдения или цензурирования трафика.
на мой взгляд, это не причины, а общие слова, ничем не подкреплённые. По-прежнему уверен, что "российские уязвимости" ничем не отличаются от "западных уязвимостей".
Согласны, что базовые уязвимости (XSS, SQLi, RCE и др.) универсальны. Мы не утверждаем, что в России есть особые “уникальные” уязвимости. Речь о другом — российские веб-приложения работают в специфической среде: с учётом языка, нормативных требований, инфраструктурных особенностей и источников угроз. Поэтому, даже при общемировом наборе атак, подход к защите должен учитывать локальный контекст. Это требует постоянной адаптации и аналитики — чем, в частности, и занимаются наши коллеги из SolidWall.
разве что, вот это интересно и даже хотелось бы узнать подробнеее. Получается, что вы во-первых, мониторите вот это всё, во-вторых, на основе мониторинга добавляете правила, в третьих перепрограммируете свой аппаратный FPGA-based балансер? Удалённо? По подписке? Если можно перепрограммировать эти правила, то, получается, разница с "вражескими" железками только в доп сервисе, а не в преимуществе одной железки над другой? То есть опять этот пункт мимо (а тогда и вышестоящие при всей изначальной спорности, тоже получаются не относящимися к устройству). Да, а вы этот сервис, получается, предоставляете?
Мониторингом веб-угроз, анализом специфики атак и регулярным обновлением сигнатур занимаются наши коллеги из SolidWall. Они развивают собственный WAF-продукт, адаптируя его под реалии Рунета. Мы, в свою очередь, отвечаем за аппаратную балансировку трафика на кластеры WAF и backend-серверов обеспечивая отказоустойчивость и высокую производительность всей системы.
Таким образом, мы реализуем подход «best of breed» — когда решение строится из отдельных специализированных компонентов, каждый из которых оптимален в своей области:
аппаратный балансировщик — под производительность и устойчивость;
WAF — под гибкую и актуальную защиту.
В статье мы противопоставляем эту архитектуру классическому западному подходу «best of suite», где все функции (включая балансировку, защиту, ускорение, кеширование и пр.) собраны в одном универсальном устройстве или облачной платформе.
Уважаемый коллега, благодарим за развернутые комментарии.
Да, вы абсолютно правы — современные западные решения представляют собой гибридную архитектуру, где основная обработка ведётся на CPU, а часть задач (например, шифрование или ускорение TCP/HTTP) разгружается на специализированные чипы. И действительно, речь уже идет не просто о балансировщиках, а о полноценных ADC (Application Delivery Controller), включающих не только L4–L7-балансировку, но и функции безопасности, оптимизации трафика и др. Однако, как показывает практика, реализовать каждую из этих функций в виде отдельного аппаратного ускорителя невозможно. В итоге ключевые компоненты всё равно конкурируют за ресурсы центрального процессора. Отдельно хотелось бы отметить, что, по нашему опыту, многие функции ADC приобретаются "на вырост" или "на всякий случай", но на практике так и остаются неактивными либо не интегрированными в реальную инфраструктуру заказчика. Причин много: сложность внедрения, отсутствие компетенций, избыточность для текущих задач.
Действительно, такие решения, как Cloudflare, Imperva, Akamai, AWS WAF или Google Cloud Armor, обладают развитым функционалом и применяют современные технологии, включая ML/NLP, в том числе для обработки текстов на разных языках. Однако важно подчеркнуть, что вы описываете решения класса Cloud WAAP (Web Application and API Protection) — то есть облачные сервисы, предоставляющие WAF как услугу с функциями защиты L7, DDoS mitigation, rate limiting и т.д. Мы же в статье говорим о внедрении WAF внутри инфраструктуры компании (on-premises или private cloud), то есть о совершенно другом классе решений, отличающемся по архитектуре, требованиям и применимости в российском контексте.
Уважаемый коллега, приглашаем вас присоединиться к аргументированной дискуссии о технических аспектах балансировки и защиты веб-приложений. Только через профессиональный диалог мы можем сделать отечественные решения действительно сильнее.
Уважаемый коллега, благодарим за ваш комментарий — приятно видеть, что дискуссия принимает более предметный характер.
Так как в случае западных решений речь идет о L7-баланасировщиках, то в этом контексте нам действительно не известны модели западных балансировщиков, где бы вся логика обработки на уровне L7 выполнялась аппаратно — на FPGA или ASIC. Как правило, даже при наличии аппаратных ускорителей (например, для SSL/TLS offload), основная логика L7 остаётся программной и исполняется на x86 CPU общего назначения.
Если у вас есть примеры моделей, реализующих полноценную L7-балансировку на FPGA, будем признательны за указание — это действительно важно для понимания архитектурных трендов и эволюции решений.
Что касается защиты веб-приложений: утверждение, что российские приложения не требуют специфического подхода к защите, на наш взгляд, спорно. Ниже — основные причины:
Языковая специфика (обработка вредоносных запросов на русском языке, в том числе с учетом морфологии, кодировок, обходов).
Культурные и социальные особенности фишинга и социальной инженерии, завязанные на российский контекст.
Локальные паттерны атак.
Опыт интеграции с ПО и понимание бизнес-процессов, характерных для российских компаний.
Отсутствие мониторинга российского DarkNet/Telegram-сегмента в западных Threat Intelligence-платформах.
Если у вас есть практические примеры успешной защиты русскоязычных и юридически значимых веб-приложений западными WAF/балансировщиками с учетом вышеуказанных нюансов — будем рады обсудить.
На данный момент действительно представлена одна модель, однако мы активно работаем над расширением продуктовой линейки, и в течение следующего года планируем представить новые модификации. Чтобы лучше понять актуальные потребности, нам было бы очень полезно узнать вашу точку зрения:
Есть ли интерес к компактным форм-факторам?
Какие типы интерфейсов и портовой ёмкости наиболее востребованы в ваших сценариях?
Благодарим за ваш комментарий и уточнение. Хотим прояснить, что на нашем тестовом стенде реализован DNAT, а не SNAT. При этом мы поддерживаем варианты интеграции как на уровне L3, так и на L2 — в зависимости от требований конкретной сетевой архитектуры. Судя по вашему комментарию, у вас, возможно, есть практическая задача или сценарий, который важно корректно учесть с точки зрения совместимости и топологии. Мы будем рады обсудить её детально с нашими техническими специалистами — например, в нашем Telegram-чате по DS Proxima, где можно быстро и напрямую задать вопросы.
Здравствуйте! Спасибо за ваш развёрнутый комментарий и внимание к деталям. Ниже уточнения:
В решении DS Proxima используется аппаратная обработка трафика на FPGA, а не на GPU (возможно Вы имели ввиду CPU). Это даёт значительные преимущества:
Стабильная производительность до 1 Тбит/с, что с лихвой покрывает потребности в 99.9% реальных сценариев и обеспечивает эффективную обработку трафика любой скорости.
Низкое энергопотребление — порядка 200 Вт, что существенно выгоднее по сравнению с архитектурами на чистом x86.
Высокая надёжность, поскольку аппаратная обработка на FPGA не зависит от операционной системы, уменьшая потенциальные риски и точки отказа.
Когда мы упоминали использование x86 ядер в западных балансировщиках, речь шла именно о функциях, связанных с балансировкой нагрузки и WAF, а не об обработке HTTPS.
Таким образом, архитектура DS Proxima представляет собой сбалансированное решение, сочетающее мощную аппаратную обработку трафика с возможностью менять функциональные возможности, что обеспечивает и высокую производительность, и адаптивность системы.
2. Вопрос касательно TLS мы довольно детально разобрали в нашей предыдущей статье “Нужен ли внешний SSL-офлоадинг, если Intel уже встроила его прямо в CPU?” Там мы показываем, что начиная с серверных процессоров Intel Xeon 4-го поколения TLS-терминацию можно выполнять прямо на сервере — быстро и эффективно. Встроенный в CPU криптоускоритель Intel QAT открывает путь к распределённой обработке HTTPS-трафика без компромиссов по производительности и надёжности. Это подтверждается также тестами программных версий F5 и Citrix NetScaler которые обеспечивают уровень производительности, сопоставимый с аппаратными ASIC-ускорителями.
3. Спешим развеять ваши сомнения касательно архитектуры решения. В нашей схеме используется не двойной NAT (SNAT + DNAT), а только DstNAT (Destination NAT). Как это работает в нашей архитектуре:
Балансировщик выполняет только DNAT, то есть меняет только адрес назначения пакета, перенаправляя трафик на нужный WAF. При этом исходный IP-адрес клиента (source IP) сохраняется неизменным в пакете, так как SNAT не применяется.
Благодаря этому WAF видит реальный source IP клиента, а не IP балансировщика. Поскольку WAF получает корректные исходные IP, все механизмы, завязанные на IP, включая GeoIP-фильтрацию, белые и черные списки, работают корректно и эффективно. Нет необходимости в дополнительной обработке X-Forwarded-For (XFF) или X-Real-IP (XRI) заголовков для восстановления исходного IP, что упрощает архитектуру и повышает надёжность системы.
Спасибо за ваше мнение. Однако хотелось бы напомнить, что на Хабре приветствуется конструктивный и уважительный диалог без оскорблений и провокаций. Предлагаю сосредоточиться на сути обсуждения и избегать необоснованных обвинений.
Добрый день! Приведённые в статье цифры как раз иллюстрируют разницу в производительности OpenSSL с подключённым Intel QAT Engine и без него. Доступ к возможностям Intel QAT осуществляется прозрачно через Intel® QAT Engine for OpenSSL, без необходимости глубокой модификации приложений. Более подробно методика тестирования и конфигурация описаны в документе Intel QuickAssist Technology (QAT) – NGINX Performance white paper, на который мы ссылаемся в статье — там есть все детали сравнения.
Поддержка Intel QAT действительно зависит от версий и конфигурации софта. Основные компоненты, через которые можно задействовать аппаратное ускорение — это OpenSSL (через QAT_Engine), а также соответствующие патчи или настройки в NGINX и ядре Linux. Для начала работы рекомендуем ознакомиться с официальной документацией от Intel: https://github.com/intel/QAT_Engine#installation-instructions
Что касается брокеров сетевых пакетов, это многофункциональное решение для оптимизации трафика, подробнее в этой статье (https://habr.com/ru/companies/dsol/articles/490252/) — там описаны и основные сценарии использования, и архитектурные особенности.
Здравствуйте! Наш балансировщик уже сегодня обеспечивает контроль состояния кластера на уровне L7, что позволяет гибко управлять распределением трафика на тот же WAF (сейчас активно тестируемся, результатами поделимся в наших следующих статьях).
Глубоко в L7-балансировку мы погружаться не планируем, дабы не разрабатывать 45й российский NGFW фунционал, уже имеющийся у российских вендоров. Необходимость дальнейшего развития балансировщика в L7 будем определять исходя из потребностей заказчиков. Поделитесь, какой именно функционал важен в вашем сценарии?
Каталог в целом производит впечатление полупустого. Одни потенциально интересные мне разделы не содержат ничего, вот прям ноль блоков:
Логично, что каких-то блоков пока нет (или разработчики о них умалчивают по каким-то причинам). На требуемые блоки можно оформить заявку и подождать отклика.
узнать о нём без регистрации всё равно нельзя.
Чтобы зарегистрироваться на сайте, нужно предоставить почтовый адрес, телефон и ИНН компании, а также «ФИО ответственного лица»
Регистрация от лица компании - необходимая мера. Каждый разработчик сам заявляет о своей Intellectual Property с подтвержденного аккаунта. К тому же не все готовы сейчас открыто рассказывать про свой потенциал.
Коллеги, FPGA в сетевых железках у нас встречаются чаще, чем кажется 🙂
В «Цифровых решениях» мы тоже активно используем FPGA — например, в брокере сетевых пакетов и балансировщике нагрузки. Последний, к слову, можно применять для кластеризации NGFW, что как раз перекликается с темой статьи.
Считается хеш, и часть полей пакета хранится для обработки коллизий. Полностью алгоритм мы не раскрываем. Напишите на почту задачу, и вместе определим, подходит он вам или нет. С учетом того, что разработка целиком наша, можем, при целесообразности, откорректировать.
Ссылку на тг поправили, спасибо!
Исправились!)
Позвольте уточнить: в статье речь идёт не об отдельных продуктах, а о предынтегрированном решении, где аппаратный балансировщик и WAF работают как единый комплекс. Именно решение в целом, с учётом всех компонентов и их взаимодействия, обеспечивает заявленную функциональность — включая анализ локальных угроз, устойчивость к отказам и производительность.
Если продолжать автомобильную аналогию — любой современный автомобиль собирается из модулей разных производителей: тормозная система — одного, электроника — другого, шины — третьего. Но потребитель покупает не комплектующие, а целостное транспортное средство, за которое отвечает автопроизводитель. И именно он гарантирует, что все части работают слаженно.
Так и здесь: наша задача — не просто предоставить железо, а собрать и сопровождать надёжную платформу, в которую уже интегрированы балансировка, отказоустойчивость и защита веб-приложений.
Нет, мы не утверждаем, что западные балансировщики не умеют распределять трафик. Это, безусловно, зрелые решения с широкими возможностями.
Наш тезис в другом: мы предлагаем альтернативный подход, в котором специализированный аппаратный балансировщик и адаптированный под российские реалии WAF работают как единое решение. Такой прединтегрированный формат позволяет быстрее внедрять, проще сопровождать и учитывать локальные особенности — технические, нормативные и организационные.
Речь не о том, что «там не умеют», а о том, что мы по-другому расставили приоритеты и собрали решение под задачи, актуальные для отечественного рынка.
Да, теоретически никто не запрещает подключить стороннюю систему защиты к любому балансировщику — как и собрать автомобиль из деталей разных производителей. Но ключевое отличие — в уровне интеграции, зрелости связки и ответственности за конечный результат.
Мы —производитель первого полноценного аппаратного балансировщика нагрузки на российском рынке, и одна из наших ключевых задач — развитие экосистемы прединтегрированных решений совместно с российскими разработчиками ИБ-систем. Это означает:
заранее протестированную и оптимизированную связку,
готовые сценарии внедрения,
совместную техническую поддержку,
развитие функциональности с учётом локальных реалий и обратной связи от клиентов.
То есть строим совместно с партнёрами комплексные решения, в которых каждый компонент усиливает другой. Именно это и даёт конечному заказчику реальное преимущество — в скорости внедрения, удобстве эксплуатации и устойчивости к атакам, актуальным для российских систем.
Благодарим за ваш отклик. Хотим уточнить: наше устройство является аппаратным балансировщиком нагрузки и оптимизировано именно под задачи высокопроизводительной балансировки трафика.
Оно не связано с функциями фильтрации, цензурирования или интеграции с системами типа СОРМ. Речь в статье шла о технических аспектах построения решения по защите веб-приложений, а не о контроле контента или передаче данных в сторонние системы наблюдения или цензурирования трафика.
Согласны, что базовые уязвимости (XSS, SQLi, RCE и др.) универсальны. Мы не утверждаем, что в России есть особые “уникальные” уязвимости. Речь о другом — российские веб-приложения работают в специфической среде: с учётом языка, нормативных требований, инфраструктурных особенностей и источников угроз.
Поэтому, даже при общемировом наборе атак, подход к защите должен учитывать локальный контекст. Это требует постоянной адаптации и аналитики — чем, в частности, и занимаются наши коллеги из SolidWall.
Мониторингом веб-угроз, анализом специфики атак и регулярным обновлением сигнатур занимаются наши коллеги из SolidWall. Они развивают собственный WAF-продукт, адаптируя его под реалии Рунета. Мы, в свою очередь, отвечаем за аппаратную балансировку трафика на кластеры WAF и backend-серверов обеспечивая отказоустойчивость и высокую производительность всей системы.
Таким образом, мы реализуем подход «best of breed» — когда решение строится из отдельных специализированных компонентов, каждый из которых оптимален в своей области:
аппаратный балансировщик — под производительность и устойчивость;
WAF — под гибкую и актуальную защиту.
В статье мы противопоставляем эту архитектуру классическому западному подходу «best of suite», где все функции (включая балансировку, защиту, ускорение, кеширование и пр.) собраны в одном универсальном устройстве или облачной платформе.
Уважаемый коллега, благодарим за развернутые комментарии.
Да, вы абсолютно правы — современные западные решения представляют собой гибридную архитектуру, где основная обработка ведётся на CPU, а часть задач (например, шифрование или ускорение TCP/HTTP) разгружается на специализированные чипы. И действительно, речь уже идет не просто о балансировщиках, а о полноценных ADC (Application Delivery Controller), включающих не только L4–L7-балансировку, но и функции безопасности, оптимизации трафика и др. Однако, как показывает практика, реализовать каждую из этих функций в виде отдельного аппаратного ускорителя невозможно. В итоге ключевые компоненты всё равно конкурируют за ресурсы центрального процессора. Отдельно хотелось бы отметить, что, по нашему опыту, многие функции ADC приобретаются "на вырост" или "на всякий случай", но на практике так и остаются неактивными либо не интегрированными в реальную инфраструктуру заказчика. Причин много: сложность внедрения, отсутствие компетенций, избыточность для текущих задач.
Действительно, такие решения, как Cloudflare, Imperva, Akamai, AWS WAF или Google Cloud Armor, обладают развитым функционалом и применяют современные технологии, включая ML/NLP, в том числе для обработки текстов на разных языках. Однако важно подчеркнуть, что вы описываете решения класса Cloud WAAP (Web Application and API Protection) — то есть облачные сервисы, предоставляющие WAF как услугу с функциями защиты L7, DDoS mitigation, rate limiting и т.д. Мы же в статье говорим о внедрении WAF внутри инфраструктуры компании (on-premises или private cloud), то есть о совершенно другом классе решений, отличающемся по архитектуре, требованиям и применимости в российском контексте.
Уважаемый коллега, приглашаем вас присоединиться к аргументированной дискуссии о технических аспектах балансировки и защиты веб-приложений. Только через профессиональный диалог мы можем сделать отечественные решения действительно сильнее.
Уважаемый коллега, благодарим за ваш комментарий — приятно видеть, что дискуссия принимает более предметный характер.
Так как в случае западных решений речь идет о L7-баланасировщиках, то в этом контексте нам действительно не известны модели западных балансировщиков, где бы вся логика обработки на уровне L7 выполнялась аппаратно — на FPGA или ASIC. Как правило, даже при наличии аппаратных ускорителей (например, для SSL/TLS offload), основная логика L7 остаётся программной и исполняется на x86 CPU общего назначения.
Если у вас есть примеры моделей, реализующих полноценную L7-балансировку на FPGA, будем признательны за указание — это действительно важно для понимания архитектурных трендов и эволюции решений.
Что касается защиты веб-приложений: утверждение, что российские приложения не требуют специфического подхода к защите, на наш взгляд, спорно. Ниже — основные причины:
Языковая специфика (обработка вредоносных запросов на русском языке, в том числе с учетом морфологии, кодировок, обходов).
Культурные и социальные особенности фишинга и социальной инженерии, завязанные на российский контекст.
Локальные паттерны атак.
Опыт интеграции с ПО и понимание бизнес-процессов, характерных для российских компаний.
Отсутствие мониторинга российского DarkNet/Telegram-сегмента в западных Threat Intelligence-платформах.
Если у вас есть практические примеры успешной защиты русскоязычных и юридически значимых веб-приложений западными WAF/балансировщиками с учетом вышеуказанных нюансов — будем рады обсудить.
На данный момент действительно представлена одна модель, однако мы активно работаем над расширением продуктовой линейки, и в течение следующего года планируем представить новые модификации. Чтобы лучше понять актуальные потребности, нам было бы очень полезно узнать вашу точку зрения:
Есть ли интерес к компактным форм-факторам?
Какие типы интерфейсов и портовой ёмкости наиболее востребованы в ваших сценариях?
Благодарим за ваш комментарий и уточнение.
Хотим прояснить, что на нашем тестовом стенде реализован DNAT, а не SNAT. При этом мы поддерживаем варианты интеграции как на уровне L3, так и на L2 — в зависимости от требований конкретной сетевой архитектуры.
Судя по вашему комментарию, у вас, возможно, есть практическая задача или сценарий, который важно корректно учесть с точки зрения совместимости и топологии. Мы будем рады обсудить её детально с нашими техническими специалистами — например, в нашем Telegram-чате по DS Proxima, где можно быстро и напрямую задать вопросы.
удалено
Здравствуйте! Спасибо за ваш развёрнутый комментарий и внимание к деталям. Ниже уточнения:
В решении DS Proxima используется аппаратная обработка трафика на FPGA, а не на GPU (возможно Вы имели ввиду CPU). Это даёт значительные преимущества:
Стабильная производительность до 1 Тбит/с, что с лихвой покрывает потребности в 99.9% реальных сценариев и обеспечивает эффективную обработку трафика любой скорости.
Низкое энергопотребление — порядка 200 Вт, что существенно выгоднее по сравнению с архитектурами на чистом x86.
Высокая надёжность, поскольку аппаратная обработка на FPGA не зависит от операционной системы, уменьшая потенциальные риски и точки отказа.
Когда мы упоминали использование x86 ядер в западных балансировщиках, речь шла именно о функциях, связанных с балансировкой нагрузки и WAF, а не об обработке HTTPS.
Таким образом, архитектура DS Proxima представляет собой сбалансированное решение, сочетающее мощную аппаратную обработку трафика с возможностью менять функциональные возможности, что обеспечивает и высокую производительность, и адаптивность системы.
2. Вопрос касательно TLS мы довольно детально разобрали в нашей предыдущей статье “Нужен ли внешний SSL-офлоадинг, если Intel уже встроила его прямо в CPU?” Там мы показываем, что начиная с серверных процессоров Intel Xeon 4-го поколения TLS-терминацию можно выполнять прямо на сервере — быстро и эффективно. Встроенный в CPU криптоускоритель Intel QAT открывает путь к распределённой обработке HTTPS-трафика без компромиссов по производительности и надёжности. Это подтверждается также тестами программных версий F5 и Citrix NetScaler которые обеспечивают уровень производительности, сопоставимый с аппаратными ASIC-ускорителями.
3. Спешим развеять ваши сомнения касательно архитектуры решения. В нашей схеме используется не двойной NAT (SNAT + DNAT), а только DstNAT (Destination NAT). Как это работает в нашей архитектуре:
Балансировщик выполняет только DNAT, то есть меняет только адрес назначения пакета, перенаправляя трафик на нужный WAF. При этом исходный IP-адрес клиента (source IP) сохраняется неизменным в пакете, так как SNAT не применяется.
Благодаря этому WAF видит реальный source IP клиента, а не IP балансировщика. Поскольку WAF получает корректные исходные IP, все механизмы, завязанные на IP, включая GeoIP-фильтрацию, белые и черные списки, работают корректно и эффективно. Нет необходимости в дополнительной обработке X-Forwarded-For (XFF) или X-Real-IP (XRI) заголовков для восстановления исходного IP, что упрощает архитектуру и повышает надёжность системы.
Спасибо за ваше мнение. Однако хотелось бы напомнить, что на Хабре приветствуется конструктивный и уважительный диалог без оскорблений и провокаций. Предлагаю сосредоточиться на сути обсуждения и избегать необоснованных обвинений.
Добрый день! Приведённые в статье цифры как раз иллюстрируют разницу в производительности OpenSSL с подключённым Intel QAT Engine и без него. Доступ к возможностям Intel QAT осуществляется прозрачно через Intel® QAT Engine for OpenSSL, без необходимости глубокой модификации приложений.
Более подробно методика тестирования и конфигурация описаны в документе Intel QuickAssist Technology (QAT) – NGINX Performance white paper, на который мы ссылаемся в статье — там есть все детали сравнения.
Поддержка Intel QAT действительно зависит от версий и конфигурации софта. Основные компоненты, через которые можно задействовать аппаратное ускорение — это OpenSSL (через QAT_Engine), а также соответствующие патчи или настройки в NGINX и ядре Linux.
Для начала работы рекомендуем ознакомиться с официальной документацией от Intel:
https://github.com/intel/QAT_Engine#installation-instructions
Использование SPAN-портов для зеркалирования работало хоть как-то предсказуемо лет 15 назад (на маленьких потоках). Тема довольно глубокая, и если кому-то интересно разобраться в деталях, можно почитать, например, этот разбор ограничений SPAN (https://habr.com/ru/companies/dsol/articles/579374/) и более подробное сравнение TAP и SPAN (https://habr.com/ru/companies/dsol/articles/568768/).
Что касается брокеров сетевых пакетов, это многофункциональное решение для оптимизации трафика, подробнее в этой статье (https://habr.com/ru/companies/dsol/articles/490252/) — там описаны и основные сценарии использования, и архитектурные особенности.
Здравствуйте!
Наш балансировщик уже сегодня обеспечивает контроль состояния кластера на уровне L7, что позволяет гибко управлять распределением трафика на тот же WAF (сейчас активно тестируемся, результатами поделимся в наших следующих статьях).
Глубоко в L7-балансировку мы погружаться не планируем, дабы не разрабатывать
45й российский NGFWфунционал, уже имеющийся у российских вендоров.Необходимость дальнейшего развития балансировщика в L7 будем определять исходя из потребностей заказчиков. Поделитесь, какой именно функционал важен в вашем сценарии?
Не считаем возможным отвечать за всех разработчиков. Наполнение общего каталога - дело нужное, но добровольное.
Логично, что каких-то блоков пока нет (или разработчики о них умалчивают по каким-то причинам). На требуемые блоки можно оформить заявку и подождать отклика.
Регистрация от лица компании - необходимая мера. Каждый разработчик сам заявляет о своей Intellectual Property с подтвержденного аккаунта. К тому же не все готовы сейчас открыто рассказывать про свой потенциал.
Ситуацию с отечественными IP можно оценить на ресурсе https://сф-блоки.рф/
В каталоге вы найдёте и PCI, и USB.
Безусловно, на данном ресурсе находятся не все, но каталог регулярно наполняется разными разработчиками.