| Oracle® Exalogic Elastic Cloud Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51447-02 |
|
 前 |
 次 |
| Oracle® Exalogic Elastic Cloud Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51447-02 |
|
前 |
次 |
この章では、Oracle SOA Infrastructure Exalogicエンタープライズ・デプロイメント・トポロジの前提条件について説明します。
この章には次のトピックが含まれます:
Exalogic計算ノードでエンタープライズ・デプロイメント用ネットワークを設定するために必要な手順について表3-1で要約しています。
この表は、章で最後のフローに従って見直します。
表3-1 Exalogicエンタープライズ・デプロイメント用ネットワーク構成プロセスの概要
| タスク | 説明 | 詳細情報 |
|---|---|---|
|
SOAエンタープライズ・トポロジで必要なExalogicネットワーク構成の理解 |
エンタープライズ・デプロイメントのネットワークを構成する前に、必要なIPoIBとEoIBのインタフェースやその他の詳細があることを確認することが重要です。 |
第3.2項「SOAエンタープライズ・トポロジのExalogicネットワーク構成について」 |
|
IPoIB用必須仮想IPアドレスの構成 |
IPoIB通信で使用するために特定の仮想IPアドレスがSOA Exalogicエンタープライズ・デプロイメントで必要です。 |
第3.3項「各計算ノードにおけるIPoIB用仮想IPアドレスの構成」 |
|
EoIB用必須仮想IPアドレスの構成 |
EoIB通信で使用するために特定の仮想IPアドレスがSOA Exalogicエンタープライズ・デプロイメントで必要です。 |
第3.4項「各計算ノードにおけるEoIB用仮想IPアドレスの構成」 |
|
必要なホスト名解決と仮想サーバー名の定義 |
ネットワーク変更、システム再配置および障害回復シナリオに対応できるトポロジで、ホスト名解決がSOA Exalogicエンタープライズ・デプロイメントで必要です。 |
|
|
必要な仮想サーバー名の定義 |
仮想サーバー名がIPアドレスに関連付けられていることとDNSの一部であることを確認してください。 |
|
|
外部ハードウェア・ロード・バランサの構成 |
外部の顧客と企業管理者の両方のリクエストを受け入れて、トポロジで適切なURLにルーティングするように外部ハードウェア・ロード・バランサを構成する必要があります。 |
|
|
ファイアウォール・ポートの構成 |
トポロジのファイアウォールをインストールして構成する際、この情報を使用して必要なポートのみを開き、各ポートで適切なタイムアウトを設定します。 |
|
次の各項では、SOAエンタープライズ・トポロジのExalogicネットワーク構成に関する情報が記載されています。
Exalogicシステムを最初に設定すると、IP over Infiniband (IPoIB)がデフォルトで構成されます。IPoIBに加えて、Exalogicラックからイーサネットで公開されるこれらのコンポーネントのEthernet over InfiniBand (EoIB)ネットワーク・アクセスを手動で構成する必要があります。
最適化されたOracle Fusion Middlewareシステムでは、トポロジの様々な要素間における通信が制約されます。そのため、Exalogic Infinibandネットワークでできるだけ多く実行されます。たとえば、コンポーネントはInfinibandインタフェースでリスニングし、適切なゲートウェイへのアクセスでオーバーヘッドを削減して、最適化されたInifibandネットワークを使用する必要があります。
さらに、WebCenterやFusion Middleware SOAなどの他のOracle Fusion Middlewareシステムや、テストや開発などの他のタイプのデプロイメントさえと、同じExalogicラックが共有する際、EoIBアクセスではSOA用に分離されたVLANコネクタが必要な場合があります。ワークロードのこの論理分割とセキュリティ分離の実施にVLANを使用できます。ただし、そのようなVLANの定義についてはこのガイドでは取り扱いません。
ExalogicにおけるOracle Fusion Middleware SOA Exalogicエンタープライズ・デプロイメントのコンポーネント、および使用する通信プロトコルとインタフェースのタイプが図3-1で説明されています。
この章にある各項と図3-1で使用されるIPアドレス(192.168.10.1などの内部IPアドレスと10.10.10.1などの外部IPアドレスの両方)は例であり、このドキュメント全体で一貫して使用されています。ただし、他のIPは有効です。順番に従ってサーバーのタイプをIP範囲で分けることをお薦めします。たとえば、Oracle Traffic Directoの場合は192.168.50.xで、SOAの場合は192.168.20.xです。使用するサブネット・マスクによってこれらの範囲は異なりますが、IP追跡管理が容易になります。
ネットワーク・マップ・ダイアグラムの詳細は、次を参照してください。
ネットワーク・マップ・ダイアグラムに示されるサブインタフェースとネットワーク・ダイアグラムの説明については、第3.2.3項「ネットワーク・インタフェース・マップの説明」を参照してください。
IPoIB (bond0)インタフェースとサブインタフェースに割り当てる必要がある仮想IPアドレスのサマリーや、IPoIBインタフェースを作成するための指示については、第3.3項「各計算ノードにおけるIPoIB用仮想IPアドレスの構成」を参照してください。
EoIB (bond1)インタフェースとサブインタフェースに割り当てる必要がある仮想IPアドレスのサマリーや、Exalogic EoIBネットワークとEoIB用仮想IPアドレスを構成するための指示については、第3.4項「各計算ノードにおけるEoIB用仮想IPアドレスの構成」を参照してください。
Admin、SOA、WSMおよびOSBのサーバー・ネットワーク・インタフェースに関連付けられるIPアドレスの詳細は、表3-4を参照してください。
次の各項では、図3-1で示す様々なネットワーク・インタフェースについて説明します。
InfiniBandファブリックで内部であると期待されているSOAサーバーと他のコンシューマによりデフォルトbond0インタフェースを使用してOWSM管理対象サーバーにアクセスします。OWSMサーバーをExalogic計算ノードの外部からアクセスする必要はありません。そのため、OWSMサーバーでEoIBインタフェースを使用する必要はありません。
SOAサーバーでは、EoIBとIPoIBの両方のインタフェースでリスニングを行います。
それらのデフォルト・チャネルでは、IPoIBリスニング・アドレスを使用します。これは、最適化されたサーバー間呼出し用であり、Coherenceデハイドレーションとデプロイメント最適化用でもあります。
サーバー移行の詳細は、第13章「Exalogicエンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。
各サブインタフェースに割り当てる仮想IPアドレスの詳細は、第3章「各計算ノードにおけるIPoIB用仮想IPアドレスの構成」を参照してください。
IPoIBインタフェースに加えて、SOA管理対象サーバーでEoIB仮想IPアドレスもリスニングします。これによって、次の目的のために外部的にアクセスできます。
RMI/JMX/T3呼出し
Jdevからリモート・デプロイメントで使用されるHTTP呼出し。
外部JMSプロデューサとコンシューマ。
SOAサーバーの直接リスニング・アドレスを使用する他の操作
T3とHTTPで別々のチャネルを使用して、異なるタイプの外部トラフィックを分離する場合があります。
SOAサーバーではサーバー移行が使用されます。これによって、EoIBとIPoIBの両方でフローティングIPで構成されます。
Oracle Service Busサーバーでは、EoIBとIPoIBの両方のインタフェースでもリスニングを行います。
それらのデフォルト・チャネルでは、IPoIBリスニング・アドレスを使用します。これは、最適化されたサーバー間呼出し用であり、Coherence結果キャッシュ用でもあります。
SOA管理対象サーバーのように、Oracle Service Busサーバーではサーバー移行を利用します。結果として、フローティングIPがEoIBとIPoIBの両方で構成されます。
IPoIBインタフェースに加えて、Oracle Service Bus管理対象サーバーでEoIBインタフェースもリスニングします。これによって、次の目的のために外部的にアクセスできます。
RMI/JMX/T3呼出し
外部JMSプロデューサとコンシューマ。
Oracle Service Busサーバーでは、T3とHTTPで別々のチャネルを使用して、異なるタイプのトラフィックを分離する場合があります。
Oracle Traffic Directorインスタンスは、計算ノード1と計算ノード2でインストールされます。
ANY/*でリスニングするリスナーのあるインスタンス2つにOracle Traffic Director構成がデプロイされます。さらに分離するには、Oracle Traffic Director EoIBインタフェース(2つのOracle Traffic Directorノード間でリクエストを分散するためにフロント・エンド・ロード・バランサで使用されます)を残りのEoIBアドレスから別のVLANに関連付けることができます。EoIBネットワークで外部的にフロント・エンド・ロード・バランサによりリスナーにアクセスできますし、IPoIBネットワークでアプリケーション層コンポーネントにより内部的にもアクセスできます。
ロード・バランシングと高可用性の場合、4つの仮想IPがOracle Traffic Directorフェイルオーバー・グループにマップされます。2つは外部アクセス用、1つはSOA内部アクセス用、1つはOSB内部アクセス用です。
Oracle Traffic Director管理サーバーではEoIB仮想IPアドレスを使用するので、別の管理ノード(このフェイルオーバー・ノードはOracle Traffic Director管理ノードをホストできません)にフェイルオーバーできます。OTD管理サーバーの仮想IPアドレスはフェイルオーバー・グループの一部ではないことに注意してください。OTD管理サーバーをフェイルオーバーするには、OTD管理ノードが含まれていない別のノードで管理サーバー・インスタンスのバックアップとリカバリを行う(または共有マウントを使用する)必要があります。
WebLogic Server管理サーバーはEoIBやIPoIBでリスニングでき、Oracle Traffic Directorにより外部の世界に公開できます。管理サーバーで実行される操作のタイプによって適切な手法が決まります。たとえば、JMX管理とメトリックが外部的にアクセスされると、ほとんどの場合に発生するように、EoIBが必要です。SOAシステムの典型的なライフサイクルにおいて、管理サーバーをデプロイメント操作で外部クライアントから使用する場合、管理サーバーのデフォルト・チャネルはEoIB IPアドレスを使用する必要があります。
理想的には、管理やデプロイメントなど、異なるタイプのトラフィックは、ランタイム呼出しとは反対に、互いに分離する必要があります。このため、管理サーバーのEoIBアドレスとSOA/OSBサーバーのEoIBアドレスが別々のVLANに配置される場合があります。これが必要かどうかは、各システムで行われる管理操作とデプロイメント操作のタイプによって異なります。単純にするため、同じVLANとパーティションにSOA/OSBサーバーと管理サーバーEoIBが存在するモデルをこのガイドで使用します。
ネットワーク・インタフェースは、次の目的でも使用されます。
計算ノードに割り当てられたデフォルトIPoIBアドレスをノード・マネージャで使用します。
このExalogicエンタープライズ・デプロイメント・トポロジのデータベースは、EoIBを使用してアクセスされます。
この項の内容は、次のとおりです。
IPoIBネットワークにおけるすべての通信では、デフォルトのbond0インタフェース、およびExalogicのハードウェアとソフトウェアを設定する際にデフォルトでこのインタフェースに割り当てられたIPアドレスが、WEBHOST計算ノードとWSM管理対象サーバーで使用されます。
ただし、第3.2.3.2項「SOA管理対象サーバーとの通信」で説明しているように、bond0ネットワーク・インタフェースのサブインタフェースを使用するようにSOAとOracle Service Busの管理対象サーバーが構成されている必要があります。
SOAHOST1とSOAHOST2でSOAとOracle Service Busの管理対象サーバー用に定義する必要がある仮想IPが表3-2に記載されています。
これらの仮想IPアドレスを定義する方法の詳細は、第3.3項「各計算ノードにおけるIPoIB用仮想IPアドレスの構成」を参照してください。
表3-2 IPoIBネットワーク・インタフェースに関連付けられる仮想IPアドレス
| インタフェース | アドレス例 | ネットワーク例 | 使用者 | デフォルト・ホスト |
|---|---|---|---|---|
|
BOND0:1 |
192.168.20.3 |
255.255.240.0 |
WLS_SOA1 (デフォルト・チャネル) |
SOAHOST1 |
|
BOND0:1 |
192.168.20.4 |
255.255.240.0 |
WLS_SOA2 (デフォルト・チャネル) |
SOAHOST2 |
|
BOND0:2 |
192.168.40.3 |
255.255.240.0 |
WLS_OSB1 (デフォルト・チャネル) |
SOAHOST1 |
|
BOND0:2 |
192.168.40.4 |
255.255.240.0 |
WLS_OSB2 (デフォルト・チャネル) |
SOAHOST2 |
|
BOND0:1 |
192.168.50.1 |
255.255.220.0 |
SOAのOTDフェイルオーバー・グループ脚注 1 |
WEBHOST1 |
|
BOND0:1 |
192.168.50.2 |
255.255.220.0 |
SOAのOTDフェイルオーバー・グループ脚注参照 1 |
WEBHOST2 |
脚注 1 これらの仮想IPアドレスがOTD/VRRPで管理され、ifconfigで明示的に有効にする必要はありません。
表3-2に記載されている各IPアドレスをSOAHOST1とSOAHOST2で有効にするには:
ifconfigコマンドを使用して仮想IPを作成します。
ifconfig subinterface virtual_ip_address netmask netmask_value
たとえば、SOAHOST1で、次を入力します。
ifconfig bond0:1 192.168.20.3 netmask 255.255.240.0 ifconfig bond0:2 192.168.40.3 netmask 255.255.240.0
定義した各仮想IPアドレスに対して、次のコマンドを使用してARPキャッシュを更新します。
arping -b -A -c 3 -I bond0 192.168.20.3
IPアドレスを追加したら、適切なIPoIBインタフェースを使用して、Oracle Traffic Directorノードと他のSOAHOSTからアクセスできることを確認してください。次に例を示します。
SOAHOST1から、次のコマンドを実行します。
ping -I bond0 192.168.20.4
SOAHOST2:
ping -I bond0 192.168.20.3
ExalogicでSOA Exalogicエンタープライズ・デプロイメント用にEoIBネットワークと必須仮想IPアドレスを作成する方法の詳細は、次の各項を参照してください。
各計算ノードで各EoIBインタフェースに関連付けられている必要がある仮想IPアドレスが表3-3に記載されています。これらの各インタフェースを図3-1に示します。
仮想ホストを定義するには、各計算ノードのEthernet用仮想ネットワーク・インタフェース・カード(VNIC)インタフェースを含めて、EoIBネットワークをExalogicで構成する必要があります。詳細は、第3.4.2項「SOAエンタープライズ・トポロジ用EoIBネットワークの構成」を参照してください。
表3-3 EoIBネットワークと関連ネットワーク・インタフェースの仮想IPアドレス
| インタフェース | アドレス例 | ネットワーク例 | サーバーで使用 | ホスト |
|---|---|---|---|---|
|
BOND1:1 |
10.10.30.1 |
255.255.220.0 |
AdminServer (デフォルト・チャネル) |
SOAHOST1 |
|
BOND1:2 |
10.10.20.3 |
255.255.220.0 |
WLS_SOA1 (HTTPとT3チャネル) |
SOAHOST1 |
|
BOND1:2 |
10.10.20.4 |
255.255.220.0 |
WLS_SOA2 (HTTPとT3チャネル) |
SOAHOST2 |
|
BOND1:3 |
10.10.40.3 |
255.255.220.0 |
WLS_OSB1 (HTTPとT3チャネル) |
SOAHOST1 |
|
BOND1:3 |
10.10.40.4 |
255.255.220.0 |
WLS_OSB2 (HTTPとT3チャネル) |
SOAHOST2 |
|
BOND1:1 |
10.10.20.1 |
255.255.220.0 |
OTD管理サーバー |
WEBHOST1 |
|
BOND1:2 |
10.10.40.1 |
255.255.220.0 |
OTD外部フェイルオーバー・グループ1脚注 1 |
WEBHOST1 |
|
BOND1:1 |
10.10.40.2 |
255.255.220.0 |
OSB外部フェイルオーバー・グループ脚注参照 1 |
WEBHOST2 |
脚注 1 これらの2つのEoIB仮想IPアドレスはオプションで、Oracle Traffic Directorアクセス・ポイントのVLAN分離に使用されますが、VRRP OTDを使用することで高速な障害検出にも使用されます。
Ethernet over Infiniband (EoIB)ネットワークをExalogicで構成する方法の詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』に記載されています。ここに記載された手順は、SOA Exalogicエンタープライズ・トポロジ用EoIBネットワークの構成に特有です。
適切なVNICとVLAN関連付けや、EoIB仮想IPをSOAHOST1とSOAHOST2で作成します。
|
注意: Oracle Traffic Directorアクセス・アドレスのVLAN分離では、適切なVNICSとEoIB仮想IPアドレスが、WEBHOST1とWEBHOST2のOracle Traffic Directorリスナー用アクセス・ポイントとして構成されている必要があります。さらに、別のVLANが作成されている必要があります。 |
SSHクライアント(PuTTYなど)を使用して、Sun Network QDR InfiniBandゲートウェイ・スイッチにログインします。ilom-adminとしてサインインし、Oracle ILOM CLIの/SYS/Fabric_Mgmt Linuxシェル・ターゲットを介してコマンドを実行することをお薦めします。
VNICとVLAN関連付けを作成するには:
el01gw04にilom-adminとしてログインします。
コマンド・プロンプトで、次を実行します。
listlinkup | grep Bridge
出力例:
Bridge-0 Port 0A-ETH-1 (Bridge-0-2) up (Enabled) Bridge-0 Port 0A-ETH-2 (Bridge-0-2) down (Enabled) Bridge-0 Port 0A-ETH-3 (Bridge-0-1) down (Enabled) Bridge-0 Port 0A-ETH-4 (Bridge-0-1) down (Enabled) Bridge-1 Port 1A-ETH-1 (Bridge-1-2) down (Enabled) Bridge-1 Port 1A-ETH-2 (Bridge-1-2) down (Enabled) Bridge-1 Port 1A-ETH-3 (Bridge-1-1) down (Enabled) Bridge-1 Port 1A-ETH-4 (Bridge-1-1) down (Enabled)
この例で、アップリンクをゲートウェイで識別し、VNICの作成で使用するイーサネット・コネクタを調べます。この例では、アップリンクはOA-ETH-1です。
次のように、VNICを必要とするExalogic計算ノードのGUIDを調べます。
VNICを必要とする計算ノードにrootとしてログインし、ibstatコマンドを実行します。たとえば、el01cn01にrootとしてログインします。
el01cn01# ibstat
CA 'mlx4_0'
CA type: MT26428
Number of ports: 2
Firmware version: 2.7.8100
Hardware version: b0
Node GUID: 0x0021280001a0a364
System image GUID: 0x0021280001a0a367
Port 1:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 120
LMC: 0
SM lid: 6
Capability mask: 0x02510868
Port GUID: 0x0021280001a0a365
Link layer: IB
Port 2:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 121
LMC: 0
SM lid: 6
Capability mask: 0x02510868
Port GUID: 0x0021280001a0a366
Link layer: IB
出力には、2つのポートに関する情報が含まれます。VNICの作成に使用するポートのGUIDおよびBase lidを識別します。
この手順の例では、GUID 0x0021280001a0a366およびBase lid 121のポートを使用します。
同じ計算ノードで次のコマンドを実行して、InfiniBandファブリックでアクティブなリンクに関する情報を表示します。
hostname# iblinkinfo.pl -R | grep hostname
hostnameは、計算ノードの名前です。計算ノードの結合されたIPoIBアドレスも指定できます。
次に例を示します。
el01cn01# iblinkinfo.pl -R | grep el01cn01
65 15[ ] ==( 4X 10.0 Gbps Active/ LinkUp)==> 121
2[ ] "el01cn01 EL-C 192.168.10.3 HCA-1" (Could be 5.0 Gbps)
64 15[ ] ==( 4X 10.0 Gbps Active/ LinkUp)==> 120
1[ ] "el01cn01 EL-C 192.168.10.3 HCA-1" (Could be 5.0 Gbps)
iblinkinfoコマンドの出力から、前述で示した計算ノード・ポートのBase lid (最初の行の121)に関連付けられているスイッチlid値(最初の列の65)が存在することに注意してください。
ibswitchesコマンドを実行して、スイッチlid 65に対応するゲートウェイ・スイッチを判別します。
el01cn01# ibswitches
Switch : 0x002128548042c0a0 ports 36 "SUN IB QDR GW switch el01gw03" enhanced port 0 lid 63 lmc 0
Switch : 0x002128547f22c0a0 ports 36 "SUN IB QDR GW switch el01gw02" enhanced port 0 lid 6 lmc 0
Switch : 0x00212856d0a2c0a0 ports 36 "SUN IB QDR GW switch el01gw04" enhanced port 0 lid 65 lmc 0
Switch : 0x00212856d162c0a0 ports 36 "SUN IB QDR GW switch el01gw05" enhanced port 0 lid 64 lmc 0
lid 65は、GUID 0x00212856d0a2c0a0のゲートウェイ・スイッチel01gw04に対応します。
次の形式のダミーMACアドレスを定義します。
last3_octets_of_switchGUID : last3_octets_of_computenode_adminIP_in_hex_format
次に例を示します。
スイッチのGUID: 00:21:28:56:d0:a2:c0:a0
最後の3つのオクテット値: a2:c0:a0
VNICを必要とする計算ノードの管理IP: 192.168.10.3 (SOAHOST1用)
最後の3つのオクテット値: 168.10.3 (16進数ではa8:0A:03)
MACアドレス: a2:c0:a0:a8:0A:03
|
注意: ダミーMACアドレスは、Exalogicネットワークで一意である必要があります。MACアドレス(ユニキャスト)の最上位タイプでは、偶数のみがサポートされています。前述のアドレスは例です。 |
手順4で識別したゲートウェイ・スイッチ(el01gw04)に、ilom-adminとしてログインします。
次のコマンドを実行し、使用するVLANにコネクタを関連付けます。
gwhostname# createvlan connector -vlan 0 -pkey default
次に例を示します。
e101gw04# createvlan OA-ETH-1 -vlan 0 -pkey default
次のコマンドを実行して、VNICを作成します。
gwhostname# createvnic connector -guid compute_node_port_GUID -mac unique_mac_address -pkey default
次に例を示します。
el01gw04# createvnic 1A-ETH-3 -guid 0021280001a0a366 -mac a2:c0:a0:a8:0A:03 -pkey default -vlan 0
VNICが作成されます。
VNICを確認するには、スイッチのCLIで、showvnicsコマンドを実行します。ホスト名をGrep検索し、ステータスがUPであることを確認します。
el01gw04# showvnics | grep el01cn01 94 UP N 0021280001EFA4BF el01cn01EL-C 192.168.10.3 0000 24:C0:A0:85:2F:2E 0 ffff 1A-ETH-3
計算ノードで次のコマンドを実行して、その計算ノードで使用できるVNICを一覧表示します。
el01cn01# mlx4_vnic_info -l
このコマンドは、計算ノードに存在するeth4などの新しいインタフェースの名前を表示します。このIDを書き留めておきます。
同じ計算ノードに対して別のVNICを作成しますが、別のゲートウェイ・スイッチのコネクタを使用します。このVNICのethX IDも書き留めておきます。
2つのEoIBインタフェースは、bond1などの結合されたインタフェースとして構成することをお薦めします。
計算ノードで、VNIC用のインタフェース・ファイルを作成します。
フェイルオーバーが適切に動作するために、VNICインタフェース・ファイルの名前とそのインタフェース・ファイルのDEVICEディレクティブ値が、カーネルに割り当てられたethXインタフェース名(eth4、eth5など)に基づいてはいけません。かわりに、インタフェース・ファイル名とそのインタフェース・ファイルのDEVICEディレクティブ値を、EPORT_IDおよびIOA_PORTの値から導出することをお薦めします。
|
注意: それ以外の一意の名前付け方式も利用できます。 |
次のコマンドを実行して、EPORT_IDを見つけます。
#mlx4_vnic_info -i ethX | grep EPORT_ID
次に例を示します。
e101cn01#mlx4_vnic_info -i eth4 | grep EPORT_ID EPORT_ID 331
表示されたEPORT_ID(この例では331)に注意してください。
次のコマンドを実行して、IOA_PORTを見つけます。
#mlx4_vnic_info -i ethX | grep IOA_PORT
次に例を示します。
e101cn01#mlx4_vnic_info -i eth4 | grep IOA_PORT IOA_PORT mlx4_0:1
表示されたIOA_PORT値のコロン(:)の後の数値(この例では1)に注意してください。
次の表記法を使用して、インタフェース・ファイル名とデバイス名を作成します。
インタフェース・ファイル名: ifcfg-ethA_B
デバイス名: ethA_B
AはEPORT_ID、BはIOA_PORT値のコロン(:)後の数値です。
次に例を示します。
インタフェース・ファイル名: ifcfg-eth331_1
デバイス名: eth331_1
この例では、331はEPORT_ID、1はIOA_PORTからの導出値です。
VIなどのテキスト・エディタを使用して、例で最初のVNIC ( eth4)用にインタフェース・ファイルを作成し、ファイルを次のディレクトリに保存します。
/etc/sysconfig/network-scripts
ファイルを次のディレクトリに保存します。
/etc/sysconfig/network-scripts
次に例を示します。
# more /etc/sysconfig/network-scripts/ifcfg-eth331_1 DEVICE=eth331_1 BOOTPROTO=none ONBOOT=yes HWADDR= a2:c0:a0:a8:0A:03 MASTER=bond1 SLAVE=yes
|
注意:
|
2つ目のVNIC( たとえば、eth5)のインタフェース・ファイルを作成します。
前述の説明のとおり、カーネルに割り当てられた名前ではなく、導出されたインタフェース名を使用して、インタフェース・ファイルの名前を付けてDEVICEディレクティブを指定してください。また、HWADDRディレクティブで適切なダミーMACアドレスを指定してください。
インタフェース・ファイルを作成したら、ifcfg-bond1ファイルを作成します。このファイルがすでに存在する場合、その内容を検証してください。
次に例を示します。
# more /etc/sysconfig/network-scripts/ifcfg-bond1 DEVICE=bond1 IPADDR=192.168.48.128 NETMASK=255.255.240.0 BOOTPROTO=none USERCTL=no TYPE=Ethernet ONBOOT=yes IPV6INIT=no BONDING_OPTS="mode=active-backup miimon=100 downdelay=5000 updelay=5000" GATEWAY=192.168.48.1
ifup コマンドを使用して、新しいbond1インタフェースを起動します。
計算ノードを再起動して、変更内容を有効にします。
SOAHOST2、WEBHOST1およびWEBHOST2の必須VNICで前述の手順を繰り返します。
表3-3を確認してから、第3.3.2項「SOAHOST1とSOAHOST2におけるIPoIBネットワーク用仮想IPアドレスの作成」の指示を使用して、表の各仮想IPを作成します。
表に記載されているサブインタフェース(bond1:n)と仮想IPアドレスを必ず関連付けてください。
異なる仮想IPアドレスにおける接続性を確認してください。追加された仮想IPアドレスがすべて外部的にアクセスでき(特にロード・バランサ・ホスト)、bond1インタフェースを使用してノード自体からもアクセスできることを確認してください。
次のコマンドをSOAHOST1とSOAHOST2から実行します。
ping -I bond1 10.10.30.1 ping -I bond1 10.10.20.3 ping -I bond1 10.10.20.4 ping -I bond1 10.10.40.3 ping -I bond1 10.10.40.4
次のコマンドをWEBHOST1とWEBHOST2から実行します。
ping -I bond1 10.10.20.1 ping -I bond1 10.10.40.1 ping -I bond1 10.10.40.2 ping -I bond1 10.10.40.3 ping -I bond1 10.10.40.4 ping -I bond1 lbr_address
|
注意: ネットマスク例で示すように、10.10.20.X、10.10.30.xおよび10.10.40.Xの範囲を使用して、割当てのスケール・アップやスケール・アウトを容易にします。複数の仮想IPが互いに到達可能でサブネットに存在するかぎり、他の値を使用できます。 |
ネットワーク変更、システム再配置および障害回復シナリオに対応できるトポロジ設計で、適切なホスト名解決が重要です。必要なDNS (/etc/hostsまたは中央DNSサーバー)定義が配置され、IPと仮想IPを直接使用かわりにホスト名と仮想ホスト名をWebLogic Serverで使用することが重要です。さらに、外部ロード・バランサとOracle Traffic Directorサーバーによりトポロジ内で適切なサーバーやサービスにリクエストがルーティングされるために、Exalogicエンタープライズ・デプロイメントでは、仮想サーバー名のセットが必要です。
これらの仮想サーバー名は、社内ネットワークで有効にされている必要があります。IPoIBアドレスをラックの名前解決システム内部のみで解決する必要があります。複数のラックが接続される場合、潜在的なIP競合を予防するには、これらも中央DNSサーバーに配置することをお薦めします。全社レベルのネットワーク管理者は、これを有効にする必要があります。または、異なるノードで伝播される適切な/etc/hostsファイルにより、ホスト名を解決できます。SOAシステムのサーバーで使用される異なるフローティングIPアドレスの名前の例が、表3-4に記載されています。
表3-4では、接尾辞のPRIV-Vnが含まれる仮想ホスト名は、内部InfiniBandファブリックのネットワーク・インタフェースにルーティングされるIPoIB仮想IPアドレスにマップされます。-PRIV-Vn接尾辞のないアドレスは、外部EoIBネットワークのネットワーク・インタフェースにルーティングされるEoIB仮想IPアドレスにマップされます。
表3-4 ホスト名と仮想IP情報
| このガイドにおけるホスト名例 | IP例とインタフェース | タイプ | ホスト | バインド | 詳細 |
|---|---|---|---|---|---|
|
ADMINVHN |
10.10.30.1/bond1:1 |
EoIB /Floating |
ComputeNode3/SOAHOST1 |
管理サーバー |
手動で管理サーバーをComputeNode3からComputeNode4に移行する場合、管理サーバーにフローティングIPアドレスを使用することをお薦めします。 |
|
OTDADMINVHN |
10.10.20.1/bond1:1 |
EoIb /Floating |
ComputeNode1/WEBHOST1 |
OTD管理サーバー |
手動でOTD管理サーバーをComputeNode1からComputeNode2に移行する場合、管理サーバーにフローティングIPアドレスを使用することをお薦めします。 |
|
WEBHOST1-PRIV |
192.168.10.1/bond0 |
IPoIB/ Fixed |
ComputeNode1/WEBHOST1 |
NA |
|
|
WEBHOST2-PRIV |
192.168.10.2/bond0 |
IPoIB/ Fixed |
ComputeNode2/WEBHOST2 |
NA |
|
|
WEBHOST1-PRIV-V1 |
192.168.50.1/bond0 |
IPoIB/Floating |
ComputeNode1/WEBHOST1 |
OTD SOA内部フェイルオーバー・グループ |
このVHNのIPは、OTDで管理されます。WLS_SOAnサーバーにルーティングするIPoIBで使用します。 |
|
WEBHOST2-PRIV-V2 |
192.168.50.2/bond0 |
IPoIB/Floating |
ComputeNode2/WEBHOST2 |
OTD OSB内部フェイルオーバー・グループ |
このVHNのIPは、OTDで管理されます。WLS_OSBnサーバーにルーティングするIPoIBで使用します。 |
|
WEBHOST1VHN1 |
10.10.40.1/bond1 |
EoIB/Floating |
ComputeNode1/WEBHOST1 |
OTD SOA/OSB外部ルーティング・フェイルオーバー・グループ |
このVHNのIPは、OTDで管理されます。外部公開EoIBとして使用されます。これは、フロント・エンド・ロード・バランサがそのプールに追加するVHNです。 |
|
WEBHOST2VHN1 |
10.10.40.2/bond1 |
EoIB/Floating |
ComputeNode2/WEBHOST2 |
OTD SOA/OSB外部ルーティング・フェイルオーバー・グループ |
このVHNのIPは、OTDで管理されます。外部公開EoIBとして使用されます。これは、フロント・エンド・ロード・バランサがそのプールに追加するVHNです。 |
|
SOAHOST1-PRIV |
192.168.10.3/bond0 |
IPoIB/ Fixed |
ComputeNode3/SOAHOST1 |
ノード・マネージャとWLS_WSM1 |
ComputeNode3で実行されるWSM1とノード・マネージャで使用される |
|
SOAHOST2-PRIV |
192.168.10.4/bond0 |
IPoIB/ Fixed |
ComputeNode4/SOAHOST2 |
ノード・マネージャとWLS_WSM2 |
ComputeNode4で実行されるWSM2とノード・マネージャで使用される |
|
WEBHOST1-PRIV-V1 |
192.168.50.1/bond0:1 |
IPoIB/ Floating |
ComputeNode1/WEBHOST1 |
OTDインスタンス1フェイルオーバー・グループ |
ComputeNode1で最初に有効にされていると、OTDによりComputeNode2にフェイルオーバーできます。 |
|
WEBHOST2-PRIV-V1 |
192.168.50.2/bond0:1 |
IPoIB/ Floating |
ComputeNode2/WEBHOST2 |
OTDインスタンス2フェイルオーバー・グループ |
ComputeNode1で最初に有効にされていると、OTDによりComputeNode2にフェイルオーバーできます。 |
|
SOAHOST1-PRIV-V1 |
192.168.20.3/bond0:1 |
IPoIB/ Floating |
ComputeNode3/SOAHOST1 |
WLS_SOA1デフォルト・チャネル |
ComputeNode3で最初に有効にされていると、サーバー移行によりComputeNode4にフェイルオーバーできます。 |
|
SOAHOST2-PRIV-V1 |
192.168.20.4/bond0:1 |
IPoIB/ Floating |
ComputeNode4/SOAHOST2 |
WLS_SOA2デフォルト・チャネル |
ComputeNode4で最初に有効にされていると、サーバー移行によりComputeNode3にフェイルオーバーできます。 |
|
SOAHOST1-PRIV-V2 |
192.168.40.3/bond0:3 |
IPoIB/ Floating |
ComputeNode3/SOAHOST1 |
WLS_OSB1 DEFAULT CHANNEL |
ComputeNode3で最初に有効にされていると、サーバー移行によりComputeNode4にフェイルオーバーできます。 |
|
SOAHOST2-PRIV-V2 |
192.168.40.4/bond0:3 |
IPoIB/ Floating |
ComputeNode4/SOAHOST2 |
WLS_OSB2 DEFAULT CHANNEL |
ComputeNode4で最初に有効にされていると、サーバー移行によりComputeNode3にフェイルオーバーできます。 |
|
SOAHOST1VHN1 |
10.10.20.3/bond1:2 |
EoIB/ Floating |
ComputeNode3/SOAHOST1 |
WLS_SOA1の外部HTTP/T3チャネル |
ComputeNode3で最初に有効にされていると、サーバー移行によりComputeNode4にフェイルオーバーできます。 |
|
SOAHOST2VHN1 |
10.10.20.4/bond1:2 |
EoIB/ Floating |
ComputeNode4/SOAHOST2 |
WLS_SOA2の外部HTTP/T3チャネル |
ComputeNode4で最初に有効にされていると、サーバー移行によりComputeNode3にフェイルオーバーできます。 |
|
SOAHOST1VHN2 |
10.10.40.3/bond1:3 |
EoIB/ Floating |
ComputeNode3/SOAHOST1 |
WLS_OSB1の外部HTTP/T3チャネル |
ComputeNode3で最初に有効にされていると、サーバー移行によりComputeNode4にフェイルオーバーできます。 |
|
SOSHOST2VHN2 |
10.10.40.4/bond1:3 |
EoIB/ Floating |
ComputeNode4/SOAHOST2 |
WLS_OSB2の外部HTTP/T3チャネル |
ComputeNode4で最初に有効にされていると、サーバー移行によりComputeNode3にフェイルオーバーできます。 |
SOAエンタープライズ・デプロイメントでは、次の仮想サーバー名を使用します。
仮想サーバー名がIPアドレスに関連付けられていることとDNSの一部であることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できることが必要です。
第3.7項「ロード・バランサの構成」の手順を使用してロード・バランサで仮想サーバー名を定義します。
|
注意: 仮想サーバー名はここで、企業ネットワークで利用可能な実際のアドレスに関係します(そして、一部は外部的にインターネットでも同様です)。これらの仮想サーバーでは同じ名前を使用しますが、Oracle Traffic Directorで定義されている仮想サーバーとは異なるエンティティです。ここに記載された仮想サーバー名は、実際のIPにマップされます。OTDで使用される仮想サーバー名は、適切なルーティング用にOTDで定義される管理エンティティです。 |
この仮想サーバー名は、soa-infraやワークフローなどのランタイムSOAコンポーネントへのすべてのHTTPトラフィック用のアクセス・ポイントとして動作します。SSL/HTTPSへの非SSL/HTTPトラフィックのリダイレクションが構成されますクライアントはsoa.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。
この仮想サーバー名は、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィック用のアクセス・ポイントとして動作します。
クライアントからの受信トラフィックでは、SSLは有効でありません。クライアントはadmin.mycompany.com:80のアドレスを使用してこのサービスにアクセスし、リクエストがWEBHOST1とWEBHOST2のポート7777に転送されます。
この仮想サーバー名は、ランタイムOracle Service Busリソースとプロキシ・サービスへのすべてのHTTPトラフィック用のアクセス・ポイントとして動作します。SSL/HTTPSへの非SSL/HTTPトラフィックのリダイレクションが構成されますクライアントはosb.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。
この仮想サーバー名は、SOAサービスの内部呼出しで使用されます。このURLはインターネットに公開されないので、イントラネットからのみアクセスできます。SOAシステムの場合、コンポジットをモデリングする際や実行時に適切なEM/MBeansで、内部サービス呼出しで使用されるURLとしてユーザーはこの値を設定できます。ただし、コールバックや内部Webサービスのような呼出しでは、InfiniBandで最適パフォーマンスのためにOTDでアドレスを使用します。詳細は、第7.7項「Exalogicエンタープライズ・デプロイメント向けOracle Traffic Director仮想サーバーの定義」を参照してください。
クライアントからの受信トラフィックでは、SSLは有効でありません。Oracle Traffic Directorフェイルオーバー・グループとして有効化されているsoainternal.mycompany.com:80のアドレスをクライアントは使用してこのサービスにアクセスします。
異なるタイプのネットワーク・トラフィックとモニタリング用にロード・バランサで仮想サーバーと関連ポートが構成されている必要があります。これらは、適切な実際のホストとポートでサービスが実行されるように構成されている必要があります。また、実際のホストとポートが利用できるようにモニターするようにロード・バランサが構成されている必要があります。これによって、サービスが停止した場合にできるかぎり早くこれらへのトラフィックが停止します。これによって、他の層における利用不可サービスに指定仮想ホストの受信トラフィックが転送されなくなります。
この項の内容は次のとおりです。
エンタープライズ・トポロジでは、外部ロード・バランサを使用します。外部ロード・バランサには、次の機能が必要です。
仮想ホスト名を通じて実際のサーバーのプールにトラフィックをロード・バランシングできること: クライアントは(実際のホスト名を使用するかわりに)仮想ホスト名を使用してサービスにアクセスします。ロード・バランサはこれを受けて、リクエストをプール内のサーバーにロード・バランシングします。
ポート変換構成。
ポートのモニタリング(HTTPとHTTPS)。
仮想サーバー名とポートを外部ロード・バランサで構成できる機能。仮想サーバー名とポートは、次の要件を満たす必要があります。
ロード・バランサでは、仮想サーバーを複数構成できる必要があります。それぞれの仮想サーバーについて、ロード・バランサでは、複数のポート上でのトラフィック管理を構成できる必要があります。たとえば、Oracle WebLogicクラスタについては、ロード・バランサは、HTTPおよびHTTPSのトラフィック用に、仮想サーバーおよびポートとともに構成されている必要があります。
仮想サーバー名をIPアドレスに関連付け、DNSに含める必要があります。クライアントは、仮想サーバー名を通じて外部ロード・バランサにアクセスできる必要があります。
ノードの障害を検出し、障害の発生したノードへのトラフィックのルーティングを即座に停止できること。
リソース・モニタリング/ポート・モニタリング/プロセス障害検出: ロード・バランサはURL、サービスおよびノードの障害を(通知などの手段により)検出して、非Oracle Netトラフィックを障害ノードに転送する処理を停止できる必要があります。外部ロード・バランサで自動的に障害を検出できる場合、使用する必要があります。
フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードに構成しておくことを強くお薦めします。
トラフィック転送先のバックエンド・サービスが利用できなくなるとロード・バランサの仮想サーバーで即座に制御をコール元クライアントに戻すように構成することを強くお薦めします。クライアント計算ノードのTCP/IP設定に基づいてタイムアウト後にクライアント自身が接続を切断するよりも好ましい構成です。
SSLアクセラレーション(この機能をお薦めしますが必須ではありません)。
TCP接続で接続タイムアウト値を大きくしてディレクトリ層用にロード・バランサの仮想サーバーを構成します。Oracle Access Management Access Managerとディレクトリ層との間でトラフィックがないと予測される場合の最大予測タイム・オーバー値よりもこの値を大きくしないでください。
クライアントIPアドレス保持機能: リクエストにおいて元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入してクライアントIPアドレスを保持できる機能がロード・バランサで必要です。
ロード・バランサの特定タイプに応じて、ロード・バランサを構成する手順は異なります。実際の手順については、ベンダー提供のドキュメントを参照してください。次の手順により一般的な構成フローを概説します。
サーバーのプールを作成します。ロード・バランシング定義に含まれているポートとサーバーのリストがこのプールに含まれています。たとえば、複数のWebホストでロード・バランシングするには、WEBHOST1とWEBHOST2のホストにリクエストがポート7777で転送されるサーバーのプールを作成します。
指定されたホストとサービスが利用可能かどうかを判別するルールを作成し、手順1で説明したサーバーのプールに割り当てます。
仮想サーバーをロード・バランサ上で作成します。これは、アプリケーションで使用されるリクエストを受信するアドレスとポートです。たとえば、Web層リクエストをロード・バランシングするには、仮想ホストをhttps://soa.mycompany.com:443用に作成します。
ロード・バランサでサポートしている場合、仮想サーバーが内部的に、外部的にまたは両方で利用できるかどうかを指定します。内部アドレスはネットワーク内部からのみ解決可能です。
可能な場合、SSL終端を仮想サーバー用に構成します。
手順1で作成したサーバーのプールを仮想サーバーに割り当てます。
Oracle SOAデプロイメントの場合、表3-5に示すように、ロード・バランサを構成します。
表3-5 ロード・バランサ構成詳細
| 仮想ホスト | サーバー・プール | プロトコル | SSL終端 | 外部 | その他の必要な構成/コメント |
|---|---|---|---|---|---|
|
|
|
HTTP |
いいえ |
いいえ |
|
|
|
|
HTTP |
いいえ |
はい |
|
|
soainternal.mycompany.com:80 |
WEBHOST1VHN1.mycompany.com:7777 WEBHOST2VHN1.mycompany.com:7777 |
HTTP |
いいえ |
いいえ |
|
|
osb.mycompany.com:443 |
WEBHOST1VHN1.mycompany.com:7777 WEBHOST2VHN1.mycompany.com:7777 |
HTTP |
いいえ |
はい |
|
Oracle Fusion Middlewareのコンポーネントおよびサービスの多くは、ポートを使用します。管理者は、これらのサービスで使用されるポート番号を知っている必要があります。また、同じホスト上の2つのサービスで同じポート番号が使用されていないことを確認する必要があります。
ほとんどのポート番号は、インストール時に割り当てられます。
表3-6に、Oracle Exalogicデプロイメント参照トポロジで使用されるポートの一覧を示します。これには、トポロジ内のファイアウォールで開いておく必要のあるポートも含まれています。
ファイアウォールの表記法は次のとおりです。
FW0は、最も外側のファイアウォールを指します。
VLANパーティションは、Web層とアプリケーション層との間にあるパーティションを指します。
FW2は、アプリケーション層とデータ層の間にあるファイアウォールを指します。
表3-6 ExalogicにおけるSOAエンタープライズ・デプロイメントで使用されるポート
| タイプ | ファイアウォール | ポートおよびポート範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | その他の考慮事項およびタイムアウトのガイドライン |
|---|---|---|---|---|---|
|
ブラウザ・リクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
インバウンド |
タイムアウトは、SOAで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザ・リクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
インバウンド |
タイムアウトは、SOAで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
コールバックとアウトバウンド呼出し |
VLANパーティション |
80 |
HTTPS/ロード・バランサ |
アウトバウンド |
タイムアウトは、SOAで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
コールバックとアウトバウンド呼出し |
VLANパーティション |
443 |
HTTPS/ロード・バランサ |
アウトバウンド |
タイムアウトは、SOAで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
OTDへのロード・バランサ |
n/a |
7777 |
HTTP |
n/a |
第3.7項「ロード・バランサの構成」を参照してください。 |
|
SOAサーバー・アクセスHTTP |
VLANパーティション |
8001 範囲: 8000 - 8010 |
HTTP / WLS_SOAn |
インバウンド |
タイムアウトは、SOAで使用されるプロセス・モデルのタイプに基づいて異なります。 |
|
SOAサーバー・アクセスRMI/T3 |
F0/VLANパーティション |
8003 |
RMI/T3/WLS_SOAn |
両方 |
タイムアウトは、RMI/T3呼出しのタイプによって異なりますし、最長リモート呼出し操作の所要時間によっても異なります。 |
|
Oracle Service BusアクセスHTTP |
VLANパーティション |
8011 範囲: 8011 - 8021 |
HTTP / WLS_OSBn |
インバウンド |
タイムアウトを短い時間(5-10秒)に設定します。 |
|
Oracle Service BusアクセスRMI/T3 |
F0/VLANパーティション |
8003 |
RMI/T3/WLS_OSBn |
両方 |
タイムアウトは、RMI/T3呼出しのタイプによって異なりますし、最長リモート呼出し操作の所要時間によっても異なります。 |
|
管理コンソールへのアクセス |
VLANパーティション |
7001 |
HTTP/管理サーバーおよびEnterprise Manager T3 |
両方 |
このタイムアウトは、管理コンソールへのアクセスのタイプ(Oracle WebLogic Server管理コンソールをアプリケーション層のクライアントから使用するか、アプリケーション層の外部のクライアントから使用するか)に基づいて調整してください。 |
|
データベース・アクセス |
FW2 |
1521 |
SQL*Net |
両方 |
タイムアウトは、SOAで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツによって異なります。 |
|
Oracle Notification Server (ONS) |
FW2 |
6200 |
ONS |
両方 |
Gridlinkで必要です。ONSサーバーは各データベース・サーバー上で実行します。 |
|
Oracle Traffic Director管理サーバーのコンソールへのアクセス |
VLANパーティション |
8989 |
HTTP |
両方 |
OTD管理コンソールへのアクセスのタイプ(コンソールをアプリケーション層のクライアントから使用するか、アプリケーション層の外部のクライアントから使用するか)に基づいてこのタイムアウトを調整してください。 |
|
Oracle Traffic Director管理ノード |
n/a |
8900 |
HTTP |
n/a |
n/a |
