勢いづく CGL 2.0 の実装

2005年6月2日、 Open Source Development Lab（OSDL）が 「Carrier Grade Linux（CGL）Requirements Definition」最新版、バージョン3.1をリリースした。

CGL 3.1 は CGL 2.0 および 1.1（業界で幅広く採用された CGL の最初期バージョン）の後継。 本稿執筆時点では、 18社以上のプラットフォームプロバイダが自社製品ラインに CGL をラインアップし、 5種類の Linux ディストリビューションが CGL 2.0実装として登録されている（現在さらに2種類が登録審査中）。 さらに、ますます多くの通信事業者やサービスプロバイダが CGL ベースの通信サービス提供に向け、サーバノードの導入を進めている。

筆者は LinuxPlanet に掲載された前回の記事で通信業界における Linux の現状について書き、 CGL 要件定義書の仕様を論評した。 本稿では、CGL ディストリビューションの概要、導入、 そして今後のいくつかの課題について述べる。

従来の通信/データサービス網は独自プラットフォームをベースに構築され、 可用性、信頼性、パフォーマンス、 そしてサービスレスポンスタイムといったかなり具体的な分野の要件を持たさなければならなかった。

これらの独自システムは特殊なハードウェア、OS、ミドルウェアで構成され、 独自の技術やインタフェースを組み込む場合が多かった。 このような独自システムアーキテクチャは、 ベンダーによる束縛を助長し、 設計の柔軟性や自由度を大きく制限し、 当時も今も保守や拡張にかなりのコストがかかるプラットフォームを生み出している（図1参照）。

これらのサービスプロバイダーや通信事業者らは、 完全な IP 環境でサービスやミッションクリティカルなアプリケーションを提供するプラットフォームで、 通信事業者レベルの特性を維持すると同時に、 コストを削減するという課題を今も抱えている。 今日の彼らは、いくつかの理由から、専門に特化した独自アーキテクチャを捨て、 民生品利用のアプローチや開発手法を採用しなくてはならない立場にある（図2）。 カギを握る主な誘因は3つある。 （続きはこちら）


図1：Carrier Grade の定義

図2：プラットフォームアーキテクチャ--過去のモデル