Развертывание sql Server Кластеры больших данных в локальной среде OpenShift и Azure Red Hat OpenShift

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

Эта статья поясняет, как развернуть Кластер больших данных SQL Server в средах OpenShift, локально или в Azure Red Hat OpenShift (ARO).

Кластеры больших данных можно развернуть в локальной среде OpenShift или в Azure Red Hat OpenShift (ARO). Проверьте, что версия CRI-O OpenShift указана в списке проверенных конфигураций, приведенных в статье Заметки о выпуске Кластеров больших данных SQL Server 2019. Хотя рабочий процесс развертывания аналогичен развертыванию в других платформах на основе Kubernetes (kubeadm и AKS), имеются некоторые различия. Разница в основном связана с запуском приложений в качестве непривилегированного пользователя и контекстом безопасности, используемым для пространства имен, в котором развертывается кластер больших данных.

Сведения о развертывании кластера OpenShift в локальной среде см. в документации по Red Hat OpenShift. Для развертываний ARO см. Azure Red Hat OpenShift.

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

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

1. Убедитесь, что pidsLimit параметр OpenShift обновлен для размещения рабочих нагрузок SQL Server. Значение по умолчанию в OpenShift слишком мало для нагрузок, характерных для рабочей среды. Укажите по меньшей мере значение 4096, но оптимальное значение будет зависеть от параметра max worker threads в SQL Server и числа ЦП на узле OpenShift.

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

   Количество процессоров	Максимальное число рабочих потоков по умолчанию	Число рабочих процессов на процессор по умолчанию	Минимальное значение pidsLimit
   64	512	16	512 + (64 *16) = 1536
   128	512	32	512 + (128*32) = 4608

   Примечание.

   Другие процессы (например, резервное копирование, CLR, Fulltext, SQLAgent) также добавляют некоторые дополнительные служебные данные, поэтому добавляйте к предполагаемому значению некоторый запас.

2. Скачайте настраиваемое ограничение контекста безопасности (SCC) bdc-scc.yaml:

   curl https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/features/sql-big-data-cluster/deployment/openshift/bdc-scc.yaml -o bdc-scc.yaml
   

3. Примените его к кластеру.

   oc apply -f bdc-scc.yaml
   

   Примечание.

   Пользовательский SCC для BDC основан на встроенном nonroot SCC в OpenShift с дополнительными разрешениями. Дополнительные сведения об ограничениях контекста безопасности в OpenShift см. в разделе Управление ограничениями контекста безопасности. Подробные сведения о том, какие дополнительные разрешения необходимы для кластеров больших данных на вершине nonroot SCC, скачайте технический документ здесь.

4. Создайте пространство имен или проект:

   oc new-project <namespaceName>
   

5. Привяжите настраиваемое ограничение контекста безопасности к учетным записям службы в пространстве имен, где развернут кластер больших данных:

   oc create clusterrole bdc-role --verb=use --resource=scc --resource-name=bdc-scc -n <namespaceName>
   oc create rolebinding bdc-rbac --clusterrole=bdc-role --group=system:serviceaccounts:<namespaceName>
   

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

   • Если пользователь, развертывающий кластер больших данных, имеет роль администратора кластера, перейдите к развертыванию кластера больших данных.

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

   oc create rolebinding bdc-user-rbac --clusterrole=cluster-admin --user=<userName> -n <namespaceName>
   

   После этого пользователь, развертывающий кластер больших данных, должен войти в консоль OpenShift:

   oc login -u <deployingUser> -p <password>
   

Разверните кластер больших данных.

1. Установите последний azdata.

2. Клонируйте один из встроенных файлов конфигурации для OpenShift в зависимости от целевой среды (локальная среда OpenShift или АТО) и сценария развертывания. Параметры для OpenShift во встроенных файлах конфигурации описаны в подразделе Параметры для OpenShift в файлах конфигурации развертывания ниже. Дополнительные сведения о доступных файлах конфигурации см. в руководстве по развертыванию.

   Выведите список всех доступных встроенных файлов конфигурации.

   azdata bdc config list
   

   Чтобы клонировать один из встроенных файлов конфигурации, выполните приведенную ниже команду (при необходимости можно заменить профиль с учетом целевой платформы или сценария):

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

   Для развертывания в ARO начните с одного из профилей aro-, который включает значения по умолчанию для serviceType и storageClass, подходящие для этой среды. Например:

   azdata bdc config init --source aro-dev-test --target custom-openshift
   

3. Настройте файлы конфигурации control.json и bdc.json. Ниже приведены некоторые дополнительные ресурсы, которые помогут вам выполнить настройку для различных вариантов использования.

   • Память
   • Сопутствующие параметры AD
   • Другие настройки

   Примечание.

   Интеграция с идентификатором Microsoft Entra (ранее Azure Active Directory) для BDC не поддерживается, поэтому этот метод проверки подлинности нельзя использовать при развертывании в ARO.

4. Задайте переменные среды.

5. Разверните кластер больших данных.

   azdata bdc create --config custom-openshift --accept-eula yes
   

6. После успешного развертывания можно войти в систему и вывести список конечных точек внешнего кластера:

      azdata login -n mssql-cluster
      azdata bdc endpoint list
   

Параметры для OpenShift в файлах конфигурации развертывания

Накопительный пакет обновления 5 для SQL Server 2019 представляет два параметра для управления сбором метрик объектов pod и узлов. Для этих параметров по умолчанию во встроенных профилях для OpenShift задано значение false, так как контейнерам мониторинга требуется привилегированный контекст безопасности, что ослабляет некоторые ограничения безопасности для пространства имен, в котором развернут кластер больших данных.

    "security": {
      "allowNodeMetricsCollection": false,
      "allowPodMetricsCollection": false
}

Именем класса хранения по умолчанию в ARO является managed-premium (в отличие от AKS, где класс хранения по умолчанию называется default). Это можно найти в control.json, соответствующем aro-dev-test и aro-dev-test-ha:

    },
    "storage": {
      "data": {
        "className": "managed-premium",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "managed-premium",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
      }

Файл bdc-scc.yaml

Файл SCC для этого развертывания:

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities:
  - SETUID
  - SETGID
  - CHOWN
  - SYS_PTRACE
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: SQL Server BDC custom scc is based on 'nonroot' scc plus additional capabilities required by BDC.
  generation: 2
  name: bdc-scc
readOnlyRootFilesystem: false
requiredDropCapabilities:
  - KILL
  - MKNOD
runAsUser:
  type: MustRunAsNonRoot
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret

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

Руководство. Загрузка примеров данных в кластер больших данных SQL Server