Привет всем 👋

В сегодняшней заметке хочу поделиться опытом подключения дисковой полки Hitachi VSP One Block 26 к кластеру OpenShift по Fibre Channel (FC).

Перед установкой

Отмечу, что ранее СХД была подключена к SAN-сети. На стороне SAN-коммутаторов были созданы алиасы (aliases) и зоннинг (zoning) для серверов OpenShift и полки Hitachi.

Для провижининга дисковых разделов потребуется открыть сетевой доступ по порту 443/TCP между нодами кластера OpenShift и СХД.
Дополнительно, на стороне дисковой полки потребуется создать локального пользователя с правами на создание и маппинг дисков.

Настройка multipathd

Конфигурации multipathd не оказалось в сетапе моего кластера. Эта служба используется для организации многопутевого доступа к блочным устройствам по Fibre Channel/iSCSI.

defaults {
    user_friendly_names yes
    find_multipaths yes
}

blacklist {
}

Кодируем содержимое:

cat ./multipath.conf | base64 -w0

Сгенерированную строку сохраняем себе, она нам пригодится далее.

Создаем YAML-конфигурацию:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: 49-multipath-machineconfig
  labels:
    machineconfiguration.openshift.io/role: worker
    # machineconfiguration.openshift.io/role: master # Раскомментировать, если роли совмещены (Master/Worker)
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<BASE64_STRING>
        verification: {}
        filesystem: root
        mode: 420
        overwrite: true
        path: /etc/multipath.conf

Здесь мы создаем манифест 49-multipath-machineconfig, который из содержимого строки base64 создаст конфигурацию /etc/multipath.conf на узлах кластера.

Стоит также обратить внимание на метки (labels). По умолчанию, конфиг применяется на узлы с ролью - worker:

labels:
  machineconfiguration.openshift.io/role: worker

Но если же по какой-то причине узлы кластера умеют совмещенные роли (master/worker), тогда метка будет такой:

labels:
  machineconfiguration.openshift.io/role: master

Применяем манифест:

oc apply -f 49-multipath-master.yaml

Проверяем:

oc get mcp master

Колонка UPDATED - True и UPDATING — False будет сигнализировать нам об успешном примении изменений.

Установка плагина Hitachi

Namespace

Все объекты плагина поместим в отдельный namespace, создаем манифест и применяем его:

kind: Namespace
apiVersion: v1
metadata:
  name: hscp

Hitachi Storage plug-in

Далее в два клика ставим плагин Hitachi Storage из OperatorHub. Переходим в меню Administrator > Operators > OperatorHub: oc-hitachi-oh1.png После перехода на страницу нужно переключиться в проект/namespace, созданный выше.

Затем в поле поиска указываем название плагина, и проваливаемся в него. Жмем на кнопку Install. oc-hitachi-oh3.png

Нас перебросить на новую страничку инсталятора, oc-hitachi-oh4.png Убеждаемся в коррестности выбранного namespace, в разделе Update approval выбираем ручное подтверждение обновлений компонентов.

Жмем на кнопку - Install.

В течении небольшого периода времени оператор будет готов к использованию, переходим к его настройке: oc-hitachi-oh5.png

Теперь поднимим контроллер, csiDriver, daemonset агентов на нодах. Делается это через кнопку создания нового инстанса: oc-hitachi-oh6.png

В окне с настройками просто жмем на кнопку - Create: oc-hitachi-oh7.png

Пока деплоятся компоненты, создадим секрет и StorageClass.

Secret

В секрет мы добавляем данные для подключения к CХД.

По аналогии с прошлым примером, данные нужно закодировать в формат base64-строки:

echo -n "https://10.10.250.124" | base64
echo -n "ocpuser" | base64
echo -n "Hitachi_pass" | base64

Создаем манифест, в значение полей url, user, password добавляем закодированные строки:

apiVersion: v1
kind: Secret
metadata:
  name: secret-vsp-26
  namespace: hscp
type: Opaque
data:
  url: <BASE64 IP/URL>
  user: <BASE64 USERLOGIN>
  password: <BASE64 PASSWORD>

StorageClass

В документации плагина, есть sample для storageClass с описанием полей, которые нужно будет заменить.

Копируем сэмпл подменяем данные в нем и применяем в кластер:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: vsp-one-26 #(1)
  annotations:
    kubernetes.io/description: Hitachi Storage Plug-in for Containers
provisioner: hspc.csi.hitachi.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  serialNumber: "123329" #(2)
  poolID: "0" #(3)
  portID : CL1-A,CL2-A,CL2-D,CL1-D,CL3-A,CL4-A,CL3-D,CL4-D #(4)
  connectionType: fc #(5)
  storageEfficiency: "CompressionDeduplication" #(6)
  storageEfficiencyMode: "PostProcess" #(7)
  csi.storage.k8s.io/fstype: xfs #(8)
  csi.storage.k8s.io/node-publish-secret-name: "secret-vsp-26" #(9)
  csi.storage.k8s.io/node-publish-secret-namespace: "hscp" #(10)
  csi.storage.k8s.io/provisioner-secret-name: "secret-vsp-26" #(9)
  csi.storage.k8s.io/provisioner-secret-namespace: "hscp" #(10)
  csi.storage.k8s.io/controller-publish-secret-name: "secret-vsp-26" #(9)
  csi.storage.k8s.io/controller-publish-secret-namespace: "hscp" #(10)
  csi.storage.k8s.io/node-stage-secret-name: "secret-vsp-26" #(9)
  csi.storage.k8s.io/node-stage-secret-namespace: "hscp" #(10)
  csi.storage.k8s.io/controller-expand-secret-name: "secret-vsp-26" #(9)
  csi.storage.k8s.io/controller-expand-secret-namespace: "hscp" #(10)

Поля, которые нужно будет поменять:

  • name - здесь указываем понятное имя, желательно с названием системы. (При создании PVC будем ссылкатся на данный SC)
  • serialNumber - серийный номер системы, его можно посмотреть в панели управления полкой VSP,
  • poolID - номер пула, если у вас настроен один дисковый пулл, то с долей вероятность он будет равен 0. При наличии нескольких пулов, нужно также смотреть его id в менеджменте системы VSP.
  • portID - здесь перечисляются порты, которые как правило подключены к SAN-Сети.
  • connectionType - тут оставляем FC (Fibre Channel)

В самом конце, в значениях 9-10 мы указываем имя ранее созданного секрета и namespace. Далее апплаем манифест в кластер.

Тестирование

Для начала проверяем и убеждаемся что все поды поднялись и в статусе Running: oc-hitachi-oh8.png

Затем запустим под из контейнера busybox, во внутрь контейнера примонтируем диск из VSP.

Создаем namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: devs

Пишем манифест для PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-pod-tester
  namespace: devs
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: vsp-one-26

В спецификации манифеста стоит обратить внимание на поля:

  • resources > requests > storage - запрашиваем диск обьемом 20Gb,
  • storageClassName - тут указываем имя ранее созданного storageClass

Пишем манифест для пода:

apiVersion: v1
kind: Pod
metadata:
  name: pv-pod-tester
  namespace: devs
spec:
  containers:
    - name: my-busybox
      image: busybox
      volumeMounts:
        - mountPath: /data
          name: sample-volume
      command:
        - sleep
        - '1000000'
      imagePullPolicy: IfNotPresent
  volumes:
    - name: sample-volume
      persistentVolumeClaim:
        claimName: pvc-pod-tester

Из примечательного, в спецификации пода мы маппим вышестоящий Claim c точкой монтирования /data.

Апплаем все в кластер.

Через некоторое время убеждаемся, что новые объекты были созданы.

Смотрим создался ли новый том. В консоле шифта переходим в раздел Storage > PersistentVolumeClaims и выбираем namespace - devs. oc-hitachi-oh9.png В списке отобразился наш Claim на 20gb, в статусе Bound.

Смотрим создался ли том на хитачи: oc-hitachi-oh10.png

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

Для этого в консоле шифта находим наш под, и запускаем терминал. oc-hitachi-oh11.png

Как можно понять из вывода диск успешно примонтировался.

Глобально нашу задачу можно считать выполненой.

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