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

  • Статья

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

Важно!

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, и программное обеспечение будет продолжать поддерживаться с помощью накопительных обновлений SQL Server до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

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

Важно!

Если вы развертываете в Azure кластер больших данных с использованием одной из управляемых служб Kubernetes (AKS или АRО), помните, что в зависимости от требований к рабочим нагрузкам ваших приложений может потребоваться учесть ряд ограничений. Например, тома, использующие управляемые диски Azure, сейчас не являются ресурсами, избыточными между зонами. Подключение томов между различными зонами невозможно. Они должны размещаться в той же зоне, что и узел, на котором размещен целевой объект pod. В этом конкретном случае стоит рассмотреть возможность использования дополнительных решений с высоким уровнем доступности, предлагаемых с Кластерами больших данных SQL Server. См. дополнительные сведения о службе Azure Kubernetes и зонах доступности.

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

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

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

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

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

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

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

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

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

Ресурсы Тип хранилища для данных Тип хранилища для журнала Примечания.
главный экземпляр SQL Server; Локальное (не менее 3 реплик) или удаленное хранилище с резервированием (1 реплика) Локальное хранилище Реализация на основе набора с отслеживанием состояния, в которой объекты pod связаны с узлами, защитит от потери данных при перезапусках и в случае временных сбоев.
Вычислительный пул Локальное хранилище Локальное хранилище Данные пользователей не хранятся.
Пул данных Локальное или удаленное хранилище с резервированием Локальное хранилище Используйте удаленное хранилище с резервированием, если не удается перестроить пул данных из других источников.
Пул носителей (HDFS) Локальное или удаленное хранилище с резервированием Локальное хранилище Убедитесь, что репликация включена.
Пул Spark Локальное хранилище Локальное хранилище Данные пользователей не хранятся.
Управление (controldb, metricsdb, logsdb) Удаленное хранилище с резервированием Локальное хранилище Очень важно использовать резервирование на уровне хранилища для метаданных кластера больших данных.

Важно!

Убедитесь, что связанные с управлением компоненты находятся в устройстве удаленного хранилища с резервированием. Объект pod controldb-0 содержит экземпляр SQL Server с базами данных, где хранятся все метаданные, связанные с состояниями службы кластеров, различными настройками и другой соответствующей информацией. Если экземпляр становится недоступным, это приведет к проблемам с работоспособностью других зависимых служб в кластере.

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

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

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

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

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

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

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

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

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

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

Постоянные тома, созданные с помощью встроенных классов хранения default и managed-premium, имеют политику освобождения Удаление. Поэтому при удалении кластера больших данных SQL Server утверждения постоянных томов удаляются, а затем удаляются и сами тома. Вы можете создавать пользовательские классы хранения с помощью средства подготовки azure-disk с политикой освобождения Retain, как показано в разделе Классы хранилищ.

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

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

Важно!

Во встроенных файлах конфигурации развертывания для kubeadm (kubeadm-dev-test и kubeadm-prod) не указано имя класса хранения для хранилища данных и журналов. Перед развертыванием необходимо настроить файл конфигурации и задать значение для className. В противном случае проверки перед развертыванием завершатся ошибкой. Во время развертывания также проверяется наличие класса хранения, но наличие требуемых постоянных томов не проверяется. Создайте достаточно томов в зависимости от размера кластера. Для минимального размера кластера по умолчанию (масштаб по умолчанию, без высокой доступности) необходимо создать не менее 24 постоянных томов. Пример того, как можно создавать постоянные тома с помощью локального средства подготовки, см. в статье о создании кластера Kubernetes с помощью Kubeadm.

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

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

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

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

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

По умолчанию размер утверждений постоянных томов, подготавливаемых для каждого объекта pod в кластере, составляет 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

Следующие шаги