Сохраняемость данных в Kubernetes с кластерами больших данных SQL Server

Область применения: SQL Server 2019 (15.x)

Постоянные тома предоставляют модель плагина для хранения в Kubernetes. В этой модели способ предоставления хранилища абстрагируется от способа его использования. Таким образом, вы можете перенести собственное высокодоступное хранилище и подключить его к кластеру больших данных SQL Server. Хотя Kubernetes поддерживает различные типы решений для хранения, включая диски и файлы Azure, сетевую файловую систему (NFS) и локальное хранилище, кластеры больших данных поддерживаются только в проверенных конфигурациях. Дополнительные сведения о поддерживаемых конфигурациях см. в заметках о выпуске платформы кластеров больших данных SQL Server 2019.

Настройка постоянных томов

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

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

• Для успешного развёртывания кластера с большими данными убедитесь, что у вас есть достаточное количество доступных постоянных томов. Если вы развертываете в кластере Службы Azure Kubernetes (AKS) и используете встроенный класс хранилища (default или managed-premium), этот класс поддерживает динамическую подготовку постоянных томов. Поэтому вам не нужно предварительно создавать постоянные тома, но необходимо убедиться, что доступные рабочие узлы в кластере AKS могут присоединять столько дисков, сколько постоянных томов, необходимых для развертывания. В зависимости от размера виртуальной машины , указанного для рабочих узлов, каждый узел может подключить определенное количество дисков. Для кластера размера по умолчанию (без высокой доступности) требуется не менее 24 дисков. Если вы включаете высокий уровень доступности или масштабируете любой пул, убедитесь, что у вас есть по крайней мере два сохраняемых тома на каждую дополнительную реплику независимо от ресурса, который вы масштабируете.

• Если средство подготовки хранилища для класса хранилища, которое вы предоставляете в конфигурации, не поддерживает динамическую подготовку, необходимо предварительно создать сохраненные тома. Например, local-storage поставщик ресурсов не поддерживает динамическое предоставление. См. этот пример сценария для руководства, как действовать в кластере Kubernetes, развернутом с kubeadm.

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

• При вычислении требований к размеру пула носителей необходимо учитывать коэффициент репликации, с помощью который настроен HDFS. Коэффициент репликации можно настроить во время развертывания в файле конфигурации развертывания кластера. Значение по умолчанию для профилей dev-test (т. е. aks-dev-test или kubeadm-dev-test) равно 2, а для профилей, которые мы рекомендуем для рабочих развертываний (т. kubeadm-prodе. ) значение по умолчанию равно 3. Рекомендуется настроить рабочее развертывание кластера больших данных с коэффициентом репликации для HDFS не менее 3. Значение коэффициента репликации влияет на количество экземпляров в пуле носителей: как минимум, необходимо развернуть по крайней мере столько экземпляров пула носителей, сколько значение коэффициента репликации. Кроме того, необходимо соответствующим образом задать размер хранилища и учитывать, что данные реплицируются в HDFS столько раз, сколько указано в коэффициенте репликации. Дополнительные сведения о репликации данных в HDFS см. здесь.

• На момент выпуска SQL Server 2019 CU1, BDC не позволяет обновлять параметры настройки хранилища после развертывания. Это ограничение предотвращает использование операций BDC для изменения размера утверждения постоянного тома для каждого экземпляра или масштабирования любого пула после развертывания. Поэтому очень важно спланировать макет хранилища перед развертыванием кластера больших данных. Однако вы можете увеличить размер постоянного тома напрямую с помощью API Kubernetes. В этом случае метаданные BDC не будут обновлены, и вы увидите несоответствия размеров томов в метаданных конфигурационного кластера.

• Развертывая приложения в контейнерах на Kubernetes и используя такие функции, как StatefulSets и постоянное хранилище, Kubernetes гарантирует перезапуск pod в случае проблем со работоспособностью и их подключение к тому же постоянному хранилищу. Но в случае сбоя узла, и модуль pod должен быть перезапущен на другом узле, существует повышенный риск недоступности, если хранилище является локальным для неисправного узла. Чтобы снизить этот риск, необходимо настроить дополнительную избыточность и включить функции высокой доступности или использовать удаленное избыточное хранилище. Ниже приведен обзор вариантов хранения различных компонентов в кластерах больших данных:

Настройка параметров хранилища кластера больших данных

Как и в других настройках, можно указать параметры хранилища в файлах конфигурации кластера во время развертывания для каждого пула в bdc.json файле конфигурации и для служб управления в control.json файле. Если в спецификациях пула нет параметров конфигурации хранилища, параметры хранилища элементов управления будут использоваться для всех остальных компонентов, включая ресурс SQL Server master (master), ресурс HDFS (storage-0) и компоненты пула данных. Следующий пример кода представляет раздел конфигурации хранилища, который можно включить в спецификацию:

    "storage": 
    {
      "data": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
    }

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

В разделе "Настройка хранилища" приведены дополнительные примеры настройки параметров хранилища для развертывания кластера больших данных SQL Server.

Классы хранения AKS

AKS поставляется с двумя встроенными классами хранения, default и managed-premium динамическим провиженером для них. Можно указать любой из них или создать собственный класс хранилища для развертывания кластера больших данных с включенным постоянным хранилищем. По умолчанию встроенный файл конфигурации кластера для AKS aks-dev-test изначально поставляется с конфигурациями постоянного default хранилища для использования класса хранилища.

Классы хранилища для kubeadm кластеров

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

Настройка конфигураций хранилища для каждого пула

Для всех настроек необходимо сначала создать копию встроенного файла конфигурации, который вы хотите использовать. Например, следующая команда создает копию aks-dev-test файлов конфигурации развертывания в подкаталоге с именем custom:

azdata bdc config init --source aks-dev-test --target custom

Этот процесс создает два файла, bdc.json и control.json, которые вы можете настроить вручную или с помощью команды azdata bdc config. Вы можете использовать сочетание библиотек jsonpath и jsonpatch для предоставления способов редактирования файлов конфигурации.

Настройка имени класса хранилища и (или) размера утверждений

По умолчанию размер запросов на постоянные тома, запрошенные для каждого из pods в кластере, составляет 10 гигабайт (ГБ). Вы можете изменить это значение, чтобы учесть рабочие нагрузки в вашем пользовательском файле конфигурации перед развертыванием кластера.

В следующем примере размер запросов на выделение постоянного тома обновляется до 32 ГБ в control.json. Если он не переопределен на уровне пула, этот параметр будет применен ко всем пулам.

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.size=100Gi"

В следующем примере показано, как изменить класс хранилища для control.json файла:

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.className=<yourStorageClassName>"

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

{
  "patch": [
    {
      "op": "replace",
      "path": "$.spec.resources.storage-0.spec",
      "value": {
        "type":"Storage",
        "replicas":2,
        "storage":{
            "data":{
                    "size": "100Gi",
                    "className": "myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    },
            "logs":{
                    "size":"32Gi",
                    "className":"myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    }
                }
            }
        }
    ]
}

Примените файл исправлений. azdata bdc config patch Используйте команду, чтобы применить изменения в файле исправлений .json. В следующем примере файл patch.json применяется к целевому файлу конфигурации развертывания custom.json.

azdata bdc config patch --config-file custom/bdc.json --patch-file ./patch.json

Next steps

• Чтобы получить полную документацию о томах в Kubernetes, см. раздел документации Kubernetes о томах.

• Дополнительные сведения о развертывании кластера больших данных SQL Server см. в статье "Развертывание кластера больших данных SQL Server в Kubernetes".