Cisco Service Control Management Suite Collection Manager ユーザ ガイド Rel. 3.1
Collection Manager の機能
Collection Manager の機能
発行日;2012/02/04 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 600KB) | フィードバック

目次

Collection Manager の機能

データ収集プロセス

RDR

CM ソフトウェア パッケージ

RDR サーバ

カテゴライザ

プライオリティ キューおよび永続的バッファ

アダプタ

JDBC アダプタ

CSV アダプタ

TA アダプタ

TA アダプタ サイクル

RAG アダプタ

RAG アダプタ集計バケット

バケットのフラッシュ

HTTPC アダプタ

データベース

バンドルされているデータベースの使用法

外部データベースの使用法

Collection Manager の機能

この章では、Collection Manager(CM)コンポーネントの機能について詳細に説明します。

この章では、Cisco Service Control Management Suite(SCMS)CM の機能について説明します。ここでは、Service Control Engine(SCE)プラットフォームが生成し CM に送信する Raw Data Record(RDR)、および CM ソフトウェア パッケージのコンポーネントの概要について説明します。また、RDR を格納するために使用されるデータベースの概要も示します。

「データ収集プロセス」

「RDR」

「CM ソフトウェア パッケージ」

「アダプタ」

「データベース」

データ収集プロセス

Cisco SCE プラットフォームは、Cisco Service Control Application for Broadband(SCA BB)などの、SEC プラットフォームで実行中のアプリケーションが仕様を定義した RDR を生成します。

RDR はシンプルで信頼性の高い RDR-Protocol を使用して、SCE プラットフォームから送信されます。Service Control ソリューションへのデータ レコード収集の統合作業では、収集システムへの RDR-Protocol サポート(わかりやすい開発プロセス)の実装も行われます。

CM が SCE プラットフォームから RDR を受信したあと、CM ソフトウェア モジュールは、プリセット カテゴリおよびタイプとプライオリティに基づいて各種タイプの RDR を認識してソートし、永続バッファに RDR をキューします。

その後、1 つまたは複数の CM アダプタが各 RDR を処理します。各アダプタが、RDR に関する特定の機能を実行します(RDR をローカル マシンに CSV 形式ファイルで保存したり、RDBMS(リレーショナル データベース管理システム)アプリケーションに送信したり、カスタム操作を実行したりします)。

プリインストールされているユーティリティ スクリプトを使用すると、CM の動作に影響する多数のパラメータを決定できます。

RDR

RDR は、SCE プラットフォームで作成されるレポートです。RDR、そのフィールド、および意味のリストは、固有の Service Control Protocol(SCP)アプリケーションごとに異なります。各 RDR タイプには RDR タグという固有の ID があります。

次に、SCP アプリケーションで作成可能な RDR の例を示します。

定期加入者使用状況レポート ― SCE プラットフォームは加入者認識ネットワーク デバイスで、加入者毎の使用状況をレポートすることができます。

これらの RDR には、一般的に加入者 ID(OSS 加入者 ID 等)、トラフィック タイプ(HTTP、ストリーミング、ピアツーピア トラフィック)、および使用状況カウンタ(合計アップストリームおよびダウンストリーム量など)が含まれています。これらのタイプの使用状況レポートは、使用状況ベースの課金方式を使用する場合や、ネットワーク分析や容量計画に必要です。

SCA BB アプリケーション加入者使用状況 RDR は次のようなカテゴリに含まれます。

トランザクション レベル レポート ― SCE プラットフォームは、配置されたリンク上で実行される各ネットワーク トランザクションのステートフル追跡を実行します。このステートフル性を使用して、SCP は複数の OSI レイヤ 7 プロトコル(HTTP、RTSP、SIP、Gnutella など)を追跡して、各アプリケーション レベル属性についてレポートします。

通常、これらの RDR には、基本的なレイヤ 3 ~ 4 属性(送信元 IP、宛先 IP、ポート番号など)からレイヤ 7 プロトコル依存属性(ユーザエージェント、HTTP のホスト名、SMTP メール送信者の電子メール アドレスなど)のトランザクションレベル パラメータ、および一般的なパラメータ(時刻、トランザクション有効期限など)が含まれます。これらの RDR は、コンテンツベース課金方式や詳細な使用状況統計情報にとって重要です。

SCA BB アプリケーション トランザクション RDR は次のようなカテゴリに含まれます。

SCP アプリケーション アクティビティ レポート ― SCP アプリケーションでは、ネットワーク トラフィックにさまざまなアクションを実行するように SCE プラットフォームをプログラムできます。これらのアクションには、トランザクションのブロック、特定の速度と制限へのトラフィックのシェーピング、アプリケーションレベルのリダイレクションの実行などが含まれています。そのような操作が実行される際に、SCP アプリケーションが RDR を生成する可能性があります。

SCA BB アプリケーション Breaching RDR および Blocking RDR は次のようなカテゴリに含まれます。(使用状況が何らかのクォータを超えたために)システムによって加入者へのアクティブな適用が変更された場合に、Breaching RDR が生成されます。(現在のサービス コンフィギュレーションに含まれている規則に従って)SCE プラットフォームがネットワーク トランザクションをブロックした場合に、Blocking RDR が生成されます。

CM ソフトウェア パッケージ

CM ソフトウェア パッケージには、一連の処理モジュールおよびソート モジュールが含まれています。たとえば、次のコンポーネントなどです。

「RDR サーバ」

「カテゴライザ」

「プライオリティ キューおよび永続的バッファ」

RDR サーバ

各着信 RDR は SCE プラットフォームから着信するため、RDR サーバが着信タイムスタンプと送信元 SCE プラットフォームの ID をこれに付加して、RDR をカテゴライザに送信します。

カテゴライザ

カテゴライザでは、RDR タグに従って各 RDR を分類します。また、各 RDR の宛先アダプタ、および RDR を送信する場合に経由するプライオリティ キューを決定します。

RDR は複数のアダプタに対応付けることができます。ユーザの要件に基づいて、有資格技術者がフローをコンフィギュレーション ファイルに定義します。

プライオリティ キューおよび永続的バッファ

各アダプタには各プライオリティ キューが 1 つ以上あり、各プライオリティ キューに永続的バッファが 1 つ割り当てられています。

プライオリティ キューで、プライオリティ レベルに従って各 RDR がキューイングされ、アダプタで処理されるまで永続的バッファに格納されます。

永続的バッファは不揮発性ストレージ領域で、万が一ハードウェア、ソフトウェア、または電源障害が発生してもシステムでの RDR の処理が保証されます。

アダプタ

アダプタは、目的のシステム要件を満たすように RDR を変換して、要求時に RDR を配布するソフトウェア モジュールです。現在、システムには次のアダプタが同梱されています。

JDBC アダプタ

CSV アダプタ

TA アダプタ

Real-Time Aggregating(RAG)アダプタ

HTTPC アダプタ

アダプタの中には、データベースへデータを送信したり、CSV ファイルに書き込むものもあります。データベース テーブルの構造、およびこれらの CSV ファイルの場所と構造については、『 Cisco Service Control Application for Broadband Reference Guide 』で説明しています。

各アダプタには独自のコンフィギュレーション ファイルがあり、すべてのコンフィギュレーション ファイルは構造内で類似しています。サンプルの RAG アダプタ コンフィギュレーション ファイルについては、「ragadapter.conf ファイル」を参照してください。

「JDBC アダプタ」

「CSV アダプタ」

「TA アダプタ」

「RAG アダプタ」

「HTTPC アダプタ」

JDBC アダプタ

JDBC アダプタは RDR を受け入れて処理し、データベースに格納します。

このアダプタの設計目的は、JDBC 準拠の任意のデータベース サーバとの互換性を保つことであり、そのデータベース サーバに応じてレコードが変換されます。JDBC アダプタは、リモート マシンで稼働するデータベースを利用するように設定できます。

JDBC アダプタは、以下のデータベースをサポートするように事前設定されています。

Sybase ASE 12.5 および 15.0

Oracle 9.2 および 10

MySQL 4.1 および 5

CSV アダプタ

CSV アダプタは、RDR を受信して処理し、ディスク上のファイルに CSV 形式で書き込みます。FTP(ファイル転送プロトコル)などの標準メカニズムを使用して、サービス プロバイダーの OSS またはサードパーティ製課金システムでこれらのレコードを取得し、拡張アカウンティングおよびネットワーク トラフィック分析レコードを生成することもできます。

TA アダプタ

TA アダプタは、加入者使用状況 RDR を受信し、含まれているデータを集計して、上位レポートをデータベースに出力し、また集計した(上位のコンシューマだけではなく)すべての加入者の日次統計を CSV ファイルに出力します。複数のメトリックの上位加入者リストを定期的に出力します(直前の 1 時間における上位 50 のトラフィック量またはセッション コンシューマなど)。

このアダプタは永続的な保存状態(ディスクに保存)を維持して、障害時のデータ損失を最小限にします。

TA アダプタは、JDBC アダプタのインフラストラクチャを使用し、JDBC 準拠データベースを使用してローカルまたはリモートで設定することができます。

TA アダプタ サイクル

TA アダプタは、短期サイクルと長期サイクルの 2 種類のサイクルで動作します。サイクルは、最後に TA アダプタが集計情報をデータベースおよび CSV ファイルに出力することのできる固定インターバルです。短期サイクルのインターバルは 1 時間、長期サイクルのインターバルは 24 時間(毎日深夜)です。(分単位で定義される)インターバルと開始および終了時間を設定可能です。


) 長期サイクル インターバルは、短期サイクル インターバルの乗数でなければなりません。


各サイクルのアクティビティは、次のようにわずかに異なります。

短期サイクル ― 短期サイクルの終わりに、アダプタは次の処理を実行します。

直前のサイクルの集約上位レポートを、短期サイクル データベース テーブルに追加します。

停電の発生に備えて、現在のステータス ファイルを保存します。

長期サイクル ― 長期サイクルの終わりに、アダプタは次の処理を実行します。

直前のサイクルの集約上位レポートを、短期サイクル データベース テーブルに追加します。

停電の発生に備えて、現在のステータス ファイルを保存します。

長期サイクル期間の集計統計情報を含む CSV ファイルを作成します。

RAG アダプタ

RAG アダプタは 1 つ以上のタイプの RDR を処理し、あらかじめ指定されたフィールド位置のデータをバケットに累積します。バケットの内容は CSV ファイルに書き込まれます。

「RAG アダプタ集計バケット」

「バケットのフラッシュ」

RAG アダプタ集計バケット

RAG アダプタ集計バケットは、RDR 内のフィールドの値を組み合わせてインデックス化されます。インデックス関係は、1 対 1 または他対 1 になります。

バケット識別フィールドの値は、RDR タイプごとに設定されたクロージャ(同等クラス)を使用して処理されます。

例:

Bucket-identifying field = field number 3
Closures: 4 = 4,5,6; 10 = 8,10,11
Value in field 3 = 4, 5, or 6; field reported as 4
Value in field 3 = 8, 10, or 11; field reported as 10
 

特定のフィールド値をモニタして、バケットに格納された最初の RDR の値に対する変化を調べるように、アダプタを設定できます。モニタするフィールドごとに、値の変化が検出時に動作が実行されます。サポートされている動作は次のとおりです。

この RDR を集約しないでバケットを終了し(チェックポイント)、この RDR で新しいバケットを開始します。

ユーザ ログに警告を発行します。

バケット、クロージャ、トリガ、およびトリガ動作が XML ファイルに定義されます。XML ファイル例については、「ragadapter.xml ファイル」を参照してください。

バケットのフラッシュ

バケットがフラッシュされると、CSV ファイルに CSV 行として書き込まれます。

バケットをフラッシュするためのトリガー(チェックポイント)は、次のうち、発生時間が最も早いものになります。

バケット作成後の経過時間が設定値に到達

バケット内の累積フィールドの量が設定値を超過

アダプタまたは CM 全体がダウン

一部のフィールドに(バケットの内容と比較して)新しい値を持つ RDR がバケットに到着

CSV ファイルを閉じるためのトリガーは、次のうち、発生時間が最も早いものになります。

ファイル作成後の経過時間が設定値に到達

ファイル内の行数が設定値に到達

アダプタまたは CM 全体がダウン

HTTPC アダプタ

HTTPC アダプタは RDR を受け入れて処理し、それを HTTP でポリシー サーバへ送信します。

HTTPC アダプタは、さまざまなポリシー サーバ モードと特定フローで必要な動作に従って、いろいろな HTTP 要求を設定するのに使用することができます。

HTTPC アダプタは、フローが開始されるポリシー サーバへの信号と、フローが終了するポリシー サーバへの信号に対する 2 つのタイプの RDR のみを受信します。

データベース

CM は、バンドルされているデータベースまたは外部データベースを使用して、システムの SCE プラットフォームから供給される RDR を格納することができます。

「バンドルされているデータベースの使用法」

「外部データベースの使用法」

バンドルされているデータベースの使用法

バンドル モードでは、CM は Sybase Adaptive Server Enterprise データベースを使用します。これは、トランザクション集約型のエンタープライズ アプリケーションをサポートし、オンラインでの情報の格納および取得が可能で、必要に応じて情報を蓄積することができます。

Sybase データベースは、他の CM コンポーネントと同じサーバ内にあります。小さくてシンプルなテーブルのグループから構成されるシンプルなスキーマを使用します。JDBC アダプタは、変換済の RDR をデータベースに送信して、これらのテーブルに格納します。レコードには、標準データベース クエリーおよびレポーティング ツールを使用してアクセスできます(シスコでは、サービス コントロール レポート ツール用の情報として、加入者の使用状況、ネットワーク リソース分析、およびトラフィック分析についてのレポートを生成できるテンプレートベースのレポート ツールを提供しています。『 Cisco Service Control Application Reporter User Guide 』を参照してください)。

データベース メンテナンスは、オペレーティング システムのコマンドとスクリプトを使用して実行されます。CM は、古いレコードをバンドルされているデータベースから自動消去する機能をサポートしています。デフォルトでは、レポート テーブルに保存された期間が2週間を超えるすべてのレコードは、自動的に消去されます。レコードは 1 時間おきにポーリングされます。データベース メンテナンスを設定するには、 dbperiodic.py ユーティリティ スクリプトを使用します。詳細については、「古いレコードの定期削除の管理」を参照してください。

外部データベースの使用法

JDBC 準拠データベース(Oracle や MySQL 等)を JDBC アダプタとともに CM で使用することができます。この場合、ローカルまたはリモートでデータベースを使用することができます。データベースを使用するように JDBC アダプタを設定し、データベース パックを設定して CM にデータベースのパラメータ(IP アドレスやポート等)を供給します。また、このデータベース用の JDBC ドライバを用意して、データベースに接続するときにアダプタで使用する必要があります。外部データベースと連動した CM の設定の詳細については、「データベースおよび CSV リポジトリの管理」を参照してください。