| Oracle® Fusion Middleware WebLogic Server Multitenantの使用 12c (12.2.1) E67376-02 |
|
 前 |
 次 |
WebLogic Server Multitenantは、Software-as-a-Service (SaaS)およびPlatform-as-a-Service (PaaS)用にOracleプラットフォームを拡張し、エンドツーエンドのライフサイクル管理(Web層、中間層、キャッシュおよびデータベース)を提供します。
このドキュメントでは、WebLogic Server Multitenant (MT)を紹介し、マルチテナント環境でのその使用方法について説明します。
トピック:
|
注意: リソース・グループ、リソース・グループ・テンプレート、デプロイメント・プランのオーバーライドなどのWebLogic Server MTの新機能の多くは、WebLogic Serverの非MTバージョンである12.2.1でも使用可能です。この章では、特定の機能が非MTバージョンで使用可能になる場合について記載し、必要に応じてWebLogic Serverドキュメントおよびオンライン・ヘルプを参照します。 |
WebLogic Serverのマルチテナントにより、複数の組織で使用できる共有可能なインフラストラクチャが提供されます。これらの組織は、テナントとして考えることができる、独自に選択した概念的なグループです。1つのドメインが複数のテナントをサポートできるようにすることによって、WebLogic Server MTは、複数のアプリケーションを共有しようとする際によく発生する困難(アプリケーション間のランタイムの影響、セキュリティの相違、データの混在、管理の課題など)を排除しながら、密度を改善し、リソースの効率的な使用を実現します。
WebLogic Server MTにより、テナントに対する実行中のアプリケーション・インスタンスおよび関連リソースの専用WebLogicドメインの管理スライスとランタイム・スライスであるドメイン・パーティション内のリソースの分離が実現します。ドメイン・パーティションによって、アプリケーション・インスタンスと関連リソースがドメイン、WebLogic Server自体、Java仮想マシンおよびオペレーティング・システムを共有できるようにすることで密度が改善されることに加えて、図2-1に示すように、テナント固有のアプリケーション・データ、構成およびランタイム・トラフィックが分離されます。
各ドメイン・パーティションには、独自のアプリケーションおよびリソースのランタイム・コピーが含まれます。WebLogic Serverによるクラス・ロードの処理方法の変更により、アプリケーションの分離と効率性の両方が実現します。マルチテナント環境にデプロイする場合は、アプリケーションを変更する必要はありません。たとえば、アプリケーションを変更せずに、異なるドメイン・パーティションにある給与計算アプリケーションの複数のインスタンスを実行できます。
WebLogic Server MTでは、WebLogic Server Enterprise EditionとWebLogic Suiteの各製品が拡張されて、次のコンポーネントが含まれます。
WebLogic Server
Oracle Traffic Director
Coherence
Fusion Middleware Control (主要なグラフィカル・ユーザー・インタフェース)
このリリースのWebLogic Server MTでは、Java EEアプリケーションのみがサポートされます。Oracle JRF (Java Required Files)に依存する製品はサポートされません。
Oracle JRFは、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークに共通の機能を提供する、WebLogic Serverインストールに含まれていないコンポーネントで構成されています。Oracle JRFは、共通の場所にデプロイされている個別に開発したライブラリおよびアプリケーションで構成されています。Oracle JRFの一部とみなされるコンポーネントには、Oracle Application Development Framework、Oracle Fusion Middleware監査フレームワーク、ダイナミック・モニタリング・サービス、Fabric Common、HTTPクライアント、インフラストラクチャ・セキュリティ、Javaオブジェクト・キャッシュ、JMXフレームワーク、JPS、ロギング、MDS、OJSP.Next、Oracle Webサービス、Oracle Web Services Manager、Oracle TopLink、UCP、XDKなどがあります。
これは、WebLogic Server MTは次の製品をサポートしないことを意味します。
Oracle Web Service Manager
SOA Suite
アプリケーション開発フレームワーク(ADF)
WebCenter
Oracle Service Bus
Oracle Enterprise Scheduler
WebLogic SCA
ドメイン・パーティションに加えて、WebLogic Server MTには次の新しい概念があります。
テナント - テナントは、WebLogicドメイン内でアプリケーションおよびリソースを使用する異なる外部の企業(たとえば、CompanyAとCompanyB)や、1つの企業内の異なる部署(たとえば、HRと会計)などの、個別のユーザー組織を表します。
テナントは独自に選択した論理グループで、これは構成可能なオブジェクトではありません。つまり、テナントではなく、ドメイン・パーティションを管理します。
テナントのアイデンティティは、特定のユーザーの特定のテナントとの関連付けです。たとえば、テナントFinanceをFinance-partitionという特定のドメイン・パーティションと関連付けるように選択できます。
ユーザー・アイデンティティ・ストアで指定されたように、ユーザーのアイデンティティから、特定のユーザーが属するテナントが導出されます。さらに、ユーザーのアイデンティティは、そのユーザーがユーザーの属するテナントを含む(ただしこれに限定されない)システム全体を移動する際の、認可される操作の適用に役立ちます。
リソース・グループ - (通常は)デプロイ可能な関連リソースの名前付きのコレクションです(たとえば、Java EEアプリケーションとそのデータ・ソース、JMSアーティファクト、アプリケーションが使用する他のリソースなどです)。
従来のWebLogic Serverドメインには、Java EEアプリケーション、JMSサーバーおよびキュー、データ・ソースなどの、複数のタイプのデプロイ可能なリソースを含めることができます。この従来のモデルでは、アプリケーション・スイートに複数のJava EEアプリケーションとそれらのアプリケーションをサポートする様々なリソースが含まれる場合は、管理者が一貫性のある単位としてではなく、個別にこれらのリソースを定義し、これらのアプリケーションをデプロイします。
WebLogic Server MTは、Java EEアプリケーションとそれらが使用するリソースを、ドメイン内の個別の管理単位にグループ化するための便利な方法として、リソース・グループを導入しています。リソースとアプリケーションは完全修飾されており、その中に、それらのリソースを開始したりそれらに接続するために必要なすべての情報(データ・ソースに接続するための資格証明やJava EEアプリケーションのターゲット指定情報を含む)が管理者によって提供されます。リソース・グループは、これらのデプロイ可能なリソースを直接含むか、リソースを定義するリソース・グループ・テンプレートを参照します。リソース・グループは、ドメイン・レベルで定義することも、ドメイン・パーティションに固有のものとすることもできます。
リソース・グループ内のすべてのリソースまたはリソース・グループによって参照されるすべてのリソースは、(同じターゲットに)まとめてターゲット指定されます。リソース・グループは起動および停止できます。
リソース・グループ・テンプレート - (通常は)複数のリソース・グループによってパターンとして使用されるデプロイ可能なリソースの名前付きのドメイン・レベル・コレクションです。特定のテンプレートを参照する各リソース・グループには、そのテンプレートに定義されているリソースの独自のランタイム・コピーが含まれます。リソース・グループ・テンプレートは、複数テナント用にリソースを定義およびレプリケートする便利な方法です。リソース・グループ・テンプレートにより、アプリケーションとリソースの同じコレクションを複数のドメイン・パーティションにデプロイすることが非常に簡単になります。
リソース・グループ・テンプレートでは、次を定義できます。
アプリケーションのデプロイメント
ライブラリのデプロイメント
JDBCシステム・リソース
JMSシステム・リソース
Coherenceシステム・リソース
ファイル・ストア
JMSサーバー
メッセージング・ブリッジ
パス・サービス
永続ストア
SAFエージェント
外部JNDIプロバイダ
メール・セッション
WLDFモジュール
リソース・グループ・テンプレートはドメイン・レベルで定義され、その後1つ以上のリソース・グループに参照されます。
リソース・グループ・テンプレートは、WebLogic Server MTが同じアプリケーションとリソースを複数回アクティブ化する(ドメイン・パーティションごとに1回ずつ) SaaS環境で特に役立ちます。そのようなリソースに関する情報のいくつかはすべてのドメイン・パーティションで同じになり、JMSキューの属性やDB接続の属性などのそのいくつかはパーティション間で異なります。たとえば、データ・ソースへの接続に使用されるURL、ユーザー名およびパスワードは、パーティション間で異なります。WebLogic Server MTは、パーティションごとに異なるテンプレートによって表されるアプリケーション・スイートをアクティブ化します。オーバーライド構成MBeanとリソース・デプロイメント・プランを指定して、パーティションのいくつかの属性値をオーバーライドできます。詳細は、「リソース・オーバーライドの構成」を参照してください。
仮想ターゲット - 仮想ターゲットは、パーティションまたはリソース・グループの実行場所およびそれらへのトラフィックをルーティングする方法(アドレス、プロトコル設定、ターゲット指定など)をカプセル化します。リクエスト・ルーティングは、ホスト名とオプションのURIで決定します。
次が含まれます。
ホスト名とポート
オプションのURI
ネットワーク・アクセス・ポイント/チャネル
プロトコル固有構成
ターゲット・クラスタおよび管理対象サーバー
仮想ターゲットにより、ドメイン・パーティションとグローバル(ドメイン・レベル)ランタイムがターゲットのWebLogic Serverインスタンスの物理属性から分離されるため、アプリケーションがこれらの詳細を認識する必要がなくなります。
アプリケーションまたはライブラリをデプロイする場合、4つのデプロイメント・スコープ・オプションから選択できます。
グローバル。これは、非パーティション環境のドメイン・レベルと同等です。
リソース・グループ・テンプレート、これは常にドメイン・レベルとなります。リソース・グループ・テンプレートにデプロイするアプリケーションまたはライブラリがドメイン・レベルとパーティションのいずれで使用できるかは、リソース・グループ・テンプレートを参照するリソース・グループのスコープに応じて異なります。
パーティション内のリソース・グループ。これは、パーティションに制限される唯一のスコープです。
ドメイン・レベルでのリソース・グループ。
ドメイン・パーティション間でアプリケーションまたはライブラリを共有できません。アプリケーションまたはライブラリはパーティション内でのみ使用可能です。アプリケーションまたはライブラリをデプロイするときに、パーティション内のリソース・グループを指定します。FMW Controlでは、パーティション内のリソース・グループにデプロイされるアプリケーションおよびライブラリに、ドメイン・パーティションの名前と、それらがデプロイされたそのパーティション内のリソース・グループが表示されます。
ドメイン・レベルで実行されるアプリケーションまたはクラスと、パーティションのコンテキストで実行されるアプリケーションまたはクラスの主な違いは、次のとおりです。
ドメイン・レベルで実行されるアプリケーションまたはクラスはドメイン全体で使用できますが、パーティションでは使用できません。
パーティションのコンテキストで実行されるアプリケーションまたはクラスは、そのパーティション内でのみ使用できます。
|
注意: 推奨のベスト・プラクティスは、すべてのアプリケーションおよびリソースをドメイン・パーティションにデプロイすることです。 |
リソースの分離は、パーティション環境では非常に重要です。ドメイン・パーティションにリソース・グループを作成すると、WebLogic Server MTによって、JMSサーバー、JMSストアおよびJMSモジュール(接続ファクトリ、キュー、トピックなど)、JCAアダプタおよびその他の関連するリソースを含む、アプリケーションに必要なすべてのリソースのランタイム・コピーが作成されます。
パーティション内にアプリケーションまたはライブラリをデプロイすると、行った構成の変更はそのパーティションに固有のものとなります。WebLogic Server MTでは、1つのパーティション内のアプリケーションはそのパーティションに適用されたリソースのみを参照するようになり、他のパーティションに関連付けられたリソースは参照しません。
WebLogic Server MTのリソースの分離には次が含まれます。
セキュリティ - 各ドメイン・パーティションの一意のセキュリティ・レルムおよびアイデンティティ・ドメイン。
管理:
パーティション固有の管理
独立したデプロイメント、構成およびソフトウェア更新
パーティション固有のモニタリングおよびトラブルシューティング
ランタイム:
専用のJNDI - WebLogic Server MTでは、JNDIレベル(パーティションに対応)のパーティション間の分離が提供されます。アプリケーションで名前付きオブジェクトをバインドして、パーティションごとにそれらを取得できます。各リソースはパーティション固有の名前で(内部的に)タグ付けされ、パーティション専用のJNDIツリーに配置されます。クラスタ内のパーティションのアプリケーション内通信およびアプリケーション間通信は、パーティションで自動的に分離されます。
分離されたデータ - JMS、ファイル・システムおよびデータ・ソース
リソースの分離と公平性 - リソース消費マネージャ(RCM)によって、JVMまたはOSによって提供されたリソースが管理されます。これにより、システム管理者が、CPU、ヒープ、ファイル、ネットワークなどのリソースに対して、リソース消費管理ポリシー(制約、リコース・アクション、通知など)を指定できるようになります。
パーティション・ワーク・マネージャ - 同じWebLogic Serverインスタンスを共有するパーティション間で作業リクエストのスレッド使用量および優先度付けの公平性を提供します。
WebLogic Server MTの2つの主なアクターは、WebLogic Serverシステム管理者とパーティション管理者です。
WebLogic Serverシステム管理者は、テナントのパーティションを作成および削除します。パーティションのセキュリティ特性(セキュリティ・レルムやSSL構成など)の設定または変更と、共有(ドメイン・レベル)リソース・グループまたはリソース・グループ・テンプレートの参照を行うことができるのはシステム管理者のみです。
「構成および管理用の管理ロール」で説明しているように、WebLogic Serverシステム管理者とパーティション管理者の大きな違いは、パーティション管理者はパーティション固有のセキュリティ・レルムに直接ログインすることです。
パーティション管理者は、パーティション内のリソース・グループごとに、パーティション構成の変更、アプリケーションのデプロイ、JMSリソース、データ・ソースおよびJDBC接続の作成など、パーティション・レベルでパーティションを管理します。
システム管理者とパーティション管理者の両方が、次の操作を行います。
パーティション内のリソース・グループを作成、変更および削除します。
パーティション内のリソース・グループに対してアプリケーションをデプロイおよびアンデプロイします。
パーティションを起動および停止します - すべてのリソース・グループとそれらのリソース・グループにデプロイされたすべてのアプリケーションが起動または停止されます。
WebLogicのロールと同様に、デプロイヤ、オペレータおよびモニターにはパーティションで制約されたロールが存在します。
SaaS環境で、アプリケーションが内部的にテナントごとのビューまたは必要なテナントごとの分離を提供できない場合は、かわりにテナントごとに個別のアプリケーションのインスタンスとその関連するサーバー側リソースをデプロイできます。各テナントで、ハードウェア容量またはJava仮想マシン、WebLogic Serverドメイン、管理サーバー、管理対象サーバー、クラスタ、およびWebサーバー、データ・グリッド、ネットワーキング、記憶域などのその他の関連リソースを含む独自のスタックが取得される場合があります。少なくとも、これは非効率的です。
WebLogic Server MTのSaaSモデルでは、引き続きリソースの分離を提供しながら、サーバー・リソースを最大限効率的に使用する方法が提供されます。各テナントで、アプリケーション・インスタンスと、ターゲット・サーバーおよびクラスタのリソース・インスタンスが取得されます。複数のドメイン・パーティションで、1つ以上の同じアプリケーションが同時に独立して実行されます。アプリケーションのコードの変更は必要なく、WebLogic Serverによってドメイン・パーティションの識別と分離が管理されます。
SaaSモデルでは、通常、1つ以上のアプリケーションと、それらがリソース・グループ・テンプレートで依存するリソースを定義します。その後、同じアプリケーションを使用するすべてのドメイン・パーティションからこのテンプレートを参照します。ドメイン・パーティション固有の変更を行うには、関連するリソース・グループの値を編集します。
SaaSモデルの手順フローの概要は次のとおりです。
WebLogic Serverシステム管理者が、リソース・グループ・テンプレートのJMSリソース、データ・ソースおよびその他のリソースを作成します。
WebLogic Serverシステム管理者は、必要なアプリケーションをリソース・グループ・テンプレートにデプロイします。
テナントに対してデプロイする準備ができたら、システム管理者が次の手順を実行します。
必要な場合は、仮想ターゲットを作成します。
リソース・グループ、プラガブル・データベース(PDB)情報、仮想ターゲット、セキュリティ・レルムを含むドメイン・パーティション構成を作成し、パーティションをクラスタまたは一連の管理対象サーバーにターゲット指定します。
特定のリソース・グループおよびアプリケーション・デプロイメントの値をオーバーライドします。
ドメイン・パーティションを起動することで、そのパーティションのリソース・グループにデプロイされたすべてアプリケーションを起動します。
ドメイン・パーティションが起動された後は、パーティション管理者がパーティションのアプリケーションおよびリソースのランタイム状態を確認したり、パーティションのログ・エントリを確認したり、パーティションのアプリケーションを停止および再起動できます。
デプロイ時に、リソース・グループ・テンプレートのアプリケーションおよびリソースがリソース・グループの各ドメイン・パーティションにレプリケートされてデプロイされ、さらに結果として次のようになります。
WebLogicインフラストラクチャがドメイン・パーティション間で共有されます。
個々のアプリケーション・インスタンスが独自のJNDIツリーとリソースを持つようになります。
ランタイム・トラフィックがエンドツーエンドに分離されます。アプリケーションには仮想ターゲットからアクセスします。
パーティション・ワーク・マネージャにより、パーティション間で作業リクエストのスレッド使用量および優先度付けの公平性が実現します。
データがプラガブル・データベース(PDB)によって分割されます。データ・ソースの実装により、ドメイン・パーティションごとに、その割り当てられたPDBへの個別の物理接続プールが作成されます。
SaaS環境でドメイン・パーティションを使用する多くの利点のうちの1つは、制御された本番環境で新しいバージョンのアプリケーションをテストできることです。
たとえば、ビジネスで重要なアプリケーションがPartition Aにデプロイされているとします。このアプリケーションに大きな変更を行う場合は、多くの場合それがユーザーに一般提供される前に、それを本番環境でテストする必要があります。WebLogic Server MTでは、これを簡単に実行できます。Partition Aで実行されているアプリケーションの安定したバージョンに影響を与えることなく、Partition Bを作成して、更新されたアプリケーションをデプロイできます。
Partition Bで実行されているアプリケーションの更新バージョンを実際の本番クラスタおよびデータ・ソースにターゲット設定して、制御された環境内でパフォーマンス・メトリックなどのすべてをテストして調整できます。
WebLogic Server MT PaaSモデルは、統合と同じ意味です。統合は、多数のテナントからの異なるアプリケーションを同じWebLogicインフラストラクチャにデプロイできることを意味します。WebLogic Server MTでは、インフラストラクチャと、ドメイン、クラスタ、管理対象サーバー、ハードウェア、ネットワークなどの基礎となるリソースが共有されます。SaaSユースケースでは、通常、WebLogic Serverシステム管理者がすべてのドメイン・パーティションと、それらのリソース・インスタンスを管理します。ただし、PaaSユースケースでは、多くの場合パーティション管理者がリソースの構成やアプリケーションのデプロイなどを行って、それぞれのドメイン・パーティションとその中のリソースを管理します。
統合:
多数のテナントからのアプリケーションを同じWebLogicインフラストラクチャに簡単にデプロイできます。
結果として、管理するドメインが1つ、リソースを消費するJVMが1つになります。
管理を分離します。WebLogic Serverシステム管理者がインフラストラクチャを管理します。パーティション管理者がドメイン・パーティションのデプロイメントと関連するリソースを管理します。
ドメイン・パーティション固有のコンポーネント(セキュリティ・レルム(テナントごと)、仮想ターゲット(アドレス)、プラガブル・データベース、JNDI (内部トラフィック)、JMS、ワーク・マネージャ)を含むランタイムを分離します。各テナントで、アプリケーション・インスタンスと専用リソースの独自のセットを取得します。
PaaSユースケースでは、通常、各テナントで異なるアプリケーションが実行されて、これらのアプリケーションが他のテナントで実行されたアプリケーションと重複する場合としない場合があります。WebLogic Server MT PaaSソリューションを実装すると、通常、リソース・グループ・テンプレートを参照しないが、かわりにドメイン・パーティション内でのみ使用可能になるアプリケーションとその関連リソースを表す、自己完結型のリソース・グループを作成します。ただしこれは、PaaSソリューションではリソース・グループ・テンプレートがあまり使用されないとしても、それらがユースケースに適合する場合にPaaSソリューションでリソース・グループ・テンプレートを使用できないことを意味するわけではありません。
PaaSモデルの手順フローの概要は次のとおりです。
WebLogic Serverシステム管理者が、必要に応じて仮想ターゲットを作成します。
WebLogic Serverシステム管理者が、ワークロードを管理する指定されたパーティション・ワーク・マネージャまたはサービス品質(QoS)定義とともにドメイン・パーティションを作成します。
パーティション・ワーク・マネージャでは、パーティションの相対的な優先度と、基礎となるメモリーとCPUの可用性が定義されます。
WebLogic Serverシステム管理者が、ドメイン・パーティションのセキュリティ・レルムを選択し、使用可能なターゲットのリストを設定します。
ドメイン・パーティションのリソースとアプリケーションは、ドメイン・パーティションのセキュリティ・レルム内のユーザーのみが使用できます。他のテナントでは、リソースまたはアプリケーションを表示することもアクセスすることもできません。
WebLogic Serverシステム管理者が、パーティション管理者にドメイン・パーティションを割り当てます。
リソースとアプリケーションは、パーティション管理者が管理します。(基礎となる管理対象サーバーとクラスタはパーティション管理者によって管理されません。)
パーティション管理者が、そのドメイン・パーティションに1つ以上のリソース・グループを作成し、使用可能なターゲットのリストからリソース・グループをターゲット指定します。
パーティション管理者が、ドメイン・パーティションの各リソース・グループに、異なるJMSリソース、データ・ソース、PDB情報、アプリケーションのデプロイメントなどを作成します。
パーティション管理者がドメイン・パーティションを起動し、これによってパーティションのリソース・グループにデプロイされたすべてアプリケーションを起動します。
追加のテナントごとに、手順1-4を繰り返します。
Fusion Middlewareのエンタープライズ・デプロイメントは複雑になる場合があります。WebLogic Server MTは、分離のためのパーティションを使用して、多くのドメインを1つに統合することを簡略化し、コンポーネント構成間の新しいレベルの調整を導入します。
WebLogic Server MTライフサイクル管理は、異なるコンポーネント間のパーティションをリンクして、テナントのニーズに応える1つの結合ユニットを形成します。これを行うには、ライフサイクル・マネージャは、コンポーネント全体の構成を統合します。
REST、WLST、Fusion Middleware ControlまたはWebLogic Server管理コンソールを介して、パーティションを作成、更新または削除すると、ライフサイクル・マネージャは、これらのアウト・オブ・バンド・アクションを検出し、その構成を管理サーバーの構成と同期します。ライフサイクル・マネージャは、登録されているプラグイン(Oracle Traffic Director (OTD)プラグインなど)にこれらの変更を通知して、環境全体で同期を維持します。
WebLogic Server MTでドメイン・パーティションが作成または更新されると、変更は複数の層にわたって編成されます。
OTD構成が更新され、新しいパーティションに接続されます。
アプリケーションがCoherenceキャッシュまたはサービスに接続されます。
データ・ソースが既存のデータベースまたはプラガブル・データベース(PDB)に接続されるか、新しいPDBが作成されます。
図2-2に、エンドツーエンドのトラフィックの分離と、Web層からデータベース層へのフローを示します。
