Comments 25
Очень интересная статья, побольше бы таких, спасибо!
UFO just landed and posted this here
Планируете смотреть в сторону Intel DPDK и аналогичных решений?
Система мониторинга была сдана заказчику в марте, поэтому в ближайшее время каких-то улучшений не планируется (насколько мне известно).
Признаюсь, в январе-феврале были горячие деньки, когда после выкатывания новой фишечки, мы заходили в top с боязнью. В такие моменты у нас в комнате и произносились магические слова DPDK, ZeroCopy и пр. Но до использования этого у нас руки не дошли:
Во-первых, никто из нас с этим не работал ранее: большинство разработок у нас это embedded.
Во-вторых, был небольшой скепсис, что это нам поможет: мы явно видели, что потребление проца возрастает после включения определенной фишки в обработке, а нагрузка на сетевую карту была такой же.
В итоге, помимо алгоритмических оптимизаций в софте, мы сделали два архитектурных изменения:
Мы изначально понимали, что один htpdec не справится со всей нагрузкой, и его надо параллелить. Сначала мы делали балансировку на проце — был процесс htpmap, который принимал весь поток и распределял между несколькими htpdec'ами. Получалось, что по факту этот процесс копирует данные из одного места в другие (из одного сокета в другие) и ел много CPU. Мы отказались от этого и решили сначала запустить четыре htpdec'a, которые будут слушать udp-порты, причем, htpdec0 слушает выход с линков 1 и 2, а htpdec1 — с 3 и 4 и так далее (так были настроены порты в MX'e). Так как линков было семь, равномерно, конечно, данные не распределялись (htpdec3 достался только линк 7). Так же, линки не были нагружены одинаково (да и иногда линки падали — и трафик перераспределялся на другие линки), и мы видели, что два процесса едят по 90%, а другие два по 45%. Нас это беспокоило, и мы запилили балансировку на уровне FPGA: считаем хэш от ip_src и отправляем на нужный udp-порт. Тем самым у нас все четыре процесса получают одинаковую нагрузку (вне зависимости от нагрузки и распределения на линках).
Изначально пакеты между MX и сервером были размером ~1500 байт, при нагрузке 3 Гбит/c это около 250K пакетов в секунду. Мы заставили MX отправлять нужные нам кусочки в jumbo фреймах (~8000 байт), а это получается около 47K пакетов в секунду. Как понимаете, это не совсем та нагрузка при которой надо расчехлять DPDK. К сожалению, у меня сейчас нет возможности посмотреть сколько приходит прерываний в секунду и сколько ест ksoftirq. Возможно, у Павла есть такая возможность)
Признаюсь, в январе-феврале были горячие деньки, когда после выкатывания новой фишечки, мы заходили в top с боязнью. В такие моменты у нас в комнате и произносились магические слова DPDK, ZeroCopy и пр. Но до использования этого у нас руки не дошли:
Во-первых, никто из нас с этим не работал ранее: большинство разработок у нас это embedded.
Во-вторых, был небольшой скепсис, что это нам поможет: мы явно видели, что потребление проца возрастает после включения определенной фишки в обработке, а нагрузка на сетевую карту была такой же.
В итоге, помимо алгоритмических оптимизаций в софте, мы сделали два архитектурных изменения:
Мы изначально понимали, что один htpdec не справится со всей нагрузкой, и его надо параллелить. Сначала мы делали балансировку на проце — был процесс htpmap, который принимал весь поток и распределял между несколькими htpdec'ами. Получалось, что по факту этот процесс копирует данные из одного места в другие (из одного сокета в другие) и ел много CPU. Мы отказались от этого и решили сначала запустить четыре htpdec'a, которые будут слушать udp-порты, причем, htpdec0 слушает выход с линков 1 и 2, а htpdec1 — с 3 и 4 и так далее (так были настроены порты в MX'e). Так как линков было семь, равномерно, конечно, данные не распределялись (htpdec3 достался только линк 7). Так же, линки не были нагружены одинаково (да и иногда линки падали — и трафик перераспределялся на другие линки), и мы видели, что два процесса едят по 90%, а другие два по 45%. Нас это беспокоило, и мы запилили балансировку на уровне FPGA: считаем хэш от ip_src и отправляем на нужный udp-порт. Тем самым у нас все четыре процесса получают одинаковую нагрузку (вне зависимости от нагрузки и распределения на линках).
Изначально пакеты между MX и сервером были размером ~1500 байт, при нагрузке 3 Гбит/c это около 250K пакетов в секунду. Мы заставили MX отправлять нужные нам кусочки в jumbo фреймах (~8000 байт), а это получается около 47K пакетов в секунду. Как понимаете, это не совсем та нагрузка при которой надо расчехлять DPDK. К сожалению, у меня сейчас нет возможности посмотреть сколько приходит прерываний в секунду и сколько ест ksoftirq. Возможно, у Павла есть такая возможность)
Зачем это нужно, если можно снимать эти же метрики с видеостриминговых серверов?
Это нужно в том случае, когда есть точка демаркации, по обе стороны которой находятся разные организации. Со своими интересами и особенностями.
И получается, что нужен объективный инструмент, способный, как арбитр в футболе, решить спорные ситуации.
И получается, что нужен объективный инструмент, способный, как арбитр в футболе, решить спорные ситуации.
Например, видео-стриминговый сервер может перестать справляться с нагрузкой. Что в этом случае произойдёт? Пользователь видео его не увидит. А кто в этом виноват? Оператор, который исправно обеспечивает транспорт видео до сервера?
И как нам в этом вопросе помогут метрики со стриминговых серверов, которые будут «рассказывать», что половину пакетов они просто не получили?
И как нам в этом вопросе помогут метрики со стриминговых серверов, которые будут «рассказывать», что половину пакетов они просто не получили?
Было бы интересно почитать про архитектуру сервера, БД и репортинга.
Я с удовольствием напишу…
На сервере мы использовали обычный (если можно так сказать) linux, debian, развернули пару контейнеров, через cgroup выдали каждому контейнеру по несколько ядер. Один контейнер занимается перелопачиванием трафика от MX'ов, а другой выполняет по cron'у генерацию отчётов. Для того, чтобы процессор не умирал на обработке прерываний, настроен interrupt coalescing и по ядрам раскидана обработка очередей (rss).
База у нас получилась самописная и она базируется на логах, которые ведёт svlogd. Я лично не считаю это большим достижением и немного остерегаюсь писать про ещё одну grepdb…
А репортинг построен на шелл-скриптах, которые парсят логи, проводят необходимую агрегацию результатов (считают количество всяких событий, означающих превышение порогов). При помощи gnuplot'а строят графики, а при помощи markdown'а генерируют html-странички.
На чём лучше сделать акцент? :)
На сервере мы использовали обычный (если можно так сказать) linux, debian, развернули пару контейнеров, через cgroup выдали каждому контейнеру по несколько ядер. Один контейнер занимается перелопачиванием трафика от MX'ов, а другой выполняет по cron'у генерацию отчётов. Для того, чтобы процессор не умирал на обработке прерываний, настроен interrupt coalescing и по ядрам раскидана обработка очередей (rss).
База у нас получилась самописная и она базируется на логах, которые ведёт svlogd. Я лично не считаю это большим достижением и немного остерегаюсь писать про ещё одну grepdb…
А репортинг построен на шелл-скриптах, которые парсят логи, проводят необходимую агрегацию результатов (считают количество всяких событий, означающих превышение порогов). При помощи gnuplot'а строят графики, а при помощи markdown'а генерируют html-странички.
На чём лучше сделать акцент? :)
А какие языки использовались?
о! я совсем забыл про TCP reassembling, который получился довольно интересным
А какие факторы повлияли на то, чтобы самописное решение по БД применить?
Еще интересно, смотрели в сторону pf_ring?
Еще интересно, смотрели в сторону pf_ring?
На самой заре проекта нужно было быстро-быстро показать макет. И мы сделали его за 2 недели! Через две недели после получения первых спеков мы уже были в тестовой зоне у заказчика с компом и MX'ом.
И за эти 2 недели сложилась определённая архитектура софта, ориентированная на быстрый результат, который можно показать. Так родилось решение: вывод демона (в текстовом виде), анализирущего трафик от MX'а пропускать через svlogd, а svlogd уже брал на себя задачу архивирования и проставление меток времени.
У этой простой схемы есть свои преимущества и недостатки. Но с задачей она всегда справлялась, поэтому поменять впоследствии её уже не удалось, т.к. была куча других насущных проблем вроде поддержки TCP-шных камер. Так до конечного продукта эта база в виде архивированных логов и самописного select'а с фильтрами на awk/grep/sed и дошла.
Зато теперь я знаю, что с базой лучше заранее определяться :)
Драйвер ixgbe.ko в базе решил все необходимые задачи, там параметром interrupt coalescing был настроен и включён rss. Трафиком от MX'а мы полностью управляем, поэтому у нас фиксированное количество unicast'овых потоков + Jumbo Frames. Да и поток на сервер небольшой по современным меркам.
Поэтому до pf_ring дело не дошло.
И за эти 2 недели сложилась определённая архитектура софта, ориентированная на быстрый результат, который можно показать. Так родилось решение: вывод демона (в текстовом виде), анализирущего трафик от MX'а пропускать через svlogd, а svlogd уже брал на себя задачу архивирования и проставление меток времени.
У этой простой схемы есть свои преимущества и недостатки. Но с задачей она всегда справлялась, поэтому поменять впоследствии её уже не удалось, т.к. была куча других насущных проблем вроде поддержки TCP-шных камер. Так до конечного продукта эта база в виде архивированных логов и самописного select'а с фильтрами на awk/grep/sed и дошла.
Зато теперь я знаю, что с базой лучше заранее определяться :)
Драйвер ixgbe.ko в базе решил все необходимые задачи, там параметром interrupt coalescing был настроен и включён rss. Трафиком от MX'а мы полностью управляем, поэтому у нас фиксированное количество unicast'овых потоков + Jumbo Frames. Да и поток на сервер небольшой по современным меркам.
Поэтому до pf_ring дело не дошло.
А как же кровавая Big Data? Просто ожидал ее тут увидеть, а у вас велосипедостроение :)
Вот это настоящая крутая работа. Не на раби скриптик налабать, в взять и сделать офигенную штуку.
… На картинке в пятнистой раскраске — это что?
… Где можно увидеть ориентировочные цены решений Вашей компании?
… Где можно увидеть ориентировочные цены решений Вашей компании?
В пятнистой раскраске первая ревизия коммутатора X10-24.
Сейчас выпускается вторая ревизия — в синей раскраске, и SFP порты в два ряда.
Сейчас выпускается вторая ревизия — в синей раскраске, и SFP порты в два ряда.
цены решения для мониторинга качества видео-потоков — проектные и зависят от количества потоков, способа подключения, опций и т.д., и т.п. пишите на support@metrotek.spb.ru — продажники посчитают.
а коммутаторы сейчас кончились, планируем выпускать новую партию на других уже чипах. используемые, честно говоря, староваты уже и функций у них недостаточно для хитрых решений. для датацентров нормально, для простых сетей тоже, а для сетей со сложной конфигурацией — нужно думать и смотреть. а цена у них (10Gx24 SFP/SFP+) в районе 200 т.р.
а коммутаторы сейчас кончились, планируем выпускать новую партию на других уже чипах. используемые, честно говоря, староваты уже и функций у них недостаточно для хитрых решений. для датацентров нормально, для простых сетей тоже, а для сетей со сложной конфигурацией — нужно думать и смотреть. а цена у них (10Gx24 SFP/SFP+) в районе 200 т.р.
Sign up to leave a comment.
Разрабатываем систему мониторинга на 55000 видео-потоков RTP