19.08.2024 07:47
Skilline 0 338 Источник

Существуют различные технологии по уплотнению ресурсов физических серверов с целью их более эффективного использования. Наиболее известный вариант – это виртуализация. Именно в данной сфере системы хранения данных (СХД) являются одним из ключевых элементов, поскольку позволяют достаточно легко реализовать кластеры высокой доступности (HA cluster). Однако, помимо виртуализации доступны иные методы повышения эффективности, одним из которых является применение контейнеров.

Давайте приведем краткие отличия виртуальных машин от контейнеров.

Виртуальные машины:

  • Полностью изолированная среда виртуальных машин друг от друга и от гипервизора за счет аппаратных средств хоста;

  • Тип внутренней операционной системы не обязан совпадать с типом операционной системы хоста;

  • Размер ВМ обычно начинается от нескольких ГБ;

  • Требуется резервирование ресурсов для каждой ВМ;

  • Старт ВМ обычно измеряется в минутах.

Контейнеры:

  • Изоляция друг от друга осуществляется исключительно программными средствами операционной системы хоста;

  • Внутренняя операционная система точно такая же, как и ОС хоста;

  • Размер контейнера может быть весьма незначительным (буквально от десятков МБ);

  • Требуется минимум ресурсов для работы самого контейнера;

  • Старт обычно измеряется в секундах.

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

Одним из часто используемых средств управления контейнерами является Kubernetes, где помимо оркестрации непосредственно самих контейнеров, требуется также управление выделенными под них ресурсами хоста. И одним из таких ресурсов является пространство хранения, в качестве которого могут выступать тома СХД.

Безусловно, управление дисковыми ресурсами может осуществляться вручную. Но возможность управления всем из одного окна куда удобнее. Достигается это благодаря стандартному протоколу взаимодействия CSI. СХД Qsan XCubeSAN как раз поддерживают такой протокол. И далее мы опишем, как добиться динамического выделения пространства хранения со стороны хоста.

Ряд замечаний

Поддерживаются только thick пулы

В рамках единой хост группы может быть создано до 32 CSI томов. При попытке создать 33-й том будет получено сообщение об ошибке

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

При подготовке статьи использовались в том числе иллюстрации, взятые из материалов производителя СХД. Желающие могут ознакомится с ними в оригинале.

Первым шагом является включение Timestamp для фиксирования времени обращения к каждому конкретному тому на стороне СХД (System -> Settings -> Enable timestamp). По умолчанию данная опция выключена, т.к. оказывает негативное влияние на общую производительность.

Далее необходимо создать требуемый пул типа thick (пусть будет Pool_01) и будущую хост группу (пусть будет test1). После переключаем внимание на хост, где необходимо установить CSI driver:

git clone https://github.com/QsanJohnson/csi-qsan

В папке csi-qsan/deploy требуется внести изменения в файл qsan-auth.yaml, а именно указать IP адреса интерфейсов управления СХД и пароль администратора.

Затем запустить скрипт установки csi-qsan/deploy/install.sh

Проверить статус установки можно командой kubectl get pod -n qsan

Далее в папке csi-qsan/deploy/example правим файл sc.yaml. Необходимо задать StorageClass name (оно пригодится позже), указать IP портов управления и iSCSI, имя пула (в нашем случае Pool_01) и имя iSCSI target. iSCSI target можно узнать на вкладке соответствующей хост группы.

Теперь применяем конфигурацию и проверяем статус

kubectl apply -f sc.yaml

kubectl get sc

Следующим шагом правим файл pvc.yaml, где PersistentVolumeClaim name, требуемый размер тома (пусть будет 100ГБ) и StorageClass name (sc-test, который мы задавали ранее).

Также применяем конфигурацию и проверяем статус

kubectl apply -f pvc.yaml

kubectl get pvc

И, наконец, правим файл pod.yaml, где необходимо задать PersistentVolumeClaim name из предыдущего шага

Все так же применяем конфигурацию и проверяем статус

kubectl apply -f pod.yaml

kubectl get pod

В результате наших действий должен создаться том 100ГБ на пуле Pool_01 в указанной хост группе test1. Проверяем на стороне СХД, что это так и есть.

Теперь остается скорректировать multipath.conf с целью включения MPIO для таких томов. Для этого добавляем в указанный файл дополнительные данные.

defaults {
	path_grouping_policy	multibus
	user_friendly_names	no
	find_multipaths		no
getuid_callout		“/lib/udev/scsi_id --replace-whitespace --whitelisted --dev
}

В данной статье были представлены основные шаги для установления связи между сервером Kubernetes и СХД Qsan XCubeSAN. Для более подробных сведений настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.

Комментарии (0)