История корпоративных систем хранения данных – это путь от жестко специализированных «черных ящиков» к гибким программным платформам. Каждый шаг этой эволюции решал проблемы прошлого, но неизбежно порождал новые противоречия. Сегодня, столкнувшись с радикальным усложнением инфраструктур (от классических ЦОД до частных облаков и объектов КИИ), – отрасль оказалась в точке, где наследие прошлых архитектурных решений стало главным ограничением для будущего. Современная корпоративная инфраструктура перестала быть монолитом. Сегодня это спектр архитектур и моделей потребления, каждая из которых предъявляет уникальные требования к системе хранения данных. С одной стороны - классические ЦОД с четким разделением ролей, ручным управлением и наследием в виде дорогих специализированных массивов. С другой - динамичные частные облака и гибридные среды, где инфраструктура должна предоставляться как сервис, масштабируясь по требованию и работая в условиях множества платформ. Между ними - гиперконвергентные кластеры, среды для критичных приложений (СУБД, VDI) и инфраструктура объектов КИИ, где на первый план выходят экстремальная производительность, отказоустойчивость и соответствие регуляторным требованиям. Все это многообразие объединяет одно требование: система хранения сегодня должна одинаково хорошо работать везде, будь то классический ЦОД или частное облако.
Традиционные СХД: архитектура, ограничивающая гибкость
И здесь обнаруживается фундаментальное противоречие. Традиционные СХД проектировались для одного мира – однородного и предсказуемого, где инфраструктура менялась раз в несколько лет, а не раз в несколько месяцев. Пока этот мир существовал, они справлялись и десятилетиями были стандартом для надежного хранения. Однако в эпоху гибридных сред их фундаментальные архитектурные ограничения стали критическими.
Вертикальное масштабирование: потолок производительности и ёмкости
Архитектура традиционной СХД предполагает единственный путь роста - вертикальный. Больше дисков дает больше ёмкости, мощный контроллер дает выше производительность. Когда физический предел платформы достигнут, единственный выход - покупка новой системы. Каждый шаг масштабирования занимает недели или месяцы: согласование, закупка, поставка, интеграция специализированных модулей от единственного вендора. Возможности горизонтального масштабирования, при котором добавление новых узлов линейно увеличивает и ёмкость, и производительность, в классической архитектуре СХД не существует.
Контроллер как узкое горлышко
Вычислительная мощность контроллеров задает жесткий потолок производительности всей системы. Максимальное количество контроллеров в традиционной СХД составляет 2, 4, реже 8 – это архитектурный предел, не зависящий от того, насколько быстрые накопители установлены или насколько широкая сеть построена. Вся обработка операций ввода-вывода ограничена вычислительными ресурсами контроллера, и именно он становится узким местом при росте нагрузки.
Закрытая архитектура: зависимость от одного поставщика
Традиционная СХД представляет собой аппаратно-программный монолит с закрытой архитектурой. Контроллеры, диски, кабели, модули расширения должны быть от одного производителя и сертифицированы под конкретную платформу. Прошивка, драйверы и утилиты диагностики – закрытый код, недоступный для аудита и модификации. Любой выход за периметр экосистемы вендора технически невозможен или влечет за собой потерю поддержки.
Ремонт и обслуживание
Парк запчастей полностью проприетарен и не унифицирован даже внутри линеек одного вендора – диск или модуль от соседней модели может физически не подойти. Заменить вышедший из строя компонент тем, что есть на складе или куплено у стороннего поставщика, невозможно: система либо не примет его, либо вендор снимет её с поддержки. В условиях недоступности оригинальных запчастей по причине санкций, ухода вендора с рынка или длительных сроков поставки система хранения превращается в необслуживаемый актив с непредсказуемым сроком жизни.
Закупка в РФ: сроки, цена, недоступность оборудования для сетей хранения
HBA-адаптеры Emulex и QLogic, коммутаторы Brocade недоступны по официальным каналам в России. Построить или расширить инфраструктуру сети хранения данных легально и предсказуемо по срокам в текущих условиях невозможно. Традиционные СХД корпоративного класса, изначально спроектированные под эту инфраструктуру, превращаются в архитектурный тупик.
Модернизация – это всегда отдельный проект
Замена контроллера или покупка новой системы неизбежно превращается в отдельный проект с планированием окон обслуживания, разработкой процедур отката и тестированием каждого приложения после переноса. Цена ошибки максимальна: некорректно выполненная миграция означает либо потерю данных, либо длительный неплановый простой.
Администрирование: проприетарная операционная модель
Закрытость традиционной СХД не ограничивается железом и пронизывает всю операционную модель. Каждый вендор вводит собственные концепции и терминологию: aggregate, vserver и qtree у NetApp, disk group и cache partition у HPE, storage pool и volume group у IBM. Это не универсальные абстракции, а уникальные сущности с уникальным поведением. Даже базовое понятие «том» у каждого вендора реализовано по-своему, со своими ограничениями и своей моделью отказа. Администратор вынужден глубоко погружаться в закрытую экосистему конкретной платформы, и эти знания не переносятся.
Современные SDS: новые возможности и неизбежные компромиссы
Программно-определяемые системы хранения (SDS) предлагают принципиально иную модель: отделение логики хранения от оборудования. Это дает гибкость, горизонтальное масштабирование и независимость от вендора.
Однако на практике многие SDS-решения, стремясь к универсальности, создают новые фундаментальные проблемы, которые порой сводят на нет их преимущества:
1. Непредсказуемая производительность. У большинства SDS скорость работы резко падает при заполнении кластера более чем на 70–80%. Причина архитектурная: файловые системы с семантикой копирования при записи при высоком заполнении пула вынуждены размещать новые блоки во всё более фрагментированном пространстве. В распределенных кластерных системах к этому добавляется неравномерное заполнение узлов хранения: при достижении порога заполнения на отдельных узлах кластер начинает отклонять запись задолго до исчерпания суммарной ёмкости. Система, которая нормально работала при 60% заполнения, становится узким местом инфраструктуры задолго до исчерпания ёмкости.
2.Нерациональное использование ресурсов. Мощное оборудование (быстрые диски, сети 100 GbE) часто не раскрывает свой потенциал из-за неоптимального кода и сложных цепочек обработки данных. Контрольные суммы и обслуживание метаданных выполняются на процессоре узла синхронно с каждой операцией записи. На быстрых дисках, где задержка устройства измеряется десятками микросекунд, именно вычислительная нагрузка на процессор становится узким местом и диски простаивают в ожидании завершения обработки блока.
3.Стандартный стек LIO – тормоз для SDS. Многие SDS, выбирая путь наименьшего сопротивления, используют для поддержки протокола iSCSI стандартный компонент ядра Linux - LIO (Linux-IO Target). Эта архитектура, работающая целиком внутри ядра, создает непреодолимые накладные расходы: каждый запрос проходит через многоуровневый стек сетевой подсистемы, что приводит к частым переключениям задач, избыточному копированию данных и высокой нагрузке на процессор. В результате производительность распределенного кластера упирается в ограничения выбранного программного стека, а не в возможности железа.
4.Сложность реальной эксплуатации. Несмотря на обещание простоты, администрирование таких систем часто требует узкоспециальных знаний для настройки, диагностики и устранения неочевидных сбоев, что превращает их в скрытый источник затрат и рисков.
5.Универсальность в ущерб эффективности. Стремясь подходить для всех задач, многие SDS оказываются недостаточно эффективными для ключевых бизнес-приложений (базы данных, виртуализация), требуя для них сложной дополнительной настройки.
6.Проблема с адаптацией под стандарты критической инфраструктуры. Для использования на объектах КИИ недостаточно просто программного решения. Необходима архитектурная прозрачность, встроенные механизмы безопасности и возможность сертификации по требованиям ФСТЭК, подтвержденная совместимость с отечественными ОС. Большинство SDS-решений этим требованиям не отвечают, поскольку прохождение сертификации в планах их разработки отсутствует.
7.Открытый код - открытый вектор атаки. SDS на базе публичных стеков наследует полный реестр уязвимостей всех своих компонентов. Практический сценарий: критическая уязвимость опубликована в понедельник. Исправление в исходном проекте появляется через месяц. Разработчик дистрибутива включает его в релиз через квартал. Кластер получает обновление в ближайшее плановое окно обслуживания еще через две недели. Все это время команда эксплуатации отслеживает уязвимости вручную по каждому компоненту без встроенного инструментария.
8.Архитектура репликации ограничивает и масштабирование, и эффективность хранения. Ряд SDS-решений поддерживает только попарное зеркалирование как единственный механизм защиты данных. Накладные расходы на хранение составляют от 100% и выше, поскольку каждый байт данных требует двух или трех физических копий. При этом помехоустойчивое кодирование, которое позволяет хранить данные с накладными расходами 60% и ниже, в этих решениях обычно недоступно. Том не может быть распределен между несколькими узлами, а его ёмкость и производительность жестко ограничены дисковым ресурсом одного сервера. Кластер может располагать петабайтами суммарной ёмкости, но отдельный том упирается в потолок одной машины.
Ограничения как отправная точка
Описанные выше ограничения не случайны и не решаются заменой одной модели на другую. Традиционные СХД и большинство программно-определяемых решений решают разные задачи, но воспроизводят одну и ту же проблему: архитектурный компромисс встроен в основу. В первом случае это закрытая экосистема и потолок контроллера, недоступность оборудования и проприетарная операционная модель. Во втором – деградация производительности при заполнении, узкие места в программном стеке, ограниченные методы защиты данных и системные сложности с сертификацией для КИИ. Вопрос не в том, какую из двух моделей выбрать. Вопрос в том, от каких из этих ограничений можно отказаться с точки зрения архитектуры и какой ценой. Мы сформулировали инженерные требования к системе хранения, которые бы учитывали необходимые компромиссы:
Производительность не должна деградировать. В традиционной СХД потолок производительности определяется числом контроллеров: максимум 2, 4, реже 8. В большинстве SDS производительность падает при заполнении кластера из-за фрагментации и неравномерного распределения данных по узлам. Необходимо, чтобы каждый узел одновременно хранил данные и мог участвовать в обработке операций ввода-вывода. Данные алгоритмически распределяются по всем дискам кластера, при каждой операции задействуются все диски одновременно. Добавление узла линейно увеличивает и ёмкость, и производительность.
Надежность не должна быть налогом на объем. Ряд SDS-решений поддерживает только попарное зеркалирование как единственный метод защиты данных: каждый байт требует, как минимум, одной полной физической копии, что означает не менее 100% накладных расходов на хранение. Помехоустойчивое кодирование N+K решает задачу защиты иначе: схема 8+2 выдерживает одновременный отказ любых двух компонентов из десяти, то есть 20% узлов или дисков кластера могут выйти из строя одновременно без потери данных.
Простота не должна означать зависимость. Традиционная СХД привязывает к проприетарному железу, проприетарным запчастям и проприетарной операционной модели на весь срок жизни системы. Система работает на стандартных серверах x86 с твердотельными накопителями и жесткими дисками.
Безопасность не должна быть надстройкой. Для эксплуатации на объектах критической информационной инфраструктуры недостаточно программного решения: необходима архитектурная прозрачность и верифицируемость. Служба аудита фиксирует все API-запросы и команды интерфейса командной строки, все изменения конфигурации, все события аутентификации и доступа. Хронология любого события восстанавливается полностью.
Это стало нашей отправной точкой при проектировании uStor. Как каждое из этих требований реализовано на уровне архитектуры – тема следующей статьи. Подробно разберем модель хранения данных, алгоритм ввода-вывода и организацию отказоустойчивости.