Fujitsu Cloud Direct当社が提供するサービスを法人のお客様へ直接販売するサイトです。

この記事は、ニフクラブログで2016-03-30に公開された記事を移転したものです。

こんにちは、FJcloud-V(旧ニフクラ) テクニカルアカウントエンジニアです。

FJcloud-V(旧ニフクラ)上で選択可能なOSに「Microsoft Windows Server 2012 R2 Standard Edition（64bit）＋SQL Server 2012 Enterprise Edition SP2」があります。

SQL Server2012のEEでは、AlwaysOnという機能が利用可能になっています。

本記事では上記OSにて、WSFC（Windows Server フェールオーバー クラスタリング）とSQL ServerのAlwaysOn可用性グループを利用してのSQLサーバーのクラスタリング構成が可能かを検証したいと思います。

はじめに

FJcloud-V(旧ニフクラ)では、サーバーに付与した増設ディスクを共有ディスクとして扱うことができません。そのため共有ディスク型でのクラスタリング構成の実現が通常は難しいという状況にあります。

そこで今回、SQL ServerのAlwaysOn可用性グループを用いて、非共有ディスク型構成でクラスタリング構成が可能か？ということで本検証を行っています。

以下にAlwaysOn 可用性グループの概要がありますので、こちらもご覧ください。 AlwaysOn 可用性グループ （SQL Server）

前提条件

本記事は、以下の前提知識がある方を想定しております。

• FJcloud-V(旧ニフクラ)のコントロールパネルの操作ができる方（サーバー作成、ネットワーク構築など）
• 基本的なWindows Server OSの設定ができる方（IPアドレスの設定、ファイアウォール設定など）
• ActiveDirectoryの環境構築ができる方

検証構成

本検証を実装するにあたり、以下の構成図の通り環境を実装しています。

• 本検証はクラスタリング構成を実装するため仮想IPが付与されることとなります。 クラスタリング対象のサーバーにグローバルIPアドレスを付与したままの場合は十分に注意して構築を行ってください。FJcloud-V(旧ニフクラ)の禁止事項に抵触する可能性があります。
  ご参考：FJcloud-V(旧ニフクラ) 禁止事項
• Windowsファイアウォールは無効にして検証を実施しています。
• FJcloud-V(旧ニフクラ)ファイアウォールは3サーバーともに同一グループで構成しています。
• 各ノード、WindowsUpdateを行っています。
• AD環境を事前に構築しています。 クラスタリング対象ノードはドメインメンバーとしてドメインに参加させています。

検証概要

FJcloud-V(旧ニフクラ)環境で、WSFCとSQL ServerのAlwaysOn可用性グループを利用してSQLサーバーのクラスタリング構成を構築し、フェールオーバーの確認までの検証を行っています。 その検証結果と手順を以降に記載します。

今回の検証ではプライマリとセカンダリの2台構成で実装しています。
本手順は、検証結果の1つであり、利用される場合は、事前にそれぞれの環境で十分に検証を行ってください。

検証手順

• 1.フェールオーバークラスタリング環境構築
• 1-1.フェールオーバークラスタリングインストール
• 1-2.クラスター環境構築
• 2.AlwaysOn 高可用性 環境構築
• 2-1.SQL Always Onの事前準備
• 2-2.SQL Server設定
• 2-3.可用性グループに設定するDBの作成
• 2-4.AlwaysOn可用性グループの作成
• 3.フェールオーバークラスタテスト
• 3-1.サーバーOS異常終了
• 3-2.SQL Serverサービス異常終了

検証詳細

1.フェールオーバークラスタリング環境構築

SQL ServerのAlwaysOn機能を使用するためにはWSFCの機能が必須となるため、まずはWSFCの機能を導入します。

役割と機能の追加ウィザードを起動し、機能の選択にてフェールオーバークラスタリングを選択しインストールします。（この手順はクラスターを構築するサーバーすべてで行います。）

以下の手順は、複数台あるノードのうち1台で実施すれば大丈夫です。今回の検証では「SQLWSFCNODE1」で実施しています。

1．管理ツールから「フェールオーバークラスターマネージャー」を開き、「構成の検証」を開きます。

2．「サーバーまたはクラスターの選択」にてクラスターを構成するすべてのサーバーを選択し、「次へ」をクリックします。
参照ボタンからADドメインのメンバサーバーの参照が可能です。

3. テスト オプションで「すべてのテストを実行する」を選択し、「次へ」をクリックします。

4. 「確認」が表示されたら「次へ」をクリックします。

5. 「概要」画面にて「検証されたノードを使用してクラスターを今すぐ作成する」にチェックを入れた状態で「次へ」をクリックします。
* いくつかの警告が出ることがありますが、「テストは正常に完了しました。」と出ていれば基本的には問題ありません。

6．「クラスターの作成ウィザード」が表示されたら「次へ」をクリックします。

7. 「クラスター管理用のアクセスポイント」ではクラスター名とIPアドレスを指定します。
ルーターのDHCP機能をご利用の場合など、ネットワークの構成によっては自動的にネットワーク・アドレスが構成され、ネットワーク・アドレスの入力欄が表示されないことがあります。

8．「確認」でクラスター名、構成するノードが表示されるので確認の後「次へ」をクリックします。

9. 作成が終わると「概要」が表示されます。
「クラスターの作成ウィザードを正常に完了しました。」と表示されていればOKです。「完了」をクリックし「クラスターの作成ウィザード」を終了します。

10. プライマリサーバーで、コマンドプロンプトを立ち上げて、クラスター用のVIPが存在していることを確認します。

2.AlwaysOn 高可用性 環境構築

WSFCの導入が完了したので、AlwaysOnの環境構築を行っていきます。

ドメインコントローラーにて、「Active Directory ユーザーとコンピューター」からドメインユーザーを作成します。

1.「ユーザーは次回ログオン時にパスワード変更が必要」は無効にした上でパスワードを指定してください。（今回の検証ではsqluserを作成します。）
以下［2］～［6］の手順はクラスター対象のノードすべてで実施してください。

2．SQL Serverのサービスへのログオンユーザーを作成したユーザーに変更します。

SQL Server構成マネージャーを起動し、「SQL Serverのサービス」を開き「SQL Server（MSSQLSERVER）」を右クリックしてプロパティを開きます。

「SQL Server（MSSQLSERVER）のプロパティ」が開いたら、「ログオン」タブの「このアカウント」にチェックをし、先ほど作成したドメインユーザーを指定し、パスワードを入力してください。

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

「AlwaysOn 高可用性」タブを開きます。 「Windowsフェールオーバークラスター名」に手順1-2［7］で登録したフェールオーバークラスター名を入力し、「AlwaysOn 可用性グループを有効にする」にチェックを入れ、「OK」を押します。

4. 「SQL Server（MSSQLSERVER）」を再起動します。

5. 「SQL Serverネットワークの構成」から「MSSQLSERVERのプロトコル」を開き、「TCP/IP」が「有効」になっていることを確認してください。

6. SQL Server saアカウントのパスワード変更

各ノードにてMicrosoft SQL Server Management Studioを起動し、認証を「SQL Server認証」に変更しsaアカウントで接続します。

初期パスワードは空白になっています。初回接続時にパスワードの変更が可能なため、任意のパスワードに変更してください。

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

この手順はクラスター対象の全ノードで実施してください。AlwaysOnでは、データとログファイルの場所が各サーバーで同じである必要があり、デフォルトと変えるときは全ノードでフォルダ作成し、手順2-1［1］で作成したユーザーに書き込み権限を付与してください。（今回の検証ではデータおよびログ用フォルダーを「C:\SQL_DATA」としています。）

2. バックアップデータ共有用フォルダの作成

各ノードで初期データを同期するための共有フォルダを作成します。

このフォルダにも手順2-1［1］で作成したユーザーに書き込み権限を付与し、共有の設定を行います。（この手順は1台のノードで行えば問題ありません。ただし、DBの作成およびAlwaysOnの設定を行うときはこの手順を実施したサーバーで実施してください。）

今回の検証ではSQLWSFCNODE1にBACKUPというフォルダを作成しています。

このページの手順は、手順2-2［2］を実施したノードにて実施してください。

SQL Server Management Studioを起動し、DBを作成します。

今回の検証では、DB名をDB1として作成しています。
作成するときに、データとログの保存先に手順2-2［1］で作成したフォルダを指定します。

2. 作成したデータベースにテーブルを作成し、データ投入をしてください。

3. 作成したDBを右クリックし、「タスク」-「バックアップ」を実行します。

バックアップ先を手順2-2［2］で作成したフォルダを指定します。

この手順は手順2-2、2-3を実施したノードで実施します。

1．可用性グループの作成

SQL Server Management Studioを起動し、「オブジェクトエクスプローラー」-「AlwaysOn 高可用性」を右クリックし、「新しい可用性グループウィザード」をクリックします。

2．次へを押して「名前の指定」で可用性グループ名にグループ名を指定してください。

今回の検証では「DB_ALWAYS」という可用性グループを作成しています。

3．「データベースの選択」で可用性グループに登録するデータベースを指定してください。

4. 「レプリカの指定」にてセカンダリレプリカのサーバーを指定します。

「レプリカの追加」を押すと「サーバーへの接続」が開くので、サーバーの指定、アカウント名とパスワードを入力して「接続」を押してください。

追加されたら「自動フェールオーバー（上限2）」と「同期コミット（上限3）」のチェックボックスすべてにチェックを入れてください。

5. 「データ同期の選択」で「完全」を指定し、「すべてのレプリカからアクセス可能な共有ネットワーク場所を指定」に、手順2-3［3］でバックアップを実行したフォルダを指定します。

6. 「検証」が実行されます。

「リスナーの構成を調べています」は警告となりますが、後ほど作成しますので問題ありません。

7. 「概要」に設定した内容が表示されるので、問題ないか確認をしてください。

8. ウィザードが正常に終了すれば問題ありません。

9. オブジェクトエクスプローラーにて、「AlwaysOn 高可用性」-「可用性グループ」-「DB名」-「可用性グループリスナー」を右クリックし「リスナーの追加」をクリックします。

「新しい可用性グループリスナー」が表示されたらネットワークの指定を行います。

10. プライマリサーバーで、コマンドプロンプトを開き、リスナー用のVIPが存在していることを確認します。

ここまででWSFCおよびAlwaysOnの構築が完了となります。この後は、実際にサーバーの停止など、不測の事態が発生したことを想定した検証を実施していきます。

今回、下記表に示すように、サーバーに付与した通常のIPアドレスとは別にWSFC用の仮想IP、SQL Serverのリスナー用の仮想IPを設定しました。

今回、WSFCおよびAlwaysOnを利用してクラスターを構築したとき、コントロールパネル上での表記が、各VIPを登録するごとに変化していきました。状況について以下に記載します。

1）サーバー構築時

2）WSFC構築終了段階

3）AlwaysOn　可用性グループリスナー登録終了段階

コントロールパネルからIPアドレスを取得する際に仮想IPのほうを表記しているみたいです。 仮想VIPが通常の静的IPを付与しているMACアドレスと同一のものに付与されているからと想定しています。

3.フェールオーバークラスタテスト

サーバーの停止時、SQLのサービス停止時に正常にフェールオーバーするか、どのような挙動となるかテストしていきます。

サーバーOSが落ちてしまった際のフェールオーバーを確認します。

3-1-1.フェールオーバー前状態確認

フェールオーバー前の各ノードの状態確認を行います。 SQLWSFCNODE1のほうがプライマリの状況です。

WSFC用VIPの状況

AlwaysOn 可用性グループリスナーの状況

3-1-2.フェールオーバーテスト

3-1-1で確認した状態からプライマリである「SQLWSFCNODE1」をシャットダウンします。

SQLWSFCNODE2にWSFC用VIPとリスナー用のVIPが引き継がれていることが確認できます。

リスナー用VIPにアクセスし、DBのデータが正常に確認できます。

OSが誤って終了してしまっても正常にフェールオーバーすることが確認できました。

SQL Serverのサービスが落ちてしまった際のフェールオーバーを確認します。

3-2-1.フェールオーバー前状態確認

フェールオーバー前の各ノードの状態確認を行います。 今回は、サービスの停止を確認するためサービスの状況も事前に確認します。 SQLWSFCNODE1の方がプライマリという状況です。

SQLWSFCNODE1

SQLWSFCNODE2

3-2-2.フェールオーバーテスト

3-2-1で確認した状態からプライマリである「SQLWSFCNODE1」のSQL Serverサービスを停止します。

サービス停止後のSQLWSFCNODE1の状態

リスナー用VIPがSQLWSFCNODE2に移行されているみたいです。

SQLWSFCNODE2の状態を確認してみます。

DBのデータも正常に同期されていたものが閲覧でき、リスナー用VIPが引き継がれてることが確認できます。

SQL Serverのサービスが何かしらの要因で停止してしまっても正常にフェールオーバーできることが確認できました。
ちなみに、この時のコントロールパネルのIPアドレスの表記は、以下のようになっていました。

検証まとめ

本検証の通り、FJcloud-V(旧ニフクラ)の提供OS「Microsoft Windows Server 2012 R2 Standard Edition（64bit）＋ SQL Server 2012 Enterprise Edition SP2」にて、WSFCとSQL ServerのAlwaysOn 可用性グループを利用するとSQLサーバーのクラスタリング構成を構築することが可能でした。

FJcloud-V(旧ニフクラ)では、標準でHA機能が実装されているため、ホストOSの故障時は自動で別ホストで復旧します（サーバー再起動は発生する）。

しかし、サービスが何らかの要因で停止してしまった場合など、OS以上が起因しての障害時の対処は、ご利用者様にて考慮する必要があります。

本検証の結果は、上記のようなOS以上の障害にも対応できる可用性の高いシステムを実現可能な構成の一つとなり得ると考えられます。

冒頭でも記述していますが、本手順については検証結果の1つであり、利用されるときは事前にそれぞれの環境で十分に検証を行っていただくようお願いします。