Публикации
2023 г. – новый этап практического применения CXL, статья
VMware сдвигает акцент в проекте Capitola на CXL, статья
Dell Validated Design for Analytics — Data Lakehouse: интегрированное хранилище данных, статья
OCP Global Summit: решения для Computational Storage и компонуемых масштабируемых архитектур, статья
Samsung CXL MemoryySemantic SSD: 20M IOPs, статья
UCIe – открытый протокол для взаимосвязи чиплетов и построения дезагрегированных инфраструктур, статья
Omni-Path Express – открытый интерконнект для экзафлопных HPC/AI-систем, статья
GigaIO: CDI_решение на базе AMD для высшего образования, статья
Энергоэффективные ЦОД на примерах решений Supermicro, Lenovo, Iceotope, Meta, статья
От хранилищ данных и “озер данных” к open data lakehouse и фабрике данных, статья
EuroHPC JU развивает НРС-экосистему на базе RISC-V, статья
LightOS™ 2.2 – программно-определяемое составное блочное NVMe/TCP хранилище, статья
End-to-end 64G FC NAFA, статья
Computational Storage, статья
Технология KIOXIA Software-Enabled Flash™, статья
Pavilion: 200 млн IOPS на стойку, статья
CXL 2.0: инновации в операциях Load/Store вводаавывода, статья
Тестирование референсной архитектуры Weka AI на базе NVIDIA DGX A100, статья
Fujitsu ETERNUS CS8000 – единая масштабируемая платформа для резервного копирования и архивирования, статья
SmartNIC – новый уровень инфраструктурной обработки, статья
Ethernet SSD, JBOF, EBOF и дезагрегированные хранилища, статья
Compute, Memory и Storage, статья
Lenovo: CXL – будущее серверов с многоуровневой памятью , статья
Liqid: компонуемые дезагрегированные инфраструктуры для HPC и AI, статья
Intel® Agilex™ FPGA, статья
Weka для AI-трансформации, статья
Cloudera Data Platform – “лучшее из двух миров”, статья
Fujitsu ETERNUS DSP - разработано для будущего, статья
Технологии охлаждения для следующего поколения HPC-решений, статья
Что такое современный HBA?, статья
Fugaku– самый быстрый суперкомпьютер в мире, статья
НРС – эпоха революционных изменений, статья
Новое поколение СХД Fujitsu ETERNUS, статья
Зональное хранение данных, статья
За пределами суперкомпьютеров, статья
Применение Intel® Optane™ DC и Intel® FPGA PAC, статья
Адаптивные HPC/AI-архитектуры для экзаскейл-эры, статья
DAOS: СХД для HPC/BigData/AI приложений в эру экзаскейл_вычислений, статья
IPsec в пост-квантовую эру, статья
LiCO: оркестрация гибридныхНРС/AI/BigData_инфраструктур, статья
 
Обзоры
Все обзоры в Storage News
 
Тематические публикации
Flash-память
Облачные вычисления/сервисы
Специализ. СХД для BI-хранилищ, аналитика "больших данных", интеграция данных
Современные СХД
Информационная безопасность (ИБ), борьба с мошенничеством
Рынки
Постоянное хранилище для масштабируемых bare-metal контейнеров Kubernetes

28, июль 2020  —  Контейнеры появились как способ сделать программное обеспечение переносимым. Контейнер содержит все пакеты, необходимые для запуска сервиса. Обеспеченная изоляция делает контейнеры чрезвычайно портативными и удобными в разработке. Контейнер может быть перемещен из разработки в тестовую среду или в производство без каких-либо или относительно небольших изменений конфигурации.

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

Контейнеры и платформы управления для них в основном разрабатывались для поддержки высокодинамичных операций (например, микросервисов) без сохранения состояния, при этом контейнеры непрерывно создавались и уничтожались для удовлетворения различных рабочих нагрузок. Одновременно удалялись и данные, созданные с помощью приложения в контейнерах (в основном, это было свойственно для приложений в ранних облачных архитектурах, которые плохо масштабировались). В приложении без сохранения состояния каждый сеанс выполняется, как в первый раз, а ответы не зависят от данных предыдущего сеанса. Приложения без сохранения состояния лучше подходят для облачных вычислений, так как их легче развертывать в случае сбоя и масштабировать с учетом изменений. Однако многие операции требуют, чтобы данные сохранялись после срока службы контейнера, что может противоречить природе контейнера. Для решения этой проблемы стали разрабатываться stateful-приложения, которые сохраняют данные клиента после действий одного сеанса для использования в следующем сеансе. Чтобы решить эти проблемы, например, Kubernetes представил плагин FlexVolume. Недавно Kubernetes выпустил плагин, соответствующий новому стандарту Container Storage Interface (CSI), который обещает упростить процесс сохранения данных на различных платформах хранения.

Все приложения, имеющие базу данных и необходимость постоянного хранения, требуют постоянного хранилища. Внедрение постоянного хранилища для контейнеров является одной из главных задач администраторов Kubernetes, DevOps и облачных инженеров, т.к необходимо обеспечить его выживание в случае удаления контейнера или сбоя оборудования.

Kubernetes является отраслевым стандартом для развертывания контейнеров в масштабе. С беспрецедентным уровнем принятия, Kubernetes стал основой для современной инфраструктуры и новых информационных технологий, как показал ОПРОС CNCF 2019 ( https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf ) – 78% респондентов используют Kubernetes в производстве (по сравнению с 58% годом ранее).

По мере развития экосистемы пользователи понимают, что им необходимо постоянное общее хранилище для своих контейнеров. Именно это привело к созданию и массовому внедрению постоянных томов и CSI (интерфейс хранения контейнеров). Эта эволюция уже произошла в более зрелых экосистемах – например, Amazon AWS или OpenStack, обе они начинали с локальных дисков для виртуальных машин / экземпляров, а затем поняли, что им требуется постоянная общая база данных хранения, и в настоящее время все рабочие нагрузки выполняются таким образом.

Проблемы с постоянными томами

Постоянные тома (PV, Persistent Volumes) являются неотъемлемой частью кластера Kubernetes. Система хранения, которая предоставляет PV, как минимум, должна быть:

  • надежной ;
  • представлять современное решение SDS, в котором больше нет привязки к поставщику оборудования;
  • распределенной, в которой больше нет единой точки отказа;
  • масштабируемой – без каких-либо ограничений роста;
  • быстрой – обеспечивать высокую производительность для ускорения всех контейнерных приложений.

В общедоступном облаке PV предоставляются собственной службой в общедоступном облаке: EBS в Amazon ECS и Persistent Disk в Google Cloud GKE. Однако многие компании имеют необходимость запускать кластеры Kubernetes за пределами общедоступного облака – в этом случае им необходимо создавать локальные развертывания K8S.

Более того, не каждый вариант использования подходит для работы в публичных облаках. Иногда эксплуатационные расходы на данные (загрузка, сохранение, загрузка) могут быть очень высокими, как в случае, когда NASA забыло о выходных затратах для своего хранилища данных объемом 247 петабайт в случае AWS ( https://www.computing.co.uk/news/4012760/nasa-egress-costs-aws ). В других случаях использование общедоступных облачных сервисов может быть неприемлемым или невозможным из-за норм и местного законодательства. Даже сервисные ограничения (например, максимальное количество ядер ЦП, объем ОЗУ и т. д.) могут быть ограничителем.

StorPool (http://storpool.com/) одно из лучших в своем классе SDS-решений, которое позволяет заново создать стек общедоступных облаков в центре обработки данных и отвечает всем вышеперечисленным основным требованиям современного хранилища Persistent Volumes для Kubernetes.

Читать полный обзор - http://www.storagenews.ru/news/2020/StorPool_76.pdf

Публикации по теме
Центры обработки данных
 
Новости StorPool

© "Storage News" journal, Russia&CIS
(495) 233-4935;
www.storagenews.ru; info@storagenews.ru.