Red Hat Enterprise Linux（RHEL）にメッセージ処理機能、リアルタイム機能、グリッド管理機能を追加したLinuxディストリビューション。
MRGは「統合」を意味する「merge」（マージ）と同じ発音で、Messaging、Realtime、Gridの頭文字を取ったもの。それぞれの機能は互いに直接には関係しない。リアルタイムOSの機能を提供するためにカーネルに変更が加えられているが、RHEL向けアプリケーションは、変更なしにそのままEnterprise MRGでも動作するという。
●OSSのメッセージングサーバを標準搭載
Enterprise MRGはメッセージ処理機能としてAMQP（Advanced Messaging Queuing Protocol）対応のモジュールとしてApache Qpidを含む。AMQPはオープンソースのプロジェクトで開発されたメッセージ処理プロトコル。既存のJMS、SOAP、WS-Security、WS-Transactionsなどと合わせて使うことができるほか、開発言語としてJava、C/C++、Python、C#が、またOSとしてLinux、Windows、Z/OSなどが利用できる。
AMQPは、もともとJPモルガン・チェースが自社開発を進めていた金融サービス向けメッセージ処理ソフトウェアのプロトコルと実装を2年前にオープンソースプロジェクトとして公開したものがベースになっている。同プロジェクトにはクレディ・スイス、ゴールドマン・サックス、シスコ・システムズ、GE、シェルなどが参加して開発を進めてきた。オープンソースモデルで提供することで、マイクロソフトやIBMのプロプライエタリなメッセージングサーバに対抗する。
●メインストリームカーネルに統合されたリアルタイム機能
応答時間を一定内に収めることを保証するリアルタイムOSの機能は、すでにLinuxのカーネルツリーに統合されているもので、カーネルに対する拡張機能やアドオンとして提供するものではない。RHELと比べたとき、カーネル自体は完全な置き換えとなるが、Enterprise MRGではライブラリやコンパイラのバージョンをRHELと統一することでアプリケーションレベルでの互換性を確保しているという。
●CPUの空き時間を活用するグリッド機能
「MRG Grid」はウィスコンシン大学マジソン校で20年前に開始したプロジェクト「コンドル」（Condor）をエンタープライズ向けに安定化させたもの。HPCでクラスタリングを構成できるほか、企業などの組織内で利用しているデスクトップワークステーションの空きCPU時間を活用する「HTC」（High Throughput Computing）の環境を実現する。
ノードとしてLAN内やインターネット上のPC、またはAmazon EC2上などの仮想サーバが利用できる。ノードとなるPCには専用のクライアントをインストールする。このクライアントは、キーボードやマウスの動き、CPU処理の負荷などをモニターしており、直接のPC利用者の作業の妨げとならないようにして、CPUの空き時間を割り振られたジョブの実行に費やす。
ウィスコンシン大学のコンピュータサイエンス学科では、15年前からコンドルを実際に導入してしている。現在同校の約1200台のワークステーションをコンドルで管理しており、研究者らが活用している。CPUの稼働率は高く、1200台構成のグリッドで平均的に1日当たり700CPU・日の計算リソースがグリッドのノードとして利用されているという。
基調講演で同社は、MRG Gridを使ってグラフィックスのレンダリングが高速化できることを示すデモンストレーション映像を公開した。具体的には、Amazon EC2上に15CPU分のEnterprise MRGのインスタンスを生成し、Webベースの管理ツールを使ってジョブを分散。1CPUで13分かかる処理を、これらのノードに分散することで4分で処理が終了した。
MRG Gridでは起動中の仮想OSのインスタンスをジョブとしてノードに移す機能も持つ。また、処理中のジョブが何らかの理由で中断された場合には、再び別のノードへジョブを割り振る高可用性もあるほか、ジョブのスケジュール実行、優先度管理などができる。
MRG GridのジョブはJavaで記述できるほか、スーパーコンピュータやクラスタで従来利用されてきたMPICH1/2/LAMといった並列処理のフレームワークをサポートする。このほか、共有ストレージが利用できないケースでもジョブの実行に必要なデータをジョブ管理サーバとノード間で受け渡す機能や、グリッド上で共通して利用できるデータベース機能などを提供する。
現在のところ、MRG Gridの機能はEnterprise MRGが持つメッセージング処理やリアルタイム機能と直接関係しないが、将来的にはメッセージベースのジョブ投入や、リアルタイムスケジューリングと組み合わせたQoS保証などの提供が可能だとしている。