Публикации
Новое поколение СХД Fujitsu ETERNUS, статья
Зональное хранение данных, статья
За пределами суперкомпьютеров, статья
Применение Intel® Optane™ DC и Intel® FPGA PAC, статья
Weka для AI-трансформации, статья
Cloudera Data Platform – “лучшее из двух миров”, статья
Excelero NVEdge для HA IoT-эры, статья
Адаптивные HPC/AI-архитектуры для экзаскейл-эры, статья
HPE: легкий путь в IIoT, статья
DAOS: СХД для HPC/BigData/AI приложений в эру экзаскейл_вычислений, статья
IPsec в пост-квантовую эру, статья
Дезагрегированные компонуемые среды для высокопроизводительных задач, статья
HPE Primera: интеллектуальная СХД HPE 3PAR, статья
HPE Elastic Platform for Big Data and Analytics, статья
LiCO: оркестрация гибридныхНРС/AI/BigData_инфраструктур, статья
FusionStorage 8.X: облачное хранилище для ЦОД нового поколения, статья
Микросхемы ускорения вычислений нейросетей, статья
Persistent Memory: новый уровень хранения данных, статья
Как строить озера данных? , статья
End-to-end NVMe AFA-массивы Huawei, статья
SweRV Core – первое RISC-V процессорное ядро Western Digital, статья
Преимущества использования SCM-кэша в составе внешних СХД HPE, статья
Технологии кэширования данных современных СХД, статья
 
Обзоры
Все обзоры в 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
Редакция: 115516, Москва, а/я 88; тел./факс - (495) 233-4935;
www.storagenews.ru; info@storagenews.ru.