Поделиться через

Использование хранилища контейнеров Azure с локальным NVMe и репликацией томов

  • Статья

Хранилище контейнеров Azure — это облачная служба управления томами, развертывания и оркестрации, специально созданная для контейнеров. В этой статье описывается, как настроить хранилище контейнеров Azure для использования временных дисков с локальными NVMe и репликацией томов в качестве серверного хранилища для рабочих нагрузок Kubernetes. В конце концов у вас будет модуль pod, использующий локальный NVMe в качестве хранилища. Репликация копирует данные между томами на разных узлах и восстанавливает том при потере реплики, обеспечивая устойчивость для эфемерного диска.

Что такое временный диск?

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

Существует два типа эфемерного диска: локальный NVMe и временный SSD. NVMe предназначен для высокоскоростной передачи данных между хранилищем и ЦП. Выберите NVMe, если приложению требуется больше операций ввода-вывода в секунду или пропускная способность, чем временный SSD, или требуется больше места в хранилище. Помните, что хранилище контейнеров Azure поддерживает только синхронную репликацию данных для локального NVMe.

Благодаря эфемерной природе этих дисков хранилище контейнеров Azure поддерживает использование универсальных временных томов по умолчанию при использовании временных дисков. Однако некоторые варианты использования могут вызывать постоянные тома , даже если данные не устойчивы. Например, если вы хотите использовать существующие файлы YAML или шаблоны развертывания, которые жестко закодируются для использования постоянных томов, а рабочая нагрузка поддерживает репликацию на уровне приложения для устойчивости. В таких случаях можно обновить установку хранилища контейнеров Azure и добавить аннотацию acstor.azure.com/accept-ephemeral-storage=true в определение запроса на постоянный том для поддержки создания постоянных томов из временных пулов дискового хранилища.

Предварительные условия

  • Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем приступить к работе.

  • Для этой статьи требуется последняя версия (2.35.0 или более поздняя) Azure CLI. Узнайте , как установить Azure CLI. Если вы используете среду Bash в Azure Cloud Shell, то последняя версия уже установлена. Если вы планируете выполнять команды локально, а не в Azure Cloud Shell, обязательно запустите их с правами администратора. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".

  • Вам потребуется клиент командной строки Kubernetes. kubectl Он уже установлен, если вы используете Azure Cloud Shell или вы можете установить его локально, выполнив az aks install-cli команду.

  • Если вы еще не установили хранилище контейнеров Azure, следуйте инструкциям в статье "Использование хранилища контейнеров Azure с Служба Azure Kubernetes".

  • Проверьте, поддерживается ли целевой регион в регионах хранилища контейнеров Azure.

Выбор типа виртуальной машины, поддерживающей локальный NVMe

Локальный диск NVMe доступен только в определенных типах виртуальных машин, например, SKU виртуальных машин, оптимизированных для хранения или SKU виртуальных машин с ускорением на GPU. Если вы планируете использовать локальный NVMe, выберите один из этих номеров SKU виртуальных машин.

Выполните следующую команду, чтобы получить тип виртуальной машины, используемый с пулом узлов. Замените <resource group> и <cluster name> собственными значениями. Вам не нужно указывать значения PoolName или VmSize, поэтому сохраните запрос, как показано здесь.

az aks nodepool list --resource-group <resource group> --cluster-name <cluster name> --query "[].{PoolName:name, VmSize:vmSize}" -o table

Ниже приведен пример выходных данных.

PoolName    VmSize
----------  ---------------
nodepool1   standard_l8s_v3

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

Создание и присоединение универсальных временных томов

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

1. Создание пула хранения с репликацией томов

Сначала создайте пул носителей, который является логическим группированием хранилища для кластера Kubernetes, определив его в файле манифеста YAML.

Если вы активировали хранилище контейнеров Azure с помощью az aks create или az aks update команд, возможно, у вас уже есть пул хранения. Используйте kubectl get sp -n acstor для получения списка пулов хранения. Если у вас уже есть пул носителей, который вы хотите использовать, можно пропустить этот раздел и перейти к отображению доступных классов хранилища.

Выполните следующие действия, чтобы создать пул носителей с помощью локальной NVMe с репликацией. В настоящее время служба хранилища контейнеров Azure поддерживает конфигурации с тремя репликами и пятью репликами. Если указать три реплики, в кластере AKS должно быть не менее трех узлов. ** Если указать пять реплик, надо иметь как минимум пять узлов.

Примечание.

Так как пулы носителей временных дисков используют все доступные диски NVMe, необходимо удалить все существующие локальные пулы носителей NVMe перед созданием нового пула носителей.

  1. Используйте избранный текстовый редактор для создания файла манифеста YAML, code acstor-storagepool.yamlнапример.

  2. Вставьте следующий код и сохраните файл. Значение имени пула name может быть любым.

    apiVersion: containerstorage.azure.com/v1
kind: StoragePool
metadata:
  name: ephemeraldisk-nvme
  namespace: acstor
spec:
  poolType:
    ephemeralDisk:
      diskType: nvme
      replicas: 3

  3. Примените файл манифеста YAML для создания пула носителей.

    kubectl apply -f acstor-storagepool.yaml

    После завершения создания пула носителей вы увидите следующее сообщение:

    storagepool.containerstorage.azure.com/ephemeraldisk-nvme created

    Эту команду можно также запустить, чтобы проверить состояние пула носителей. Замените <storage-pool-name> значением имени пула носителей. В этом примере значение будет ephemeraldisk-nvme.

    kubectl describe sp <storage-pool-name> -n acstor

При создании пула хранилища Azure Container Storage создаст класс хранилища от вашего имени, используя соглашение об именовании acstor-<storage-pool-name>.

2. Отображение доступных классов хранилища

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

Запустите kubectl get sc , чтобы отобразить доступные классы хранилища. Вы увидите класс хранилища с именем acstor-<storage-pool-name>.

$ kubectl get sc | grep "^acstor-"
acstor-azuredisk-internal   disk.csi.azure.com               Retain          WaitForFirstConsumer   true                   65m
acstor-ephemeraldisk-nvme        containerstorage.csi.azure.com   Delete          WaitForFirstConsumer   true                   2m27s

Внимание

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

3. Развертывание модуля pod с универсальным временным томом

Создайте pod с помощью Fio (гибкий тестировщик ввода-вывода) для тестирования и моделирования рабочих нагрузок, используя универсальный временный том.

  1. Используйте избранный текстовый редактор для создания файла манифеста YAML, code acstor-pod.yamlнапример.

  2. Вставьте следующий код и сохраните файл.

    kind: Pod
apiVersion: v1
metadata:
  name: fiopod
spec:
  nodeSelector:
    acstor.azure.com/io-engine: acstor
  containers:
    - name: fio
      image: nixery.dev/shell/fio
      args:
        - sleep
        - "1000000"
      volumeMounts:
        - mountPath: "/volume"
          name: ephemeralvolume
  volumes:
    - name: ephemeralvolume
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              type: my-ephemeral-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: acstor-ephemeraldisk-nvme # replace with the name of your storage class if different
            resources:
              requests:
                storage: 1Gi

    При изменении размера хранилища томов убедитесь, что размер меньше доступной емкости временного диска одного узла. См. раздел Проверка емкости эфемерного диска узла.

  3. Примените файл манифеста YAML для развертывания модуля pod.

    kubectl apply -f acstor-pod.yaml

    Вы должны увидеть результат, аналогичный приведенному ниже:

    pod/fiopod created

  4. Убедитесь, что pod запущен и что ephemeral volume claim успешно привязан к pod.

    kubectl describe pod fiopod
kubectl describe pvc fiopod-ephemeralvolume

  5. Проверьте тестирование fio, чтобы просмотреть текущее состояние:

    kubectl exec -it fiopod -- fio --name=benchtest --size=800m --filename=/volume/test --direct=1 --rw=randrw --ioengine=libaio --bs=4k --iodepth=16 --numjobs=8 --time_based --runtime=60

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

Создание и присоединение постоянных томов

Чтобы создать постоянный том из эфемерного хранилища дисков, необходимо включить аннотацию в заявки на постоянные тома (PVCs) в качестве меры предосторожности, чтобы гарантировать, что вы намерены использовать постоянные тома даже если данные являются эфемерными. Кроме того, перед созданием запросов на постоянный том необходимо включить --ephemeral-disk-volume-type флаг с PersistentVolumeWithAnnotation значением в кластере.

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

1. Обновление установки хранилища контейнеров Azure

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

az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage ephemeralDisk --storage-pool-option NVMe --ephemeral-disk-volume-type PersistentVolumeWithAnnotation

2. Создайте накопитель с репликацией томов

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

Примечание.

Так как пулы носителей временных дисков используют все доступные диски NVMe, необходимо удалить все существующие локальные пулы носителей NVMe перед созданием нового пула носителей.

  1. Используйте избранный текстовый редактор для создания файла манифеста YAML, code acstor-storagepool.yamlнапример.

  2. Вставьте следующий код и сохраните файл. Значение имени пула носителей может быть любым на ваш выбор. Задайте для реплик значение 3 или 5.

    apiVersion: containerstorage.azure.com/v1
kind: StoragePool
metadata:
  name: ephemeraldisk-nvme
  namespace: acstor
spec:
  poolType:
    ephemeralDisk:
      diskType: nvme
      replicas: 3

  3. Примените файл манифеста YAML для создания пула носителей.

    kubectl apply -f acstor-storagepool.yaml

    После завершения создания пула носителей вы увидите следующее сообщение:

    storagepool.containerstorage.azure.com/ephemeraldisk-nvme created

    Эту команду можно также запустить, чтобы проверить состояние пула носителей. Замените <storage-pool-name> значением имени пула носителей. В этом примере значение будет ephemeraldisk-nvme.

    kubectl describe sp <storage-pool-name> -n acstor

При создании пула хранилища, хранилище контейнеров Azure создаст класс хранилища от вашего имени, используя соглашение acstor-<storage-pool-name> об именовании.

3. Отображение доступных классов хранилища

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

Запустите kubectl get sc , чтобы отобразить доступные классы хранилища. Вы увидите класс хранилища с именем acstor-<storage-pool-name>.

$ kubectl get sc | grep "^acstor-"
acstor-azuredisk-internal   disk.csi.azure.com               Retain          WaitForFirstConsumer   true                   65m
acstor-ephemeraldisk-nvme        containerstorage.csi.azure.com   Delete          WaitForFirstConsumer   true                   2m27s

Внимание

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

4. Создайте запрос на постоянный том

Запрос постоянного тома (PVC) используется для автоматической подготовки хранилища на основе класса хранения. Выполните следующие действия, чтобы создать ПВХ с помощью нового класса хранения.

  1. Используйте избранный текстовый редактор для создания файла манифеста YAML, code acstor-pvc.yamlнапример.

  2. Вставьте следующий код и сохраните файл. Значение ПВХ name может быть каким хотите.

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ephemeralpvc
  annotations:
    acstor.azure.com/accept-ephemeral-storage: "true"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: acstor-ephemeraldisk-nvme # replace with the name of your storage class if different
  resources:
    requests:
      storage: 100Gi

    При изменении размера хранилища томов убедитесь, что размер меньше доступной емкости временного диска одного узла. См. Проверка емкости эфемерного диска узла.

  3. Примените файл манифеста YAML для создания ПВХ.

    kubectl apply -f acstor-pvc.yaml

    Должен отобразиться примерно такой результат:

    persistentvolumeclaim/ephemeralpvc created

    Вы можете проверить состояние ПВХ, выполнив следующую команду:

    kubectl describe pvc ephemeralpvc

После создания PVC он готов к использованию подом.

5. Развертывание модуля pod и подключение постоянного тома

Создайте модуль pod с помощью Fio (гибкий средство тестирования ввода-вывода) для тестирования и моделирования рабочих нагрузок и укажите путь подключения для постоянного тома. Для имени запроса используйте значение имени, которое вы использовали при создании запроса постоянного тома.

  1. Используйте избранный текстовый редактор для создания файла манифеста YAML, code acstor-pod.yamlнапример.

  2. Вставьте следующий код и сохраните файл.

    kind: Pod
apiVersion: v1
metadata:
  name: fiopod
spec:
  nodeSelector:
    acstor.azure.com/io-engine: acstor
  volumes:
    - name: ephemeralpv
      persistentVolumeClaim:
        claimName: ephemeralpvc
  containers:
    - name: fio
      image: nixery.dev/shell/fio
      args:
        - sleep
        - "1000000"
      volumeMounts:
        - mountPath: "/volume"
          name: ephemeralpv

  3. Примените файл манифеста YAML для развертывания модуля pod.

    kubectl apply -f acstor-pod.yaml

    Вы должны увидеть результат, аналогичный приведенному ниже:

    pod/fiopod created

  4. Убедитесь, что модуль pod запущен и что утверждение постоянного тома успешно привязано к pod:

    kubectl describe pod fiopod
kubectl describe pvc ephemeralpvc

  5. Проверьте тестирование fio, чтобы просмотреть текущее состояние:

    kubectl exec -it fiopod -- fio --name=benchtest --size=800m --filename=/volume/test --direct=1 --rw=randrw --ioengine=libaio --bs=4k --iodepth=16 --numjobs=8 --time_based --runtime=60

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

Управление томами и пулами хранения

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

Проверка емкости временного диска узла

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

Выполните следующую команду, чтобы проверить доступную емкость эфемерного диска для одного узла.

$ kubectl get diskpool -n acstor
NAME                                CAPACITY      AVAILABLE     USED        RESERVED    READY   AGE
ephemeraldisk-nvme-diskpool-jaxwb   75660001280   75031990272   628011008   560902144   True    21h
ephemeraldisk-nvme-diskpool-wzixx   75660001280   75031990272   628011008   560902144   True    21h
ephemeraldisk-nvme-diskpool-xbtlj   75660001280   75031990272   628011008   560902144   True    21h

В этом примере доступная емкость эфемерного диска для одного узла составляет 75031990272 байт или 69 ГиБ.

Отключите и подключите постоянный том заново

Чтобы отсоединить постоянный том, удалите модуль pod, к которому он подключен.

kubectl delete pods <pod-name>

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

Чтобы проверить, к какому постоянному тому привязан запрос на постоянный объем, выполните следующую команду:

kubectl get pvc <persistent-volume-claim-name>

Включение гиперконвергенции (необязательно)

Что такое гиперконвергенция?

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

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

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

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

Поведение гиперконвергенции для нереплицированных и реплицированных томов

Нереплицированные тома NVMe/TempSSD:

  • Гиперконвергенция включена по умолчанию.

  • Если подходящий узел недоступен с локализованным пулом дисков, модуль pod приложения не сможет запуститься из-за нехватки ресурсов.

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

Реплицированные тома NVMe/TempSSD:

  • Гиперконвергенция — это лучшие усилия.

  • Планировщик попытается разместить модуль pod приложения на том же узле, что и одна из реплик тома.

  • Если подходящий узел недоступен, модуль pod по-прежнему будет запланирован в другом месте, но производительность чтения может быть ниже ожидаемой.

Принцип работы

Если включена гиперконвергенция, хранилище контейнеров Azure определяет приоритет планирования модулей pod на узлах, где находятся их реплики томов.

  1. Планировщик Kubernetes по умолчанию назначает оценки всем узлам на основе стандартных параметров, таких как ЦП, память, сходство и терпимости.
  2. Оценка предпочтений узлов хранилища контейнеров Azure: Хранилище контейнеров Azure использует предпочтительную привязанность узлов для влияния на решения планировщика. Таким образом, каждый узел получает:
    • 1 точка, если у него есть допустимый пул дисков.
    • 1 точка, если она уже размещает реплику тома; эти оценки являются аддитивными и предоставляют небольшое предпочтение узлам с локальными репликами томов при соблюдении других критериев планирования.
  3. Окончательное решение о планировании: планировщик Kubernetes объединяет оценки по умолчанию с оценками на основе привязки к хранилищу контейнеров Azure. Узел с наивысшей совокупной оценкой, учитывающей и предпочтения хранилища Azure Container Storage, и стандартную логику Kubernetes, выбирается для размещения pod.

Когда использовать гиперконвергенцию

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

Рассмотрите возможность включения гиперконвергенции для реплицированных томов в следующих случаях:

  • Высокая производительность чтения важна. Сохранение рабочих нагрузок и реплик хранилища на одном узле снижает задержку в сети и повышает производительность чтения.
  • Локальность данных может значительно повлиять на производительность— приложения, которые часто считываются из хранилища, получают снижение передачи данных между узлами.

Когда не использовать гиперконвергенцию

Примечание. Этот раздел применяется только к реплицированным томам, так как гиперконвергенция всегда применяется для нереплицированных томов.

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

  • Потенциальный дисбаланс ресурсов: хотя гиперконвергенция сама по себе не ограничивает количество приложений на узле, если несколько рабочих нагрузок создают реплики на одном узле; и если этому узлу не хватает ресурсов (процессора, памяти или пропускной способности хранилища), некоторые рабочие нагрузки могут не иметь возможности быть запланированными там. В результате они могут в конечном итоге работать без гиперконвергенции, несмотря на то, что он включен.

Включение гиперконвергенции в хранилище контейнеров Azure

Гиперконвергенция включена по умолчанию для NVMe и временных пулов носителей дисков с одной репликой. Это обеспечивает оптимизированную локализацию данных и улучшенную производительность для конфигураций с одной репликой. При настройке нескольких реплик гиперконвергенция по умолчанию не включена, но может быть настроена hyperconverged с помощью параметра в спецификации StoragePool.

Ниже приведен пример шаблона YAML для включения гиперконвергенции для конфигураций с несколькими репликами:

apiVersion: containerstorage.azure.com/v1 

kind: StoragePool 

metadata: 

  name: nvmedisk 

  namespace: acstor 

spec: 

  poolType: 

    ephemeralDisk: 

      diskType: "nvme" 

      replicas: 3 

      hyperconverged: true

Расширить пул хранения

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

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

  1. Выполните следующую команду, чтобы добавить узел в кластер AKS. Замените <cluster-name>, <nodepool name> и <resource-group-name> собственными значениями. Чтобы получить имя пула узлов, выполните команду kubectl get nodes.

    az aks nodepool add --cluster-name <cluster name> --name <nodepool name> --resource-group <resource group> --node-vm-size Standard_L8s_v3 --node-count 1 --labels acstor.azure.com/io-engine=acstor

  2. Запустите kubectl get nodes и увидите, что узел был добавлен в кластер.

  3. Запустите kubectl get sp -A и убедитесь, что емкость пула носителей увеличилась.

Удаление пула носителей

Если вы хотите удалить пул носителей, выполните следующую команду. Замените <storage-pool-name> именем пула хранения.

kubectl delete sp -n acstor <storage-pool-name>

Оптимизация производительности при использовании локального NVMe

В зависимости от требований к производительности рабочей нагрузки можно выбрать три различных уровня производительности: "Базовый", "Стандартный" и "Премиум". Эти уровни предлагают различный диапазон операций ввода-вывода в секунду (IOPS), и ваш выбор повлияет на количество виртуальных ЦП, которые компоненты хранилища контейнеров Azure используют в узлах, где они установлены. Стандартная конфигурация по умолчанию, если вы не обновляете уровень производительности.

Репликация в одной зоне

Уровень Количество виртуальных ЦП. 100 % операций ввода-вывода в секунду 100 % операций ввода-вывода в секунду
Basic 12,5% от общего числа ядер виртуальных машин До 120 000 До 45 000
Standard (по умолчанию) 25 % общих ядер виртуальных машин До 220 000 До 90 000
Premium 50% общих ядер виртуальных машин До 550 000 До 180 000

Репликация в нескольких зонах

Уровень Количество виртуальных ЦП. 100 % операций ввода-вывода в секунду 100 % операций ввода-вывода в секунду
Basic 12,5% от общего числа ядер виртуальных машин До 120 000 До 45 000
Standard (по умолчанию) 25 % общих ядер виртуальных машин До 220 000 До 90 000
Premium 50% общих ядер виртуальных машин До 550 000 До 180 000

Примечание.

Потребление ОЗУ и огромных страниц будет оставаться постоянным на всех уровнях: 1 ГиБ ОЗУ и 2 ГиБ огромных страниц.

После определения уровня производительности, который соответствует вашим потребностям, можно выполнить следующую команду, чтобы обновить уровень производительности установки хранилища контейнеров Azure. Замените <performance tier> базовым, стандартным или премиумом.

az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type> --ephemeral-disk-nvme-perf-tier <performance-tier>

См. также