gLite(ジーライトと発音)は、CERN LHC実験やその他の科学分野で使用されるグリッドコンピューティング向けのミドルウェアソフトウェアプロジェクトです。ヨーロッパの12の異なる学術研究機関および産業研究機関に所属する80名以上の研究者の協力によって開発されました。gLiteは、インターネット上の分散コンピューティングおよびストレージリソースを活用するアプリケーションを構築するためのフレームワークを提供します。gLiteサービスは250以上のコンピューティングセンターに採用され、ヨーロッパおよび世界中の15,000名以上の研究者によって利用されています。
2004年と2005年のプロトタイプ開発段階を経て、 2006年5月にgLite 3.0がリリースされ、 LHCコンピューティンググリッド(LCG-2)ディストリビューションとの統合が達成されました。そして、2010年に終了したEnabling Grids for E-sciencE (EGEE)プロジェクトの公式ミドルウェアとなりました。
その後、gLiteミドルウェアの開発は欧州ミドルウェアイニシアチブ( EMI)に引き継がれ、現在はEMIソフトウェアスタックの一部として維持管理されている。
EGEEが構築した分散コンピューティングインフラストラクチャは、現在、欧州グリッドインフラストラクチャによってサポートされています。これは、「欧州ミドルウェアイニシアチブ」によって開発されたグリッドミドルウェアを実行しており、その多くのコンポーネントはgLiteミドルウェアから派生したものです。
gLiteユーザーコミュニティは仮想組織(VO)にグループ化されています。[ 1 ]ユーザーは、グリッドリソースを使用するための認証と認可を受けるために、gLiteを実行しているインフラストラクチャによってサポートされているVOに参加する必要があります。
WLCG /EGEEのグリッドセキュリティインフラストラクチャ (GSI) は、オープンネットワーク上で安全な認証と通信を可能にします。[ 2 ] GSI は、公開鍵暗号化、 X.509証明書、およびセキュアソケットレイヤー(SSL) 通信プロトコルに基づいており、シングルサインオンと委任のための拡張機能があります。
ユーザーが自身を認証するには、ミドルウェアを実行するインフラストラクチャによって信頼されている認証局(CA)によって発行されたデジタルX.509証明書が必要です。
特定のグリッドリソースに対するユーザーの認証は、2つの異なる方法で行うことができます。1つ目はよりシンプルな方法で、グリッドマップファイルメカニズムを利用します。2つ目は、仮想組織メンバーシップサービス(VOMS)とLCAS/LCMAPSメカニズムを利用する方法で、ユーザー権限をより詳細に定義できます。
gLite Gridへのアクセスポイントはユーザーインターフェース(UI)です。これは、ユーザーが個人アカウントを持ち、ユーザー証明書がインストールされているマシンであればどれでも構いません。UIから、ユーザーは認証を受けてWLCG/EGEEリソースの使用を許可され、情報管理システム、ワークロード管理システム、データ管理システムが提供する機能にアクセスできます。また、基本的なグリッド操作を実行するためのCLIツールも提供されます。
グリッド用語におけるコンピューティング要素(CE)とは、サイト(つまり、クラスター、コンピューティングファーム)に配置されたコンピューティングリソースの集合体を指します。CEは、クラスターへの汎用インターフェースとして機能するグリッドゲート(GG)、ローカルリソース管理システム(LRMS)(バッチシステムと呼ばれることもあります)、そしてジョブが実行されるノードであるワーカーノード(WN)の集合体であるクラスター自体で構成されます。
gLite 3.1には、2種類のCE実装があります。1つはEDGが開発し、LCG-22で使用されているLCG CE、もう1つはEGEEが開発したgLite CEです。サイトはどちらをインストールするかを選択でき、両方のタイプを提供しているサイトもあります。GGはジョブを受け付け、LRMSを介してWN上で実行するようディスパッチする役割を担います。
gLite 3.1 でサポートされていた LRMS タイプは、 OpenPBS / PBSPro、Platform LSF、Maui/Torque、BQS およびCondor、Sun Grid Engineでした。[ 3 ]
ストレージエレメント(SE)は、データストレージリソースへの均一なアクセスを提供します。ストレージエレメントは、シンプルなディスクサーバー、大規模なディスクアレイ、またはテープベースのマスストレージシステム(MSS)を制御することができます。ほとんどのWLCG/EGEEサイトには、少なくとも1つのSEが設置されています。
ストレージエレメントは、さまざまなデータアクセスプロトコルとインターフェースをサポートできます。簡単に言うと、GSIFTP(GSIセキュアFTP)はファイル全体の転送に使用されるプロトコルであり、ローカルおよびリモートのファイルアクセスはRFIOまたはgsidcapを使用して行われます。
ほとんどのストレージリソースは、ストレージリソースマネージャ(SRM)によって管理されます。SRMは、ディスクからテープへの透過的なファイル移行、ファイルの固定、領域予約などの機能を提供するミドルウェアサービスです。ただし、異なるSE(システム環境)は異なるバージョンのSRMプロトコルをサポートする場合があり、その機能も異なる場合があります。
現在、さまざまな機能を備えた複数のSRM実装が利用されています。ディスクプールマネージャ(DPM)は、ディスクベースのストレージのみを備えた比較的小規模なSEで使用されています。一方、CASTORは、フロントエンドにディスク、バックエンドにテープストレージを備えた大規模なMSSを管理するように設計されています。dCacheは、MSSと大規模ディスクアレイストレージシステムの両方を対象としています。その他のSRM実装も開発中で、SRMプロトコル仕様自体も進化を続けています。
SRMインターフェースを持たない従来のSEは、シンプルなディスクベースのストレージモデルを提供する。これらは段階的に廃止されつつある。
情報サービス(IS)は、WLCG/EGEEグリッドのリソースとその状態に関する情報を提供します。リソースの発見はISを介して行われるため、この情報はグリッド全体の運用に不可欠です。公開された情報は、監視および会計目的にも使用されます。
ISに公開されるデータの多くはGLUEスキーマ[ 4 ]に準拠しており、これはグリッドリソースの監視と発見に使用される共通の概念データモデルを定義しています。
gLite 3.1 で使用される情報システムは、Globus Monitoring and Discovery Service (MDS) から主要な概念を継承しています。[ 5 ]ただし、MDS の GRIS と GIIS は、基本的に外部プロセスによって更新されるOpenLDAPサーバーであるBerkeley Database Information Index (BDII)に置き換えられています。
ワークロード管理システム(WMS) [ 6 ]の目的は、ユーザーのジョブを受け付け、最も適切なコンピューティング要素に割り当て、そのステータスを記録し、出力を取得することです。リソースブローカー(RB)は、WMSサービスが実行されるマシンです。
投入されるジョブは、ジョブ記述言語(JDL)を使用して記述されます。JDLでは、例えば、実行する実行可能ファイルとそのパラメータ、ジョブが実行されるワーカーノードとの間で移動するファイル、必要な入力グリッドファイル、CEおよびワーカーノードに対する要件などが指定されます。
ジョブの送信先となるCEの選択は、マッチメイキングと呼ばれるプロセスで行われます。このプロセスでは、まず利用可能なすべてのCEの中から、ユーザーが指定した要件を満たし、かつ指定された入力グリッドファイルに近いCEを選択します。次に、CEの状態情報から得られるランクが最も高いCEを選択します。このランクは、 CEの性能(通常は実行中のジョブ数とキューに入っているジョブ数の関数)を表します。
リソースブローカー(RB)は、ジョブ記述で指定されたグリッド入力ファイルを、データロケーションインターフェース(DLI)と呼ばれるサービスを使用して検索します。DLIは、ファイルカタログへの汎用インターフェースを提供します。このようにして、リソースブローカーは、LFC以外のファイルカタログ(DLIインターフェースを備えている場合)とも通信できます。
EGEEの最新のWMS実装では、単一のジョブの送信だけでなく、ジョブの集合(ジョブ間に依存関係がある場合も含む)の送信も、旧型のLCG-2 WMSよりもはるかに効率的に行うことができ、その他にも多くの新機能が搭載されています。
最後に、ログ記録および簿記サービス(LB)[ 7 ]は、WMSによって管理されるジョブを追跡します。多くのWMSコンポーネントからイベントを収集し、ジョブの状態と履歴を記録します。