Облачная платформаAdvanced

Обзор хранилища

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Контейнерное хранилище

Kubernetes Container Storage Interface (CSI) — это стандартизированный фреймворк дополнений хранилища, запущенный Cloud Native Computing Foundation (CNCF). Он направлен на разъединение систем хранилища от Kubernetes, позволяя получать доступ к сервисам хранилища как к дополнениям без изменения основного кода Kubernetes. Хранилище CCE построено на основе CSI и поддерживает широкий спектр типов хранилища, включая блочное хранилище, файловое хранилище и объектное хранилище, чтобы удовлетворять потребности как приложений без состояния, так и приложений с состоянием. CSI полностью совместим с нативной системой хранилища Kubernetes и поддерживает несколько форм хранилища, таких как emptyDir, hostPath, secret и ConfigMap.

Рисунок 1 Типы контейнерного хранилища


CCE позволяет pod‑ам рабочей нагрузки использовать несколько типов хранилища:

  • С точки зрения реализации, хранилище поддерживает Container Storage Interface (CSI) и нативное хранилище Kubernetes.

    Тип

    Описание

    CSI

    Стандартизированный механизм плагинов (соответствующий CCE Everest), разработанный для разъединения систем хранилища от оркестрационных платформ, решающий проблему тесной привязки традиционных in‑tree плагинов хранилища к основному коду Kubernetes. Его основная концепция заключается в определении единой спецификации интерфейса gRPC, позволяющей поставщикам хранилища разрабатывать пользовательские плагины хранилища в out‑of‑tree режиме. Это обеспечивает независимую сборку, компиляцию и выпуск функций хранилища без встраивания исходного кода плагина в репозиторий исходного кода Kubernetes. Достаточно объявить требования к хранилищу через PVC и PV. Драйвер CSI обрабатывает остальное, обеспечивая динамическое предоставление и управление хранилищем.

    Начиная с Kubernetes 1.13, CSI стал официально рекомендованной реализацией плагинов хранилища.

    Нативное хранилище Kubernetes

    Работает в режиме in‑tree, когда код плагина хранилища встроен непосредственно в репозиторий основного кода Kubernetes. Это означает, что плагины хранилища собираются, компилируются и выпускаются вместе с основными компонентами Kubernetes, такими как kubelet и kube‑controller‑manager. Плагины хранилища должны обновляться одновременно с Kubernetes. Их нельзя разрабатывать, обновлять или расширять независимо от цикла выпуска Kubernetes. Это ограничивает гибкость поддержки сторонних систем хранилища.

  • С точки зрения носителей хранилища, хранилище может классифицироваться как облачное хранилище, локальное хранилище и объекты ресурсов Kubernetes.

    Тип

    Описание

    Сценарий применения

    Облачное хранилище

    Хранилище предоставляется поставщиками облачных сервисов и позволяет сохранять данные в удалённых кластерах через сети. Это обеспечивает централизованное управление и эластичное масштабирование ресурсов хранилища. В кластере вам достаточно объявить требования к хранилищу через PVCs и PVs. Дополнение CSI автоматически обрабатывает доступ к облачному хранилищу, устраняя необходимость ручной настройки базовых ресурсов.

    Данные требуют высокой доступности или должны быть общими, например, журналы и медиа‑ресурсы.

    Выберите подходящий облачный StorageClass в зависимости от сценария применения. Подробнее см. Cloud Storage Comparison.

    Локальное хранилище

    Носителем хранилища является локальный диск с данными или память узла. Локальный PV — это настроенный StorageClass, предоставляемый CCE и монтируемый с помощью PVCs и PVs через CSI. Другие StorageClass являются нативными для Kubernetes.

    Данные Non-HA требуют высокой производительности ввода‑вывода и низкой задержки.

    Выберите подходящий тип локального хранилища в зависимости от сценария применения. Подробнее см. Local Storage Comparison.

    Объекты ресурсов Kubernetes

    ConfigMaps и secrets — это ресурсы, создаваемые в кластерах. Они представляют собой специальные типы хранилища и предоставляются tmpfs (файловой системой на основе ОЗУ) на сервере API Kubernetes.

    ConfigMaps используются для внедрения конфигурационных данных в pods.

    Secrets используются для передачи конфиденциальной информации, такой как пароли, в pods.

Cloud Storage Comparison

Элемент

EVS

SFS

SFS Turbo

OBS

Определение

Сервис блочного хранилища, работающий в общих пулах ресурсов хранения. Он предоставляет масштабируемые, высокопроизводительные и надежные тома хранения для облачных серверов. Диски EVS доступны в различных спецификациях и являются экономичными.

Масштабируемый до петабайт, SFS предоставляет полностью управляемое совместное файловое хранилище, обладающее высокой доступностью и стабильностью, способное обрабатывать приложения с интенсивным использованием данных и пропускной способности в HPC, обработке медиа, совместном использовании файлов, управлении контентом и веб‑службах.

Масштабируемый до 320 ТБ, SFS Turbo предоставляет полностью управляемое совместное файловое хранилище с высокой доступностью и стабильностью, поддерживая небольшие файлы и приложения, требующие низкой задержки и высокой IOPS. Вы можете использовать SFS Turbo в веб‑сайтах с высоким трафиком, хранении журналов, сжатии/распаковке, DevOps, корпоративных OA и контейнеризованных приложениях.

Масштабируемое, безопасное, надежное и экономичное хранилище для данных любого типа и объёма. Его можно использовать в корпоративных бэкап/архивировании, видеопотоке по запросу (VoD), видеонаблюдении и многих других сценариях.

Логика хранения данных

Хранит двоичные данные и не может напрямую сохранять файлы. Чтобы сохранять файлы, сначала отформатируйте файловую систему.

Хранит файлы и сортирует и отображает данные в иерархии файлов и папок.

Хранит файлы и сортирует и отображает данные в иерархии файлов и папок.

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

Access mode

Доступно только после монтирования к ECSs и инициализации.

Монтируется к ECSs с использованием сетевых протоколов. Необходимо указать сетевой адрес или сопоставить его с локальным каталогом для доступа.

Поддерживает протокол Network File System (NFS) (только NFSv3). Вы можете бесшовно интегрировать существующие приложения и инструменты с SFS Turbo.

Доступно через Internet или Direct Connect. Укажите адрес bucket и используйте протоколы передачи, такие как HTTP или HTTPS.

Static storage volumes

Поддерживается. Подробнее см. Using an Existing EVS Disk Through a Static PV.

Поддерживается. Подробнее см. Using an Existing SFS File System Through a Static PV.

Поддерживается. Подробнее см. Using an Existing SFS Turbo File System Through a Static PV.

Поддерживается. Подробнее см. Using an Existing OBS Bucket Through a Static PV.

Dynamic storage volumes

Поддерживается. Подробнее см. Using an EVS Disk Through a Dynamic PV.

Поддерживается. Подробнее см. Using an SFS File System Through a Dynamic PV.

Поддерживается для поддиректорий SFS Turbo. Подробнее см. (Recommended) Creating an SFS Turbo Subdirectory Using a Dynamic PV.

Поддерживается. Подробнее см. Using an OBS Bucket Through a Dynamic PV.

Функции

Несинхронное хранилище. Каждый volume может быть подключен только к одному node.

Общее хранилище с высокой производительностью и пропускной способностью

Общее хранилище с высокой производительностью и пропускной способностью

Общая файловая система в пользовательском режиме

Сценарии применения

HPC, корпоративные ядровые кластерные приложения, корпоративные прикладные системы и dev/test

ПРИМЕЧАНИЕ:

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

HPC, обработка медиа, управление контентом, веб‑сервисы, большие данные и аналитические приложения

ПРИМЕЧАНИЕ:

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

Веб‑сайты с высоким трафиком, хранение логов, DevOps и корпоративные OA

Аналитика больших данных, хостинг статических веб‑сайтов, онлайн‑видеопоток (VoD), секвенирование генов, интеллектуальное видеонаблюдение, бэкап и архивирование, а также корпоративные облачные коробки (веб‑диски)

Ёмкость

TB

SFS 1.0: PB

General-purpose: TB

EB

Задержка

1–2 ms

SFS 1.0: 3–20 ms

General-purpose: 1–5 ms

10 ms

Max. IOPS

2,200–256,000, в зависимости от флейворов

SFS 1.0: 2,000

General-purpose: до 100,000

Десятки миллионов

Пропускная способность

MB/s

SFS 1.0: GB/s

Общее назначение: до GB/s

TB/s

Сравнение локального хранилища

Элемент

Local PV

Local Ephemeral Volume

emptyDir

hostPath

Определение

Локальные диски узла формируют пул хранилища (VolumeGroup) через LVM. LVM делит их на логические тома (LVs) и монтирует их в pods.

Встроенный в Kubernetes emptyDir, где локальные диски узла формируют пул хранилища (VolumeGroup) через LVM. LVs создаются в качестве носителя хранения emptyDir и монтируются в pods. LVs обеспечивают лучшую производительность, чем носитель хранения по умолчанию для emptyDir.

Встроенный в Kubernetes emptyDir. Его жизненный цикл совпадает с жизненным циклом pod. В качестве носителя хранения можно указать память. При удалении pod том emptyDir удаляется, и его данные теряются.

Используется для монтирования файлового каталога хоста, где находится pod, в указанную точку монтирования pod.

Функции

Низкая задержка, высокая I/O и non-HA PV.

Тома хранения являются несвязанным хранилищем и привязываются к узлам через метки. Поэтому тома хранения могут монтироваться только к одному pod.

Local ephemeral volume. Объём хранения берётся из локальных LVs.

Local ephemeral volume. Объём хранения берётся из локального корневого каталога kubelet или памяти.

Используется для монтирования файлов или каталогов файловой системы host. Каталоги host могут создаваться автоматически. Pods могут мигрировать (не привязаны к узлам).

Монтирование тома хранения

Статические тома хранения не поддерживаются.

Using a Local PV Through a Dynamic PV поддерживается.

Для получения подробной информации см. Local EV.

Для получения подробной информации см. Temporary Path.

Для получения подробной информации см. hostPath.

Сценарии применения

Высокие требования к I/O и встроенные HA‑решения приложений, например, развертывание MySQL в режиме HA.

  • Временное пространство, например, для сортировки слиянием на диске
  • Создание чекпоинтов длительных вычислений для восстановления после сбоев
  • Сохранение файлов, полученных контейнером менеджера контента, при использовании данных контейнера веб‑сервера
  • Временное пространство, например для сортировки слиянием на диске
  • Создание чекпоинтов длительных вычислений для восстановления после сбоев
  • Сохранение файлов, полученных контейнером менеджера контента, при использовании данных контейнера веб‑сервера

Требуется файл узла, например, если используется Docker, можно использовать hostPath для монтирования пути /var/lib/docker узла.

NOTICE:

Избегайте использования томов hostPath насколько это возможно, так как они подвержены рискам безопасности. Если тома hostPath необходимо использовать, они могут быть применены только к файлам или каталогам и монтироваться в режиме только для чтения.

Enterprise Project Support

Note

Чтобы использовать эту функцию, дополнение Everest должно быть обновлено до версии v1.2.33 или более новой.

  • Автоматическое создание хранилища:

    При создании EVS или OBS PVC с использованием StorageClass в CCE вы можете указать enterprise project, чтобы назначить созданные ресурсы хранилища (диски EVS и OBS). Этот enterprise project может быть либо проектом по умолчанию, либо тем же, к которому относится кластер.

    Если enterprise project не указан, enterprise project, указанный в StorageClass, будет использоваться по умолчанию для создания ресурсов хранилища.

    • Для пользовательского StorageClass вы можете указать enterprise project в StorageClass. Подробности см. Creating a StorageClass Through the Console. Если enterprise project не указан в StorageClass, используется enterprise project по умолчанию.
    • Для классов хранилища csi-disk и csi-obs, предоставляемых CCE, созданные ресурсы хранилища принадлежат enterprise project по умолчанию.

  • Использовать существующее хранилище:

    При создании PVC с использованием PV убедитесь, что everest.io/enterprise-project-id, указанный в PVC и PV, одинаковый, поскольку при создании ресурса хранилища был указан проект предприятия. В противном случае PVC и PV не могут быть привязаны.

Полезные ссылки

  • Прежде чем использовать контейнерное хранилище, ознакомьтесь с базовыми понятиями, такими как PVs и PVCs. Для получения подробной информации см. Storage Basics.
  • CCE использует Everest для взаимодействия с облачными сервисами хранилища. Для получения подробной информации об Everest см. CCE Container Storage (Everest).
  • CCE поддерживает следующие типы томов хранилища: