https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets
WebLogic Serverのmulti-tenancyサポートについてご存知ない場合、まずはTim Quinnのエントリを一読することをおすすめします。この中でWebLogic Server 12.2.1のパーティション機能の概要とこの記事で使っているコンセプトを紹介しています。
Domain Partitions for Multi-tenancy in WebLogic Server
https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html
Partition Targeting
Timのブログでわかるように、ドメインパーティション（以後パーティションと略します）はアプリケーションやリソースの集合を含むWebLogicドメインの管理権限とランタイムのスライスです。これらのアプリケーションやリソースはドメイン中（クラスタ、特定の管理対象サーバ、もしくは管理サーバ自身）で実行する上で必要なものです。12.1.3以前では、アプリケーションやリソースのターゲットを個別に指定しています。通常は管理対象サーバやクラスタに対して直接指定します。パーティションの場合、少々異なります。
- パーティションでは、リソースとアプリケーションはリソースグループとしてまとめられ、リソースグループに対してターゲットを指定します。ターゲットがリソースグループに設定されると、ターゲットはリソースグループ内のすべてのリソースやアプリケーションに対して適用します（リソースグループ内で個別にターゲット指定できません）。
- パーティション内のリソースグループを仮想ターゲットに対してターゲット指定します。つまり管理対象サーバやクラスタに直接ターゲットを指定しません。
Virtual Targets
では、仮想ターゲットとは何でしょうか。WebLogic Serverの仮想ホストやWebサーバの仮想ホストという一般的なコンセプトをご存知であれば、仮想ターゲットが仮想ホストに類似するものと考えることができることでしょう。仮想ターゲットで以下の3点を達成します。- 物理ターゲット（クラスタやサーバ）を提供。仮想ターゲットを物理ターゲットにデプロイし、仮想ターゲットにデプロイされた任意のリソースを、仮想ターゲットをラップする物理ターゲットにデプロイする。
- 個別のHTTPサーバを提供。そのため、仮想ターゲットにデプロイされた任意のWebアプリケーションはそれのHTTPサーバで動作する（デフォルトのHTTPサーバではない）。
- 特定仮想ターゲットへのインバウンドリクエストのマッピングを（URLの形式で）提供する。結果として特定パーティションへのリクエストのマッピングを提供する。
Physical Targets
管理対象サーバまたはクラスタを仮想ターゲットの物理ターゲットとして（VirtualTargetMBeanのsetメソッドもしくはaddTargetメソッドを使用して）指定することができます。VirtualTargetMBeanメソッドは、複数の物理ターゲットをサポートしていても、VirtualTargetに複数の物理ターゲットを設定できないようにするため、現在バリデーションがかかりますのでご注意ください。物理ターゲットは以下の2項目を実現します。
- 仮想ターゲットのデプロイ先（つまり仮想HTTPサーバが動作する場所）
- リソースやアプリケーションを仮想ターゲットにデプロイした場合に使われる場所
HTTP Server
各仮想ターゲットには個別にHTTPサーバがあり、仮想ターゲットが動作している（ターゲットとして指定されている）管理対象サーバ（もしくは管理対象サーバのクラスタ）上で遅延初期化されます。仮想ターゲットにデプロイされた任意のWebアプリケーションやリソースはこのHTTPサーバで動作します。これにより、アプリケーションが別の仮想ターゲット（もしくはデフォルトのHTTPサーバ）で動作してもコンテキストパスの衝突は起こりません。URL mapping
リクエストがWebLogic Serverインスタンスに入ると、2個の重要なことが起こる必要があります。- URLが所属するパーティションを識別する必要があります。
- HTTPリクエストの場合、適切なHTTPサーバを使うようVirtualTargetを配置する必要があります。
仮想ターゲットには3個の属性があり、以下のマッチングを実現するために設定できます。
- Virtual hostnames: 1つまたは複数の仮想ホスト名
- uriPrefix: 1個のURI接頭辞パス
- port: ポート番号
Virtual Hostnames
仮想ターゲットはゼロ個以上の仮想ホスト名を持つことができます。これらのホスト名をクライアントが使うホスト名に対してマッチングします（HTTP 1.1で導入されたフィールド。HTTPを使うとホストによって提供されます）。マッチングは、リテラル文字列の比較ですが、複数のホスト名を指定することができます。これは、リクエストで使われる可能性のあるすべてのホスト名（myserver、myserver.us.com、など）をエイリアシングするのに便利です。また、仮想ホスト名はなくてもかまいません。uriPrefixのみ（もしくはポート番号のみ）を使いたいのであれば、それで大丈夫です。URI Prefix
ホスト名の一致に加えて、例えば"/partition1"といった具合で、特定のURIパスで始まるすべてのリクエストが当該仮想ターゲットに一致するよう、着信リクエストのURIに一致させることができます。Port Number
ポート番号に基づくルーティングは、URLの変更ができない古いクライアントの後方互換性を主たる目的として提供されています。仮想ターゲットで明示的なポート番号もしくはポート番号のオフセットを指定することができます。ポート・オフセットを使う場合、オフセットをサーバのデフォルトチャネルに適用します。仮想ターゲットにベースチャネル名を指定する場合は、特定のベースチャネル名に対して適用します。仮想ターゲットにポート番号を指定する場合、WebLogic Serverは自動的に仮想ターゲットのチャネルを実行時に作成するので、こうしたチャネルをご自身で作成する必要はありません。当該チャネル（ポート番号）に入ってくる任意のリクエストは仮想ターゲットに流れます。この点で、ポート番号は、URI接頭辞と仮想ホスト名の両方を上回ります。
Examples
下表はどのようにマッチングが機能するかを説明したものです。ここではサーバのデフォルトのポート番号を7001と仮定しています。| ホスト名 | uriPrefix | ポート番号 | 一致するURL | 一致しないURL | Notes |
| red red.com | - | - | http://red:7001/myapp http://red.com:7001/myapp | http://red.us.com:7001/myapp | ホスト名は文字列と厳密に一致しなければならない。 |
| colors colors.com | /red | - | http://colors:7001/red/myapp http://colors.com:7001/red/myapp | http://red.com/red/myapp | ホスト名とuriPrefixの両方一致しなければならない。 |
| - | - | 7277 | http://anyhost.com:7277/myapp | http://anyhost.com:7001/myapp | ポート番号7277から到達する任意のリクエストに一致する。その他は一致しない。 |
| - | /red | - | http://anyhost.com:7001/red/myapp | http://colors.com:7001/blue/myapp | ホスト名を指定しない。この場合、ホスト名は基本的にワイルドカード。 |
Tips
スキームをPick a scheme and stay with it and don't get fancy probing strange combinations. 通常は以下のパターンのうちの一つを使いたいと思うでしょう。- 仮想ホストのみで識別する（red.com, blue.com, green.com）
- uriPrefixのみで識別する（colors.com:7001/red, colors.com:7001/blue, colors.com:7001/gree）
- ポート番号のみで識別する（colors.com:7277, colors.com:7278, colors.com:7279）
- 既存クライアントの後方互換性を保つ必要性から、ポート番号によってのみ識別する
一般的なHTTP仮想サーバ（仮想ホストとしても知られています）のコンセプトに詳しくない場合は、このトピックに関する文書を読んでおくべきでしょう。
Partition Targeting
最初に述べたように、パーティションのリソース/アプリケーションはリソースグループにまとめられ、リソースグループがターゲットに対して指定されます。いくつか重要なコンセプトがあります。- パーティションの利用可能なターゲット（PartitionMBean availableTargets）: これはパーティション内でリソースグループを対象とするために使われる仮想ターゲットのリストです。通常、WebLogic Serverの管理者は数多くの仮想ターゲットをドメイン内に作成し、その後仮想ターゲットのサブセットを特定のパーティションに割り当てます。パーティション内のリソースグループはこれら利用可能なターゲットの一つに対してターゲット指定します。
- パーティションのデフォルトターゲット（PartitionMBean defaultTargets）:パーティションは、0個以上のデフォルトターゲットを持つことができます。パーティション内のリソースグループを明示的にターゲットとすることができます（ResourceGroupMBeanのメソッドを使ってターゲットの設定や追加ができます）。しかし明示的なターゲットをリソースグループに対して設定していない場合、デフォルトではパーティションのデフォルトターゲットを選択します。
- ResourceGroupMBean:useDefaultTargetsというboolean属性があります。この値がTrue（デフォルト値）の場合、明示的なターゲットが設定されていない場合、リソースグループはパーティションのデフォルトターゲットをターゲットとして利用します。この値がfalseの場合、リソースグループはパーティションのデフォルトを使わないので、ターゲットをリソースグループに対して明示的に設定する必要があります。また、明示的にターゲットをリソースグループに設定した場合、パーティションのデフォルトを選択しないことを見越してこのフラグはfalse"へと反転します。
- パーティションのeffective targets（事実上のターゲット）：パーティションのリソースグループが任意のタイミングで利用する、利用可能なターゲットの（サブ）セット
- WebLogic Serverの管理者は、パーティションが利用する仮想ターゲットをドメインレベルで作成
- WebLogic Serverの管理者は、パーティションを作成し、パーティションで利用可能なターゲットを各パーティションに使わせたいターゲットのセットに設定
- WebLogic Server（もしくはパーティションの）の管理者は、パーティションにリソースグループを作成し、パーティションに対し利用可能なターゲットに基づいて、リソースグループターゲットを設定する（もしくはパーティションのデフォルトを利用する）
Gotchas
その他注意すべきことをいくつか。- 仮想ターゲットの占有: ホスト名を持たない、"/"というuriPrefixを持つ仮想ターゲットを定義すると、仮想ターゲットは、ドメインに入ってくるすべてのリクエストを占有します。全く望んではいないでしょうが、これは破綻します。WebLogic Serverの構成検証機能により、そのような仮想ターゲットの作成ができないようになってはいますが、すべてのパターンに対応できているわけではありません。そのため、仮想ターゲットを具体的に意図したリクエストにマッチングさせるように留意する必要があります。
- 制限事項: 12.2.1では、ターゲティングに制限があります。その例をご紹介します。
- 仮想ターゲットを複数のパーティションで共有できません
- 仮想ターゲットはターゲットとして1個の（サーバもしくはクラスタの）セットのみ持つことができます
- リソースグループを複数の仮想ターゲットに対してターゲット指定することができます。
- ただし、リソースグループに以下のコンポーネントが1個以上含まれていないことが条件です。
- JMSServer
- MessagingBridge
- PathService
- JMSBridgeDestination
- FileStore
- JDBCStore
- JMSSystemResource
End-to-End Example
以下は、WLSTを使って、一つのリソースグループと仮想ターゲットを持つ”Acme”という名前のパーティションを作成する簡単なサンプルです。アプリケーションを当該リソースグループにデプロイします。仮想ターゲットには物理ターゲットとして"myserver"（管理サーバ）があり、"/acme"というuriPrefixを使います。そのため、アプリケーションへアクセスする場合には"/acme"をURLの前に付ける必要があります。最終的に、パーティションがデフォルトでは動作していないので、パーティションが起動します。import os,sys,urllib,time
# Change this to the location of a simple web application.
APP_PATH='/scratch/tmp/counter.war'
# Change these to your admin login credentials and connection URL
USER='admin'
PASSWORD='admin123'
T3_URL='t3://localhost:7001'
# Change this to be the name of the server you want to deploy the app to
SERVER='myserver'
print "Connecting to " + T3_URL
connect(USER,PASSWORD,T3_URL)
edit()
domain=getMBean('/')
tgt=getMBean('/Servers/' + SERVER)
# Create "Acme" virtual target
# We set a uriPrefix only (no virtual host names)
startEdit()
acmevt=domain.createVirtualTarget('AcmeVT')
acmevt.addTarget(tgt)
acmevt.setUriPrefix('/acme')
# The VT contains a virtual HTTP server. We can configure it
acmevt.getWebServer().getWebServerLog().setBufferSizeKB(0)
activate()
# Create Acme partition and ResourceGroup
startEdit()
acmepart=domain.createPartition('Acme')
acmepart.addAvailableTarget(acmevt)
acmerg=acmepart.createResourceGroup('SimpleRG')
acmerg.addTarget(acmevt)
activate()
# Deploy the application to SimpleRG in partition Acme
startEdit()
progress=deploy(appName='sampleapp',
path=APP_PATH,
partition=acmepart.getName(),
resourceGroup=acmerg.getName(),
deploymentOrder=10,securityModel='DDOnly')
activate()
while not (progress.isCompleted() or progress.isFailed()) :
os.time.sleep(2)
progress.printStatus()
# You must start the partition to get the stuff in it running
# This is a convenience command to start the partition and
# wait for it to come up
startPartitionWait(acmepart)
# Now hit the webapp at (for example) http://localhost:7001/acme/webapp/webapp.jsp
0 件のコメント:
コメントを投稿