クアトール

Quattor は、コンピュータのインストール、構成、管理に使用される汎用オープン ソース ツールキットです。Quattor は、もともと European Data Grid プロジェクト (2001 ～ 2004) のフレームワークで開発されました。2003 年の最初のリリース以来、Quattor は、主にグリッド システム管理者のコミュニティのユーザーと開発者のボランティア コミュニティによって維持および拡張されてきました。他の構成管理システムと同様に、Quattor ツールキットは、クラスターの維持に必要なスタッフを削減し、信頼性の高い変更管理を容易にします。ただし、3 つの独自の機能により、グリッドリソースの管理に特に魅力的です。

• フェデレーション管理: ツールキットのオープンでモジュール化された性質により、異なる機関のシステム管理者が分散リソースの管理を共有できます。
• 共有構成と管理の効率: Quattor は、構成情報をほとんどまたはまったく変更せずにさまざまなサイトに配布して使用できるように構成情報の再利用を推奨します。これにより、各サイトで構成変更を実装する必要なくベスト プラクティスの配布が容易になります。
• 一貫したサイト モデル: Quattor を使用すると、管理者はサイト モデルを開発できます。サイト モデルを構築すると、実際のマシン、仮想マシン、クラウド リソースなど、さまざまなリソースの管理に使用できます。

^{これらの機能は、グリッドのコンテキストを超えて魅力的です。これは、大規模な商業組織[1]}と学術機関の両方でQuattorの採用が増えていることからも確認されており、そのほとんどはツールキットを使用してグリッドシステムと非グリッドシステムを一貫して管理しています。

コラボレーション システムでコンポーネントを構造化して共有するという課題は新しいものではありません。長年にわたり、プログラミング言語の設計者はさまざまな角度からこの問題に取り組んできました。トレンドは変化しますが、基本原則はよく理解されています。カプセル化、抽象化、モジュール化、型付けなどの機能は、明確な利点を生み出します。管理ドメイン間で構成情報を共有する場合にも、同様の原則が当てはまると考えています。

Quattor 構成ツールキットはLCFGからアーキテクチャを派生し、いくつかの側面でそれを改善しています。Quattor の中核は Pan です。これは、柔軟なインクルード メカニズム、さまざまなデータ構造、および現代のプログラマーに馴染みのある検証機能を備えた高レベルの型付き言語です。Pan を使用すると、管理者は共同でサービス タイプ、ハードウェア コンポーネント、構成パラメーター、ユーザーなどを記述する複雑な構成テンプレートのセットを作成できます。高レベル言語を使用すると、構成スニペットのカット アンド ペーストを超えた方法でコードの再利用が容易になります。

Quattor に具体化された原則は、システム管理コミュニティ内で確立された原則と一致しています。特に、管理対象ノードはすべて、ソース コントロール システム (分散管理の場合は複数のシステム) によってサポートされる構成サーバーから構成を取得します。これにより、ハードウェア障害が発生した場合でも個々のノードを再作成できます。Quattor は、分散インフラストラクチャと従来の (単一サイト) インフラストラクチャの両方を処理します。

分散管理には、マルチサイト インフラストラクチャの一貫性、複数の管理ポイント、構成サイトの特定のニーズに対応する機能など、さまざまな機能があります。分散インフラストラクチャには単一の「正しい」モデルは存在しないため、構成システム自体のアーキテクチャには高い柔軟性が必要です。高度に自律的なサイトのセットが緩やかに連携する必要がある場合があります。この場合、各サイトはかなり包括的な構成サーバーのセットをホストし、共通の構成情報は共有データベースから取得され、ローカル構成と統合されます。

管理タスクを分散すると、新たなコストが発生する可能性があります。たとえば、WAN 経由で構成情報を送信すると、遅延やセキュリティ上の懸念が生じます。Quattor を使用すると、インフラストラクチャ内の適切な場所にサーバーを配置して遅延を短縮できます。また、標準ツールとプロトコルを使用することで、既存のセキュリティ システム (公開鍵インフラストラクチャなど) を利用して通信を暗号化および認証できます。

Quattor の構成管理システムは、高レベルの構成テンプレートを保存する構成データベース、テンプレートを検証して XML または JSON プロファイルに変換する Pan コンパイラ、およびクライアント ノードにプロファイルを提供するマシン プロファイル リポジトリで構成されています。Quattor システムでは Pan コンパイラのみが厳密に必要であり、他の 2 つのサブシステムは、同様の機能を提供する任意のサービスに置き換えることができます。

クロスドメイン環境での分散管理では、ユーザーを認証し、その操作を承認する必要があります。構成データベースでは、多くの標準ツールでサポートされているため X.509 証明書を使用できます。また、きめ細かな制御が可能なためアクセス制御リスト (ACL) も使用できます (ACL は各テンプレートに添付できます)。多くのユーザーがシステムとやり取りすると、競合や構成ミスが発生し、ロールバック メカニズムが必要になる場合があります。この目的のために、標準バージョン コントロール システムに基づく単純な同時トランザクション メカニズムが実装されました。

Quattor のモジュール アーキテクチャにより、3 つの構成管理サブシステムを分散型または集中型のいずれの形式でも展開できます。分散型アプローチでは、プロファイルのコンパイル (開発段階) がクライアント システムで実行され、テンプレートが適切なデータベースにチェックインされ、最後にサーバー上で別の操作を呼び出して展開が開始されます。集中型アプローチでは、構成データを厳密に制御できます。コンパイルの負荷は中央サーバーにかかり、ユーザーは専用のインターフェイスを介してのみテンプレートにアクセスして変更できます。

2 つのパラダイムは基本的に同じ機能を提供するため、どちらを選択するかは組織の管理モデルにどちらがより適しているかによって決まります。たとえば、集中型アプローチはワークフローが厳密に制御されるため大規模なコンピュータ センターに適していますが、GRIF などの複数サイト組織では、構成セット全体のさまざまな部分を自律的に処理できるため分散型アプローチが好まれます。

Pan 言語コンパイラ panc は、Quattor ツールキットの中核にあります。システム管理者がPan 構成言語で記述したマシン構成をコンパイルし、Quattor クライアントが簡単に使用できる XML または JSON ファイル (プロファイル) を生成します。Pan 言語自体は、構成情報と関連スキーマを同時に定義できる、シンプルな宣言型構文を持っています。このセクションでは、分散サイトの分散管理に関連する Pan 機能 (検証、構成の再利用、モジュール化) のみに焦点を当てます。

検証。 Pan 言語の広範な検証機能により、コンパイル時に構成の問題が見つかる可能性が最大限に高まり、展開された誤った構成のコストのかかるクリーンアップが最小限に抑えられます。 Pan を使用すると、システム管理者は、関連する検証関数を使用してアトミック型または複合型を定義できます。構成スキーマの一部が型にバインドされると、宣言された制約が自動的に適用されます。

構成の再利用。Pan では、「構造テンプレート」を通じて構成情報を識別し、再利用できます。これらは、管理者が不変 (またはほぼ不変) の構成サブツリーを識別するたびに使用できる、Pan レベルの構成情報の小さな再利用可能なチャンクを識別します。

モジュール化。元の設計に関して、モジュール化と構成の大規模な再利用を促進するために、名前空間メカニズムとロードパス メカニズムという 2 つの新しい機能が開発されました。

完全なサイト構成は、通常、ディレクトリとサブディレクトリに整理された多数のテンプレートで構成されます。Pan テンプレートの名前空間は、Java 言語で行われるのとほぼ同じように、この構成を模倣 (および強制) します。名前空間階層は、構成スキーマとは独立しています。構成スキーマは、ポートのファイアウォール設定、アカウント生成、ログ ローテーション エントリ、cronエントリなどの低レベル サービスによって整理されることがよくあります。対照的に、Pan テンプレートは通常、高レベル サービス (Web サーバー、メール サーバーなど) や責任者/グループなどの他の基準に基づいて整理されます。

名前空間により、構成のさまざまな部分を分離して識別できます。構成の一部を効果的にモジュール化して再利用するには、管理者がモジュールをサイトの構成に簡単にインポートしてカスタマイズできる必要があります。Pan コンパイラのユーザーは、ロード パスと名前空間を組み合わせてこれを実現します。コンパイラはロード パスを使用して、複数のルート ディレクトリで特定の名前付きテンプレートを検索します。ロード パスで最初に見つかったバージョンがコンパイラによって使用されます。これにより、モジュールを元の状態に保ちながら、サイトが特定のテンプレートをオーバーライドできるようになります。

さらに、モジュール開発者はグローバル変数を公開してモジュールをパラメータ化することもできるため、システム管理者はモジュールのテンプレートの内部動作を理解していなくてもモジュールを使用できます。

Quattor ワーキング グループ (QWG) テンプレートは、グリッドミドルウェアサービスを構成するために使用されます。QWG テンプレートは Pan のすべての機能を使用して、分散サイトでグリッドミドルウェアの専門知識を共有できるようにします。

大規模な分散インフラストラクチャを管理するための重要な機能は、マシンをリモート ロケーションから自動的にインストールできることです。この目的のために、Quattor は自動インストール インフラストラクチャ (AII) と呼ばれるモジュール フレームワークを提供しています。このフレームワークは、ノード プロファイルに組み込まれた構成パラメータを、標準インストール ツールで使用できるインストール手順に変換する役割を担っています。現在の AII モジュールは、ノード プロファイルを使用して、DHCP サーバー、PXE ブート、および Kickstart ガイド付きインストールを構成します。

通常、AII は各サイトにインストール サーバーを設置してセットアップされます。ただし、上記のテクノロジにより、標準プロトコルを使用して中央サーバーと適切なリレーをセットアップすることで、複数サイトへのインストールを透過的に実装できます。

Quattor では、管理対象ノードが構成プロセスを自律的に処理します。リポジトリから構成プロファイルが取得されると、すべてのアクションがローカルで開始されます。各ノードには、構成スキーマの特定の部分にそれぞれ登録されている構成エージェント (コンポーネント) のセットがあります。たとえば、ユーザー アカウントを管理するコンポーネントは、パス /software/components/accounts に登録されます。ノードで実行されるディスパッチャ プログラムは、新しく取得した構成を分析して関連セクションの変更を検出し、適切なコンポーネントをトリガーします。実行時の依存関係はノードのプロファイルで表現できるため、コンポーネントの実行時に部分的な順序を適用できます。たとえば、ファイル所有権を正しく指定できるようにするには、ファイル作成コンポーネントの前にユーザー アカウント コンポーネントを実行することが重要です。

設計上、構成コンポーネントの正しい実行を保証するための制御ループは提供されていません。サイト管理者は通常、標準の監視システムを使用して構成の失敗を検出し、対応します。Quattorサイトでは、この目的のためにNagiosと Lemon の両方が使用されています。実際、Lemon は Quattor と連携して開発されており、Quattor コンポーネントの実行の失敗を検出するセンサーを提供します。

通常、ノードは自動的に更新されますが、管理者はシステムを設定して自動変更展開を無効にすることができます。これは、構成の変更と展開の責任がそれぞれ分離される可能性がある分散システムでは重要です。一般的なシナリオは、トップレベルの管理者が複数のリモート サイトの共有構成を管理し、ローカル マネージャーがポリシーに従ってそれを適用することです。たとえば、ソフトウェア更新は異なる時間にスケジュールされる場合があります。

• オープンソース構成管理ソフトウェアの比較

• Quattorホームページ
• Quattor のケーススタディ
• StratusLab プロジェクト
• クアトール・オン・オーロ
• LISA 08 論文
• グリッドコンピューティングジャーナル論文
• パン言語に関するドキュメント