| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.3.0) E61956-03 |
|
前 |
次 |
この章では、Oracle Identity and Access Managerエンタープライズ・デプロイメント用のOracle Web層を構成する方法について説明します。可能なWeb層の構成は、Oracle HTTP ServerまたはOracle Traffic Directorの2つあります。
この章の構成は、次のとおりです。
この項では、Oracle HTTP ServerをWebLogic Serverドメインに関連付ける方法について説明します。Oracle HTTP ServerをWebLogic Serverに関連付けると、Oracle Fusion Middlewareコンソールを使用してWeb層を監視できるようになります。
その後、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようロード・バランサを構成します。
最後の項では、リクエストをロード・バランサ仮想ホストにルーティングするためのOracle HTTP Serverディレクティブを定義する方法について説明します。
この項では、次の項目について説明します。
Oracle Web層を構成するための手順は、WEBHOST1とWEBHOST2のどちらでも同じです。
デフォルトでは、Oracle HTTP Serverはポート7777でインストールされます。ノード上の他のサービスが、ポート7777を使用していないことを確認してください。このポートが使用中かどうかを確認するには、Oracle HTTP Serverを構成する前に次のコマンドを実行します。このポートが使用されている場合は、解放する必要があります。
netstat -an | grep 7777
Oracle HTTP Serverが使用するポートを含むファイルを作成します。インストール・メディアのDisk1で、次のディレクトリにあるstaticports.iniファイルを探します。
stage/Response
これをohs_ports.iniというファイルにコピーします。ohs_ports.iniからOHS PORTとOPMN Local Portを除くすべてのエントリを削除します。これらのポートの値をそれぞれ7777と6700に変更します。または標準のポートを使用する場合は、別のポートに変更します。
|
注意: ファイルのポート名がOHS PORTおよびOPMN Local Portと若干異なる場合、ファイルでこれらの名前を使用します。 |
Oracle Web層を構成する手順は、次のとおりです。
Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。
cd OHS_ORACLE_HOME/bin
構成ウィザードを起動します。
./config.sh
構成ウィザードに次の情報を入力します。
「ようこそ」画面で、「次へ」をクリックします。
「コンポーネントの構成」画面で「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」および「Oracle Web Cache」が選択されていないことを確認してください。
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を指定します。
WEBHOST1に次の値を入力します。
インスタンス・ホームの場所: LOCAL_CONFIG_DIR/instances/ohs1
インスタンス名: ohs1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「ポートの構成」画面で、以前に作成したohs_ports.iniファイルを使用して、使用するポートを指定します。こうすることによって、自動ポート構成をバイパスできます。
構成ファイルを使用してポートを指定を選択します。
ファイル名フィールドに、ohs_ports.iniファイルへの絶対パスを指定します。「参照」ボタンを使用してファイルを検索し、「開く」をクリックします。
「保存」→「次へ」をクリックします。
「セキュリティ・アップデートの指定」画面で、アップデートをスキップするかどうかを選択するか、セキュリティ・アップデートが通知されるOracle Support詳細を入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。そうでない場合は、「戻る」をクリックして前の画面に戻り、選択内容を変更します。
「構成」をクリックします。
「構成」画面で、複数のConfiguration Assistantが起動されます。このプロセスは、時間がかかることがあります。終了したら、「次へ」をクリックします。
「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。
WEBHOST2について、インスタンス名/コンポーネント名にohs2を使用して繰り返します。
構成の検証
インストールが完了したら、次のURLを使用してOracle HTTP Serverホームページにアクセスできることを確認します。
http://WEBHOST1.example.com:7777/ http://WEBHOST2.example.com:7777/
仮想ホストを構成するには、この項で説明する次のタスクを実行します。
この項では、エンタープライズ・デプロイメントのブループリントの対象であるすべての製品のすべてのWeb層構成について説明します。トポロジのサブセットのみを構成している場合は、使用中のトポロジに適したエントリのみを含めてください。
デプロイメント内の各仮想ホストに対するOHS構成ファイルを、次の場所に作成します。
OHS_ORACLE_INSTANCE/config/OHS/<component>/moduleconf.
|
注意: 以降の各項では、すべてのコンポーネントに対するすべてのエントリを示します。コンポーネントのサブセットのみをデプロイしている場合は、該当するエントリのみを含める必要があります。NameVirtualHostは、読み取られる最初のファイルにのみ必要です。このエントリをアルファベット順で最初のファイル名に挿入するか、httpd.confファイルに直接挿入できます。 |
これらのファイルは次のように表示されます。
iadadmin_vh.conf
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://iadadmin.example.com:80
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
RewriteRule ^/em/targetauth/emaslogout.jsp "/oamsso/logout.html?end_url=/em" [R]
UseCanonicalName On
ServerAdmin you@your.address
#Weblogic related entries
# Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost iadadminvhn.example.com
WeblogicPort 7001
</Location>
<Location /consolehelp>
WLSRequest ON
WebLogicHost iadadminvhn.example.com
WeblogicPort 7001
</Location>
<Location /em>
WLSRequest ON
WebLogicHost iadadminvhn.example.com
WeblogicPort 7001
</Location>
<Location /oamconsole>
WLSRequest ON
WebLogicHost iadadminvhn.example.com
WeblogicPort 7001
</Location>
<Location /apm>
WLSRequest ON
WebLogicHost iadadminvhn.example.com
WeblogicPort 7001
</Location>
<Location /access>
WLSRequest ON
WebLogicCluster oamhost1.example.com:14150,oamhost2.example.com:14150
WLCookieName OAMJSESSIONID
</Location>
<Location /gms-rest>
WLSRequest ON
WebLogicCluster oamhost1.example.com:14180,oamhost2.example.com:14180
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
<Location /msm-mgmt>
WLSRequest ON
WLCookieName OAMJSESSIONID
WebLogicCluster oamhost1.example.com:14180,oamhost2.example.com:14180
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
</VirtualHost>
igdadmin_vh.conf (分割ドメイン・トポロジを使用している場合)
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://igdadmin.example.com:80
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
RewriteRule ^/em/targetauth/emaslogout.jsp "/oamsso/logout.html?end_url=/em" [R]
UseCanonicalName On
ServerAdmin you@your.address
# Weblogic Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost igdadminvhn.example.com
WeblogicPort 7101
</Location>
<Location /consolehelp>
WLSRequest ON
WebLogicHost igdadminvhn.example.com
WeblogicPort 7101
</Location>
<Location /em>
WLSRequest ON
WebLogicHost igdadminvhn.example.com
WeblogicPort 7101
</Location>
###################################################
## Entries Required by Oracle Entitlements Server
###################################################
# APM
<Location /apm>
WLSRequest ON
WebLogicHost igdadminvhn.example.com
WeblogicPort 7101
</Location>
################################################
## Entries Required by Oracle Identity Manager
################################################
<Location /oim>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster
oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
<Location /sysadmin>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster
oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster
oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# OIM self service console
<Location /identity>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster
oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# Nexaweb WebApp - used for workflow designer and DM
<Location /Nexaweb>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster
oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# Scheduler webservice URL
<Location /SchedulerService-web>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster
oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# Oracle BIP console
<Location /xmlpserver>
WLSRequest ON
WLCookieName JSESSIONID
WebLogicCluster oimhost1vhn3.example.com:9704,oimhost2vhn3.example.com:9704
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
</VirtualHost>
login_vh.conf
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://login.example.com:443
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end
_url=/console" [R]
RewriteRule ^/em/targetauth/emaslogout.jsp "/oamsso/logout.html?end_url=/em"
[R]
UseCanonicalName On
ServerAdmin you@your.address
#OAM Entries
<Location /oam>
WLSRequest ON
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName OAMJSESSIONID
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
</Location>
<Location /oamfed>
WLSRequest ON
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
WLCookieName OAMJSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /ms_oauth >
WLSRequest ON
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
WLCookieName OAMJSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>
prov_vh.conf
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://prov.example.com:443
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end
_url=/console" [R]
RewriteRule ^/em/targetauth/emaslogout.jsp "/oamsso/logout.html?end_url=/em" [R]
UseCanonicalName On
ServerAdmin you@your.address
<Location /identity>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
<Location /HTTPClnt>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# Requests webservice URL
<Location /reqsvc>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLProxySSL ON
WLProxySSLPassThrough ON
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
</VirtualHost>
iadinternal_vh.conf
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://iadinternal.example.com:7777
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end
_url=/console" [R]
RewriteRule ^/em/targetauth/emaslogout.jsp "/oamsso/logout.html?end_url=/em"
[R]
UseCanonicalName On
ServerAdmin you@your.address
#MSM Entries
<Location /msm>
WLSRequest ON
WebLogicCluster oamhost1.example.com:14180,oamhost2.example.com:14180
WLCookieName OAMJSESSIONID
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
# MSM runtime services for MAM
<Location /ecp>
WLSRequest ON
WLCookieName OAMJSESSIONID
WebLogicCluster oamhost1.example.com:14180,oamhost2.example.com:14180
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
# Mobile File manager
<Location /mfm>
WLSRequest ON
WLCookieName OAMJSESSIONID
WebLogicCluster
oamhost1.example.com:14180,oamhost2.example.com:14180
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
# MSAS management services
<Location /gms-rest>
WLSRequest ON
WLCookieName OAMJSESSIONID
WebLogicCluster oamhost1.example.com:14180,oamhost2.example.com:14180
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
# MSM management rest services
<Location /msm-mgmt>
WLSRequest ON
WLCookieName OAMJSESSIONID
WebLogicCluster oamhost1.example.com:14180,oamhost2.example.com:14180
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/msm_component.log"
</Location>
</VirtualHost>
igdinternal_vh.conf
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://igdinternal.example.com:7777
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
RewriteRule ^/em/targetauth/emaslogout.jsp "/oamsso/logout.html?end_url=/em" [R]
UseCanonicalName On
ServerAdmin you@your.address
##################################################
## Entries Required by Oracle Identity Manager
#################################################
#SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
<Location /sodcheck>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn2.example.com:8001,oimhost2vhn2.example.com:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/soa_component.log"
</Location>
# OIM, role-sod profile
<Location /role-sod>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the SOA Managed Server Port
<Location /workflowservice>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/soa_component.log"
</Location>
# used for FA Callback service.
<Location /callbackResponseService>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# spml xsd profile
<Location /spml-xsd>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
# OIM, spml dsml profile
<Location /spmlws>
WLSRequest ON
PathTrim /weblogic
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
<Location /reqsvc>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/soa_component.log"
</Location>
<Location /integration>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn2.example.com:8001,oimhost2vhn2.example.com:8001
</Location>
# SOA Infra
<Location /soa-infra>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN2.example.com:8001,OIMHOST2VHN2.example.com:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/component/oim_component.log"
</Location>
# UMS Email Support
<Location /ucs>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN2.example.com:8001,OIMHOST2VHN2.example.com:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/component/oim_component.log"
</Location>
<Location /provisioning-callback>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
<Location /CertificationCallbackService>
WLSRequest ON
WLCookieName oimjsessionid
WebLogicCluster oimhost1vhn1.example.com:14000,oimhost2vhn1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>
</VirtualHost>
第31.1.3項「ディレクトリ・サービスの起動と停止」の手順を使用して、WEBHOST1およびWEBHOST2でOHSを再起動します。
デフォルトでは、Oracle HTTP Serverはユーザーnobodyとして実行されます。Identity Managementをインストールした環境では、ソフトウェア所有者およびグループとしてOracle HTTP Serverを実行する必要があります。
適切なユーザーおよびグループとしてサーバーを実行するために、ファイルhttpd.confを編集してください。このファイルは、OHS_ORACLE_INSTANCE/config/OHS/component_name内にあります。
httpd.conf内で、Userが定義されているセクションを見つけます。
このセクションの内容を次のように変更します。
User User_who_installed_the_software Group Group_under_which_the_HTTP_server_runs
Groupは、通常はデフォルト・ユーザー・グループです(例: oinstall)。
次に例を示します。
<IfModule !mpm_winnt_module> # # If you wish httpd to run as a different user or group, you must run # httpd as root initially and it will switch. # # User/Group: The name (or #number) of the user/group to run httpd as. # . On SCO (ODT 3) use "User nouser" and "Group nogroup". # . On HPUX you may not be able to use shared memory as nobody, and the # suggested workaround is to create a user www and use that user. # NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET) # when the value of (unsigned)Group is above 60000; # don't use Group #-1 on these systems! # User oracle Group oinstall </IfModule>
デフォルトでは、Oracle HTTP Serverには、ほとんどのアプリケーションに適したパラメータ値が含まれています。ただし、これらの値はIDMデプロイメントでは調整する必要があります。
次のように実行します。
次の場所にあるファイルhttpd.confを編集します。
OHS_ORACLE_INSTANCE/config/OHS/component_name
次のようなエントリを探します。
<IfModule mpm_worker_module>
このセクションの値を次のように更新します。
<IfModule mpm_worker_module>
ServerLimit 20
StartServers 10
MaxClients 1000
MinSpareThreads 200
MaxSpareThreads 800
ThreadsPerChild 50
ThreadLimit 50
MaxRequestsPerChild 1000
AcceptMutex fcntl
LockFile "${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME}/http_lock"
</IfModule>
ファイルを保存します。
次のコマンドを使用して、OHSサーバーを再起動します。
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
インストールが完了した後、次のURLを使用して、Oracle HTTP Serverにアクセスできることを確認してください。
http://WEBHOST1.example.com:7777/
http://WEBHOST2.example.com:7777/
https://prov.example.com
https://login.example.com
http://iadadmin.example.com
http://igdadmin.example.com
http://igdinternal.example.com:7777
http://iadinternal.com:7777
ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。
Oracle Traffic Directorは、バックエンドのサーバーに対するHTTP/SおよびTCPトラフィックのロード・バランシングを行うためのソフトウェア・ロード・バランサです。これらのバックエンド・サーバーは、Oracle Traffic Director内でオリジン・サーバーと見なされており、アプリケーション・サーバー、Webサーバー、LDAPサーバーがあります。
エンタープライズ・デプロイメント用のOracle Traffic Directorのインストールおよび構成には、表14-1に示す手順の実行が含まれます。
表14-1 エンタープライズ・デプロイメント用のOracle Traffic Directorのインストールおよび構成の概要
| タスク | 説明 | 詳細情報 |
|---|---|---|
|
Oracle Traffic Directorの前提条件の確認。 |
たとえば、必要な仮想IPアドレスを設定したこと、ユーザー・アカウントにストレージ・アプライアンスでのroot権限があること、Oracle Identity Managementトポロジの初期Oracle WebLogic Serverドメインがすでに作成されていることなどを確認します。 |
『Oracle Traffic Directorインストレーション・ガイド』の前提条件に関する項 |
|
Oracle Traffic Directorソフトウェアのインストール。 |
第7.5.5項「ディレクトリの推奨場所」で作成したディレクトリとマウント・ポイントを使用して、ソフトウェアをインストールします。 |
第11.2.2項「Oracle Traffic Directorのインストール」 |
|
Oracle Traffic Director管理サーバーの作成および起動。 |
Oracle Traffic Director管理サーバーは、管理コンソールとコマンドライン・インタフェースをホストし、ユーザーはこれらを介してOracle Traffic Director構成を作成し、それをインスタンスとして管理ノードにデプロイして、そのインスタンスを管理できます。 |
第14.2.1項「Traffic Director管理サーバーの作成および起動」 |
|
インストールの確認。 |
引き続き環境を構成する前に、インストールが正常に行われたことを確認します。 |
『Oracle Traffic Directorインストレーション・ガイド』のインストールの確認に関する項 |
|
WEBHOST2の管理ノードとしての登録。 |
これにより、Oracle Traffic Directorが、WEBHOST1とWEBHOST2の両方で起動され実行されることが保証されます。 |
|
|
構成の作成。 |
構成は、Oracle Traffic DirectorインスタンスからOracle WebLogic Serverドメイン内の管理対象サーバーにリクエストをルーティングする必要があります。 また、リクエストのルーティング先として必要なオリジン・サーバーのプールを定義する必要もあります。 |
|
|
Oracle Traffic Directorインスタンスの起動。 |
前の手順で作成した構成に基づいて、WEBHOST1およびWEBHOST2のインスタンスを起動します。 |
14.2.4項「Oracle Traffic Directorの起動、停止および再起動」 |
|
仮想サーバーの定義。 |
様々な管理ツールやトポロジのログイン画面にアクセスするために必要な仮想サーバーを定義します。 |
第14.2.5項「エンタープライズ・デプロイメントで必要なOracle Traffic Director仮想サーバーの定義」 |
|
ルートの作成。 |
ルートを追加すると、URIの内容に応じて、仮想サーバーがリクエストを別のサーバー・プールに送信できるようになります。 |
|
|
login.example.comでのSSLパススルーの有効化。 |
アプリケーションのリダイレクトが正しく行われることを保証するため、追加の構成手順を実行します。 |
|
|
構成のデプロイおよびテスト。 |
構成をデプロイし、仮想サーバーのURLをテストして、Oracle Traffic Directorインスタンスが正常に構成されたことを確認します。 |
第14.2.9項「構成のデプロイと仮想サーバー・アドレスのテスト」 |
|
アクティブ/パッシブ・フェイルオーバー・グループの作成。 |
WEBHOST1またはWEBHOST2が使用できなくなった場合に、リクエストが引き続き処理されるようにするため、フェイルオーバー・グループを作成します。 |
第14.2.10項「仮想ホストのフェイルオーバー・グループの作成」 |
この項では、次の項目について説明します。
WEBHOST1およびWEBHOST2にOracle Traffic Directorをインストールしたら、Oracle Traffic Director管理サーバーを作成できます。
Oracle Traffic Directorは、rootユーザーまたは非権限ユーザーのどちらで実行するようにも構成できます。この章では両方の場合について説明していますが、rootで実行するように構成することをお薦めします。Oracle Traffic Directorをrootで実行すると、インスタンスの開始と停止など、すべての管理タスクをOracle Traffic Director管理コンソールから実行できます。
Oracle Traffic Directorをrootで実行するように構成しない場合は、rootアカウントを使用して、Oracle Traffic Directorコンソール外部で追加の手順が必要になります。これは、フェイルオーバー・グループ(後述)で、rootのみがアクセスできるプロセスの実行が必要であるためです。
詳細は、『Oracle Traffic Director管理者ガイド』の「管理サーバーの管理」を参照してください。
WEBHOST1でOracle Traffic Director管理サーバーを作成するには、次のようにして、OTD_ORACLE_HOME/binディレクトリからtadmコマンドを実行します。
WEBHOST1で、次のコマンドを入力します。
OTD_ORACLE_HOME/bin/tadm configure-server --port=OTD_ADMIN_PORT \ --user=otdadmin --instance-home=OTD_ORACLE_INSTANCE --host=OTDADMINVHN --server-user=root
説明:
OTD_ORACLE_HOMEは、Oracle Traffic Directorインストーラで入力したOracleホームの場所です。
OTD_ORACLE_INSTANCEは、表7-4「プライベート記憶域ディレクトリ - 分散トポロジ」にリストされている推奨値です。
OTDADMINVHNは、Oracle Traffic Director管理サーバーとコンソールで使用される仮想ホスト名です。
次に例を示します。
OTD_ORACLE_HOME/web/bin/tadm configure-server --port=8800 --user=otdadmin \
--instance-home=/u02/private/oracle/config/instances/otd1 --host=OTDADMINVHN.example.com
|
注意: Oracle Traffic Directorをrootユーザーとして実行する場合(ポート<1024を使用してOracle Traffic Directorを実行する場合に必要)、次の追加パラメータをコマンドに含める必要があります。--server-user=root |
管理者パスワードを入力します。
後でこのパスワードを使用してOracle Traffic Director管理コンソールにログインします。
管理者パスワードの再入力を求めるプロンプトが次のように表示されます。
Please enter admin-user-password again>
管理者パスワードを再度入力して確認します。
Oracle Traffic Directorの管理サーバー・インスタンスが作成され、手順1で指定したOTD_ORACLE_INSTANCEディレクトリ内のadmin-serverという、ローカル・ホスト上のディレクトリにデプロイされます。
WEBHOST1で次のコマンドを実行して、管理サーバーを起動します。
WEB_INSTANCE_HOME/admin-server/bin/startserv
サーバーをrootとして実行する場合は、rootとして起動します。
次のURLを使用して、管理サーバーにログインします。
https://OTDADMINVHN:8800
8800はOTD_ADMIN_PORTです。
前の手順で指定したパスワードを使用して、Oracle Traffic Directorのメイン・ページが表示されることを確認します。
この項では、Oracle Traffic Directorがインストールされ、管理サーバーが起動されて、インストールが確認済であることを前提としています。
WEBHOST1およびWEBHOST2には、IP over InfiniBand (IPoIB)アドレスがあります。たとえば、192.168.10.5や192.168.10.6などです。
ここでWEBHOST2をOracle Traffic Director管理サーバーに登録するには、次のように、OTD_ORACLE_HOME/binディレクトリからtadmコマンドを使用します。
WEBHOST2で、configure-serverコマンドを実行し、ホストを管理ノードとしてリモート管理サーバーに登録します。
./tadm configure-server --user=otdadmin --port=OTD_ADMIN_PORT --host=OTDADMINVHN \ --admin-node --node-port=OTD_NODE_PORT --instance-home=OTD_ORACLE_INSTANCE --node-host=WEBHOST2 --server-user=root
説明:
OTD_ORACLE_HOMEは、WEBHOST2上のOracle Traffic DirectorのOracleホームへのパスです。
WEB_INSTANCE_HOMEは、表7-4「プライベート記憶域ディレクトリ - 分散トポロジ」にリストされている推奨ディレクトリ・パスです。
node-hostは、このインタフェースが実行されているマシン(IAMHOST1、IAMHOST2またはWEBHOST2)です。
次に例を示します。
./tadm configure-server --user=otdadmin --port=8800 --host=OTDADMINVHN --admin-node \ --node-port=8900 --instance-home=/u02/private/oracle/config/instances/otd2 --node-host=WEBHOST2
|
注意: Oracle Traffic Directorをrootユーザーとして実行する場合(ポート<1024を使用してOracle Traffic Directorを実行する場合に必要)、次の追加パラメータをコマンドに含める必要があります。--server-user=root |
詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』のconfigure-serverに関する項を参照するか、configure-server --helpコマンドを使用して、コマンドライン・オプションの説明を参照してください。
configure-serverコマンドを実行すると、次のプロンプトが表示されます。
This command creates an Administration Node and register it with the following remote Administration Server: https://WEBHOST1.example.com Enter admin-user password>
Oracle Traffic Director管理サーバーの管理ユーザー・パスワードを入力します。
configure-serverコマンドにより、指定した管理サーバー・ホスト、ポート、ユーザーおよびパスワードを使用してリモート管理サーバーとの接続が試行されます。WEBHOST1上で管理サーバーが起動され、実行されている必要があります。
管理ノードを作成しているホストが初めて管理サーバーに接続しようとしている場合は、管理サーバーのサーバー証明書が表示されます。
「y」を入力して証明書を信頼します。
次のメッセージが表示されます。
OTD-70215 The administration node has been configured successfully.The node can be started by executing:
OTD_ORACLE_INSTANCE/admin-server/bin/startserv
WEBHOST2で次のコマンドを実行して、Oracle Traffic Directorサーバーを起動します。
WEB_INSTANCE_HOME/admin-server/bin/startserv
サーバーをrootとして実行する場合は、rootとして起動します。
管理ノードを起動した後、管理ノード上でOracle Traffic Director構成のインスタンスを作成できます。各管理ノード上では構成のインスタンスを1つのみ作成できることに注意してください。
エンタープライズ・デプロイメント用にOracle Traffic Directorをインストールおよび構成する手順で次に行うのは、Oracle WebLogic Serverドメイン内の管理対象サーバーで構成されるサーバー・プールにリクエストをルーティングする構成を作成することです。
新しい構成を作成する際、オリジン・サーバーのホストおよびポート情報を指定する必要があり、それによって、origin-server-pool-1というオリジン・サーバー・プールが自動的に作成(および命名)されます。これはデフォルトのオリジン・サーバー・プールで、このプールを確認するには管理コンソールで「サーバー・プール」オプションをクリックします。デフォルトのオリジン・サーバー・プール名は変更できません。
管理コンソールを使用してIAMという構成を作成する手順:
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします
「共通のタスク」ペインで、「新規構成」をクリックします。
新規構成ウィザードが開始されます。
「ステップ1 構成情報」画面で、次の情報を入力します。
名前: login.example.com
サーバー・ユーザー: oracle (サーバー・インスタンスをrootとして実行する場合は、root)。
オリジン・サーバー・タイプ: 「HTTP」が選択されていることを確認します。
「次へ」をクリックします。
リスナー情報の構成画面で、リスナー・ポートをWEB_HTTP_PORTに設定します。たとえば、7777です。
|
注意: IDM LCMツールを使用してOracle Identity and Access Managementをデプロイしている場合は、リスナー・ポートを6666などの一時値に設定する必要があります。これは、自動ツールによってOracle HTTPサーバーがWEB_HTTP_PORTにインストールされるためです。IDMLCMインストールの完了後、Oracle HTTPサーバーを無効にして、OTDリスニング・ポートをWEB_HTTP_PORTの値に更新します。この結果、IDMLCMでそのアプリケーション間書込みが実行された場合に、WEB_HTTP_PORTが使用されることが保証されます。Oracle HTTPサーバーが無効化されると、OTDによってWebサーバーのロールが引き継がれます。 |
その他のデフォルト値はそのまま使用して、「次へ」をクリックします。
「ステップ3 サーバー・プール情報」画面で、次のようにします。
「オリジン・サーバー: ホスト:」フィールドに、OAMHOST1.example.com、ポート14100 (OAM_PORT)と入力し、「サーバーの追加」をクリックします。
OAMHOST2.example.com、ポート14100と入力し、「サーバーの追加」、「次へ」の順にクリックします。
「ステップ4 デプロイメント情報」画面で、「管理サーバー」と「WEBHOST2」を選択して、「次へ」をクリックします。
「確認」画面が表示されます。
情報を確認して、「構成の作成」をクリックします。
「結果」画面が表示されます。
構成が作成された後、新規構成ウィザードの「結果」画面に構成の作成が成功したことを示すメッセージが表示されます。構成のインスタンスを作成することを選択した場合、インスタンスの作成が成功したことを示すメッセージも表示されます。
結果画面で、「閉じる」をクリックします。
新規構成ウィザードで、構成のインスタンスの作成を選択しなかった場合、作成した構成がまだデプロイされていないことを示すメッセージ「アンデプロイ済構成」が表示されます。
Oracle Traffic Directorインスタンスの起動および停止は、第31.1.7.2項「Oracle Traffic Directorインスタンスの起動」を参照してください。
Oracle Traffic Director構成用に仮想サーバーを作成および構成します。この項では、Oracle Identity and Access Managementデプロイメント用に次のOracle Traffic Director仮想サーバーを作成します。外部Oracle HTTP Serverが使用されている場合、これらの仮想サーバーのいくつかはOracle Traffic Directorで有効にできません。
表14-2 OTD仮想サーバーの定義
| 仮想サーバー | 用途 | 仮想サーバーの作成方法 | OHSで必要 |
|---|---|---|---|
|
login.example.com |
シングル・サインオン・サービスに送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.2項「仮想サーバーの作成」で、管理コンソールを使用して作成されます。 |
いいえ |
|
prov.example.com |
プロビジョニング・アプリケーションに送信されるすべてのHTTPトラフィック用のアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.2項「仮想サーバーの作成」で、管理コンソールを使用して作成されます |
いいえ |
|
iadadmin.example.com |
IAMAccessDomain管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.2項「仮想サーバーの作成」で、管理コンソールを使用して作成されます。 |
いいえ |
|
igdadmin.example.com |
IAMGovernanceDomain管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.2項「仮想サーバーの作成」で、管理コンソールを使用して作成されます |
いいえ |
|
iadinternal.example.com |
モバイル・セキュリティ・マネージャ(MSM)に送信されるすべての内部HTTPトラフィック・リクエスト用のアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.2項「仮想サーバーの作成」で、管理コンソールを使用して作成されます。 |
いいえ |
|
igdinternal.example.com |
OIMおよびSOAに送信されるすべての内部HTTPトラフィック・リクエスト用のアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.2項「仮想サーバーの作成」で、管理コンソールを使用して作成されます。 |
はい |
|
idstore.example.com |
すべてのアイデンティティ・ストアのLDAPトラフィックのアクセス・ポイントとして機能します。 |
この仮想サーバーは、第14.2.5.3項「idstore.example.comのTCPプロキシおよびリスナーの作成」で、OUDのTCPプロキシの構成時に作成されます。 |
はい |
管理コンソールを使用して仮想サーバーを作成および構成するには、次の各項の手順を実行します。
サーバー・プールとは、同じ仮想および物理ネットワークやストレージ・リソースにアクセスできる同じプロセッサ・アーキテクチャを持つ1つ以上の仮想化ホストのグループです。サーバー・プールにより、ロード・バランシング、高可用性機能、およびプール内のすべてのメンバーによる一部リソースの共有が可能になります。
この項では、表14-3に示したOracle Traffic Directorのオリジン・サーバー・プールを作成します。
表14-3 物理Exalogic用のオリジン・サーバー・プールおよびオリジン・サーバー
| オリジン・サーバー・プール | オリジン・サーバー・タイプ | オリジン・サーバー | ポート |
|---|---|---|---|
|
iadadmin-pool |
HTTP |
IADADMINVHN.example.com |
7001 ( |
|
igdadmin-pool |
HTTP |
IGDADMINVHN.example.com |
7101 ( |
|
ldap-pool |
TCP |
IAMHOST1.example.com、IAMHOST2.example.com |
1389 ( |
|
oim-pool |
HTTP |
OIMHOST1VHN1.example.com、OIMHOST2VHN1.example.com |
14000 ( |
|
ama-pool |
HTTP |
IAMHOST1.example.com、IAMHOST2.example.com |
14150 ( |
|
msm-pool |
HTTP |
IAMHOST1.example.com、IAMHOST2.example.com |
14180 ( |
|
origin-server-pool-1 |
HTTP |
IAMHOST1.example.com、IAMHOST2.example.com |
14100 ( |
|
soa-pool |
HTTP |
OIMHOST1VHN2.example.com、OIMHOST2VHN2.example.com |
8001 ( |
|
bi-pool |
HTTP |
OIMHOST1VHN3.example.com、OIMHOST2VHN3.example.com |
9704 ( |
表14-4 仮想Exalogic用のオリジン・サーバー・プールおよびオリジン・サーバー
| オリジン・サーバー・プール | オリジン・サーバー・タイプ | オリジン・サーバー | ポート |
|---|---|---|---|
|
iadadmin-pool |
HTTP |
IADADMINVHN.example.com |
7001 ( |
|
igdadmin-pool |
HTTP |
IGDADMINVHN.example.com |
7101 ( |
|
ldap-pool |
TCP |
LDAPHOST1.example.com、LDAPHOST2.example.com |
1389 ( |
|
oim-pool |
HTTP |
OIMHOST1VHN1.example.com、OIMHOST2VHN1.example.com |
14000 ( |
|
origin-server-pool-1 |
HTTP |
OAMHOST1.example.com、OAMHOST2.example.com |
14100 ( |
|
soa-pool |
HTTP |
OIMHOST1VHN2.example.com、OIMHOST2VHN2.example.com |
8001 ( |
|
bi-pool |
HTTP |
OIMHOST1VHN3.example.com、OIMHOST2VHN3.example.com |
9704 ( |
|
ama-pool |
HTTP |
OAMHOST1.example.com、OAMHOST2.example.com |
14150 ( |
|
msm-pool |
HTTP |
OAMHOST1.example.com、OAMHOST2.example.com |
14180 ( |
表14-5 外部OHSサーバー用のオリジン・サーバー・プールおよびオリジン・サーバー
| オリジン・サーバー・プール | オリジン・サーバー・タイプ | オリジン・サーバー | ポート |
|---|---|---|---|
|
iadadmin-pool |
HTTP |
IADADMINVHN.example.com |
7001 ( |
|
igdadmin-pool |
HTTP |
IGDADMINVHN.example.com |
7101 ( |
|
ldap-pool |
TCP |
IAMHOST1-EXT.example.com、IAMHOST2-EXT.example.com |
1389 ( |
|
oim-pool |
HTTP |
OIMHOST1VHN2-EXT.example.com、OIMHOST2VHN2-EXT.example.com |
14000 ( |
|
bi-pool |
HTTP |
OIMHOST1VHN3-EXT.example.com、OIMHOST2VHN3-EXT.example.com |
9704 ( |
|
origin-server-pool-1 |
HTTP |
IAMHOST1-EXT.example.com、IAMHOST2-EXT.example.com |
14100 ( |
|
soa-pool |
HTTP |
OIMHOST1VHN2.example.com、OIMHOST2VHN2.example.com |
8001 ( |
|
ama-pool |
HTTP |
IAMHOST1-EXT.example.com、IAMHOST2-EXT.example.com |
14150 ( |
|
msm-pool |
HTTP |
IAMHOST1-EXT.example.com、IAMHOST2-EXT.example.com |
14180 ( |
|
注意: origin-server-pool-1は、構成の作成時に自動的に作成されます。 |
オリジン・サーバー・プールを作成する手順:
次のURLを使用して、管理コンソールにログインします。
https://OTDADMINVHN:OTD_ADMIN_PORT
OTD_ADMIN_PORTは、第8.1項「必要な仮想IPアドレスのサマリー」で定義されます。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
サーバー・プールを作成する構成を選択します。たとえば、login.example.comです。
「共通のタスク」ペインで、「新規サーバー・プール」をクリックします。
新規オリジン・サーバー・プール・ウィザードが起動されます。
「サーバー・プール情報」画面で次の情報を入力します。
名前: サーバー・プールの名前。たとえば、oim-poolです。
オリジン・サーバー・タイプ: プールで処理するリクエストのタイプ。たとえば、HTTPです。
アドレス・ファミリ: OTDがオリジン・サーバーと通信する方法。通常、これはinetに設定されます。
「次へ」をクリックします。
「オリジン・サーバー情報」画面で次の情報を入力します。
オリジン・サーバーのホスト: OIMHOST1VHN1.example.com
ポート: 14000 (OIM_PORT)
「サーバーの追加」をクリックします。
他のサーバーの情報を入力します。次に例を示します。
オリジン・サーバーのホスト: OIMHOST2VHN1.example.com
ポート: 14000 (OIM_PORT)
「次へ」をクリックします。
「確認」画面の情報を確認します。情報が正しければ、「サーバー・プールの作成」をクリックします。
作成された各HTTPプールに複数のオリジン・サーバーを追加する場合は、次の追加構成手順を実行します。
新規作成されたサーバー・プールの名前(例: oim-pool)をクリックします。
プールのプロパティが表示されます。
「詳細設定」を開きます。
「動的検出」チェック・ボックスを選択します。
これにより、今後追加される新規クラスタ・メンバーはOTDサーバー・プールに自動的に追加されるので、手動で追加する必要はなくなります(ただし、手動による追加は引き続き推奨される方法です)。
|
注意: OUDのオリジン・サーバー・プール(oud-pool)では動的検出を使用できません。 |
「保存」をクリックします。
結果画面で、「閉じる」をクリックします。
作成したオリジン・サーバー・プールの詳細が、「オリジン・サーバー・プール」ページに表示されます。
さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。第14.2.9項「構成のデプロイと仮想サーバー・アドレスのテスト」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。
表14-3にリストされているオリジン・サーバー・プールについて、これらの手順を繰り返します。
表14-7「ルートおよび条件」の情報を使用して、仮想サーバーを作成します。
表14-6 仮想サーバーの情報
| 名前 | ホスト | プール |
|---|---|---|
|
login.example.com |
login.example.com |
origin-server-pool-1 |
|
prov.example.com |
prov.example.com |
soa-pool |
|
iadadmin.example.com |
iadadmin.example.com |
iadadmin-pool |
|
igdadmin.example.com |
igdadmin.example.com |
igdadmin-pool |
|
igdinternal.example.com |
igdinternal.example.com |
oim-pool |
|
iadinternal.example.com |
iadinternal.example.com |
msm-pool |
|
注意: login.example.com仮想サーバーは、構成の作成時に自動的に作成されます。 |
管理コンソールを使用して仮想サーバーを作成する手順:
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
仮想サーバーを作成する構成(例: login.example.com)を選択します。
「共通のタスク」ペインで、「新規仮想サーバー」をクリックします。
新規仮想サーバー・ウィザードが開始されます。
「仮想サーバー情報」ページで、次の情報を入力します。
名前: 仮想サーバーを示した名前。たとえば、login.example.comです。
ホスト: この仮想サーバーへのアクセスに使用されるDNS/ホストの名前。たとえば、login.example.comです。
「次へ」をクリックします。
「HTTPリスナー情報」画面で、既存のリスナーを選択します。
「次へ」をクリックします。
「サーバー・プール情報」画面で、次の情報を入力します。
選択: オリジン・サーバーのプールを選択します。
名前: 「OTDオリジン・サーバー・プールの作成」で作成したサーバー・プールの名前を1つ選択します。
「次へ」をクリックします。
「確認」に表示された情報を確認して、「仮想サーバーの作成」をクリックします。
表14-6の各仮想サーバーについて、手順4から6を繰り返します。
管理コンソールを使用してTCPプロキシを作成します。
TCPプロキシを作成する手順:
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
TCPプロキシを作成する構成(例: login.example.com)を選択します。
「共通のタスク」ペインで、「新規TCPプロキシ」をクリックします。
新規TCPプロキシ・ウィザードが開始されます。
「ステップ1: TCPプロキシ情報」画面で、次の情報を入力して「次」をクリックします。
名前: idstore.example.com
リスナー名: listener-oud
ポート: 1389 (LDAP_LBR_PORT)
|
注意: LDAPサーバーがOTDインスタンスと同じホストで実行されている場合、LDAPポート(LDAP_PORT)とOTD LDAPポート(LDAP_LBR_PORT)は異なる必要があります。 |
「IPアドレス」フィールドに「*」と入力します。
「ステップ2: サーバー・プール情報」画面で、「オリジン・サーバーのプールの選択」をクリックします。
ドロップダウン・リストで「ldap-pool」を選択して、「次へ」をクリックします。
「確認」画面が表示されます。
詳細を確認して、「TCPプロキシの作成」をクリックします。
結果画面で、「閉じる」をクリックします。
TCPプロキシ・ページに、作成したTCPプロキシの詳細が表示されます。
さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。第14.2.9項「構成のデプロイと仮想サーバー・アドレスのテスト」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。
|
注意: この項は、Oracle Traffic DirectorがWebサーバーとして使用されている場合にのみ関連します。 |
ルートは、Oracle HTTPの場所ディレクティブと似ています。仮想サーバー内の特定のURIに対する受信リクエストは、適切なサーバー・プールに送信されます。ルートを追加すると、URIの内容に応じて、仮想サーバーがリクエストを別のサーバー・プールに送信できるようになります。
管理コンソールを使用して、表14-7にリストされたルートを作成します。外部Oracle HTTP Serverが使用されている場合、ルートが必要なのはIGDINTERNAL.example.comに対してのみです。他のルーティングはすべてOracle HTTP Server上で行われます。
表14-7 ルートおよび条件
| 仮想ホスト | ルート | オリジン・サーバー・プール | 条件 | Cookie名 |
|---|---|---|---|---|
|
iadadmin.example.com |
デフォルト |
iadadmin-pool |
N/A |
|
|
amaadmin-route |
ama-pool |
$uri= ~'/access' |
||
|
igdadmin.example.com |
デフォルト |
igdadmin-pool |
NA |
|
|
bi-route |
bi-pool |
$usr= ~'/xmlpserver' |
oimjsessionid |
|
|
oim-admin-route |
oim-pool |
$uri =~ '/oim'、 |
||
|
$uri =~ '/identity'、 |
||||
|
$uri =~ '/sysadmin'、 |
||||
|
$uri =~ '/xlWebApp'、 |
||||
|
$uri =~ '/Nexaweb' |
||||
|
login.example.com |
デフォルト |
origin-server-pool-1 |
N/A |
OAM_JSESSIONID |
|
prov.example.com |
デフォルト |
soa_pool |
N/A |
oimjsessionid |
|
oim-prov-route |
oim-pool |
$uri =~ '/identity'、 |
oimjsessionid |
|
|
$uri =~ '/xlWebApp'、 |
||||
|
$uri =~ '/HTTPClnt'、 |
||||
|
$uri =~ '/reqsvc' |
||||
|
igdinternal.example.com |
デフォルト |
oim-pool |
N/A |
oimjsessionid |
|
soa-igdinternal-route |
soa-pool |
$uri =~ '/soa-infra'、 |
oimjsessionid |
|
|
$uri =~ '/sodcheck'、 |
||||
|
$uri =~ '/integration'、 |
||||
|
$uri =~ '/ucs' |
||||
|
iadinternal.example.com |
デフォルト |
iammsm-pool |
N/A |
仮想サーバーのルートを作成する手順:
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
ルートを構成する構成(例: login.example.com)を選択します。
ナビゲーション・ペインで、「仮想サーバー」、「login.example.com」仮想サーバーの順に展開して、「ルート」を選択します。
「ルート」ページが表示されます。仮想サーバーに現在定義されているルートがリストされます。
ルートの作成
「新規ルート」をクリックします。
「新規ルート」ダイアログ・ボックスが表示されます。
「ステップ1: ルート・プロパティ」画面で、「名前」フィールドに「oim-sso-route」と入力します。
「オリジン・サーバー・プール」ドロップダウンで「oim-pool」を選択して、「次へ」をクリックします。
ステップ2: 条件情報画面で、「変数/関数」ドロップダウン・リストから「$uri」変数を選択します。演算子(この例では'= ~ ')を選択します。さらに、「値」フィールドに値を入力します。
|
注意: シーケンスの最初の式には、ジョイナ(andやorなど)は使用できません。 |
「OK」をクリックし、プラス・ボタンをクリックして次の式を追加します。
「変数/関数」、「演算子」および「値」を選択して、「OK」をクリックします。
ジョイナ「or」が選択可能になっていることに注意してください。
必要なすべての値を追加するまで、手順dからgを実行します。
「手動編集」ボタンをクリックして、テキスト・フィールドで式を編集することもできます。手動モードにすると、デフォルトの編集モードには戻れないことに注意してください。手動編集モードで編集を続け、条件を保存する必要があります。
「次へ」、「ルートの作成」の順にクリックします。
作成したルートが「ルート」ページに表示されます。
さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。第14.2.9項「構成のデプロイと仮想サーバー・アドレスのテスト」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。
新規作成したルートとデフォルト・ルートのCookie名を更新します。
新規作成したルートをクリックします。
「詳細設定」を開きます。
「スティッキCookie」を表14-7に記載されたCookie名に設定します。
「スティッキURIパラメータ」を表14-7に記載されたCookie名に設定します。
表14-7にリストされている値について、これらの手順を繰り返します。
「保存」をクリックします。
エンタープライズ・デプロイメントのトポロジでは、SSLはハードウェア・ロード・バランサで終了し、HTTPプロトコルを使用してOracle Traffic Directorにパススルーされます。外部HTTPサーバーが使用されている場合、この項は適用されません。
Oracle Traffic Directorでは、アプリケーションのリダイレクトが正しく行われることを保証するため、追加の構成手順が必要です。
アプリケーションのリダイレクトが正しく行われるようにする手順:
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
ルートを構成する構成(例: login.example.com)を選択します。
ナビゲーション・ペインで、「仮想サーバー」を展開し、仮想サーバー「login.example.com」を選択します。
「ルート」をクリックします。
定義済のルートが表示されます。
ルート(例: default-route)をクリックします。
「ルート・プロパティ」画面が表示されます。
「詳細設定」を開きます。
「ルート・プロパティ」セクションで、「リライト・ヘッダー」ラベルの付いたボックスの内容を削除します。
「オリジン・サーバーに転送されるパラメータ」セクションで、次を選択解除します。
SSL
暗号
キー・サイズ
秘密鍵サイズ
SSL/TLSセッションID
証明書
ユーザーDN
発行者DN
「保存」をクリックします。
仮想サーバーlogin.example.comに関連付けられた各ルートについて、手順を繰り返します。
仮想サーバーprov.example.comに関連付けられた各ルートについて、手順を繰り返します。
OTDが実行されると、/tmpに複数のファイルが作成されます。一時ディレクトリをクリーンアップするUNIXプロセスTMPWATCHによって、これらのファイルが削除される可能性があります。これは、OTDの操作に影響を与えます。
この問題を回避するには、Oracle Traffic Directorにそのファイルを/tmp以外の場所に格納するように通知する必要があります。
このように実行するようにOTDに指示する手順は、次のとおりです。
OTDサーバーの実行に使用しているユーザーと同じユーザーで、tmpという名前のディレクトリをLOCAL_CONFIG_DIRに作成します。
次に例を示します。
mkdir LOCAL_CONFIG_DIR/tmp
このディレクトリを各OTDホストに作成します。
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
「構成」メニューから「詳細設定」をクリックします。
「一般構成」設定で、「一時ディレクトリ」の値をLOCAL_CONFIG_DIR/tmpに更新します。
「保存」をクリックします。
構成をデプロイして、そのインスタンスを管理ノード上に作成します。構成をデプロイすると、実行中のインスタンスが再構成され構成の変更が反映されます。
管理コンソールを使用した構成のデプロイ
管理コンソールを使用して構成をデプロイするには、次の操作を行います。
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
「login.example.com」を選択します。
「デプロイ」をクリックします。
更新された構成が正常にデプロイされたことを確認するメッセージが表示されます。
「閉じる」をクリックします。
リクエストが仮想ホストidstore.example.comまたはIGDINTERNAL.example.comのいずれかに送信されると、そのリクエストは仮想ホスト名に関連付けられたIPアドレスに転送されます。このIPアドレスは、OTDインスタンスのいずれかで有効です。障害が発生すると、IPアドレスはまだ使用可能なOTDインスタンスに移動されます。
各OTDインスタンスは、他のそれぞれのOTDインスタンスとのハートビートを保持します。そのハートビートに障害が発生すると、OTDは、ダウンしているインスタンス上のアクティブなIPアドレスを、指定のフェイルオーバー・インスタンスのいずれかに移動します。このためには、そのIPアドレスに対してアクティブ/パッシブ・フェイルオーバー・グループを作成します。このフェイルオーバー・グループには、1つのプライマリ・インスタンスと複数のセカンダリ・インスタンスがリストされます。
Exalogicでのエンタープライズ・デプロイメントでは、次の4つのフェイルオーバー・グループを使用します。
内部LDAPリクエストを複数のOUDサーバーに分散するためのフェイルオーバー・グループ(1つ)。
内部アプリケーション間リクエスト用のフェイルオーバー・グループ(1つ)。
外部ロード・バランサのリクエストを複数のOracle Traffic Directorサーバーに許可するためのフェイルオーバー・グループ(2つ)。ロード・バランサがOTDインスタンスを直接指している可能性があるため、このフェイルオーバー・グループはオプションです。Oracle Traffic Directorフェイルオーバー・グループを使用する利点は、フェイルオーバー・グループを使用することにより障害を速やかに検出して解決できるため、サーバー障害からのリカバリ時間が短縮されることです。
次の手順では、表14-8の情報を使用してフェイルオーバー・グループを作成する方法を示します。
表14-8 フェイルオーバー・グループの詳細
| 仮想ホスト | ルーターID | ネットワーク接頭辞 | プライマリ・ノード | プライマリ・ネットワーク・インタフェース | セカンダリ・ノード | セカンダリ・ネットワーク・インタフェース |
|---|---|---|---|---|---|---|
|
idstore.example.com |
50 |
19 |
管理ノード |
bond0 |
WEBHOST2 |
bond0 |
|
iadinternal.example.com |
52 |
19 |
WEBHOST2 |
bond0 |
管理ノード |
bond0 |
|
igdinternal.example.com |
53 |
19 |
管理ノード |
bond0 |
WEBHOST2 |
bond0 |
|
webhost1vhn1.example.com |
54 |
19 |
管理ノード |
bond1 |
WEBHOST2 |
bond1 |
|
webhost2vhn1.example.com |
55 |
19 |
WEBHOST2 |
bond1 |
管理ノード |
bond1 |
|
注意: ロード・バランサは2つのOracle Traffic Directorインスタンス間でリスエストをフェイルオーバーするため、外部仮想IPアドレス用のフェイルオーバー・グループはオプションです。ただし、それを使用することで通常のロード・バランサによる監視よりも高速な障害検出とフェイルオーバーが可能です。 |
|
注意: 「ルーターID」は、ルーティングに割り当てる一意の番号です。1 - 244の数値を指定する必要があります。「ネットワーク接頭辞」は、CIDR形式のサブネット・マスクです。 「プライマリ・ノード」は、フェイルオーバー・グループが最初にアクティブになっているノードです。 「プライマリ・ネットワーク・インタフェース」は、フェイルオーバー・グループがバインドされているホスト上のインタフェースです。 「セカンダリ・ノード」は、プライマリ・ノードが使用できない場合にフェイルオーバー・グループを起動できるノードです。 「セカンダリ・ネットワーク・インタフェース」は、セカンダリ・ノード上で使用されるネットワーク・インタフェースです。 |
管理コンソールを使用してフェイルオーバー・グループを作成するには、次の操作を行います:
第31.2項「Identity and Access ManagementコンソールのURLについて」に指定されているURLを使用して、OTD管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
フェイルオーバー・グループを作成する構成(例: login.example.com)を選択します。
ナビゲーション・ペインで、「フェイルオーバー・グループ」をクリックします。
フェイルオーバー・グループ・ページが表示されます。
「新規フェイルオーバー・グループ」をクリックします。
新規フェイルオーバー・グループ・ウィザードが表示されます。
「仮想IP (VIP)」フィールドに、idstore.example.comに関連付けられた仮想IPアドレスを入力します。たとえば、192.168.50.2です。「次へ」をクリックします。
igdinternal.example.comのフェイルオーバー・グループを作成するには、ワークブックに示されている、igdinternal.example.comに関連付けられたVIPを使用します。たとえば、192.168.50.1です。
「ステップ2: フェイルオーバー・ノード情報」画面で、プライマリ・ノードおよびバックアップ・ノード(OTDADMIN、WEBHOST2)を選択し、「次へ」をクリックします。
フェイルオーバー・グループ・ページに、作成したフェイルオーバー・グループの詳細が表示されます。
|
注意: 一般に、「ネットワーク・インタフェース(NIC)」はデフォルト値(「自動検出」)のままでも構いません。デフォルト値のままにすると、Oracle Traffic Director (OTD)がフェイルオーバー・グループのIPアドレスに基づいて、使用するネットワーク・インタフェース・カードを判別します。ただし、これは簡単に導出されるものではなく、たとえば関連付けられたIPアドレスに標準のCIDRが使用されていない場合、どのネットワーク・インタフェースにフェイルオーバー・グループを接続するか、OTDに手動で通知する必要が生じることがあります。
たとえば、内部IPアドレスが192.168.1.1で、 Oracle Traffic Directorはフェイルオーバー・グループを作成する前に、情報を検証します。 次のような検証エラーを受信した場合は、割り当てようとしているIPアドレスがネットワーク・カードの現在の構成と互換性がありません。このエラーが発生した場合は、別のIPアドレス/ネットワークを選択する必要があります。 OTD-67322 The specified virtual IP 'x.x.x.x' cannot be bound to any of the network interfaces on the node 'hostname'. The IP addresses bound to the node are [......] check if the specified virtual IP is in the proper subnet. This error could also be caused if either the network interfaces on the node are not configured correctly or if the network prefix length is incorrect. |
結果画面で、「閉じる」をクリックします。
フェイルオーバー・グループ・ページに、作成したフェイルオーバー・グループの詳細が表示されます。
|
注意: 権限が不足しているために関連するノードでフェイルオーバー・グループを起動できないことを示すメッセージが表示されることがあります。これを解決するには、各ノードにrootとしてログインし、次のコマンドを実行します。OTD_ORACLE_HOME/bin/tadm start-failover --instance-home=WEB_INSTANCE_HOME/ --config=login.example.com |
ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Web層のインストールをバックアップする手順は次のとおりです。
第31.1項「エンタープライズ・デプロイメント・コンポーネントの起動と停止」の説明に従って、インスタンスを停止します。
Web層のMiddlewareホームをバックアップします。Linuxでは、rootとして次のコマンドを使用します。
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
次のコマンドをrootとして使用して、Web層のインスタンス・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
第31.1項「エンタープライズ・デプロイメント・コンポーネントの起動と停止」の説明に従って、インスタンスを起動します。
|
注意: 記載された手順に従って、Web層にあるすべてのマシンでバックアップを作成します。 |
Oracle Traffic Director構成をバックアップします。詳細は、第31.5項「バックアップとリカバリの実行」を参照してください。
