Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-01 |
|
前 |
次 |
このエンタープライズ・トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。このためには、bi_server1管理対象サーバーが障害発生時にAPPHOST2上で再起動されるように構成し、bi_server2管理対象サーバーが障害発生時にAPPHOST1上で再起動されるように構成します。このような構成では、bi_server1サーバーおよびbi_server2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
重要: セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
この章は、次の項で構成されています。
ステップ1では、サーバー移行リース・テーブルのユーザーと表領域を設定します。
leasingという表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。
SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
leasingという名前のユーザーを作成し、leasing表領域に割り当てます。
SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
leasing.ddlスクリプトを使用してleasing表を作成します。
WL_HOME/server/db/oracle/817またはWL_HOME/server/db/oracle/920のいずれかのディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
leasingユーザーとしてデータベースに接続します。
leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @Copy_Location/leasing.ddl;
ステップ2では、Oracle WebLogic Server管理コンソールからleasing表のマルチ・データソースを作成する方法について説明します。マルチ・データソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータソースを、これらのデータソースとグローバルleasingマルチ・データソースの両方について作成します。データソースを作成する際は、次の考慮事項に留意してください。
このデータソースが、XAデータソースではないことを確認してください。
マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データソースは、グローバル・トランザクションのサポートを必要としません。したがって、データソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」サブオプションを選択しない)で、データベースのサービス名を指定します。
これらのデータソースをbi_clusterにターゲット指定します。
データソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」を選択し、「データ・ソース」を選択します。「データ・ソース」リストでデータソースの名前をクリックし、「接続プール」タブをクリックして「初期容量」フィールドに0(ゼロ)を入力します。
マルチ・データ・ソースの作成
マルチ・データソースを作成するには、次の手順を実行します。
管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックし、「マルチ・データ・ソース」を選択します。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
「名前」には、leasing
と入力します。
「JNDI名」には、jdbc/leasing
と入力します。
「アルゴリズムのタイプ」では、「フェイルオーバー」(デフォルト)を選択します。
「次へ」をクリックします。
「ターゲットの選択」ページで、ターゲットとして「bi_cluster」を選択します。
「次へ」をクリックします。
「データ・ソースのタイプを選択」ページで、「非XAドライバ」(デフォルト)を選択します。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
「名前」には、leasing-rac0
と入力します。「JNDI名」には、jdbc/leasing-rac0
と入力します。「データベース・タイプ」では、「Oracle」を選択します。
注意: leasing表のマルチ・データソースを作成する場合、名前は<MultiDS>-rac0、<MultiDS>-rac1という形式で入力します。 |
「次へ」をクリックします。
「データベース・ドライバ」では、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10以降を選択します。
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
leasingスキーマの詳細を次のように入力します。
サービス名: データベースのサービス名を入力します。
データベース名: Oracle RACデータベースの最初のインスタンスのインスタンス名を入力します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、最初のインスタンスのVIP名またはノード名をホスト名として指定します。
ポート: データベースのポート番号(1521
)を入力します。
データベース・ユーザー名: leasing
と入力します。
パスワード: leasingのパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。
「次へ」をクリックします。
「ターゲットの選択」ページで、ターゲットとして「bi_cluster」を選択します。
「終了」をクリックします。
Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをbi_clusterに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
「データ・ソースの追加」ページで、leasing-rac0とleasing-rac1を「選択済み」リストに移動することによって、それらをデータソースに追加します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
ステップ3では、ノード・マネージャと管理サーバー間でのホスト名検証に使用する適切な証明書を作成します。この手順の詳細は、第7.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。まだ証明書を作成していない場合は、この項の手順を実行して、ノード・マネージャと管理サーバー間でのホスト名検証に使用する証明書を作成します。
サーバー移行の構成のステップ4では、ノード・マネージャのプロパティ・ファイルを編集します。このタスクは、サーバー移行を構成する両方のノードのノード・マネージャで実行する必要があります。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface: このプロパティは、浮動IPのインタフェース名(たとえば、eth0)を指定します。
サブインタフェース(eth0:1
、eth0:2
など)を指定しないでください。このインタフェースは、:0
または:1
なしに使用されます。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。
NetMask: このプロパティは浮動IP用インタフェースのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。このドキュメントの例では、255.255.255.0を使用します。
UseMACBroadcast: このプロパティは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、言い換えれば、arping
コマンドで-b
フラグを使用するかどうかを指定します。
ノード・マネージャの出力(ノード・マネージャを起動するシェル)で、これらのプロパティが使用されていることを確認してください。使用されていない場合は、移行中に問題が発生することがあります。ノード・マネージャの出力には次のような行が含まれます。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
注意: サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。 |
nodemanager.propertiesファイルで次のプロパティを設定します。
StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。
APPHOST1とAPPHOST2で、WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、ノード・マネージャを起動します。
注意: 共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動されます。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、HOSTnで別のインタフェース(eth3)を使用するには、Interface環境変数を次のように使用します。HOSTn> export JAVA_OPTIONS=-DInterface=eth3 この変数がシェル内で設定された後、ノード・マネージャを起動します。 |
サーバー移行のステップ5では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。
PATH環境変数に次のファイルが含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限の付与
パスワードの要求がなくても動作するようにsudoを構成します。
セキュリティ上の理由から、sudoを wlsifconfig.sh スクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
WebLogicユーザー(oracle)に、パスワードなしのsudo権限を付与し、/sbin/ifconfigと/sbin/arpingのバイナリの実行権限を付与します。
スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。/etc/sudoers内の次のエントリ例では、oracle
のsudo実行権限を、ifconfig
とarping
に対しても付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。 |
ステップ6では、サーバー移行ターゲットを構成します。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。次の手順に従って、クラスタ内の移行でクラスタ移行を構成します。
管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
移行を構成する対象となるクラスタ(bi_cluster)を、表の「名前」列でクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、leasingデータソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補マシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
ヒント: サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。 |
移行を構成するサーバーをクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「移行の構成」セクションの「候補マシン」で移行を有効にするマシンを選択し、右矢印ボタンをクリックします。bi_server1の場合はAPPHOST2を選択します。bi_server2の場合はAPPHOST1を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバー、ノード・マネージャ、管理対象サーバーおよびサーバー移行が構成されているシステム・コンポーネントを再起動します。
最後のステップ8は、サーバー移行をテストします。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。
APPHOST1から:
bi_server1管理対象サーバーを停止します。そのためには、次のコマンドを実行します。
APPHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
HOST1> ps -ef | grep bi_server1
ノード・マネージャのコンソールを確認します。bi_server1の浮動IPが無効になっていることを示すメッセージが表示されます。
ノード・マネージャがbi_server1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
APPHOST2から:
ローカルのノード・マネージャのコンソールを確認します。ノード1でbi_server1の再起動が最後に試行されてから30秒経過した後、ノード2のノード・マネージャによって、bi_server1の浮動IPが有効化されようとしていること、およびこのノードでサーバーが再起動されようとしていることが示されます。
同じIPを使用していずれかのアプリケーション(BI Publisherなど)にアクセスします。
管理コンソールからの検証
移行は次のように管理コンソールで確認することもできます。
管理コンソールにログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
図8-1に示すように、「移行の状態」表に移行の状態に関する情報が表示されます。
注意: サーバーの移行後、そのサーバーを元のノード/コンピュータにフェイルオーバーするには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたコンピュータ上の管理対象サーバーを起動します。 |