More Related Content Similar to インタークラウドにおける仮想インフラ構築システムの提案 (20) More from Ryousei Takano (20) インタークラウドにおける仮想インフラ構築システムの提案2. 背景
• インタークラウドへの注⽬目の⾼高まり
– クラウド連携、ハイブリッドクラウドなど
• 新しいIT基盤サービスの登場
– クラウド間での柔軟な資源の融通
– 複数クラウドの資源を組み合わせたサービスの提供
インタークラウド環境における
仮想インフラ構築技術の開発
2
3. 本研究の貢献
• IaaS事業者からの要求に対して、ネットワーク
越しに資源を提供するHaaSサービスモデルの
提案
• HaaS資源管理理システム Iris (Inter-‐‑‒cloud
Resource Integration System)の設計と
プロトタイプ実装
– 既存のCloudStackに変更更を加えることなく、要求に
応じた計算資源提供が可能
– ⼊入れ⼦子型仮想化技術(LXCおよびNested KVM)の
性能評価
3
5. Apache CloudStack
• IaaSクラウド基盤構築・管理理ソフトウェア
– セルフサービス
– マルチテナント
• 国内外に多数の利利⽤用実績
– 例例:北北⼤大アカデミッククラウド、NTT Com Cloudn
• 柔軟なネットワーク構成
– 基本ゾーン
• 全テナントのユーザVMが、フラットな単⼀一ネットワークを
共有(AWSスタイル)
– 拡張ゾーン
• VLANによるネットワーク隔離離が可能
5
6. CloudStackの構成
Management
Web API
Server
Zone 1 Zone 2
Secondary
Storage
Pod 2
Pod 1 Cluster 2
Cluster 1
Computing Computing Computing
Node Node Node
VM VM VM
Primary
Storage
6
8. HaaS: Hardware as a Service
• IaaS利利⽤用者から無尽蔵な資源プールに⾒見見えても、
IaaS事業者の資源は有限
– ピーク需要に対する設備投資は⾮非効率率率
• HaaSはIaaSへ資源を提供するクラウドサービス
SaaS: Software as a Service
PaaS: Platform as a Service
IaaS: Infrastructure as a Service
HaaS: Hardware as a Service
8
10. HaaSサービスモデル
• 計算資源の貸出単位
– 計算ノード
– ポッド:単⼀一のL2ネットワークに接続された計算ノードの集合
• データセンタ間ネットワーク接続
– L2トンネル
– IPルーティング(L3)
モデルa モデルb
貸出単位:計算ノード 貸出単位:ポッド
ネットワーク
DC間ネットワーク:L2 DC間ネットワーク:L2
-‐‑‒ モデルc
DC間
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L3 DC間ネットワーク:L3
貸出単位
10
11. HaaSサービスモデル
モデルa モデルb
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L2 DC間ネットワーク:L2
-‐‑‒ モデルc
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L3 DC間ネットワーク:L3
HaaS
Data
Center
IaaS
Data
Center
Rent
a
Compute
Node
11
12. HaaSサービスモデル
モデルa モデルb
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L2 DC間ネットワーク:L2
-‐‑‒ モデルc
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L3 DC間ネットワーク:L3
HaaS
Data
Center
IaaS
Data
Center
Rent
a
Pod
12
13. HaaSサービスモデル
モデルa モデルb
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L2 DC間ネットワーク:L2
-‐‑‒ モデルc
貸出単位:計算ノード 貸出単位:ポッド
DC間ネットワーク:L3 DC間ネットワーク:L3
HaaS
Data
Center
IaaS
Data
Center
Rent
a
Pod
13
15. HaaSサービスへの要求
• HaaSサービス利利⽤用者(IaaS事業者)
– 既存IaaSシステムとの親和性 ゲートウェイの設置
のみでHaaSと接続
– 設置作業の最⼩小化
三つのサービス
– 資源提供の単位の⾃自由度度
モデルに対応
– 安定したDC間通信
帯域保証技術の利利⽤用
• HaaSサービス提供者(HaaS事業者)
– 制御ネットワークの隠蔽
仮想化技術の利利⽤用
– 複数テナントへの対応
15
16. 資源管理理
• HaaSシステムでは計算機、ネットワーク共に
2段階の仮想化が必要
– 計算機:⼊入れ⼦子型仮想化
– ネットワーク:エッジオーバレイ
HaaS Data Center IaaS Data Center
IaaS L2
L2
L2
L1
L1
L1
User VM
VM
VM
VM
VM
VM
ユーザネットワーク
(VLAN)
IaaS L1
L1
L1
仮想ネットワーク
Provider VM
VM
VM
L0
L0
L0
(OpenFlow、トンネル)
物理理ネットワーク
HaaS
Provider L0
L0
L0
計算資源の仮想化 ネットワーク資源の仮想化
16
17. Iris: HaaS資源管理理システム
物理計算機を要求
クラウド
管理者
資源コーディ
ネータ
クラウド資源管理
物理計算機を要求
システムで
DC間ネットワークを要求
計算機を管理
資源 資源
マネージャ マネージャ
過負荷により
DC内ネットワーク(制御網)
サービスレベル
物理計算機の 低下の恐れ
クラウド
提供
資源管理
物理 V
物理V V V V V
M M M M M M
計算機
計算機
DC間ネットワーク
DC内ネットワーク(データ網)
GW GW DC内ネットワーク(データ網)
Data Center 1 (HaaS事業者)
Data Center 2 (IaaS事業者)
17
18. Iris: プロトタイプ実装
• アプリケーション・インタフェース
– Webサービスは未実装(GNS-‐‑‒WSIv3ベースを検討)
– CLIスクリプトのみ対応
• ゲートウェイ
– Open vSwitch 1.4.0ベースに実装
• 計算資源管理理
– KVM on LXCとNested KVMに対応
• DC内ネットワーク資源管理理
– GREトンネル
• ゲートウェイを頂点とするスター型で実装。メッシュ型を実装中
• DC間ネットワーク資源管理理
– GREトンネル
18
20. 実験構成(1/2)
• 計算サーバ
– Intel Core2 quad-‐‑‒core Q9550/2.83 GHz、メモリ8GB、
ギガビットイーサネットNIC
– Ubuntu 12.04
• IaaS
– CloudStack 4.0.0-‐‑‒beta
Cluster
1
IP
network
(LAN)
Cluster
2
(HaaS) (IaaS)
control
plane
HaaS
HaaS
IaaS
IaaS
UVM
UVM
UVM
UVM
LXC/ LXC/ GW
GW
KVM
KVM
host2 host1 head0 head3 host4 host5
data
plane
20
21. 実験構成(2/2)
Haas UVM (L) HaaS UVM (K)
CPU mem disk NIC CPU mem disk NIC
L2 1 512 MB 5 GB (qcow2) virtio_net 1 512 MB 5 GB (qcow2) virtio_net
L1 4 no limit chroot veth 2 6 GB 32 GB (qcow2) virtio_net
L0 4 8 GB 640 GB e1000e 4 8 GB 640 GB e1000e
Cluster
1
IP
network
(LAN)
Cluster
2
(HaaS) (IaaS)
control
plane
HaaS
HaaS
IaaS
IaaS
UVM
UVM
UVM
UVM
LXC/ LXC/ GW
GW
KVM
KVM
host2 host1 head0 head3 host4 host5
data
plane
21
22. 動作確認
• ユーザVMのデプロイ
– CloudStack内部ではゲスト・パブリック・管理理
ネットワークにVLANを割当て
• ユーザVMのライブマイグレーション
Cluster
1
IP
network
(LAN)
Cluster
2
(HaaS) (IaaS)
control
plane
HaaS
HaaS
IaaS
IaaS
UVM
UVM
UVM
UVM
LXC/ LXC/ GW
GW
KVM
KVM
host2 host1 head0 head3 host4 host5
data
plane
22
23. ユーザVMのデプロイ時間
• 管理理ポータルからユーザVMのデプロイに要する
時間を計測(3回の平均時間)
– デプロイ時間にOSの起動時間 は含まない
– システムVMのデプロイ時間
• ユーザVMのデプロイ時間への影響はなし
– ⾮非同期APIを⽤用いるので、遅延の影響は限定的と推測
(単位は秒)
IaaS UVM HaaS (L) UVM HaaS (K) UVM
15.81 15.82 15.96
23
24. ユーザVM間の通信性能
• pingのRTTとIperfによるTCP性能を計測(10回平均)
– 注意:HaaS UVM間はGREトンネルなし
• LXCの性能オーバヘッドは無視できる
• ⼀一⽅方、Nested KVMの性能オーバヘッドは無視できない
– RTTは4.5倍に増加、グッドプットは30%減少
往復復遅延時間(ミリ秒) グッドプット(Mbps)
IaaS HaaS HaaS server IaaS HaaS HaaS
UVM (L) UVM (K) UVM client UVM (L) UVM (K) UVM
IaaS IaaS
0.36 0.64 1.22 934 913 806
UVM UVM
HaaS HaaS
- 0.35 0.87 912 934 872
(L) UVM (L) UVM
HaaS HaaS
- - 1.66 635 647 621
(K) UVM (K) UVM
24
25. BYTE UNIX benchmark
(単位はIndex。⼤大きいほど⾼高性能)
BM IaaS UVM HaaS (L) UVM HaaS (K) UVM
Dhrystone 2396.9 1317.4 1318.0 1061.1
Whetstone 594.7 582.3 581.6 492.0
Execl throughput 564.5 194.5 198.2 17.2
File copy 256 1448.4 979.9 975.5 824.1
File copy 1024 2048.4 1441.2 1425.7 1198.3
File copy 4096 2095.7 1617.3 1669.6 1357.3
Pipe throughtput 1305.6 770.6 772.3 636.5
Context 315.6 343.1 348.2 41.1
switching
Process creation 535.3 138.6 141.0 10.5
Shell scripts 1688.0 425.0 434.0 40.9
System call 1508.2 616.2 615.7 517.7
25
26. 参考:⼊入れ⼦子型仮想化
• Intel VTがサポートするのは1段階の仮想化のみ
• Nested VMX: VMX命令令のtrap & emulate
– L2 VM exitを処理理するために、L1 VMでは多くの処理理が必要:
VMCSの読書き、割込みの禁⽌止、ページテーブル操作など
– 上記の操作はtrapできるが、VM exit multiplicationが発⽣生
– 1回のL2 VM exitに対して、10〜~100回のL1 VM exitが発⽣生
L2
L1 VM Exit .....
L0 VM Entry
Single level Two level
26
27. 参考:VM Exit発⽣生回数
• VM exitの発⽣生回数と原因をSystemTapを⽤用いて調査
– 75%: VMREAD, VMWRITE, VMRESUME
– 25%: その他(EXCEPTION_̲NMI, CR_̲ACCESS, INVLPGなど)
• Nested VMXでは、プロセス⽣生成、切切替に関するVM exit発⽣生
回数が70〜~90倍に増加
– CR_̲ACCESS、INVLPGなどアドレス空間切切替のコストが増加と推測
L1 KVM L2 KVM L2/L1 Ratio
Dhrystone 5008 52879 10.6
Whetstone 3967 54129 13.6
Pipe throughput 4025 52798 13.1
Context switching 4437 304922 68.7
Process creation 4240 374785 88.4
System call 4034 54222 13.4
※測定環境はXeon X5650/2.67GHz, 6GB memory, Ubuntu 12.10
27
28. 得られた知⾒見見
• LXC
– 性能オーバヘッドは無視できるが、コンテナ間の隔
離離が不不完全であるため、⼀一部サービス(NFSクライア
ント、Open vSwitch)において異異常動作を観測
• Nested KVM
– 性能オーバヘッドは⼤大きいが、VM間の隔離離は完全な
ので、性能以外の制限事項はない
– 特にアドレス空間切切替のオーバヘッドが⼤大
• Open vSwitch
– 複数のVLANを1本のGREトンネルでトランクできる
ので設定が容易易 c.f. Linux bridge device
28
29. 関連研究
• ⼊入れ⼦子型仮想化(Nested Virtualization)
– Turtles Project [OSDI10]、xCloud [EuroSys12]
– L1 VMとしてフル機能のVMMが必要か?
• 論論理理分割:VirtageのKVM on LPAR
• 軽量量VMMの利利⽤用:BitVisor??
• データセンタネットワークの仮想化
– SecondNet [CoNext10]、Seawall [NSDI11]
– エッジ・オーバレイネットワーク: OpenFlow (Nicira NVP)、
Stratosphere SDN Platform、MidoNet
• Virtual Private Cloud (VPC)
– ⾃自前のオンプレミス計算資源をパブリッククラウドと接続する
ために利利⽤用
– 仮想ルータ経由の接続(HaaSサービスモデルcに近い)
29
31. まとめ
• IaaS事業者からの要求に対して、ネットワーク
越しにハードウェア資源を貸し出すHaaSサービ
スモデルを提案
• HaaS資源管理理システムIrisのプロトタイプ実装
を開発し、実証実験を実施
– 既存IaaSシステムに変更更を加えることなく、ゲート
ウェイの設置だけで、HaaS資源を透過的に利利⽤用可能
– 2段階の仮想化によりユーザVMからHaaSの制御ネッ
トワークを隠蔽可能
– HaaSシステム上へのユーザVMのデプロイ時間は、
IaaSシステム上と遜⾊色ないことを確認
31
32. 今後の課題
• 資源コーディネータや各種資源マネージャに対
するWebサービスインタフェースの設計と実装
• マルチテナント対応
• 未実装のサービスモデルへの対応
• 実ネットワーク環境上での実証実験
謝辞:
SystemTapを⽤用いた⼊入れ⼦子型仮想化の実験では、拓拓殖⼤大学の
Praween Amontamavutさんに協⼒力力して頂きました
32