Развертывание sql Server Кластеры больших данных в локальной среде OpenShift и Azure Red Hat OpenShift
Область применения:
SQL Server 2019 (15.x)
Важно!
Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, и программное обеспечение будет продолжать поддерживаться с помощью накопительных обновлений SQL Server до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.
Эта статья поясняет, как развернуть Кластер больших данных SQL Server в средах OpenShift, локально или в Azure Red Hat OpenShift (ARO).
Совет
Чтобы осуществить начальную загрузку образца среды с помощью ARO и затем развернуть кластер больших данных на этой платформе, можно использовать скрипт Python, доступный здесь.
Кластеры больших данных можно развернуть в локальной среде 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, указаны варианты доступа к целевой среде и пространство имен, которое используется для развертывания кластера больших данных.
Предварительные требования
Важно!
Указанные ниже предварительные требования должны быть выполнены администратором кластера OpenShift (роль кластера "Администратор кластера") с достаточными разрешениями для создания этих объектов на уровне кластера. Дополнительные сведения о ролях кластера в OpenShift см. в разделе Использование RBAC для определения и применения разрешений.
Убедитесь, что
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) также добавляют некоторые дополнительные служебные данные, поэтому добавляйте к предполагаемому значению некоторый запас.
- Чтобы узнать, как обновить
Скачайте настраиваемое ограничение контекста безопасности (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Примените его к кластеру.
oc apply -f bdc-scc.yamlПримечание.
Пользовательский SCC для BDC основан на встроенном
nonrootSCC в OpenShift с дополнительными разрешениями. Дополнительные сведения об ограничениях контекста безопасности в OpenShift см. в разделе Управление ограничениями контекста безопасности. Подробные сведения о том, какие дополнительные разрешения необходимы для кластеров больших данных на вершинеnonrootSCC, скачайте технический документ здесь.Создайте пространство имен или проект:
oc new-project <namespaceName>Привяжите настраиваемое ограничение контекста безопасности к учетным записям службы в пространстве имен, где развернут кластер больших данных:
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>Назначьте соответствующее разрешение для пользователя, развертывающего кластер больших данных. Выполните одно из следующих действий.
Если пользователь, развертывающий кластер больших данных, имеет роль администратора кластера, перейдите к развертыванию кластера больших данных.
Если пользователь, развертывающий кластер больших данных, является администратором пространства имен, назначьте ему локальную роль администратора кластера для созданного пространства имен. Это предпочтительный вариант, когда пользователь, развертывающий кластер больших данных и управляющий им, должен иметь разрешения администратора на уровне пространства имен.
oc create rolebinding bdc-user-rbac --clusterrole=cluster-admin --user=<userName> -n <namespaceName>После этого пользователь, развертывающий кластер больших данных, должен войти в консоль OpenShift:
oc login -u <deployingUser> -p <password>
Разверните кластер больших данных.
Установите последний azdata.
Клонируйте один из встроенных файлов конфигурации для 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Настройте файлы конфигурации control.json и bdc.json. Ниже приведены некоторые дополнительные ресурсы, которые помогут вам выполнить настройку для различных вариантов использования.
Примечание.
Интеграция с идентификатором Microsoft Entra (ранее Azure Active Directory) для BDC не поддерживается, поэтому этот метод проверки подлинности нельзя использовать при развертывании в ARO.
Задайте переменные среды.
Разверните кластер больших данных.
azdata bdc create --config custom-openshift --accept-eula yesПосле успешного развертывания можно войти в систему и вывести список конечных точек внешнего кластера:
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
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по