連載:クラウド基盤とネットワーク【第1回】
VMware環境の仮想スイッチはどう進化してきたか
サーバ仮想化が大規模化し、クラウドに進化すると、それに応じたネットワーク機能が求められるようになってくる。今回は仮想化基盤として最も普及しているVMwareの仮想スイッチの進化を考える。
サーバ仮想化技術によって、多くの企業がコンピューティングリソースの統合を進めている。現在では、サーバ仮想化の段階からプライベートクラウドの段階へとステップアップを図っている企業や、既にプライベートクラウドを構成してサービスを提供している企業も数多く存在している。
クラウド基盤では、仮想マシンが非常に簡単に作成できる。しかし、この迅速に生成された仮想マシンに対して、適切なネットワークアクセスを即座に設定することは難しい。この点に課題を持つ企業は多く、これに対応する新たな技術や製品が登場している。
このような背景を踏まえ、本連載では、「クラウド基盤のネットワーキング機能」について解説する。最初に、VMwareを中心とした爆発的なクラウドの浸透に対して、クラウドネットワークがどのような変化を遂げてきたか、 「vSphere Standard Switch」、 「vSphere Distributed Switch」(vDS)といった技術を振り返る。そして、今後主流になるであろう「VXLAN」(Virtual Extensible Local Area Network)や、新しいクラウドネットワーク技術の登場背景や機能を紹介し、その仕組みや課題もあわせて解説していく。
プライベートクラウド基盤に求められるネットワーク要件
まず、プライベートクラウド基盤に求められるネットワーク要件と、それに対応する技術を紹介する。
サーバ仮想化技術によって、サーバは物理サーバ上で仮想マシンの形態で稼働することになる。この段階でのネットワークの最低要件は、「物理ネットワークから特定の仮想マシンにアクセスできること」、そして、「異なる物理サーバに存在する仮想マシン間でアクセスできること」だ。
この要件への対応は、ハイパーバイザーの内部にVLANタグ(802.1q) を認識する仮想的なスイッチを導入し、各仮想マシンのMACアドレスを、VMware ESXが接続された物理スイッチが学習することで実現した。
最低限の動作だけなら、この程度の仮想ネットワーク機能でも問題ないのだが、物理ネットワークが実装している機能と比較すると、非常に大きな差がある。
このギャップを埋めるために、vSphere vDSや、シスコシステムズが開発・販売する「Cisco Nexus 1000V」 などのサードパーティーの仮想スイッチが登場してきた。さらに、仮想マシン間の通信を物理スイッチ経由の通信へと変更可能な「Cisco VM-FEX」(Virtual Machine Fabric Extender) などの機能の登場によって、物理スイッチ機能の有効利用と仮想マシン間の通信の可視化も実現している。
サーバ仮想化の次の段階であるプライベートクラウドでは、さらに以下のようなさまざまな要件が存在し、ネットワークリソースに関してもこれらを満たす必要がある。
- 迅速にリソースアクセスを提供するための仕組み
- 異なる組織グループを同一基盤で稼働させるためのアクセス制御
- ユーザーが利用したいときに、すぐにリソースを使用可能とするセルフサービス
- 膨大に増え続ける仮想マシンの数への対応
- 仮想マシンのライブマイグレーションにおけるサービス継続
では、具体的にVMware vSphereに実装されているvSSやvDS、サードパーティーのスイッチにどのような特徴があるのかを、順に紹介しながら解説していく。
仮想スイッチの特徴と差異
vSS(vNetwork Standard Switch:標準スイッチ)
VMware vSphereで構成される最も標準的なスイッチ機能が、vSSだ。vSSは各ESXiホストに対して、"仮想スイッチ"と“「ポートグループ」 を作成することで、仮想ネットワークと物理ネットワークをひも付けることができる。また、全てのESXiホスト内に同じ名前のポートグループを作成しておくことで、これら複数のホスト(物理サーバ)にまたがるライブマイグレーションを実施できる。ESXi上に複数のネットワークインタフェースを保持することにより、これらを冗長化する機能も実装されている。
しかし、多数のポートグループをESX全てに対して設定する必要があるため、ESXiの台数増加に伴い、作業工数が非常に大きくなるというvSSの課題が露見してきた。
vSphere vDS(vNetwork Distributed Switch:分散仮想スイッチ)
vSSの課題を踏まえて登場した技術がvDSである。vDSは、「VMware vCenter」によって複数のESXiをまたがる仮想的な単一のスイッチを構成することが可能だ。これによって、vCenterから単一のポートグループを作成することで、全てのESXに対して同一のポートグループへの通信を提供することが可能になった。
Cisco Nexus 1000V
最近ではvDSと比較して主だった機能差がなくなりつつあるが、依然としてCisco Nexus 1000V独自のメリットもまだ多く存在する。
例えば、CBWFQ(Class-Based Weighted Fair Queueing)のようなQoSや、ACL(Access Control List)およびDHCP snoopingのようなセキュリティ機能は、vDSではまだ提供されていない。また、LACP(Link Aggregation Control Protocol)は標準化されている技術ではあるが、同じシスコのスイッチ間で使用した方が相性は良い。さらに、vPathのようなCisco Nexus 1000Vと仮想マシン間の通信を制御できる機能を使い、仮想スイッチとファイアウォールなどの仮想アプライアンスを連携することもできる。また、ネットワークエンジニアが、仮想スイッチの設定がCisco CLIで行えるため、ネットワークエンジニアが物理から仮想までのネットワークを管理できる点も優位点といえるだろう。
Cisco Nexus 1000Vは、ESXi以外にも、Hyper-VやKVMなど、複数のハイパーバイザーへの対応を進めている。
プライベートクラウド基盤における物理スイッチ
これまで仮想スイッチに関して解説してきたが、仮想スイッチと物理スイッチとの接続方法も「プライベートクラウド基盤に求められるネットワーク要件」においては重要である。
キャンパスネットワークでは、スイッチのスタック接続で複数のスイッチを1台のように見せる技術は以前からあったが、データセンタースイッチにおいても同様の機能を実現する技術として、シスコのvPC(Virtual Port Channel)、ブロケードのvLAG(Virtual Link Aggregation Group)などが登場している。これらの機能によって、実際には複数の物理スイッチがあっても、vSSやvDSからは1台のスイッチとポートチャネルを接続しているように見えるため、可用性が高くなる。
また、仮想化環境ではレイヤー2のネットワークを構築する必要があるため、以前からあるSTP(Spanning Tree Protocol)を使用してネットワークを構築すると、ループ防止のためブロッキングボートが作成され、帯域が無駄になってしまう。また、STPを使用していると、仮想マシン間の通信がSTPのトポロジーに依存してしまうことから、最適経路が実現できない。
これらの問題を解決するために、TRILLという技術の標準化作業が進行中である。既にこのTRILLをベースとした各ベンダー独自の技術であるCisco FabricPath、Brocade VCS(Virtual Cluster Switching)などが、データセンタースイッチに実装されている。これらの技術を使用することで、先に挙げていた問題の解決のみだけではなく、レイヤー2網内でロードバランスも可能になっている。
今回は、プライベートクラウド基盤に求められるネットワークを、仮想スイッチの側面から解説した。次回は大規模なクラウド基盤における要件を整理しつつ、そこで浮き彫りになるネットワークの課題を紹介する。それによって、新しいクラウドネットワーク技術の登場背景が浮き彫りになってくる。
Copyright © ITmedia, Inc. All Rights Reserved.
連載:クラウド基盤とネットワーク
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用 -
技術文書・技術解説
[NTTインテグレーション株式会社] 「耐量子計算機暗号」(PQC)に今、取り組むべき理由とは? 実現の道筋も解説 -
製品資料
[株式会社リンプレス] どうしたら非デジタル人材を「自走するDX推進者」に変えられるのか? -
製品資料
[アステリア株式会社] 既存システムをAIレディに変える「連携型モダナイゼーション」の手法とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
3
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
4
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
5
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
OpenAIやAnthropicでさえ制御不能 2026年夏「3大サイバー攻撃」の衝撃
-
8
「アップグレードできないJava」をどう守る IBMとRed HatがAIで400件超修正
-
9
生成AIが普及しても「技術書」を手放せないエンジニアの本音
-
10
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
3
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
4
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
5
「IT史に名を残すシステム障害」8選
-
6
SASE選定は「見極め力」で大きな差――本当に必要な製品を選ぶための6つの視点
-
7
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
8
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
9
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
10
「標的型攻撃メール」事例・サンプル集
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー