SQL Server 2019 は Kubernetes (k8s) が利用された構成も追加されています。
新しい機能として追加される Big Data Clusters についても、基盤部分は k8s が利用され、その上に様々な役割の Pod が起動することで、大規模データ分析の基盤の構築が行われます。
SQL Server 2012 で追加された AlwaysOn 可用性グループについても SQL Server 2019 では k8s をサポートし、k8s の可用性 / 回復性を使用した SQL Server の冗長構成のクラスターを構築することができるようになりました。
(SQL Server 2017 でも k8s 上に SQL Server をデプロイすることはできたのですが、シングルインタンスとしての利用想定となっており、k8s の仕組みを利用した AlwaysOn 可用性グループの構築については手法が提供されていませんでした)
詳細については、Always On availability groups for SQL Server containers で解説されていますが、構築の流れや構成を軽く見ておきたいと思います
構築の手順については、Deploy a SQL Server Always On Availability Group on Kubernetes Cluster から確認することができます。
k8s にデプロイするためのマニフェストファイルが公開されていますので、ドキュメントに従い、それらを順に実行することで構成できるかと。
最初に可用性グループ用の名前空間の作成を行います。
kubectl create namespace ag1
名前空間配下に作成できるリソースは、ここにまとめられますので、再構築したい場合などはこの名前空間を削除すれば一括で消せるかと。
kubectl delete namespace ag1
以降は、Github で公開されているマニフェストファイルを使用していきます。
https://github.com/Microsoft/sql-server-samples/tree/master/samples/features/high%20availability/Kubernetes/sample-manifest-files
最初に AlwaysOn AG on k8s のコアのリソースとなるオペレーター (カスタムリソース定義) を作成するための YAML を実行します。
kubectl apply -f https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/features/high%20availability/Kubernetes/sample-manifest-files/operator.yaml --namespace ag1
これでカスタムロールやオペレーターの Pod の作成が行われます。
次に、Pod 内の SQL Server のコンテナーで使用する sa のパスワードと、可用性グループを使用する際に使用する資格情報生成のためのマスターキーのパスワード格納するためのシークレットを作成します。
kubectl create secret generic sql-secrets --from-literal=sapassword="<sa パスワード>" --from-literal=masterkeypassword="<masterkey パスワード>" --namespace ag1
シークレットとしてパスワード用のものが追加されていますね。
後は、SQL Server のノードとなる Pod の展開を行います。
Github で公開されている YAML ですが、3 台の SQL Server が展開されるようになっています。
SQL Server 2019 CTP 2.0 が公開された直後に検証していた限りでは、各 Pod は重複したノードに配置できないようになっているようなので、起動する SQL Server 分のノードが必要になるかと。
そのため、今回、AKS のノードは 3 台で構築しています。
kubectl apply -f https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/features/high%20availability/Kubernetes/sample-manifest-files/sqlserver.yaml --namespace ag1
これで、Pod の展開が開始されます。
AKS の場合、各 SQL Server の「/var/opt/mssql」の永続化ボリュームのマウントも簡単に実行できるのでよいですね。
今回の検証では、SQL Server のデプロイをしてから 5,6 分で Pod の展開が完了し、SQL Server がデプロイされた状態になりました。
このタイミングで、各 Pod に 1433 の外部エンドポイント (Public IP) を持ったサービスが作成されていますね。
各 SQL Server にはこの IP で直接接続できるようになっていますので接続して構成を確認してみます。
Pod を展開するという操作だけで、可用性グループが自動的に構築されていることが確認できますね。
この時点では、各インスタンス向けのサービスは作成されていますが、AlwyasOn 可用性グループの特徴である、「透過的なプライマリへの接続」が可能な、エンドポイントが提供されていません。
それでは、最後に可用性グループに透過的にアクセスするためのサービスを作成します。
kubectl apply -f https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/features/high%20availability/Kubernetes/sample-manifest-files/ag-services.yaml --namespace ag1
これで Selector を用いて、透過的にプライマリ / セカンダリにアクセスをするためのサービスの作成が行われます。
従来の可用性グループのリスナーの役目を持ったサービスが作成された状態ですね。
Pod が停止 (SQL Server が停止) した場合の可用性/回復性については k8s の基盤や Operator の Pod により制御が行われます。
例えば、mssql1-0 という、プライマリの Pod を削除してみます。
kubectl delete pods mssql1-0 --namespace ag1
これを実行しても新しい Pod の生成や、プライマリの切り替えといった作業を k8s が実行してくれて、可用性と回復性を持った環境として SQL Server を実行することができるようになっています。
(フェールオーバー用のマニフェストを充てることで、手動フェールオーバーも可能です)
SQL Server は SQL Server 2017 で、クロスプラットフォーム対応として、SQL Server on Linux が提供されました。
SQL Server 2019 では、マルチプラットフォーム対応として、「SQL Server を実行する基盤」としての選択肢が追加されています。
k8s 上の Pod の SQL Server は、SQL Server on Linux で動作しているのですが、SQL Server 2017 での対応により、今までの SQL Server では利用できなかった基盤上での利用も、今後増えていくのかもしれないですね。