More than 5 years have passed since last update.

SQL Server AlwaysOn 構築メモ（その３）

SQLServer

Last updated at 2015-08-31Posted at 2015-08-31

前編ではWSFCの構成を行ないました。
ここではいよいよAlwaysOn（可用性グループ）の構成を行ってみます。
正直長くてめんどくさいですが、１つずつ進めて行きましょう。

##全体構成

その１：前提知識の整理と基礎環境構築編
その２：WSFC(Window Server Failover Clustering)構築編
その３：AlwaysOn構築編
その４：接続確認編
その５：テストしてみる
その６：その他（可用性グループへのDB追加など）

##本編での主な内容

SQL Serverのインストール
AlwaysOnのための構成（前準備）
AlwaysOnの構成

##SQLサーバのインストール

SQL Serverのインストール情報は多く存在しているので他の記事に譲ります。
インストール自体は標準的に行ないます。

強いてポイントを上げるとすると、

認証はWindows認証ではなく、統合認証を選択しておく

ということでしょうか。後々で1ステップ減らせますので。
私はSQL Server 2014を利用していますが、2012でもほぼ同じです。

##AlwaysOnのための構成

SQL Serverのインストールが完了したら、AlwaysOnを構成するための各種設定を行っていきます。
冗長化するDBを作成する前準備としては、次のような操作が必要です。

AlwaysOn可用性グループの有効化（SQL Server構成マネージャでの作業）
SQL Server実行のユーザー作成と設定（ADおよびSQL Server構成マネージャでの作業）
TCP/IPの有効化（SQL Server構成マネージャでの作業）
WindowsFirewallの設定
データ、ログファイルの格納場所作成
バックアップデータの共有場所作成

###AlwaysOn可用性グループの有効化

SQLサーバ構成マネージャにてAlwaysOn可用性グループの有効化を行ないます。
SQL Serverのプロパティ画面で、「AlwaysOn 高可用性」のタブを選択します。クラスター名として先ほど作成したWSFCのクラスタが選択されています。

AlwaysOn　高可用性グループを有効にする　にチェックをいれます。この操作はSQL1,SQL2の両方で行なって下さい。
設定を反映させるためにSQL Serverを一度再起動します。

###SQL Server実行ユーザーの作成と設定

AlwaysOnを構成・実行するためには全てのSQL Serverで同じドメインユーザーでが実行アカウントとして利用されている必要がありますので、作成します。

####ユーザーの作成

ユーザーの作成はAD側で行ないます。追加するユーザー名はsqlserviceとします。
管理ツールより、ActiveDirectoryユーザーとコンピューターから、Usersを右クリックし、ユーザーを追加していきます。

パスワードの変更要求はチェックを外して下さい。画面の伴わないユーザーなので、パスワードを変更することができずトラブルのもとです。ウイザードをそのまま進め、ユーザーを作成します。

####SQL Serverログオン（実行）ユーザーの設定

SQL Server用のユーザー作成が完了したので、SQL1,SQL2のSQL Server実行ユーザーをsqlserviceに変更します。

SQLサーバ構成マネージャを起動し、ユーザーを変更します。SQL Serverのプロパティを開き、「ログオンタブ」でユーザーをsqlserviceに変更します。
このとき、場所をドメインにしないとユーザーが見つかりませんのでご注意を。変更するとサービスが再起動されます。

###TCP/IPの有効化

SQL Serverがリモートからの制御を受け付けるにはFirewallだけでなく、SQL Server自体の設定も必要です。
SQLサーバ構成ツールのネットワーク構成のプロトコルメニューから、TCP/IPの有効化を行って下さい。この操作はSQL1,SQL2にて行って下さい。
構成を変更したら再起動を行ないます。

###Windows Firewallの設定

TCP/IPは有効にしましたが、Fiewallが標準ではSQLの通信ポートである1433をブロックするので、SQL1とSQL2が通信できるように1433ポートを空けます。ここでは少しサボって、ドメインネットワークにおけるFierwallを無効にします。この操作はSQL1,SQL2にて行って下さい。

ここまでで、準備はおおよそ整いました。

##AlwaysOnの構成

AlwaysOnの構成（DBの可用性グループへの追加）は、DB単位で行ないますが、追加に際しては対象となるDBがいくつかの条件を満たしている必要があります。その条件とは下記のようなものです。

データファイル(mdf)、ログファイル(ldf)の保存位置がSQL1,SQL2で同じであること。
最低限1回、完全普及モデルでフルバックアップが取られ、そのファイルがSQL1,SQL2で共有できる場所に置かれていること。
上記を満たすDBが1つは存在していること。

###データおよびログファイル格納場所の作成

データおよびログファイルの保存位置を作ります。
AlwaysOnでは、上記の通り保存の位置が各サーバで同じ必要があります。そういう意味では、必ずしも新規に保存場所を作る必要はありませんが、標準の保存場所は階層が深いため、ここではわかりやすい位置にフォルダを作成しておきます。

また、作成したフォルダにはsqlserviceユーザーが書き込めるように権限を付与します。

場所はCドライブの直下にC:¥SQL_AO_Dataというフォルダを作り、権限を付与します。この操作はSQL1,SQL2で行って下さい。

作成だけでなく、sqlserviceユーザーへの権限付与もお忘れなく。

###バックアップデータ共有フォルダの設定

SQL1,SQL2で初期データを同期するための共有フォルダを作成します。
その１で紹介した絵では、AD上に配置していましたが（わかりやすさのために）、別にsqlserviceユーザーがアクセスできればどこでもいいので、今回はSQL1に、C:¥SQL_AO_Shareとして作成します（SQL2で行う必要はありません）。

共有設定し、かつsqlserviceユーザーからの書込みを許可します。

このフォルダを介してバックアップデータを共有するのは初期設定および何かしらのトラブルで再度同期処理を行うときのみで、運用中は利用されません（たぶん）。でないと、シェアードナッシングにならないので。

###DBの作成

DBも1つ作っておきましょう。また、簡単なテーブルも作成し、データを流し込んでおきます。
この操作はSQL1のみで行ないます。

普通にManagement StudioからDBを作成します。
ここでは、testdbというDBを作ります。このとき、データとログの保存位置は、先述のプロセスで作成したC:¥SQL_AO_Dataフォルダを指定します。

作成したら、適当にテーブルを作成し、データを流し込んでおきましょう。ここではnameというカラムがあるmembersテーブルを作成してみました。

nameにhogeをインサートしておきます。

###DBのバックアップ

可用性グループを構成するには、必ず一度バックアップしたDBが必要なので、testdbのバックアップを取得します。
このとき、バックアップの保存先は先ほど作成したC:¥SQL_AO_Shareにします。

バックアップが必要というより、復旧モデルが"完全"のバックアップには全履歴が入っているので同期の起点となるものと考えて方がいいでしょう。

###可用性グループの作成

やっと本題です。
DBの可用性グループを作成していきます。この操作はSQL1のみで行ないます。
「新しい可用性グループウイザード」を起動させます。

ウイザードが開始されます。

グループ名としてTEST_AGと名前をつけます。

データベースを選択します。なお、DBの設定ミスがあれば、ここの状態にエラー内容が表示されます。
ここでは前提条件を満たしている旨の内容が表示されています。

レプリカの追加でSQL2を指定します。なお、ここでFirewallやTCP/IPの有効化などを忘れているとSQL2にログインできません。ログインに失敗した場合には、Firewall等の設定を再度確認してみてください。

SQL2が追加されたら、自動フェールオーバーや同期・非同期、セカンダリの読取りの可否などを設定します。
ここでは、自動フェールオーバー、同期、セカンダリの読取り可等を設定します。多くの場合、自動フェースオーバーでいいと思いますが、運用に合わせて手動にする場合もあるでしょう（データに不整合が発生する際など）。