SE の雑記

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

IaaS の SQL Server で AlwaysOn を構築した際に考慮しておきたい設定について

leave a comment

Azure の IaaS (仮想マシン) に SQL Server をインストールした場合、AlwaysOn 可用性グループで可用性を向上させることが多いかと思います。

IaaS の SLA は Virtual Machines の SLA に記載されており、可用性セットや Premium SSD を使用することで稼働率を上昇させることは可能です。

AlwaysOn 可用性グループを使用した場合は、可用性セットによる稼働率の向上を行いますが、IaaS の可用性セットでは、可用性セット内のいずれかのインスタンスへの接続を保証することになるため、クラスター内のいずれかのサーバーが停止した時間が発生するということになります。

クラスターの標準の設定であれば、数秒程度の停止であればフェールオバーを発生させることなくシステムを稼働させることはできますが、メンテナンスで数 10 秒停止するようなケースでは、フェールオーバーが発生することになります。

メンテナンスが発生した場合に、できるだけフェールオーバーを発生させないようにするための情報については、いくつかの情報が公開されていますので、本投稿ではその情報をまとめておきたいと思います。

仮想マシンのメンテナンスに対しての WSFC としての対応

まず、Azure の仮想マシンのメンテナンスですが、Azure での仮想マシンのメンテナンス にどのようにメンテナンスが行われるかが記載されています。
(メンテナンススケジュールの情報取得については Azure Metadata Service: Windows VM のスケジュールされたイベント を参照)

頻繁に行われる可能性が高いのは「再起動を必要としないメンテナンス」に記載されている「メモリ保持メンテナンス」になるのではないでしょうか。

メモリ保持メンテナンスについては次のように記載されています。

影響がゼロではないメンテナンスでは、ほとんどの場合、VM の一時停止は 10 秒未満です。 場合によっては、Azure はメモリ保持メンテナンスのメカニズムを使用します。 これらのメカニズムでは、最大 30 秒間 VM が一時停止され、RAM 内のメモリが保持されます。 その後、VM が再開され、クロックが自動的に同期されます。

メモリ保持メンテナンスは長時間の停止は発生しませんが、最大で 30 秒程度、仮想マシンが一時停止する可能性があります。

まず、最初に考慮すべき必要のあることは WSFC (Windows Server Failover Clustering) のフェールオーバーをどのように設定するかとなります。

WSFC ではノード間の死活監視が行われており、クラスターに参加しているノードの稼働状況がハートビート通信により確認されています。

WSFC としてはこのハートビートによる死活監視の期間をどのようにするか?を考慮しておく必要があります。

これについては クラスターのハートビート通信の設定値の範囲について で設定値がまとめられています。

WSFC では、同一または異なるサブネットに対してのハートビートの送信間隔や、送信の試行回数を設定することができます。

同一のサブネット内のノードに対してのハートビートの送信間隔については、

  • SameSubnetDelay
  • SameSubnetThreshold

異なるサブネット間のノードに対してのハートビートの送信間隔については、

  • CrossSubnetDelay
  • CrossSubnetThreshold

で設定を行うことができ、この設定を調整することでノードが一時停止状態になっていても、WSFC のノードを構成するサーバーとしては有効な状態としておくことができます。

同一のリージョンであれば「Same~」、異なるリージョンであれが「Cross~」の設定が重要になってきます。

メモリ保持メンテナンスを意図的に発生させることは難しいため、Hyper-V の仮想マシン等で環境を作成し、一時停止をすることで、メモリ保持メンテナンスのような状況を作り出してテストをするのが良いかと思います。

今回は、AG-DB01 / AG-DB02 という、2 台で AlwaysOn 可用性グループを構築しています。

テストについてはすべてのクラスターリソースを AG-DB01 で実行している状態で、次のスクリプトを実行して、アクティブノードを 30 秒間、一時停止状態にして再開するというものになります。

Get-VM -Name "AG-DB01" | Suspend-VM
Start-Sleep -Seconds 30
Get-VM -Name "AG-DB01" | Resume-VM

この裏で、AlwaysOn 可用性グループのリスナー経由でクエリを実行し続け、どのような動作となるかを確認します。

クラスターの設定としては次の 2 パターンの設定を使用します。

(1 行目の設定はデフォルトの設定です)

(Get-cluster).SameSubnetDelay = 1000;(Get-cluster).SameSubnetThreshold=5
(Get-cluster).SameSubnetDelay = 2000;(Get-cluster).SameSubnetThreshold=120

 

デフォルトの設定で SQL を継続して実行した場合は次のような挙動となりました。

image

最初は AG-DB01 で動作していますが、デフォルトの設定ではハートビートの遅延 / 試行回数が低い設定となっています。

そのため、AG-DB01 が一時停止状態になると、あまり時間を待たずにノードの停止とみなされ、AG-DB01 で動作していたリソースがフェールオーバーし、AlwaysOn 可用性グループも AG-DB02 に切り替わります。

それでは 2 行目の設定にしてみます。

コマンドのタイムアウトは発生していますが、一時停止中にフェールオーバーは発生せず、一時停止解除後は、AG-DB01 に接続が行われていることが確認できます。

image

このように、ハートビートの間隔を変更することで、クラスターでノードが停止されるまでの期間を緩和させることができ、メモリ保持メンテナンスにより、数 10 秒の一時停止が発生してもフェールオーバーの発生を抑制することができます。

ただし、コマンドタイムアウト (クライアントの SQL タイムアウト) や、セマフォタイムアウト (TCP/IP レベルでのタイムアウト) のようなものが発生する可能性がありますので、フェールオーバーしないこととコマンドが継続して実行されるかについては別の観点で考慮をしておく必要があります。

数秒の停止であればコマンド / セマフォタイムアウトは耐えられるかと思いますが、数10 秒の停止となると、ハートビートの設定でフェールオーバーがしなかったとしても、TCP/IP レベルで接続がタイムアウトして、エラーになると思います。

 

可用性グループのクラスターリソースの設定について

SameSubnet / CrossSubnet の設定は、クラスターの設定となりますが、AlwaysOn 可用性グループとしても正常性監視の設定があります。

Always On 可用性グループのリース、クラスター、正常性チェック タイムアウトのしくみとガイドライン。

AlwaysOn 可用性グループを構築すると、クラスターリソースとして「SQL Server Availability Group」を使用したリソースが作成され、このリソースにより可用性グループの状態の維持管理が行われます。

このクラスターリソースでは、次のようなプロパティの設定があり、ヘルスチェックの間隔やチェックする内容の設定を行うことができます。

image

メモリ保持メンテナンスによる一時停止による対応を想定した場合には、こちらの設定はデフォルトでも問題ないかと思います。

このリソースは、リソース自身がオンラインの状態でこれらのプロパティの設定を使用して、正常性の監視が行われているはずです。

そのため、一番最初に考慮すべきことは「クラスターのノードとして、アクティブなノードが停止にならないようにする」ことであり、この設定については SameSubnet / CrossSubnet によって制御されますので、まずは、AlwaysOn 可用性グループのリソース設定ではなく、クラスターのハートビートの設定を考慮すべきだと思います。

 

マルチサブネット / リージョンで構築する場合の考慮点

構成によっては東西のデータセンターにノードを配置する必要があるのではないでしょうか。

AlwaysOn 可用性グループは WSFC のテクノロジーを使用するため、「東西のそれぞれのデータセンターのみで稼働する状況をいかにして作成するか?」ということを考慮する必要があるかもしれません。

アプリケーションがどのように単一の接続点で、SQL Server に接続を行うかということについても考慮が必要です。

AD が入ると、正直この辺はとても面倒であり、切り戻しをどう考えるかも、かなり大変な点ではありますので、本投稿ではそれほど触れません。

どのような機能を活用することができるかだけ触れておきたいと思います。

東西のデータセンターで考えた場合、西日本のデータセンター内のノードが停止していても、東日本のサービス稼働状況には影響を与えないようにしておく必要があります。

クラスターとしては、投票数の調整を考慮しておく必要があるかと。

デフォルトの設定では、東西のすべてのサーバーがクラスター内の投票の割り当てを持ちますので、西日本のノードがダウンしたことによる投票数の調整が想定しない挙動になる可能性があります。

そのため、西日本のノードについては投票の割り当てをそもそも行わないように、得票数をどのようにするかを検討しておく必要があります。

これについては クォーラムを構成および管理する で触れられていますので、投票数の調整を検討しましょう。

クラスターの設定だけでなく、可用性グループの設定についても検討を行う必要があります。

今の AlwaysOn 可用性グループは構成の選択肢がいくつか増えており、次のような構成が可能です。

  1. AD のメンバーサーバーを使用した AlwaysOn 可用性グループ
  2. ワークグループクラスターを使用した可用性グループ
  3. クラスターレス可用性グループ
  4. 分散型可用性グループ

可用性グループにはいくつかの構成の選択肢があります。

東西のデータセンターの独立性を担保するような場合には、分散型可用性グループでつなぐことで構成としてはシンプルになるかと思います。

ただし、分散型可用性グループでは、単一のリスナーによる分散型可用性グループ内のノードへの接続ということが難しいですので、アプリケーションからの接続についてはどのようにするかを検討する必要があります。

(PaaS の場合はフェールオーバーグループがこれを解消するための機能となりますが)

 

IaaS で作成するとここで書いたような設定の考慮点の他に、パッチマネージメントやソフトウェアのバージョンアップといった維持管理についても検討する必要があります。

Azure VM を使用した構成については次のような情報も把握しておく必要があります。

久しぶりに IaaS のクラスター周りの情報を確認しましたが、IaaS で高い稼働率を誇る環境を作るということは PaaS で実装されている様々な考慮点を自分で実装するということになりますので、なかなかしんどいですね。

Written by masayuki.ozawa

1月 18th, 2020 at 8:29 pm

Posted in SQL Server

Tagged with

Leave a Reply

*