Стоимость системы Тотального Прослушивания Всего и Всех

Некоторое время тому назад кто-то из пользователей LJ в период обострения параноидального состояния разразился постом про то, как Спецслужбы Слушают Всех, и, помимо прочего, приводил там выкладки о том, сколько нужно байт/серверов/... для того, чтобы иметь возможность записывать все разговоры всех абонентов какого-то мобильного оператора и хранить их в течении одного-трех месяцев. Пост имел известность, попал в Top-5 яндекса и собрал вагоны комментариев.

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

Возьмем те же данные, что и автор процитированного поста: оператора с 51.5 млн. абонентов, каждый из которых потребляет в среднем 134 минуты голосового трафика в месяц.

Итого месячный трафик будет составлять: 51,50 млн х 134 мин = 6,9 млрд мин

Передача данных по голосовому каналу в GSM идёт со скоростью 9,6 Кбит/с. Таким образом, общий объём трафика за месяц: 6,9 млрд мин х 60 с/мин х 9,6 Кб/с / (8 б/Б) = 5E14 Б ~= 500 ТБ

Дальше автор делает вывод, что (цитирую): ... если брать винты по 0,5 ТБ, то их нужно будет всего 1000. Причём не в 1 месте сразу, а по всей стране, распределёнными в каждой сети, может быть, даже по сотам. [...] Вариант этого: на каждом коммутаторе ставится машина с 1-2-3 дисками (а это может быть уже терабайт), которая занимается записью трафика. Полностью заполненный диск вытаскивается (заменяясь на чистый), маркируется (дата/время начала/конца, штрих-код по вкусу) и относится на склад, до истечения срока хранения, а затем пускается в оборот. На машинке основная операция - запись. Обращения к ней по чтению - пренебрежимо малы, а обращение к вынутым архивным дискам - вообще не занимают эту машину.

Автор, судя по всему, не знает про существование inter-MSC handover-ов (в т.ч inter-MSC) и уверен, что любой разговор можно записать в пределах соты. Кроме того, его не смущает то, что любой разговор будет записан два раза - когда мы пишем звонящего абонента и абонента, получающего звонок. Впрочем, чем нападать на технически безграмотных, давайте лучше придумаем свою систему, с блэк-джеком и шлюхами (кстати, все в курсе, что будут снимать продолжение Футурамы?), и посмотрим, сколько может стоить ее построить. Ну, и обслуживать - куда же без этого.

Итак, нам нужна система, которая:

Записывает исходящие и входящие разговоры всех абонентов внутри домашней сети.
Делает это в режиме реального времени
Позволяет легко найти любой разговор (по идентификатору абонента и дате, например)
Позволяет хранить информацию в течении минимум трех месяцев
Работает с коммутационным оборудованием любого поставщика
Не создает дополнительной нагрузки на сигнальные и голосовые линки
Достаточно надежна - например, записывает не менее 99% разговоров
Достаточно безопасна - не допускает утечки конфиденциальных сведений лицам, не имеющим специального разрешения (санкции прокурора, например).

Что из этого следует (по пунктам):
Пишем все разговоры => Система не должна бояться того, что абоненты - мобильны (т.е. должна обрабатывать handover-ы, форварды и т.п.)
В real time => Если мы как-то жмем записываемое - то должны успевать делать это быстро.
Можем найти записанное => Система должна быть снабжена индексом/поисковым механизмом. Данные в системе должны быть актуальны с задержкой не более чем на столько-то минут.
Храним 3 месяца => Ну, сайзинг уже приведен выше. Нужно (по минимуму) 1500 Тб дисков (если мы ничего не жмем).
Работаем с любым железом => Тут самое главное узкое место, т.к. нам нужен стандартный специфицированный интерфейс, который гарантировано будет и у Сименса, и у Нортела, и у Хуавея, и даже (чем черт не шутит?) у Стром-а. Можете пойти на сайт 3GPP и попробовать его найти... Чтобы не портить красивую сказку, давайте предположим, что такой интерфейс есть. Осталось понять, где именно он находится - на уровне MSC, на уровне BSC, на уровне BTS, или ...?
Не создаем нагрузки => Нельзя грузить call processor-ы в MSC или канальное оборудование нехарактерными для них задачами
Надежность => нужно резервирование для каналов связи, электропитания и дисков
Безопасность => нужен централизованный механизм управления доступом (как минимум)

Из написанного следует, что система должна подключаться к MSC (чтобы быть в курсе эволюций мобильных абонентов и успевать на них реагировать). На 50 млн абонентов оператору нужно иметь около 50 среднестатистических коммутаторов.

Теперь посмотрим, можно ли сделать систему распределенной, разместив около каждого MSC не просто storage для первичного накопления информации, а что-то более интеллектуальное - например, узел, удовлетворяющий всем сформулированным требованиям.

Сначала представим себе один несколько возможных сценариев обслуживания звонка.

Сценарий 1: На протяжении всего звонка A->B абонент А находится в зоне обслуживания коммутатора X, а абонент B - в зоне обслуживания коммутатора Y. При этом разговор можно снять на любом из коммутаторов, по нашему выбору. Если мы пишем все и везде, то перед складированием в центральное хранилище одну из копий можно смело выкинуть.

Сценарий 2: На протяжении всего звонка A->B абонент А находится в зоне обслуживания коммутатора X, а абонент B - в зоне обслуживания коммутатора Y, но при этом звонок проходит через промежуточный коммутатор Z. Сценарий очень похож на предыдущий, за исключением того, что копий будет три и в процессе выкидывания лишнего надо будет не забыть (тут меня надо поправить, если я не прав), что промежуточный коммутатор будет знать MSRN абонента B, но не его MSISDN.

Сценарий 3: В начале разговора абонент А находится в зоне обслуживания коммутатора X, а абонент B - в зоне обслуживания коммутатора Y, а в процессе разговора они перемещаются: абонент А переходит в зону обслуживания коммутатора S, а абонент - в зону обслуживания коммутатора T. В этом случае запись придется собирать из частей. Всего частей будет четыре, и из них можно будет собрать две полных копии (четырьмя возможными способами).

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

• сначала свести данные в какое-то общее хранилище.
• стаскивать в центральное хранилище только метаданные о звонке и коррелировать их, а сырые записи звонков хранить как угодно (возможно даже распеределенно, но с overhead-ом минимум в два раза). Результаты корреляцию затем использовать для извлечения из распределенного хранилища конкретного разговора/разговоров. Извлечение, правда, будет долгим и нудным, а если подойти к вопросу устаревания данных наиболее простым способом (форматируем самый старый винчестер), то каких-то частей можно и недосчитаться.

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

Для простоты предположим, что нагрузка на коммутаторы распределена равномерно и непрерывно. Соответственно, 500 Тб разговоров размазаны между 50 коммутаторами, и на каждый приходится по 10 Тб голосового трафика в месяц. Чтобы забирать такое кол-во информации, нужно иметь канал пропускной способностью: 10 * 1024^4 / (3600 с в часе * 24 часа * 30 дней) * 8 бит в байте = 4241943 бит/сек = 32 мегабита в секунду

Итого, записываем в смету 50 таких каналов (не резервированных).

Далее, чтобы обеспечивать надлежащее качество хранения данных, нужно иметь запасные носители. Взяв за основу данные по надежности винчестеров, накопленные в Google, можно утверждать, что нужно иметь запас в объеме минимум 5% от используемых носителей.

Сколько мы их будем использовать? От 3000 винчестеров по 500 Гб до 6000 (если мы пишем все подряд без предобработки и каждый разговор записываем по два раза - для звонящего и принимающего). Соответственно, запас - еще 150-300 таких же винчестеров ежегодно.

Дальше - интереснее. Надо объединить такое кол-во винчестеров в индексируемое хранилище с каким-никаким интерфейсом доступа. Хранилище

• не вопрос, есть коммерческие решения на 300-50 Тб на винчестерах и даже больше - на стриммерах. Вот интерфейс к тому (API и GUI), что мы записали - это уже более интересно. Плюс - надо обеспечить запись в это хранилище данных со скоростью (как минимум) 32 мегабита в секунду. Или, если мы считаем все потоки со всех коммутаторов - 1600 mbps. Ну, и не забываем про обновление индексов.

Можно было бы продолжать и дальше, но я считаю, что материала и так уже предостаточно.

Кратко перечислим все, что мы насчитали до сих пор:

• 3000-6000 винчестеров по 500 Гб, либо же в 10 раз (грубо) меньше винчестеров, но - с кучей CPU power для сжатия записываемого на лету
• 50 каналов 32 mbps
• Сервера, обеспечивающие интерфейс к хранилищу и его функционирование (индексация, поиск нужных записей, поиск и удаление старых записей)
• Питание и климат-контроль для всего этого дела
• Место (серверные), в которых это все надо разместить
• Инфраструктура эксплуатации всей системы (люди, склады, логистика ...)

Понятное дело, что технически все это можно установить, написать, сконфигурировать и т.п. Но вопрос - не в этом.