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

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

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

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

Kubernetes позволяет поставщикам инфраструктуры хранилища подключать драйверы (также называемые Addons), расширяющие Kubernetes. Надстройки хранилища должны соответствовать стандарту интерфейса хранилища контейнеров. Есть десятки надстроек, которые можно найти в этом не окончательном списке драйверов 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>

Example:

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

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

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

Как правило, существует два типа хранилища:

  • Локальное хранилище — хранилище , подготовленное на локальных жестких дисках на определенном узле. Такой тип хранилища может быть идеальным с точки зрения производительности, но требует специального проектирования для избыточности данных путем репликации данных на нескольких узлах.
  • Удаленное, общее хранилище — это хранилище, подготовленное на удаленном устройстве хранилища, например SAN, 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 контроллера данных:

Service Запросы постоянных томов
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 контроллера, базу данных метрик и базу данных журналов, как правило, имеют достаточно низкий объем и не критически зависимы от задержек, поэтому использование высокопроизводительного хранилища не является необходимым. Если у вас есть пользователи, которые часто используют интерфейс журналов, и у вас большое количество экземпляров базы данных, тогда пользователи могут воспользоваться более быстрыми параметрами хранения.
  • Емкость хранилища является переменной с количеством развернутых экземпляров базы данных, так как журналы и метрики собираются для каждого экземпляра базы данных. Данные хранятся в журналах и метриках базы данных за две (2) недели до очистки.
  • Изменение класса хранилища после развертывания сложно, не документировано и не поддерживается. Не забудьте правильно выбрать класс хранилища во время развертывания.

Note

Если класс хранилища не указан, используется класс хранилища по умолчанию. Для каждого кластера 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) для резервных копий. Дополнительные сведения о режимах доступа.

Warning

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

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

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

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

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

Instance Запросы постоянных томов
Управляемый экземпляр Azure SQL <namespace>/logs-<instance name>-0, <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. Если база данных в основном используется для чтения небольшого количества "горячих данных", но существует большой общий объем холодных данных, то можно выбрать устройство SAN, способное поддерживать многоуровневое хранилище. Выбор правильного класса хранилища не отличается от выбора типа хранилища, используемого для любой базы данных.
  • Если вы используете локальный провиженер объемов хранилища, убедитесь, что локальные тома, подготовленные для данных, журналов и резервных копий, находятся на разных базовых устройствах хранения, чтобы избежать конкуренции на дисках ввода-вывода. ОС также должна находиться на томе, подключенном к отдельному диску(ам). Это, по сути, те же рекомендации, что и для экземпляра базы данных на физическом оборудовании.
  • Поскольку все базы данных на данном экземпляре совместно используют запрос на постоянный объем и постоянный объем, убедитесь, что занятые экземпляры базы данных не размещаются в одном экземпляре. Если это возможно, разделите занятые базы данных на собственные экземпляры базы данных, чтобы избежать конфликтов ввода-вывода. Кроме того, используйте метки узла для целевой установки экземпляров базы данных на отдельные узлы, чтобы распределить общий трафик операций ввода-вывода по нескольким узлам. Если вы используете виртуализацию, обязательно рассмотрите возможность распределения трафика ввода-вывода не только на уровне узла, но и объединенного действия ввода-вывода, происходящих всеми виртуальными машинами узла на определенном физическом узле.

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

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

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

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

Тип ресурса Количество случаев Требуемое количество постоянных томов
Контроллер данных 1 4 * 2 = 8
Azure SQL Managed Instance 5 5 * 2 = 10
Общее количество постоянных томов 8 + 10 + 10 = 28

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

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

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

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

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

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

Общедоступная облачная служба Recommendation
Служба Azure Kubernetes (AKS) Служба Azure Kubernetes (AKS) имеет два типа хранилища — файлы Azure и управляемые диски Azure. Каждый тип хранилища имеет два ценовых и производственных уровня — стандартный (HDD) и премиум (SSD). Таким образом, четыре класса хранилища, предоставляемые в AKS: azurefile (стандартный уровень Azure Files), azurefile-premium (премиум уровень Azure Files), default (стандартный уровень Azure Disks) и managed-premium (премиум уровень Azure Disks). Класс хранения по умолчанию — default (стандартный уровень Azure Disks). Существуют существенные различия в ценах между типами и уровнями, которые следует учитывать. Для рабочих нагрузок с высокими требованиями к производительности рекомендуется использовать managed-premium для всех классов хранилища. Для рабочих нагрузок, связанных с разработкой и тестированием, доказательства концепции и т. д., где важным является учет затрат, azurefile является наименее дорогим вариантом. Все четыре варианта можно использовать для ситуаций, требующих удаленного общего хранилища, так как они являются всеми подключенными к сети устройствами хранения в Azure. Дополнительные сведения о хранилище AKS.
Служба AWS Elastic Kubernetes (EKS) Служба Elastic Kubernetes Amazon имеет один основной класс хранилища на основе драйвера хранилища EBS CSI. Это рекомендуется для продуктивных рабочих нагрузок. Существует новый драйвер хранилища — драйвер хранилища EFS CSI , который можно добавить в кластер EKS, но в настоящее время он находится на бета-стадии и подлежит изменению. Хотя AWS говорит, что этот драйвер хранилища поддерживается для рабочей среды, мы не рекомендуем использовать его, так как он по-прежнему находится в бета-версии и подлежит изменению. Класс хранилища EBS — это класс хранилища по умолчанию и называется gp2. Дополнительные сведения о хранилище EKS.
Google Kubernetes Engine (GKE) Google Kubernetes Engine (GKE) имеет только один класс хранения.standard Этот класс используется для постоянных дисков GCE. Будучи единственным, он также является значением по умолчанию. Хотя существует локальный статический провиженер томов для GKE, который можно использовать с прямо подключаемыми SSD, мы не рекомендуем его использовать, так как он не обслуживается и не поддерживается Google. Дополнительные сведения о хранилище GKE.
  • Last updated on