普及を阻むのはベンダーの独善的拙速

「シンプルなファブリック」でSDNは「2016年こそ本当に」離陸できるのか（1/3 ページ）

「企業はメリットのないものを決して導入しない」「従来技術によるネットワークアーキテクチャは終わりを迎えようとしている」と語るネットワーク技術者が、SDNが普及するために必要な条件を示す。

公開 2016年06月15日 09時01分

更新 2016年09月01日 11時43分

著者

佐熊勇介

[日本アバイア]

印刷する Googleで優先するソースとして追加

　「Software Defined Networking（SDN）は複雑そうだ」「SDNはうちのような規模の小さい企業には見合わない」

　このようなユーザー企業の声を、この数年何度も聞いてきた。SDNという言葉に対して、日本ではこのような間違ったイメージに基づく誤解が広まっている。その原因は、多くのSDN対応ネットワーク機器ベンダーが、ユーザー企業の課題を解決するためではなく、自分たちの理想とするSDNを主軸とした提案を押し付けてきたことにある。しかし、ユーザー企業は、ビジネスメリットのないものを決して導入しない。

　その一方で、ネットワークを取り巻く環境が急激に変化している。スマートデバイスやインターネットにつながるモノ（IoTデバイス）の普及、ビッグデータの活用が進み、新たなビジネスチャンスを生んでいる。これらのビジネス活用が進む中、ユーザー企業はビジネスプロセスの自動化を求めている。「デジタルトランスフォーメーション」と呼ぶことも多いこの流れがある一方で、支えるネットワークインフラは従来通り設定や構成変更が必要なままだ。この状態はいつまで続くのだろうか。

　今こそ自動化したネットワークが必要だ。そのためにはSDNの概念を実現できる正しいアプローチが必須になる。この記事ではそのステップを紹介する。

2016年上半期「ネットワーク」記事ランキング（2016年1月1日～2016年6月20日）

1位　見くびっていると超難問、無線LANとWindowsの単純トラブル処方薬

2位　今後登場する無線LAN規格の全て、IEEE 802.11ac「Wave 2」は何をもたらす？

3位　MVNOが提供するビジネス向け「格安SIM」サービスをチェックする

4位　「VLAN」編──全てはVLANの混沌から

5位　意外に便利な“野良Wi-Fi”、それでも放置してはいけない理由とは

ステップ1：シンプルなネットワークアーキテクチャの導入

　多くのSDNベンダーは、ネットワークインフラが抱える現状の課題を解決しないまま、「オーケストレーター（ITインフラ全体のリソース制御・管理を担うシステム）で自動化」という方向を提案する。だが、そもそものネットワークインフラの課題を解決せずしてSDNの実現はできない。その課題とは何か。

ネットワーク予算の大部分をメンテナンスのために費やしている
新たなサービスの展開にシステム導入だけで何カ月もかかっている
保守やトラブルシューティングに多くの時間を割いている

　この課題を放置したままで前向きなIT投資はできない。そして、どの課題も複雑な従来技術のネットワークが原因となっている。

　こうした原因を取り除くために、シンプルなアーキテクチャのネットワークインフラを構築する必要がある。その有力な手段が、ネットワークリソースの効率的な利用や低遅延化、拡張性向上などを実現するネットワーク構成手法「ファブリック」（イーサネットファブリックとも呼ぶ）だ。

ファブリックは、データ転送の最短経路を自動的に選択したり複数の最短経路を同時に利用可能にしたりする「レイヤー2マルチパス」といった技術で構成する。レイヤー2マルチパスを構成する主要技術として「Shortest Path Bridging」（以下、SPB）がある。SPBは既に標準化団体のIEEEとIETFの策定作業で標準化した技術で、その内容は「IEEE802.1aq」と「RFC 6329」で定義している。

　従来のネットワーク技術では、ループ防止プロトコルの「スパニングツリープロトコル」（STP）やルーティング（経路制御）プロトコルの「OSPF」「PIM」といったさまざまなプロトコルをスタックして構成していたため、ネットワークデザインでもトラブルシューティングでも、スタックした全てのプロトコルを意識しなければならなかった。

　それに対してファブリックベースのSDNアーキテクチャは、SPBのみの単一プロトコルを使う。そのため、プロトコルスタックを排除したシンプルなアーキテクチャを実現した（なお、単一のプロトコルとして「TRILL」もあるが、こちらは、L3ネットワークやIPマルチキャストにおいてプロトコルスタックが必要になる。一方、SPBはL3ネットワークやIPマルチキャストでも単一プロトコルで対応できる）。万が一、ネットワーク障害が発生した場合は、最短経路に自動で迂回することで基本的には数百ミリ秒というレベルで復旧が可能だ。

例えば、Avayaのファブリックをベースとしたネットワークアーキテクチャ「Avaya SDN Fx」では、複雑なプロトコルスタックを排除してシンプルな構成を実現した（出典：Avaya）《クリックで拡大》

次ページへ導入は短時間であればなるほど普及しやすい。

印刷する

この記事の著者

佐熊勇介

日本アバイアのAvaya Networking ＆ SDN SolutionsのチームのNetwork Sales Directorとして、主にSDN関連製品の市場開発に従事。以下のSNSでも発信している。 Facebook https://www.facebook.com/AvayaNetworking Twitter https://twitter.com/sakumayusuke

「シンプルなファブリック」でSDNは「2016年こそ本当に」離陸できるのか（1/3 ページ）

2016年上半期「ネットワーク」記事ランキング（2016年1月1日～2016年6月20日）

ステップ1：シンプルなネットワークアーキテクチャの導入

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

「シンプルなファブリック」でSDNは「2016年こそ本当に」離陸できるのか（1/3 ページ）

2016年上半期「ネットワーク」記事ランキング（2016年1月1日～2016年6月20日）

ステップ1：シンプルなネットワークアーキテクチャの導入

この記事の著者

関連記事

ブームが去った後にこそ真価が問われるSDN

SDNの本格導入が進まない4つの理由

SDNで既存のプロトコルを使えるか？

「SDN」編──“ネットワーク管理に向いていない人類”を助けるはずだった

「OpenFlow」編──その実力以上に期待されてしまった救世主

「VLAN」編──全てはVLANの混沌から

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓