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

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

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

Внимание

Эта статья относится к хранилищу контейнеров Azure (версия 2.x.x),которая поддерживает локальный диск NVMe и Azure Elastic SAN в качестве резервных типов хранилища. Дополнительные сведения о более ранних версиях см. в документации Azure Container Storage (версии 1.x.x).

Что такое локальный NVMe?

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

По умолчанию хранилище контейнеров Azure создает универсальные временные тома при использовании локальных дисков NVMe. Для вариантов использования, требующих запроса на выделение постоянного тома, можно добавить аннотацию localdisk.csi.acstor.io/accept-ephemeral-storage: "true" в шаблон запроса на выделение постоянного тома.

Чередование данных

Чтобы повысить производительность, хранилище контейнеров Azure автоматически расчерчивает данные через все доступные локальные диски NVMe на уровне каждой виртуальной машины. Полосование — это метод, при котором данные делятся на небольшие блоки и равномерно записываются на несколько дисков одновременно, что увеличивает пропускную способность и улучшает общую производительность операций ввода-вывода. Это поведение включено по умолчанию и не может быть отключено.

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

Например, серия Lsv3 масштабируется с одного диска NVMe 1,92 ТБ на Standard_L8s_v3 (около 400 000 операций ввода-вывода в секунду и 20 000 МБ/с) до 10 дисков NVMe на Standard_L80s_v3 (около 3,8 млн операций ввода-вывода в секунду и 20 000 МБ/с).

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

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

  • Для этой статьи требуется Azure CLI версии 2.83.0 или более поздней. Дополнительные сведения см. в статье "Установка Azure CLI". Отключите такие расширения, как aks-preview если возникают проблемы. Установите или обновите расширения по мере необходимости:

    • az extension add --upgrade --name k8s-extension
    • az extension add --upgrade --name elastic-san (только Elastic SAN)

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

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

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

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

Выполните следующую команду, чтобы получить тип виртуальной машины, используемый с пулом узлов. Замените <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

Примечание.

В хранилище контейнеров Azure (версия 2.x.x.x) теперь можно использовать кластеры с менее чем тремя узлами.

В сценариях, когда размеры виртуальных машин с одним локальным диском NVMe используются вместе с временными дисками ОС, локальный диск NVMe выделяется для ОС, поэтому для использования Azure Container Storage не остается ресурсов. Чтобы обеспечить оптимальную производительность и доступность локальных дисков NVMe для высокопроизводительной обработки данных, рекомендуется выполнить следующие действия.

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

Дополнительные сведения см. в рекомендациях по эфемерным дискам данных NVMe в службе Azure Kubernetes.

Создание класса хранилища для локального NVMe

Если у вас еще нет хранилища контейнеров Azure, установите его.

Хранилище контейнеров Azure (версия 2.x.x) представляет локальный NVMe в качестве стандартного класса хранилища Kubernetes. Создайте класс хранилища один раз для кластера и используйте его как для универсальных временных томов, так и для запросов на постоянные тома.

  1. Используйте ваш любимый текстовый редактор для создания файла манифеста YAML, например storageclass.yaml, затем вставьте следующую спецификацию.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-csi
provisioner: localdisk.csi.acstor.io
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

  2. Примените манифест для создания класса хранилища.

    kubectl apply -f storageclass.yaml

Кроме того, можно создать класс хранилища с помощью Terraform.

  1. Используйте Terraform для управления классом хранения, создав конфигурацию, как показано ниже main.tf. Обновите версию поставщика или путь kubeconfig по мере необходимости для вашей среды.

    terraform {
  required_version = ">= 1.5.0"
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 3.0"
    }
  }
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

resource "kubernetes_storage_class_v1" "local_csi" {
  metadata {
    name = "local-csi"
  }

  storage_provisioner    = "localdisk.csi.acstor.io"
  reclaim_policy         = "Delete"
  volume_binding_mode    = "WaitForFirstConsumer"
  allow_volume_expansion = true
}

  2. Инициализация, проверка и применение конфигурации для создания класса хранилища.

    terraform init
terraform plan
terraform apply

Проверка класса хранилища

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

kubectl get storageclass local-csi

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

NAME       PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-csi  localdisk.csi.acstor.io    Delete          WaitForFirstConsumer   true                   10s

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

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

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

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

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

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

    kind: Pod
apiVersion: v1
metadata:
  name: fiopod
spec:
  nodeSelector:
    "kubernetes.io/os": linux
  containers:
    - name: fio
      image: mayadata/fio
      args: ["sleep", "1000000"]
      volumeMounts:
        - mountPath: "/volume"
          name: ephemeralvolume
  volumes:
    - name: ephemeralvolume
      ephemeral:
        volumeClaimTemplate:
          spec:
            volumeMode: Filesystem
            accessModes: ["ReadWriteOnce"]
            storageClassName: local-csi
            resources:
              requests:
                storage: 10Gi

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

    kubectl apply -f fiopod.yaml

Проверка развертывания и выполнение тестов

Убедитесь, что модуль pod запущен:

kubectl get pod fiopod

Вы должны увидеть pod в состоянии 'Running'. Запустив программу, вы можете выполнить тест с использованием Fio benchmark:

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

Создайте и прикрепите постоянные тома с аннотацией эфемерного хранилища

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

Примечание.

Хранилище контейнеров Azure (версия 2.x.x) использует новую заметку localdisk.csi.acstor.io/accept-ephemeral-storage: "true" вместо предыдущей acstor.azure.com/accept-ephemeral-storage: "true".

Убедитесь, что хранилище контейнеров Azure установлено , а local-csi класс хранилища, созданный ранее, доступен перед развертыванием рабочих нагрузок, использующих его.

Развернуть StatefulSet с постоянными томами

Если необходимо использовать запросы на постоянный том, которые не привязаны к жизненному циклу Pod, следует добавить аннотацию localdisk.csi.acstor.io/accept-ephemeral-storage: "true". Данные тома являются локальными для узла и теряются, если узел удаляется или pod перемещается на другой узел.

Ниже приведен пример набора с отслеживанием состояния с использованием постоянных томов с заметкой о эфемерном хранилище:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-lcd-lvm-annotation
  labels:
    app: busybox
spec:
  podManagementPolicy: Parallel
  serviceName: statefulset-lcd
  replicas: 10
  template:
    metadata:
      labels:
        app: busybox
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
        - name: statefulset-lcd
          image: mcr.microsoft.com/azurelinux/busybox:1.36
          command:
            - "/bin/sh"
            - "-c"
            - set -euo pipefail; trap exit TERM; while true; do date -u +"%Y-%m-%dT%H:%M:%SZ" >> /mnt/lcd/outfile; sleep 1; done
          volumeMounts:
            - name: persistent-storage
              mountPath: /mnt/lcd
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: busybox
  volumeClaimTemplates:
    - metadata:
        name: persistent-storage
        annotations:
          localdisk.csi.acstor.io/accept-ephemeral-storage: "true"
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: local-csi
        resources:
          requests:
            storage: 10Gi

Сохраните и примените этот YAML, чтобы создать StatefulSet с постоянными хранилищами.

kubectl apply -f statefulset-pvc.yaml

Управление хранилищем

В этом разделе описано, как проверить емкость временного диска узла, расширить емкость хранилища и удалить ресурсы хранилища.

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

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

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

kubectl get csistoragecapacities.storage.k8s.io -n kube-system -o custom-columns=NAME:.metadata.name,STORAGE_CLASS:.storageClassName,CAPACITY:.capacity,NODE:.nodeTopology.matchLabels."topology\.localdisk\.csi\.acstor\.io/node"

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

NAME          STORAGE_CLASS   CAPACITY    NODE
csisc-2pkx4   local-csi       1373172Mi   aks-storagepool-31410930-vmss000001
csisc-gnmm9   local-csi       1373172Mi   aks-storagepool-31410930-vmss000000

Если вы столкнулись с пустыми данными о емкости, убедитесь, что StorageClass для localdisk.csi.acstor.io существует. Ресурс csistoragecapacities.storage.k8s.io создается только после того, как storageClass для localdisk.csi.acstor.io существует.

Расширение емкости хранилища

Так как эфемерное хранилище дисков использует локальные ресурсы на узлах кластера AKS, расширение емкости хранилища требует добавления узлов в кластер.

Чтобы добавить узел в кластер, выполните следующую команду. Замените <cluster-name>, <nodepool-name><resource-group>и <new-count> вашими значениями.

az aks nodepool scale --cluster-name <cluster-name> --name <nodepool-name> --resource-group <resource-group> --node-count <new-count>

Удаление ресурсов хранилища

Чтобы очистить ресурсы хранилища, необходимо сначала удалить все PersistentVolumeClaims и/или PersistentVolumes. Удаление хранилища контейнеров Azure StorageClass не удаляет существующие функции PersistentVolumes/PersistentVolumeClaims.

Чтобы удалить класс хранилища с именем local-csi, выполните следующую команду:

kubectl delete storageclass local-csi

См. также

  • Last updated on