WebLogic EJBまたはJMSリソースが、リソースを呼び出すアプリケーションと同じKubernetesネームスペースにある場合、次のようになります:
追加の構成ステップは必要ありません。
アプリケーションが指定するURLは、アプリケーションのロケーションとターゲット・リソースのロケーションの両方によって異なります。
アプリケーションがWebLogic Server JVMで実行されていて、JVMがターゲット・リソースをホストしている場合、またはJVMがターゲット・リソースと同じWebLogicクラスタ内にある場合、アプリケーションはリソースのJNDI名を単純に指定でき、「URLを指定しないでください」。
アプリケーションが前述のいずれかのロケーション外で実行されているが、ターゲット・リソースと同じKubernetesネームスペースにある場合は、JNDI名に加えて、ターゲット・リソースのKubernetes ClusterIPサービスのDNS名を含むt3またはt3s URLも指定する必要があります。 デプロイ済ドメインのサービスDNS名を表示するには、kubectl -n MYNS get servicesを実行します。
URLの例:
クラスタがポート7001でリスニングしているドメインUID myuidを持つWebLogicクラスタmycluster内の任意の場所にホストされているターゲット・リソースの場合:
t3://myuid-cluster-mycluster:7001
サーバーがポート7001でリスニングしているドメインUID myuidを持つドメインの一部である、クラスタ化されていないWebLogic Server myserverでホストされているターゲット・リソースの場合:
t3://myuid-myserver:7001
WebLogic EJBまたはJMSリソースが、リソースをコールするアプリケーションと同じKubernetesクラスタに配置され、アプリケーションとリソースが異なるKubernetesネームスペースにある場合、次のようになります:
アプリケーションで使用されるURLはt3またはt3sで始まり、ネームスペースを区別するためにURLのDNSアドレスを完全に指定する必要があります。 例えば:
mynsのドメインUID myuidを持つWebLogicクラスタmyclusterにあり、クラスタがポート8001でリスニングしている場合、オペレータによって生成されるクラスタ・サービス名はmyuid-cluster-myclusterになり、完全なURLはt3://myuid-cluster-mycluster.myns:8001になります。mynsのドメインUID myuidを持つWebLogic Server myserverで、サーバーがポート7001でリスニングしている場合、オペレータによって生成されるサーバー・サービス名はmyuid-myserverとなり、完全なURLはt3://myuid-myserver.myns:7001になります。アプリケーションは、次の構成でターゲットに構成されている「WebLogicカスタムT3またはT3Sチャネル」を使用して、ターゲットのWebLogic Serverまたはクラスタにアクセスします:
mynsで実行されているドメインUID myuidを持つドメインの一部であるWebLogicクラスタmycluster内にある場合、クラスタ・サービス名はmyuid-cluster-myclusterとなり、完全に装飾された名前はmyuid-cluster-mycluster.mynsになります。mynsで実行されているドメインUID myuidを持つドメインの一部であるWebLogic Server myserver内にある場合、サーバー・サービス名はmyuid-myserverとなり、完全に装飾された名前はmyuid-myserver.mynsになります。outbound enabledを有効にしないでください。t3またはt3sで始まるURLを引き続き使用できます。 アプリケーションURLはチャネルのポートを指定する必要があります。 アプリケーションがWebLogic Server JVM内で実行される場合、ターゲットEJBまたはJMSリソースをホストするWebLogic Serverインスタンスを「不明なホスト・アクセスを有効にします」に構成する必要がある場合があります。 これは、前の箇条書きアイテムに示されているように、ネットワーク・チャネルのパブリック・アドレスが構成されている場合には必要ありません。
JTAトランザクションが様々なネームスペースのドメイン間にまたがる場合、JTAトランザクション・マネージャがドメイン間で相互に通信できるように、追加の構成が必要です: 各サーバーのデフォルト・チャネルExternal Listen Addressを、サーバー・ネームスペースで装飾されたサービス名に構成します。 詳細は、「WebLogicデフォルト・チャネルの外部リスニング・アドレスの構成」を参照してください。
WebLogic EJBまたはJMSリソースがKubernetesクラスタ内でホストされているが、リソースをコールするアプリケーションがKubernetesクラスタ外でホストされている場合、次のようになります:
アプリケーションで使用できる外部アドレスとポートを公開するには、次の2つの方法がサポートされています:
NodePortsアプリケーションは、外部アドレスに解決されるURLを指定する必要があります。 トンネリングの場合、このURLはt3またはt3sではなくhttpまたはhttpsで始める必要があります。 たとえば、http://my-lb-address:my-lb-portです。
EJBまたはJMSリソースをホストするWebLogic Serverインスタンスで「不明なホスト・アクセスを有効にします」が必要になる場合があります。
トンネリングの場合、サーバー・アフィニティ・デフォルト・ロード・バランサ・アルゴリズムを使用してEJBまたはJMSリソースをホストするクラスタの構成が必要になることがあります。 これにより、EJBおよびJMSクライアントの接続作成を大幅に高速化できます。 「WebLogic Serverアフィニティ・ロード・バランシング・アルゴリズムの構成」を参照してください。
「RMI転送」を使用して、複数のWebLogic Serverドメインを含むJTAトランザクションをサポートする必要がある場合があります。
WebLogic EJBまたはJMSリソースがKubernetesクラスタ外でホストされ、リソースをコールするEJBまたはJMSアプリケーションがクラスタ内にある場合、次のようになります:
外部のWebLogic Serverインスタンスでは、「不明なホスト・アクセスを有効にします」が必要になる場合があります。
さらに、HTTPを使用してロード・バランサをトンネリングすることによってのみターゲット・サーバーにアクセスできる場合:
t3ではなくhttpで始まるソース・サーバーのURLを指定します。「RMI転送」を使用して、複数のWebLogic Serverドメインを含むJTAトランザクションをサポートする必要がある場合があります。
すべてのDNSアドレスは'DNS-1123'に準拠している必要があります。これは、サービスの名前、ポッド、WebLogic Server、WebLogicクラスタなどを使用して作成されたDNS名はすべて、ダッシュ(ハイフン)に変換されたアンダースコアで小文字にする必要があります。 たとえば、WebLogic Serverインスタンスの名前がMy_Serverで、ドメインUIDがMyUidの場合、ネームスペース内のリスニング・アドレスはmyuid-my-serverになります。 Kubernetesリソース準拠のネーミングの詳細は、「Kubernetesリソース名の制限を満たす」を参照してください。
ロード・バランサ・トンネリングは、Kubernetesクラスタ外でホストされているアプリケーションに、クラスタ内でホストされているEJBおよびJMSリソースへのアクセス権を付与する場合に優先される方法です。 このアプローチでは、リソースのWebLogicクラスタにネットワーク・チャネルを構成し、ネットワーク・チャネルがHTTPを介してトンネリングされたT3プロトコル・トラフィックを受け入れるようにし、外部HTTPネットワーク・トラフィックをネットワーク・チャネルにリダイレクトするロード・バランサをデプロイし、アプリケーションがURLがhttpまたはhttpsで始まるロード・バランサのネットワーク・アドレスを解決するURLを指定するようにします。
ステップは、次のとおりです。
WebLogicで、HTTPトンネリングを有効にするT3プロトコルのカスタム・チャネルを構成し、リモート・アプリケーションがロード・バランサへのアクセスに使用するアドレスおよびポートに対応する外部アドレスおよびポートを指定します。 サンプルおよび詳細は、「WebLogicカスタム・チャネルの追加」を参照してください。
HTTPトラフィックをカスタム・チャネルにリダイレクトするロード・バランサを設定します。 ロード・バランサの詳細は、Ingressを参照してください。 Oracle Container Engine for Kubernetes/Oracle Cloud Infrastructureを使用してKubernetesクラスタをホストする場合は、「Oracle Cloud Infrastructure Load Balancerの使用」も参照してください。
重要: ロード・バランサがHTTPフローをスティッキーに構成していることを確認してください - たとえば、Traefikロード・バランサにはsticky sessionsオプションがあります。 これにより、トンネリング・クライアント接続のすべてのパケットが同じポッドに流れるようになります。そうしないと、そのパケットが別のポッドにロード・バランシングされるときに接続が停止します。
重要: クラスタをターゲットとするEJBおよびJMSリソースの場合は、EJBおよびJMSクライアントの接続作成を高速化するために、サーバー・アフィニティ(ラウンドロビン・アフィニティ、重みベース・アフィニティ、ランダム・アフィニティ)を提供するデフォルトのロード・バランサ・アルゴリズムを構成することをお薦めします。 「WebLogic Serverアフィニティ・ロード・バランシング・アルゴリズムの構成」を参照してください。
リモートWebLogic Serverインスタンスでホストされているアプリケーションへのアクセスを追加する場合、Kubernetesでホストされるサーバーは「不明なホスト・アクセスを有効にします」が必要になることがあります。
リモート・アプリケーションは、t3:// URLのかわりにhttp:// URLを使用してカスタム・チャネルにアクセスできます。
「セキュリティ・ノート」を確認します。
次の項では、WebLogicカスタム・チャネルの考慮事項および構成について説明します。
WebLogicは、クラスタ内のサーバーごとに指定されたListen AddressおよびPortフィールドにまたがるマルチ・プロトコル・デフォルト・チャネルを暗黙的に作成しますが、通常、このチャネルはEJBおよびJMSアプリケーションからの外部ネットワーク・トラフィックに適していません。 かわりに、追加の専用WebLogicカスタム・チャネルを構成して、リモートEJBまたはJMSアプリケーションのネットワーク・トラフィックを処理する必要がある場合があります。
カスタム・チャネルは、デフォルトのチャネルとは異なり、外部アプリケーションで使用する外部リスニング・アドレスおよびポートを構成する方法を提供します。 外部リスニング・アドレスまたはポート構成は、チャネルの構成済のリスニング・アドレスまたはポートが、リモート・アプリケーションでURLを形成するために使用した場合には機能しない場合に必要です。 これは、リモートEJBおよびJMSアプリケーションが内部的にアプリケーションのチャネルの構成済ネットワーク情報を使用して、必要に応じてWebLogicに再接続するためです。 (EJBおよびJMSアプリケーションは、アプリケーションのJNDIコンテキストで指定された初期URLを必ずしも使用しません。)
カスタム・チャネルは、認可されていない外部JMSおよびEJBアプリケーションによるアクセスを防止する方法として双方向SSLを使用してロックダウンできます。チャネルに対して明示的に有効化されているプロトコルのみを受け入れ、HTTPでトンネリングするEJB/JMSアプリケーションを受け入れる唯一のチャネルとして構成できます。 多くの場合、デフォルト・チャネルは、便利な内部使用のために意図的に暗号化されていない可能性があります。または、外部で使用する場合は、webトラフィックにのみ使用されます(トンネリング・トラフィックには使用されません)。 また、デフォルト・チャネルでは複数のプロトコルがサポートされていますが、外部アプリケーションによってアクセス可能なプロトコルを制限することをお薦めします。 最後に、外部アプリケーションは接続を行うためにHTTPトンネリングを使用してアクセスする必要がある場合がありますが、通常は、すでに外部HTTPトラフィックを処理している保護されていないデフォルト・チャネルのトンネリングを有効化することをお薦めします。 これは、HTTPトンネリングを有効にすると、認可されていない外部JMSおよびEJBアプリケーションで、同じHTTPパスを介してWebLogicクラスタへの保護されていないアクセスが許可される可能性があるためです。
リモートEJBおよびJMSアクセス用のカスタム・チャネルを構成するための基本的な要件は次のとおりです:
各サーバーで同じ名前とポートを使用してT3プロトコル・ネットワーク・アクセス・ポイント(NAP)を構成します(オペレータがリスニング・アドレスを設定します)。
アプリケーションが使用できるURLのアドレスおよびポート・コンポーネントと一致するように、各NAPで外部リスニング・アドレスおよびポートを構成します。 たとえば、ロード・バランサを使用してリモート・アプリケーションへのアクセスを提供している場合、これらはロード・バランサのアドレスとポートと一致する必要があります。
WebLogic T3アプリケーションをHTTPを介してトンネリングする場合は、各NAPでHTTPトンネリングを有効にします。 これは多くの場合、ロード・バランサに必要です。
ネットワーク・アクセス・ポイント(デフォルトはfalse)でoutbound-enabledをtrueに設定「しない」でください。設定すると、ネットワーク・アクセス・ポイントを経由するように内部ネットワーク・トラフィックが停止する可能性があります。
オペレータ制御のWebLogicクラスタの場合は、WebLogic動的クラスタ・サーバーに対してcalculated-listen-portsを有効にしていないことを確認します。 このオペレータでは、チャネルがクラスタ内の各サーバーで同じポートを持つ必要がありますが、calculated-listen-portsでは各サーバーで異なるポートが使用されます。
オペレータ制御されて「いない」クラスタの場合、少なくともサーバーのデフォルト・チャネルListenAddressが構成されていることを確認します。 Oracleでは、すべてのWebLogic ServerインスタンスでListenAddressを構成することを強くお薦めします。 NAPのListenAddressが空白のままの場合、デフォルト・チャネルのListenAddressが使用されることに注意してください。 (オペレータがすべてのWebLogic Serverインスタンスでリスニング・アドレスを設定するため、これはオペレータ制御クラスタにとって問題ではありません。)
たとえば、cluster-1という名前のオペレータ制御のWebLogic動的クラスタに対して定義されたチャネルMyChannelのWebLogicドメインconfig.xmlファイルのスニペットを次に示します:
<server-template>
<name>cluster-1-template</name>
<listen-port>8001</listen-port>
<cluster>cluster-1</cluster>
<network-access-point>
<name>MyChannel</name>
<protocol>t3</protocol>
<public-address>some.public.address.com</public-address>
<listen-port>7999</listen-port>
<public-port>30999</public-port>
<http-enabled-for-this-protocol>true</http-enabled-for-this-protocol>
<tunneling-enabled>true</tunneling-enabled>
<outbound-enabled>false</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
</network-access-point>
</server-template>
<cluster>
<name>cluster-1</name>
<cluster-messaging-mode>unicast</cluster-messaging-mode>
<dynamic-servers>
<name>cluster-1</name>
<server-template>cluster-1-template</server-template>
<maximum-dynamic-server-count>5</maximum-dynamic-server-count>
<calculated-listen-ports>false</calculated-listen-ports>
<server-name-prefix>managed-server</server-name-prefix>
<dynamic-cluster-size>5</dynamic-cluster-size>
<max-dynamic-cluster-size>5</max-dynamic-cluster-size>
</dynamic-servers>
</cluster>
前のconfig.xmlファイル・スニペットに対応するオフラインWLSTコードのスニペットを次に示します:
templateName = "cluster-1-template"
cd('/ServerTemplates/%s' % templateName)
templateChannelName = "MyChannel"
create(templateChannelName, 'NetworkAccessPoint')
cd('NetworkAccessPoints/%s' % templateChannelName)
set('Protocol', 't3')
set('ListenPort', 7999)
set('PublicPort', 30999)
set('PublicAddress', 'some.public.address.com')
set('HttpEnabledForThisProtocol', true)
set('TunnelingEnabled', true)
set('OutboundEnabled', false)
set('Enabled', true)
set('TwoWaySslEnabled', false)
set('ClientCertificateEnforced', false)
前のスニペットに対応するWDTモデルYAMLファイル構成のスニペットを次に示します:
topology:
Cluster:
'cluster-1':
DynamicServers:
ServerTemplate: 'cluster-1-template'
ServerNamePrefix: 'managed-server'
DynamicClusterSize: '5'
MaxDynamicClusterSize: '5'
MinDynamicClusterSize: '0'
CalculatedListenPorts: false
ServerTemplate:
'cluster-1-template':
Cluster: 'cluster-1'
ListenPort: 8001
NetworkAccessPoint:
MyT3Channel:
Protocol: 't3'
ListenPort: 7999
PublicPort: 30999
PublicAddress: 'some.public.address.com'
HttpEnabledForThisProtocol: true
TunnelingEnabled: true
OutboundEnabled: false
Enabled: true
TwoWaySSLEnabled: false
ClientCertificateEnforced: false
この例では、次のようになります。
WebLogicは、カスタム・ネットワーク・チャネルをポート7999に、デフォルト・ネットワーク・チャネルを8001にバインドします。
オペレータは、カスタム・チャネルとデフォルト・チャネルの両方に対してDOMAIN_UID-cluster-cluster-1という名前のKubernetesサービスを自動的に作成します。
オペレータは、各チャネルの各WebLogic ServerインスタンスにListenAddressを自動的に設定します。
チャネルと同じKubernetesクラスタで実行されている内部アプリケーションは、t3://DOMAIN_UID-cluster-cluster-1:8001を使用してクラスタにアクセスできます。
外部アプリケーションは、t3://some.public.address.com:30999などのURLを持つカスタム・チャネルを使用してクラスタにアクセスするか、トンネリングを使用している場合はhttp://some.public.address.com:30999にアクセスする必要があります。
構成済クラスタのチャネル構成では、各サーバーで同じネットワーク・アクセス・ポイントを構成する必要があります。 オペレータは現在、クラスタ内のサーバーごとに異なる構成を持つネットワーク・チャネルをテストまたはサポートしていません。
カスタム・チャネルを構成しない外部アプリケーションには、追加のステップが必要です - 「概要」を参照してください。
NodePorts次の項では、Kubernetes NodePortsの詳細について説明します。
NodePortの概要Kubernetes NodePortsは、外部WebLogic EJBまたはJMSアプリケーションにKubernetesホストWebLogicクラスタへのアクセス権を付与するための代替アプローチを提供します。 このアプローチには、T3プロトコル・トラフィックを受け入れる目的のWebLogicクラスタでのネットワーク・チャネルの構成、およびKubernetesノード上の外部ネットワーク・トラフィックをネットワーク・チャネルにリダイレクトするKubernetes NodePortの公開が含まれます。
NodePort警告Kubernetes NodePortsはデモおよびスタート・ガイドでの使用に適していますが、通常は次のような複数の理由で本番システムには適していません:
NodePortsを公開できません。「ロード・バランサのトンネリング」は、Kubernetes NodePortsよりも優先されるアプローチです。
NodePortステップステップの概要は次のとおりです。
「NodePort警告」を確認します。
WebLogicで、リモート・アプリケーションの使用に適した外部アドレスおよびポートを指定するT3プロトコルのカスタム・チャネルを構成します。 「WebLogicカスタム・チャネルの追加」を参照してください。
Kubernetes NodePortを定義して、WebLogicポートを公開します。 「NodePortの設定」を参照してください。
リモートWebLogic Serverインスタンスへのアクセスを追加する場合、Kubernetesホスト・サーバーは「不明なホスト・アクセスを有効にします」が必要になる場合があります。
「セキュリティ・ノート」を確認します。
NodePortの設定Kubernetes NodePortは、Kubernetesクラスタの各ワーカー・ノードでポートを公開します(通常、マスターでは公開されません)。このポートには、Kubernetesクラスタの外部からアクセスできます。 このポートは、ネットワーク・トラフィックをKubernetesクラスタ内のポッドにリダイレクトします。 Kubernetes NodePortの設定は、外部のWebLogicアプリケーションがJMSまたはEJBにアクセスできるようにするための1つの方法です。
EJBまたはJMSサービスが管理サーバーで実行されている場合は、この項の残りの部分をスキップし、spec.adminServer.adminService.channelsドメイン・フィールドを使用してオペレータにNodePortを作成させることができます。 「リファレンス - Domain」を参照してください。 それ以外の場合、EJBまたはJMSサービスがWebLogicクラスタまたはスタンドアロンのWebLogic Server管理対象サーバーで実行されているときに、NodePortを使用してサービスへのアクセスを提供するには、NodePortを手動で公開する必要があります - 次のサンプルおよび表を参照してください。
NodePortを設定するには、通常、カスタム・ネットワーク・チャネルも設定する必要があります。 「WebLogicカスタム・チャネルの追加」を参照してください。
NodePortリソース次のNodePort YAMLファイルでは、DOMAIN_UIDのドメインUID、DOMAIN_NAMEのドメイン名およびCLUSTER_NAMEのクラスタ名に対して、30999の外部ノード・ポートおよび内部ポート7999が公開されています。 7999は、WebLogicクラスタで構成されているチャネルのT3プロトコル・ポートに対応していることを前提としています。
apiVersion: v1
kind: Service
metadata:
namespace: default
name: DOMAIN_UID-cluster-CLUSTER_NAME-ext
labels:
weblogic.domainUID: DOMAIN_UID
spec:
type: NodePort
externalTrafficPolicy: Cluster
sessionAffinity: ClientIP
selector:
weblogic.domainUID: DOMAIN_UID
weblogic.clusterName: CLUSTER_NAME
ports:
- name: myclustert3channel
nodePort: 30999
port: 7999
protocol: TCP
targetPort: 7999
NodePort属性の表| 属性 | 説明 |
|---|---|
metadata.name |
この特定のユースケースでは、DNSと互換性があるかぎり、NodePort名は任意に指定できます。 ただし、慣例として、DOMAIN_UID-cluster-CLUSTER_NAME-extを使用することをお薦めします。 名前がDNS互換であることを確認するには、すべての小文字を使用し、すべてのアンダースコア(_)をダッシュ(-)に変換します。 |
metadata.namespace |
WebLogicクラスタのネームスペースと一致する必要があります。 |
metadata.labels |
オプション。 クリーンアップ・スクリプトが特定のドメインUIDに関連付けられたすべてのKubernetesリソースを検出できるように、weblogic.domainUidラベルを設定すると便利です。 |
spec.type |
NodePortである必要があります。 |
spec.externalTrafficPolicy |
ほとんどのユースケースでは、Clusterに設定します。 これによりパフォーマンスが低下する可能性がありますが、spec.selectorに一致するポッドを持たないノードにアタッチするクライアントは、一致するポッドを持つノードに再ルーティングされます。 Localに設定すると、特定のノードへの接続はそのノードのポッドにのみルーティングされ、そのノードが特定のspec.selectorを持つポッドをホストしていない場合は失敗します。 spec.externalTrafficPolicy: Local NodePortのアプリケーションでは、t3://mynode1,mynode2:30999などのすべてのノードのリストに解決されるURLを使用することをお薦めします。これにより、クライアントの接続試行は、mynode1が失敗した場合に暗黙的にmynode2を試行します(または、mynode1,mynode2のかわりにラウンドロビンDNSアドレスを使用します)。 |
spec.sessionAffinity |
HTTPトンネリング接続が常に同じポッドにルーティングされるようにするには、ClientIPに設定します。そうしないと、接続がハングして失敗する可能性があります。 |
spec.selector |
NodePortリソースをクラスタのポッドに関連付けるweblogic.domainUIDおよびweblogic.clusterNameを指定します。 オペレータは、デプロイするWebLogicクラスタ・ポッドにこれらのラベルを自動的に設定します。 |
spec.ports.name |
この名前は任意です。 |
spec.ports.nodePort |
アプリケーションが使用する外部ポート。 これは、WebLogicで構成されたチャネル/ネットワーク・アクセス・ポイントで構成されている外部ポートと一致する必要があります。 デフォルトでは、Kubernetesはこの値を30000から32767の範囲にする必要があります。 |
spec.ports.portおよびspec.targetPort |
これらは、WebLogicで構成されたチャネル/ネットワーク・アクセス・ポイントで構成されているポートと一致する必要があります。 |
次のセクションでは、不明なホスト・アクセスを有効にするタイミングと方法について説明します。
ソースWebLogic ServerがターゲットWebLogic ServerとのEJB、JMSまたはJTA接続を開始しようとすると、ソース・サーバーのリスニング・アドレスがDNSに見つからない場合、ターゲットWebLogic Serverはデフォルトで接続を拒否します。 このような接続試行が失敗すると、"...RJVM has already been shutdown..."や"...address was valid earlier, but now we get..."などのログ・メッセージまたは例外が発生する可能性があります。
つまり、通常は、WebLogic Serverをホストするオペレータによって開始されるEJB、JMSまたはJTA通信をサポートできるように、外部WebLogic Serverインスタンスで不明なホスト・アクセスを有効にする必要があります。 たとえば、オペレータがWebLogic Serverをサービス・アドレスmydomainuid-myservernameでホストした場合、リモートのWebLogic ServerへのJMS接続が開始されると、リモート・サーバーは、接続設定の一部としてDNSでmydomainuid-myservernameを暗黙的に検索しようとし、通常、この参照は失敗します。
同様に、これは、外部WebLogic Serverのリスニング・アドレスをKubernetersクラスタで実行しているDNSで解決できない場合に、外部WebLogic ServerインスタンスからのEJBまたはJMS接続リクエストを受け入れる、オペレータがホストするWebLogic Serverで不明なホスト・アクセスを有効にする必要もあります。
不明なホストのソースWebLogic ServerがターゲットWebLogic ServerとのEJB、JMSまたはJTA通信を開始できるようにするには:
weblogic.rjvm.allowUnknownHost Javaシステム・プロパティをtrueに設定します。
spec.serverPod.env属性で定義されたJAVA_OPTIONS 「ドメイン環境変数」に-Dweblogic.rjvm.allowUnknownHost=trueを含めることで、このプロパティを設定できます。WebLogic ServerドメインにまたがるJTAトランザクションは、クロスドメイン・トランザクションと呼ばれます。 WebLogic Serverトランザクション・マネージャ(TM)では、他のすべてのグローバル・トランザクション・サーバー参加者とのサーバー間直接通信が必要です。 KubernetesがホストするWebLogicクラスタの場合、クラスタ内の各サーバーが個別にアドレス指定可能である必要があります。 これは、クラスタ内のネットワーク・チャネルがクラスタ内のすべてのサーバーにわたって同じポートを持つこと、およびクラスタ・サービスを使用してWebLogic Serverクラスタ内の通信のロード・バランシングを行うことが現在のオペレータ要件と競合します。
RMI転送では、クラスタ内の各サーバーを個別にアドレス指定可能にする必要なく、ドメイン間トランザクションが可能です。
これには、ターゲットWebLogic Serverドメイン内のサーバーにメッセージをルーティングするように構成された、ロード・バランサやIngressなどのプロキシを使用する必要があります。
WebLogic Server TMによって発行されたトランザクション調整RMIコールなどのT3メッセージが、ソースWebLogic Serverから別のWebLogic Serverドメイン内のターゲットWebLogic Serverに送信された場合:
トランザクション・サーバーの参加者が相互に直接接続を確立できない場合、RMI転送が必要になることがあります。
たとえば、クロスドメイン・トランザクション通信が失敗し、次のようなメッセージがWebLogicサーバー・ログ・ファイルにあるとします:
<BEA-111015> <The commit operation for transaction BEA1-0000993203DB6CDB7DE9 timed out after 30 seconds.>
Javaシステム・プロパティ-Dweblogic.debug.DebugJTA2PC=trueを使用して追加のJTAデバッグをオンにすると、次のようなメッセージは、失敗したトランザクションが、トランザクション参加者がトランザクション・コーディネータに到達できないことが原因であることを確認します:
...<startPrepare FAILED javax.transaction.SystemException: Could not obtain coordinator at managed-server1+domain1-managed-server1:8001+domain1+t3+...
ドメイン内のWebLogic Serverインスタンスのリスニング・アドレスは、他の参加者のDNSによって解決できないため、グローバル・トランザクション参加者の参加者であるが、他のすべてのグローバル・トランザクション参加者がアクセスできない各WebLogic Serverドメインのプロキシを構成します。 たとえば、domain2のサーバーからdomain1のサーバーにアクセスできない場合は、domain2のサーバーから送信されるメッセージをプロキシ経由でdomain1のサーバーにルーティングできるように、domain1のプロキシを構成します。
各ソースWebLogic Serverドメインで、各ターゲットWebLogic Serverドメインに構成されたプロキシのURLを指定します:
weblogic.rjvm.domain.proxy.<prefix>に設定します。<prefix>は、ターゲットのWebLogic ServerドメインのドメインUIDです。 <prefix>の値が異なる複数のJavaシステム・プロパティを指定できます。 spec.serverPod.env属性で定義されたJAVA_OPTIONS 「ドメイン環境変数」にシステム・プロパティを含めます。たとえば、domain1のプロキシのURLがt3://proxy-host:31234の場合は、WebLogic Server domain2にJavaシステム・プロパティ-Dweblogic.rjvm.domain.proxy.domain1=t3://proxy-host:31234を指定します。 domain2のWebLogic Serverインスタンスから発生した、domain1で始まるホスト名(t3://domain1-managed-server1:8001など)宛てのメッセージは、t3://proxy-host:31234のプロキシに送信されます。 次に、プロキシはメッセージをdomain2のWebLogic Serverインスタンスにルーティングし、RMI転送は、メッセージがdomain1のWebLogic Server managed-server1に到達することを確認します。
パッチ32408938は、ドメイン間トランザクションに参加する各WebLogic Serverインスタンス、またはプロキシのルーティング先に必要です。 このパッチは、WebLogicバージョン12.2.1.4.0 (PS4)および14.1.1.0.0で使用でき、2022年7月からこれらのリリースのPSUにすでに含まれています。
ロード・バランサ・トンネリングを使用して外部クライアントがEJBおよびJMSリソースにアクセスできるようにする場合は、リソースがターゲットとなるクラスタに対してサーバー・アフィニティ・ロード・バランシング・アルゴリズムを構成することをお薦めします。 サーバー・アフィニティ・ベースのアルゴリズムを使用すると、EJBおよびJMSスタンドアロンまたはサーバー・ホスト・クライアントがトンネリング・ポートを介して接続を確立するのにかかる時間が短縮されます。 これは、クライアントにすでに確立されたクライアントへの接続があるターゲット・サーバー・インスタンスとの通信を希望させることで行われます。この場合、このようなクライアントがJNDIコンテキストを作成するときに、このサーバー・インスタンスが暗黙的に選択されます。 「クラスタでのロード・バランシング」の「EJBおよびRMIオブジェクトのロード・バランシング」を参照してください。
クラスタ'cluster-1'でサーバー・アフィニティを有効にするためのオフラインWLSTコードのスニペットを次に示します:
clusterName = "cluster-1"
cd('/Clusters/%s' % clusterName)
set('DefaultLoadAlgorithm', 'round-robin-affinity')
クラスタ'cluster-1'でサーバー・アフィニティを有効にするためのWDTモデルYAMLファイル構成のスニペットを次に示します:
topology:
Cluster:
'cluster-1':
DynamicServers:
ServerTemplate: 'cluster-1-template'
ServerNamePrefix: 'managed-server'
DynamicClusterSize: '5'
MaxDynamicClusterSize: '5'
MinDynamicClusterSize: '0'
CalculatedListenPorts: false
DefaultLoadAlgorithm: 'round-robin-affinity'
WebLogic Serverには、外部のJMSクライアントおよびEJBクライアントが、クライアントのDNSで直接使用できないリスニング・アドレス(ファイアウォールやロード・バランサ、Kubernetes内の異なるネームスペース間など)を持つサーバーへの接続を適切に再確立またはロード・バランシングするための外部リスニング・アドレス/DNS名機能が用意されています。 外部リスニング・アドレスの詳細は、ServerMBeanリファレンスのExternalDNSName属性を参照してください。
ドメインuid domain1のネームスペースweblogic-domainでAdminServerという名前のスタンドアロン・サーバーの外部リスニング・アドレスを設定するためのオフラインWLSTコードのスニペットを次に示します:
serverName = "AdminServer"
domainUid = "domain1"
nameSpace = "weblogic-domain"
address = domainUid + '_' + serverName + '_' + nameSpace
externalDNSName = address.lower().replace('_','-') # DNS names must be DNS-1123 compliant
cd('/Servers/%s' % serverName)
set('ExternalDNSName', externalDNSName)
ここでは、domain-uid domain1のネームスペースweblogic-domainに、cluster-1-templateという名前のサーバー・テンプレートの外部リスニング・アドレスを設定するためのオフラインWLSTコードの抜粋を示します:
templateName = "cluster-1-template"
serverName = "managed-server${id}"
domainUid = "domain1"
nameSpace = "weblogic-domain"
address = domainUid + '_' + serverName + '_' + nameSpace
externalDNSName = address.lower().replace('_','-') # DNS names must be DNS-1123 compliant
cd('/ServerTemplates/%s' % templateName)
set('ExternalDNSName', externalDNSName)
サーバー名には、WebLogic Serverランタイムによって正しいインスタンスIDが置換されるサーバー・テンプレート・マクロ"${ID}"が含まれます。 「サーバー・テンプレート」の「マクロの使用」を参照してください。
スタンドアロン・サーバーとサーバー・テンプレートの両方にExternalDNSName属性を設定するWDTモデルYAMLファイル構成のスニペットを次に示します:
topology:
Cluster:
"cluster-1":
DynamicServers:
ServerTemplate: "cluster-1-template"
ServerNamePrefix: "managed-server"
DynamicClusterSize: 5
MaxDynamicClusterSize: 5
CalculatedListenPorts: false
Server:
"admin-server":
ListenPort: 7001
ExternalDNSName: '@@ENV:DOMAIN_UID@@-admin-server.@@ENV:NAMESPACE@@'
ServerTemplate:
"cluster-1-template":
Cluster: "cluster-1"
ListenPort : 8001
ExternalDNSName: '@@ENV:DOMAIN_UID@@-managed-server${id}.@@ENV:NAMESPACE@@'
前述の例では、DOMAIN_UIDおよびNAMESPACEはすでに'DNS-1123'に準拠していると想定されています。 または、DNS-1123許容値(小文字およびダッシュに変換されたアンダースコアに変更)でマクロを置き換えることもできます。 Kubernetesリソース準拠のネーミングの詳細は、「Kubernetesリソース名の制限を満たす」を参照してください。
一部のクラウド・プロバイダでは、ロード・バランサまたはNodePortがポートをパブリック・インターネットに暗黙的に公開する場合があります。 「NodePort警告」も参照してください。
外部で使用可能なポートでWebLogicアプリケーションに適したプロトコルがサポートされている場合、WebLogicでは、デフォルトでJNDIエントリ、EJB/RMIアプリケーションおよびJMSに匿名ユーザーによるアクセスが許可されることに注意してください。
セキュア・プロトコルと双方向SSLを使用してカスタム・チャネルを構成することで、不要なアプリケーションによる外部アクセスを防止できます。 「WebLogicカスタム・チャネルはいつ必要ですか。」を参照してください。
外部ネットワーク・アクセスのセキュリティの詳細は、「外部ネットワーク・アクセスのセキュリティ」を参照してください。
JMS、EJBおよびJNDIアプリケーションのWebLogic URL構文の詳細は、「WebLogic URLの理解」を参照してください。
JMSアプリケーションでURLを指定する必要があり、アプリケーションがWebLogic Serverまたはクラスタでホストされている場合は、ベスト・プラクティスとして、使用するアプリケーションをコーディングする必要があります。JMS接続ファクトリおよびJMS宛先のローカルJNDI名、および外部JMSサーバーを使用してリモートのロケーションにマップするために、これらのローカルJNDI名をWebLogicで構成する必要があります。 外部JMSサーバーは、JMS接続ファクトリまたはJMS宛先のローカルJNDI名を、別のURLにあるリモートJNDI名にマップします。ローカルJNDI名、リモートJNDI名、リモート・ユーザー名、リモート・パスワードおよびリモートURLはすべて構成可能です。 「リモートJMS宛先の統合」を参照してください。
T3とポート・マッピングの組合せの使用方法の詳細は、「Kubernetesで実行されるWebLogic Server用のT3 RMI通信」を参照してください。