AlwaysOn 可用性グループでは可用性グループのクラスターリソースの実行ノードによって、プライマリ / セカンダリの切り替えを行っています。
可用性グループのクラスターリソースがフェールオーバーした際に優先所有者の切り替えが発生しているので、その動作についてまとめてみたいと思います。
左がフェールオーバーする前、右がフェールオーバーした後の優先所有者の設定となります。
フェールオーバー前後で優先所有者の設定は同じになっていますね。
それでは、本題の可用性グループのフェールオーバーが発生した場合の動作を見てみたいと思います。
左がフェールオーバー前、右がフェールオーバー後の優先所有者になります。
AlwaysOn-SQL-02 から AlwaysOn-SQL-01 にフェールオーバーを実施したのですが、優先所有者の順番が変更されているのが確認できます。
WSFC のログからも確認をしてみたいと思います。
WSFC のログには以下のような出力が行われています。
00001f5c.00001458::2014/12/25-12:47:25.596 INFO [GUM] Node 2: executing request locally, gumId:1936, my action: /rcm/gum/SetGroupPreferredOwners, # of updates: 1 00001f5c.00001458::2014/12/25-12:47:25.596 INFO [RCM] rcm::RcmGum::SetGroupPreferredOwners(AlwaysOn-AG, 00001f5c.00001458::2014/12/25-12:47:25.596 INFO 2 00001f5c.00001458::2014/12/25-12:47:25.596 INFO 00001f5c.00001458::2014/12/25-12:47:25.596 INFO ) 00001f5c.00001458::2014/12/25-12:47:25.596 INFO [GEM] Node 2: Sending 1 messages as a batched GEM message 00001f5c.00001458::2014/12/25-12:47:25.620 INFO [RCM] rcm::RcmApi::AddPossibleOwner: (AlwaysOn-AG, 1) 00001f5c.00001458::2014/12/25-12:47:25.620 INFO [GUM] Node 2: executing request locally, gumId:1937, my action: /rcm/gum/AddPossibleOwner, # of updates: 1 00001f5c.00001458::2014/12/25-12:47:25.621 INFO [RCM] rcm::RcmGum::AddPossibleOwner(AlwaysOn-AG,1) 00001f5c.00001458::2014/12/25-12:47:25.621 INFO [RCM] Adding node 1 to resource 'AlwaysOn-AG'. 00001f5c.00001458::2014/12/25-12:47:25.621 INFO [GEM] Node 2: Sending 1 messages as a batched GEM message 00000948.00000ab0::2014/12/25-12:47:25.622 INFO [RES] Network Name : Getting Read/Write private properties 00001f5c.00001458::2014/12/25-12:47:25.624 INFO [GUM] Node 2: executing request locally, gumId:1938, my action: /rcm/gum/SetGroupPreferredOwners, # of updates: 1 00001f5c.00001458::2014/12/25-12:47:25.624 INFO [RCM] rcm::RcmGum::SetGroupPreferredOwners(AlwaysOn-AG, 00001f5c.00001458::2014/12/25-12:47:25.624 INFO 2 00001f5c.00001458::2014/12/25-12:47:25.624 INFO 1 00001f5c.00001458::2014/12/25-12:47:25.624 INFO 00001f5c.00001458::2014/12/25-12:47:25.624 INFO ) 00001f5c.00001458::2014/12/25-12:47:25.624 INFO [GEM] Node 2: Sending 1 messages as a batched GEM message
SetGroupPreferredOwners が実行されているのが確認できますね。
名称から見て、優先所有者の変更が行われているかと思います。
AlwaysOn 可用性グループの優先所有者ですが、自動的にプライマリのノードが設定されるようになっています。
この理由ですが、自動フェールバックの設定に起因しているのではと考えています。
AlwaysOn 可用性グループの自動フェールバックの設定ですが、以下のようになっています。
フェールバックの設定ですが、「今すぐ」に設定されています。
そのため、最優先所有者 (一番上の優先所有者) に自動的にフェールバックが行われます。
この設定を有効に利用するために、優先所有者の自動的な設定を行っているようです。
優先所有者の変更ですが、可用性グループのクラスターリソースがオンラインになったタイミングで変更を行っているようです。
そのため、以下のような状況になった場合、すぐにフェールバックが行われる可能性があります。
- 一時的に障害が発生し、セカンダリにフェールオーバーが行われたが、可用性グループのリソースがオンラインになる前に障害が復旧した場合
この場合、障害が回復し、自動的にフェールバックが行われ利用ができればいいのですが、瞬間的な復旧ですぐに障害が再発した場合、障害のままフェールオーバーされない状態になることが考えられます。
デフォルトの設定では、
- 指定した期間内の最大エラー数 : 1
- 期間 (時間) : 6
となっています。
そのため、6 時間に 1 回を超えるフェールオーバーは実施せずに、障害が発生した場合は失敗の状態のままにして再度のオンラインが行われません。
この動作を避けるためには、
- 自動フェールバックを使用しない (フェールバックを禁止する)
- 最大エラー数と時間を調整して、複数回のエラーが許容できるようにする
の対応が考えられるかと。
優先所有者の設定については、可用性グループのリソースをオンラインにした際に、自動的に設定を変更してしまっているため、この設定を変更することはできませんが、「フェールオーバー」タブの内容については、可用性グループのリソースでは設定を変更していないため、設定した内容はフェールオーバー後も適用されます。
この辺の動作が記載されているドキュメントが見当たらないのですが、障害の際の動作を把握するうえで、結構重要な動作な気がします。