Автору спасибо за действительно инженерный разбор без маркетинговой шелухи, большая редкость.
Пара уточняющих вопросов по архитектуре, которые возникли после прочтения:
В статье упоминается, что строится классификационное дерево в памяти. Учитывая отказ от First Match, корректно ли я понимаю, что на 88 тысячах правил итоговое дерево поиска получается более плоским и детерминированным по задержке, чем классический последовательный обход? И как миграция на объектную модель (когда объект будет раскрываться в десятки IP) повлияет на этот алгоритм в следующих релизах - пойдет ли перестроение дерева в рантайме?
По поводу изоляции CPU: 19% на дашборде при 100% утилизации ядер Dataplane — понятная ситуация. Реализован ли механизм предотвращения "Noisy Neighbor", когда, например, Elasticsearch внутри своего контейнера в момент ротации индексов внезапно начнет отъедать кэш L3 или каналы памяти у ядер Dataplane? Используется ли тут Intel RDT/CAT или жесткая изоляция только по ядрам?
И вопрос вдогонку про высокую доступность: HA-линк синхронизирует conntrack. Учитывая скорость установки соединений (сотни тысяч CPS в тестах), какой механизм гарантирует, что сессия уже ушла в Dataplane на Master, но еще не реплицировалась на Slave до момента падения? Отбрасывается ли такой трафик на резерве или Mirada умеет делать "session pickup" с повторной валидацией TCP?
Автору спасибо за действительно инженерный разбор без маркетинговой шелухи, большая редкость.
Пара уточняющих вопросов по архитектуре, которые возникли после прочтения:
В статье упоминается, что строится классификационное дерево в памяти. Учитывая отказ от First Match, корректно ли я понимаю, что на 88 тысячах правил итоговое дерево поиска получается более плоским и детерминированным по задержке, чем классический последовательный обход? И как миграция на объектную модель (когда объект будет раскрываться в десятки IP) повлияет на этот алгоритм в следующих релизах - пойдет ли перестроение дерева в рантайме?
По поводу изоляции CPU: 19% на дашборде при 100% утилизации ядер Dataplane — понятная ситуация. Реализован ли механизм предотвращения "Noisy Neighbor", когда, например, Elasticsearch внутри своего контейнера в момент ротации индексов внезапно начнет отъедать кэш L3 или каналы памяти у ядер Dataplane? Используется ли тут Intel RDT/CAT или жесткая изоляция только по ядрам?
И вопрос вдогонку про высокую доступность: HA-линк синхронизирует conntrack. Учитывая скорость установки соединений (сотни тысяч CPS в тестах), какой механизм гарантирует, что сессия уже ушла в Dataplane на Master, но еще не реплицировалась на Slave до момента падения? Отбрасывается ли такой трафик на резерве или Mirada умеет делать "session pickup" с повторной валидацией TCP?