TURNING POINT 
※本記事は上記ドキュメントをベースに構成しています。
CLUSTERPRO構築備忘録①～NEC CLUSTERPRO X とは～
CLUSTERPRO構築備忘録②～CLUSTERPRO X インストール手順～
Contents
前提条件の確認
Cluster WebUI、そして WebManager と builder を使用してクラスタを作成していきますが、WebManager と builder は Java アプレットのため JRE が必要です。インストールしておきましょう。JRE のダウンロードはここから。オンライン版でもオフライン版でも問題ありません。
Java 実行環境 WebManagerを使用する場合には、Java実行環境が必要です。
- Java(TM) Runtime Environment Version9.0 (9.0.4） 以降
- Java(TM) Runtime Environment Version8.0 Update 162(1.8.0_162) 以降
※WebManagerで使用するJavaの注意点
x64のマシン上でWebManagerを動作させるには32bit用のJava実行環境(JRE)を使用する必要があります。最新情報はCLUSTERPROのWebサイトを参照してください。
上記注意事項より、JRE は x64 マシンだろうが x64 ブラウザだろうが、32bit 版をインストールしてください。
例えば今回はクラスタサーバ自身(Win2016)に JRE をインストールして設定を進めていきますが、64bit 版 JRE をインストールした場合、WebManager が白くなります。これは JRE インストール前と同じ現象です。つまり 64bit 版の JRE をインストールしても意味ないです。
JRE無しだと WebManager が機能しない
JRE 64bit版をインストールしている場合も同様
Cluster Manager のポート番号について
そもそも「Cluster Manager」って何？と思った方は結構鋭いと思います。「Cluster Manager」という単語はスタートアップガイドにもインストール&設定ガイドにも登場しませんし、PPガイド (Oracle® Database)にも何も説明はありませんが、Cluster WebUI、WebManager、builder の総称だと思ってください。
実際 CLUSTERPRO X をインストールするとデスクトップに「Cluster Manager」というリンクファイルが作成されますが、実行してみると「http://localhost:29003/」(つまりClusterWebUI)が開くだけだったりします。
恐らくなんですが、元々は WebManager と builder の Javaアプレット組の総称として使用していたのでしょう。実際 Cluster WebUI のウィンドウのタブ名(title)は「Cluster WebUI」ですが、WebManager と builder はどちらも「Cluster Manager」です。
で、ここで紹介したいのはその Cluster Manager のポート番号です。Cluster Manager の URL は「http://IPアドレス:29003/」です。この後ろについているポート番号「29003」ですが、必ずつけてください。つけない場合はアクセスできないのでご注意を。
29003無しだとアクセス不可
IE 以外のブラウザは基本的にNGです
動作確認済みブラウザが Internet Explorer 10,11 しかない(笑)とだけあって、他のブラウザは使わないほうがいいです。例えば Firefox で WebManager を開こうとしても、開けません。問答無用で IEを使ってください。
IE だといけるが、Firefox だと WebManager(builder) が開けない
クラスタの作成
JRE の 32bit 版をインストールしたとして、実際にクラスタを作成していきます。
① IE に下記のアドレスを入力し、Cluster WebUI を起動します。
http://10.0.0.1:29003/
※まだフローティングIPの設定はしていないので、サーバ1号機の実IPアドレスにアクセスします。
② Cluster WebUI から「WebManager」をクリックします。
Java の警告が表示されるかもしれませんが、「OK」的な感じで進んでください。
③ クラスターが未構築の場合、WebManager(Builder)を起動させると下図がポップアップされます。 「クラスタ生成ウィザードを開始する」を選択してください。その後「標準版クラスタ生成ウィザードを開始する」を選択してください。
④ クラスター名を設定します。今回はデフォルトの「cluster」とします。「次へ」をクリックします。
管理IPアドレスとは管理用のフローティングIPアドレスのことです。フェイルオーバー用に用意しているフローティングIPアドレス（本記事では10.0.0.11）は使用しないでください。
もし管理IPアドレスとフェイルオーバー用フローティングIPアドレスを同じに設定してしまった場合、下図のようにフェイルオーバー用のフローティングIPアドレスが重複を原因として活性に失敗します。
管理IPアドレスとフェイルオーバー用 fip が重複するとダメ
そもそも、フェイルオーバー用のフローティングIPアドレスでも WebManager へアクセスすることは可能ですので、管理IPアドレスは特段の理由が無ければ設定しなくてもいいです。
⑤ [サーバの定義] 画面が表示されます。WebManager 起動時に URL で指定した IP ア ドレスのサーバ 1号機が一覧に登録されています。「追加」をクリックし、サーバ2号機を追加します。追加したら「OK」でウィンドウを閉じ、 「次へ」をクリックします。
初期状態
node2を追加
追加後
⑥ 使用するインタコネクトを設定し、「次へ」をクリックします。
- 優先度：上にある(数字が若い)ものがより優先度が高いです。
- 種別：ハートビート(インタコネクト)用の場合は「カーネルモード」にします。
- MDC：データミラーリング通信に使用する経路のことです。今回は共有ディスクなので「使用しない」とします。
ハートビートの送受信に使用する通信経路（インタコネクト）は、[種別] 列のセルをク リックして、[カーネルモード] を選択してください。必ず一つ以上の通信経路をインタコネクトに設定する必要があります。なるべく全ての通信経路をインタコネクトに設定してください。 なお、インタコネクトを複数設定する場合、[優先度] 列の番号が小さい通信経路が優先的にクラスタサーバ間の内部通信に使用されます。優先度を変更する場合は、[上へ]・[下へ] で通信経路の順位を変更してください。
BMC ハートビートを使用する場合、[種別] 列のセルをクリックし、[BMC] を選択してくだ さい。各サーバのセルをクリックして BMC の IP アドレスを入力してください。BMC ハートビートを使用しないサーバは、そのサーバのセルを空白にしてください。
デフォルトだとすべての NIC がインタコネクトとして選択されています。今回の場合はマネジメント用とストレージ用の NIC は除外します。
初期状態
整理後
⑦「追加」をクリックします。今回は NP 解決用に共有パーティションと ping 装置(PC) を用意しているので、DISK に (H:)ドライブを設定し、ping に 10.0.0.254 を設定します。「次へ」をクリックします。
初期状態
追加後
⑧ フェイルオーバーグループは後で作成するため、ここでは「次へ」をクリックします。
⑨ モニタリソースも同じく後で作成するため、そのまま「完了」をクリックします。
監視リソースとも呼ばれます。要はフェイルオーバを発生させるためのトリガーです。例えば「NIC Link Up/Down監視リソース」で NIC をモニタリングすると、NIC がダウンした際にフェイルオーバを発生させることができます。
デフォルトで存在する「userw」は数あるモニタリソースの内の1つで、「ユーザ空間」というメモリ領域を監視します。なんでこれだけデフォルトで追加されるかは謎です…笑。まあ、このくらいは最低限必要でしょみたいな感じなんですかね。
⑩ モニタリソース異常時の回復動作を抑制するか尋ねられるので、「はい」を選択します
※[いいえ] をクリックすると、モニタリソースが異常を検出しても回復動作を行わなくなります。
フェイルオーバーグループの作成
先ほど⑧でスキップしたフェイルオーバーグループを作成します。
サーバー1に異常が発生した場合、業務に必要なフェイルオーバーグループに登録された リソースをサーバー2に切り替えることにより、フェイルオーバーを実現します。
上記のように、クラスタ生成ウィザードでクラスタは構成されましたが、リソース(共有ディスクやフローティングIPアドレス)ごとのフェイルオーバ設定はまだしていません。やっていきましょう。
①「Groups」から、「グループの追加」をクリックします。
② フェイルオーバーグループ名を設定し、「次へ」をクリックします。
※今回はデフォルトの”failover”のまま進めます。
③「全てのサーバでフェイルオーバ可能」にチェックが付いていることを確認し、「次へ」をクリックします。
④ 要件に合わせて設定し、「次へ」をクリックします。
※今回はデフォルトのまま進めます。
いわゆる “フェイルオーバポリシー” です。例えばクラスタをシャットダウンしたとして、グループ起動属性が「手動」になっていた場合、サーバを起動してもフェイルオーバグループは起動しません。
CLUSTERPRO製品では、該当フェイルオーバグループのグループ起動属性で「自動起動」が設定されている場合、クラスタを開始する際に、グループが起動可能な最も優先順位の高いサーバでグループが自動的に起動します。
「手動起動」が設定されている場合、サーバが起動してもグループは起動いたしません。この場合は、サーバ起動後、WebManagerまたは [clpgrp] コマンドを使用してグループを手動で起動してください。
どういうときに調整が必要かというと、例えば「クラスタ起動時は必ず1号機がアクティブの状態にしたい場合」などです。CLUSTERPRO は起動時にどちらがアクティブになるかはフェイルオーバポリシーで設定します。ただし、「停止時にアクティブだった方が起動時にアクティブになる」という動作を自動化することは不可能です。
「クラスタリブート時アクティブだったホストで自動的に起動する」という動作は不可能なのでしょうか。
恐れ入りますが、CLUSTERPRO製品の基本機能では、要件を満たす設定はございません。
ご回答いただいた内容だと、上記の動きをさせたい場合手動設定にしたうえで手動によりアクティブ側で起動するという処理になるのでしょうか。
はい、お客様ご認識の通りでございます。
⑤ リソースは後で設定するため、そのまま「完了」をクリックします。
ディスクリソースの追加
① failover グループから、「リソースの追加」をクリックします。
② タイプから「ディスクリソース」を選択し、ディスクリソース名を設定します。設定が完了したら「次へ」をクリックします。
※今回はデフォルトの”sd”のまま進めます。
③ 依存関係はデフォルトのまま、「次へ」をクリックします。
依存関係のあるリソースが活性した後に当該リソースを活性するという意味です。基本的には「既定の依存関係に従う」で OK です。
CLUSTERPRO製品の依存関係につきまして、グループリソースが活性処理および非活性処理を行なう際の順序に関係いたします。対象のリソースに依存関係となるリソースがある場合、対象リソースの深度が下がり依存関係のリソースが活性した後に、対象リソースの活性処理が行なわれます。非活性処理の場合、対象リソースの非活性処理を行なった後に依存関係となるリソースの非活性処理が行なわれます。
「既存の依存関係に従う」を有効にすると、リソースのタイプ毎に予め決められた依存関係に従って自動的に依存関係を設定することが可能となります。
④ ディスクリソースの復旧動作を選択し、「次へ」をクリックします。
※ 環境に合わせて復旧動作を設定してください。
活性異常とはリソースを活性(起動)できないことを指し、非活性異常とはリソースを非活性(停止)できないことを指します。注意点は、非活性異常に「何もしない」を設定してはいけないことです。
非活性異常検出時の最終動作に [何もしない] を選択すると、グループが非活性失敗のまま
停止しません。実際に業務で使用する際には、[何もしない] は設定しないように注意してください。
してはいけない設定がなぜ選択できるのかというと、検証用ですね。
上記選択肢は「実業務では設定しないように」とあるように、検証環境での利用を想定されているのでしょうか。
はい、お客様ご認識の通りです。
⑤ ドライブ文字を設定します。ドライブ文字の設定は下記手順で行います。
- node1を選択し、追加をクリックします。
- 情報取得フィールドの「接続」をクリックします。
- 切替パーティション（データパーティション）用ドライブを選択します。
- OKをクリックします。
- node2を選択し、追加をクリックします。
- node1で選択したドライブ文字と同じドライブ文字を選択します。
- OKをクリックします。
「接続」するとそのサーバの全てのドライブが表示されます
ノード2台でドライブ1つの場合こんな感じになります
フローティングIPリソースの追加
① failover グループから、「リソースの追加」をクリックします。
② タイプから「フローティングIPリソース」を選択し、fip名リソース名を設定します。設定が完了したら「次へ」をクリックします。
※今回はデフォルトの”fip”のまま進めます。
③ 依存関係はデフォルトのまま、「次へ」をクリックします。
④ fipリソースの復旧動作を設定し、「次へ」をクリックします。
※ 環境に合わせて復旧動作を設定してください。
⑤ 使用するfipのアドレスを入力します。入力が完了したら「完了」をクリックし、fip リソースの設定は終了です。
設定の保存
先ほどから設定を行っていますが、この段階ではまだ設定は反映されていませんし、保存もされていません。例えば現時点でウィンドを閉じてしまうと、設定を最初からやり直さなければなりません。
構成後、未反映の状態
ウィンドウを閉じた後、設定は消えている
設定を反映(保存)するには「ファイル」-「設定の反映」をクリックします。
以上で基本的な設定は完了です。
Cluster WebUI の画面に戻ると下図のように全て「正常」となっているはずです。
※もし下図のようになっていなかった場合、「ステータス」からクラスター開始をクリックしてください。
グループリソースは node1が持っており、node2 は CLUSTERPRO Server サービスは動作している(サーバに入って “services.msc” で実際に確認できます)がリソースは持っていない(停止している)状態です。これが正常な状態なので、この状態を覚えておきましょう。
CLUSTERPRO インストール後のディスク
フェイルオーバーグループを作成したことにより、共有ボリュームが CLUSTERPRO により適切に制御されているはずです。
アクティブ側
スタンバイ側
アクティブ側データパーティション
スタンバイ側データパーティション
アクティブ側NP解決用パーティション
スタンバイ側NP解決用パーティション
スタンバイ側では共有ボリュームには全てアクセス不可、アクティブ側はデータパーティションに対してはアクセス可という状態です。
パスワードの設定
Cluster WebUI や WebManager では当然ながらクラスタのシャットダウンやサーバのシャットダウンなどが実施できます。にもかかわらず、インストール時やクラスタ構築時にパスワード設定というものがありません。
つまり、ネットワーク的に疎通があり CLUSTERPRO サーバの実IP もしくはフローティングIP とポート番号を知っていれば誰でも操作できます。
Cluster WebUI / WebManager /builder ではパスワードの設定が可能なので、早めにやっておきましょう。
まずは builder からクラスタ名（本記事では cluster）を右クリックし、「プロパティ」を開きます。
「WebManager」タブ「パスワードによって接続を制御する」の「設定」をクリックします。
「操作用パスワード」と「参照用パスワード」それぞれに異なるパスワードを設定します。
2つのモードそれぞれにパスワードを設定可能
初回は”古いパスワード”入力不要（これセンスないからやめてほしい）
設定後に「ファイル」-「設定の反映」を実行するのを忘れないでください。設定反映後、ブラウザを再起動すると下図のようになります。builder で設定しましたが、きちんと Cluster WebUI でもパスワードを聞いてきます。
Cluster WebUI にも反映される
とりあえず参照専用でログイン
参照専用でログインできたので、次は WebManager を確認してみます。
“参照専用”でログイン成功
WebManager で再入力する必要あり（これもセンスないからやめてほしい）
面倒なのが、Cluster WebUI でパスワードを入力したにも関わらず、WebManager でもパスワードが聞かれることです。これは参照専用で Cluster WebUI にログインしたからではなく、操作可能でも同じです。
参照専用でログインしている状態で設定モードに移行しようとすると、当然「操作可能」権限のパスワードが聞かれます。
下図は参照専用でログインした場合の Cluster WebUI「ステータス」画面ですが、サーバのシャットダウンや再起動ができそうな雰囲気があります。実際に node2 をシャットダウンできるか試してみます。
「サーバ通信時に認証エラーが発生しました」となりシャットダウンできませんでした。安心なことに、参照専用ではクラスタ/サーバの操作はできません。
勿論、操作可能権限であればサーバのシャットダウンは可能です。
操作可能であれば操作可能!
次回は現時点でのフェイルオーバーのテストをやってみます。
