プライベートクラウド時代のネットワーク機器
仮想化基盤のネットワーク配線をシンプルにするIBMの技術
2011/10/19
サーバを仮想化し、巨大なラックに統合するのが現在の流行だ。しかし、サーバを仮想化するときはIPとストレージの配線をいかに簡単にするかが重要なポイントになる。この課題を解決する技術について日本IBMの担当者に聞いた。
サーバ仮想化とサーバ統合の需要に応える製品
日本IBMは2011年8月17日、プライベートクラウド基盤となるハードウェアをセットにした製品「IBM BladeCenter Foundation for Cloud」を発表した。サーバ仮想化とサーバ統合の需要に応え、各種クラウド管理ソフトウェアと組み合わせることでプライベートクラウドの基盤として活用できる製品だ。
セットを構成する主要な要素は、「IBM BladeCenter H」のシャーシに、ブレードサーバ「BladeCenter HS22/HS22V/HX5」のいずれか。さらにストレージ機器、これらの機器を接続するネットワーク機器。デフォルトではヴイエムウェアの「VMware ESXi」が導入された形で出荷されるが、カスタマイズ次第で日本マイクロソフトの「Hyper-V」、オープンソースの「KVM」といった仮想化ソフトを導入し、仮想化基盤を迅速に構築することができるようになっている。
しかし、サーバの仮想化とサーバ統合が進むと、ネットワークをどう構成するかという問題にぶち当たる。サーバ同士はイーサネット、ストレージにはファイバチャネルと、それぞれ別々に配線していたのでは、ラックの中の配線は混迷を極め、ネットワークの管理はかなり面倒になるだろう。
IBM BladeCenter Foundation for Cloudの主要コンポーネントであるBladeCenterは、この問題に対処するために、「IBM BladeCenter Open Fabric」という技術を導入している。この技術について日本IBM システム製品事業 システムx事業部でテクニカル・セールスを務める坂巻宏亮氏(写真1)に聞いた。
アドレスの設定法を工夫して運用負荷を激減
IBM BladeCenter Open Fabricを構成する要素は4つ。1つ目は「IBM BladeCenter Open Fabric Manager」。BladeCenterのシャーシが備えるサーバベイ(ブレードサーバの差し込み口)に、任意のMACアドレスとWorld Wide Name(WWN:ファイバチャネルのポート1つに必ず付くアドレス。基本的に世界中で重複することはない)を設定しておけるのだ。
これは、ブレードサーバに障害が発生したときの対応を容易にするための機能だ。例えば、サーバベイにMACアドレスとWWNを割り振る機能がないと、障害 が発生しサーバを入れ替えた際に、新しいサーバが持つMACアドレスとWWNで通信することになり、MACアドレスやWWNが変わってしまう。MACアドレスが変わると、IPアドレスとMACアドレスの対応を書き換えなければならないので、しばらくの間正常に通信できなくなる。さらに、WWNが変わると、ストレージ機器の設定を変えなければ、通信ができなくなるのだ。
ところが、サーバではなくサーバベイにアドレスを設定するようにしておけば、障害が発生して、シャーシ内のブレードサーバが停止したとき、同じ仕様のブレードサーバを用意して差し替えるだけでよいのだ。
止めにくいサービスを動かしているときに、障害が発生した原因を追究している暇はない。とにかく動く状態にして、その後で原因を追及するという体制を取れるのだ。
ほかの使い方もできる。現在使用していないサーバベイにMACアドレスやWWNをあらかじめ設定しておくと、ブレードサーバを追加したときに、ストレージの設定をしなくてもすぐに稼働できる。
さらに、バックアップサーバを1台決めておけば、ブレードサーバが故障したときに、そのバックアップサーバが自動的にMACアドレスとWWNを引き継いで動作する。こうしておけば、トラブル発生時に対応できるエンジニアがいなくても、事実上サーバが止まることはない。例えば、深夜、誰もが寝静まったときにトラブルが発生しても、エンジニアをたたき起こす必要はないのだ。
この機能は、IBM BladeCenter Hのシャーシが内蔵する「Advanced Management Module」という監視機器によって実現している。専用のスイッチが不要でどのベンダのスイッチを、IBM BladeCenter Hに接続しても、BladeCenter Open Fabric Managerの機能は問題なく使えるという。
高速な通信路を仮想的に分割
2つ目の要素は「Virtual Fabric Adapter/vNIC」だ。これは、「Emulex Virtual Fabric adapter II」というCNA(Converged Network Adapter)にも対応しているネットワークインターフェイスアダプタと、IBMが買収したBLADE Network Technologies(BNT)のスイッチの機能を利用したものだ。
普通のサーバの場合、IP通信用のイーサネットインターフェイスを複数備え、その上、ストレージへの接続のためにファイバチャネルのインターフェイスがあるので、正確に配線するには、接続先によく気を付けなければならない上、スイッチの端子も多く消費する。さらに、ファイバチャネルの配線までしなければならない。
CNAは、10Gbit/秒のイーサネットインターフェイスを2つ備えている。そして、それぞれのインターフェイスの通信帯域を分割して、仮想的な通信路を複数作れるのだ(図1)。例えば、大量のデータが通る通信路として5Gbit/秒の仮想的な通信路を作り、簡単な管理用通信に使う通信路として100Mbit/秒の仮想的な通信路を作れるのだ。
それぞれの通信帯域は100Mbit/秒単位で設定可能。コマンドで設定する一般的なスイッチとは異なり、帯域幅の設定はGUIのツールで簡単に設定できるという。そして、帯域の設定は時間によって変えることができる。夜間には、バッチ処理に必要な通信路の帯域を広げ、営業時間中はオンライン処理に必要な通信路の帯域を広げるという使い方も可能だ。
この技術を使えば、サーバ1台当たりに最大で8本の仮想的な通信路を設定できる。しかし、通信に必要な物理的なケーブルは2本で済む。スイッチのインターフェイスを浪費せずに、何種類もの異なる性質の通信を流せるのだ。当然、配線も簡単になる。
セキュリティ対策も万全だ。それぞれの仮想的な通信路が干渉することはなく、同じケーブルを通っている、仮想的に別々の通信路の間でデータが漏えいすることはない。
仮想サーバが物理サーバの壁を越えたときはどうする
3つ目の要素は「VMready」だ。仮想サーバを運用していると、トラブルが発生して、仮想サーバが物理サーバの壁を越えて移動して、稼働を続けることがある。ヴィエムウェアの「vMotion」や「VMware HA」が備える機能である。物理的サーバにかかる負荷などを考えて、仮想サーバを別の物理サーバに移動させられるのは便利なことだが、この機能を使うことを前提にネットワークを構築することは簡単ではない。
物理サーバが2台あり、そのうち1台で仮想サーバを2つ動作させる場合、一般には図2のようにネットワークを構成する。仮想サーバA、Bがつながっているスイッチには、仮想サーバC情報も記載する必要があり、仮想サーバCがつながっているスイッチには、仮想サーバA、Bの情報も設定しなければならない。
これは、仮想サーバが物理的サーバの壁を乗り越えて移動しても、動作し続けるようにするための設定だ。しかしこのように設定すると、パケットを不必要にあちこち移動させることになりかねない。
そこで、BNTの「Nmotion」機能を備えるスイッチを使うと、不必要な情報を設定する必要がなくなる(図3)。スイッチには、関係する仮想サーバの情報だけを記載すればよい。仮想サーバが別の物理サーバに移動したら、スイッチが移動した仮想サーバのMACアドレスを検知し、関係するスイッチに情報を移動させるのだ。
すべての通信をイーサネットに統合
さらに、IBM BladeCenter Foundation for Cloudではサーバに関係する通信プロトコルをすべてイーサネットに統合して、ネットワーク配線をシンプルにしている。ストレージとの通信に使うファイバチャネルをFCoE(ファイバチャネル over イーサネット)とし、ストレージとの通信、サーバ同士の通信、インターネットへの通信すべてにイーサネットを使うようにし、専用のスイッチでストレージ向け通信とLAN、インターネット向け通信をスイッチングするようにしている。
これは、Virtual Fabric Adapter/vNICにも関係する機能だ。合計20Gbit/秒の高速な通信路を仮想的に複数の通信路に分割する技術を利用して、ストレージ通信をイーサネットに通しているのだ。
このように、すべての通信をイーサネットに統合することで、サーバにつながるケーブルがイーサネットケーブルだけになり、すっきりして扱いやすくなる。例えば、さらにファイバチャネルのケーブルが走り回ると、正確に配線することも難しくなるだろう。
そして、ネットワーク経路の途中に対応スイッチを配置しておけば、IPトラフィックとファイバチャネルのトラフィックを分割することができる。例えば、ストレージのそばにスイッチを置いておけば、ファイバチャネルのトラフィックだけを選んでストレージに流せる。その結果、配線の本数やスイッチの台数を削減できる。
他ベンダの機器との相互接続性にも優れる
ここまで説明してきたIBM BladeCenter Open Fabricの機能は、一部BNTのスイッチを必要とするものもあるが、基本的にはほかの主要ネットワーク機器ベンダの製品との相互接続性を確保してある。同社は、顧客がすでに持つデータセンタ環境をすべて入れ替えることを勧めることはない。すでにあるネットワーク機器とうまく接続することを目指しているという。
関連リンク
- IBM BladeCenter Foundation for Cloud
- IBM BladeCenter Open Fabric Manager
- BNT(BLADE Network Technologies)スイッチ・モジュール
関連記事
提供:日本アイ・ビー・エム株式会社
アイティメディア営業企画/制作:@IT 編集部
掲載内容有効期限:2011年11月18日