オンプレミスの OpenShift および Azure Red Hat OpenShift に SQL Server ビッグ データ クラスターをデプロイする

適用対象: はいSQL Server 2019 (15.x)

この記事では、オンプレミスまたは Azure Red Hat OpenShift (ARO) 上の OpenShift 環境に SQL Server ビッグ データ クラスターをデプロイする方法について説明します。

ヒント

ARO を使用してサンプル環境をブートストラップし、このプラットフォームに BDC を簡単にデプロイするには、こちらで入手できる Python スクリプトを使用できます。

オンプレミスの OpenShift または Azure Red Hat OpenShift (ARO) に、ビッグ データ クラスターをデプロイできます。 SQL Server ビッグ データ クラスター リリース ノートのテスト済み構成と比較して、OpenShifts CRI-O のバージョンを検証します。 デプロイのワークフローは、他の Kubernetes ベースのプラットフォーム (kubeadmAKS) でのデプロイに似ていますが、いくつかの違いがあります。 この違いは主に、アプリケーションをルート以外のユーザーとして実行することと、名前空間 BDC のデプロイに使用されるセキュリティ コンテキストに関連するものです。

オンプレミスに OpenShift クラスターをデプロイする場合は、Red Hat OpenShift のドキュメントを参照してください。 ARO のデプロイについては、「Azure Red Hat OpenShift」を参照してください。

この記事では、OpenShift プラットフォームに固有のデプロイ手順について説明し、ターゲット環境にアクセスするためのオプションと、ビッグ データ クラスターのデプロイに使用する名前空間を示します。

前提条件

重要

以下の前提条件は、これらのクラスター レベル オブジェクトを作成するための十分なアクセス許可を持つ OpenShift クラスター管理者 (クラスター管理者クラスター ロール) によって実行される必要があります。 OpenShift でのクラスター ロールの詳細については、「Using RBAC to define and apply permissions」 (アクセス許可を定義して適用するための RBAC の使用) を参照してください。

  1. 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) によってもオーバーヘッドが加わるので、推定値にバッファーを追加します。

  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. SCC をクラスターに適用します。

    oc apply -f bdc-scc.yaml
    

    注意

    BDC に対するカスタム SCC は、OpenShift に組み込まれた "nonroot" SCC と追加のアクセス許可に基づきます。 OpenShift でのセキュリティ コンテキスト制約の詳細については、「Managing Security Context Constraints」 (セキュリティ コンテキスト制約の管理) を参照してください。 "nonroot" SCC に追加する、ビッグ データ クラスターに必要なアクセス許可の詳細については、こちらのホワイトペーパーをダウンロードしてください。

  4. 名前空間とプロジェクトを作成します。

    oc new-project <namespaceName>
    
  5. カスタム 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:mssql-bdc
    
  6. BDC をデプロイするユーザーに、適切なアクセス許可を割り当てます。 次のいずれかの操作を行います。

    • BDC をデプロイするユーザーがクラスター管理者ロールを持っている場合は、「ビッグ データ クラスターをデプロイする」に進んでください。

    • BDC をデプロイするユーザーが名前空間管理者である場合は、作成される名前空間に対するクラスター管理者ローカル ロールをユーザーに割り当てます。 これは、ビッグ データ クラスターのデプロイと管理を行うユーザーが名前空間レベルの管理アクセス許可を持つ場合に推奨されるオプションです。

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

    ビッグ データ クラスターをデプロイするユーザーは、OpenShift コンソールにログインする必要があります。

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

ビッグ データ クラスターをデプロイする

  1. 最新の azdata をインストールします。

  2. ターゲット環境 (オンプレミスの OpenShift または ARO) とデプロイ シナリオに応じて、OpenShift 用の組み込み構成ファイルの 1 つを複製します。 組み込みの構成ファイルで OpenShift に固有の設定については、後の「デプロイ構成ファイルでの OpenShift 固有の設定」セクションを参照してください。 使用可能な構成ファイルの詳細については、展開のガイダンスに関するページを参照してください。

    使用可能なすべての組み込み構成ファイルの一覧を表示します。

    azdata bdc config list
    

    組み込み構成ファイルの 1 つを複製するには、次のコマンドを実行します (必要に応じて、対象のプラットフォームまたはシナリオに基づいてプロファイルを置き換えることができます)。

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

    ARO へのデプロイの場合は、aro- プロファイルのいずれかを使用して開始します。それには、この環境に適した serviceTypestorageClass の既定値が含まれます。 次に例を示します。

    azdata bdc config init --source aro-dev-test --target custom-openshift
    
  3. 構成ファイル control.json と bdc.json をカスタマイズします。 さまざまなユース ケースのためのカスタマイズに関するガイドについては、次の追加リソースを参照してください。

    注意

    BDC 向け Azure Active Directory との統合はサポートされていないため、ARO にデプロイするときはこの認証方法を使用できません。

  4. 環境変数を設定します

  5. ビッグ データ クラスターをデプロイします

    azdata bdc create --config custom-openshift --accept-eula yes
    
  6. デプロイが正常に完了したら、ログインして外部のクラスター エンドポイントの一覧を表示することができます。

       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-testaro-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

次のステップ

チュートリアル:SQL Server ビッグ データ クラスターにサンプル データを読み込む