Oracle Blogs 日本語のまとめ

Oracle Blogsの主としてテクノロジー製品のエントリを日本語でご紹介します（オリジナルのエントリを投稿することもあります）。厳密性をご所望の方は原文をどうぞ。よい内容でしたら原文に対し、"Good Entry, thanks!"でもいいので、是非コメントお願いします（Typoや誤訳はコメント欄からどうぞ）。なお、このエントリは個人の見解であり、所属する会社の公式見解ではありません。また、エントリ内でご紹介している製品・サービスは国内導入時期が未定の場合もありますのでご了承下さい。

Good entries on Oracle Blogs are put into Japanese. Mainly this blog covers technology products. Opinions expressed in this blog is my personal one and does not represent the official opinion of Oracle Corporation and my employer.

[Java] Eager reclamation of Humongous objects with G1

原文はこちら。
https://blogs.oracle.com/poonam/entry/eager_reclamation_of_humongous_objects

JDK 8u40 と8u60 のG1GCで、すばらしい機能拡張がなされました。これらのリリースにアップグレードされた際に驚かれたかもしれません。

領域の半分以上を占めるオブジェクトはHumongousオブジェクトと呼ばれ、Humongoud領域と呼ばれる特殊な領域に格納されることはご存知の通りです。8u40以前は、Humongous領域はEvacuation Pauseで回収されず、マーキングサイクルの最後、もしくはFull GC時にのみ回収されていました。

8u40で、G1GCに対し以下の機能強化が図られました。

JDK-8027959: Early reclamation of large objects in G1
https://bugs.openjdk.java.net/browse/JDK-8027959

この機能強化により、どこからも参照されないHumongousオブジェクトの再利用が可能になりました。以下の2個の実験的なJVMオプションが追加されました。

G1ReclaimDeadHumongousObjectsAtYoungGC
実験的なオプションで、デフォルトで有効。このオプションが有効である場合、G1はyoung GCの都度Dead状態の（死んだ）オブジェクトを再利用する。

G1TraceReclaimDeadHumongousObjectsAtYoungGC
実験的なオプションでデフォルトでは無効。このオプションが有効である場合、G1はyoung GCの際にHumongousオブジェクトのGCに関する情報を出力する。

ただ、上記変更はリグレッションがありました。これは8u60で修正されています。

JDK-8069367: Eagerly reclaimed humongous objects left on mark stack
https://bugs.openjdk.java.net/browse/JDK-8069367

8u60でこの機能拡張が改善され、参照されるオブジェクトを持つ可能性のあるHumongous領域も早期再利用の対象になっています。これらの参照される参照を検査し、これらの参照がストール／死んでいるとG1が認知した場合には、Humongous領域は再利用されます。この作業は、以下の機能拡張リクエストの一環で行われました。

JDK-8048179: Early reclaim of large objects that are referenced by a few objects
https://bugs.openjdk.java.net/browse/JDK-8048179

この変更に伴い、JVMオプションの名称変更がありました。

旧	新
G1ReclaimDeadHumongousObjectsAtYoungGC	G1EagerReclaimHumongousObjects
G1TraceReclaimDeadHumongousObjectsAtYoungGC	G1TraceEagerReclaimHumongousObjects

さらに、新しいJVMオプション（G1EagerReclaimHumongousObjectsWithStaleRefs）が追加されています。

G1EagerReclaimHumongousObjectsWithStaleRefs
実験的なオプションで、デフォルトで有効。このオプションが有効である場合、G1は参照されるオブジェクトを有する可能性のあるHumongousオブジェクトを、young GCの都度再利用しようとする。

[Applications, Cloud] E-Business Suite in the Oracle Cloud

原文はこちら。
https://blogs.oracle.com/pshuff/entry/e_business_suite_in_the

この3日間で、複数のサーバを展開し、クラウドでサービスを隠蔽することで異なるレイヤを保護する方法について説明してきました。

Networking 102
https://blogs.oracle.com/pshuff/entry/networking_102
https://orablogs-jp.blogspot.jp/2016/09/networking-102.html
Networking 102 - part 2
https://blogs.oracle.com/pshuff/entry/networking_102_part_2
https://orablogs-jp.blogspot.jp/2016/09/networking-102-part-2.html
hiding a server in the cloud
https://blogs.oracle.com/pshuff/entry/hiding_a_server_in_the
https://orablogs-jp.blogspot.jp/2016/09/hiding-server-in-cloud.html

今日は、複数のCompute CloudインスタンスにE-Business Suite 12.2.5のインストールプロセス、手順を辿っていくことにします。必要であれば、このインスタンスを開発およびテスト、QA、あるいは本番環境に利用することもできます。EBSのインストール方法はたくさんあることにご注意ください。Oracle Compute Cloud Service（IaaS）にすべてをインストール、つまりLinuxサーバ上にWebLogicとOracle Databaseをインストールすることができますし、データベース・コンポーネントをOracle Database Cloud Service（DBaaS）にインストールし、その他をIaaS上にインストールすることができます。また、データベースをDBaaSに、アプリケーションをOracle Java Cloud Service（JaaS）に、残りをIaaSにインストールすることもできます。現在推奨される展開シナリオは、IaaS上にすべてをデプロイし、お持ちのEBS、データベース、WebLogic Server、そしてIdentity Server用のライセンスを使うことです。
このエントリでは、以下のチュートリアルの手順を辿ることにします。

Provisioning a Multi-Node Oracle E-Business Suite Release 12.2 Installation (with Database 12.1.0.2) to Oracle Compute Cloud Service
http://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/compute-iaas/using_automated_ebs/04multinode.html

最初に、マルチノード・インストールを実施していきます。このためには、他の全てのイメージをブートし、スタンドアロン・インスタンスにするためのプロビジョニング・ツールをインストールする必要があります。また、テストデプロイのためには、500GBのディスクストレージを持つComputeインスタンスが少なくとも4個必要です。個々の要件は下表の通りです。

デプロイメントを開始する前に、Oracle Cloud MarketplaceでEBS起動可能イメージをダウンロードする必要があります。Marketplaceで"e-business"イメージを検索します。

Oracle Cloud Marketplace
http://cloud.oracle.com/marketplace/ja_JP/

必要とするイメージは下表の通りです。

Step 1:

検索結果のページでEBS 12.2.5 Fresh Install DB Tier Imageを選択し、イメージのページで、［アプリケーションの入手］（Get App）をクリックしてダウンロードします。使用条件の画面が現れますので、了解した上でOKをクリックします。条件に同意すると、デプロイ可能なクラウドインスタンスのリストが現れます。サーバーのリストが現れない場合、インスタンスのプリファレンスでMarketpraceのアプリケーションをインスタンスにプロビジョニングすることを許可するチェックボックスにチェックを入れる必要があります。また、起動可能イメージをプロビジョニングするためには、Compute_Adminロールが必要です。ダウンロード後はComputeインスタンスに移動する必要はありません。DB Tier Imageをプライベートイメージにコピーしていきます。

Step 2:

EBS 12.2.5 Demo DB Tier Imageをダウンロードします。残念ながら前画面に戻る機能がないので、再度Marketplaceのページで検索し、Demo DB Tier Imageを選択する必要があります。

Step 3:

EBS 12.2.5 Application Tier Imageをダウンロードします。

Step 4:

EBSイメージ（OSのみ）をダウンロードします。

Step 5:

EBS Provisioning Tools Imageをダウンロードします。

Step 6:

全てのイメージについて準備完了していることを確認します。イメージの準備が完了したことを通知する確認メールを受け取り、新規インスタンスを作成し、プライベート・イメージ領域にイメージを確認することができるはずです。5個のイメージが利用可能で、全てのイメージのための起動可能イメージを作成することができるはずです。

Step 7:

プロビジョニング・ツールを使ってComputeインスタンスを作成します。OC3インスタンスを使い、デフォルト設定で作成していきます。新たなセキュリティ・リストを作成し、HTTPアクセスを許可するようにします。プライベート・イメージのリストから起動イメージを選択する必要があります。

プロビジョニング前にこの設定を確認することができます。

この結果、起動可能ディスクを作成し、インスタンスを起動するOrchestrationが作成されます（少々時間がかかります）。完了すると、全てのプロビジョニング・ツールの実行と、マルチノードEBSインスタンスをデプロイする準備が完了します。

Step 8:

SSHを使ってopcユーザでサーバに接続します。IPアドレスは前のページで取得します。最初の接続施行時にセキュリティリストにデフォルトを追加する必要がありました。そうしない場合、接続がタイムアウトで失敗します。SSHルールを追加すると、想定通りに動作しました。

Step 9:

ユーザーをoracleに切り替えて以下のコマンドを実行します。

knife oc image list

ComputeサービスのComputeエンドポイントを求めるプロンプトが現れます。ComputeダッシュボードでComputeの詳細でRESTエンドポイントをチェックしておく必要がありますが、今回の場合少々変更が必要です。このドメインと2個のゾーンが関連付けられており、z17ゾーンではなくz16ゾーンに接続したいのです。エンドポイント、アイデンティティ・ドメイン、アカウントID、アカウントパスワードを指定して、起動可能なイメージのリストを取得します。リストの一番下に、EBSイメージがあり、これがよさそうです。z17ゾーンを使ってイメージが現れない場合には、z16ゾーンに変更して同じ操作を繰り返すことが重要です。これは、常にインスタンスの最も若い番号のゾーンにイメージをデプロイするというMarketplaceの構成が原因です。

Step 10:

/u01/install/APPS/apps-unlimited-ebs/ProvisionEBS.xml を編集し、アイデンティティ・ドメインとユーザー名をknifeコマンドの出力結果に置き換えます。後続のコマンドは少々スクリーンショットと異なることに注意しておいてください。また、OSイメージを日付を含めるよう変更する必要もありました。そうしなければ、これから実行しようとするPerlスクリプトが失敗します。このファイル名は/Compute-obpm44952/pat.shuff@oracle.com/Oracle-E-Business-Suite-OS-Image-12032015 としていますが、皆様の環境では異なるファイル名になるはずです。

Step 11:

以下のコマンドを実行してインストールを開始します。

perl  /u01/install/APPS/apps-unlimited-ebs/ProvisionEBS.pl

これは、前のセクションで取得したxmlファイルを読み取り、他のインスタンスをインストールするためのメニューシステムを表示します。システムは再度ComputeサーバのREST APIエンドポイント、ストレージのREST APIエンドポイント（ダッシュボードでストレージをクリックして確認してください）、アイデンティティ・ドメイン、アカウント名、パスワードを尋ねます。今回はテストインストールなので、マルチノードの単一アプリケーション・サーバへのインストールのために3を選択しました。その後、Perlスクリプトは、chefをインストールし、cookbookをpullし、データベースやアプリケーション・サーバをインストールして、Computingインスタンスにサーバ・インスタンスを構成します。このステップには少々時間がかかります。インストールされるものを把握するまでは、全てのオプションと構成を試してみることをおすすめします。今回はデモインストール用途で、開発・テスト用途のインストールではないため、単一のアプリケーション・サーバ・ノードと、単一のデータベース・ノードを使いましたが、デモや開発用途で、複数のアプリケーション・サーバ・ノードを使うこともできます。このプロセスでのスクリーンショットの一部は以下の通りです。今回のインストールをprsEBSと呼ぶことにします。prsEBSに対する参照を見かけた場合、このインストールに関連します。プロセスは、Orchestrationをクラウドサービスにデプロイした後、Oracle Cloudでこれらのサービスを開始します。

ComputeコンソールのOrchestrationページで想定通りに動作していることを確認することができます。

完了すると、4個のインスタンスがComputeサービスで動作していることがわかります。

まとめますと、単一のアプリケーションサーバ、単一のE-Business Suiteからなる複数インスタンスをプロビジョニングすることができます。このプロセスは、ドキュメントで説明されており、スクリプトかされています。これらのスクリーンショットや手順が、先述のオンラインチュートリアルを進める上で役に立つことを願っています。次は、データベースを保護し、パブリックインターネットから隠すために、以前話題にしていたセキュリティ原則を適用したいと思います。

[Java] Java EE 8 and 9

来月のJavaOne報告会あたりで詳細の説明があると思いますが、JavaOne会期中のTweetなどでJava EE 8/9についていろいろと誤解を生む表現が散見されたため、少々まとめておきます。
なお、お約束として以下の文言を入れておきます。

このエントリは個人の見解であり、所属する会社の公式見解ではありません。
Opinions expressed in this blog entry is my personal one and does not represent the official opinion of my employer.

Java EE 8およびJava EE 9に関する内容は、Oracleによる提案（Proposal）に過ぎず、正式決定されたものではありません。内容の賛否や改善要望などはどんどんフィードバックしてください（換言すれば、このタイミングを逃すと変更がききません）。締め切りは10月21日（PDT）中です。

Java EE Community Survey
http://glassfish.org/survey

Java EE 8/9のリリース時期について

既報の通り、Java EE 8は2017年中のリリース、Java EE 9は2018年中のリリースを目指しています。

Java EE 8について

基調講演でも話がありましたが、昨年のJava Day Tokyoにも来てくださったLinda DeMichiel さんのセッションでもう少し詳しい話がありました。セッションスライドの27、28枚目に、Java EE 8として提案しているものが記載されています。
このうち、MVC 1.0はまだ仕様として存在しないので、仕様策定しないことを提案しています。JMS 2.1については延期、Managementについては、仕様のアップデートをしないことを提案しています。

Java EE 8 Update [CON7976]（Linda DeMichiel）
https://java.net/downloads/javaee-spec/JavaEE8Update.pdf

当初のJava EE 8で提案していたものから、取り下げを提案しているもの

Management 2.0 (JSR 373)
JMS 2.1 (JSR 368)
MVC 1.0 (JSR 371)

当初のJava EE 8には含まれておらず、新たに追加を提案しているもの

Configuration / Configuration for Java EE 8 and the Cloud [CON7979]

アプリケーション構成を外部化することに関する標準化

Health Checking

クライアント側のヘルスレポートの標準化

その他、技術面で注力する領域として、以下を挙げています（スライドの29枚目）。これらの内容には、Java EE 8で達成したいもの、Java EE 9で達成したいものが混在しています。例えば、セキュリティについてはOAuth 2.0、OpenID Connect対応はJava EE 9での対応を目指すことを提案しています。

プログラミング・モデル

Reactive Programmingのための拡張
統一されたイベントモデル
イベントメッセージングAPI
JAX-RS、HTTP/2、Lambda、JSON-Bなど

パッケージング

アプリケーションやランタイムのサービスへパッケージング
イミュータブルなスタンドアロンの実行バイナリ
マルチアーティファクト・アーカイブ

Key Valueストア、Documentストア

Key-valueおよびDocumentデータベースのための永続化およびクエリAPI

結果整合性（Eventual Consistency）

観察対象のデータ構造に対する変更を自動的に安定化

Serverless

インターフェース、パッケージング形式、マニフェストなどの仕様策定
Ephemeral Instantiation（短時間のインスタンス化）

Configuration / Configuration for Java EE 8 and the Cloud [CON7979]

構成の外部化
構成へのアクセスのための統一されたAPI

Multitenancy

集積度の向上
テナントを認知したルーティングおよびデプロイメント

State

外部化された状態(State)を保存するためのAPI

Resiliency / Portable Cloud ApplicaAons with Java EE [CON8292]

クライアント側でのCircuit Breakerをサポートするための拡張
Resilient（回復）コマンド
システム状態レポートのためのクライアント側のフォーマットの標準化

Security / Security for Java EE 8 and the Cloud [CON7978]

Secret管理
OAuth 2.0サポートの改良
OpenID Connectのサポート

Java EE 9で注力したいと考えている技術領域

Java EE 9でOracleが目指そうと提案している技術的な注力ポイントの概要を説明したセッションがEnterprise Java for the Cloud [CON7975]でした。このほか、上記のPortable Cloud ApplicaAons with Java EE [CON8292]でも類似の内容を説明しています。両スライドと併せてご覧いただくと、Java EE 9で注力したい領域として提案している領域の内容の理解が進むと思います。

Enterprise Java for the Cloud (Rajiv Mordani, Josh Dorr, Dhiraj Mutreja)
https://java.net/downloads/javaee-spec/JavaEE9.pdf

なお、Java EE for the Cloud [BOF7984]ではより突っ込んだ議論がありました。この内容はJavaOne報告会で説明があることでしょう。

参考資料

Adam Bienさんや今年のJava Day Tokyoで登壇されたSebastian DaschnerさんのエントリにもJava EE 8/Java EE 9に関する記述があります。

The Ingredients and Roadmap of Rebooted Java EE 8 and 9
http://www.adam-bien.com/roller/abien/entry/the_ingredients_and_roadmap_of
Thoughts on Java EE 8 roadmap update
https://blog.sebastian-daschner.com/entries/thoughts_on_javaee8_update

[Cloud, Network] hiding a server in the cloud

原文はこちら。
https://blogs.oracle.com/pshuff/entry/hiding_a_server_in_the

先日サーバの保護とインターネットから隠すことについて質問がありました。昨日Webサーバとプライベートネットワークで通信し、インターネットから見えなくすることについて説明しました。質問の核心は、コンソールやシェルへのアクセスを隠し、Oracle Cloudの他インスタンスからのアクセスだけを許可できるか、というものです。
確認するために、セキュリティ・ルールとセキュリティ・リストを定義することでサーバへのインバウンドおよびアウトバウンドポートを構成することができます。ここでは、インターネット、サイト、インスタンス間で通信するためのポートを許可します。セキュリティ・リストの詳細は、以下をご覧ください。

Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)
Managing Security Lists
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-C94EF16D-DD88-46D9-B37E-20C2A3F62E6F.htm#OCSUG144

なお、新たにセキュリティ・リストを定義するためにはCompute_Operationsロールに属している必要があります。あなたは、新しいセキュリティのリストを定義することができるようにCompute_Operationsの役割を持っている必要があります。セキュリティ・リストを使って、着信パケットに対しACKを返さずに無視したり、ACK付きで拒否したりすることができます。推奨構成は、応答せずに無視することです。アウトバウンドポリシーを使うと、ACKなしで無視するか、ACK付きでパケットを拒否することができます。アウトバウンドポリシーは、プログラムに外部環境と通信させたり、インスタンスをロックダウンさせたりすることができます。デフォルトでは、アウトバウンドは全て許可、インバウンドは全て拒否するよう設定されています。
セキュリティ・リストを定義すると、セキュリティ・ルールを使ってリストに例外を作成します。セキュリティ・リストに関する詳細情報は以下をご覧ください。

Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)
Managing Security Rules
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-630622EC-160B-4523-88AD-F7B46463A0BE.htm#OCSUG145

セキュリティ・ルールを管理するためには、Compute_Operationsロールに属している必要があります。ルールに対し、名前を付け、特定のポートで通信を有効または無効を定義します。たとえば、defaultPublicSSHAccessは、インターネットからインスタンスへの22/tcpに対する通信を許可するように設定されています。Linuxインスタンスへコンソールとコマンドラインでのログインを許可するデフォルトのセキュリティリストにこれをマッピングします。本日は新たにセキュリティ・リストを作成することにします。このセキュリティ・リストは、ローカルインスタンスがSSHでの通信を許可し、パブリックアクセスを無効にします。ローカルの22/tcpへのルーティングを作成するセキュリティ・ルールを作成します。アクセスを許可するものです。まずセキュリティ・アプリケーションを選択してポートを定義します。今回の例では、22/tcpに対応するSSHを許可したいと思います。その他にも、送信元、送信先を定義する必要があります。セキュリティ・リストやセキュリティIPリストに接続することもできます。セキュリティIPリストでは、インスタンスやインターネット、サイトを送信元、送信先を定義します。画面左側のセキュリティIPリストタブを使って別のオプションを追加することができます。デフォルト定義を見ると、インスタンスが管理ドメイン（AD）に割り当てられているインスタンスにマッピングされていることがわかります。今回の場合、10.196.96.0/19、10.2.0.0/26、10.196.128.0/19にマッピングされています。その理由は、これら3個のプライベートIPアドレスレンジをADでプロビジョニングすることができるからです。インターネットは0.0.0.0/0にマップされています。サイトは10.110.239.128/26、10.110.239.0/26、10.110.239.192/26にマッピングされています。ネットマスクは、サイトとインスタンス定義の間の重要な違いであることに注意してください。
今日は、（下図のインスタンス1）WebServer1を使って、インターネットからのSSHアクセスを無効にします。また、WebServer2（インスタンス2）からのSSHを有効化し、このコンピュータのコンソールやシェルにアクセスできるようにしたいと思います。我々は、効果的にインターネットからのすべてのアクセスからWebServer1を隠し、WebServer2からこのサーバにプロキシログインのみを許可したいと思います。ネットワークトポロジーは以下のようです。

Step 1:

2日前の構成手順を辿り、ComputeインスタンスではHTTPサーバが動作し、ポートが開いており、ファイアウォールが無効化します。このインスタンスをWebServer1と呼ぶことにします。インターネットからのSSH接続を許可するデフォルトセキュリティ・リストを使います。

Step 2:

WebServer2に対してStep 1を実施します。

Step 3:

まずやることは、新たなセキュリティ・リストを定義することです。このセキュリティ・リストではプライベート・ネットワークでのSSHを許可し、パブリック・ネットワークからのSSHを拒否します。このリストをprivateSSHと呼ぶことにします。

Step 4:

22/tcpのセキュリティ・ルールを定義する必要があります。これは、インスタンスから先ほど作成したprivateSSHセキュリティ・リストへの通信を許可するものです。10.x.x.xネットワーク（パブリックネットワークではありません）の22/tcpを使ったSSHを許可しています。

Step 5:

続いて、WebServer1インスタンスのネットワーク・オプションを更新し、privateSSHセキュリティ・リストアイテムを追加し、デフォルトのセキュリティ・リストを削除する必要があります。この変更を実施する前に、いくつか構成が必要です。まず、SSH鍵をデスクトップから~/opc/.ssh へコピーし、WebServer2がWebServer1へのSSH接続ができるようにします。その後、WebServer2にログイン、さらにWebServer2からWebServer1 へのSSHでのログインテストを実施します。現時点でデスクトップからWebServer1へのSSH接続ができています。これは疎通テストなので、opcユーザーで実施することができます。

Step 6:

セキュリティリストprivateSSHを追加し、デフォルトのセキュリティ・リストを削除します。セキュリティ・リストがWebServer1用に正しく構成されていることを確認します。

Step 7:

WebServer2からWebServer1へのSSH接続が可能であること、デスクトップからWebServer1へのインターネット越しの接続はできないことを確認します。この例では、WebServer1へopcユーザーでデスクトップから接続していますが、Step 6を実行した後に再度接続を試してください。接続に失敗するはずです。

まとめると、2個のWebサーバを用意し一方をパブリックインターネットから隠しました。別のWebサーバからシェルにログインできますが、パブリックインターネットからはログインできません。この例ではWebサーバを使いましたが、それは簡単に試すことができるからです。PeopleSoftやJDE、E-Business Suite、Primaveraのようなより複雑なものでも可能です。SSHアクセス不可にすることと同様に、隠されたサービスと公開されたサービス間でのデータベース通信やアイデンティティの通信のためにより多くのポートを開くことができます。
「パブリックインターネットからのサーバを隠すことができるか？」という問いに対する基本的な答えは、Yesです。セキュリティ・リストやセキュリティ・ルール、セキュリティIPリスト、セキュリティ・アプリケーションを使って簡単にサーバを隠すことができます。必要であれば、これらをOrchestrationやCLIスクリプトで記述することができます。このエントリではComputeコンソールからの実現方法を辿りました。また、Computeコンソールを使って様々なアプリケーションのためにカスタマイズする上で必要な情報を入手するためのドキュメントのリンクを提供しました。

登録: 投稿 (Atom)