インタークラウドにおける仮想インフラ構築システムの提案

  • 2,112 views
Uploaded on

2013年2月IPSJ OS研究会

2013年2月IPSJ OS研究会

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,112
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
22
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. インタークラウドにおける仮想インフラ構築システムの提案 ⾼高野  了了成  中⽥田  秀基  ⽵竹房  あつ⼦子 柳柳⽥田  誠也  ⼯工藤  知宏 産業技術総合研究所  情報技術研究部⾨門 2013年2月28日 OS研究会@岡山コンベンションセンター
  • 2. 背景•  インタークラウドへの注⽬目の⾼高まり –  クラウド連携、ハイブリッドクラウドなど•  新しいIT基盤サービスの登場 –  クラウド間での柔軟な資源の融通 –  複数クラウドの資源を組み合わせたサービスの提供 インタークラウド環境における 仮想インフラ構築技術の開発 2
  • 3. 本研究の貢献•  IaaS事業者からの要求に対して、ネットワーク 越しに資源を提供するHaaSサービスモデルの 提案•  HaaS資源管理理システム  Iris  (Inter-‐‑‒cloud   Resource  Integration  System)の設計と プロトタイプ実装 –  既存のCloudStackに変更更を加えることなく、要求に 応じた計算資源提供が可能 –  ⼊入れ⼦子型仮想化技術(LXCおよびNested  KVM)の 性能評価 3
  • 4. 発表の流流れ•  Apache  CloudStack•  HaaSサービスモデル•  Iris:  HaaS資源管理理システム•  プロトタイプ実装による実験 –  ユーザVMのデプロイ時間 –  ⼊入れ⼦子型仮想化の性能⽐比較•  議論論•  まとめと今後の課題 4
  • 5. Apache  CloudStack•  IaaSクラウド基盤構築・管理理ソフトウェア –  セルフサービス –  マルチテナント•  国内外に多数の利利⽤用実績 –  例例:北北⼤大アカデミッククラウド、NTT  Com  Cloudn•  柔軟なネットワーク構成 –  基本ゾーン •  全テナントのユーザVMが、フラットな単⼀一ネットワークを 共有(AWSスタイル) –  拡張ゾーン •  VLANによるネットワーク隔離離が可能 5
  • 6. CloudStackの構成 Management   Web  API ServerZone  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
  • 7. HaaSサービスモデル 7
  • 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
  • 9. HaaSサービスへの要求•  HaaSサービス利利⽤用者(IaaS事業者) –  既存IaaSシステムとの親和性 –  設置作業の最⼩小化 –  資源提供の単位の⾃自由度度 –  安定したDC間通信•  HaaSサービス提供者(HaaS事業者) –  制御ネットワークの隠蔽 –  複数テナントへの対応 9
  • 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
  • 14. Irisはギリシャ神話で 「虹の⼥女女神」Iris:  HaaS資源管理理システム 14
  • 15. HaaSサービスへの要求•  HaaSサービス利利⽤用者(IaaS事業者) –  既存IaaSシステムとの親和性 ゲートウェイの設置 のみでHaaSと接続 –  設置作業の最⼩小化 三つのサービス –  資源提供の単位の⾃自由度度 モデルに対応 –  安定したDC間通信 帯域保証技術の利利⽤用•  HaaSサービス提供者(HaaS事業者) –  制御ネットワークの隠蔽 仮想化技術の利利⽤用 –  複数テナントへの対応 15
  • 16. 資源管理理•  HaaSシステムでは計算機、ネットワーク共に 2段階の仮想化が必要 –  計算機:⼊入れ⼦子型仮想化 –  ネットワーク:エッジオーバレイ HaaS Data Center IaaS Data CenterIaaS 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、トンネル) 物理理ネットワークHaaSProvider 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
  • 19. 実験 19
  • 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 NICL2 1 512 MB 5 GB (qcow2) virtio_net 1 512 MB 5 GB (qcow2) virtio_netL1 4 no limit chroot veth 2 6 GB 32 GB (qcow2) virtio_netL0 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) UVMIaaS IaaS 0.36 0.64 1.22 934 913 806UVM UVMHaaS HaaS - 0.35 0.87 912 934 872(L) UVM (L) UVMHaaS HaaS - - 1.66 635 647 621(K) UVM (K) UVM 24
  • 25. BYTE  UNIX  benchmark (単位はIndex。⼤大きいほど⾼高性能) BM IaaS UVM HaaS (L) UVM HaaS (K) UVMDhrystone 2396.9 1317.4 1318.0 1061.1Whetstone 594.7 582.3 581.6 492.0Execl throughput 564.5 194.5 198.2 17.2File copy 256 1448.4 979.9 975.5 824.1File copy 1024 2048.4 1441.2 1425.7 1198.3File copy 4096 2095.7 1617.3 1669.6 1357.3Pipe throughtput 1305.6 770.6 772.3 636.5Context 315.6 343.1 348.2 41.1switchingProcess creation 535.3 138.6 141.0 10.5Shell scripts 1688.0 425.0 434.0 40.9System 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
  • 30. まとめと今後の課題 30
  • 31. まとめ•  IaaS事業者からの要求に対して、ネットワーク 越しにハードウェア資源を貸し出すHaaSサービ スモデルを提案•  HaaS資源管理理システムIrisのプロトタイプ実装 を開発し、実証実験を実施 –  既存IaaSシステムに変更更を加えることなく、ゲート ウェイの設置だけで、HaaS資源を透過的に利利⽤用可能 –  2段階の仮想化によりユーザVMからHaaSの制御ネッ トワークを隠蔽可能 –  HaaSシステム上へのユーザVMのデプロイ時間は、 IaaSシステム上と遜⾊色ないことを確認 31
  • 32. 今後の課題•  資源コーディネータや各種資源マネージャに対 するWebサービスインタフェースの設計と実装•  マルチテナント対応•  未実装のサービスモデルへの対応•  実ネットワーク環境上での実証実験 謝辞: SystemTapを⽤用いた⼊入れ⼦子型仮想化の実験では、拓拓殖⼤大学の Praween Amontamavutさんに協⼒力力して頂きました 32