| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド リリース12.2.1 E70049-02 |
|
 前 |
 次 |
uploadディレクトリとstageディレクトリを検証および更新します。ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次に、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。
前提:
管理サーバーを、localhostまたは任意のアドレスではなく、ADMINVHN上でリスニングするように構成します。
ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。
この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。
管理サーバーはWCCHOST1からWCCHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
WCCHOST1: 100.200.140.165
WCCHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、WCCHOST1およびWCCHOST2からアクセスできます。
Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、WCCHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。
次の手順は、管理サーバーを別のノード(WCCHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。
この手順では、エンタープライズ・トポロジでドメインごとのノード・マネージャを構成していると仮定しています。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください
管理サーバーを別のホストにフェイルオーバーするには:
管理サーバーを停止します。
管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。
ADMINVHN仮想IPアドレスを第2ホストに移行します。
WCCHOST1上で次のコマンドをroot権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースになります)。
/sbin/ifconfig ethX:Y down
WCCHOST2で次のコマンドをルートとして実行します。
/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>
次に例を示します。
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
注意:
使用するネットマスクとインタフェースは、WCCHOST2で使用可能なネットワーク構成と一致している必要があります。
次の例のように、arpingを使用してルーティング表を更新します。
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
WCCHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
WCCHOST2上で管理サーバーを起動します。
次の方法でWCCHOST2上の管理サーバーにアクセスできることをテストします。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/console
次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。
http://ADMINVHN:7001/em
管理サーバーの手動フェイルオーバーを実行したら、標準管理URLを使用して管理サーバーにアクセスできることを確認することが重要です。
ロード・バランサから、次のURLにアクセスして、管理サーバーがWCCHOST2で実行しているときにアクセスできることを確認します。
http://admin.example.com/console
このURLではWebLogic Server管理コンソールが表示されます。
http://admin.example.com/em
このURLでは、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。
この項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を説明します。
注意:
この手順は、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。
エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。
この項では、WCCHOST1に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。
キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、WCCHOST2では、WCCHOST1の証明書用に作成されたcertディレクトリを使用します。
かわりに信頼できるCA証明書を使用する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する情報を参照してください。
パスワードについて
このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。
自己署名証明書を作成する手順は次のとおりです。
この項では、WCCHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。
前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、WCCHOST1とADMINVHN両方の証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
注意:
アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。
SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。
あるいは、setUserOverrides.shファイルを使用して、これらのオプションを配置できます。この方法では、ドメインのスクリプトが構成ウィザードによって拡張されたり、解凍操作によって更新されたりする場合にも、これらのオプションは上書きされません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。
カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内のASERVER_HOME/nodemanagerディレクトリとMSERVER_HOME/nodemanagerディレクトリの両方にあるnodemanager.propertiesファイルの最後に次の行を追加します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity KeyStore CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd CustomIdentityAlias=Identity Key Store Alias CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate
ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、WCCHOST1では、「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従って、appIdentity2を使用します
(appIdentity2 mapped to the WCCHOST1 listen address). Example for Node 1: KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=password CustomIdentityAlias=appIdentity1 CustomIdentityPrivateKeyPassPhrase=password
「WCCHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。
IDキーストアおよび信頼キーストアを構成するには:
この項では、特定の管理ロールを持つ製品の概要を提供して、エンタープライズ・デプロイメント管理グループに製品固有の管理ロールを追加する手順を説明します。
各エンタープライズ・デプロイメントは複数の製品で構成されます。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。
ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、「新規LDAP認可プロバイダの作成およびエンタープライズ・デプロイメントの新しいユーザーとグループのプロビジョニング」を参照してください。
単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。
詳細な情報は、次のトピックを参照してください
次の表に、エンタープライズ・デプロイメントの管理グループ(WCCAdministrators)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します(この管理グループは、エンタープライズ・デプロイメントのLDAP認可プロバイダで定義したものです)。
次の表にある情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
| 製品 | アプリケーション・ストライプ | 割り当てる管理ロール |
|---|---|---|
Oracle Web Services Manager。 |
wsm-pm |
policy.updater |
SOAインフラストラクチャ |
soa-infra |
SOAAdmin |
ここでは、トランザクション・ログ(TLOG)とJMSのためにJDBC永続ストアをいつ使用するかについてガイドラインを示します。サポートされるデータベースに永続ストアを構成するために使用できる手順も説明します。
Oracle Fusion Middlewareは、Oracle WebLogic Serverトランザクション・ログ(TLOG)およびJMSのために、データベースベースとファイルベース両方の永続ストアをサポートします。環境の永続ストア戦略を決定する前に、各アプローチのメリットとデメリットを検討してください。
注意:
選択する記憶域のタイプにかかわらず、トランザクションの整合性と一貫性を保つためにJMSとTLOGで同じタイプのストアを使用することをお薦めします。
OracleデータベースでTLOGおよびJMSデータを格納すると、データベースのレプリケーションや高可用性の機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡略化できます。これは、障害時リカバリ構成にOracle Fusion Middlewareをデプロイしている場合に特に重要です。
また、TLOGおよびJMSデータをデータベースに格納すると、そのデータについて共有記憶域内の特定の場所を指定する必要がありません。ただし、エンタープライズ・デプロイメントの他の観点からも共有記憶域が必要であることに注意してください。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポート)、デプロイメント・プラン、およびアダプタ・アーティファクト(ファイル/FTPアダプタの制御ファイルおよび処理済ファイル)でも必要です。
TLOGおよびJMSストアを共有記憶域デバイスに格納する場合は、適切なレプリケーションおよびバックアップ戦略を使用してデータを保護し、データ損失ゼロを保証できます。また、システム・パフォーマンスを潜在的に向上することができます。ただし、ファイル・システムの保護機能はOracle Databaseによって提供される保護機能ほど優れていません。
データベースベースのTLOGおよびJMSストアの使用によるパフォーマンスへの潜在的な影響の詳細は、「TLOGおよびJMS永続ストアのパフォーマンスへの影響」を参照してください。
トランザクション・ログとJMSの永続ストアの格納方法を選択する際の重要な考慮事項の1つは、パフォーマンスに対する潜在的な影響です。ここでは、TLOGおよびJMSのJDBC永続ストアの使用によるパフォーマンスの影響を判別するために役立つガイドラインと詳細情報を説明します。
トランザクション・ログおよびJMSストアのパフォーマンスへの影響
トランザクション・ログの場合、ログの性質から非常に一過性が高いため、JDBCストア使用の影響は相対的にわずかです。一般的に、システムの他のデータベース操作と比べると影響は最小です。
一方、JMSデータベース・ストアは、アプリケーションでのJMS使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。
パフォーマンスに影響する要因
JMS DBストアをカスタム宛先で使用するとき、システムのパフォーマンスに影響する要因は複数あります。主なものを次に示します。
関連するカスタム宛先とそのタイプ
永続化するペイロード
SOAシステムでの同時実行性(宛先のコンシューマに対するプロデューサ)
前述のそれぞれの影響の程度に応じて、パフォーマンスを改善するために次に関して様々な設定を構成できます。
JMS表で使用されるデータ型(RAWまたはLOBの使用)
JMS表のセグメント定義(索引および表レベルのパーティション)
JMSトピックの影響
ご使用のシステムがトピックを集中的に使用すると、同時実行性が高くなるにつれて、Oracle RACデータベースでのパフォーマンス低下はキューの場合よりも大きくなります。JMSを使用するOracleで行ったテストでは、様々なペイロード・サイズと様々な同時実行性での平均パフォーマンス低下はキューの場合は30%未満でした。トピックの場合、影響は40%を超えました。データベース・ストアを使用するかどうかを決めるときには、リカバリの観点からこのような宛先の重要性を検討してください。
データ型とペイロード・サイズの影響
ペイロードで使用するためにRAWデータ型またはSecureFiles LOBデータ型を選択するときは、永続化するペイロードのサイズを考慮します。たとえば、ペイロード・サイズが100バイトから20KBまでの場合、SecureFiles LOBで必要なデータベース時間はRAWデータ型の場合よりも少し長くなります。
具体的には、ペイロード・サイズが約4KBになると、SecureFilesで必要なデータベース時間が長くなります。4KBになると書込みが行の外に移動するためです。ペイロード・サイズが約20KBになると、SecureFilesデータの効率がよくなります。ペイロード・サイズが20KBを超えると、RAWデータ型に設定されたペイロードではデータベース時間が長くなります。
SecureFilesのもう1つの利点は、ペイロードが500KB以上に増加すると、発生するデータベース時間が安定することです。つまり、その時点で、データによって格納されるペイロードが500KB、1MBまたは2MBであるかは(SecureFilesにとって)関係ありません。書込みは非同期で行われ、競合はすべてのケースで同一であるためです。
キューのスループットに対する同時実行性(プロデューサとコンシューマ)の影響は、ペイロード・サイズが50KBになるまではRAWとSecureFilesで似ています。ペイロードが小さい場合は、同時実行性を変更しても影響は実質的に同じです(RAWのスケーラビリティが少し上回ります)。ペイロードが50KBを超えると、SecureFilesのスケーラビリティが高くなります。
同時実行性、ワーカー・スレッドおよびデータベース・パーティション化の影響
永続ストアに定義された同時実行性とワーカー・スレッドによって、RACデータベースの索引およびグローバル・キャッシュ・レベルで競合が発生することがあります。1つのサーバーで複数のワーカー・スレッドを有効にするときに逆索引を使用する、または複数のOracle WebLogic Serverクラスタを使用すると、逆索引を使用すると状況が改善する可能性があります。ただし、Oracle Databaseのパーティション化オプションが使用可能な場合は、索引のグローバル・ハッシュ・パーティションをかわりに使用してください。こうすると、索引の競合とグローバル・キャッシュ・バッファの待機が減少し、それによってアプリケーションのレスポンス時間が短縮されます。パーティション化はどのケースでも効果がありますが、逆索引を使用しても大きく改善されないことがあります。
JMSおよびTLOGのためのデータベースベース永続ストアを構成する前に、2つのデータ・ソース(TLOG永続ストアのために1つ、JMS永続ストアのために1つ)を作成する必要があります。
エンタープライズ・デプロイメントでは、TLOGおよびJMSストアでGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成する手順は次のとおりです。
サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。次に例を示します。
wccedg.example.com
ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。次に例を示します。
db-scan.example.com:1521
「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。
SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。
SQL>show parameter remote_listener; NAME TYPE VALUE -------------------------------------------------- remote_listener string db-scan.example.com
注意:
Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:
dbhost1-vip.mycompany.com (port 1521)
および
dbhost2-vip.mycompany.com (1521)
データベース・ユーザー名: 次のように入力します。
TLOGストアの場合はTLOG、JMS永続ストアの場合はJMSと入力します。
パスワード: データベースにユーザーを作成したときに使用したパスワードを入力します。
パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。
データベースで表領域とユーザーを作成して、データ・ソースを作成した後で、TLOG永続ストアを必須の管理対象サーバーそれぞれに割り当てることができます。
データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後で、JMS永続ストアを必須のJMSサーバーそれぞれに割り当てることができます。
この項では、Oracle WebCenter Contentエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。
注意:
この項で示す静的アーティファクトと実行時アーティファクトの一部は、Network Attached Storage (NAS)でホストされています。可能であれば、これらのボリュームをアプリケーション・サーバーからではなくNASファイラから直接バックアップおよびリカバリします。
Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。
「環境のバックアップ」
環境のリカバリに関する項
表17-1に、典型的なOracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示します。
表17-1 Oracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
| タイプ | ホスト | 層 |
|---|---|---|
データベースOracleホーム |
DBHOST1およびDBHOST2 |
データ層 |
Oracle Fusion Middleware Oracleホーム |
WEBHOST1およびWEBHOST2 |
Web層 |
Oracle Fusion Middleware Oracleホーム |
WCCHOST1およびWCCHOST2 |
アプリケーション層 |
インストール関連ファイル |
WEBHOST1、WEHOST2および共有記憶域 |
該当なし |
表17-2に、典型的なOracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクトを示します。
表17-2 Oracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクト
| タイプ | ホスト | 層 |
|---|---|---|
管理サーバーのドメイン・ホーム(ASERVER_HOME) |
WCCHOST1およびWCCHOST2 |
アプリケーション層 |
アプリケーション・ホーム(APPLICATION_HOME) |
WCCHOST1およびWCCHOST2 |
アプリケーション層 |
Oracle RACデータベース |
DBHOST1およびDBHOST2 |
データ層 |
スクリプトとカスタマイズ |
WCCHOST1およびWCCHOST2 |
アプリケーション層 |
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME) |
WCCHOST1およびWCCHOST2 |
アプリケーション層 |
ドメインを作成し、管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。
この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。
管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。
「ロックして編集」をクリックします。
「サーバー」をクリックします。
管理対象サーバー・ドメイン・ホーム・ディレクトリ内の各管理対象サーバーについて次の操作を実行します。
管理対象サーバーの名前をクリックします。
「構成」タブをクリックし、「デプロイメント」タブをクリックします。
「ステージング・ディレクトリ名」が次のように設定されていることを確認します。
MSERVER_HOME/servers/server_name/stage
MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。
管理サーバーのステージング・ディレクトリを構成する予定がある場合、プロパティを次のように設定する必要があります。
をクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。
をクリックして、ロールを編集します。
をクリックします。
ASERVER_HOME/servers/AdminServer/stage
「アップロード・ディレクトリ名」を次の値に更新します。
ASERVER_HOME/servers/AdminServer/upload
ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。
「保存」をクリックします。
「サーバーのサマリー」画面に戻ります。
各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。
すべての管理対象サーバーを再起動します。
