このページの本文へ

前へ 1 2 次へ

「SDN Japan 2014」レポート 前編~総務省、OpenDaylight、NTT Com

運用フェーズに入ったSDN、ユーザー視点で見えてきた課題とは?

2014年11月12日 06時00分更新

文● 高橋睦美

  • この記事をはてなブックマークに追加
  • 本文印刷

ネットワークでもDevOps? NTT Comの「AMPP」が広げる可能性

 NTTコミュニケーションズの栗原良尚氏は、「通信事業社におけるSDI(Softwre Defined Infrastructure)の取り組みと実現に対する課題について」と題し、同社が社内検証網用に独自に開発した「AMPP」(A Multiple southbound interface control Platform and Portal system)の狙いと仕組みについて講演を行った。AMPPの機能の一部は、6月に開催されたInterop Tokyoの「SDN ShowCase」でもデモが展示されていた。

NTTコミュニケーションズの栗原良尚氏

 同社では、運用の自動化による運用コスト削減と、細かな品質制御による顧客のエクスペリエンス向上といった観点からSDNに着目してきたそうだ。「今の仕組みでは、ネットワークを増設してほしいという要望を受けた場合、その開通依頼に応じて、ルーティング担当、MPLS担当、セキュリティ担当、クラウド担当などそれぞれの担当者が人手で設定を行うため、時間がかかるし設定にムラが生じる。ヒューマンリスクのエラーがある上、保守面でも障害発生時の切り分けが大変という課題がある」(栗原氏)。

 こうした課題を、SDNを活用して解決できないだろうか――それがAMPPが生まれたきっかけだ。AMPPは、IPネットワークとMPLS網、データセンターやクラウドサービス全体を一括してオーケストレーションする仕組みだ。オペレーターがGUI上でネットワークの追加などを指示すると、AMPPのオーケストレーターからREST APIを介し、OpenFlowコントローラーを含む複数のコントローラーに指示が行く。これに従ってネットワーク機器や網、クラウドサービスにルーティングやMPLSの設定が追加され、開通のオーダーが自動的に走るようになっている。

 AMPPは、全体を制御するオーケストレーターの下に、「Ryu」をベースとしたOpenFlowコントローラーやOpenStack APIを利用したクラウドオーケストレーター、それにSDN/OpenFlow非対応機器に対して抽象化されたインターフェイスを通じて管理を行うコマンドラインのDevコントローラーなどが連携する構成となっている。「すべてにOpenFlowを使うのではなく、得意なところに生かす」(栗原氏)という発想だ。

AMPPの構成およびアーキテクチャ

 OpenFlowを生かした例の1つが、「OpenFLow PatchPanel」だという。これは、あらかじめ物理的な配線を済ませておいたルーターやスイッチのトポロジを、OpenFlowエントリで変更することでネットワークを停止させることなく、特定のトラフィックのみをプローブできる仕組みだ。「メンテナンスのために停止させることなく、見たいポート、見たいvLANだけをタップするといったことができる」(栗原氏)。

 栗原氏は、AMPPによって、ルーティングやMPLS、クラウドといった異なるサービスをまたいだ設定の自動化が実現できたと評価する。一方で、「マルチベンダー対応がない点は課題だ。独自のシステムインテグレーションなしで使えるようになれば」と、業界への期待を述べた。さらには、「DevOps」のアプローチがネットワークにも適用され、「テスト環境の情報を吸い上げて、そのままどんと本番環境に適用できるようになれば面白い。これができれば、顧客にネットワークを導入する際のテストなども自動化できるかもしれない」(栗原氏)と語った。

* * * * *

 後編記事では、Interop Tokyoの「ShowNet」運用チームが語ったSDN活用の裏側と課題についてご紹介したい。どうぞお楽しみに。

■関連サイト

前へ 1 2 次へ

カテゴリートップへ

  • 角川アスキー総合研究所
  • アスキーカード