私は、 JVM を実行する x86 ベースのサーバーを多数実行する大企業で働いています。
VMWare ESX の実験に成功し、データ センターをより有効に活用することができました。しかし、これらは依然として処理ユニットごとに多くの電力を消費します。
私は、メインフレームを復活させ、多数の JVM または仮想マシンのいずれかをホストできるようにするべきだと思いました。
誰もこれを試しましたか？良い費用対効果はありますか？
柔軟性を失いますか？たとえば、社内の別の場所にメインフレームがありますが、マシンの使用方法がかなり厳格なようです。多くの変更管理、長いリード タイムなどがあります。
IBM は、真剣に検討すべき特別な Java コプロセッサーを作成しています。ライセンスされたソフトウェアの MPU 料金が増加する可能性があるため、一般的なエンジンでは Java を実行しません。
私たちは、Windows、Linux、およびIBM SystemI（または、その年のIBMの気分に応じてiSeries、またはAS / 400）ミニコンピューターでJavaを実行した豊富な経験があります。私の意見では、ミニコンピュータープラットフォームは、最新のマルチコアx86 CPUに比べて、はるかに少ない価値しか提供していないようです。
Javaは本質的にマルチスレッドの性質があるため、今日の一般的なソフトウェアよりも複数のコアを利用できることで、より簡単にメリットが得られることに注意してください。これは、複数のJVMを実行する場合にさらに当てはまります。
とは言うものの、通常、ミニフレームまたはメインフレームのメモリにアクセスするためのより良い帯域幅と、ディスクサブシステム（全体）のより良いスループットで、より多くのCPUコアを利用できるようになるため、これらのシステムは、より多くの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プロセッサの追加を検討する価値は間違いありません。（これらは実際には標準のCPUとそれほど違いはなく、Java jvmワークロードに制限されています-そして-最も重要なのは、CPUベースのソフトウェアライセンスの価格設定から除外されていることです）。
複数のLinuxVMを実行して、それぞれが独自のJavaアプリを実行できます。
以前はDOSと呼ばれていた最小限のオペレーティングシステムを実行している複数のネイティブVMを実行できますが、名前は2、3年ごとに変更されます。ソフトウェアライセンスはメインOSよりも安価ですが、機能が非常に限られているため、自己完結型のアプリケーションを実行している場合に有利であることがわかります。
モンスターz/OS環境では、次のいずれかで実行できます。-
a。親z/OS内で実行されているほぼ完全なUNIXOSであるUSS（Unix System Services）内。
b。独自の開始タスク（== unixデーモン）でJavaアプリを実行します。
c。CICS内でアプリを実行します。（おそらく、通常はServlet /J2EEAPIを使用するCICS/Java APIを使用する必要があるため、アプリを書き直す必要があるためではありません。）
IBM はこれを許可します。一部のメインフレームは、バイトコードをネイティブで実行する Java アクセラレータ プロセッサを搭載してパフォーマンスを向上させることができます。また、DB2 アクセラレーターもあり、場合によっては XML 操作用のものもあります。
私はそれらのどれとも遊んだことがありませんが、きっと喜んでいます。
私は 1975 年からこの業界に携わっていますが、もはや「メインフレーム」が何であるかはわかりません。私の現在の開発用マシンには、4 つの 3GHZ プロセッサ、8GB の RAM、750GB のディスク領域 (RAID 1 なので、実際にはその 2 倍)、および 2 つの 19 インチ フラットスクリーン モニターが搭載されています。
それは私が契約でそこにいるからです。従業員は全員、私よりもはるかに強力なボックスを持っています。
サーバー マシン、特にデータベース サーバーがはるかに高速であることは理解しています。
メインフレーム?