さて、このシリーズを終わらせないと年が越せない(^_^;)ということで、vExpert Advent Calendar連続投稿中の @interto さんにも鬼振り？されちゃったりしていますが、今年最後のエントリーになるかもですがいってみましょー。
すでに何を書くつもりだったのか半ば忘れているのですが、前々回のエントリーで「オーバーレイプロトコルと集中管理を組み合わせることによって、何が可能となるのか」について書くと予告していたみたいなので、そのあたりから始めてみます…。ただ、せっかく広げるなら今年最後だし最大限の大風呂敷を！ということで、オーバーレイプロトコルに限らず、OpenFlowでもSDNでもなんでもいいんですが、様々な方式を使ったネットワークの集中管理によって、何が可能になるのか、考えてみたいと思います。風呂敷広げすぎて、もはや畳めない、というオチになりそうですし、そもそもタイトルの分散スイッチングと分散ルーティング、からすでにだいぶ乖離してしまっている気もしますが…気にしない！
なお、本エントリーではWANやオフィス／キャンパスネットワークではなく、基本的にデータセンターネットワークを対象にしております。
集中管理されたネットワークのメリットとデメリット
そもそも、なぜデータセンターのネットワークを集中管理したいのでしょうか？それは、サーバ仮想化などによってインフラを動的なリソースとして扱う様になってきたことに伴って、ネットワークもまた同じように、よりリソース的に扱いたいから、つまりは動的な変化と拡張に対応させたいから、といった感じではないでしょうか。さらには、集中管理することによって、次のステップとしての自動化がより実現しやすくなるから、ということも理由といえるかもしれません。
ネットワークの集中管理をするべきなのかどうか、その判断基準はネットワーク規模の大小、ではありません*1。どちらかといえば、メリットの大小、こそが重要なポイントです。つまり、ネットワークを集中管理することによって得られるメリットがとても大きいのであれば、小規模のネットワークであったとしても集中管理を検討すべきですし、逆にどんなに大規模なネットワークだとしても自律分散動作の方が適しているのであれば、ネットワークは集中管理に移行するべきではない、といえます。
また、集中管理＝自動化ではないことは理解しておく必要があるでしょう。前述したとおり、確かに集中管理することによって自動化へは一歩前進することができます。なぜならば、管理対象への接点が1箇所になることによって、自動化はより実現しやすくなるから、です。しかし、集中管理されたネットワークは、単にそれだけでは自動化には結びつきません。また、何でもかんでも管理しようとすることは、逆に自動化を阻害することにも繋がる場合もあり得ますので注意が必要です。たとえばOpenFlowはフロー制御を集中管理するための仕組みを作ろうとしている取り組みですが、全ての通信に対してOpenFlowによってルールを定義しようと思ったらおそらくそれは非常に困難であり、自律分散に基づくネットワークよりも大きなメリットにはなり得ない場合もあるかもしれません*2。
単に複雑性にはふたをしてしまおう、というアプローチにも注意が必要です。たとえば、物理ネットワークのトポロジーを一切意識する必要のない論理ネットワークをオーバーレイによって実現する手法はとても便利ですし、手軽に実現できる「自由にネットワークを構成する」手法ではあるのですが、この手法をネットワーク全体に広げるべきなのかどうかはよく考えてから行うべきであるといえるでしょう。たとえば、VMwareは先日、『VMware NSX Virtualization Network Design Guide』(PDF)というドキュメントを公開しましたが、このドキュメントにおいては、VMware NSXを導入するネットワークにおいては、その基板となる物理ネットワークとしてはいわゆるSpine-Leafトポロジーのフルメッシュアクティブなネットワーク(つまりはEthernet Fabric構成)を構成することが望ましいと記載されています。オーバーレイのネットワークであっても、最終的にはパフォーマンスや安定性などの性能は物理ネットワークに依存するため、(理論的にはIPリーチャビリティさえあればどんな物理ネットワークでも可、とはいえども)物理ネットワークにはボトルネックのない、フラットかつスケールするネットワークが必要とされます。
また、オーバーレイによる論理ネットワークは、仮想マシンと同様に自由に、手軽に構成・追加できるが故に、いわゆるスプロール現象ともいわれる、無秩序な増加が起きてしまう可能性がありえます。VXLANなどのオーバーレイプロトコルによって、VLAN数という制約は超えられるかもしれませんが、それでもむやみなネットワークの増加は、セキュリティ面でも問題を引き起こす可能性があるなどのため、仮想マシンの増加以上に望ましくはない状態となる可能性があり得ます。運用管理にオーバーレイネットワークを組み込むのであれば、ネットワークの追加だけではなく、管理ルール、そして不要になったネットワークの適切な削除までを含めて管理できる方法を明確にしておくべきです。
また、論理ネットワークを構成する、ということは物理ネットワークとは別の、しかし物理ネットワークの影響を受ける新たなネットワークを増やすということに他なりません。それぞれをどういうポリシーで、誰が、どのような方法で管理するのか。それぞれのトポロジーをどう把握し、トラブルシュートや影響範囲の対応は問題なく行うことが可能か、など、導入するのであれば考慮すべき事項は多くあります。
このように、気軽に新しいネットワークを構成することができるということは、大きなメリットであると同時に、デメリットにもなり得る、という点をしっかりと理解した上で集中管理されたネットワークの導入は検討されるべきです。
なぜネットワークを集中管理したいのか？
結局のところ、何のためにネットワークを集中管理したいのか、その目的がぶれないようにすることこそが重要でしょう。ネットワークの管理は、目的ではなく手段であるべきです。ビジネスのスピードに対してITインフラ提供のスピードが足を引っ張っていて、その原因がネットワークの構成や管理に時間がかかることにあるのであれば、ネットワークの管理方法について改善を検討すべきであり、その結果として集中管理する手法が適していると判断したのであれば、そこで始めて「どうやってネットワークを集中管理するか」の検討を始めるべきなのです。
ネットワークを集中管理する方法には様々な手法があります。ネットワークの集中管理、というとらえ方を、単に1箇所にControllerとなる要素を配置するという方式だけに制限せずに、複数台のデバイスから構成されるネットワークを一体化して管理するバリエーションと捉えれば、ハードウェア中心の取り組みからソフトウェア中心の取り組み、両者を組み合わせた方式、オープンソースプロジェクトからベンダーによる独自実装まで、まさに様々、です。
- 独自管理ツールによる構成管理
- 裏側では単にTelnet/SSHでネットワーク機器に接続してコマンドによる構成を投げ込んでいる類のツールを使った構成管理
- SNMPによる構成管理
- NETCONFによる構成管理
- OpenFlowによる構成管理
- onePKなどのオープンではあってもベンダー独自のAPIによる構成管理
- Cisco FabricPathやBrocade VCSなどといったTRILLベースのEthernet Fabricネットワーク
- AvayaやHuaweiなどのSPBベースのEthernet Fabricネットワーク
- Junipar QFabricなどの独自ベースのEthernet Fabricネットワーク
- Cisco Application Centric Infrastructure (ACI)によるオーバーレイプロトコルも包含したEthernet Fabricネットワーク
などなど…。
どの方式を選択するのか、選定のポイントはコストパフォーマンスやらベンダーロックイン回避やら、ユーザによって重要視するポイントは色々あるでしょうが、結局のところは最もユーザにとってもメリットが大きいと判断した方式を選択することになるでしょう。もちろん、メリットだけではなくデメリットもしっかりと確認し、妥協できない点があるのであれば、そもそも集中管理方式を選択しない、という選択肢もあるはずです。
また、点を統合するサーバ仮想化に対して、ネットワークは面を構成する要素であるため「他に影響を与える要素」です。サーバであれば物理から仮想に変わっても、影響を受けるのはそのサーバ自身と、そのサーバとの通信を行うシステムやユーザに限られますが、ネットワークは点と点をつなぎ合わせる線の集合としての面、ですのでサーバ仮想化のようには、単純に物理から引きはがす、ということは容易ではありません。合わせて、本エントリーシリーズのタイトルでもある分散スイッチングや分散ルーティングなどの技術も、整合性を確保するためには基本的には対象範囲のネットワーク全体が集中管理されているからこそ実現できる方式といえます。
ネットワークの目的は点と点を結びつけること、ですが、現在ではそこに様々な要素が複雑に介在しています。セキュリティ、パフォーマンス、暗号化、ロードバランシング、最適化、帯域制御、等々…。ネットワークの集中管理は、柔軟性や拡張性といった大きなメリットを得ることができますが、単純な「点と点を結びつける」ネットワークならまだしも、これらの様々な要素が結びついたネットワークを集中管理したいと考えるのであれば、必要としている要素はどのように組み込むことができるのか、きちんと押さえていく必要があります。置き換える手法はあるかもしれませんが、それに伴って利便性が向上するなどのメリットが生まれるのかどうかも重要な考慮点です。
究極的には、ユーザにとって、さらにはビジネスにとって価値がある、利便性が向上する、課題が解決する、それらの目的のために、メリットを提供することができるネットワークの集中管理とはどういう方式なのか。コストパフォーマンスはどの程度なのか。その方式にすることによるデメリットはどういう部分で、それは許容できたり、妥協できるものなのか。技術の進歩は日進月歩であり、今、解決できていない問題であっても、近い将来、それを解決する技術が登場するかもしれません。選択肢は数多く、どうしても決断が必要な部分はいつであっても出てくるでしょうが、軸とする目的の部分だけはぶれることのない判断が必要でしょう。
サービス化していくITリソース
ネットワークを集中管理するやり方には様々な方式があり、OpenFlowとEthernet Fabricなんかは対極にあるような気もしてしまうのですが、意外と目指している方向性は似たような感じで、使い分けというか、融合というか、次第に実用的で現実的？な仕様と実装に終着しつつあるように思えます。管理手法としても、GUIの見た目や操作性などに注目が向くのですが、CLIの使い勝手やトラブルシュート性、Scriptingのためのインターフェイスやバリエーション、そしてなんといってもAPIのオープン性など、総合的な管理性を持っていることがより重要になっていくでしょう。
ITインフラを構成する要素としては、ざっくり分類するとOS/Hypervisor、サーバ、ネットワーク、ストレージといった感じに分類できるかと思いますが、これらの中で、ネットワークはCLIに最適化されすぎていたが故に、GUIやAPIなどといった他のインターフェイスへの対応が遅れていたのかもしれません。しかし、ここ数年で急速にネットワークは集中管理への対応と合わせて、それらへの対応が急速に充実しつつあります。API制御されたネットワークがどのような使われ方をするようになるのか、その下準備が急速に進んだ2013年から、その使われ方が次第に明確になっていくであろう2014年へと、まだまだネットワークまわりは興味深い動きが続くことになるでしょう。
正直、これまでのPrivate Cloudは、Public Cloudの後追いというか、ぶっちゃけ劣化コピーのような感じがあったような気がします。しかし、ITインフラリソースを所有しない・管理しないということから得られるメリットに対して、ITインフラを所有し管理することによって得られる自身のために最適化されたITリソースのメリットはもっとあってよいと思います。
PublicにしろPrivateにしろ、ITリソースはよりサービス化することが求められるようになっていくでしょう。新しいネットワークのカタチが、どのような使われ方をされるようになっていくのか。楽しみですね。
The tomorrow's entry of vExpert Advent Calendar return to @interto .
Merry Christmas!! & A Happy New Year!!
今年も1年間、ありがとうございましした。来年も、よろしくお願いします。
