Всем привет! Я Василий — инженер архитектурных решений в команде Deckhouse Storage. Мы занимаемся хранилищами для Kubernetes — от локальных дисков до «железных» СХД — и знаем: в любом кластере рано или поздно встаёт задача надёжного хранения данных приложений, запущенных в нём. Самый простой путь — держать данные на локальном диске сервера, но если узел или диск выйдет из строя, информация может быть утрачена безвозвратно. Разумеется, есть приложения, умеющие реплицировать данные сами (например, распределённые БД или Elasticsearch), но для большинства сервисов потеря хранилища остаётся серьёзной проблемой.

Риск потери данных при отказе узла могут решить внешние СХД либо гиперконвергентные SDS-решения(например, на основе Ceph или DRBD, но о них мы поговорим в другой статье). Мы интегрировали в платформу драйверы CSI (Container Storage Interface), предоставляемые вендорами для платформ от Hewlett Packard Enterprise (HPE), Huawei, NetApp и YADRO. Однако в реальных инфраструктурах может встречаться устаревшее или нестандартное оборудование, для которого нет CSI-драйверов от вендора, либо которое мы ещё не интегрировали с нашей платформой, но для таких случаев у нас есть универсальное решение.

В этой статье поговорим о интегрированных нами CSI-модулях от вендоров оборудования, а также рассмотрим универсальный модуль, который позволяет кластеру работать с любой СХД, использующей протоколы iSCSI (Internet Small Computer Systems Interface) и Fibre Channe.

Модули, использующие CSI-драйверы от вендоров

Одно из преимуществ модулей от производителей — они могут управлять СХД, то есть посредством специального API создавать, удалять и расширять тома, создавать и удалять снимки. 

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

Может возникнуть вопрос, зачем использовать модули Deckhouse Kubernetes Platform (DKP), когда можно просто установить в кластер оригинальные CSI-драйверы? На это есть ряд причин. 

1. В процессе упаковки в модуль мы тестируем продукт с реальным железом (да, мы покупаем непосредственно СХД для команды разработки), чтобы убедиться, что никакие особенности нашей платформы не мешают корректной работе CSI. На этом этапе были случаи, когда доносили до производителя обнаруженные проблемы. 

2. Можем приносить предложения по улучшению вендорам. Сейчас, например, работаем над csi-huawei с целью полного отказа от Shell внутри контейнера для обеспечения большей безопасности при использовании в кластере.

3. Гоняем нагрузочные тестирования, так как на этом этапе тоже могут быть особенности и ситуации, например СХД может ограничивать количество запросов к API, и исходя из тестов подбираем оптимальные по нашему и клиентскому опыту настройки.

4. Упрощаем установку. Сам по себе модуль ставится с помощью одного манифеста, в дополнение к этому мы скрываем за двумя-тремя своими CRD настройку всего, что необходимо для работы оригинальных CSI-драйверов. Принесённые нами контроллеры максимально скрывают за собой все недра, избавляя от необходимости вникать в достаточно большое количество специфической документации. 

И параллельно мы работаем над унификацией уже наших интерфейсов. Цель: настроил один модуль подключения к СХД — понимаешь, как настроить любой. Мы хотим получить максимально похожий пользовательский опыт от работы с любым модулем.

Также мы готовим модули к сертификации ФСТЭК России — проверяем их на известные уязвимости, максимально их закрываем, проводим статический анализ и собираем конечные модули из исходников, храним код у себя в Git, а образы — в своих registry, что означает, что они не исчезнут никуда в результате форс-мажоров. На данный момент модуль csi-yadro-tatlin-unified уже готов к включению во ФСТЭК-редакцию нашей платформы и появится в новом релизе, а в перспективе имеем такие же планы на csi-huawei и csi-netapp.

Кратко пройдёмся по модулям на основе CSI-драйверов от вендоров, которые используются в Deckhouse Kubernetes Platform.

csi-huawei

Данный модуль поддерживает управления томами с использованием различных СХД Huawei, включая серии OceanStor Dorado(V3,V6), OceanStor (V6, V5), FusionStorage, FusionStorage Block, OceanStor Pacific. 

CSI-драйвер позволяет подключать устройства хранения по популярным протоколам (iSCSI, FC, NFS) и полноценно управлять томами: создавать, удалять и изменять размер. Также он поддерживает работу со снимками томов (volume snapshots).

csi-hpe

Модуль на основе CSI-драйвера от компании HPE предоставляет возможности, схожие с модулем Huawei: умеет управлять СХД — создавать, удалять и изменять размеры томов, — а также поддерживает работу со снимкам.

CSI-драйвер поддерживает СХД на платформах Alletra Storage MP B10000, Alletra OS 9000, Alletra OS 5000/6000, Nimble OS, Primera OS и 3PAR OS.

Поддерживаются протоколы iSCSI и Fibre Channel. NFS в этих СХД поддерживается, но не работает «из коробки» на самой системе хранения. Вместо этого в кластере автоматически создаётся служебный под с встроенным NFS-сервером. К этому поду подключается выделенный на СХД том, после чего он экспортируется как NFS. Уже этот NFS-экспорт монтируется в пользовательский под.

csi-netapp

Данный модуль поддерживает управление томами с использованием СХД, совместимых с Trident CSI, включая серии NetApp All SAN Array (ASA) и Element (HCI/SolidFire).

CSI-драйвер позволяет подключать устройства хранения по популярным протоколам (iSCSI и FC) и полноценно управлять томами: создавать, удалять и изменять размер. Также он поддерживает работу со снимками томов (volume snapshots). Поддержка NFS возможна через конфигурацию Trident как NAS-бэкенда, но в модуле сделан акцент на блочном хранении.

csi-yadro-tatlin-unified

Также не забыли отечественных производителей СХД. Компания YADRO разработала серию систем хранения данных TATLIN.UNIFIED и предоставляет для них CSI-драйвер. Функционал модуля полноценный, как и у других производителей, включает управление конфигурацией СХД: создание, расширение и удаление томов, создание снимков томов.

Поддерживаются протоколы iSCSI и Fibre Channel — как и во всех современных модулях.

Читайте о совместимости экосистемы продуктов Deckhouse от «Фланта» и TATLIN.UNIFIED.

Универсальный csi-драйвер сsi-scsi-generic

_{One Ring to rule them all, One Ring to find them, One Ring to bring them all, and in the darkness bind them.} 

_{© John Ronald Reuel Tolkien, Lord of The Rings}

Вендорские модули действительно удобны, но что делать, если СХД уже не поддерживается, но по-прежнему ещё служит верой и правдой? Или если нужно быстро подключить SCSI/iSCSI-устройство, а специализированного CSI-драйвера под систему не существует?

В таких случаях универсальные CSI-драйверы становятся настоящим спасением. С их помощью нельзя управлять СХД, но они позволяют использовать несколько разных источников — несколько разных СХД — без необходимости подключать дополнительные модули. 

Именно для таких задач команда Deckhouse создала модуль csi-scsi-generic. Пусть у него нет возможности управлять источником, но он будет незаменим, когда нужно подключить СХД уже сейчас, а csi-драйвера нет. 

С помощью сsi-scsi-generic можно подключать любые устройства, совместимые с протоколом SCSI (через iSCSI или Fibre Channel), без необходимости управлять самим источником (iSCSI Target/СХД). Такой подход особенно полезен в инфраструктурах, где есть разные типы хранилищ: старая СХД, Ceph, FreeNAS. Используя один универсальный модуль с разными конфигами, можно подключать и использовать весь набор устройств.

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

Хоть это и накладывает определённые ограничения на конфигурацию (все тома должны быть доступны на всех узлах), так у нас есть возможность подключать конкретные тома на конкретных узлах кластера.

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

Не забыли также и про поддержку multipath IO — стандартного решения для повышения отказоустойчивости оборудования и балансировки нагрузки. 

сsi-scsi-generic также не поддерживает создания снимков и удобного расширения томов, так как такой функционал находится на уровне системы хранения. Ничего не поделаешь, за универсальность нужно платить. Однако мы постарались подсветить этот момент для администратора платформы. В случае запроса на расширение тома CSI создаёт ресурсы PendingResizeRequest, ориентируясь на которые можно оперативно расширять тома на СХД. В ближайшем будущем мы добавим в кластере алерты на появление таких запросов, чтобы администраторов СХД можно было оповещать автоматически.

Заключение

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

А как вы решаете задачу интеграции хранилищ и управления ими в своей инфраструктуре?

P. S.

Читайте также в нашем блоге:

• Единый механизм указания значений по умолчанию для StorageClass: централизованный подход Deckhouse

• Лучшие практики по настройке конфигураций в Kubernetes

• Cloud Native LVM: как автоматизировать поиск и разметку локальных дисков в Kubernetes