連載:クラウド基盤とネットワーク【第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
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー