サーバ仮想化技術の普及に伴い、これまで企業内の各システムにおいて別々のハードウェアとして動作させていたサーバ群を一つの物理サーバ上に統合するサーバ統合が当たり前になりつつあります。サーバ仮想化は企業内のシステムに以下の恩恵をもたらしました。

1. 物理サーバ集約によるコスト削減

2. リソースの有効活用

3. 迅速で柔軟な構成変更

図 1　従来のシステムのネットワーク構成（サーバ仮想化統合まで導入済み）

企業内のシステム単位での基盤インフラの最適化だけに留まらず、企業内の複数システムでハードウェアを共有するマルチテナント型の基盤インフラとしてプライベートクラウドを構築する事例が増えています。物理サーバをコンピュートリソースプール（CPU、メモリ、ディスク）として扱い、その一部を仮想サーバとして各システムに割り当てると同時に、ネットワーク機器で構成される物理ネットワークを論理的に分離されたネットワーク（論理ネットワーク）として各システムに割り当てます。論理ネットワークに各システムが必要とする数だけのネットワークセグメントが用意されて、各ネットワークセグメントに対して仮想サーバ（時として物理サーバも）が接続されるだけでなく、ファイアウォールや負荷分散といったネットワークサービスが必要に応じて接続されます。

図 2　マルチテナント型のプライベートクラウド

 

このようにマルチテナントに対応するクラウド型のネットワーク基盤では、以下の要件が求められます。

1. 物理から分離された論理ネットワーク
ハードウェア構成を変更せずに、各システムが必要とするネットワークサービスを自由に組み合わせ可能なこと

2. ライブマイグレーション対応
仮想サーバがどのホスト上で起動されても同一のネットワークに接続されること

3. 運用自動化
ネットワーク構成に必要な設定をネットワーク機器に自動的に反映可能

4. 帯域の有効活用
全ての通信路を有効に利用したルーティング制御

 

課題1. VLANによるID数とネットワーク構成の制約

 

ネットワークのハードウェア構成を変更せず、複数のネットワークに分割する既存技術としてVLAN（Virtual LAN）があります。Virtual Routing and Forwardingに対応したL3スイッチ、マルチインスタンスに対応したファイアウォール・ロードバランサとVLANを紐付けることで、システム単位に独立した仮想的なネットワークが実現できます。ただし、VLANには割り当てられるIDの数に上限があり4094個のセグメントまでしか作成できず、特にデータセンタや大規模な企業内インフラなどにおいて大きな課題となります。しかも、スイッチの機種によっては250までのVLAN IDしか使用できないという制約や、1つのシステムで1個のVLAN IDを消費するわけでなく、4～5個のVLAN IDを消費することが一般的なこともあり、統合できるテナント数は4094よりも少なくなります。
また、VLANで分割した場合、ネットワークを共有する全てのシステムにおいて経由するネットワーク機器構成を統一させる必要があります。そのため、ネットワークサービスとしてロードバランサを必要としないシステムが存在する場合でも、ネットワーク経路としてロードバランサを経由する形で実装する必要があります。ネットワークの論理設計上はロードバランサが存在しないにも関わらず、実際はロードバランサを経由していることから想定外の通信上の制約などが生じる可能性があります。

図 3　マルチテナントに対応可能なネットワーク

 

 

課題2. 仮想サーバのマイグレーションとポートプロファイルの追従

 

サーバ仮想化におけるマイグレーション技術を使用することで、サービスをオンラインとしたままで他の物理サーバ上に仮想マシンを移動できます。ただし、仮想マシンをマイグレーションできる条件として、移動先と移動元のネットワークが同じセグメントに属する必要があります。そのため、スイッチのポートに紐付いているVLANやアクセス制御などの設定を仮想マシンの移動に併せて、動的にハイパーバイザ上の仮想スイッチやホストが接続する物理スイッチの設定を更新する必要があります。仮想スイッチはハイパーバイザが提供する機能により自動的に更新できる場合が多いですが、物理スイッチに関しては手動で設定を更新する必要が生じる場合があります。

図 4　仮想マシンのマイグレーション技術に対応可能なネットワーク

 

 

課題3. ネットワークコンフィグレーションの一元管理

 

仮想マシンの移動だけでなく、ビジネス変化に応じて迅速にリソースを変動させてクラウドのメリットを享受する上でも、物理スイッチに対して自動的に設定を反映する仕組みが必要です。しかしながら、VLANという標準化された技術であってもヘッダー構造のみが規定されており、スイッチに対してVLANを設定するためのインタフェースは規定されておりません。そのため、TELNETやSSHでログインしてコマンドを発行する、SNMPやNETCONFといったプロトコルでセットするという方法がありますが、現状ではいずれもベンダ独自のコマンドやデータ構造に依存する可能性があり、複数のベンダ機器で構成される環境における設定の自動化の実現はかなり難しい状況といえます。

図 5　ネットワーク機器の運用自動化

 

 

課題4. システム統合によるネットワーク帯域のスケーラビリティ

 

複数のシステムを統合した場合、同一の物理リンク上に各システムの通信が混在して流れます。外部のネットワークからシステムに流入するNorth-Southトラフィックよりも、サーバとサーバ間・ハイパーバイザとストレージ間のEast-Westトラフィックがシステム内の大半を占めることから、レイヤ2ネットワークとして利用できる帯域は高い拡張性が求められます。そのため、全ての物理リンクにトラフィックを振り分けて無駄なく利用するECMP（Equal Cost Multi Path）などのトラフィック制御が求められますが、従来のSTP（Spanning Tree Protocol）では、トラフィックのループを回避するためにブロッキングポートが定義されることから一部の物理リンクのみしか利用できない課題があります。

図 6　マルチテナントにおける帯域の有効活用

 

その他にも既存のネットワーク技術の課題は色々とあります。「プライベートクラウド管理のすゝめ② - 其の壱」へ。

 

 

クラウド時代に求められるネットワークを実現する上での課題を挙げてきましたが、これらの課題を解決するネットワーク技術が登場しています。VLAN IDの上限数の課題に対してはVXLAN（Virtual eXtensible LAN）やNVGRE（Network Virtualization using Generic Routing Encapsulation）、仮想マシンのマイグレーションへのスイッチのポート設定の追従に対してはEVB（Edge Virtual Bridging）、全ての物理リンクの有効活用に対してはTRILL（TRansparent Interconnection of Lots of Links）やSPB（Shortest Path Bridging）といった多様な技術が実用化されつつあります。これらの技術は主に既存技術の拡張による解決策である一方で、異なる視点から期待されているもう一つの解決策としてOpenFlowが認知されつつあります。

表 1. ネットワークの課題と解決策

クラウド時代に求められる ネットワーク要件	VLANベース	OpenFlowベース
物理から分離された 論理ネットワーク	VLAN / VXLAN / NVGRE / STT + 仮想アプライアンス	OpenFlow + 仮想アプライアンス
ライブマイグレーション対応	EVB
運用自動化	バーチャルシャーシ + 仮想アプライアンス
帯域の有効活用	TRILL / SPB / MC-LAG

OpenFlowに関する詳細な技術情報は「SDN/OpenFlow技術紹介」へ。

 

 

クラウド時代に求められるネットワーク要件はVLANベースとOpenFlowベースのいずれでも満たすことができます。ただし、違いとしてはネットワーク機器の制御方法が標準化されているか否かという点が挙げられます。
VLANベースでは外部からネットワーク機器を制御する方法は標準化されておらず、一般的に各ネットワーク機器ベンダが提供するソフトウェアからのみ制御できます。
一方で、OpenFlowベースではネットワーク機器を制御するためのインタフェースが標準化されているため、機器ベンダ以外の開発したソフトウェアから制御できます。そのため、複数のベンダのOpenFlowスイッチを混在させたネットワークを構成した場合でも、単一のソフトウェアから一元的に制御することも可能となり、ベンダーロックインの回避にも有効です。
また、OpenFlowベースの場合、ファイアウォールやロードバランサといったネットワークサービスをOpenFlowの高度な活用により再現することも可能です。しかしながら、OpenFlowコントローラとの通信が必要なことから従来のアプライアンス製品のように非常に高いスループット性能を満たす技術としてはあまり考慮されていないため、それらのネットワークサービス機能を実装した仮想アプライアンス製品やハードウェアアプライアンス製品と一緒に活用する必要があります。仮想マシンのように管理可能な仮想アプライアンス製品によってネットワークサービスをプール化して利用する、あるいは既存のハードウェアアプライアンス製品を一部のシステムに利活用することも可能となり、他のシステムのネットワーク構成を意識することなく、システムごとに自由なサービスを組み合わせたネットワークを構成できます。

集中管理・分散制御を実現する理想的なネットワークとOpenFlowの関連性に関する詳しい情報は「プライベートクラウド管理のすゝめ② - 其の弐」がオススメ。

 

Hinemosのオプション製品である「Hinemos仮想ネットワーク管理オプション」を活用することで、以下に記載するクラウド時代のネットワーク運用管理を実現します。

図 7　Hinemos仮想ネットワーク管理オプションの動作イメージ

 

1. シンプルな集中制御（運用自動化）

OpenFlowスイッチで構成されたネットワークトポロジをOpenFlowコントローラが自動的に検出して、そのトポロジに最適な経路設定がOpenFlowコントローラから各OpenFlowスイッチに一元的かつ自動的に配布されます。ネットワークトポロジの構成や各OpenFlowスイッチの設定情報は単一のコンソールから管理でき、従来のネットワーク機器のように各スイッチにログインしてコマンドを実行する必要はありません。

ネットワークの運用簡素化・高可用性・障害復旧性に関する詳しい情報は「プライベートクラウド管理のすゝめ② - 其の参」がオススメ。

2. 容易なスケールアウト（帯域の有効活用）

ネットワーク帯域が不足した場合、OpenFlowスイッチ間の物理リンクの本数を増やすだけです。物理リンクの本数を増やすことで生まれた新たな経路をOpenFlowコントローラが自動的に検知し、新たな経路に対してトラフィックを分散します。従来のネットワークのように、各スイッチに対してリンク・アグリゲーションの設定を行う必要はなく、スパニングツリーのようにネットワークのループを考える必要もありません。

ネットワーク性能と効率性の向上に関する詳しい情報は「プライベートクラウド管理のすゝめ② - 其の参」がオススメ。

3. 多様なネットワークの仮想化統合（物理から分離された論理ネットワーク）

異なるネットワークサービスで構成される複数のシステムを統合できます。同一のネットワークセグメント内でのパケット転送、あるいは異なるネットワークセグメント間のルーティング制御などを共有した物理スイッチで実現しつつ、システムごとに論理ネットワークとして分割（スライシング）できます。論理ネットワーク内には経由点として物理サーバ・仮想サーバ・ハードウェアアプライアンス・仮想アプライアンス・ストレージ装置などを自由に設けられ、各システムが必要とするネットワークサービスを特に制約なく組み込めます。単一のコンソールからシンプルなGUI操作で設定された論理ネットワークの構成をに基づき、OpenFlowコントローラがトラフィックの転送経路は自動的に設定されることから、各システムのネットワーク管理者はネットワークサービスの設定だけに専念できます。

ネットワークの迅速なプロビジョニングに関する詳しい情報は「プライベートクラウド管理のすゝめ② - 其の参」および「プライベートクラウド管理のすゝめ③ - 其の壱」がオススメ。

4. 動的に変化する接続機器への対応（ライブマイグレーション対応）

OpenFlowスイッチに接続される各機器のリンク状態変化をOpenFlowコントローラは自動的に検知します。仮想マシンのライブマイグレーションのようにポートのリンク状態が変化すると、OpenFlowコントローラは各OpenFlowスイッチの経路設定を新たな構成に基づいた最適な経路に書き換えます。

ネットワーク周辺機器との協調性に関する詳しい情報は「プライベートクラウド管理のすゝめ② - 其の参」がオススメ。

5. サーバ仮想化技術と連動したオーケストレーション（運用自動化）

プライベートクラウドなどで普及している多様なハイパーバイザと連携して、各システムの論理ネットワークに接続される仮想マシンをテンプレートからプロビジョニングできます。この制御は論理ネットワークの新規生成や構成変更と連動して行えることから、サーバとネットワークが共に仮想化された環境を一元的に管理できます。また、各システム内に仮想マシンとしてオープンソースソフトウェアであるHinemosマネージャを設けることにより、ライセンスを気にせずにシステムの仮想化統合および仮想化されたシステムの運用管理を実現できます。

Software-Defined Infrastructureの実現に関する詳しい情報は「プライベートクラウド管理のすゝめ③ - 其の弐」がオススメ。

 

対応済みOpenFlowバージョン

Hinemos仮想ネットワーク管理オプションが対応しているOpenFlowバージョンを記載します。

表 2. 対応済みOpenFlowバージョン一覧

OpenFlowバージョン	対応状況
1.0	○
1.1 ～ 1.4	×

動作検証済みのOpenFlowスイッチ

Hinemos仮想ネットワーク管理オプションが対応しているOpenFlowスイッチを記載します。

表 3. 対応済みハードウェアOpenFlowスイッチ一覧

提供元	製品名
エヌ・シー・エル・コミュニケーション株式会社	Pica8 P-3290/P-3295/P-3295R/ P-3297/P-3297R/P-3780/ P-3920/P-3922/P-3930/P-3930R
日本アイ・ビー・エム株式会社	IBM System Networking G8264
日本電気株式会社	UNIVERGE PF5220
日本ヒューレット・パッカード株式会社	HP 3800-24G-2SFP+ Switch (J9575A)

表 4. 対応済みソフトウェアOpenFlowスイッチ一覧

提供元	製品名
シトリックス・システムズ・ジャパン株式会社	XenServer 6.0/6.1/6.2 (Open vSwitch)

対応済みハイパーバイザ

Hinemos仮想ネットワーク管理オプションが対応しているハイパーバイザを記載します。

表 5. 対応済みハイパーバイザ一覧

提供元	製品名
米ヴイエムウェア	vSphere 5.5 (vCenter Server, vSphere ESXi)
レッドハット株式会社	Red Hat Enterprise Linux 6 KVM
シトリックス・システムズ・ジャパン株式会社	XenServer 6.0/6.1/6.2 (Open vSwitch)

プライベートクラウド管理のすゝめ①　基本編　（公開日 : 2014/06/23）

プライベートクラウド管理のすゝめ②　ネットワーク管理者編 - 其の壱 (公開日 : 2014/07/08)

プライベートクラウド管理のすゝめ②　ネットワーク管理者編 - 其の弐 (公開日 : 2014/07/08)

プライベートクラウド管理のすゝめ②　ネットワーク管理者編 - 其の参 (公開日 : 2014/07/08)

プライベートクラウド管理のすゝめ③　応用編 - 其の壱 (公開日 : 2014/08/06)

プライベートクラウド管理のすゝめ③　応用編 - 其の弐 (公開日 : 2014/08/06)

SDN/OpenFlow技術紹介

 

Hinemos仮想ネットワーク管理オプション

Hinemos VM管理オプション

Himemosクラウド管理オプション

Hinemos各種オプション製品リーフレット

書籍「翔泳社　OpenFlow徹底入門　SDNを実現する技術と知識」（外部リンク）

書籍：Hinemos統合管理[実践]入門

準備中

お問い合わせへ