СХД для телеком-операторов: как построить IT-инфраструктуру под огромные массивы транзакций и данных абонентов
Телеком-оператор федерального масштаба обрабатывает миллиарды транзакций ежемесячно: биллинговые события, CDR-записи, данные DPI, абонентские профили, журналы сетевых устройств. Такая IT-инфраструктура провайдера требует СХД с субмиллисекундными задержками, архитектурой Active/Active, поддержкой NVMe и FC/iSCSI, а также соответствия регуляторным требованиям. NIMBUS «Гром» и «Молния» закрывают весь спектр задач хранения оператора связи — от горячего биллинга до холодных архивов.
Ни один другой корпоративный сегмент не предъявляет к хранилищу данных столь противоречивых требований одновременно. С одной стороны — экстремальная скорость: биллинговая система должна зафиксировать начало и конец каждого звонка, каждой сессии, каждого SMS-сообщения в реальном времени. С другой — огромная ёмкость: закон обязывает хранить метаданные коммуникаций годами. И всё это — в условиях нулевого допустимого простоя, потому что каждая секунда недоступности биллинга — это прямые финансовые потери и риск нарушения SLA.
Для инженера, проектирующего IT-инфраструктуру провайдера, ключевой вопрос звучит не «какое хранилище взять», а «как разложить нагрузки по ярусам хранения так, чтобы не переплачивать за производительность там, где она не нужна, и не экономить там, где экономия убьёт сервис».
Анатомия нагрузок телеком-оператора
Прежде чем проектировать хранилище данных оператора связи, необходимо чётко классифицировать типы нагрузок — они принципиально разные по профилю ввода-вывода.
Горячий ярус (Tier 0 / Tier 1): биллинговые платформы — это чистый OLTP. Случайная запись и чтение, размер блока 4–16 KB, требования к задержкам — не более 0.5–1 мс. Любая деградация здесь немедленно отражается на точности начислений и качестве обслуживания. Сюда же относятся CRM-системы, базы абонентских профилей и системы управления сетью (OSS/BSS).
Тёплый ярус (Tier 2): аналитика, BI и хранилища DWH. Здесь нагрузка смешанная — большие последовательные чтения для построения отчётов, сравнительно редкие записи. Задержки менее критичны, чем на горячем ярусе, но пропускная способность должна быть высокой: аналитический запрос к таблице CDR-записей за квартал может сканировать десятки терабайт.
Холодный ярус (Tier 3): регуляторные архивы. Закон об оперативно-розыскной деятельности и поправки к нему обязывают операторов хранить метаданные вызовов и сессий до 3 лет, а контент — до 6 месяцев. Это петабайты данных с редким доступом. Здесь приоритет — максимальная ёмкость при минимальной стоимости гигабайта.
Требования к СХД в телекоме: что реально важно
Инженеры ЦОД операторов связи выделяют несколько параметров, которые на практике определяют пригодность хранилища к эксплуатации в этой отрасли.
- Архитектура Active/Active контроллеров — оба контроллера одновременно обслуживают I/O. При сбое одного из них производительность снижается вдвое, но сервис не прерывается. В отличие от Active/Passive, нет «холодного» контроллера и нет задержки на failover
- Поддержка Fibre Channel (FC 32G) и iSCSI — биллинговые системы традиционно подключаются по FC для гарантированной латентности; современные OSS-платформы и аналитика — по iSCSI или NVMe over Fabrics
- Высокий IOPS при смешанной нагрузке — CDR-обработка и биллинг генерируют сотни тысяч операций в секунду; для NVMe-массива это стандарт, для гибридного — требует правильного расчёта кэша
- Снепшоты без деградации производительности — ежесуточные снимки биллинговой БД для RPO = 24h; реализация через copy-on-write не должна влиять на IOPS основного потока
- Тиринг (автоматическое перемещение данных) — горячие CDR за последние 30 дней лежат на NVMe, данные за год — на SAS4, архивы — на ёмких SATA-дисках с расширительных полок
- Метрокластер — синхронная репликация между двумя географически разнесёнными ЦОД с RPO = 0 и автоматическим failover без ручного вмешательства
Линейка NIMBUS для телеком: архитектурное решение
Телеком-оператор — это не монолитная нагрузка, которую можно закрыть одной моделью СХД. На практике строится трёхуровневая архитектура хранения, где каждый ярус закрывается оптимальной моделью из линейки NIMBUS.
| Ярус хранения | Задача | Модель NIMBUS | Ключевые характеристики |
|---|---|---|---|
| Tier 0 — Горячий (биллинг, OSS/BSS) | OLTP, CDR, абонентские профили | «Молния» (All-Flash NVMe) | Латентность <0.5 мс, Active/Active, кэш до 1 TB, FC 32G / iSCSI / NVMe-oF |
| Tier 1 — Тёплый (аналитика, DWH) | BI-отчётность, DPI-аналитика, ML-модели | «Гром» 230 (гибрид SAS4 + NVMe) | Авто-тиринг, SAS4 до 90 дисков, кэш до 512 GB, iSCSI / FC |
| Tier 2 — Холодный (регуляторные архивы) | Хранение по «закону Яровой», CDR-архив | «Гром» 210 / 220 + полки расширения | Максимальная сырая ёмкость, RAID TP, дедуп + Zstd компрессия |
| Репликация / DR | Геораспределённость, RPO=0 | «Молния» + «Гром» (метрокластер) | Синхронная репликация, расстояние до 300 км, ПО «Юпитер» |
СХД NIMBUS «Молния» для биллинга и OSS/BSS
Биллинговая платформа — сердце оператора связи. Простой биллинга длиной в 15 минут для крупного федерального оператора означает тысячи незафиксированных тарификационных событий и потенциальные судебные разбирательства с абонентами. Именно поэтому для этого яруса нужна архитектура, которая не имеет единой точки отказа ни на уровне дисков, ни на уровне контроллеров, ни на уровне площадок.
СХД NIMBUS «Молния» строится на архитектуре Active/Active: оба контроллера одновременно принимают операции ввода-вывода и балансируют нагрузку. NVMe-диски обеспечивают случайный IOPS на уровне, недостижимом для SAS-массивов. Кэш контроллера до 1 TB с резервным питанием (BBU) гарантирует, что данные в полёте не будут потеряны при кратковременном сбое питания. Поддержка Fibre Channel 32G позволяет подключать биллинговые серверы по выделенной SAN-сети с предсказуемыми задержками.
Почему это важно именно для телекома? CDR-запись (Call Detail Record) весит порядка 200–500 байт. Оператор с 10 млн абонентов в пиковый час генерирует сотни тысяч таких записей в секунду. Случайная запись мелкими блоками — именно тот профиль нагрузки, для которого NVMe-массив с Active/Active-контроллерами является оптимальным выбором.
СХД NIMBUS «Гром» для аналитики и DWH
Аналитическое хранилище оператора связи — другая сторона той же медали. Здесь не нужны субмиллисекундные задержки при случайном доступе, но критична пропускная способность при последовательном чтении: аналитический запрос к CDR-таблице за квартал сканирует десятки терабайт. Плюс — регулярные ETL-процессы, которые ночью загружают в DWH данные из биллинга, DPI-систем и CRM.
СХД NIMBUS «Гром» 230 в гибридной конфигурации (NVMe-кэш для горячих данных + SAS4-диски для основного массива) идеально попадает в этот профиль. Автоматический тиринг через ПО «Юпитер» переносит горячие блоки на NVMe-ярус по статистике обращений — без ручного вмешательства администратора. Холодные агрегированные данные за прошлые периоды опускаются на ёмкие SAS4-диски с включённой Zstd-компрессией.
На практике мы видим следующую картину: CDR-данные за последние 30 дней активно используются для оперативной отчётности и тарификации спорных ситуаций. Данные за 6–12 месяцев нужны для стратегической аналитики и BI. Данные старше года — исключительно для регуляторных запросов. Такая трёхуровневая логика тиринга реализуется в ПО «Юпитер» через политики автоматического перемещения данных.
Регуляторные требования: хранение по «закону Яровой»
Для операторов связи требования законодательства — не абстракция, а конкретные петабайты данных, которые нужно хранить, обеспечивать к ним доступ по запросу и защищать от несанкционированного удаления. Речь идёт о хранении метаданных коммуникаций сроком до 3 лет и контента — до 6 месяцев.
Для холодного яруса хранения NIMBUS «Гром» 210/220 с полками расширения до 90 дисков обеспечивает петабайтную ёмкость в одной стойке. RAID TP (тройная чётность) защищает данные при одновременном отказе до трёх дисков — критично для плотных конфигураций с большим количеством дисков в одной группе. Дедупликация и Zstd-компрессия через ПО «Юпитер» дополнительно снижают физическую ёмкость для хранения метаданных на 30–60% (метаданные CDR содержат много повторяющихся полей — номера операторов, коды сетей, форматы дат).
Метрокластер: непрерывность сервисов при катастрофическом сбое
Федеральные операторы связи обязаны обеспечивать непрерывность критических сервисов даже при полном выходе из строя одной площадки — это требование как регулятора (ФСТЭК, Роскомнадзор), так и собственных SLA перед корпоративными клиентами.
ПО «Юпитер» реализует метрокластер — синхронную репликацию данных между двумя СХД NIMBUS на разных площадках с RPO = 0 (нулевая потеря данных) и автоматическим failover. Расстояние между площадками — до 300 км при использовании тёмной оптики с задержкой не более 5 мс. При сбое основной площадки резервный узел принимает нагрузку без ручного вмешательства: биллинговые серверы автоматически переключаются на реплику по протоколу FC или iSCSI.
Важная деталь: метрокластер в ПО «Юпитер» работает с дедупликацией репликационного трафика. Между площадками передаются только изменённые блоки данных — это снижает нагрузку на межплощадочный канал в 3–5 раз по сравнению с полной репликацией.
Импортозамещение в телекоме: регуляторная реальность
Телекоммуникационная отрасль — один из первых секторов, в которых требование перехода на отечественное оборудование приобрело практический, а не декларативный характер. Системообразующие операторы включены в перечень организаций критической информационной инфраструктуры (КИИ), что налагает конкретные обязательства по использованию сертифицированного и включённого в реестры оборудования.
СХД NIMBUS «Гром» и «Молния» включены в реестр Минпромторга РФ как российское оборудование. ПО «Юпитер» — в реестр Российского ПО. Это означает, что инвестиции в инфраструктуру NIMBUS засчитываются в выполнение требований по импортозамещению, открывают доступ к государственным субсидиям и льготным программам лизинга, а также полностью исключают риски, связанные с санкционными ограничениями на обновление ПО и получение технической поддержки.
Часто задаваемые вопросы
Какая СХД подходит для биллинговой системы телеком-оператора?
Биллинг — это OLTP с интенсивной случайной записью мелкими блоками (4–16 KB) и требованием латентности не выше 1 мс. СХД NIMBUS «Молния» на базе All-Flash NVMe с архитектурой Active/Active, кэшем до 1 TB и поддержкой Fibre Channel 32G полностью закрывает эту задачу. Для операторов с несколькими миллионами абонентов рекомендуется конфигурация с метрокластером между двумя площадками.
Как телеком-оператор должен хранить данные по регуляторным требованиям?
Требования предполагают хранение метаданных вызовов и интернет-сессий сроком до 3 лет, контента голосовых коммуникаций — до 6 месяцев. Для этого нужна высокоёмкая СХД с поддержкой уровней хранения (tiering) и защиты от потери данных при отказе нескольких дисков. СХД NIMBUS «Гром» 210/220 с полками расширения до 90 дисков, RAID TP и ПО «Юпитер» с автотирингом оптимально закрывает этот регуляторный сценарий.
Нужна ли архитектура Active/Active для ЦОД телеком-оператора?
Да, это критически важное требование для биллинговых и OSS-систем. При Active/Passive в момент failover возникает пауза переключения и временная деградация производительности. В СХД NIMBUS «Молния» архитектура Active/Active обеспечивает постоянную балансировку нагрузки между контроллерами — при отказе одного из них сервис продолжается без прерывания, просто с вдвое меньшей пиковой производительностью.
Как организовать геораспределённое хранилище для оператора с несколькими ЦОД?
Используется метрокластер — синхронная репликация между двумя площадками с RPO = 0 и автоматическим failover. ПО «Юпитер» в составе СХД NIMBUS поддерживает метрокластер на расстоянии до 300 км по тёмной оптике или Ethernet с задержкой не более 5 мс. При сбое основной площадки резервный узел принимает нагрузку без ручного вмешательства администратора.
Как сократить затраты на хранение петабайтных архивов оператора?
Оптимальная стратегия — трёхуровневый тиринг с автоматическим перемещением данных через ПО «Юпитер»: горячие CDR за 30 дней на NVMe, аналитические данные за год — на SAS4, архивы — на ёмких дисках с Zstd-компрессией. Дополнительно — дедупликация метаданных CDR (поля операторов, коды сетей высоко дублируются), которая даёт реальную экономию ёмкости на 30–60% на холодном ярусе.
Гром
система хранения данных
В реестре
Оптимально подходит для организаций среднего и крупного бизнеса, которым требуется надежное, масштабируемое и эффективное решение для хранения данных с возможностью адаптации к различным типам нагрузок
Молния
система хранения данных
В реестре
Решение премиум-класса для организаций, чей бизнес зависит от скорости обработки данных и требует инфраструктуры хранения с высокой пропускной способностью. Подходит для отраслей: телекоммуникации, финансы, госучреждения и производство