Хранение трафика: каналы и приём терабайтов

25. October 2013, 13:21 Занимательное, Интернет

ConnectedВ продолжение предыдущей записки о системе хранения интернет-трафика. Понятно, что мало найти место для хранения трафика, нужно ещё решить ряд других непростых задач: во-первых, трафик нужно как-то заливать в хранилище; во-вторых, нужно предоставить доступ (с поиском и разными выборками) к сохранённому трафику.

Мы оцениваем трафик порядка терабита в секунду (это верхний предел, определённый из объёмов MSK IX). Конечно, напрямую заливать терабит в систему хранения через один порт технически невозможно. Поэтому для приёма трафика требуется построить некий распределённый многопортовый шлюз. Это большая проблема. Дело даже не в том, что гипотетический сверхпроизводительный элементарный узел сможет обрабатывать не более гигабита в секунду и таких узлов потребуется тысяча, а в том, что поступающий трафик нужно будет корректно сортировать по ряду признаков. Сортировка нужна хотя бы для того, чтобы удалить дубликаты пакетов и верно определить источник и получателя для каждой сессии. Тем не менее, эта проблема решается. Узлы, составляющие принимающий шлюз, могут быть размещены на разных площадках: не обязательно организовывать подключение в одной точке. Между узлами потребуется построить собственную сеть обмена “метаинформацией” о том, кто и что сохраняет. Очищенный на местах трафик отправляется в центральное хранилище.

Отдельная сложность – поиск в базе данных, имеющей объём около трех петабайт. Вспомним, что речь идёт о данных, которые перезаписываются каждые 12 часов. То есть, поиск должен быть быстрым, так как каждый час, затраченный на выборку, означает, что часть данных, которые могут потребоваться для уточняющих запросов, уже удалена. Возьмём экстремальный случай и предположим, что для выполнения запроса требуется перебрать 10% собранных данных. Пусть объём всей базы 2,7 петабайта, тогда 0.1 это 270 терабайт. Если наш “процессинговый центр” обрабатывает гигабайт в секунду (чрезвычайно быстро), то для перелопачивания 270 терабайт потребуется 75 часов. А это означает, что обработка уже не имеет никакого смысла. Не нужно, впрочем, делать вывод, что из подобной системы хранения нельзя извлечь ничего полезного.

Решением является создание архитектуры, оптимизированной с точки зрения выполнения неких определённых типов запросов на поиск. Чтобы такие запросы выполнять быстро, нужно будет при сохранении трафика вычислить некоторое “избыточное” представление, позволяющее найти нужный фрагмент трафика, скажем, в течение часа. Впрочем, решение этой задачи существенно усложняет организацию системы, записывающей трафик: потребуются дополнительные вычислительные мощности и, конечно, новое дисковое пространство.

Ну а идеальным решением было бы хранилище, способное долговременно хранить весь трафик. Пока что это абсолютная фантастика, ведь для терабита в секунду потребуется система, способная прирастать, примерно, на шесть петабайт доступного пространства в сутки – дата-центры строятся медленнее.

Адрес записки: https://dxdt.ru/2013/10/25/6265/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 12

  • 1 <t> // 25th October 2013, 15:31 // Читатель Влад написал:

    Можно резко снизить требования, игнорируя трафик с порносайтов и ютуба.

  • 2 <t> // 25th October 2013, 17:33 // Читатель Jeff Zanooda написал:

    Тогда враги будут обмениваться информацией исключительно через эти сайты.

  • 3 <t> // 25th October 2013, 20:16 // Читатель зашел в гости написал:

    Да и информации с ю-туба можно много полезной извлечь. Например, отследить материалы, которые смотрел подозреваемый в терроризме. Посмотреть кто также смотрел те же самые ролики примерно в то же время, а также, кто их выкладывал в сеть.

  • 4 <t> // 25th October 2013, 20:31 // Читатель jno написал:

    А, прошу прощения, это у нас *весь* IP-трафик, да?
    Т.е., включая все эти ICMP и прочие BGP?

    Далее, с учётом времени на анализ, сходу херим *данные*, скажем SIP’ов и прочих скайпов (“заголовки” сессии – храним).

    Далее, читаем подзаконные акты (хе-хе) и находим протоколы, обслуживающиеся “традиционным СОРМ-2” (ну, мыло, там, всякое – снилось мне).

    Интересно было бы оценить, насколько можно сократить объём хранения при таком подходе?

  • 5 <t> // 26th October 2013, 17:07 // Читатель RE написал:

    2jno
    А какие мы данные “прочих скайпов” херим, простите?
    И зачем тогда вообще всё?

    Вот данные торрента вплоне можно херить. Клиппарты.
    Вообще по идее должны сделать некую базу данных известных файлов, которую нужно херить (фильмы, музыка, файлы) и специально обученные люди будут их просмтаривать. Собственно таким макаром можно отбросить весьма большую часть трафика видео/аудио/софта – хранить в логах только хеш.

  • 6 <t> // 26th October 2013, 18:54 // Читатель jno написал:

    я исхожу из предложенной схемы.
    за 12 часов вряд ли реально вскрыть шифрованный трафик.
    в принципе мало смысла в почти любых бинарных данных, непригодных к непосредственному анализу.
    так же мало смысла в критериях, неизвлекаемых *просто* из значений полей в IP-пакетах или, в крайнем случае, из первых пакетов TCP-сессии.

  • 7 <t> // 28th October 2013, 11:02 // Читатель Андрей написал:

    По долгу службы знакомился с подобными техническими решениями. Так вот. По данным некоторых провайдеров из всего tcp трафика – 10% ( оценка сверху для канала , через который идет трафик простых домохозяйств) – http, остальное – torrent-ы, шифрованные каналы из которых ничего извлечь не удается и т.п. Из http подавляющее большинство – потоковое видео и аудио ( вконтактик, youtube и т.п) дальше идут баннеры, фотографии и т. п. Всё это можно отсечь и в результате получается, что вполне возможно хранить десятые доли процентов от того, что передается по каналу.
    Насчет хранения и доступа к данным – есть специализированные СУБД и подходы, которые позволяют решить эти задачи. Пример – сегментировать всё по часам, внутри сегмента упорядочивать факты по идентификатору абонента и т.п.

  • 8 <t> // 28th October 2013, 18:30 // Читатель sarin написал:

    вообще датамайнинг уже знает довольно много инструментов для обработки таких объёмов информации, но вот скорость – да. 12 часов это очень мало. тут правда на ум приходит такой нюанс, что вроде как отечественный СОРМ не аналог Призмы и нарушать права граждан не должен. а значит информацию он может выдавать только в отношении конкретных лиц.

    в процессе сохранения информации её необходимо индексировать по получателю и отправителю. думаю это вполне реализуемо. тогда извлечение данных из системы уже не станет такой огромной проблемой.

  • 9 <t> // 28th October 2013, 23:32 // Читатель jno написал:

    снилось мне, что СОРМ – такой же, как и призма…

    да, формально требуется решение суда или хотя бы постановление о возбуждении.
    а реально – никакого контроля.
    вообще.

  • 10 <t> // 29th October 2013, 15:21 // Читатель sarin написал:

    если Вам про СОРМ столько снилось, то поведайте нам есть ли в нём возможность извлечения данных по параметрам контента? например какие пользователи запрашивали данные по тому или иному URL. или всёже у него только можно получить информацию куда ходил тот или иной пользователь?

  • 11 <t> // 29th October 2013, 17:46 // Читатель jno написал:

    давний сон был, много с тех пор чего утекло.

  • 12 <t> // 31st October 2013, 07:16 // Читатель guest22 написал:

    Sarin, а разве СОРМ не хранит долговременно все данные соединения(но не сами передаваемые данные, что только по суду)? Вроде бы так изначально и было. Отсюда и ответ на ваш вопрос положительный.