Ние разработваме система за мониторинг на 55 000 RTP видео потока

Какво наблюдаваме?

Свързването към Ethernet връзки е възможно само в режим на наблюдение, с помощта на оптични съединители, с други думи, в ненатрапчив режим. Такава връзка е за предпочитане, тъй като в този случай трафикът не преминава през оборудването и следователно не може да повлияе на качеството на предоставяните услуги (смятаме, че спадът в нивото на оптичния сигнал на сплитера е съвсем незначителен). За операторите това е изключително важен аргумент. А за разработчиците от такава връзка следва важен нюанс - винаги ще трябва да гледате потоците „отвън“, т.к. пакетите не могат да се предават към мрежата (например не можете да изпратите ping и да получите отговор). Това означава, че ще трябва да работите в условия на липса на информация.

Какво измерваме?

RTP може да „мине“ както през UDP, така и (предимно, в 90% от случаите) през RTSP/TCP в режим „Interleaving data“. Да, въпреки факта, че RFC за RTSP казва, че е по-добре да не се използва режимът на Interleaving Data - вижте 10.12, rfc2326).

И кое е толкова трудното?

Търсим подходящо решение...

Естествено, ние се опитахме да се възползваме максимално от собствения си опит. По времето, когато беше взето решението, вече имахме реализация на обработка на Ethernet пакети на FPGA захранвано устройство Bercut-MX (по-просто - MX). С помощта на Bercut-MX успяхме да получим необходимите полета за анализ от заглавките на Ethernet пакетите. За съжаление, нямахме опит в обработката на такъв обем трафик с помощта на „обикновени“ сървъри, така че те погледнаха на такова решение с известно опасение ...

Какво може да се измери чрез полетата на RTP пакет?

Форматът на RTP пакета е описан в rfc3550.

Съвсем очевидно е, че поредният номер ви позволява да дефинирате следните параметри на потока:

загуба на пакети (загуба на рамка);
повторно изпращане на пакета (дубликат);
промяна на реда на пристигане (пренареждане);
презареждане на камерата, с голям "пропуск" в последователността.

Timestamp ви позволява да измервате:

вариация на забавянето (наричана още трептене). В този случай 90 kHz брояч трябва да работи на приемащата страна;
по принцип забавянето на преминаването на пакета. Но за това трябва да синхронизирате времето на камерата с времевия печат и това е възможно, ако камерата предава доклади на изпращача (RTCP SR), което по принцип не е вярно, т.к. в реалния живот много камери игнорират съобщението RTCP SR (около половината от камерите, с които имахме възможност да работим).

Подробните алгоритми за измерване на параметрите са извън обхвата на статията, няма да се задълбочавам в нея. Ако се интересувате, rfc3550 има пример за код за изчисляване на загубите и формула за изчисляване на трептене. Основният извод е, че само няколко полета от RTP пакети и NAL единици са достатъчни за измерване на основните характеристики на транспортния поток. А останалата информация не участва в измерванията и може и трябва да се изхвърли!

Как да идентифицирам RTP потоци?

Интересното е, че първоначално идентифицирахме камерата само чрез IP на източника и SSRC, разчитайки на факта, че SSRC трябва да е случаен, но на практика се оказа, че много камери задават SSRC на фиксирана стойност (да речем, 256). Очевидно това се дължи на спестяване на ресурси. В резултат на това трябваше да добавим портове към идентификатора на камерата. Това реши напълно проблема с уникалността.

Как да отделя RTP пакети от друг трафик?

Остава въпросът: как Berkut-MX, след като е приел пакета, ще разбере, че това е RTP? RTP хедърът няма такава изрична идентификация като IP, няма контролна сума, предава семоже през UDP с номера на портове, които се избират динамично при установяване на връзката. И в нашия случай повечето от връзките отдавна са установени и можете да чакате много дълго време за преинсталиране.

За да се реши този проблем, се препоръчва в rfc3550 (Приложение A.1) да се проверят битовете на RTP версията - това са два бита, и полето Payload Type (PT) - седем бита, което в случай на динамичен тип заема малък диапазон. На практика установихме, че за набора от камери, с които работим, PT се побира в диапазона от 96 до 100.

Има и друг фактор - паритетът на пристанището, но както показа практиката, той не винаги се спазва, така че трябваше да бъде изоставен.

По този начин поведението на Berkut-MX е следното:

получаваме пакет, разглобяваме го на полета;
ако версията е 2 и типът полезен товар е в дадените граници, тогава изпращаме заглавките към сървъра.

Очевидно при този подход има фалшиви положителни резултати, т.к. не само RTP пакетите могат да попаднат под такива прости критерии. Но за нас е важно, че определено няма да пропуснем RTP пакета и сървърът ще филтрира „грешните“ пакети.

Продължавам...

В резултат на това сървърът не работи с 50-60 Gigabit / s, а с максимум 5% (това е точно съотношението на изпратените данни към средния размер на пакета). Тоест на входа на цялата система 55 Gigabit / s и само не повече от 3 Gigabit / s достига до сървъра!

В резултат на това получихме следната архитектура:

И получихме първия резултат в тази конфигурация две седмици след настройката на първоначалния TOR!

Какъв е крайният резултат от сървъра?

И така, какво прави сървърът в нашата архитектура? Неговите задачи:

слушане на UDP сокет и четене на полета с пакетирани заглавки от него;
анализирайте входящитепакети и извличане на RTP заглавни полета от там заедно с идентификатори на камерата;
съпоставете получените полета с тези, които са били получени преди, и разберете дали пакетите са били изгубени, дали пакетите са били изпращани многократно, дали редът на пристигане се е променил, каква е била промяната в забавянето на транзита на пакета (трептене) и т.н.;
запис на измерените данни в базата данни по време;
анализира базата и генерира доклади, изпраща капани за критични събития (висока загуба на пакети, загуба на пакети от някоя камера и т.н.).

Въпреки факта, че общият трафик на входа на сървъра е около 3 Gigabit / s, сървърът се справя дори ако не използваме никакви DPDK, а просто работим през linux сокет (след увеличаване на размера на буфера за сокета, разбира се). Освен това ще бъде възможно да се свързват нови връзки и MX, тъй като маржът на производителността остава.

Ето как изглежда горната част на сървъра (това е горната част само на един lxc контейнер, отчетите се генерират в друг):

От него се вижда, че цялото натоварване за изчисляване на параметрите на качеството и отчитане на статистиката е равномерно разпределено върху четири процеса. Успяхме да постигнем такова разпределение с помощта на хеширане в FPGA: хеш функцията се изчислява по IP, а ниските битове на получения хеш определят номера на UDP порта, към който ще отиде статистиката. Съответно всеки процес, слушащ своя порт, получава приблизително еднакво количество трафик.

минуси и плюсове

Време е да се похвалите и да признаете недостатъците на решението.

Ще започна с положителните страни:

без загуба на кръстовището с 10G връзки. Тъй като FPGA поема целия „удар“, можем да сме сигурни, че всеки пакет ще бъде анализиран;
за наблюдение на 55 000 камери (иоще) е необходим само един сървър с една 10G карта. В момента използваме сървъри, базирани на 2x Xeon с 4 ядра по 2400 MHz всяко. Достатъчно с резерв: успоредно със събирането на информация се генерират отчети;
наблюдението на 8 "десетки" (10G връзки) се побира само в 2-3 единици: не винаги има много място и мощност в стойката за системата за наблюдение;
когато свързвате връзки от MX през комутатора, можете да добавяте нови връзки, без да спирате наблюдението, защото не е необходимо да вмъквате никакви платки в сървъра и не е необходимо да го изключвате за това;
сървърът не е претоварен с данни, той получава само това, което е необходимо;
заглавките от MX идват в jumbo Ethernet пакет, което означава, че процесорът няма да бъде задушен от прекъсвания (освен това не забравяме за обединяването на прекъсванията).

В крайна сметка получихме софтуерно-хардуерен комплекс, в който можем да контролираме както частта, която анализира пакетите на интерфейсите, така и частта, която поддържа статистика. Пълният контрол върху всички възли на системата буквално ни спаси, когато камерите започнаха да превключват на RTSP/TCP interleaved режим. Тъй като в този случай RTP хедърът вече не се намира в пакета с фиксирано отместване: той може да бъде навсякъде, дори на границата на два пакета (първата половина в единия, втората в другия). Съответно алгоритъмът за получаване на RTP хедъра и неговите полета е претърпял фундаментални промени. Трябваше да направим повторно сглобяване на TCP на сървъра за всички 50 000 връзки - оттук и доста високото натоварване в горната част.

Никога преди не сме работили в областта на приложения с високо натоварване, но успяхме да разрешим проблема благодарение на нашите умения в FPGA и се получи доста добре. Имаше дори резерв - например още 20-30 хиляди могат да бъдат свързани към система с 55 000 камерипотоци.

Настройка на подсистеми на linux (разпределение на опашки по прекъсвания, увеличаване на получаващите буфери, директно разпределение на ядрата към конкретни процеси и т.н.) оставих извън обхвата на статията, т.к. тази тема вече е много добре покрита.

Описах далеч не всичко, събраха се много рейкове, така че не се колебайте да задавате въпроси :)

Много благодаря на всички, които прочетоха до края!