CGL:採用と導入――1本物であることが証明されて勢いづく CGL
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つある。 その結果、独自のレガシーシステムは、 生き残れる実用的なアプローチではもはやなくなってしまった。 これらは購入、保守、拡張のいずれにもかなりのコストがかかる。 その結果、業界は独自の専用システムを捨て、 業界で確立された標準や共通の手法をベースにしたオープンプラットフォームへと移行しつつある。 図2は、専用アーキテクチャを捨てて民生品利用の手法や基盤部品に移行していく業界の最初のステップを示している。この図は、ネットワークの構成部品が独自のコンポーネントを使って設計および構築されたものから、標準化され、入手の容易なハードウェアと Carrier Grade Linux を採用したものへと移行しつつあるトレンドを示している。 さらに今後は(図3)、 標準ベースのハードウェア管理、標準ベースのミドルウェアとインターフェイス、 そして標準化されたプロトコルが導入されるようになる。 その結果、業界標準の早期採用、 革新の促進、そして低価格化の保証を促進するプラットフォームを実現するアプリケーションが登場してくる。 図4はテレコム用プラットフォームの例を示している。 これは、複数のネットワーク部品で構成された1つのサブラックとなっている。 各ネットワーク構成部品が異なるタイプのアプリケーションを運用している。 そして、どのネットワーク構成部品も、 標準化された基盤部品と民生品利用のハードウェアおよびソフトウェアコンポーネントの概念を中心に構築された、 同じオープンアーキテクチャを採用している。 次へ Carrier Grade Linux »
図1:Carrier Grade の定義 ![]() 図2:プラットフォームアーキテクチャ--過去のモデル ![]() 図3:プラットフォームアーキテクチャ--現在そして未来 ![]() 図4:複数のネットワーク構成分を収納した典型的な通信事業者のサブラック
最新トップニュース
|
|