2017-11-15 11 views
1

SDNコントローラは多様で複雑ですが、共通の目標と機能を備えています。どのSDNコントローラを選択するかを知る上で重要なことは、パフォーマンスが良いかどうか、パフォーマンスのボトルネックがかなり高いかどうかです。OpenFlowコントローラの性能評価:信頼性の高い評価は何ですか?

知恵を借りて、私はthis evaluation paperを見つけました。これは、OpenFlowのパフォーマンスを本質的に批判し、なぜOpenFlowプロトコルがサブビジョンとして実装されたのかについての多くの洞察的理由を与えています。最も興味深いのは、同様のベンチマークで多くのSDNコントローラを比較したことです。

私はOpenDaylightコントローラを使って研究していますが、この論文ではODLが非常に非効率で実験データが無駄であると主張しています。これは、ODLがどれほど大きくてアクティブなのかを考えると、非現実的な主張のようです。

この論文では、他のOpenFlowコントローラのパフォーマンスがあまり良くない理由はたくさんありますが、OpenDaylightでは厳密に何も指定されていないのは面倒です。さらに、私はこれらのSDNコントローラの一般的な論理アーキテクチャは与えられていないことに注意します。これは心配です。プログラマビリティはSDNのゲームの名前なので、ほとんどの場合デフォルト動作を使用しています(これは私が想定していることです)は、おそらくSDNコントローラの容量を比較する最も信頼できる方法ではありません。

コントローラAはテクニックAを使用してトポロジを自動的に検出し、コントローラBはテクニックBを使用します。実装Bに関係なくテクニックBが効率的であれば、両方のコントローラのパフォーマンス評価に明らかな偏りが生じます。両方のコントローラがテクニックB(SDNの高度に設定可能な性質を考慮して妥当なもの)を使用した場合、評価はより公平になります。

私を悩ますもう一つの点は、評価される特性です。私の考えでは、レイテンシは、特定のハードウェアノードの1秒あたりの一定量のメッセージを処理するボトルネックのパフォーマンスと同じくらい重要です。これは私にとっては、SDNで同様のタスクを実行するさまざまな手法が存在するため、実装に依存することははるかに少なくなりますが、これらの手法ではメッセージングオーバーヘッドやパケットイン/パケットアウトと同じ '複雑さ'レート。

これは意味がありますか?そうですか、何か不足していますか?紙に書かれている演奏は、塩の穀物で取られていますか? 「はい」の場合は、実装に依存しないコントローラテクノロジを評価する方法は何ですか?

答えて

3

私の友人の1人、RedHatのDaniel Farrelが、あなたの 質問へのURLを送ってくれました。 Danielは数年間OPNFV CPerfプロジェクトを率いていました。 https://wiki.opnfv.org/display/cperf CPerfは、 ODL統合/テスト、OPNFV、IETFベンチマーキングメソドロジ ワーキンググループのメンバーとのクロスプロジェクト協力です。私たちは、テストの取り組みである と週1回のディスカッションを通じてかなりのことを学びました(もちろん、私たちに参加しても構いません)。

私はあなたが引用した会議論文を読み、多くのあなたの 懸念事項を共有しています。あなたの興味や疑問の多くは、ターゲットになっています。 と私はいくつかのリンクを共有し、いくつかの短い答えを追加します。 これは役に立つかもしれません。

私も、 のパフォーマンスが低いためにODLの結果を除外したことに驚いていました。ODL、CIテストの結果を含む ための周りのテスト結果がたくさんあります: 興味深い比較研究のhttps://wiki.opendaylight.org/view/CrossProject:Integration_Group:Performance_Test:Results 一つは、数年前、CPerfの メンバーによって行われた。 驚きの一つは、ということでしたhttps://www.linux.com/news/sdn-developers-report-key-lessons-testing-opendaylight-performance

永続データストア(ODLの重要な信頼性機能 )が のパフォーマンスハンディキャップであり、他のコントローラがこの 機能を提供しなかったか、デフォルトで有効にしていませんでした。公平なデータストア は、公正な比較を行うためにODLで無効にする必要があります。データストアにSSDを使用する利点も評価されました。 ODLコントローラの より最近のテストでは、ここで説明されています https://www.opendaylight.org/blog/2017/10/24/how-performance-testing-improved-the-nitrogen-release

別のディスカッショントピックは、コントローラのベンチマークのための メトリックのセット「右」を中心としています。 https://jira.opnfv.org/projects/CPERF/issues/CPERF-3?filter=allopenissues OpenFlow Packet-INの紛失件数が に減少したことは、Flow-MODレスポンスがベンチマークの重要なメトリックであることを示しています。換言すれば、 コントローラスループットの多くのテストでも応答待ち時間は と同時に測定され、多くの待ち時間の高いスループットは多くの応答で有効な稼働状態ではない可能性があります。 Packet-INが応答を生成しない場合も同様です。 とCPerfは、スループット測定で応答が失われていないレベルの を報告することに同意しました。我々のチームメンバーの1人は golangツールをコントローラのプローブとしてデプロイしました: https://github.com/anastop/latte そして、OFインターフェイスでの損失と遅延の両方の測定を行います。 https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-term-06 https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-meth-06

は、私はあなたがいただければ幸いです:

私はまた、IETFベンチマーク手法WGは は、コントローラのベンチマークのための仕様に取り組んでおり、筆頭著者これらのインターネットドラフトの もCPerfに参加したことを述べましたあなたの研究に役立つこの資料を探してください。

al

関連する問題