https://blogs.oracle.com/weblogicserver/t3-rmi-communication-for-weblogic-server-running-on-kubernetes
Overview
Oracle WebLogic ServerはJava EEをサポートしており、そしていくつかのベンダー固有の機能強化を含んでいます。それは、Java EEベースのIIOP、RMIという2個のRMI実装に加え、WebLogic ServerがT3と呼ばれる独自のRMIプロトコルです。このエントリではT3にも当てはまる汎用的なRMIの構成と、WebLogic ServerをKubernetesで動作させる上でT3固有の部分を説明します。Background
T3 RMIは、WebLogic Server独自の高性能RMIプロトコルであり、WebLogic Server内部での主要な通信コンポーネントであり、JMS、EJB、OAMなどのサービスの外部でも使用されます。WebLogic ServerのT3 RMI構成が進化しました。これは、デフォルトのチャネルとして知られているWebLogic Server上の単一のマルチプロトコルリスンポートとリスンアドレスで始まります。ネットワークアクセスポイントレイヤーを追加することでデフォルトのチャネルが強化されました。これにより、ユーザーは複数のポートを設定できるほか、カスタムチャネルと呼ばれるポートごとに異なるプロトコルも設定できます。 WebLogic ServerがKubernetes上で動作している場合、WebLogic Serverのリスンポート番号は、Kubernetes公開ポート番号と同じでも異なっていてもかまいません。Kubernetes上で実行されているWebLogic Serverでは、カスタムチャネルを使用して、この2つのポート番号をマッピングできるからです。下表は、このブログで使用されている重要な用語を纏めたものです。詳細を確認するためのドキュメントへのリンクも付けています。
| 用語 | |
|---|---|
| Listen port | WebLogic Serverが物理的にバインドしているTCP/IPポート |
| Public port | パブリックポート。 呼び出し側がT3 URLを定義する際に使うポート番号。ポートマッピングを使った接続でない限り、通常はリスンポートと同じ。 |
| Port mapping | とあるアドレスとポート番号の組合せからの通信リクエストを別のものにリダイレクトするネットワークアドレス変換（Network Address Translation、NAT）のアプリケーション。 |
| Default channel | すべてのWebLogic Serverドメインが自動生成する、すべてのWebLogic Serverが有するデフォルトチャネル。 Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の管理 12c (12.2.1.3.0) デフォルト・ネットワーク・チャネル https://docs.oracle.com/cd/E92951_01/wls/CNFGD/network.htm#CNFGD167 Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1.3.0) The Default Network Channel https://docs.oracle.com/middleware/12213/wls/CNFGD/network.htm#CNFGD167 |
| Custom channel | 異なる種類のネットワークトラフィックを分離するために利用 |
| ServerTemplateMBean | デフォルトチャネルとしても知られる。詳細は以下を参照。 Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0 Interface ServerTemplateMBean https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/ServerTemplateMBean.html |
| NetworkAccessPointMBean | カスタムチャネルとしても知られる。詳細は以下を参照。 Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0 Interface NetworkAccessPointMBean https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/NetworkAccessPointMBean.html |
| WebLogic cluster communication | クラスタに属するWebLogic Serverインスタンスはマルチキャスト、ユニキャストの2個の基本ネットワークテクノロジーのうちいずれかを使ってお互いに通信する。マルチキャストとユニキャストについては以下を参照。 Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0) クラスタでの通信 https://docs.oracle.com/cd/E92951_01/wls/CLUST/features.htm#CLUST127 Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1.3.0) Communications In a Cluster https://docs.oracle.com/middleware/12213/wls/CLUST/features.htm#CLUST127 |
| WebLogic transaction coordinator | トランザクションコーディネータとして振る舞うWebLogic Serverトランザクションマネージャ |
| Kubernetes service | Kubernetes conceptsを参照。 Kubernetes Concepts - Services https://kubernetes.io/docs/concepts/services-networking/service/ これはKubernetesのバックエンドとNodePortを定義する。 |
| Kubernetes pod IP address | Podがどのホスト上にあるかに関わらず、KubernetesはPodが他のPodと通信することを想定している。各PodにクラスタプライベートIPアドレスを付与するので、明示的にPod間のリンクやコンテナのポートとホストのポートとのマッピングを作成する必要はない。詳細は以下を参照。 Kubernetes Concepts - Cluster Networking https://kubernetes.io/docs/concepts/cluster-administration/networking/ |
| ClusterMBean | ClusterBroadcastChannelを参照。 Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12.2.1.3.0 Interface ClusterMBean https://docs.oracle.com/middleware/12213/wls/WLAPI/weblogic/management/configuration/ClusterMBean.html |
WebLogic Server Listen Address
WebLogic Serverは、マルチキャストとユニキャストの2つのクラスタメッセージングプロトコルをサポートしています。WebLogic Server on Kubernetesの動作保証の検証は、Flannelネットワークファブリックを使用して行われました。 現在、ユニキャスト通信のみを動作保証しています。デフォルトでは、WebLogic Serverはユニキャスト通信にデフォルトチャネルを使用します。ユーザーは、関連付けられたWebLogic Server ClusterMBeanにカスタムチャネルを設定することでオーバーライドできます。
WebLogicクラスタのユニキャスト構成の一環として、WebLogicクラスタメンバーがお互いを発見できるよう、クラスタメンバーごとに指定されたリスンアドレスとポートが必要です。 既定では、既定のチャネルまたはカスタムチャネルはnullリスンアドレスを持ち、実行時に0.0.0.0として割り当てられます。マルチノードKubernetesクラスタ環境では、0.0.0.0とlocalhostのどちらを使っても、異なるノードの他のクラスタメンバが互いに発見できませんが、その代わりに、WebLogic Serverインスタンスが実行されているKubernetes Pod IPアドレスを使用できます。
TCP Load Balancing
一般に、WebLogic T3はTCP/IPベースであるため、複数のバックエンドを持つKubernetesサービスなど、サービスが同種の場合にTCP負荷分散をサポートできます。WebLogic Serverでは、JMSやEJBなどのいくつかのサブシステムが同種のものです。例えば、JMSフロントエンドサブシステムは、リモートJMSクライアントが任意のクラスタメンバーに接続できるWebLogicクラスタで構成できますが、対照的に、JTAサブシステムでは、単一のKubernetesクラスタを超えて広がる複数のWebLogicドメインにまたがるトランザクションでTCPロードバランシングを安全に使用できません。JTAトランザクションコーディネータは、トランザクションがコミットまたはロールバックされたときに、トランザクションのサブコーディネータとして選択されたサーバインスタンスへの直接RMI接続を確立する必要があるからです。下図は、T3プロトコルを使用してサブコーディネータに接続するWebLogicトランザクションコーディネータを示しています。WebLogicトランザクションコーディネータは、TCPロードバランシングが原因で、選択したサブコーディネータに接続できません。
 |
| Figure 1: Kubernetes Cluster with Load Balancing Service |
 |
| Figure 2: Kubernetes Cluster with One-on-One Service |
Port Mapping and Address Mapping
WebLogic Serverは、2つのスタイルのT3 RMIの構成をサポートしています。1つはデフォルトチャネル（ServerTemplateMBeanを参照）によって定義され、もう1つはカスタムチャネル（NetworkAccessPointMBeanを参照）によって定義されるものです。Oracle Fusion Middleware MBean Reference for Oracle WebLogic Server 12.2.1.3.0 MBean ReferenceKubernetesでWebLogic Serverを実行する場合は、ポートマッピングに特に注意する必要があります。
ServerTemplateMBean
https://docs.oracle.com/middleware/12213/wls/WLMBR/mbeans/ServerTemplateMBean.htmlNetworkAccessPointMBean
https://docs.oracle.com/middleware/12213/wls/WLMBR/core/index.html
NodePortを使用してKubernetesクラスタ外でWebLogic T3 RMIサービスを公開する場合は、NodePortをWebLogic Serverのリスンポートにマップする必要があります。NodePortがWebLogic Serverのリスンポートと同じであれば、WebLogic Serverのデフォルトチャネルを使用できます。それ以外の場合は、NodePortのnodePort値と一致する「パブリックポート」と、NodePortのポート値と一致する「リスンポート」を定義するカスタムチャネルを設定する必要があります。
下図は動作しないNodePort/デフォルトチャネルの構成と、動作するNodePort/カスタムチャネルの構成を示したものです。
 |
| Figure 3: T3 External Clients in K8S |
| Default Channel (ServerTemplateMBean) | Custom Channel (NetworkAccessPointMBean) | |
|---|---|---|
| 複数のプロトコルをサポート（T3、HTTP、SNMP、LDAPなど） | Yes | No |
| RMI over HTTP tunneling | Yes （デフォルトでは無効） | Yes （デフォルトでは無効） |
| Port mapping | No | Yes |
| Address | Yes | Yes |
Examples of WebLogic T3 RMI configurations
WebLogic Serverは複数のT3 RMIの構成方法をサポートしています。以下はよく使われる方法の例です。Using the WebLogic Server Administration Console
以下のコンソールページは、リスンポートとして9001、リスンアドレスは無指定、SSLポートの設定をしていない、管理サーバーのWebLogic Serverインスタンスの例です。このサーバーインスタンスをデフォルトチャネルを使って構成しているため、ポート9001はT3、http、iiop、snmp、そしてldapをサポートします。 |
| Figure 4: T3 RMI via ServerTemplateMBean on WebLogic console |
 |
| Figure 5: T3 RMI via NetworkAccessPointMBean on WebLogic Console |
Using WebLogic RESTful management services
以下のシェルスクリプトはリスンポートとして${CHANNEL_PORT}、ペアとなるパブリックポートとして${CHANNEL_PUBLIC_PORT}を持つカスタムチャネルを作成します。#!/bin/sh
HOST=$1
PORT=$2
USER=$3
PASSWORD=$4
CHANNEL=$5
CHANNEL_PORT=$6
CHANNEL_PUBLIC_PORT=$7
echo "Rest EndPoint URL http://${HOST}:${PORT}/management/weblogic/latest/edit"
if [ $# -eq 0 ]; then
echo "Please specify HOST, PORT, USER, PASSWORD CHANNEL CHANNEL_PORT CHANNEL_PUBLIC_PORT"
exit 1
fi
# Start edit
curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/changeManager/startEdit
# Create
curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{
name: '${CHANNEL}'
}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/Servers/myServer/networkAccessPoints
curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{
listenPort: ${CHANNEL_PORT},
publicPort: ${CHANNEL_PUBLIC_PORT}
}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/Servers/myServer/networkAccessPoints/${CHANNEL}
curl -j --noproxy '*' --silent \
--user $USER:$PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d "{}" \
-X POST http://$HOST:$PORT/management/weblogic/latest/edit/changeManager/activate
Using a WLST script
以下のWLSTスクリプトではt3Channelという名前のカスタムT3チャネルを作成します。これはリスンポートとしてlisten_port、パブリックポートとしてpublic_portを持ちます。host = sys.argv[1]
port = sys.argv[2]
user_name = sys.argv[3]
password = sys.argv[4]
listen_port = sys.argv[5]
public_port = sys.argv[6]
print('custom host : [%s]' % host);
print('custom port : [%s]' % port);
print('custom user_name : [%s]' % user_name);
print('custom password : ********');
print('public address : [%s]' % public_address);
print('channel listen port : [%s]' % listen_port);
print('channel public listen port : [%s]' % public_port);
connect(user_name, password, 't3://' + host + ':' + port)
edit()
startEdit()
ls()
cd('/')
cd('Servers')
cd('myServer')
create('t3Channel','NetworkAccessPoint')
cd('NetworkAccessPoints/t3Channel')
set('Protocol','t3')
set('ListenPort',int(listen_port))
set('PublicPort',int(public_port))
print('Channel t3Channel added ...')
activate()
disconnect()
Summary
WebLogic ServerはT3プロトコルを使うRMI通信を使用して、WebLogic Serverインスタンス間および他のJavaプログラムとクライアント間を通信します。WebLogic ServerがKubernetesクラスタで動作する場合、RMI通信を行うために考慮すべき特別な事項と構成要件があります。このエントリでは、Kubernetesクラスタの外部からのRMI通信がKubernetesクラスタ内で実行されているWebLogic Serverインスタンスに正常に到達できるように、WebLogic ServerとKubernetesを構成する方法について説明しています。EJB、JMS、JTA、WLSTなど、T3 RMIを使用する多くのWebLogic Server機能では、Kubernetesクラスタの内部と外部のクライアントをサポートしています。さらに、マルチノードKubernetesクラスタ内の単一、および複数のWebLogicドメインの両方をサポートします。
0 件のコメント:
コメントを投稿