| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-04 |
|
前 |
次 |
この章では、Oracle Business Intelligenceエンタープライズ・デプロイメントのサーバー移行を構成する手順について説明します。
|
重要: セットアップのプロセスを開始する前に、『Oracle Fusion Middlewareリリース・ノート』に目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
この章には次のトピックが含まれます:
bi_server1とbi_server2の管理対象サーバーにサーバー移行を構成します。サーバー移行を構成しておくことで、障害が発生した場合でも、bi_server1管理対象サーバーはAPPHOST2で再起動し、bi_server2管理対象サーバーはAPPHOST1で再起動します。このような構成では、bi_server1サーバーおよびbi_server2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。
次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。
create tablespace leasingコマンドを使用して、サーバー移行リース・テーブルのユーザーおよび表領域を設定します。
サーバー移行leasing表のユーザーと表領域を設定する手順は次のとおりです。
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 password;
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表を作成します。
次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。
WL_HOME/server/db/oracle/817 WL_HOME/server/db/oracle/920
leasingユーザーとしてデータベースに接続します。
leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
Oracle WebLogic Server管理コンソールでリース・テーブルのマルチデータ・ソースを作成します。
マルチデータ・ソースの設定プロセス中に、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバル・リース・マルチデータ・ソースの両方に対して作成します。データ・ソースを作成する前に、次の準備が必要です。
非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」サブオプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをbi_clusterにターゲット指定します。
データ・ソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」を選択し、「データ・ソース」を選択します。「データ・ソース」リストでデータ・ソースの名前をクリックし、「接続プール」タブをクリックして「初期容量」フィールドに0(ゼロ)を入力します。
Oracle RACのマルチデータ・ソースの設定に関するその他の推奨事項は、『Oracle Fusion Middleware高可用性ガイド』の高可用性Oracle Databaseアクセスの考慮事項に関する項を参照してください。
マルチ・データ・ソースを作成する手順は次のとおりです。
管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「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を「選択済み」リストに移動することによって、それらをデータ・ソースに追加します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
ノード・マネージャと管理サーバー間のホスト名検証用に適切な証明書を作成します。この手順は、第10.3項「ノード・マネージャでのホスト名検証証明書の有効化」で説明されています。まだこれらの証明書を作成していない場合は、この項の手順を実行して、ノード・マネージャと管理サーバー間でホスト名を検証するための証明書を作成します。
ノード・マネージャのプロパティ・ファイルを、サーバー移行を構成する両方のノードで編集します。nodemanager.propertiesファイルは次のディレクトリにあります。
WL_HOME/common/nodemanager
次のプロパティを追加してサーバー移行が正常に動作するようにします。
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 この変数がシェル内で設定された後、ノード・マネージャを起動します。 |
wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。
表11-1に示すファイルをPATH環境変数で指定していることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限の付与
パスワードの要求がなくても動作するようにsudoを構成します。
セキュリティ上の理由から、sudo権限の付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。 |
サーバー移行ターゲットを構成します。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。
管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
移行を構成する対象となるクラスタ(bi_cluster)を、表の「名前」列でクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補マシンを設定します。次の手順を使用して、すべての管理対象サーバーに対してこのタスクを実行する必要があります。
管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
|
ヒント: サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。 |
移行を構成するサーバーをクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「移行の構成」セクションの「候補マシン」で移行を有効にするマシンを選択し、右矢印ボタンをクリックします。bi_server1の場合はAPPHOST2を選択します。bi_server2の場合はAPPHOST1を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバー、ノード・マネージャ、管理対象サーバーおよびサーバー移行が構成されているシステム・コンポーネントを再起動します。
サーバー移行が適切に機能していることを確認する手順は次のとおりです。
APPHOST1から:
bi_server1管理対象サーバーを停止します。そのためには、次のコマンドを実行します。
APPHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
APPHOST1> ps -ef | grep bi_server1
ノード・マネージャのコンソールを確認します。bi_server1の浮動IPが無効になっていることを示すメッセージが表示されます。
ノード・マネージャがbi_server1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。
APPHOST2から:
ローカルのノード・マネージャのコンソールを確認します。ノード1でbi_server1の再起動が最後に試行されてから30秒経過した後、ノード2のノード・マネージャによって、bi_server1の浮動IPが有効化されようとしていること、およびこのノードでサーバーが再起動されようとしていることが示されます。
同じIPを使用していずれかのアプリケーション(BI Publisherなど)にアクセスします。
管理コンソールからの検証
管理コンソールで移行を検証する手順は次のとおりです。
管理コンソールにログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブ→「移行」タブをクリックします。
次の図に示すとおり、「移行ステータス」表には、移行の状態に関する情報が表示されます。
|
注意: サーバーの移行後、そのサーバーを元のノード/コンピュータにフェイルバックさせるには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたコンピュータ上の管理対象サーバーを起動します。 |
