今回は SQL Server 2019 ビッグデータクラスター (BDC) を Azure Kubernetes Service (AKS) にインストールする方法についてみていきます。
前提条件
Windows 10 PC での手順です。Linux の場合は参照リンクから詳細を確認してください。
また今回は Azure Kubernetes Service は自分で構築して、そこに SQL Server 2019 BDC をインストールします。
事前準備
まずはインストールにも利用するクライアントツールをインストールします。
参照: SQL Server 2019 のビッグ データ ツールをインストールする
- python
- azdata
- Azure Data Studio と Data Virtualization 拡張
- Azure Kubernetes Service
※ Python スクリプトで AKS も同時にインストールする手順もあります。
参照:Python スクリプトを使用して SQL Server ビッグ データ クラスターを Azure Kubernetes Service (AKS) に展開する
python
今回想定しているバージョンは python 3 です。
1. Python が含まれる次のいずれかの圧縮ファイルをダウンロード。
Windows
https://go.microsoft.com/fwlink/?linkid=2074021
Linux
https://go.microsoft.com/fwlink/?linkid=2065975
OSX
https://go.microsoft.com/fwlink/?linkid=2065976
2. 圧縮されたファイルをターゲット コンピューターにコピーし、任意のフォルダーに展開。
3. フォルダーから installLocalPythonPackages.bat を実行して、パラメーターと同じフォルダーへの完全なパスを設定。
installLocalPythonPackages.bat "C:\python-3.6.6-win-x64-0.0.1-offline\0.0.1"
azdata
MSI が用意されています。azdata Windows インストーラー をダウンロードして実行してください。
Azure Data Studio と Data Virtualization 拡張
Azure Data Studio はクロスプラットフォームで動作する Azure データサービス用のクライアントツールです。
1. Windows 用の Azure Data Studio ユーザー インストーラーをダウンロードしてインストール。
2. インストール完了後 Azure Data Studio を起動。
3. 左ペインより Extensions アイコンをクリックして「Data Virtualization」を検索してインストール。
Azure Kubernetes Service
既存の AKS を使うこともできますが、ここでは新規に環境を作成します。
1. リソースグループを作成。
az group create --name sqlbdcrg --location japaneast
2. AKS を作成。ここではテストのため最小限の構成で作成。
- Linux OS の Standard_L8s を 1 台指定
az aks create -n sqlbdc -g sqlbdcrg --generate-ssh-key --node-vm-size Standard_L8s -c 1
3. 作成完了後、環境に接続。
az aks get-credentials -n sqlbdc -g sqlbdcrg
4. ノードを確認。
>kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-41170276-vmss000000 Ready agent 4m17s v1.13.12
SQL Server 2019 BDC のインストール
参照: Kubernetes 上に SQL Server ビッグ データ クラスターを展開する方法
azdata ツールでインストールを実行することができます。構成は json 形式で定義しますが、既定でテンプレートがいくつか用意されています。SQL Server 各種コンポーネントのコンテナイメージは mcr.microsoft.com にホストされており、構成ファイルがその情報をすでに持っているため、必要最小限の情報構成のみでインストールが開始できます。
AKS 用は既定で 2 つのパターンの構成ファイルが用意されています。
- aks-dev-test: 基本となる構成
- aks-dev-test-ha: 高可用性を含んだ構成
全ての構成は azdata bdc config list -o table で確認できます。
既定でのインストール
まずは既定でどのようなコンポーネントが、どうインストールされるかを見ていきます。
1. 管理者のユーザー名とパスワードを環境変数として設定。ドキュメントにある以下の内容に注意。
特殊文字が含まれている場合は、必ずパスワードを二重引用符で囲みます。 AZDATA_PASSWORD は自由に設定できますが、必ずパスワードを十分に複雑にして、!、&、' 文字は使用しないでください。 二重引用符の区切り記号は bash コマンドでしか機能しないことに注意してください。
SET AZDATA_USERNAME=admin
SET AZDATA_PASSWORD=<password>
2. 既定の構成でインストールを実行。
azdata bdc create --config-profile aks-dev-test --accept-eula yes
3. 以下メッセージにもあるとおり、15-30 分くらい時間がかかるので、SQL Server 2019 BDC 展開の概要ビデオでも見て待つ。
NOTE: Cluster creation can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.
4. インストールが完了したメッセージを確認。
Starting cluster deployment.
Waiting for cluster controller to start.
Waiting for cluster controller to start.
Waiting for cluster controller to start.
Waiting for cluster controller to start.
Waiting for cluster controller to start.
Waiting for cluster controller to start.
Waiting for cluster controller to start.
Cluster controller endpoint is available at xxx.xxx.xxx.xxx:30080.
Waiting for control plane to be ready after 5 minutes.
Cluster control plane is ready.
Data pool is ready.
Storage pool is ready.
Master pool is ready.
Compute pool is ready.
Cluster deployed successfully.
インストール構成ファイルの確認
既定の構成ファイルは以下の手順で確認可能です。
1. 以下コマンドで aks-dev-test を custom としてコピー。
azdata bdc config init --source aks-dev-test --target custom
2. 生成された custom フォルダを開く。
start custom
3. Visual Studio Code などでファイルを確認。
インストールされたコンポーネントの確認
既定で SQL Server 2019 BDC は control.json に指定されている mssql-cluster 名前空間にインストールされます。よって kubectl でコンポーネントを表示する場合は -n mssql-cluster を使うか、既定の名前空間を変えたものを用意します。ここでは既定の名前空間を変えておきます。
1. sqlbdc 設定を確認。
>kubectl config get-contexts sqlbdc
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* sqlbdc sqlbdc clusterUser_sqlbdcrg_sqlbdc
2. 新しく名前空間を指定してコンテキストを作成。
kubectl config set-context mssql-cluster --namespace=mssql-cluster --cluster=sqlbdc --user=clusterUser_sqlbdcrg_sqlbdc
3. コンテキストを切り替え。
kubectl config use-context mssql-cluster
ポッドを確認
ポッドの一覧を確認すると、bdc.json で定義された内容と同一のポッドが確認可能。また controldb や metricsdb などコントローラー用のポッドも配置されていることが確認できます。
>kubectl get pods
NAME READY STATUS RESTARTS AGE
appproxy-j4qxz 2/2 Running 2 110m
compute-0-0 3/3 Running 3 110m
control-hnkt6 3/3 Running 3 125m
controldb-0 2/2 Running 2 125m
controlwd-4xg8d 1/1 Running 1 120m
data-0-0 3/3 Running 3 110m
data-0-1 3/3 Running 3 110m
gateway-0 2/2 Running 2 110m
logsdb-0 1/1 Running 1 120m
logsui-fs4x8 1/1 Running 1 120m
master-0 3/3 Running 3 110m
metricsdb-0 1/1 Running 1 120m
metricsdc-d9lwk 1/1 Running 1 120m
metricsui-9trpv 1/1 Running 1 120m
mgmtproxy-qw79h 2/2 Running 2 120m
nmnode-0-0 2/2 Running 2 110m
sparkhead-0 4/4 Running 4 110m
storage-0-0 4/4 Running 4 110m
storage-0-1 4/4 Running 4 110m
サービスを確認
サービスは環境に接続できるエンドポイントが作成されていることが確認可能です。
- control.json で定義された Controller と ServiceProxy、および BDC のエンドポイント
- BDC の各種コンポーネントの内部 ClusterIP
>kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
appproxy-svc ClusterIP None <none> 8080/TCP 141m
appproxy-svc-external LoadBalancer 10.0.139.201 52.xxx.xx.xxx 30778:30442/TCP 141m
compute-0-svc ClusterIP None <none> 1433/TCP,8300/TCP,8310/TCP,8311/TCP,8400/TCP,8410/TCP,8411/TCP,5502/TCP 141m
controldb-svc ClusterIP 10.0.15.221 <none> 1433/TCP,8311/TCP,8411/TCP 156m
controller-svc ClusterIP None <none> 443/TCP,8311/TCP,8301/TCP,8411/TCP,8401/TCP 156m
controller-svc-external LoadBalancer 10.0.17.229 52.xxx.xx.xxx 30080:31669/TCP 156m
data-0-svc ClusterIP None <none> 135/TCP,1433/TCP,8300/TCP,8310/TCP,8311/TCP,8312/TCP,8313/TCP,8400/TCP,8410/TCP,8411/TCP,8412/TCP,8413/TCP,51000/TCP 141m
gateway-svc ClusterIP None <none> 8443/TCP,8300/TCP,8311/TCP,8400/TCP,8411/TCP 141m
gateway-svc-external LoadBalancer 10.0.186.187 52.xxx.xx.xxx 30443:31769/TCP 141m
logsdb-svc ClusterIP None <none> 9200/TCP,8300/TCP,8400/TCP 151m
logsui-svc ClusterIP None <none> 5601/TCP,8300/TCP,8400/TCP 151m
master-p-svc ClusterIP 10.0.148.90 <none> 1433/TCP 141m
master-svc ClusterIP None <none> 135/TCP,8088/TCP,50075/TCP,50020/TCP,50010/TCP,8031/TCP,8032/TCP,8033/TCP,8040/TCP,8042/TCP,8080/TCP,1433/TCP,1533/TCP,9995/TCP,8998/TCP,8300/TCP,8301/TCP,8302/TCP,8310/TCP,8311/TCP,8400/TCP,8401/TCP,8402/TCP,8410/TCP,8411/TCP,8312/TCP,51000/TCP 141m
master-svc-external LoadBalancer 10.0.128.187 52.xxx.xx.xxx 31433:30783/TCP 141m
metricsdb-svc ClusterIP None <none> 8086/TCP,8300/TCP,8400/TCP 151m
metricsui-svc ClusterIP None <none> 3000/TCP,8300/TCP,8400/TCP 151m
mgmtproxy-svc ClusterIP None <none> 443/TCP,8300/TCP,8311/TCP,8400/TCP,8411/TCP 151m
mgmtproxy-svc-external LoadBalancer 10.0.76.84 52.xxx.xx.xxx 30777:31730/TCP 151m
nmnode-0-svc ClusterIP None <none> 9000/TCP,50470/TCP,14000/TCP,8300/TCP,8311/TCP,8400/TCP,8411/TCP,2020/TCP,50200/TCP 141m
sparkhead-svc ClusterIP None <none> 135/TCP,8088/TCP,8031/TCP,8032/TCP,8033/TCP,8080/TCP,1433/TCP,9995/TCP,8998/TCP,8300/TCP,8301/TCP,8302/TCP,8400/TCP,8401/TCP,8402/TCP,51000/TCP 141m
storage-0-svc ClusterIP None <none> 50470/TCP,50075/TCP,50200/TCP,50020/TCP,9000/TCP,50010/TCP,8040/TCP,8042/TCP,1433/TCP,8443/TCP,8300/TCP,8301/TCP,8310/TCP,8311/TCP,8400/TCP,8401/TCP,8410/TCP,8411/TCP 141m
クラスターのエンドポイントはサービスごとに役割を持っています。
また Azure 側にも対応する外部 IP があることを確認します。
ステートフルセットとデーモンセットを確認
SQL Server 2019 BDC はステートフルなサービスであるため、Statefulsets が作成されるほか、裏でメトリックを取るためデーモンも作成されます。
>kubectl get statefulsets
NAME READY AGE
compute-0 1/1 153m
controldb 1/1 168m
data-0 2/2 153m
gateway 1/1 153m
logsdb 1/1 163m
master 1/1 153m
metricsdb 1/1 163m
nmnode-0 1/1 153m
sparkhead 1/1 152m
storage-0 2/2 152m
>kubectl get daemonsets
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
metricsdc 1 1 1 1 1 <none> 164m
また詳細は以下のようなコマンドで確認。
kubectl get statefulset master -o yaml
ボリュームと要求を確認
各ポッドはボリュームが必要であり、data と logs が割り当てられます。これらの設定は control.json の storage で定義されています。
>kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-084b1ac5-1a52-11ea-9062-26efe99880fd 15Gi RWO Delete Bound mssql-cluster/data-metricsdb-0 default 169m
pvc-084c691b-1a52-11ea-9062-26efe99880fd 10Gi RWO Delete Bound mssql-cluster/logs-metricsdb-0 default 169m
pvc-09a0776f-1a52-11ea-9062-26efe99880fd 15Gi RWO Delete Bound mssql-cluster/data-logsdb-0 default 169m
pvc-09a1e09b-1a52-11ea-9062-26efe99880fd 10Gi RWO Delete Bound mssql-cluster/logs-logsdb-0 default 169m
...<省略>
>kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-compute-0-0 Bound pvc-767e0f16-1a53-11ea-9062-26efe99880fd 15Gi RWO default 161m
data-controldb Bound pvc-645d5908-1a51-11ea-9062-26efe99880fd 15Gi RWO default 176m
data-controller Bound pvc-64389d94-1a51-11ea-9062-26efe99880fd 15Gi RWO default 176m
data-data-0-0 Bound pvc-779b689f-1a53-11ea-9062-26efe99880fd 15Gi RWO default 161m
...<省略>
Azure ポータルからも同じ数の Disk が作成されている事を確認します。
SQL Server 2019 BDC への接続
参照: Azure Data Studio を使用して SQL Server ビッグ データ クラスターに接続する
ドキュメントにはセキュリティの観点からパスワードを変更するように記述があります。必要に応じて変えてみてください。
AZDATA_USERNAME ログインは、セットアップ時に作成される SQL Server マスター インスタンス上でのシステム管理者です。 SQL Server のコンテナーを作成した後、そのコンテナーで echo $AZDATA_PASSWORD を実行すると、指定した環境変数 AZDATA_PASSWORD が検索できるようになります。 セキュリティ上の理由から、ベスト プラクティスとしてパスワードを変更してください。
1. Azure Data Studio よりマスターインスタンスへ接続。
- アドレス: kubectl get svc で表示した service/master-svc-external の外部 IP とポート (既定で 31433)
- ユーザ名とパスワード: インストール時に環境変数に設定したもの
2. SQL Server Big Data Cluster タブでエンドポイントを確認。
まとめ
今回は azdata で簡単に SQL Server 2019 BDC をインストールできる事と、AKS 上に構成されるコンポーネントを見ていきました。次回はこの環境にサンプルをインストールしていくつかの操作を試します。