オンプレミスの OpenShift および Azure Red Hat OpenShift に SQL Server ビッグ データ クラスターをデプロイする
適用対象:
SQL Server 2019 (15.x)
重要
Microsoft SQL Server 2019 ビッグ データ クラスターのアドオンは廃止されます。 SQL Server 2019 ビッグ データ クラスターのサポートは、2025 年 2 月 28 日に終了します。 ソフトウェア アシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。 詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグ データ オプション」を参照してください。
この記事では、オンプレミスまたは Azure Red Hat OpenShift (ARO) 上の OpenShift 環境に SQL Server ビッグ データ クラスターをデプロイする方法について説明します。
ヒント
ARO を使用してサンプル環境をブートストラップし、このプラットフォームに BDC を簡単にデプロイするには、こちらで入手できる Python スクリプトを使用できます。
オンプレミスの OpenShift または Azure Red Hat OpenShift (ARO) に、ビッグ データ クラスターをデプロイできます。 SQL Server ビッグ データ クラスター リリース ノートのテスト済み構成と比較して、OpenShifts CRI-O のバージョンを検証します。 デプロイのワークフローは、他の Kubernetes ベースのプラットフォーム (kubeadm や AKS) でのデプロイに似ていますが、いくつかの違いがあります。 この違いは主に、アプリケーションをルート以外のユーザーとして実行することと、名前空間 BDC のデプロイに使用されるセキュリティ コンテキストに関連するものです。
オンプレミスに OpenShift クラスターをデプロイする場合は、Red Hat OpenShift のドキュメントを参照してください。 ARO のデプロイについては、「Azure Red Hat OpenShift」を参照してください。
この記事では、OpenShift プラットフォームに固有のデプロイ手順について説明し、ターゲット環境にアクセスするためのオプションと、ビッグ データ クラスターのデプロイに使用する名前空間を示します。
前提条件
重要
以下の前提条件は、これらのクラスター レベル オブジェクトを作成するための十分なアクセス許可を持つ OpenShift クラスター管理者 (クラスター管理者クラスター ロール) によって実行される必要があります。 OpenShift でのクラスター ロールの詳細については、「Using RBAC to define and apply permissions」 (アクセス許可を定義して適用するための RBAC の使用) を参照してください。
OpenShift の
pidsLimit設定が、SQL Server のワークロードに対応するように更新されていることを確認します。 OpenShift の既定値は、ワークロードのような運用環境には低すぎます。 少なくとも4096で開始しますが、最適な値は SQL Server でのmax worker threadsの設定と、OpenShift ホスト ノード上の CPU プロセッサの数によって決まります。- OpenShift クラスターに対する
pidsLimitを更新する方法については、こちらの手順を参照してください。4.3.5より前のバージョンの OpenShift には欠陥があり、更新した値が反映されないことに注意してください。 必ず、OpenShift を最新バージョンにアップグレードしてください。 - 環境および予定されている SQL Server ワークロードに応じた最適な値を計算するには、次の推定と例を使用できます。
プロセッサの数 既定の最大ワーカー スレッド数 既定のプロセッサあたりワーカー数 pidsLimit の最小値 64 512 16 512 + (64 *16) = 1536 128 512 32 512 + (128*32) = 4608 注意
他のプロセス (例: バックアップ、CLR、フルテキスト、SQLAgent) によってもオーバーヘッドが加わるので、推定値にバッファーを追加します。
- OpenShift クラスターに対する
カスタム セキュリティ コンテキスト制約 (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.yamlSCC をクラスターに適用します。
oc apply -f bdc-scc.yaml注意
BDC に対するカスタム SCC は、OpenShift に組み込まれた "
nonroot" SCC と追加のアクセス許可に基づきます。 OpenShift でのセキュリティ コンテキスト制約の詳細については、「Managing Security Context Constraints」 (セキュリティ コンテキスト制約の管理) を参照してください。 "nonroot" SCC に追加する、ビッグ データ クラスターに必要なアクセス許可の詳細については、こちらのホワイトペーパーをダウンロードしてください。名前空間とプロジェクトを作成します。
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 をインストールします。
ターゲット環境 (オンプレミスの OpenShift または ARO) とデプロイ シナリオに応じて、OpenShift 用の組み込み構成ファイルの 1 つを複製します。 組み込みの構成ファイルで OpenShift に固有の設定については、後の「デプロイ構成ファイルでの OpenShift 固有の設定」セクションを参照してください。 使用可能な構成ファイルの詳細については、展開のガイダンスに関するページを参照してください。
使用可能なすべての組み込み構成ファイルの一覧を表示します。
azdata bdc config list組み込み構成ファイルの 1 つを複製するには、次のコマンドを実行します (必要に応じて、対象のプラットフォームまたはシナリオに基づいてプロファイルを置き換えることができます)。
azdata bdc config init --source openshift-dev-test --target custom-openshiftARO へのデプロイの場合は、
aro-プロファイルのいずれかを使用して開始します。それには、この環境に適したserviceTypeとstorageClassの既定値が含まれます。 次に例を示します。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 では、ポッドとノードのメトリックのコレクションを制御する 2 つの機能スイッチが導入されました。 これらのパラメーターは、OpenShift 用の組み込みプロファイルでは既定で false に設定されています。これは、監視コンテナーでは特権付きセキュリティ コンテキストが必要であるためです。これにより、BDC がデプロイされる名前空間に対するセキュリティ制約の一部が緩和されます。
"security": {
"allowNodeMetricsCollection": false,
"allowPodMetricsCollection": false
}
ARO での既定のストレージ クラスの名前は managed-premium です (これに対し、AKS での既定のストレージ クラスの名前は default です)。 これは、aro-dev-test と aro-dev-test-ha に対応する control.json で確認できます。
},
"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
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示