メインフレーム上の Java

https://stackoverflow.com/questions/505284

21-08-2019
|

質問

私は以下を運営する大企業で働いています。多く JVM を実行する x86 ベースのサーバーの数。

データセンターの利用効率を高めるために、VMWare ESX を使用した実験に成功しました。しかし、これらは依然として処理ユニットごとに大量の電力を消費します。

私は、メインフレームを復活させて、多数の JVM または仮想マシンをホストできるようにすべきだという突飛なアイデアを思いつきました。

誰かこれを試したことがありますか?何か良い費用対効果はあるのでしょうか？

柔軟性が失われますか？例えば。会社の他の部門にもメインフレームがありますが、マシンの使用法がはるかに厳密であるようです。多くの変更管理、長いリードタイムなど

解決

ここではすべて、Z/OS 上の Java について話しているのではなく、マシンの数が減ることによるコスト削減を利用するためにメインフレーム上で Linux VM を実行しているのではないと仮定しています。

仮想化に関する私の考えはこの記事の最後にあり、おそらく皆さんが検討したいルートだと思いますが、メインフレームは伝統的に関連付けられており、私もよく知っているものであるため、Z/OS から始めます。私はメインフレーム Java の経験があります。

簡単に言うと、それは状況によりますが、おそらくそうではありません。あなたのアプリケーションは具体的に何ですか?メインフレームはx86サーバーに比べて厳しい環境です。Websphere などで I/O 集中型のワークロードを実行している場合、メインフレームが十分に活用されていないと仮定すると、それだけの価値があるかもしれません。

私の経験では、Java はメインフレーム上では恐ろしく遅いですが、それは私が使用したシステムがパフォーマンスではなく開発者の柔軟性を重視して設定されていたためです。これは、メインフレームでは汎用の x86 サーバーよりも多くのワークロードを実行するため、メインフレームでのパフォーマンスチューニングが通常、平均的なサーバーよりもはるかに複雑であることを証明しています。

メインフレームは主に I/O スループットを目的として設計されており、その点では通常の x86 サーバーよりも優れたパフォーマンスを発揮できることに注意してください。大量の計算負荷の高い計算を行うように設計されていないため、大量の計算を行う場合は、x86 サーバーの小規模クラスターを上回るパフォーマンスは得られません。

メインフレームの変更管理には正当な理由があります。1 つの x86 サーバーに問題がある場合は、それを再起動します。メインフレームに問題が発生すると、メインフレームがダウンするたびに企業に損失が発生します。また、アプリが依存するネイティブコードや、ネイティブコードを使用する可能性のあるサードパーティライブラリも考慮する必要があります。そのコードはすべて移植する必要があります。

メインフレームの構成には、x86 サーバーよりも平均ではるかに長い時間がかかります。これを真剣に検討したい場合は、現在のビジネスアプリとの緊密な統合など、省電力よりも優れたビジネスケースを作成し、概念実証または新しいアプリケーションで小規模から始めることをお勧めします。ビジネスクリティカルではなく、メインフレームの強みを活用するために実装できるもの。

IBM メインフレームは、ネイティブモードまたは VMWare と同様の仮想化環境で Linux を実行することもできます。あなたの会社が例外でない限り、Linux インスタンスは仮想マシンとして実行されます。これについてはあまり経験がありませんが、アプリがネイティブコードに依存せず、Linux 上で実行される場合、おそらく Linux を実行するメインフレーム上で動作するでしょう。メインフレーム上の Linux の詳細については、次を参照してください。このリンク.

他のヒント

IBM は特別な Java コプロセッサーを開発しているので、真剣に検討する必要があります。ライセンスされたソフトウェアの MPU 料金が高くなる可能性があるため、一般的なエンジンでは Java を実行しません。

当社には、Windows、Linux、および IBM SystemI (または、その年の IBM の気分に応じて iSeries、または AS/400) ミニコンピューター上で Java を実行した豊富な経験があります。私の意見では、ミニコンピュータープラットフォームは、最新のマルチコア x86 CPU に比べてはるかに見返りが少ないように思えます。

Java は本質的にマルチスレッドの性質を持っているため、今日の一般的なソフトウェアよりも複数のコアを利用できることから恩恵を受けやすいことに注意してください。これは、複数の JVM を実行する場合にはさらに当てはまります。

とはいえ、通常は、ミニフレームまたはメインフレーム上のメモリにアクセスするための帯域幅が向上し、ディスクサブシステム (全体) のスループットが向上するため、より多くの CPU コアを利用できるようになり、より多くの JVM を使用することで、これらのシステムの拡張性が向上する可能性があります。それらの上に。

IBM はこれを許可します。メインフレームの一部には、パフォーマンスを向上させるためにバイトコードをネイティブに実行する Java アクセラレータプロセッサを搭載できます。また、DB2 アクセラレータも備えており、XML 操作用のアクセラレータも備えている可能性があります。

私は彼らの誰ともプレイしたことがありませんが、ぜひプレイしてみたいです。

私は 1975 年からこの業界にいますが、「メインフレーム」が何なのかはもうわかりません。私の現在の開発マシンには 4 つの 3GHZ プロセッサ、8 GB の RAM、750 GB のディスク容量 (RAID 1 なので実際にはその 2 倍)、および 2 つの 19 インチフラットスクリーンモニターが搭載されています。

それは私が契約でそこにいるからです。従業員は全員、私よりもはるかに強力なボックスを持っています。

サーバーマシン、特にデータベースサーバーがはるかに高速であることは理解しています。

メインフレーム？

ワークロードに応じて、検討する価値があります。

IBM ハードウェアを使用するだけで、驚くほど多くのオプションが利用可能になります。

Java プロセッサのアドオンを検討する価値は間違いなくあります。（これらは実際には標準のCPUとは異なる形ではありません。それはJava JVMワークロードに限定されているだけです。最も重要なことは、CPUベースのソフトウェアライセンス価格から除外されます）。
複数の Linux VM を実行して、それぞれ独自の Java アプリを実行できます。
DOSと呼ばれるように使用されるミニマリストオペレーティングシステムを実行する複数のネイティブVMを実行できますが、数年ごとに名前を変更します。ソフトウェアライセンスはメインOSよりも安価ですが、機能が非常に限られているため、セルフコンテッドアプリケーションを実行している場合に有利になります。
Monster z/OS 環境では、次のいずれかを実行できます。

ａ．USS（UNIX System Services）は、親z/OS内で実行されている完全なUNIX OSです。

b.Java アプリを独自の開始タスク (== unix デーモン) で実行します。

c.CICS 内でアプリを実行します。（おそらく、CICS/Java APIを使用する必要があるためではないので、通常はServlet/J2EE APIを使用して、アプリが書き直される必要があります。）

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow