AlwaysOn 可用性グループを検証環境用と等で最小構成で構築したい場合のメモを。
この構成は AlwaysOn 可用性グループのフェールオーバーは使用できますが、ドメインコントローラーが SPOF になっていますのでご注意ください。
サーバーとして用意するものは、
- ドメインコントローラー 1 台
- SQL Server 2 台
となります。
ドメインコントローラー / SQL Server は通常のインストールが行われていることを前提とした環境を利用します。
■WSFC 構築上のポイント
AlwaysOn 可用性グループは、可用性グループに参加する SQL Server が WSFC のノードとして追加されている必要があります。
上述の環境で WSFC を構築すると、SQL #1 / SQL #2 の 2 ノードクラスターとなります。
通常、WSFC ではノード数の過半数 + 1 の投票権を確保しておく必要があります。
Windows Server 2012 であれば Dynamic Quorum の仕組みにより、Dynamic Weight による投票権調整が行われることで、2 ノードでクラスターを構築した場合の 1 ノード障害にも耐えることができる可能性がありますが、2 ノード構成の場合は一般的には以下のリソースが投票数を持つ環境を構築するかと。
- SQL #1
- SQL #2
- 共有フォルダー
上記のリソースが投票数を持つことで全体で 3 票を持つ環境を構築することができます。
この環境の場合、2 票が維持されていればクラスターを起動した状態とすることができますので、
- SQL #1 で障害が発生しダウン
- SQL #2 で障害が発生しダウン
- 共有フォルダーで障害が発生しダウン
のパターンに対応することができます。
今回の環境の場合、ドメインコントローラー上で共有フォルダを作成することで最小構成とすることができます。
# ただし、この環境ではドメインコントローラーが SPOF になるため、ドメインコントローラーが起動していないと AlwaysOn 可用性グループを使用することができません。
ドメインコントローラー上に共有フォルダーを作成する場合のポイントとしては、
- 共有フォルダーとして使用するフォルダーに WSFC の CNO のコンピューターアカウントのフルコントロールを設定しておく
ということでしょうか。
今回の環境では、WSFC-01 というコンピューターアカウントが作成されています。
そのため、ドメインコントローラー上に作成したフォルダーには以下のようなアクセス権を付与します。
このような環境が整っている場合、以下の PowerShell で共有フォルダーを使用したクラスタークォーラム設定を適用することができます。
# DC-01 がドメインコントローラー名 / Quorum Share が共有フォルダー名になります。
Get-Cluster | Set-ClusterQuorum -FileShareWitness "\DC-01QuorumShare"
これで、共有フォルダーが投票権を持つことができますので、SQL Server のどちらかが落ちてもクラスターを起動した状態とすることができます。
GUI から設定する場合には、「その他のアクション」→「クラスター クォーラムの構成」から設定することができます。
■APIPA を使用した CNO の IP アドレス設定
Azure 上で WSFC を構築した場合、CNO で使用される IP アドレスを DHCP から取得した場合、クラスターに参加しているノードのローカルの IP アドレスと重複したものが設定されてしまい、障害となり CNO をオンラインにすることができません。
AlwaysOn 可用性グループをテンプレート展開した場合とチュートリアルを参考に構築した場合の相違点 で少し触れたのですが、テンプレートから展開した場合、CNO の IP アドレスとして APIPA のリンクローカルのアドレスが設定されています。
この設定ですが GUI からはできず、以下のような PowerShell で設定する必要があります。
# GUI から静的な IP を設定しようとした場合、自分の NIC のサブネット内の IP しか設定することができません。
$res = Get-ClusterResource "クラスター IP アドレス" $res | Stop-ClusterResource $APIPA = "169.254.1.1" $SubnetMask = ($res | Get-ClusterParameter -Name SubnetMask).value $res | Set-ClusterParameter -Multiple @{"Address" = "$APIPA";"SubnetMask"= "$SubnetMask";"OverrideAddressMatch"=1;"EnableDhcp"=0}
ここまでの設定をすることで、Azure 上で AlwaysOn 可用性グループを構築するための前提となる WSFC の環境を構築することができます。
■SQL Server 構築上のポイント
SQL Server の構築はリスナー以外は通常の AlwaysOn と相違はないかと。
- 各ノードの SQL Server のサービスの起動ユーザーを同一ドメインユーザにする
- SQ Server 構成マネージャーから「AlwaysOn 可用性グループを有効にする」を有効にし、SQL Server のサービスを再起動
- 各ノードで同一のドライブレターの設定としておく
# 異なるドライブレターでも構築できますが、同一のほうが楽です - Windows ファイアウォールで以下を許可しておく
- TCP : 1433 (SQL Server)
- TCP : 5022 (可用性グループのエンドポイント)
- TCP : 59999 (負荷分散ロードバランサーの死活監視ポート)
Windwos ファイアウォールについては以下のような PowerShell で設定ができます。
New-NetFirewallRule -Name "SQL Server (TCP:1433)" -DisplayName "SQL Server (TCP:1433)" -Protocol "TCP" -LocalPort "1433" -Action Allow New-NetFirewallRule -Name "SQL Server (TCP:5022)" -DisplayName "SQL Server (TCP:5022)" -Protocol "TCP" -LocalPort "5022" -Action Allow New-NetFirewallRule -Name "SQL Server (TCP:59999)" -DisplayName "SQL Server (TCP:59999)" -Protocol "TCP" -LocalPort "59999" -Action Allow
あとは可用性グループのウィザードで作成していけばよいのですが注意点としては、
- 可用性グループのリスナーはあとで作成する
ということでしょうか。
可用性グループのリスナーですが、Azure Load Balancer (Public Load Balancer) 、 Internal Load Balancer のどちらを使用するかによって指定する IP が異なってきます。
次の投稿でリスナーについてまとめてみたいと思います。