Рассмотрим ключевые решения при предоставлении хранилища для контейнеризированных приложений и выбор между блочным, файловым или объектным хранилищем. — computerweekly.com
Когда контейнеры только появились, они задумывались как эфемерные — без сохранения состояния, одноразовые и с минимальным объемом данных. Но все изменилось. Как отмечает Gartner, сценарии использования контейнеров эволюционировали, включив в себя аналитику и обработку искусственного интеллекта (ИИ), и к 2028 году, по прогнозам, 15% локальных производственных рабочих нагрузок будут выполняться в контейнерах. Это рост на 300% с 2022 года. Теперь, хотя сами контейнеры сохраняют все преимущества эфемерности — быстрое воспроизведение, а затем такое же быстрое исчезновение для компенсации всплесков рабочей нагрузки, — хранилище, подключенное к ним, не может жить по тем же правилам. По мере того как предприятия переходят от проверки концепций к запуску значительной части производственных рабочих нагрузок в контейнерах, уровень хранения стал поворотным моментом. Если на ранних этапах основное внимание уделялось простому масштабированию веб-приложений, то теперь контейнеры перешли в область критически важных баз данных, масштабных конвейеров науки о данных и энергоемкого мира генеративного ИИ (GenAI). Задача заключается в навигации по ключевым выборам, таким как хранение в виде файлов, блоков или объектов, CSI против нативного для контейнеров хранения и вопрос о выборе выделенной платформы хранения для контейнеров.
Контейнеризация — это легковесная виртуализация
Контейнеризация — это легковесная форма виртуализации. В отличие от традиционных виртуальных машин (ВМ), которым требуется гипервизор и полноценная гостевая операционная система (ОС), контейнеры используют общую ОС хоста. Это делает их легче, быстрее масштабируемыми и более переносимыми. Они построены на принципах микросервисов, которые разбивают монолитные приложения на дискретные компоненты, связанные через интерфейс прикладного программирования (API), что соответствует методологиям DevOps. Хотя существует несколько оркестраторов (например, Docker Swarm и OpenShift), Kubernetes является лидером рынка. Он управляет кластером узлов, где поды запускают контейнеры. Кластеры — это группы узлов, управляемые плоскостью управления (control plane), где мы находим API-сервер, планировщик для размещения подов, контроллер для поддержания желаемого состояния и etcd для конфигурации хранения. В первоначальной концепции хранение контейнеров было эфемерным, и данные исчезали при удалении пода. Поэтому для поддержки корпоративных приложений в Kubernetes были разработаны постоянные тома (PV), которые подключаются к кластеру и отделяют хранилище от вычислений, чтобы приложения могли оставаться переносимыми, сохраняя при этом доступ к данным.
CSI против нативного для контейнеров хранения
Container Storage Interface (CSI) — это стандарт, который позволяет поставщикам систем хранения — доступно более 130 драйверов — предоставлять свои системы для Kubernetes. CSI позволяет Kubernetes запускать расширенные службы данных, такие как снимки, клонирование и автоматическое выделение ресурсов для блочного, файлового и объектного хранилищ в локальных и облачных средах. CSI, по сути, является «брокером». Это отраслевой стандартный API, который выступает в роли посредника, позволяя Kubernetes взаимодействовать с внешними массивами хранения. Например, когда разработчик запрашивает хранилище через запрос постоянного тома (PVC), драйвер CSI указывает внешней системе хранения выделить часть емкости и подключить ее к контейнеру. Преимущество в том, что вы можете использовать дорогостоящее, надежное корпоративное хранилище, которым вы уже владеете, но хранилище по-прежнему «вне» кластера, и если вы переместите контейнеры в другое облако или центр обработки данных, этого внешнего оборудования может не оказаться. Между тем, нативное для контейнеров хранилище — это хранилище, которое находится внутри кластера Kubernetes. Обычно оно развертывается как набор самих контейнеров. Оно использует указанные диски, подключенные к узлам Kubernetes, и объединяет их в один большой виртуальный ресурс. Нативное для контейнеров хранилище потенциально имеет преимущество в переносимости — локально, в облаке и т. д., благодаря присущей ему виртуализации, в то время как CSI, скорее всего, привязывает развертывание к развернутым массивам хранения. Нативное для контейнеров хранилище не зависит от местоположения, поэтому вы можете запустить ту же конфигурацию локально или в облаке. Но оно может потреблять центральный процессор (CPU) и оперативную память (RAM) ваших узлов Kubernetes для управления данными, что может вызывать беспокойство.
Действительно ли контейнерам нужна такая переносимость?
CSI обеспечивает подключение к мощным, полнофункциональным системам хранения, а нативное для контейнеров хранилище обещает гибкость развертывания, переносимость и так далее. Но так ли важна переносимость? Эрик Феникс, руководитель инженерной практики в аналитической компании GigaOm, считает, что нет. «Контейнеры предлагают уровень абстракции вычислений, который делает приложение независимым от инфраструктуры, а не решение, предназначенное для повышения переносимости приложений», — говорит он. Феникс утверждает, что хотя контейнеры делают код агностичным, развертывание — это другой вопрос. «Если только компания не является клиентоориентированной PaaS [платформа как услуга] с необходимостью работать в каждом облаке, я не вижу необходимости запускать одну и ту же рабочую нагрузку в нескольких облаках. Как только что-то развернуто, миграция всегда сопряжена с трудностями», — говорит он. И эта «затруднительность» почти всегда связана с данными, по мнению Феникса. В то время как образ контейнера может перемещаться за секунды, многотерабайтный постоянный том, подключенный к нему, — нет. Джеймс Браун, аналитик GigaOm, отмечает, что нативное для контейнеров хранилище по сути является программно-определяемым хранилищем и несет свои собственные привязки. «Сильно интегрированные проприетарные платформы нативных для контейнеров поставщиков рискуют заменить привязку к аппаратному обеспечению привязкой к программному обеспечению. Привязка вашей архитектуры к проприетарным функциям хранения внутри кластера создает огромные препятствия для миграции, фактически нарушая основное обещание переносимости Kubernetes», — говорит он. Таким образом, выбор здесь сводится к тому, насколько переносимыми должны быть ваши системы. Предприятия часто используют гибридный подход: CSI для подключения к массивным, высокопроизводительным массивам для самых тяжелых баз данных; нативное для контейнеров хранилище для современных, распределенных приложений, которые должны иметь возможность перемещаться без «затруднительной» миграции данных. В 2026 году выбор правильного протокола хранения для контейнерного хранилища — это игра в «смешанной экономике», когда кластер Kubernetes может одновременно использовать все три формата.
Блочное хранение для высокой производительности
Блочное хранение представляет данные как необработанный, неформатированный том — как физический жесткий диск, — который подключается только к одному узлу за раз. В Kubernetes это обычно обрабатывается через постоянные тома с режимом доступа ReadWriteOnce (RWO). Блочное хранилище может находиться в локальных массивах или в облаке, например, в Amazon Elastic Block Store (EBS), Google Persistent Disk или Microsoft Azure Disk. Блочное хранилище обеспечивает самую низкую задержку и наибольшее количество операций ввода-вывода в секунду (IOPS), поскольку между приложением и хранилищем отсутствует накладной расход файловой системы. Это делает его идеальным для баз данных, где небольшие, частые обновления происходят в определенных местах внутри файлов. Что касается недостатков, большинство блочных хранилищ не могут быть подключены к нескольким подам в разных узлах одновременно, а масштабирование обычно требует изменения размера тома и расширения файловой системы. Блочное хранилище, как правило, является и самым дорогим.
Файловое хранение для доступа к каталогам
Файловое хранение предоставляет общее иерархическое пространство имен (папки и файлы), доступное по сети. В Kubernetes это основной способ достижения ReadWriteMany, позволяющий нескольким подам на разных узлах читать и записывать одни и те же данные. Оно также доступно в локальных системах хранения или облачных сервисах, таких как Amazon Elastic File System (EFS), Microsoft Azure Files и Google Filestore. Файловый доступ идеально подходит для горизонтального масштабирования веб-серверов, где всем подам нужен доступ к одним и тем же ресурсам, а большинство устаревших приложений созданы для чтения/записи в стандартную структуру каталогов. По сравнению с блочным доступом сетевые протоколы, такие как NFS или SMB, вносят большую задержку, а при больших масштабах (миллионы файлов) обход глубоких деревьев каталогов может стать чрезвычайно медленным. Между тем, обработка одновременных операций записи в нескольких подах может привести к конфликтам блокировки файлов, если не управлять ею осторожно.
Объектное хранение для крупных хранилищ данных
Объектное хранение управляет данными как отдельными объектами в плоском пространстве имен и доступ к нему осуществляется через API (например, S3 или Swift), а не «подключается» как диск. Это облачный нативный протокол хранения, хотя он также может работать локально. Примеры включают Amazon Simple Storage Service (S3), MinIO, Google Cloud Storage и Ceph RGW. Объектное хранение может хранить петабайты данных без беспокойства об ограничениях разделов или размерах дисков и обычно является самым дешевым вариантом для неструктурированных данных в больших масштабах (журналы, изображения, резервные копии). Объектное хранение идеально подходит для современных «облачных нативных» приложений, которые взаимодействуют с хранилищем напрямую через HTTP/HTTPS, полностью минуя ядро ОС. С другой стороны, объектное хранение, как правило, является самым медленным для транзакционной работы с высокой пропускной способностью, но с более высокой задержкой, чем блочное или файловое. При этом вы не можете «отредактировать» одну строку в файле; вам нужно перезагрузить весь объект, чтобы изменить его.
Принятие решений о протоколе хранения
Таким образом, блочное хранение дорогое, но самое производительное, файловое хранение менее затратное, но с ограничениями по масштабу, а объектное хранение отлично подходит для огромной емкости, но также отстает с точки зрения производительности. Так что же выбрать? Это случай «каждому свое», по словам Тони Лока, директора по взаимодействию и ведущего аналитика Freeform Dynamics. «В идеальном мире выбор базового хранилища — блочного, файлового или объектного — вероятно, будет зависеть от того, что это за приложение, где организация хочет его запустить и каковы его характеристики с точки зрения размера, количества контейнеров, требований к задержке, безопасности, местоположения, стоимости и т. д.», — говорит он. Между тем, Уит Уолтерс, главный технический директор GigaOm, считает, что S3 выигрывает битву, но у блочного хранилища есть свое место. Он говорит: «Настоящая история — это бифуркация протоколов внутри конвейеров ИИ. Объектное хранилище доминирует на уровне приема данных и озер данных, предлагая горизонтальное масштабирование экзабайтного масштаба с богатыми, настраиваемыми метаданными, которые обеспечивают семантический поиск нативно на уровне хранения. «Блочное хранилище по-прежнему владеет горячим путем вывода, где векторные базы данных требуют 500 000+ IOPS, однако. «Появляющаяся тенденция, за которой стоит следить, — это COSI, Container Object Storage Interface, который нацелен на то, чтобы сделать корзины объектного хранения первоклассными ресурсами Kubernetes со стандартизированным, декларативным управлением жизненным циклом»».
CSI против нативного для контейнеров в платформе поставщика хранилища для контейнеров
Все крупные поставщики систем хранения предлагают ту или иную форму платформы или оболочки для контейнерного хранения. К ним относятся Container Storage Modules от Dell, Ezmeral Runtime Enterprise от HPE, Hitachi Kubernetes Service (HKS), Astra от NetApp и Portworx от Everpure. Общее у них всех — средство управления контейнерным хранилищем, а в некоторых случаях и защита данных и многое другое. Различия под капотом заключаются в том, что большинство из них основаны на CSI, поэтому они предоставляют уровень для управления драйверами CSI для своего хранилища. Некоторые отличаются тем, что предоставляют свои функции управления изнутри Kubernetes. Например, Portworx от Everpure полностью находится в Kubernetes, но использует CSI в качестве «рукопожатия» с внешним хранилищем. Между тем, HPE Ezmeral также работает в Kubernetes, но получает доступ к данным через драйвер CSI. Astra Datastore от NetApp была нативной для контейнеров, подобно Portworx, но была прекращена в 2023 году. Хотя все ключевые поставщики систем хранения предлагают продукты, которые могут управлять хранилищем для контейнеров, обязательно проверьте, в какой степени они являются нативными для контейнеров или зависят от CSI. Как упоминалось, подключение через CSI может лучше подходить для больших, более статичных сред, в то время как нативные для контейнеров решения могут быть лучшими для более динамичных наборов рабочих нагрузок. Уолтерс из GigaOm уточняет: «Налог Kubernetes реален, но это компромисс. Нативные для контейнеров платформы выполняют репликацию, дедупликацию и шифрование на рабочих узлах. Только Ceph несет базовую нагрузку ЦП в размере 2–10% на узел только для кворума кластера, и эта нагрузка резко возрастает во время восстановления реплик. «В средах ИИ с высокой плотностью ГП [графический процессор], где на счету каждый цикл, выгрузка этой работы на специализированные ASIC [приложения с конкретной областью применения] массива через продвинутую модель CSI оставляет вычислительные узлы чистыми. Но в сценариях с мультиоблаком или периферийными вычислениями без выделенных массивов этот налог на ЦП дает вам топологически-осведомленное размещение и самовосстанавливающуюся автоматизацию, которую действительно трудно воспроизвести иным образом»». Могут также возникнуть соображения по производительности с точки зрения конкуренции за ресурсы, а также вопросы о том, как они администрируются.
К автономному, агентивному хранилищу
По мере приближения к 2027 году фокус смещается с ручного выделения ресурсов на хранение на основе политик. Конечная цель — система, где хранилище «ощущает» требования рабочей нагрузки. Например, если запускается контейнер для обучения ИИ, система автоматически выделяет высокопроизводительное файловое хранилище, или если база данных масштабируется, она получает блочное хранилище с низкой задержкой.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Antony Adshead