SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Server v.Next CTP 1.3 のクロスプラットフォーム可用性グループとクラスターレス可用性グループについて思ったこと

leave a comment

SQL Server v.Next CTP 1.3 では、Windows / Linux のクロスプラットフォームで可用性グループを組むことができます。

作った際に思ったことをつらつらと。

実際に構築した環境が以下になるのですが、Windows と Linux で分散型可用性グループを組んでおり、Windows がプライマリ可用性グループとなり、Windows 側の DB 変更が Linux 側に伝搬される構成で作っています。
image

クロスプラットフォームの可用性グループですが、「同一の可用性グループににクロスプラットフォーム環境を配置する」のではなく、「分散型可用性グループを使用して各プラットフォームの可用性グループを接続する」という形が基本構成になるのではないかと思います。

SQL Server v.Next CTP 1.3 時点では、Linux 側はクラスターレスの可用性グループとして構築することになります。
Windows / Linux でクラスターレスの可用性グループを構築した場合「仮想 IP や可用性グループのリソースチェック / 自動的なフェールオーバー / プライマリセカンダリの制御」に関しては、WSFC 以外の仕組みを使用して実装する必要があるのかと。

Linux の場合は、Pacemaker + Corosync のような組み合わせで、制御を実施しています。

CTP 1.3 時点では、Windows 版の場合は、クラスターレスで構築した際に、可用性グループを監視する仕組みが現状提供されていない (私がドキュメントを見つけられていないだけかも知れませんが…) ので、仮想 IP を持つリスナーの作成や、可用性グループの制御を実施する方法がないのかなと。

現状、Windows 環境で、クラスターレスで構築した場合、両ノードが起動している際の手動フェールオーバーは実施できると思いますが、障害系の動作をした場合に、可用性グループを正常に動作させることが現状は難しいのかなと思っています。(方法があるのかもしれませんが、ドキュメントやその部分の検証をうまくすることができませんでした)
「ADD LISTENER」 でリスナーを追加しても、仮想 IP が付与されるわけではないので、クラスターレスと仮想 IP を利用した、プライマリに対しての透過的な接続方法についても検討が必要なのかなと。
# Windows の可用性グループの仮想 IP の制御は従来、クラスターリソースが実施していたため、単純にクエリでリスナーを作成しても、仮想 IP は付与されません。

Windows / Linux を同一の可用性グループに配置することはできましたが、「Windows / Linux の可用性グループを一元的に管理 / 制御する仕組み」がないと、同一の可用性グループ内のノードの制御がうまくできないため、この構成のクロスプラットフォーム可用性グループは難しいのかなと思いました。

Windows / Linux を同一のクラスターとして制御する仕組みでサードパーティーが参入する余地があるのかもしれませんが、どういう構成がサポートされるのか、今後標準機能でクロスプラットフォームの可用性グループの制御をする仕組みが提供されるのかは、今後もウォッチしようかなと。

SQL Server v.Next CTP 1.3 の Windows / Linux 間の分散型可用性グループであれば、クロスプラットフォームの可用性グループを作成することができました。

以下を気を付けておけばよさそうです。

  • Windows / Linux 間の接続は、証明書を使用したエンドポイントの設定を使用する
  • 直接シード処理を実施する場合、Windows と Linux でデータベースを配置するパスを同じにしておく
    (Windows の DB を Linux パスでアクセスできる場所に併せておけばよいかと)
  • Linux のリスナーについては、Pacemaker で作成した仮想 IP を使用して設定する
  • Windows 側はクラスターレスではなく、WSFC の可用性グループとして構築する

Windows 側をクラスターレスの可用性グループにした場合、アクセス可能な仮想 IP が設定がうまくできなかったため「リスナー間を接続する」という設定ができないため、Windows 側については WSFC の可用性グループで作っておいた方がよいかと。
今回の検証は、クラスターレス間の可用性グループを接続しているのですが、Windows 側はリスナー (仮想 IP )が設定できなかったため、分散型可用性グループを設定する際に、Windows 側の接続先に関しては、特定のノードの実 IP を設定することで、Windows / Linux のクラスターレス可用性グループ間を接続させてしまっています。
Windows 側のプライマリが切り替わると、分散型可用性グループの同期が停止してしまうため、実運用では使えないですが…。

SQL Server 2016 と Linux の v.Next CTP 1.3 の異なるバージョン間の分散型可用性グループの設定については、まだ検証を実施している最中で、検証ができたら改めてブログに書こうかと思っています。

  • クロスプラットフォームの可用性グループ
  • クラスターレスの可用性グループ

はまだ、情報が少ないので検証をしながら定期的に情報をキャッチアップしないとなと。

クロスプラットフォームの可用性グループは、「移行/テストのためのデータ移行」や「最小のダウンタイムで切り替えを行う」方法としての利用かと思いますが、構成を理解できていないと運用がなかなか厳しいな…。

追記

Always On Availability Groups with No Underlying Cluster in SQL Server v.Next がとても興味深かったです。

この情報を読んでよく考えてみたのですが、AlwaysOn 可用性グループ、自動フェールオーバーを伴わない同期モードが使えましたね。

クラスターレスの可用性グループを構築し、自動フェールオーバーを無効にすることで、ウィットネスを含まないミラーリングのような同期構成として利用はできるかもしれないですね。
自動フェールオーバーをしない可用性グループの設定であれば、Windows と Linux を混在させたクラスターレスの環境を使うというのは一考の余地がありそうですね。
image

クラスターレスの構成では「REQUIRED_COPIES_TO_COMMIT」によるコピー数の制御は重要な設定となってきそうです。
デフォルトの設定は「0」となっており、この構成の動作は SQL Server 2016 と同等ということになっています。

クラスターレスの構成の場合、ノードマジョリティ相当になるのかなと思っていたのですが、そういうことでもなさそうです。

今回の可用性グループは 3 台で構成しているのですが、3 台中 2 台が落ちていてもアクセスができる状態となっています。

image

しかし、3 台で同期モードを使用している場合、「HADR_SYNC_COMMIT」の待ちとなり、更新はできないのですが検索はできる状態となっていました。
1 台でも更新を可能にする場合、プライマリになっているサーバーのみが同期で、他のサーバーに関しては非同期にするというような構成にする必要があるかと。
この設定であれば、1 台のサーバーのみが稼働している状態で、参照と更新の両方を実施することが可能です。
image

2 台以上が「同期コミット」となっている場合は「REQUIRED_COPIES_TO_COMMIT」を 1 以上に設定することができるようになります。

image

上記のように設定した場合は、「REQUIRED_COPIES_TO_COMMIT」が「1」に設定することができます。
# 「同期コミットのサーバー数 ?1」が設定できます。

ALTER AVAILABILITY GROUP ag1 SET (REQUIRED_COPIES_TO_COMMIT=1)


この設定にした場合、同期コミット内で 1 台のコピーが必要となりますので、同期コミットの環境が 2 台起動していないと、DB にアクセスができない状態となるようです。

image

2 台の同期コミットのサーバーが起動している場合は DB にアクセス可能となります。

image

クラスターレスの可用性グループに関しては、自動フェールオーバーをしない環境として構築をし、「REQUIRED_COPIES_TO_COMMIT」によって、同期コミットの何台が稼働しているかで制御を行う構成を意識しておくと検証がはかどりそうですね。

Share

Written by Masayuki.Ozawa

2月 23rd, 2017 at 8:16 am

Posted in SQL Server

Tagged with ,

Leave a Reply