Building Virtual Infrastructure at Inter-Cloud system

1,718 views
1,609 views

Published on

Presented by Seiya Yanagida

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,718
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
21
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Building Virtual Infrastructure at Inter-Cloud system

  1. 1. 柳田 誠也 高野 了成 中田 秀基竹房 あつ子 工藤 知宏産業技術総合研究所 情報技術研究部門2013年3月22日 第12回CloudStackユーザー会@IDCフロンティアインタークラウドにおける仮想インフラ構築システムの提案
  2. 2. 背景• インタークラウドへの注目の高まり– クラウド連携、ハイブリッドクラウドなど• 新しいIT基盤サービスの登場– クラウド間での柔軟な資源の融通– 複数クラウドの資源を組み合わせたサービスの提供2インタークラウド環境における仮想インフラ構築技術の開発
  3. 3. HaaS: Hardware as a Service• IaaS利用者から無尽蔵な資源プールに見えても、IaaS事業者の資源は有限– ピーク需要に対する設備投資は非効率• HaaSはIaaSへ資源を提供するクラウドサービス3SaaS: Software as a ServicePaaS: Platform as a ServiceIaaS: Infrastructure as a ServiceHaaS: Hardware as a Service
  4. 4. HaaSにおける資源管理• HaaSシステムでは計算機、ネットワーク共に2段階の仮想化が必要– 計算機:入れ子型仮想化– ネットワーク:エッジオーバレイ4L0L0L0L0L0L0L2VML2VML2VML1VML1VML1VML1VML1VML1VMHaaSProviderIaaSProviderIaaSUserHaaS Data Center IaaS Data Centerユーザネットワーク(VLAN)仮想ネットワーク(OpenFlow、トンネル)物理ネットワーク計算資源の仮想化 ネットワーク資源の仮想化
  5. 5. Iris: HaaS資源管理システム(Inter-cloud Resource Integration System)5Irisはギリシャ神話で「虹の女神」
  6. 6. Iris: HaaS資源管理システム6物理計算機DC内ネットワーク(データ網)DC内ネットワーク(制御網)資源マネージャ物理計算機DC内ネットワーク(データ網)クラウド資源管理VMVMData Center 1 (HaaS事業者) Data Center 2 (IaaS事業者)クラウド管理者資源コーディネータVMVMVMVM資源マネージャ物理計算機を要求物理計算機を要求DC間ネットワークを要求クラウド資源管理システムで計算機を管理過負荷によりサービスレベル低下の恐れ物理計算機の提供DC間ネットワークGW GW
  7. 7. Iris: プロトタイプ概要• アプリケーション・インタフェース– Webサービスは未実装(GNS-WSIv3ベースを検討)– CLIスクリプトのみ対応• ゲートウェイ– Open vSwitch 1.4.0ベースに実装• 計算資源管理– KVM on LXCとNested KVMに対応• DC内ネットワーク資源管理– GREトンネル(Open vSwitch利用)• ゲートウェイを頂点とするスター型で実装。メッシュ型を実装中• DC間ネットワーク資源管理– GREトンネル(Open vSwitch利用)7
  8. 8. Iris: プロトタイプ構成8Cluster 1(HaaS)Cluster 2(IaaS)IP network(LAN)head0 head3controlplanedataplanehost1host2 host5host4HaaSUVMLXC/KVMHaaSUVMLXC/KVMIaaSUVMIaaSUVM• 計算サーバ– Intel Core2 quad Q9550/2.83 GHz、メモリ8GB、GbE NIC– Ubuntu 12.04 x86_64 (kernel 3.2.0-38)– libvirtd 0.9.8、qemu 1.0、lxc 0.7.5• IaaS– CloudStack 4.0.0-beta (Advanced Network構成)GW GW
  9. 9. 動作確認9Cluster 1(HaaS)Cluster 2(IaaS)IP network(LAN)head0 head3controlplanedataplanehost1host2 host5host4HaaSUVMLXC/KVMHaaSUVMLXC/KVMIaaSUVMIaaSUVM• HaaS L1VMをCloudStackの計算ノードとして追加– CloudStack内部ではPrivate・Public・Guestの各ネットワークに別々のVLANを割当て• ユーザVMのデプロイ・ライブマイグレーション• BYTE UNIX Benchmarkの実行GW GW
  10. 10. L2VM比較10IaaS UVM(L1)KVM onLXCNestedKVMVMデプロイ時間 (sec) 15.81 15.82 15.96VM間通信速度 (Mbps) 930 934 621Ping RTT (msec) 0.36 0.35 1.66Dhrystone (BYTE index) 1317.4 1318.0 1061.1Execl (BYTE index) 194.5 198.2 17.2
  11. 11. 得られた知見(KVM on LXC)• L2VMの性能オーバヘッドは無視できる• LXCコンテナ(L1VM)間の隔離が不完全であるため、L1VMの一部サービスにおいて異常動作を観測– カーネルモジュール+ユーザーデーモンの構成をとるサービスは基本的にL1VMで使用不可 (NFS、udev、Open vSwitch等、ただしNFSは回避策あり)• 環境構築手順はNested KVMより複雑• いったん環境構築できれば、L2VMは安定して動作する11
  12. 12. 得られた知見(Nested KVM)• L2VMの性能オーバヘッドは大きい– 特にアドレス空間切替のオーバヘッドが大• VM間の隔離は完全なので、性能以外の制限事項はない• KVM on LXCに比べて環境構築が容易• L2VMの動作がやや不安定 (12.04の場合)– BYTE UNIX Benchmarkが原因不明のSEGVで落ちることがあった。しかも再現性なし– 12.10では今のところ問題なし12
  13. 13. 設定のポイント• KVM on LXC– LXCコンテナ(L1VM)内のlibvirtdのパーミッション• オーナーroot:ttyかつSGIDビットONでないとL2VMの起動がEPERMで失敗– NFS問題回避のため、Private Network用NICをL0ホストにも用意する– LXC設定ファイルで、デバイスkvm、tun、loopがL1VMから見えるようにする• Nested KVM– 最新のカーネルを使用する(12.04の場合)– L0ホストの/etc/default/qemu-kvmのパラメータKVM_NESTEDを有効にする13
  14. 14. 設定のポイント(ネットワーク)• ゾーン追加時、全てのトラフィックタイプについて、トラフィックラベルを明示的に指定する• L1VM用ブリッジおよびGREトンネルは、OpenvSwitchで構築すると容易に構築可能– Linux付属のモジュール(gre.ko等)を使うと、GREトンネルがうまく構築できない– OpenFlowコントローラはパッケージ付属のものを利用可能• ipコマンドとovs-vsctlコマンドで構築できる• ただしDC内トンネルをメッシュ型にする場合は、Broadcast Stormを回避するために独自コントローラが必要14
  15. 15. まとめ• IaaS事業者からの要求に対して、ネットワーク越しにハードウェア資源を貸し出す、HaaS資源管理システムIrisのプロトタイプ実装を開発し、実証実験を実施– 既存IaaSシステムに変更を加えることなく、ゲートウェイの設置だけで、HaaS資源を透過的に利用可能– 2段階の仮想化によりユーザVMからHaaSの制御ネットワークを隠蔽可能15
  16. 16. ありがとうございました資料は後日CloudStackユーザー会のサイトにアップロードしていただく予定です。関連論文:高野了成、中田秀基、竹房あつ子、柳田誠也、工藤知宏:インタークラウドにおける仮想インフラ構築システムの提案、情報処理学会OS研究会、2013年2月28日http://www.slideshare.net/oraccha/sigos12416
  17. 17. 補足:libvirtd• /var/log/libvirt/libvirtd.log• /var/log/cloud/agent/agent.log172012-11-13 06:50:46.101+0000: 667: error :qemuProcessReadLogOutput:1006 : internal error Processexited while reading console log output: chardev: openingbackend "pty" failed: Permission denied2012-11-13 06:50:46,282 WARN[kvm.resource.LibvirtComputingResource] (agentRequest-Handler-3:null) Failed to start domain: v-83-VM:internal error Process exited while reading console logoutput: chardev: opening backend "pty" failed: Permissiondenied
  18. 18. 補足:NFS• LXCコンテナ(L1VM)におけるマウント状態• L0ホスト(GREトンネル手前)のパケットキャプチャ180.001263 192.168.101.102 -> 192.168.101.1NFS 218 V4 Call GETATTR FH:0x0cde70550.001566 192.168.101.1 -> 192.168.101.102NFS 286 V4 Reply (Call In 8) GETATTR192.168.101.1:/export/primary on/mnt/2a3c975c-5a26-331b-9a49-a3a85cd7b6bb type nfs(rw,vers=4,addr=192.168.101.1,clientaddr=192.168.101.5)
  19. 19. 補足:DC間GREトンネルovs-vsctl add-br br0ip addr add 10.1.1.1/16 dev br0ip link set br0 upovs-vsctl add-port br0 eth0ovs-vsctl add-port br0 gre0ovs-vsctl set interface gre0 type=gre ¥options:local_ip=xxx.xxx.xxx.xxx options:remote_ip=yyy.yyy.yyy.yyyovs-vsctl add-port br0 c111gre0ovs-vsctl set interface c111gre0 type=gre ¥options:local_ip=10.1.1.1 options:remote_ip=10.1.1.419
  20. 20. 補足:DC内GREトンネルovs-vsctl add-br c112brovs-vsctl add-port c112br c112gre0ovs-vsctl set interface c112gre0 type=gre ¥options:local_ip=10.1.1.3 options:remote_ip=10.1.1.1ip addr add 10.1.1.3/16 dev eth0ip link set c112br up20

×