銀の光と碧い空

クラウドなインフラとC#なアプリ開発の狭間にいるエンジニアの日々

SQL Server Always On 可用性セットをOpenShift 3.11上にデプロイしてみた

SQL Server 2019 から Kubernetes (k8s) が利用されたAlways On可用性セットの構成がサポートされました。詳細はSEの雑記のこの記事を読んでいただきたいのですが、kubernetesで動くならOpenShiftでも動くだろうということで試してみました。現在この機能が利用可能なSQL ServerのコンテナイメージはRHELではありませんが、基本的にもRHELではないコンテナイメージであってもOpenShift上で動きます。なお、Microsoftのプレゼンなどではkubernetes/OpenShiftをサポートと書かれていたりするので、将来的にはOpenShift向けの手順も公開されるものと思われます。

AKS を使用した SQL Server 2019 の AlwyasOn 可用性グループの構築 at SE の雑記

具体的な構築手順はこちらのドキュメントを参考に進めます*1

Kubernetes クラスター上の SQL Server Always On 可用性グループをデプロイします。 | Microsoft Docs

まず準備するOpenShiftですが、kubernetes 1.11.0が必要とあるので、OpenShift 3.11を使います。OpenShift 3.11がkubernetes1.11、3.10が1.10を含むようにバージョンが対応しています。また最低3つのcompute ノードとReadWriteOnceなPersistent Volume (PV)に利用可能なストレージが必要です。今回の検証に利用した環境はOpenShift 3.11で、master 1ノード、computeノード 4ノードの計5ノード構成をAzure上に構築しています。Azure Cloud Providerを有効にすることでAzure DiskをPVします。

基本的にはkubectlのコマンドをOpenShift CLIのocコマンドが対応しているので、kubectlをocに置き換えて実行していけばOKです。名前空間については、OpenShiftではプロジェクトとして作成する必要があります。

$ oc new-project ag1

GitHubのリポジトリからダウンロードしたマニフェストを使って展開していきます。まずはoperatorです。

$ oc  apply -f operator.yaml --namespace ag1

f:id:tanaka733:20181102162304p:plain

これで何がデプロイされたかはoc get allコマンドを使うとわかります。

f:id:tanaka733:20181102162425p:plain

また、WebConsoleから確認したい場合で、oc new-projecをsystem:adminなどで作った場合はWebConsoleにログインするユーザーにも権限を与えておきましょう。Projectのadmin権限を与えるコマンドはこうです。

$ oc adm policy add-role-to-user admin <ユーザー名> -n ag1

この時点ではWebConsoleではこのように見えています。

f:id:tanaka733:20181102162959p:plain

次にパスワード用のsecretを作成します。

$ oc create secret generic sql-secrets --from-literal=sapassword="SAP@ssW0rd" --from-literal=masterkeypassword="M@sterP@ssW0rd"  --namespace ag1

f:id:tanaka733:20181102163729p:plain

WebConsoleからだと、secretの中身を確認することもできます。

f:id:tanaka733:20181102163747p:plain

そして、SQL Serverのコンテナイメージ本体を展開します。

$ oc apply -f sqlserver.yaml --namespace ag1

f:id:tanaka733:20181102164533p:plain

oc get allするとSQL Serverのpodの他に初期化処理用にjobが実行されているのがわかります。

f:id:tanaka733:20181102165747p:plain

WebConsoleだとこんな感じに見えます。 f:id:tanaka733:20181102170557p:plain

それぞれのPodがSQL ServerとHA supervisor用の2つのコンテナを起動し、SQL Serverの方はag1とmssql1という2つのService (OpenShift Cluster内から接続可能なエンドポイント)が定義されています。

f:id:tanaka733:20181102170606p:plain

ag1はSQL Serverの3つのPodにわたって分散され、mssql1,2,3というのはそれぞれPodごとに作成されています。 f:id:tanaka733:20181102171014p:plain f:id:tanaka733:20181102171026p:plain

またストレージを確認すると3つのPVCがdynamic provisioningにより作成されていることがわかります。

f:id:tanaka733:20181102172243p:plain

OpenShiftのノードとなっているAzure のVMを確認すると、この名前のついたAzure Diskがマウントされていることもわかります。

f:id:tanaka733:20181102172338p:plain

次に負荷分散用のServiceを作成します。

$ oc apply -f ag-services.yaml --namespace ag1

f:id:tanaka733:20181102172701p:plain

これらのServiceはLoadBalancer Typeとして作成されています。Azure Cloud Providerを有効にしている場合は、kubernetesがAzure Load Balancerを作成し設定しています。同じAzureのリソースグループ内にkubernetesというAzure Load Balancerが作成されていて、これらのService用の設定が行われいてるのが確認できます。

f:id:tanaka733:20181102172935p:plain

実際に接続してみましょう。

f:id:tanaka733:20181102173111p:plain

ドキュメントの手順に従って可用性グループにデータベースを追加することもできました。

f:id:tanaka733:20181102173306p:plain

現時点では、OpenShiftとしての動作サポートはUbuntuベースですのでないのですが*2、OpenShiftはkubernetesをそのまま含んでいるのでMicrosoftのドキュメントと同様に動作することがわかりました。

*1:日本語があやしいですが

*2:RHEL以外のOSのコンテナの、OpenShiftでのサポートについてはRed Hatからの公式ドキュメントを参照してください