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

Конфигурация хранилища

  • Статья

Основные понятия, связанные с хранилищем Kubernetes

Kubernetes предоставляет слой абстрагирования инфраструктуры, располагающийся над базовым (необязательным) техническим стеком виртуализации и оборудованием. Способ, с помощью которого Kubernetes выполняет абстрагирование хранилища, заключается в использовании классов хранения. При подготовке pod можно указать класс хранения для каждого тома. Когда pod готов, вызывается средство подготовки класса хранения, чтобы подготовить к работе хранилище, а затем в этом подготовленном хранилище создается постоянный том, и pod подключается к постоянному тому с помощью утверждения постоянного тома.

Kubernetes предоставляет поставщикам инфраструктуры хранилища возможность подключать драйверы (также называемые "надстройками"), которые расширяют возможности Kubernetes. Надстройки хранилища должны соответствовать стандарту Container Storage Interface. В этом неокончательном списке драйверов CSI можно найти десятки надстроек. Используемый драйвер CSI зависит от таких факторов, как запуск в облачной службе, управляемой службе Kubernetes или поставщике oem, используемом для оборудования.

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

kubectl get storageclass

Пример выходных данных для кластера Службы Azure Kubernetes (AKS):

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

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

kubectl describe storageclass/<storage class name>

Пример:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

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

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Пример отображения постоянных томов:


kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Пример отображения заявок на постоянные тома:


kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Факторы, учитываемые при выборе конфигурации хранилища

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

Обычно существует два типа учетных записей хранения:

  • Локальное хранилище — хранилище, подготавливаемое к работе на локальных жестких дисках определенного узла. Такой тип хранилища может быть идеальным в плане производительности, но в ходе его разработки требуется учитывать, что нужно обеспечивать избыточность данных за счет репликации данных между несколькими узлами.
  • Удаленное общее хранилище — хранилище, подготавливаемое к работе на удаленном запоминающем устройстве. Например, в сети хранения данных, в NAS или в такой службе облачного хранения, как EBS или Azure Files. Этот тип хранилища обычно автоматически обеспечивает избыточность данных, но работает не так быстро, как локальное хранилище.

Классы хранения на основе NFS

В зависимости от конфигурации NFS-сервера и средства подготовки класса хранения может потребоваться установить supplementalGroups в конфигурации pod для экземпляров базы данных. Может также потребоваться изменить конфигурацию NFS-сервера для использования идентификаторов групп, переданных клиентом (в отличие от поиска идентификаторов групп на сервере по переданному идентификатору пользователя). Обратитесь к администратору NFS, чтобы определить, в этом ли дело.

Свойство supplementalGroups принимает массив значений, которые можно задать во время развертывания. Контроллер данных Azure Arc применяет их к любым экземплярам базы данных, которые он создает.

Для настройки этого свойства выполните следующую команду:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Конфигурация хранилища контроллера данных

Некоторые службы в Azure Arc для служб данных зависят от настройки, связанной с использованием удаленного общего хранилища, поскольку эти службы не могут реплицировать данные. В коллекции объектов pod для контроллеров данных находятся следующие служб:

Служба Заявки на постоянные тома
OpenSearch <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0
InfluxDB <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0
Экземпляр SQL контроллера <namespace>/logs-controldb, <namespace>/data-controldb
Служба API контроллера <namespace>/data-controller

В ходе подготовки к работе контроллера данных класс хранения, который будет использоваться для каждого из этих постоянных томов, указывается либо путем передачи параметра --storage-class | -sc для команды az arcdata dc create, либо путем настройки классов хранения в используемом файле шаблона развертывания control.json. Если вы используете портал Azure для создания контроллера данных в режиме прямого подключения, шаблон развертывания, который вы выбрали, имеет определенный класс хранилища в шаблоне или вы можете выбрать шаблон, который не имеет предопределенного класса хранилища. Если шаблон не определяет класс хранилища, портал запрашивает его. При использовании пользовательского шаблона развертывания можно указать класс хранения.

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

Если вы задаете класс хранилища с помощью --storage-class или -scпараметра, этот класс хранилища используется как для классов журналов, так и для хранения данных. Если в файле шаблона развертывания задать классы хранения, можно указать различные классы хранения для журналов и данных.

Важные факторы, которые следует учитывать при выборе класса хранения для объектов pod контроллера данных:

  • Необходимо использовать класс удаленного общего хранилища, чтобы обеспечить устойчивость данных. Таким образом, если pod или узел удаляется, после восстановления модуль pod может снова подключиться к постоянному тому.
  • Данные, записываемые в экземпляр SQL контроллера, базу данных метрик и базу данных журналов, обычно характеризуются довольно низким объемом, и задержка не важна для них. Поэтому наличие хранилища с крайне высокой производительностью не обязательно. Если у вас есть пользователи, которые часто используют интерфейсы Grafana и Kibana, а также большое количество экземпляров базы данных, пользователи могут воспользоваться преимуществами более быстродействующего хранилища.
  • Требуемая емкость хранилища — это переменная, определяющая количество развернутых экземпляров базы данных, так как журналы и метрики собираются для каждого экземпляра базы данных. Данные хранятся в журналах и базе данных метрик в течение двух (2) недель, а затем удаляются.
  • Изменение класса хранения после развертывания выполняется сложно, не документируется и не поддерживается. Не забудьте правильно выбрать класс хранения во время развертывания.

Примечание.

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

Конфигурация хранилища экземпляров базы данных

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

При создании экземпляра с помощью az sql mi-arc create одного или или az postgres server-arc createчетырех параметров, которые можно использовать для задания классов хранилища:

Название параметра, краткое название Используется для
--storage-class-data, -d Класс хранилища для всех файлов данных (.mdf, ndf). Если не указано, по умолчанию используется класс хранилища для контроллера данных.
--storage-class-logs, -g Класс хранилища для всех файлов журнала. Если не указано, по умолчанию используется класс хранилища для контроллера данных.
--storage-class-data-logs Класс хранилища для файлов журнала транзакций базы данных. Если не указано, по умолчанию используется класс хранилища для контроллера данных.
--storage-class-backups Класс хранилища для всех файлов резервного копирования. Если значение не указано, по умолчанию используется класс хранилища для данных (--storage-class-data).

Используйте класс хранилища ReadWriteMany (RWX) для резервных копий. Дополнительные сведения о режимах доступа.

Предупреждение

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

В следующей таблице перечислены пути в контейнере "Управляемый экземпляр Azure SQL", которые сопоставлены с постоянным томом для данных и журналов:

Название параметра, краткое название Путь внутри mssql-miaa контейнера Description
--storage-class-data, -d /var/opt Содержит каталоги для установки MSSQL и других системных процессов. Каталог MSSQL содержит каталоги данных по умолчанию (включая журналы транзакций), журналов ошибок и резервных копий
--storage-class-logs, -g /var/log Содержит каталоги, в которых хранятся выходные данные консоли (stderr, stdout), а также другие сведения из журнала процессов в контейнере

В следующей таблице перечислены пути в контейнере экземпляра PostgreSQL, сопоставляемые с постоянным томом для данных и журналов:

Название параметра, краткое название Путь в контейнере Postgres Description
--storage-class-data, -d /var/opt/postgresql Содержит каталоги данных и журналов для установки Postgres
--storage-class-logs, -g /var/log Содержит каталоги, в которых хранятся выходные данные консоли (stderr, stdout), а также другие сведения из журнала процессов в контейнере

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

Если в данном экземпляре базы данных несколько баз данных, все базы данных используют одно и то же утверждение постоянного тома, постоянный том и класс хранилища. Все резервные копии — разностные резервные копии журналов и полные резервные копии используют одинаковые утверждения постоянного тома и постоянный том. Ниже приведены заявки на постоянные тома для модулей pod экземпляра базы данных.

Экземпляр Заявки на постоянные тома
Управляемый экземпляр SQL Azure <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0
Экземпляр Базы данных Azure PostgreSQL <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0
Azure PostgreSQL <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0

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

  • Начиная с выпуска служб данных Azure Arc за февраль 2022 г. необходимо указать класс хранилища ReadWriteMany (RWX) для резервного копирования . Дополнительные сведения о режимах доступа. Если для резервного копирования не указан класс хранения, используется класс хранилища по умолчанию в kubernetes, и если это не поддерживает RWX, развертывание управляемого экземпляра SQL Azure может завершиться ошибкой.
  • Развертывание экземпляров базы данных может выполняться либо по шаблону с одним модулем pod, либо по шаблону с несколькими модулями pod. Примером шаблона с одним pod является ценовая категория "Общего назначения" для управляемого экземпляра Azure SQL. Примером шаблона с несколькими pod является ценовая категория с высоким уровнем доступности "Критически важный для бизнеса" управляемых экземпляров Azure SQL. Для экземпляров баз данных, развернутых с одним pod, необходимо использовать удаленный общий класс хранения, чтобы обеспечить устойчивость данных. Таким образом, если pod или узел выйдет из строя, то после восстановления pod сможет снова подключиться к постоянному тому. В отличие от них в высокодоступном управляемом экземпляре SQL Azure для синхронной или асинхронной репликации данных из одного экземпляра в другой применяются группы доступности AlwaysOn. В частности, если данные реплицируются синхронно, всегда существует несколько копий данных. Обычно таких копий три. По этой причине для файлов данных и журналов можно использовать классы локальных хранилищ или удаленных общих хранилищ. При использовании локального хранилища данные сохраняются даже в случае сбоя pod, узла или оборудования хранилища, так как существует несколько копий данных. Учитывая эту гибкость, вы можете использовать локальное хранилище в целях повышения производительности.
  • Производительность базы данных во многом определяется пропускной способностью системы ввода-вывода в определенном запоминающем устройстве. Если в базе данных выполняется много операций чтения или записи, то следует выбирать класс хранения исходя из наличия оборудования, предназначенного для такого типа рабочей нагрузки. Например, если база данных в основном служит для операций записи, вы можете выбрать локальное хранилище с RAID 0. Если же ваша база данных в основном используется для операций чтения небольшого объема "горячих данных", но объем реже используемых данных велик, можно выбрать устройство для сети хранения данных, способное выступать в роли многоуровневого хранилища. Выбор подходящего класса хранения не отличается от выбора типа хранилища, используемого для любой базы данных.
  • Если вы используете локальный средство подготовки томов хранилища, убедитесь, что локальные тома, подготовленные для данных, журналов и резервных копий, находятся на разных базовых устройствах хранения, чтобы избежать конфликтов на дисках ввода-вывода. Операционная система также должна находиться на томе, подключенном к отдельному диску или отдельным дискам. По сути, эти рекомендации не отличаются от рекомендаций в случае размещения экземпляра базы данных на физическом оборудовании.
  • Поскольку у всех баз данных в этом экземпляре одинаковые заявка на постоянный том и постоянный том, не следует размещать экземпляры занятых баз данных в одном и том же экземпляре базы данных. По возможности разделяйте занятые базы данных, создавая отдельные экземпляры базы данных, во избежание состязания при выполнении операций ввода-вывода. Кроме того, используйте назначение метки узла для размещения экземпляров баз данных на отдельных узлах, чтобы распределить общий трафик операций ввода-вывода между несколькими узлами. Если вы используете виртуализацию, обязательно рассмотрите возможность распределения трафика ввода-вывода не только на уровне узла, но и объединенного действия ввода-вывода, происходящих всеми виртуальными машинами узла на определенном физическом узле.

Оценка требований к хранилищу

Каждый pod, содержащий данные с отслеживанием состояния, использует как минимум два постоянных тома: один постоянный том предназначен для данных, а другой — для журналов. В следующей таблице указано количество постоянных томов, необходимых для одного контроллера данных, управляемого экземпляра SQL Azure, экземпляра Базы данных Azure для PostgreSQL и экземпляра Гипермасштабирования для Azure PostgreSQL:

Тип ресурса Число модулей pod с отслеживанием состояния Требуемое количество постоянных томов
Контроллер данных 4 (control, controldb, logsdb, metricsdb) 4 x 2 = 8
Управляемый экземпляр SQL Azure 1 2
Azure PostgreSQL 1 2

В таблице ниже показано общее количество постоянных томов, необходимых для примера развертывания:

Тип ресурса Количество экземпляров Требуемое количество постоянных томов
Контроллер данных 1 4 x 2 = 8
Управляемый экземпляр SQL Azure 5 5 x 2 = 10
Azure PostgreSQL 5 5 x 2 = 10
Общее число постоянных томов 8 + 10 + 10 = 28

Это вычисление можно использовать при планировании хранилища для кластера Kubernetes с учетом средства подготовки хранилища или среды. Например, если для кластера Kubernetes с пятью (5) узлами используется средство подготовки локального хранилища, то в случае указанного выше примера развертывания для каждого узла требуется, по крайней мере, хранилище с 10 постоянными томами. При подготовке к работе кластера Azure Kubernetes Service (AKS) с пятью (5) узлами крайне важно выбрать адекватный размер виртуальной машины для пула узлов. Например, можно указать, что разрешено подключать 10 дисков данных. Дополнительные сведения о том, как выбрать размер узлов для хранения узлов AKS, приведены здесь.

Выбор правильного класса хранения

Локальные и пограничные сайты

Корпорация Майкрософт и ее OEM-партнеры и партнеры в сфере операционных систем и Kubernetes применяют программу проверки для служб данных Azure Arc. Эта программа предоставляет сопоставимые результаты тестирования из набора средств для сертификации. Тесты оценивают совместимость функций, результаты стресс-тестирования и производительность и масштабируемость. Результаты теста указывают используемую ОС, используемое распределение Kubernetes, используемое HW, используемое надстройку CSI и используемые классы хранения. Это помогает клиентам выбирать лучший класс хранения, дистрибутив ОС, Kubernetes и оборудование для своих требований. Дополнительные сведения об этой программе и результатах тестирования можно найти здесь.

Общедоступное облако, службы управляемой среды Kubernetes

Если речь идет о службах управляемой среды Kubernetes в общедоступном облаке, мы можем порекомендовать следующее:

Общедоступная облачная служба Рекомендация
Служба Azure Kubernetes (AKS) Для службы Azure Kubernetes (AKS) есть два типа хранилища: Файлы Azure и Управляемые диски Azure. Каждому типу хранилища соответствуют две ценовые категории и два уровня производительности — "Стандартный" (жесткий диск) и "Премиум" (диск SSD). Таким образом, в AKS предоставляются четыре класса хранения: azurefile (уровень "Стандартный" Файлов Azure), azurefile-premium (уровень "Премиум" Файлов Azure), default (уровень "Стандартный" Дисков Azure) и managed-premium (уровень "Премиум" Дисков Azure). Класс хранения по умолчанию — default (уровень "Стандартный" Дисков Azure). Существуют существенные различия в ценах между типами и уровнями, которые следует учитывать. Когда у рабочих нагрузок высокие требования к производительности, рекомендуется использовать managed-premium для всех классов хранения. Что касается рабочих нагрузок при разработке, тестировании, подтверждении концепции и т. д., когда важна стоимость, azurefile — наименее дорогостоящий вариант. Все четыре варианта можно использовать в ситуациях, когда требуется удаленное общее хранилище, так как все эти запоминающие устройства являются сетевыми в Azure. Дополнительные сведения см. в разделе о хранилище AKS.
Служба AWS Elastic Kubernetes (EKS) Служба Elastic Kubernetes Service в Amazon имеет один основной класс хранения на основе драйвера хранилища EBS CSI. Мы не рекомендуем использовать ее при работе с производственными рабочими нагрузками. Существует новый драйвер хранилища, а именно драйвер хранилища EFS CSI, который можно добавить в кластер EKS. Однако сейчас он находится на стадии бета-версии, и в него могут быть внесены изменения. Хотя разработчики AWS и утверждают, что этот драйвер хранилища поддерживается рабочей средой, мы не рекомендуем использовать его, так как пока это бета-версия, которая может измениться. Класс хранения EBS используется по умолчанию и называется gp2. Дополнительные сведения см. в разделе о хранилище EKS.
Google Kubernetes Engine (GKE) Google Kubernetes Engine (GKE) имеет только один класс хранения.standard Этот класс используется для постоянных дисков GCE. Он не только единственный, но и используется по умолчанию. Несмотря на то, что для GKE существует средство подготовки локальных статических томов, которое можно использовать в случае непосредственно подключаемых дисков SSD, мы не рекомендуем использовать его, так как для него не предоставляется поддержка и он не поддерживается Google. Дополнительные сведения см. в разделе о хранилище GKE.