SQL Server 2012 では共有ストレージを使用しない冗長化構成 (AlwaysOn フェールオーバークラスターインスタンス / AlwaysOn 可用性グループ) をとることができるようになっています。
そのため、クォーラム構成として [ノードおよびファイル共有マジョリティ] を使用することも多くなってくるかと思います。
今回の投稿では、ノードおよびファイル共有マジョリティを使用した場合のサーバー起動順の注意点を見ていきたいと思います。
Windows Server 2008 R2 で試していますので、Windows Server 2012 になるとこの辺の挙動が変わるかもしれません。
# ダイナミッククォーラムがどのように影響するかまだ調べられていないもので…。
■今回使用している構成
今回は以下の構成を使用しています。
二つのネットワークにサーバーを配置して、クォーラムの構成としてはノードおよびファイル共有マジョリティを使用しています。
これは災害対策のサイトを構築する際に使用されることのあるクラスターの投票の構成になると思います。
ネットワーク A のサーバーのみがクラスターの Vote (投票) を有効にしていますので、ネットワーク B のサーバーで障害が発生してもクラスターを形成するための投票には含めない形になっているため、ネットワーク A のサーバーには影響を与えることなくサービスを提供することができます。
# CLS-NODE-01 / CLS-NODE-02 / CLS-FS-01 の中で 2 台が起動していればクラスターが動作する構成です。
■ネットワーク A でサーバーを起動する際の注意点
このような構成を使用している場合、ネットワーク A でサーバーを起動する際に注意事項があります。
両サーバーを片側ずつ停止 / 起動をして、クラスター内で起動しているノードがある場合には問題はないのですが、全サーバーを停止した状態で起動する場合は注意が必要になります。
例えば以下の順番でサーバーを停止 / 起動してみます。
- CLS-NODE-01 を停止
- CLS-NODE-01 を停止後に、CLS-NODE-02 を停止
- CLS-NODE-01 を起動
ノードおよびファイル共有マジョリティが使用されていますので、CLS-NODE-01 / CLS-FS-01 の 2 台が起動しており投票数も足りている状態ですが、この状態でクラスターが起動するでしょうか??
この停止の起動順序では、イベントビューアーのシステムに [FailoveClustering] の [1561] が出力されクラスターを開始することができません。
# サービスは起動しているのですがクラスターに接続できない状態となります。 
これについては以下の技術情報に記載があります。
フェールオーバー クラスターのクォーラム構成について
クラスター ノードのクラスター サービスを開始または停止する
The MNS cluster service may not start after you install the update in Microsoft Knowledge Base article 921181 on a computer that is running Windows Server 2003 with Service Pack 1
先程の停止 / 起動手順では最後に起動していたノードは CLS-NODE-02 になります。
そのため、このノードがクラスター構成データの最新のコピーを保持していることになります。
そのため、クラスターを開始するためには、CLS-NODE-02 が起動している必要があります。
- CLS-NODE-01 を停止
- CLS-NODE-01 を停止後に、CLS-NODE-02 を停止
- CLS-NODE-01 を起動
- CLS-NODE-02 を起動
という手順で起動をすることで、クラスターを開始することができます。
CLS-NODE-02 を起動してフェールオーバー クラスター マネージャーを起動すると現在のホスト サーバーが CLS-NODE-02 となっていることが確認できます。 
- CLS-NODE-02 を停止
- CLS-NODE-02 を停止後に、CLS-NODE-01 を停止
- CLS-NODE-01 を起動
という手順で停止 / 起動をした場合は、CLS-NODE-01 を起動したタイミングでクラスターに接続することができますので、ホスト サーバーは CLS-NODE-01 となっています。 
ノードおよびファイル共有マジョリティを使用する場合、クラスター構成データの最新のコピーをどのノードが持っていたかということが起動する際に重要になってきます。
サーバーを全停止しなければ (1 台ずつの停止であれば) 影響はでませんがメンテナンス等で全停止する場合は気を付ける必要が出てきます。
■クラスターの強制起動による障害対応
クラスター構成データの最新のコピーを持っていたサーバーが起動できれば問題はないのですが、全停止をした後に最新のコピーをもっていたサーバーが起動できなかった場合は、他のノードでクラスターを強制起動する必要があります。
例としては以下のようなシナリオですね。
- CLS-NODE-02 を停止
- CLS-NODE-02 を停止後に、CLS-NODE-01 を停止
- CLS-NODE-02 を起動
- CLS-NODE-01 で障害が発生して起動できない
この場合、最新のコピーをもっていたのは CLS-NODE-01 になりますので、CLS-NODE-02 を起動したタイミングでは1561 のエラーが発生しクラスターを起動することができません。
ただし、最新のコピーを持つサーバーは障害が発生していますので、CLS-NODE-02 だけで起動する必要があります。
このような場合に使用するのが強制起動の作業になります。
クォーラムを使用せずに WSFC クラスターを強制的に起動する
手順としては、
- サービスから [Cluster Service] を停止する。
- [管理ツール] → [Windows PowerShell Modules] を起動する。
- [Start-ClusterNode -FixQuorum] を実行して、強制起動する。
この手順を実行することでクラスターを強制起動することができます。
# コマンドプロンプトから起動する場合は、[net start clussvc /forcequorum] で起動することができます。
強制起動することで、最新のコピーを持つサーバーは CLS-NODE-02 になりますので再起動をした場合は再度同じ作業をしなくても起動することが可能です。
強制起動した後に CLS-NODE-01 が復旧した場合は、特に追加の作業はしないでもノードに組み込まれます。
AlwaysOn 可用性グループを使用している場合、クラスターを強制起動した後は可用性グループの所有者が更新されていないため、可用性グループの強制手動フェールオーバーを実行する必要があります。
これについては BOL に記載があります。
可用性グループの強制手動フェールオーバーの実行 (SQLServer)
可用性グループの環境も作成しようと思っているのでこれは別の機会にまとめてみたいと思います。