この項では、エンタープライズ・デプロイメント環境で実行する必要性が見込まれる構成および管理タスクについて説明します。
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次の各項で、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であり、仮想サブインタフェース(eth0:1など)に割り当てられており、WCCHOST1またはWCCHOST2からアクセスできます。
Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、WCPHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用して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>
注意:
索引はBIHOST2のBI Server 2の索引とは異なります。次に例を示します。
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
注意:
使用するネットマスクとインタフェースは、WCPHOST2で使用可能なネットワーク構成と一致している必要があります。
次の例のように、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にアクセスして、管理サーバーがWCPHOST2で稼働しているときにアクセスできることを確認します。
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に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。
キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。Oracleでは、別の目的で使用される証明書(HTTP呼び出し用に設定されたSSLなど)には中央または共有のストアを使用することをお薦めしています。詳細は、エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解に記載されているKEYSTORE_HOMEの場所のファイルシステム仕様に関する内容を参照してください。
かわりに信頼できるCA証明書を使用する方法は、『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のアイデンティティとトラストの構成に関する情報を参照してください。
パスワードについて
このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。
自己署名証明書を作成する手順は次のとおりです。
この項では、WCCHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。
前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、すべてのホストおよびADMINVHNに対して前に作成した証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
注意:
アイデンティティ・ストアは、utils.ImportPrivateKey
ユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。
SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。
setDomainEnv.sh
スクリプトは、Oracle WebLogic Serverによって提供され、ドメイン内の管理サーバーと管理対象サーバーの起動に使用されます。各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.sh
スクリプトを次のように編集します。カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内の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
には必ず正しい値を使用してください。たとえば、utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成の手順に従って、WCCHOST1 MSERVER_HOMEでは別名WCCHOST1を使用し、WCCHOST1上のASERVER_HOMEでは別名ADMINVHNを使用します。
Example for WCCHOST1: KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=password CustomIdentityAlias=WCCHOST1 CustomIdentityPrivateKeyPassPhrase=password
「WCCHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.properties
ファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.properties
ファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを再起動し、エントリを暗号化します。
注意:
この構成の実行後、ドメインを拡張するたびにCustomIdentityAlias
を修正する必要があります。解凍操作によって、ドメイン構成が書き込まれるときにCustomIdentityAlias
が管理サーバーの値に置き換えられます。単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理するには、特定の管理ロールまたはグループを必要とする製品を理解することに加え、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する方法を理解することが必要です。
各エンタープライズ・デプロイメントは複数の製品で構成されています。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。
ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、「新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよびグループのプロビジョニング」を参照してください。
単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。
詳細な情報は、次のトピックを参照してください
次の表に、エンタープライズ・デプロイメントの管理グループ(WCPAdministrators
)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します(この管理グループは、エンタープライズ・デプロイメントのLDAP認可プロバイダで定義したものです)。
次の表の情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。
製品 | アプリケーション・ストライプ | 割り当てられる管理ロール |
---|---|---|
Oracle Web Services Manager。 |
wsm-pm |
policy.updater |
WebCenter Portal |
webcenter |
s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator |
SOAインフラストラクチャ |
soa-infra |
SOAAdmin |
この項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用する方法のガイドライン、およびサポートされているデータベースで永続ストアを構成する手順について説明します。
Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。お使いの環境の永続ストア戦略を決定する前に、各方法の長所と短所を検討してください。
注意:
選択するストレージ方法に関係なく、トランザクションの整合性および一貫性を確保するために、JMSとTLOGの両方に同じタイプのストアを使用することをお薦めします。
TLOGおよびJMSデータをOracleデータベースに格納する場合、データベースの複製機能と高可用性機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡易化できます。これは、Oracle Fusion Middlewareを障害回復構成でデプロイする場合に特に重要です。
また、TLOGおよびJMSデータをデータベースに格納すると、そのデータについて共有記憶域内の特定の場所を指定する必要がありません。ただし、エンタープライズ・デプロイメントの他の観点からも共有記憶域が必要であることに注意してください。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポート)、デプロイメント・プラン、およびアダプタ・アーティファクト(ファイル/FTPアダプタの制御ファイルおよび処理済ファイル)でも必要です。
TLOGおよびJMSストアを共有記憶域デバイスに格納する場合、適切な複製およびバックアップ戦略を使用してデータ損失ゼロを保証することで、このデータを保護できます。また、システム・パフォーマンスも向上する可能性があります。ただし、ファイル・システム保護は常に、Oracle Databaseによって提供される保護よりも弱くなります。
データベースベースのTLOGおよびJMSストアの使用によるパフォーマンスへの潜在的な影響の詳細は、「TLOGおよびJMS永続ストアのパフォーマンスへの影響」を参照してください。
永続ストアを利用するFMW製品およびコンポーネントを決定するには、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションで、ドメイン名 > 「サービス」 > 「永続ストアを使用します。リストには、ストアの名前、ストア・タイプ(通常はFileStore)、ターゲットの管理対象サーバー、およびターゲットを移行可能かどうかが示されます。
移行可能ターゲットを含む永続ストアは、JDBC永続ストアの使用を検討するのに適した候補です。リストされている中でMDSに関連するストアについてはこの章では扱わず、考慮されません。
通常、Oracle WebCenter ContentおよびOracle SOAが含まれるOracle WebCenter Portal環境の場合、各クラスタ内のWLS_WCCnおよびWLS_SOAnの管理対象サーバーがJMSおよびTLOGSのデータ・ソースと新しいJDBC永続ストアのターゲットとなります。
トランザクション・ログのストレージ方法およびJMS永続ストアを選択する際の考慮事項の1つとして、パフォーマンスへの影響があげられます。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。
トランザクション・ログとJMSストアのパフォーマンスへの影響
トランザクション・ログの場合、ログは本質的に一時的であるため、JDBCストアの使用による影響は比較的小さくて済みます。通常、システム内の他のデータベース操作と比較した場合、影響はほとんどありません。
一方、JMSデータベース・ストアは、アプリケーションでのJMS使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。
パフォーマンスに影響を与える要素
カスタム宛先にJMS DBストアを使用する場合、複数の要素がパフォーマンスに影響を与えます。主なものは、次のとおりです。
関与するカスタム宛先とそのタイプ
永続化されるペイロード
SOAシステムの同時実行性(宛先のコンシューマおよびプロデューサ)
上述のいずれかの影響に応じて、次の領域に様々な設定を構成し、パフォーマンスを向上させることができます。
JMS表に使用されるデータ型のタイプ(RAWの使用対LOBの使用)
JMS表のセグメント定義(索引および表レベルでのパーティション)
JMSトピックの影響
システムでトピックが集中的に使用されている場合、同時実行性が高まるにつれて、Oracle RACデータベースのパフォーマンス低下はキューの場合よりも大きくなります。OracleがJMSに対して実施したテストでは、様々なペイロード・サイズおよび様々な同時実行性での平均パフォーマンス低下率は、キューの場合は30%未満でした。トピックの場合、影響は40%を超えていました。データベース・ストアを使用するかどうかを決定する際、リカバリの観点からこれらの宛先の重要性を検討してください。
データ型およびペイロード・サイズの影響
ペイロードにRAWデータ型を使用するかSecureFiles LOBデータ型を使用するかを選択する場合、永続化されるペイロードのサイズを考慮してください。たとえば、ペイロード・サイズの範囲が100bから20kの場合、SecureFiles LOBデータ型で必要とされるデータベース時間の量はRAWデータ型よりも若干多くなります。
具体的に言うと、ペイロード・サイズが約4kに達すると、SecureFilesはより多くのデータベース時間を必要とするようになります。これは、4kでは書込みが行外になるためです。約20kのペイロード・サイズで、SecureFilesデータはより効率的になり始めます。ペイロード・サイズが20kを超えると、RAWデータ型に設定されたペイロードのデータベース時間は悪化します。
SecureFilesのもう1つの利点は、500kを超えた時点からペイロードが増加してもデータベース時間が安定化し始める点です。すなわち、その時点で、(SecureFilesにとって)データが500k、1MBまたは2MBのいずれのペイロードを格納しているかは関係なくなります。書込みが非同期化され、すべてのケースで競合が同じになるためです。
ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合、同時実行性が変化してもその影響はほぼ同じですが、RAWの方がスケーラビリティがやや優れています。ペイロードが50kを超える場合、SecureFilesの方がスケーラビリティが優れています。
同時実行性、ワーカー・スレッド、データベースのパーティション化の影響
永続ストアに定義された同時実行性とワーカー・スレッドは、索引レベルおよびグローバル・キャッシュ・レベルでRACデータベースの競合の原因になることがあります。1つの単一サーバーで複数のワーカー・スレッドを有効にする場合、または複数のOracle WebLogic Serverクラスタを使用する場合、リバース索引を使用することで様々なことを改善できます。ただし、Oracle Databaseのパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。
JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。
エンタープライズ・デプロイメントでは、TLOGおよびJMSストアにGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成する手順は次のとおりです。
データベースでユーザーと表領域を作成し、データ・ソースを作成したら、必要な各管理対象サーバーにTLOG永続ストアを割り当てることができます。
データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。
Oracle WebCenter Portalエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。
注意:
ここで示されている一部の静的およびランタイム・アーティファクトは、Network Attached Storage (NAS)からホストされます。可能な場合は、これらのボリュームをアプリケーション・サーバーではなく直接NASファイラからバックアップおよびリカバリします。
Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。
環境のバックアップ
環境のリカバリ
表17-1に、典型的なOracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示します。
表17-1 Oracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
タイプ | ホスト | 層 |
---|---|---|
データベースOracleホーム |
DBHOST1およびDBHOST2 |
データ層 |
Oracle Fusion Middleware Oracleホーム |
WEBHOST1およびWEBHOST2 |
Web層 |
Oracle Fusion Middleware Oracleホーム |
WCCHOST1およびWCCHOST2 (またはNASファイラ) |
アプリケーション層 |
インストール関連ファイル |
WEBHOST1、WEHOST2および共有記憶域 |
N/A |
表17-2に、典型的なOracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクトを示します。
表17-2 Oracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクト
タイプ | ホスト | 層 |
---|---|---|
管理サーバーのドメイン・ホーム(ASERVER_HOME) |
WCCHOST1 (またはNASファイラ) |
アプリケーション層 |
アプリケーション・ホーム(APPLICATION_HOME) |
WCCHOST1 (またはNASファイラ) |
アプリケーション層 |
Oracle RACデータベース |
DBHOST1およびDBHOST2 |
データ層 |
スクリプトとカスタマイズ |
ホスト当たり |
アプリケーション層 |
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME) |
WCCHOST1 (またはNASファイラ) |
アプリケーション層 |
OHS構成ディレクトリ |
WEBHOST1およびWEBHOST2 |
Web層 |