Cisco Service Control Management Suite Collection Manager ユーザ ガイド
Collection Manager 概要
Collection Manager 概要
発行日;2012/02/03 | 英語版ドキュメント(2011/02/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

Collection Manager 概要

データ収集プロセス

Raw Data Record

Collection Manager ソフトウェア パッケージ

Raw Data Record サーバ

カテゴライザ

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

アダプタの説明

JDBC アダプタ

カンマ区切り形式のアダプタ

Topper/Aggregator アダプタ

TA アダプタ サイクル

TA アダプタ メモリ要件

Real-time Aggregating アダプタ

RAG アダプタ集計バケット

バケットのフラッシュ

データベースの使用

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

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

Collection Manager 概要

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

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

「データ収集プロセス」

「Raw Data Record」

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

「アダプタの説明」

「データベースの使用」

データ収集プロセス

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

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

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

3. 1 つ以上の CM アダプタが各 RDR を処理します。各アダプタが、RDR に関する特定の機能を実行します(RDR をローカル マシンに Comma Separated Value(CSV; カンマ区切り形式)ファイルで保存したり、RDBMS アプリケーションに送信したり、カスタム操作を実行したりします)。

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

Raw Data Record

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

表 2-1 には、SCP アプリケーションによって生成される RDR の例が含まれています。

 

表 2-1 SCP アプリケーションによって生成される RDR の例

レポート タイプ
説明
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 が生成されます。

Collection Manager ソフトウェア パッケージ

CM ソフトウェア パッケージは、処理モジュールおよびソート モジュールのグループです。たとえば、次のコンポーネントなどです。

「Raw Data Record サーバ」

「カテゴライザ」

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

Raw Data Record サーバ

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

カテゴライザ

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

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

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

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

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

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

アダプタの説明

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

「JDBC アダプタ」

「カンマ区切り形式のアダプタ」

「Topper/Aggregator アダプタ」

「Real-time Aggregating アダプタ」

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

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

JDBC アダプタ

JDBC アダプタは RDR を受信して処理し、レコードをデータベースに格納します。

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

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

Sybase Adaptive Server Enterprise(ASE)12.5 および 15.0

Oracle 9.2、10.2、11


) Oracle 10 以降のバージョンで利用できるごみ箱機能はディセーブルにする必要があります。テキスト初期化ファイルである init<SID>.ora ファイルの recyclebin パラメータの初期値を設定できます。例:
recyclebin=off


MySQL 4.1、5.0、5.1

カンマ区切り形式のアダプタ

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

Topper/Aggregator アダプタ

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

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

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


) 複数の CM サーバが 1 つのデータベースを使用する場合は、TA アダプタは各 CM 上でローカルに集約されるため、TA アダプタ情報が不正確になる可能性があります。


「TA アダプタ サイクル」

「TA アダプタ メモリ要件」

TA アダプタ サイクル

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


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


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

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

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

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

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

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

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

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

TA アダプタ メモリ要件

TA アダプタが正常に動作するには、十分なメモリ量を TA アダプタ専用に割り当てる必要があります。次の場所にある cm.conf コンフィギュレーション ファイルの値を設定します。

[adapter_mem]
com.cisco.scmscm.adapters.topper.TAAdapter=<Memory for TA Adapter>

TA アダプタ専用に割り当てる推奨メモリ量を計算するには、次の計算式を使用します。

メモリ(バイト)= 2.5 × NUM_SUBSCRIBERS × (AVG_SUBS_ID_LENGTH + 64 × NUM_SERVICES + 12 × NUM_TOP_ENTRIES)

ここでは、各変数には次の値が入ります。

NUM_SUBSCRIBERS は、(この CM にレポートを送信するすべての SCE 上への)追加が見込まれる 1 日当たりの新しい加入者数です。

一般的に、この値は大きい数値になります。特に、匿名加入者モードで動作している場合には、大きい値になります。

CM がすでに認識している加入者見積もり数を表示するには、次のコマンドを使用します。

~/setup/mbean.py --getattr=Subscribers DCAdapters com.cisco.scmscm.adapters.topper.TAAdapter
 

AVG_SUBS_ID_LENGTH は、加入者の平均文字長です。

一般的には、この値を 20 前後に設定します。

NUM_SERVICES は加入者使用状況のカウンタ数で、 taadapter.conf コンフィギュレーション ファイルで設定されます。

NUM_TOP_ENTRIES は taadapter.conf コンフィギュレーション ファイルの num_top_entries 値で設定します。


) Linux の場合、メモリ構成が 2 GB を超えることはできません。
Solaris JRE 32-bit の場合は、メモリ構成が 3.5 GB を超えることはできません。
Solaris JRE 64-bit の場合は、メモリ構成をこれよりも大きい値に設定できます。JRE 64-bit で実行するように TA または RAG アダプタを構成するには、「[adapter_mem] セクション」を参照してください。


Real-time Aggregating アダプタ

Real-time Aggregating(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 ファイルに 1 行書き込まれます。

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

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

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

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

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

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

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

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

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

データベースの使用

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

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

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

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

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

Sybase データベースは、他の CM コンポーネントと同じサーバ内にあります。小さくシンプルなテーブルのグループから構成されるシンプルなスキーマを使用します。

1. JDBC アダプタは、変換済みの RDR をデータベースに送信して、これらのテーブルに格納します。

2. レコードには、標準データベース クエリーおよびレポーティング ツールを使用してアクセスできます (シスコでは、Service Control レポート ツール用の情報として、加入者の使用状況、ネットワーク リソース分析、およびトラフィック分析についてのレポートを生成できるテンプレートベースのレポート ツールを提供しています。『 Cisco Service Control Application Reporter User Guide 』を参照してください)。

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

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

任意の JDBC 準拠データベース(Oracle や MySQL など)を JDBC アダプタとともに CM で使用できます。この場合、ローカルまたはリモートでデータベースを使用することができます。

作業手順:

このデータベースを使用するように JDBC アダプタを設定します。

CM にデータベースのパラメータ(IP アドレスやポートなど)を渡すようにデータベース パックを設定します。

また、このデータベース用の JDBC ドライバを用意して、データベースに接続するときにアダプタで使用します。

外部データベースと連動した CM の設定の詳細については、「データベースとカンマ区切り形式リポジトリの管理」を参照してください。