VMware/サーバー/ネットワーク監視ツール
COLUMN
2012.01.26

第9回:OpenFlow環境の性能監視

今回の「kanshi de mirai」は、新しいネットワーク技術であるOpenFlowについてふれてみます。

私もいくつかのミーティングに出ておりますが、SDN(Software Defined Networking)の一機能であるOpenFlowの話題が非常に多くなっています。OpenFlow対応機種ではスイッチが発表されていますが、商用のコントローラだけでなく、仮想スイッチやハイパーバイザーとの連携、スマートフォン対応など、適用範囲が広がっており、少しずつ普及のフェーズに入ってきているようにも思えます。

OpenFlowはメディアでも多数登場していますが、このコラムでも少しだけ機能の概要を記載します。

OpenFlowのネットワークは「OpenFlowコントローラ」と「OpenFlowスイッチ」から構成されます。経路計算などはOpenFlowコントローラが担当し、OpenFlowスイッチはOpenFlowコントローラで設定されている「フローテーブル」に従い、パケット転送を実行します。
フローテーブルはOpenFlowコントローラ上にありますが、OpenFlowスイッチは「OpenFlowプロトコル」でやり取りしたフローテーブルをキャッシュすることで、次回以降の通信は効率的に転送が可能となります。

ネットワークエンジニアの目線で記載を致しますと、ネットワークの設計・導入をおこなう際に、設計したネットワークフローに沿って冗長構成やVLAN、QoS等を考慮して、個々のスイッチの設定を検討しコンフィグレーションをおこないますが、OpenFlowでは各スイッチには最低限の設定のみをおこない、詳細なコンフィグレーションをフローテーブルという形で「コントローラ」におこないます。

ここで構築のポイントですが、OpenFlowコントローラに設定したフローテーブルをスイッチ側に予めキャッシュさせておく事がポイントです。

大規模システムでは多数のフローテーブルを登録しますので、スイッチ上にない経路宛のパケットが来た際に発生するコントローラへの問い合わせを出来るだけ減らすことで、遅延ならびにコントローラへの負荷を軽減することが可能になります。

システム運用の目線で記載を致しますと、システムがどのようなネットワークフローで稼働しているのか、トラブル時の障害判断や経路切替、設定追加・変更もすべて「コントローラ」での制御になりますので、ネットワークの安定化および管理の一元化ができます。

また、OpenFlowのメリットとして「仮想化による運用の容易性」が上げられ、構築時やプロビジョニング、トラブル時の優位性もあり、ネットワーク負荷増大時のスケールアウトの容易性も上げられます。

今回のコラムでなぜOpenFlowを取り上げたかといいますと、我々アイビーシーのミッションはICTサービスの可視化、ICTサービスの安定稼働を掲げており、OpenFlowと非常にリンクしていると考えているからです。

では、容易な可視化、安定稼働、運用が楽になる「OpenFlow」が登場することで、我々のツール・サービスが必要無くなるのでしょうか?

実は逆に我々の出番が増えることになります。

OpenFlowネットワークの運用のポイントとしては、

  1. 1.増大するトラフィックに対しての適切なキャパシティ管理
  2. 2.スイッチ全体が安定的に稼働しているかを把握するリソース管理
  3. 3.複雑な計算・処理をおこなうコントローラのリソース管理

実は上記の1、2を把握するための手法はコントローラではなく、個々のスイッチの情報を把握する事が現状のOpenFlowネットワークでは一般的です。
コントローラ・スイッチ間でのOpenFlowプロトコルではパケットの統計情報も合わせて送信されますが、構築ポイントで記載したように、OpenFlowプロトコルによる問い合わせを減らすことで統計情報を収集することが難しい為に、スイッチ側の情報を収集する手法となります。
コントローラで一元管理が可能な最新のネットワークであっても、性能の把握は個々のスイッチに対してレガシーなプロトコルである「SNMP」が活用されています。
もちろん3のコントローラのリソースも一般的なサーバーで稼働している為、「SNMP」で把握可能です。

新しいネットワークシステムであっても、安定稼働させるためには今まで通り「システムの性能全般」を正確に把握する事が一番のポイントであると考えます。
複数のシステムを統合する際にもOpenFlowネットワークは有効的ですが、新ネットワークシステムへの移行に対して、現在の複数システムの稼働状況を正確に把握し、適切なサイジングをおこなう為の事前アセスメントにもやはり「性能」を含めた全体の把握が必要です。
OpenFlowはあくまでネットワークレイヤとなりますので、その上で動くアプリケーションの稼働状況を把握する上で、サーバーシステムの性能把握も当然必要です。

アイビーシーのミッションである「ICTサービスの可視化」の解決の為に、OpenFlowネットワークに向けては、製品であるSystem Answer や System Answer G2をどのように連携が出来る、サービスとして事前アセスメントや導入時の運用システム全般のサービス提供も含めて取り組みをおこなっています。

クラウド時代のネットワークシステムとして、OpenFlowだけではなく、新たな規格(VXLAN、TRILL、VEPA 等々。。。)がドラフト・標準化が進んでいます。

これからも新しい機能に対しての運用の課題をどのように解決できるのかを含め、アイビーシーの取り組みをこのコラムで記載させて頂きます。

次回のテーマは「『レスポンス』の監視を考えてみて」です。

by コンサルティング部 塚本浩之

お電話でのお問い合わせ
受付 9:30〜17:30(平日)
トップに戻る
上に戻る