適用於:SQL Server 2019 (15.x)
Important
MICROSOFT SQL Server 2019 巨量數據叢集已淘汰。 SQL Server 2019 巨量數據叢集的支援已於 2025 年 2 月 28 日結束。 如需詳細資訊,請參閱 Microsoft SQL Server 平臺上的公告部落格文章和巨量數據選項。
本文說明如何在 OpenShift 環境、內部部署或 Azure Red Hat OpenShift (ARO) 上部署 SQL Server 巨量數據叢集。
Tip
如需使用 ARO 啟動範例環境,然後在此平臺上部署 BDC 的快速方式,您可以使用 此處提供的 Python 腳本。
您可以將巨量數據叢集部署到內部部署 OpenShift 或 Azure Red Hat OpenShift (ARO)。 根據 SQL Server 巨量數據叢集版本資訊上測試的組態,驗證 OpenShifts CRI-O 版本。 雖然部署工作流程類似於在其他 Kubernetes 型平臺中部署 (kubeadm 和 AKS),但有一些差異。 差異主要在於以非 root 使用者身分執行應用程式,以及命名空間 BDC 所使用的安全性內容的部署。
若要在內部部署部署 OpenShift 叢集,請參閱 Red Hat OpenShift 檔。 如需 ARO 部署,請參閱 Azure Red Hat OpenShift。
本文概述 OpenShift 平臺特有的部署步驟,指出您用來存取目標環境和用來部署巨量數據叢集之命名空間的選項。
Pre-requisites
Important
下列必要條件必須由具有足夠許可權的 OpenShift 叢集管理員(cluster-admin 叢集角色)執行,才能建立這些叢集層級物件。 如需 OpenShift 中叢集角色的詳細資訊,請參閱 使用 RBAC 來定義和套用許可權。
pidsLimit請確定 OpenShift 上的設定已更新,以容納 SQL Server 工作負載。 OpenShift 中的預設值對於類似生產環境的工作負載而言過低。 至少從4096開始,但最佳值取決於max worker threadsSQL Server 中的設定,以及 OpenShift 主機節點上的 CPU 處理器數目。- 若要瞭解如何更新
pidsLimitOpenShift 叢集,請使用 這些指示。 請注意,之前的4.3.5OpenShift 版本有缺陷,導致更新的值不會生效。 請務必將 OpenShift 升級至最新版本。 - 為了協助您根據環境和規劃的 SQL Server 工作負載來計算最佳值,您可以使用下列估計和範例:
處理器數目 預設最大工作者執行緒 每個處理器的預設工作者 最小 pidsLimit 值 64 512 16 512 + (64 *16) = 1536 128 512 32 512 + (128*32) = 4608 Note
其他進程(例如備份、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將 SCC 套用至叢集。
oc apply -f bdc-scc.yamlNote
BDC 的自定義 SCC 是以 OpenShift 中的內建的
nonrootSCC 為基礎,並具備額外的許可權。 若要深入瞭解 OpenShift 中的安全性內容條件約束,請參閱 管理安全性內容條件約束。 如需詳細了解 SCC 上nonroot巨量數據叢集所需的額外權限,請在這裡 下載白皮書。建立命名空間/專案:
oc new-project <namespaceName>將自訂 SCC 系結至部署 BDC 之命名空間中的服務帳戶:
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>將適當的許可權指派給部署 BDC 的使用者。 執行以下動作之一。
如果部署 BDC 的使用者具有叢集管理員角色,請繼續 部署巨量數據叢集。
如果部署 BDC 的使用者是命名空間管理員,請為建立的命名空間指派使用者叢集管理員本機角色。 這是部署和管理巨量數據叢集以擁有命名空間層級系統管理員許可權的使用者慣用選項。
oc create rolebinding bdc-user-rbac --clusterrole=cluster-admin --user=<userName> -n <namespaceName>然後,部署巨量數據叢集的用戶必須登入 OpenShift 主控台:
oc login -u <deployingUser> -p <password>
部署巨量數據叢集
安裝最新的 azdata。
根據您的目標環境 (內部部署或 ARO) 和部署案例,複製 OpenShift 的其中一個內建組態檔。 如需內建組態檔中 OpenShift 專屬的設定,請參閱下方 部署組態檔一節中的 OpenShift 特定 設定。 如需可用組態檔的詳細資訊,請參閱 部署指引。
列出所有可用的內建組態檔。
azdata bdc config list若要複製其中一個內建組態檔,請執行下列命令(選擇性地,您可以根據目標平臺/案例來取代配置檔):
azdata bdc config init --source openshift-dev-test --target custom-openshift針對 ARO 上的部署,請從
aro-設定檔之一開始,其中包含適用於此環境的serviceType和storageClass的預設值。 For example:azdata bdc config init --source aro-dev-test --target custom-openshift自定義 control.json 和 bdc.json組態檔。 以下是一些額外的資源,引導您完成各種使用案例的自定義:
Note
不支援與 BDC 的 Microsoft Entra ID (先前稱為 Azure Active Directory) 整合,因此您無法在 ARO 上部署時使用此驗證方法。
設定 環境變數
部署巨量數據叢集
azdata bdc create --config custom-openshift --accept-eula yes成功部署后,您可以登入並列出外部叢集端點:
azdata login -n mssql-cluster azdata bdc endpoint list
部署組態檔中的 OpenShift 特定設定
SQL Server 2019 CU5 引進兩個功能開關來控制 Pod 和節點度量指標的集合。 這些參數預設會在 OpenShift 的內建配置檔中設定為 false ,因為監視容器需要 特殊許可權的安全性內容,這會放寬命名空間 BDC 的一些安全性限制。
"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