SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server 2008 R2 August CTP のノード追加のリトライ結果です。
SQL Server 2008 R2 だけがインストールされている環境を作って再検証してみました。
今回は最初のノードのインストール後に再起動し、ノード追加を実行してみたところ、正常にインストールが完了しました。
?
[SQL Setup failuer] のエラーポップアップが表示されてしまていたのは、SQL Server のリソースが
起動していなかったからかもと、今更ながら思ってしまいました…。
再起動したタイミングでリソースを移動するの忘れていたらポップアップとしては同じメッセージが表示されました。
Setup Boot Strap のログに出力されている Exception もぱっと見は同じ気がします。
ひとまず、CTP 版でもクラスタの構築は一通りできたの、構築の流れをつかむという当初の目的はクリアです。
SQL Server 2008 のクラスタ構築と手順は一緒ですね。
今回、Windows Server 2008 R2 で SQL Server を 3 インスタンス起動させた Active / Active / Active / Passive (AAAP) の
クラスタを構築したのは Windows Server 2008 の WSFC で AntiAffinityClassNames プロパティが動くことの検証を
したかったためです。
[AntiAffinityClassNames] は 3 ノード以上のクラスタでクラスタグループに設定するプロパティになります。
サーバー クラスタ : Windows Server 2003 のクラスタ構成の推奨事例
ホット スペア サポートのための Windows クラスタ グループ構成方法
3 ノード以上のクラスタの場合、1 ノードを待機ノードとして設定するのが一般的な構成です。
| ノード 1 | ノード 2 | ノード 3 |
| Active (稼働ノード) | Active (稼働ノード) | Passive (待機ノード) |
| サービス A | サービス B | N/A |
この状態でノード障害が起きた時にリソースがどのように配置されるかというと、
| ノード 1 | ノード 2 | ノード 3 |
| Active (稼働ノード) | 障害 | Active (稼働ノード) |
| サービス A | N/A | サービス B |
となることもありますが、
| ノード 1 | ノード 2 | ノード 3 |
| Active (稼働ノード) | 障害 | Passive (待機ノード) |
| サービス A / サービス B | N/A | N/A |
となることもあります。
優先所有者が設定されている場合は、優先所有者にフェールオーバーされますが、障害はどのノードで発生するか
わかりませんので、優先所有者の設定で 1 ノードでサービスが 2 つ起動しないようにするのは大変です。
# 優先所有者がすべて障害だった場合は、実行可能なノード内でランダムにリソースが配置されます。
このような時に使用するのが、[AntiAffinityClassNames] になります。
[AntiAffinityClassNames] を設定すると、リソースを実行していないノードがある場合はそのノードに
優先的にリソースの移動をさせることができるようになります。
この設定は優先所有者より優先されます。
設定はクラスタグループに以下のように行います。
| クラスタグループ | サービス A | サービス B |
| AntiAffinityClassNames | MSSQL | MSSQL |
[サービス A] と [サービス B] に [MSSQL] という [AntiAffinityClassNames] を設定しています。
これにより、リソースが移動する際に [MSSQL] という [AntiAffinityClassNames] が設定されているグループを
実行しているノードには、同一の [AntiAffinityClassNames] の移動を優先的には行わないようになります。
| ノード 1 | ノード 2 | ノード 3 |
| Active (稼働ノード) | Active (稼働ノード) | Passive (待機ノード) |
| サービス A | サービス B | ? |
の状態で [ノード 2] で障害が発生した場合、リソースの移動先は [ノード 1] / [ノード 3] のどちらかになります。
[サービス B] の [AntiAffinityClassNames] には [MSSQL] という値が設定されています。
[サービス A] の [AntiAffinityClassNames] にも [MSSQL] が設定されているため、このグループが動いているノード
[ノード 1] は優先的な移動対象から外し、[ノード 3] で [サービス B] が実行されます。
# 同一の [AntiAffinityClassNames] が設定されているノードは排他で考え、優先的な移動先から外します。
ただし、厳密な排他ではありませんので、他に稼働できるノードがない場合は、同一の [AntiAffinityClassNames] が
設定されているグループを複数実行する形になります。
この設定により、3 ノード以上のクラスタで、待機ノードを有効に使用できるようにすることが可能です。
今回の検証環境では SQL Server のインスタンスは以下のように配置しています。
この状態で [2008R-NODE-03] のクラスタサービスが停止した場合、インスタンスを起動していない、
[2008R2-NODE-04] にリソースが移動するでしょうか？
[2008R2-NODE-04] に移動してしまいました…。
5,6 回試したのですが、リソースが動いていないノードに移動してくれていました。
何回か試していると、既にリソースが動いているノードにも移動される予定だったのですが、
待機系のノードにリソースが移動されてしまいました。
2008 のクラスタになってこの辺りの制御ロジックって変わったのでしょうか？？
これだと [AntiAffinityClassNames] の挙動が確認できないので [INSTANCE3] の優先所有者として
[2008R2-NODE-01] を設定して、各グループに [AntiAffinityClassNames] を設定してみました。
[AntiAffinityClassNames] は以下のコマンドで設定できます。
| cluster group “<グループ名>” /prop AntiAffinityClassNames=”<一意の識別名>”
例) |
?
優先所有者だけが設定されている場合、[2008R2-NODE-03] を停止すると、[2008R2-NODE-04] にリソースが移動し、
[2008R2-NODE-03] 起動後に [2008R2-NODE-04] を停止すると、[2008R2-NODE-01] でリソースが実行されました。
# なんだか納得いかない動きですが…。
[AntiAffinityClassNames] を設定すると、[2008R2-NODE-03] が停止すると、[2008R2-NODE-04] にリソースが移動し、
[2008R2-NODE-03] 起動後に [2008R2-NODE-04] を停止すると、[2008R2-NODE-03] でリソースが実行されました。
停止時の動きが変わっているの [AntiAffinityClassNames] の設定により、リソースの移動先が選定されているように見えます。
3 ノード以上は Windows Server 2008 でも [AntiAffinityClassNames] の設定は必要そうですね。
SQL Server 2008 R2 のノード追加作業です。
最初に書いておきますと、ノードの追加に失敗してしまいました…。
最初のノードのインストールが終了した際に再起動していなかったことが気になりますがスナップショットを撮っていなかったので、
簡単に再検証することもできず…。
中途半端な投稿となってしまいましたが環境を再整備できたらまた試してみたいと思います。
R2 をインストールすると SQL Server 2008 の共有コンポーネントも R2 にアップグレードされてしまうものがあるようなので、
共存環境を作る際は考慮が必要かもしれないです。