Oracle Java Cloud Serviceインスタンスを作成する前に、要件に最も合うサービス・インスタンスを作成するために考慮する必要がある詳細があります。
サービス・インスタンスを設計するときは、次の点を考慮してください。
| 詳細 | 説明 |
|---|---|
|
サービス・レベル |
次のいずれかのサービス・レベルを選択できます。
注意: Fusion MiddlewareサービスレベルのOracle Java Cloud Serviceはサポートされていません。 |
|
ソフトウェア・リリース |
3つのOracle WebLogic Serverリリースのいずれかを選択できます。
Oracle Java Cloud Service製品とOracle WebLogic Serverソフトウェア・リリースについてを参照してください。 Oracle Java Cloud Serviceでは、既存のサービス・インスタンスにパッチを簡単に適用できますが、既存のサービス・インスタンスをOracle WebLogic Serverの新しいリリースにアップグレードする自動化ツールは用意されていません。 |
|
エディション |
次のいずれかのOracle WebLogic Serverエディションを選択できます。
WebLogic Serverの一部の機能は、特定のエディションでのみサポートされます。 これらのエディションの詳細は、次を参照してください。 |
|
計算シェイプ |
Oracle Java Cloud Serviceは様々な使用ケースに適した一連のコンピューティング形態を備えています。 全目的型およびメモリー集中型の一連の形態から選択します。 コンピューティング形態が大きくなるほど、処理能力が向上し、使用可能なメモリーが増加します。 Oracle Java Cloud Serviceインスタンスのデフォルト・ヒープ・サイズ設定についてを参照してください。 |
|
クラスタ |
1つ、2つまたは4つの管理対象サーバーの初期クラスタ・サイズを選択します。 一般に、クラスタが大きくなるほど、サービス・インスタンスによって処理できるアプリケーション・リクエストの数が増えます。 ただし、Oracle Java Cloud Serviceでは、サービス・インスタンスの作成後にこのクラスタをスケール・インおよびスケール・アウトすることもできます。 クラスタの詳細は、次を参照してください。
|
|
ドメイン・パーティション |
WebLogic Server 12cドメインは、オプションで複数のパーティションに分類できます。 各パーティションは、特定のアプリケーションおよび関連リソースの実行専用となり、同じドメイン内の他のパーティションとは別個に管理されます。 パーティションはサービス・インスタンスの作成時に定義できます。サービス・インスタンスの作成後は、Fusion Middleware Controlを使用してドメイン・パーティションを追加または削除できます。 これらのドメイン・パーティションは、デフォルトのリソース管理ポリシーで作成されます。 ドメイン・パーティションを使用して、WebLogic Serverドメイン全体と個々のパーティションで異なるセキュリティ・レルムを作成することもできます。 各セキュリティ・レルムは、ユーザー、資格証明およびグループを含む独自のアイデンティティ・ストアを保有できます。 WebLogic Server Multitenantの使用のWebLogic Server MTについてを参照してください。 次を選択した場合は、ドメイン・パーティションを構成できません。
|
|
クライアント・アクセス |
Oracle Java Cloud Serviceインスタンスへのアクセスは、デフォルトではHTTPSやSSHなどのセキュア・プロトコルを使用した場合にのみ可能です。 HTTPポートを使用してアプリケーションにアクセスする場合は、サービス・インスタンスの作成後に手動でこのポートを有効化できます。 次の項を参照してください: HTTPポートがデフォルトで無効になるのは、Oracle Java Cloud Serviceコンソールを使用してサービス・インスタンスを作成した場合のみです。 REST APIを使用してサービス・インスタンスを作成する場合、HTTPポートはデフォルトで有効化されています。 |
|
Coherenceデータ層 |
サービス・インスタンス内にOracle Coherenceデータ層をプロビジョニングすると、Oracle Java Cloud Serviceによって、インメモリー・データ・グリッドまたはキャッシュをホストするための2つ目のWebLogic Serverクラスタがドメイン内に作成されます。 このCoherenceクラスタによって、アプリケーションで使用頻度の高いデータに対して信頼性と拡張性の高い高速アクセスを行うことができます。 データ・グリッドの初期キャッシュ容量を構成するには、事前定義された容量単位を選択するか、カスタム容量単位を定義します。 容量単位は、キャッシュのサイズ(GB単位)、クラスタ内のVMの数、およびこれらのVMのコンピューティング形態を制御します。 Oracle Java Cloud Service-Coherenceインスタンスの容量単位についてを参照してください。 サービス・インスタンスの作成後、一度に1つの容量単位を追加することで、キャッシュ容量を増やすことができます。 Oracle Java Cloud ServiceインスタンスのCoherenceデータ層のスケーリングを参照してください。 Oracle Java Cloud Serviceでサービス・インスタンス内にCoherenceデータ層をプロビジョニングできるのは、Enterprise Edition with Coherence (Suite)を選択した場合のみです。 |
|
データベース |
Oracle Java Cloud Serviceには、標準のOracle Infrastructureスキーマを含む既存のリレーショナル・データベースへのアクセスが必要です。 Oracle Java Cloud Serviceは、このデータベースにアクセスするためにJava Database Connectivity(JDBC)を使用します。 Oracle Database Cloud Serviceデータベース・デプロイメントを作成するか、既存のオンプレミスOracleデータベースを使用します。 サービス作成プロセス中、Oracle Java Cloud Serviceは必要なスキーマをOracle Database Cloud Serviceにプロビジョニングします。 他のOracleデータベースを選択する場合は、Oracle Java Cloud Serviceインスタンスを作成する前にこのスキーマを手動で作成する必要があります。 Oracle Database Cloud Serviceの使用のデータベース・デプロイメントの作成に関する項を参照してください。 |
|
ロード・バランサ |
ロード・バランサは、Oracle Traffic Director (OTD)のインスタンスです。 ロード・バランサは、クライアントから受信したリクエストをOracle Java Cloud Serviceインスタンス内で構成されたWebLogic Serverにルーティングします。 複数の管理対象サーバーを構成する場合は、ロード・バランサを使用することをお薦めします。 ロード・バランサには、定期メンテナンスを実施するためにOracle Java Cloud Serviceインスタンスを一時的に中断する機能も用意されています。 2つ目のロード・バランサをサービス・インスタンスのプロビジョニング中に構成することも、サービス・インスタンスのプロビジョニング後にロード・バランサを追加することもできます。 各ロード・バランサには別個のパブリックIPアドレスが割り当てられます。 2つのアクティブなロード・バランサを持つ構成には、次のような利点があります。
ただしこの構成では、クライアントが両方のロード・バランサ・ノードを利用し、一方が使用不能になった場合にもう一方にフェイルオーバーする操作を担当します。 1つ目のロード・バランサをOracle Java Cloud Serviceインスタンスに追加した後で削除することはできません。 無効にすることはできますが、サービス・インスタンス内に保持した期間については課金されます。 次の項を参照してください: |