銀の光と碧い空

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

OpenShift上のSQL Server Always On 可用性セットをfailover してみる

前回の記事でSQL Server Always On 可用性セットをOpenShift 3.11に展開してみました。

tech.tanaka733.net

この環境を使ってfailoverのテストをしてみたいと思います。

手順はこちらのドキュメントに記載されています。

docs.microsoft.com

failoverするためのトリガーがkubernetesのjobとしてサンプルが公開されています。

sql-server-samples/failover.yaml at master · Microsoft/sql-server-samples · GitHub

この定義を見ると、mcr.microsoft.com/mssql/ha:vNext-CTP2.0-ubuntuというコンテナにはmssql-server-k8s-failoverというコマンドが用意されていて、それを実行することでfailoverが実施できるように見えます。可用性セットの名前をMSSQL_K8S_AG_NAMEで、セカンダリーからプライマリーに昇格させるPodの名前をMSSQL_K8S_NEW_PRIMARYで、可用性セットを展開している名前空間(OpenShiftの場合プロジェクト)をMSSQL_K8S_NAMESPACEという環境変数に指定します。前回の記事の通りに展開している場合、MSSQL_K8S_NEW_PRIMARYのみ変更の必要があります。<containerName>とあるのでPodではなくContainerの名前を指定するように見えますが、そうではなくて、現在セカンダリーで今からプライマリーに昇格するPodの名前になります。つまり、mssql2-0などと指定する必要があります。Podの名前が指定されていないとJobの実行が失敗して、失敗するたびに新規のJob用のPodが作成される*1ので、その場合はJobを削除しましょう。

Podの名前を指定したら、Jobを作成します。Jobもocコマンドで作成することができます。結果はdescribeコマンドで確認できます。

$ oc apply -f failover.yaml
$ oc describe jobs/manual-failover

f:id:tanaka733:20181106140705p:plain

失敗したときなどは、ログを確認しましょう。Pos名はJobが実行されるたびに変わるので、oc get podなどで確認してください。

$ oc logs <pod_name> -c manual-failover

f:id:tanaka733:20181106140856p:plain

failoverしたあとも、引き続き可用性セットのエンドポイントで接続できることもわかります。

f:id:tanaka733:20181106141833p:plain

というわけで一通りのことがOpenShift上でも確認できました。引き続きバージョンアップを待って試してみたいと思います。

*1:restartPolicy: Neverと指定されているため