やまさんノート

先に、「SQL Server 2012 RC0 のインストール」や「新機能の理解」ということで、簡単に整理しました。
ここでは、2012年3月7日（U.S.時間）にリリースされた最新の SQL Server 2012 の注目機能のひとつとして「AlwaysOn 可用性グループ」について、実際に試してみたいと思います。

その前に、AlwaysOn 可用性グループ について、簡単におさらいしておきましょう。

簡単に言うと、AlwaysOn 可用性グループは、DBM（データベースミラーリング）と WSFC（Windows フェールオーバー クラスタリング）のいいところどりをしたようなものです。

AlwaysOn 可用性グループでのデータベースの複製は、DBM の場合と同様に、「同期モード」と「非同期モード」のどちらかを選択することができます。（トランザクションログ（更新履歴）に基づいています。）
具体的に、「同期モード」では、プライマリでログ情報の圧縮を行い、それをセカンダリへ転送し、セカンダリでそのログを受け取ったことをプライマリへ伝え、プライマリがセカンダリからの受け取り通知を受け取ってはじめて処理が完了します。（トランザクションの完了） 一方、「非同期モード」では、セカンダリがログを受け取ったことを確認せずに処理を完了します。（この方法は、パフォーマンス重視のモードで、遠隔地へのデータベースの複製時など、DR（災害復旧）に利用することができます。）
なお、実際の設定では、同期モードには、さらに2つのモードがあり、障害が発生したときにプライマリとセカンダリの役割を自動的に入れ替える「自動フェールオーバー」モードと、自動フェールオーバーは行わずに手動で切り替えを行う「高い安全性」モードがあります。 なお、DBM（データベースミラーリング） との大きな違いは、DBM では、セカンダリの台数が1台に制限される点で、AlwaysOn 可用性グループでは、セカンダリを4台まで追加することができます。（セカンダリ1台では、ローカルの可用性の確保に同期モードのデータベースミラーリングを採用した場合、DR（災害復旧）対策に別のテクノロジー（ログ配布など）を採用しなければなりませんし、DR 対策として非同期モードのデータベースミラーリングを採用した場合には、今度はローカルの可用性確保のために別のテクノロジー（WSFC による SQL Server クラスターなど）を採用しなければなりません。） AlwaysOn 可用性グループでは、ローカルでの可用性確保を同期モードのセカンダリで行いつつ、DR 対策として非同期モードのセカンダリを配置する、といったことが簡単に行うことができます。
また、AlwaysOn 可用性グループでは、セカンダリに対するリアルタイムでの読み取り操作を行える点も大きな違いです。（DBM ではデータベーススナップショット作成時点での過去のデータの参照のみです。）
また、セカンダリに対しては、バックアップ（完全バックアップやログバックアップ）を実行することもでき、本番環境へ負荷をかけることなくバックアップの取得が可能になります。
さらに、AlwaysOn 可用性グループでは、監視サーバー（ウィットネス）が不要となり、コスト削減の効果もあります。（DBM では、自動フェールオーバー構成時に監視サーバーが必須になります。）

それでは、自習書にならって、AlwaysOn 高可用性を試していきましょう。

１．前提条件

まずは、AlwaysOn 可用性グループを動作させるための前提条件を確認します。

・AlwaysOn 可用性グループへ参加させる各サーバーは、Windows Server 2008 R2 SP1 を適用していること。

・AlwaysOn 可用性グループへ参加させる各サーバーは、同じ Active Directory ドメインへ参加していること。
　AlwaysOn 可用性グループは、 WSFC（Windows Server フェールオーバークラスター）の機能を利用するため、各サーバーは同じ Active Directory ドメインへ参加している必要があります。 ・AlwaysOn 可用性グループへ参加させる各サーバーは、WSFC（Windows Server フェールオーバークラスター）のノードであること。
　AlwaysOn 可用性グループでは、各ノードの障害検知とリスナー（仮想サーバー名）機能を実現するために、WSFC のリソース機能を利用しているため、AlwaysOn 可用性グループを構成するメンバーは、必ず WSFC のノード（WSFC の管理ツールであるフェールオーバークラスターマネージャー上で「ノード」として認識されているサーバー）である必要があります。 ・WSFC の各ノードには、通常の SQL Server のインストールと同様、それぞれのローカルドライブへインストールした SQL Server インスタンス、またはフェールオーバークラスターインスタンスとしてインストールした SQL Server（SQL Server クラスター）が必要。
　AlwaysOn 可用性グループを構成するには、SQL Server クラスターが必須ではないことがポイントです。（SQL Server クラスターを構成するには高価な共有ストレージが必須になりますが、AlwaysOn 可用性グループでは、SQL Server クラスターが必須ではないため、共有ストレージは不要です。）
なお、AlwaysOn 可用性グループを構成する各ノードには、通常の SQL Server の場合と同様、それぞれのローカルドライブへ SQL Server をインストールします。
（ただし、AlwaysOn 可用性グループのメンバーにできるのは、異なるマシン上で動作している単独の SQL Server インスタンスまたは SQL Server クラスターのみで、同じマシン（同じノード）内の、複数の名前付きインスタンスを同じ AlwaysOn 可用性グループ内のメンバーにすることはできません。）
（従来のバージョンのデータベースミラーリングやログ配布機能などは、同一マシン内の複数インスタンスで検証することができましたが、AlwaysOn 可用性グループでは複数マシンが必須になります。）

・SQL Server のサービスアカウントをドメインユーザーへ設定して、すべてのノードで同じアカウントを利用していること。

・データベースを格納するフォルダーに対して、SQL Server のサービスアカウントへ NTFS アクセス許可（変更権限）を付与しておくこと。

・データベースを格納するフォルダーを、すべてのサーバー上に同じパスで作成しておくこと。

・バックアップデータを保管するための共有フォルダーを作成しておき、SQL Server のサービスアカウントに対して共有アクセス許可と NTFS アクセス許可（変更権限）を付与しておくこと。

・対象データベースの復旧モデルが「完全」であること。

・対象データベースの完全バックアップを最低1回取得していること。

・SQL Server 構成マネージャーツールを利用して、AlwaysOn 可用性グループ を有効化しておくこと。

２．WSFC のノードに各サーバーを追加

なお、ここでは、自習書にならって、Active Directory 環境下に 3台のサーバー（EVAL-SQL2012-1、EVAL-SQL2012-2、EVAL-SQL2012-3）を用意しました。
（なお、ドメインサーバーを、WSFC のノードのひとつとして流用することはできません。（DC のため構成が異なります。））

では、簡単に、WSFC（Windows Server フェイルオーバークラスター）のノードとしてクラスタ環境を作成する流れについて整理します。

まずは、各サーバーに「フェイルオーバークラスタリング」機能をインストールします。（「サーバーマネージャー」から） インストール後、「フェイルオーバークラスターマネージャー」を起動して、「構成の検証...」を行います。 ノードとする各サーバーを追加して、「次へ」進みます。 「すべてのテストを実行する」を選択して、「次へ」進みます。 確認して、「次へ」進みます。 検証中．．． 検証完了です。（なお、警告は、内容を確認しておきます。（「レポートの表示」から）） 続いて、「クラスターの作成...」を行います。 同じく、ノードとする各サーバーを追加して、「次へ」進みます。 クラスター管理用のアクセスポイント（クラスター名、および、IPアドレス）を設定して、「次へ」進みます。 確認して、「次へ」進みます。 クラスター作成中．．． クラスターの作成が完了です。 各サーバーが、クラスターのノードとして追加されました。

その後、各ノードには、それぞれのローカルドライブへ SQL Server 2012 のデータベースエンジンをインストールしていきます。

３．前提条件の確認

AlwaysOn 可用性グループについて、いろいろと試す前に、先に挙げた前提条件を確認しておきたいと思います。
（または、ここで、条件に合うように設定していきます。）

・Windows Server 2008 R2 の SP1 を適用していること。
・同じ Active Directory ドメインへ参加していること。
・WSFC（Windows Server フェールオーバークラスター）のノードであること。

この3点については、WSFC ノードとして追加できた段階でクリアだと思います。

・SQL Server のサービスアカウントをすべてのノードで同じアカウントを利用していること。（ドメインユーザー）
SQL Server のサービスアカウントとして使うアカウントを Active Directory ドメインユーザーへ設定して、すべてのノードにそのアカウントをサービスアカウントとして設定します。
（「SQL Server 構成マージャー」から、SQL Server サービスのプロパティを開いて、［ログオン］タブから行います。）

・データベースを格納するフォルダーに対して、SQL Server のサービスアカウントへ NTFS アクセス許可（変更権限）を付与しておくこと。
データベースを格納するフォルダーに対して、SQL Server のサービスアカウントへ NTFS アクセス許可（変更権限）を付与します。（なお、該当フォルダは、自習書にならって、C:\AGtest とします。）
（Windows エクスプローラから、該当アカウントを追加して、変更権限を与えます。） ・データベースを格納するフォルダーをすべてのサーバー上に同じパスで作成しておくこと。
ここでは C:\AGtest フォルダーを3つのサーバー上に作成しました。
（なお、これは、高可用性設定ウィザードでは、内部的にバックアップと復元機能を利用して初期同期（初回のデータベース複製）を行っているため、同じパスのフォルダーがないと、復元に失敗してしまうためです。）

・バックアップデータを保管するための共有フォルダーを作成しておき、SQL Server のサービスアカウントに対して共有アクセス許可と NTFS アクセス許可（変更権限）を付与しておくこと。
バックアップデータを保管するための共有フォルダー（ここでは、C:\AGtemp）を、プライマリサーバー上に作成し、SQL Server のサービスアカウントに対して共有アクセス許可と NTFS アクセス許可（変更権限）を付与します。
（共有フォルダーを作成するには、フォルダーのプロパティを開いて、［共有］タブから行います。） ・対象データベースの復旧モデルが「完全」であること。
まずは、可用性グループを設定するためのデータベースを作成します。
（「SQL Server Management Studio」を起動して、プライマリサーバーへ接続し、AlwaysOn 可用性グループをテストするデータベース（ここでは、AGtestDB）を作成します。） このステートメントでは、AGTestDB という名前でデータベースを作成し、データ ファイル（.mdf）とログ ファイル（.ldf）は「C:\AGtest」フォルダーへ格納しています。データベースの作成後は、その中へ「t1」という名前のテーブルを作成して、データを1件（1）を INSERT しています。

次に、対象データベースの復旧モデルが「完全」であることを確認します。
（データベース（AGTestDB）のプロパテを開いて、［オプション］ページの［復旧モデル］から確認ます。） ・対象データベースの完全バックアップを最低1回取得していること。
該当データベースの完全バックアップを実行します。（可用性グループを設定するには、事前に最低 1回の完全バックアップを実行しておく必要があります。） ・SQL Server 構成マネージャーツールを利用して、AlwaysOn 可用性グループを有効化しておくこと。
「SQL Server 構成マネージャー」から、AlwaysOn 可用性グループを有効化します。（各ノードで設定します。）
（AlwaysOn 高可用性を有効化するには、「SQL Server サービス」のプロパティを開いて、［AlwaysOn 高可用性］タブで「AlwaysOn 可用性グループを有効化する」をチェックします。（なお、WSFC（Windows Server フェールオーバークラスター）のノードでない場合には、このオプションはグレーアウトされていて設定することができません。）） 設定後は、SQL Server サービスを再起動する必要があります。（「SQL Server サービス」を右クリックして、［再起動］をクリックします。） ４．可用性グループの設定

SQL Server Management Studio の左ペインの「AlwaysOn 高可用性」の「可用性グループ」を右クリックして、「新しい可用性グループウィザード」をクリックします。 「新しい可用性グループ」ウィザードが起動するので、「次へ」進みます。 「可用性グループ名」へ任意の名前を入力して、「次へ」へ進みます。 対象のデータベースを選択（ここでは、AGTestDB）して、「次へ」進みます。 「レプリカの追加」ボタンをクリックして、追加したいセカンダリへ接続します。
（順次、EVAL-SQL2012-2 、EVAL-SQL2012-3 と追加します。） 続いて、EVAL-SQL2012-1 と EVAL-SQL2012-2 の「自動フェールオーバー」と「同期コミット」にチェックをいれます。（これで、自動フェールオーバーが可能な同期モードにます。）
また、EVAL-SQL2012-3 は、そのままにします。（これで、データベース複製を非同期モードで行うようになります。） また、「読み取り可能なセカンダリ」で、読み取りモード（「はい」、「読み取り目的のみ」）を選択することで、セカンダリに対しても読み取りアクセスができるようになります。 次に、「エンドポイント」タブにおいて、可用性グループの内部的な通信で利用されるエンドポイントの設定を確認（変更）することができます。既定では、hadr_endpoint という名前のエンドポイントが TCP 5022 ポート番号を利用するように作成され、暗号化が有効化に設定されています。 次に、「バックアップの設定」タブにおいて、「セカンダリ優先」をチェックします。（可用性グループの自動バックアップをセカンダリレプリカで行います。使用可能なセカンダリレプリカがない場合はバックアップはプライマリレブリカで実行されます。） 次に、「リスナー」タブにおいて、「今は可用性グループリスナーを作成しない」を選択し、「次へ」進みます。（後で、手動で静的な IP アドレスを割り当てたリスナーを作成することにします。） 「データ同期の選択」において、「完全」を選択し、共有ネットワークの場所（ここでは、AGtemp）を入力して、「次へ」進みます。
（選択した各データベースの完全データベースバックアップおよびログバックアップを実行することにより、データ同期が開始されます。これらのデータベースは各セカンダリに復元され、可用性グループに結合されます。） 「検証」結果を確認して、「次へ」進みます。 「確認」して、「完了」をクリックします。（可用性グループの構築が開始されます。） 可用性グループ構築中．．． ひとつ警告が出ましたが、とりあえずは完了です。 「可用性グループ」を展開して、作成した可用性グループ（AG1）が表示されることを確認します。 ５．可用性グループの状態の確認

「SQL Server Management Studio」から、［表示］メニューの［オブジェクトエクスプローラーの詳細］を選択して、「オブジェクトエクスプローラーの詳細」を表示します。 左ペインのオブジェクトエクスプローラーで「可用性レプリカ」をクリックして、セカンダリとの接続状態や同期の状態（同期済みかどうかなど）を確認することができます。 なお、同期モードや自動フェールオーバーの設定などを確認・変更する場合は、可用性グループ（AG1）を右クリックし、「プロパティ」を選択し、表示されるダイアログ上にて行います。
次は、「ダッシュボードからの監視」について整理したいと思います。