あまちゃんブログ

やあ!僕だよ!

カテゴリ:SI構築技術 > 冗長化


はじめに

WindowsServerFailoverCluster(2012R2)を商用環境で構築してきました。
なかなかググってもいい情報もなし、書籍をみても簡単なチュートリアルしかなく実際に自分で構築をしてから作業にあたりましたが、構築してハマって見つけて大変助かりましたNECさんや富士通さんが出している構築手順書は秀逸だと思います。
http://support.express.nec.co.jp/os/w2012r2/WS2012R2_WSFC_installation_guide.pdf

なら、こここで終わってしまうのですが、構築時にはまっている人向けに、構築して分かった事象解決やナレッジ的な情報を書いてみたいと思います。困っている人の味方あまちゃん:wink:
ほんとは画面SSを見せたいのですが、閉じた環境での構築だったり、コンプラなんちゃらで載せられませんの。

構成

まず構築した構成について紹介しますね。
 

■クラスタ方式
-アクティブスタンバイの2台構成でFC-SAN接続の共有ディスクをマウントさせる「ノード及びマジョリティ構成」という一般的な構成です。従って「Quarum」ディスク用に1GB以上のLUNを用意しました。構成ファイルをクラスタが参照するのでrawではなくNTFSフォーマット(最新のフォーマットでいいです)でマウントしてください。ドライブの見分けがつかないといった管理上の理由がなければ、クラスタ構成ファイルが存在することなどからドライブレターはつけない方がいいかもしれません。
 

■クラスタリソース構成
-管理アクセスポイント(コアクラスタリソース)
 -仮想IP <192.168.0.1>
 -仮想ホスト名
 -Quarum領域 <ドライブレターなし/NTFS>
-役割
 -クライアントアクセスポイント
  -仮想IP <192.168.0.11>
  -仮想ホスト名
  -データ領域 (共有ドライブ)
  -ファイルサーバ
  -HULFT(汎用サービス)


■構成イメージ
aa.png

アプリケーションリソース単位で分けたい方は、クライアントアクセスポイントは複数作成可能です。ここではクライアントアクセスポイントを一つ作成して、その配下にミドルウェアサービスや共有ドライブのリソースを作成しました。

 

■リソース依存関係
ab.png

クラスタ概念で必須の起動から停止のシーケンスについて図で表しています。
あまり意識しなくてもクラスタがこの関係を作ってくれますが、例えばインスタンス起動の後リスナーを起動させてエラーを吐かせない作りにしたり、スクリプト処理を追加するのであればここの依存関係を意識します。変更手順は該当するリソースを選択し、[プロパティ] ダイアログ ボックスの[依存関係] タブを使用して設定してくださいね。

それでは構築順序にともないチェックリストと解説を入れていきますね。

OS環境設定チェックと補足

  • OSインストール後Windows修正パッチを最新にしましょう。
  • サービスLANはSPOFの観点からNICチーミングをしましょう。Windows標準のものを使った方が管理しやすいです。
  • ADに参加してください。必須です。
  • ノードのローカル管理者権限を有するドメインアカウントでログインする。Administratorであるならば意識はしません。ただしADの管理者権限はWSFCでは要件ではないので、エンドユーザーのセキュリティポリシーに従って設定してください。
  • WindowsFirewall無効にする際サービスまで停止しないこと。また無効にする際はAD参加後に実施しないとドメインに対する設定が有効になっても気づかない。
  • NICの順序設定は「サービス用」⇒「ハートビート用」に並べ替える。

ストレージ接続設定チェックと補足

  • クラスタを組んでいるんだからストレージはそれなりのアレイ構成にしてください。
  • クラスタのQuarum領域は1GB以上のLUNを用意すること。
  • ポート設定においては図を参考に冗長性のある接続をしましょう。パス認識がストレージ側及びサーバ側のマルチパス接続でも検知されません。そのくらいシビアです。余談ですが問題が発生した際現地の作業員に指示をだすときも楽です。
  • ホスト設定はWWWNを表示するツールばない場合はMIB情報を参照するといいです。例えば富士通であったらIRMC、IBMであったらIMMです。
  • サーバとストレージ間のFC接続は、SPFモジュールを買い忘れる確率が高いので気を付けて!
  • サーバ側にマルチパスドライバのユーティリティをインストールすると、サーバ側でできている2パスを一つに束ねてくれます。Windowsでいったらmpioの設定を勝手に行ってくれるわけですね。

ac.png
ストレージの管理からの設定になると思いますがこの図の構成であれば2パスの定義ですね。
(CM#0 CA#0 PORT#0)
(CM#1 CA#0 PORT#1)

WSFCインストールのチェックと補足

  • コンポーネントの追加より
  • 最新のパッチもネットで調べて適用しましょう。困ったときは重要かもしれません。

ディスクのマウントと初期化のチェックと補足

  • ディスクのオンライン=ActiveとStanbyサーバ両機でオンラインにしておく
  • 初期化(NTFS)とドライブレター割り当て=Active側で行う

クラスタ「構成検証」ウイザードのチェックと補足

  • 共有ドライブを使用する際、MPIOのところがNGになった場合クラスタは組めません。マルチパスドライバユーティリティで必ず複数パスが束ねられていることを確認してください。
  • 警告は推奨されていない構成であるので潰しましょう。無視できる理由がある場合以外を除いて。 

「クラスタ作成」ウイザードのチェックと補足

  • 管理アクセスポイントをここで作成します。管理用の仮想IPと仮想ホスト名とQuarum領域を定義します。
  • 「使用可能な記憶域はすべて追加する」をチェックすること。勝手に共有領域を登録してくれるのと、共有ドライブクラスタ保護の観点から必須です。


役割の追加(クライアントアクセスポイントを作成する)

ここはポイントなので長文解説しますね。
「クライアントアクセスポイント」とは(IPリソース)と(ホスト名リソース)の組み合わせで構成された業務接続する際のアクセスポイントと言う事になります。何度もいってますが、提供するミドルウェアやサービスごとに作成することも可能ですが、ここではクライアントアクセスポイントは一つだけ作成して、その配下に「共有ディスク」「ファイルサービス」「ミドルウェア」を登録しています。
 

①まずはじめに、「ファイルサーバーリソース」を登録する際に「クライアントアクセスポイント」を作成します。ファイルサーバーが利用する共有ディスク(記憶域)を選択しますよ。

たくさんクライアントアクセスポイントを作れる人はこの方法でいいんですが、なんとなくしっくりこないですね。やっぱり「クライアントアクセスポイント」をまず作ってから、ぶら下げるようにリソースを追加したい...そんな人は以下の手段で作成できるとおもいます。
「役割」-「空の役割を作成」-(右クリックメニュー)-「リソースの追加」-「クライアントアクセスポイント」

ここの設定で失敗しても削除してやり直せばいいのでガンガン作って消してイメージ掴んじゃいましょう!:smirk_cat:


②次にクライアントアクセスポイントが作成されたら、配下にHULFTサービスを追加します。手順はクライアントアクセスポイントを右クリックして「リソースの追加」-「汎用サービス」でHULFTサービスを選択します。ここでも同様にHULFTのデータ集配信で共有利用する共有ディスクを選択しますよ。

あ、「クライアントアクセスポイント」って書くの面倒なので"CAP"って省略させてください。ごめんなさい。:sob:
このCAP配下に登録された書くリソースは、CAPがActiveサーバからStanbyサーバへフェイルオーバされた場合、すべて一緒に移動されます。Active×Stanbyの2台構成であれば何も考えなくていいですが3台構成で各サーバごとに提供するサービスが違う場合、リソースごとにCAPを作り、その配下でリソースを動作させてくださいね。当然「共有ディスク」を使うのであれば、複数サーバからマウントはできないためそれぞれにLUNを用意するなどストレージ設計をしてください。

※ここで例としてあげているミドルウェア製品「HULFT」のクラスタ化は「汎用サービス」で行っています。必ずクラスタ化するための手段がメーカーから提示されていて、その手段に従いクラスタ化してください。
クラスタ対応してないのに無理してやるのは、ミドルウェアの改竄を無理してやっていることと同じです。昔どつぼにハマった末に出した結論です。:dizzy_face:

構築の話は以上です。問題なく構築できましたでしょうか。できなかった場合は以下記述にヒントがあればいいのですが。。
 

構築時に発生した事象

クライアントアクセスポイントが登録できない
「イベントID:1055,1222,10028」がログされていて、だいたいの内容としては、コンピューターアカウントオブジェクトに対する更新処理が拒否されホスト名リソースのオンライン処理に失敗しているようです。
いろいろ試した結果、ADの「コンピュータオブジェクト」に、先に登録されている「管理アクセスポイントのホスト名」に適切な権限が付与されていない場合におきるようです。管理アクセスポイントを登録するまでは問題なかったのですが、いざCAPを登録するときに拒否されます。おそらくADの問題で、ネットワークが遅かったり、ADのサイトリンクコストの間隔により30分経過しても解決しない場合があります。したがってADの管理者との連携が発生するかもしれません。ちなみに自宅の仮想環境では10回やって1度も再現しなかったです。(そんなこんなであきらめて翌日に再確認したところ成功しました。夜も寝れないくらい不安だったw
 

フェイルオーバテスト手順

まあここらへんのテスト概念はご存じだと思われますが言葉や操作方法がよく分からないんですよ。なので以下の流れでフェイルオーバを実施するといいですよ。これで正しいはず(クレームは無しで):smirk:

「CAPとその配下のリソースをフェイルオーバする場合」
ツリー ⇒役割 ⇒表示されているCAPを右クリック ⇒移動 ⇒ノードの選択 ⇒移動先サーバ選択。
 

「管理アクセスポイントをフェイルオーバする場合」
ツリー ⇒管理アクセスポイントを右クリック ⇒他のタスク ⇒コアクラスタリソースの移動 ⇒ノードの選択 ⇒移動先サーバを選択。

 

まとめ

OSの機能としてライセンスも不要なWSFCはプロパティに設定されている初期値が、マイクロソフトさんのMSCS時代から蓄積したクラスタウェア設計思想が反映されていて、とても秀逸なものです。

しかしながら、世にはあまり構築やトラブルシューティングに関する情報はありません。MSの販促は何をしているのでしょうか。

たかがクラスタソフトです。
がんがんぶっ壊してがんがん作りこんでいじり倒しましょう。(構築期間中だけねw)

 

出血大サービスおまけ(保守用クラスタリソース停止起動バッチ)

WSFCはPowerShellでしか制御できません。ここではバッチの中でしか生きられない人(私)のために運用に関するバッチを載せておきますね。
読まれた方はたまにはイイねくださいね。私のような稼ぐこともできない慈善でやっているブロガーはモチベーションあげるのが大変なんでね:thinking:


-----------------
wsfc_stop.bat
-----------------
#

ECHO OFF

set OutPath=c:\windows\cluster\reports

DATE /T >%OutPath%OfflineOut.LOG

TIME /T >>%OutPath%OfflineOut.LOG


REM WSFC Service STOP

PowerShell -Command Stop-ClusterResource 'クラスタリソースの名前' -Wait 600 >>%OutPath%OfflineOut.LOG

IF %ERRORLEVEL% == 0 (echo "クラスタリソースの名前 Service STOP" >>OutPath%OfflineOut.LOG)

EXIT 


----------------------------------
wsfc_start.bat
----------------------------------

ECHO OFF

set OutPath=c:\windows\cluster\reports

DATE /T >%OutPath%OnlineOut.LOG

TIME /T >>%OutPath%OnlineOut.LOG
 

REM WSFC Service START

PowerShell -Command Stop-ClusterResource 'クラスタリソースの名前' -Wait 600 >>%OutPath%OnlineOut.LOG

IF %ERRORLEVEL% == 0 (echo "クラスタリソースの名前 Service STOP" >>OutPath%OnlineOut.LOG)

EXIT


網掛けの箇所は以下を参考にして変更してください。


保守メンテ時に使用するであろうPowershellコマンドレットリファレンス

コマンドレット

解説

用途

Start-Cluster

すべてのノードのクラスター サービスを開始

クラスタレベルでの保守

Start-ClusterGroup

クライアントアクセスポイントを開始

クライアントアクセスポイント/管理アクセスポイントレベルでの保守

Start-ClusterNode

対象ノードのクラスター サービスを開始

対象ノードレベルでの保守

Start-ClusterResource

ミドルウェアなどのサービスリソースを開始

ミドルウェアレベルでの保守

top-Cluster

対象ノードすべてのクラスタサービスを停止

クラスタレベルでの保守

Stop-ClusterGroup

クライアントアクセスポイントを停止

クライアントアクセスポイント/管理アクセスポイントレベルでの保守

Stop-ClusterNode

対象ノードのクラスター サービスを停止

対象ノードレベルでの保守

Stop-ClusterResource

ミドルウェアなどのサービスリソースを停止

ミドルウェアレベルでの保守



それではさいならさいならさいなら〜





🌟ちょっとでもあなたの仕事の役に立つページであったなら、ここをクリックしてくれるとまた頑張れるんだ。




このエントリーをはてなブックマークに追加 mixiチェック Clip to Evernote

おれのライフキーパーになってくれないか

CLUSTERPROでだいぶ飯を食ってきた私。ここへきて案件でLifeKeeperでHAする機会がありました。こういう製品構築ってのはすぐ忘れちゃうから、クラスタ構築案件あれば手伝わせてくださいw

なんてことで、サクッと手順洗い出しの検証はしておきたいと思うのは私だけではないはず。以前は「どんな目的で使うの?買ってくれるんだよね」的なものがあったりして敷居が高かったんですが、完全にトライアル版のダウンロードができるようになりました。これで現場でおろおろすることもないでしょう。まあ一番の肝であるマルチデバイスパスとかDBの検証は、検証環境ではできなそうですけど、共有ドライブの引き継ぎ確認などはiSCSIで接続してマウントポイント・・とかで検証できそうですね。
http://sios.jp/bcp/lkv9/trial/
この評価版に添付のガイドも秀逸なんで誰でもサクッと始められます。
んじゃそのガイドみればいいじゃん!って思うかもしれませんが、GUI操作の説明しかないため、コマンドでフェイルオーバーしたいとおもいますよね?

評価版のガイドに従い、httpdを保護リソースとしてクラスタリングを作成しております。 

フェイルオーバー(フェイルバック)のコマンドリファレンス

・実行する際はクラスタスタンバイ側でキックしてくださいね。そいえばコマンドにリストアって書いてありますね。
・rootでやらないと失敗しますよ。sudoでできたっけか?まあ失敗しても怖くないから
・コマンドの書式は
$ perform_action -t apache-etc.httpd -a restore
そうですね、「apache-etc.httpd」がターゲットリソース名です。複数あるリソースの中で何故これか?
まあ、どれを指定しても依存関係によって順番で落としてくれるみたいなんですが、どこの有識者に確認しても、最初に落とすべきリソースを指定するらしいです。
このマニュアルでいう依存関係の順番でいうと、
レプリケーションを停止⇒ドライブマウント解除⇒VIP解放⇒apache停止
の流れになります。まあ安全にリソースを停止するという意味では辻褄はあっていますね。
フェイルオーバー先で再開する際も、
レプリケーション開始⇒マウント⇒VIP付け替え⇒apache開始
という流れになります。

それではさっそく実施してみましょう。

sub.failover_start
[root@lk01 ~]# perform_action -t apache-etc.httpd -a restore
BEGIN restore of "datarep-DR"
/dev/sda2 is configured to be mirrored using /dev/md0
/dev/md0: merging bitmap from target "lk02"
/dev/md0: bitmap merged, resyncing 0.0 B
Partial resynchronization of component "/dev/nbd1" has begun for mirror "/dev/md0"
END successful restore of "datarep-DR"
BEGIN restore of /mnt/DR
"fsck"ing file system /mnt/DR 
fsck.ext4 -y /dev/md0 
e2fsck 1.41.12 (17-May-2010)
/dev/md0: clean, 13/327680 files, 55902/1310720 blocks
mounting file system /mnt/DR 
mount -text4 -orw,barrier=0 /dev/md0 /mnt/DR 
File system /mnt/DR has been successfully mounted. 
END successful restore of /mnt/DR
BEGIN restore of "ip-192.168.33.100"
END successful restore of "ip-192.168.33.100"
LifeKeeper: RESTORE: APACHE: RESTORING apache-etc.httpd TO SERVICE START AT:
    2016年 6月 8日 水曜日 17:12:45 JST
httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.33.11 for ServerName
LifeKeeper: RESTORE APACHE RESOURCE apache-etc.httpd END err=0 AT:
    2016年 6月 8日 水曜日 17:12:48 JST

おまけでステータスチェック方法も載せます。
実行しているサーバ上のSTATE欄で各クラスタリソースがISP(起動)/OSU(停止)であることを確認するわけですね。

sub.cluster_status_check
[root@lk01 ~]# lcdstatus -q
LOCAL    TAG                 ID                                        STATE     PRIO  PRIMARY
lk01     apache-etc.httpd    apache-etc.httpd                          ISP          1  lk01
lk01      ip-192.168.33.100  IP-192.168.33.100                         ISP          1  lk01
lk01       /mnt/DR           /mnt/DR                                   ISP          1  lk01
lk01        datarep-DR       SATA_VBOX_HARDDISK_VBd61b7a23-183fb23c-2  ISP          1  lk01

MACHINE  NETWORK ADDRESSES/DEVICE             STATE     PRIO
lk02     TCP     192.168.33.11/192.168.33.12  ALIVE        1
lk02     TCP     172.16.0.11/172.16.0.12      ALIVE        2

あ、どうせならログの場所なんかも載せましょうかね~
何が便利かというと、このフェイルオーバコマンドを実行している側では画面に状況が表示されるのですが、実行していない側ではよくわからないので、裏の動きを見たいよねってだけなんですがね。

sub.status_log
[root@lk01 ~]# tail -f /var/log/lifekeeper.log

これを仕込んでおけばリアルタイムで画面上でログ確認できますね。 

それでは、さいなら、さいなら

🌟ちょっとでもあなたの仕事の役に立つページであったなら、ここをクリックしてくれるとまた頑張れるんだ。




 

このエントリーをはてなブックマークに追加 mixiチェック Clip to Evernote

↑このページのトップヘ