［ネットワーク編］仮想ネットワークを物理ネットワークと同じに考えてはいけない

　最近は仮想化技術の普及がめざましく，仮想マシンと仮想マシンの間，もしくは仮想マシンと物理マシンの間に仮想スイッチが介在するようなネットワークが増えている。もちろん，仮想マシン自体のネットワーク・インタフェース・カード（NIC）も仮想化されている。しかし，仮想化されたスイッチやNICで構成するネットワークでは気を付けることが多い。仮想ネットワークを物理ネットワークと同じに考えてはいけないのである。

物理ネットワークと接合するセグメントを広範囲にしてはいけない

　仮想スイッチや仮想NICの動作に関するトラブルは，基本的にL2（レイヤー2）レベルの現象である。対策としては，セグメントを分けることが基本になる。仮想スイッチの動作に起因する具体的なトラブルの例をもとに説明しよう。

　この環境では，フラッディングという通信の増大によって，広域イーネット網のネットワーク性能が著しく低下するという現象が発生していた（図1）。詳しくは後で説明するが，原因は仮想化したサーバーとの通信だった。本来は物理ネットワークを通過する必要のない通信であり，不用意に広域イーサネット網へ流れないはずだった。それが実際には物理ネットワークに流出した結果，L2スイッチでフラッディングを引き起こし，通信量を増大させていたのである。

図1●仮想化に起因する具体的なトラブルの例

　問題となったサーバーを詳しく調べると，仮想化した環境に特有の現象だった。このサーバーでは，1台の物理マシン上に仮想化ソフトを用いて仮想マシンを構築していた。物理マシン（ホストOS）上のアプリケーションと，仮想マシン（ゲストOS）上のアプリケーションが双方向の通信を行っている。また，サーバーの物理NICは外部のL2スイッチにつながっていた。

　この環境では，ゲストOSからホストOSへ向かう通信は，仮想化ソフトで作られた仮想NICを利用して行われる。ゲストOSからホストOSへ向かうイーサネット・フレームは，仮想的なネットワークの中で閉じた通信になり，外部のL2スイッチへは流れない。

　一方で，ホストOSからゲストOSへ向かう通信は，物理NICを介して行われる。ホストOSからゲストOSへ向かうイーサネット・フレームは，ゲストOSに流れるとともに，物理的なNICを経由してその先に接続されているL2スイッチへ流れる。

　こうした独特の通信によって，外部のL2スイッチは，仮想マシンが利用している仮想NICのMACアドレスを学習できなくなった。その結果，ホストOSからゲストOSへ向かうイーサネット・フレームはL2スイッチに届いた際，すべてのポートへと送信されるフラッディングになる。

　このケースでは不幸なことに外部のL2スイッチが直接広域イーサネット網に接続されていた。そのため，フラッディングが広域イーサネット網にも及んでしまい，ネットワーク性能が著しく低下する事態にまで発展したのだ。

　そもそも，広域イーサネット網などのL2ネットワークでは，ブロードキャストが流れるような接続は，仮想化技術の使用の有無にかかわらず，行ってはいけない。ブロードキャストストームの危険性があるため，必ずルーターなどで終端して，セグメントを分ける必要がある。

仮想NICのMACアドレスを固定にしてはいけない

　次に注意したいのは，MACアドレスの重複である。これは仮想化した環境に多い問題だ。物理NICの場合は一意なMACアドレスをROMに記録しているため，MACアドレスが重複することは基本的にない。ドライバの設定などでMACアドレスを意図的に変更するときに，注意するぐらいだ。

　一方で仮想NICのMACアドレスには，重複のリスクが常にある。仮想マシンの作成/起動のとき，ランダムに生成されたり，任意のMACアドレスを設定することができたりするためだ。特に，一度作成した仮想マシンを複製して別の仮想マシンを作成する場合にMACアドレスが重複しやすい。

　仮想化ソフトの設定でMACアドレスを自動生成する場合は，重複を回避するメカニズムが働き，トラブルに至らないことが多いようだ。しかし，MACアドレスを固定する設定の場合は，同一セグメント上に同一MACアドレスのノードが複数出現する可能性が高い。実際にそうなったら，正常な通信は行えなくなるだろう。

　ここに示した例のように，仮想化環境でのネットワーク構築の歴史は物理環境のネットワークと比べるとまだ浅く，思わぬ地雷が埋まっていることがある。一般的には，万一のことを想定して，影響範囲を極小化するよう，ルーターで仮想化環境と物理環境のセグメントを分けるといった基本的な対策をしておくことが重要である。