AMPはリアルタイムモニタリングアプライアンスだ。モニタリングポイントにおいてフローから特徴量を抽出する。
前にも書いたが、フローの全量をリダイレクトして分析しているわけではない。各スイッチにおいて前処理をしている。
これらの特徴的な情報を Initiator, Target, Fabric において取得することで、どこに問題があるのかを理解することができる。ECTもしくはFRTが Initiator/Target/Fabricのいずれでも大きい値の場合(何より大きいかは言っていない、これは定常的な値との比較になる)、それはおそらく Target が FC Slow Drain Device であることを表す。また、Fabricだけ普通で、Initiator/Target で大きい場合は、Target が SCSI 的に見た Slow Drain であることを示しているはずだ。このようにある一つの事象を抽出するために複数のモニタリングポイントの情報を関連付けしないといけない(しかもリアルタイムに)。これがAMPのやることだ。
一台のスイッチにおいてレイテンシなどの情報を取得することは FOS の bottleneckmon コマンドで可能だ。しかし、アプリケーションフロー的には単一のスイッチの情報だけでは意味を成さない。AMPはファブリックワイドで情報の集積、関連付け、ポリシー比較、通知を行うのが新しい。
これらの情報をつかうことで、AMPはストレージというよりもアプリケーションのコンサルに使える。仮想化の場合は VM ID 的な情報もないとダメだけど。
どういう場合にAMPのようなアプライアンスが必要になるかというと、
1.大規模(ポート数で言うと2000ポートを越えるような構成)
2.複数のストレージ(とりわけ複数ベンダ)がある
3.FCでいうところの世代がまたがる(4GFC, 8GFC, 16GFCなどを混在させている)デバイスが接続されている
とりわけ、2,3の場合はAMPは役に立つだろう。
対象に課題があるとすると、日本では2,3に合致するケースは少ないというところか。