伸縮自在なデータセンターを実現するインタークラウド資源管理システム
•
5 recomendaciones•1,890 vistas
第34回インターネット技術第163委員会研究会 -ITRC meet34-
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 伸縮自在なデータセンターを実現するインタークラウド資源管理システム
Similar a 伸縮自在なデータセンターを実現するインタークラウド資源管理システム (20)
Más de Ryousei Takano
Más de Ryousei Takano (20)
伸縮自在なデータセンターを実現するインタークラウド資源管理システム
- 1. 伸縮⾃自在なデータセンターを実現する インタークラウド資源管理理システム ⾼高野了了成 ⽵竹房 あつ⼦子 中⽥田秀基 柳柳⽥田誠也 ⼯工藤 知宏 産業技術総合研究所 情報技術研究部⾨門 2013年年10⽉月30⽇日 ITRC meet 34@広島
- 2. 概要 • 伸縮可能なデータセンターを実現する HaaSモデル • Iris：インタークラウド資源管理理システム • FELIXプロジェクトの紹介 5⽉月のRICC WSからの差分 ・Irisの開発進捗 ・ライブマイグレーション対応 ・KVM on LPAR (Virtage)実験 ・FELIXプロジェクトの紹介 2
- 3. インタークラウドの必要性 • End to Endでのサービス毎の品質保証 GICTF WhitePaper2011-1-v1.1 – 性能保証 – 可⽤用性保証 3.1 • DCをまたいだスケールアウト・スケールイン 急激な負荷増加に対する性能 を保証するユースケース 出典：GICTF Whitepaper 「インタークラウドのユース ケースと機能要件」 3
- 4. インタークラウドの必要性 • 災害からのリカバリやサービス安定稼働の実現 には，1つのデータセンターでの処理理・管理理では 不不⼗十分 – 東⽇日本⼤大震災で岩⼿手県、 宮城県の4市町で、 計約３万８６００件の⼾戸籍、 住⺠民基本台帳のデータが 消失 – レンタルサーバ会社の データ消失事故 （2012年年6⽉月） • 更更新プログラムのバグで データを削除 4
- 5. インタークラウドの必要性 • ビッグデータ処理理基盤への期待 – 情報の爆発的な増加 • ⾼高エネルギー物理理実験 – LHC@CERN – Belle II@KEK (50PB/year, 2022までに200PB) • DNAシークエンサーのハイスループット化 – 2010年年時点で1台あたり180GB/week D. Asner (PNNL), TIP2013 – 2012年年3⽉月29⽇日 Big Data R&D Initiative@⽶米国 • ビッグデータ関連研究開発や教育に$200M – 公的情報のオープン化の動き • ⽶米国「オープンガバメントイニシアティブ」（Data.gov） （2009/05） • ⽇日本「電⼦子⾏行行政オープンデータ戦略略」（2012/07) • 「Open DATA METI」（β版） http://datameti.go.jp/ (2013/1/28) 5
- 6. インタークラウド • 地理理的に分散した複数クラ ウド（DC）の資源を統合し てサービスを構築する技術 • ⾼高い信頼性・可⽤用性を実現 可能 • ただし、技術的課題も ! ! ! – – – – – ⾃自動化 安全性 サービスレベルの保持 利利⽤用／管理理のI/Fの差異異 DC間の⼤大量量データの移動、 管理理、処理理 – セキュリティ 6
- 7. 現在のインタークラウド ソリューション インタークラウド資源管理理が 異異なるI/Fの差異異を吸収 インタークラウド 資源管理理 IaaS資源管理理A IaaS資源管理理B Internet ☓⾃自動化 △安全性 ☓サービスレベル △I/Fの差異異 ☓⼤大量量データ管理理 Data Center 各VMでVPN設定（⼿手動） 7
- 8. グリッドで得た知⾒見見から 共通インタフェースの策定は現実的か？ – 標準化には時間がかかる – 複雑な仕組みは普及しない クラウドOSの普及 CloudStack，OpenStack, Eucalyptus, OpenNebula, ... IaaSの下位層に潜り込む IaaS事業者X IaaS事業者Y HaaS（Hardware as a Service）事業者 8
- 9. 伸縮⾃自在なデータセンター 2. Requests HaaS resources 3. Allocates compute resources Resource coordinator Resource manager IaaS users IaaS admin 4. Allocates network resources Resource manager 1. Service degradation due to excessive load DC Network (control plane) IaaS middleware VM VM VM VM VM VM BM Inter-‐‑‒DC network DC Network (Data plane) GW Data Center 1 (物理理資源貸出業者) GW DC Network Data Center 2 (クラウド事業者) 9
- 10. 伸縮⾃自在なデータセンター IaaS users Resource coordinator Resource manager IaaS admin Resource manager DC Network (control plane) IaaS middleware 5. Deploys IaaS userʼ’s VM VM VM VM VM VM VM VM VM BM Inter-‐‑‒DC network DC Network (Data plane) GW Data Center 1 (物理理資源貸出業者) GW DC Network Data Center 2 (クラウド事業者) 10
- 12. インタークラウドモデル • vIaaS (Virtual Infrastructure as a Service) • HaaS (Hardware as a Service) (a) vIaaS: overlay model DC DC IaaS VI (= IaaS) DC (requester) DC IaaS federation layer IaaS VI VI IaaS tenant VI (= IaaS) DC (provider) DC (requester) (b) HaaS: extension model 12
- 13. HaaSサービスへの要求 • Ease of use – 既存のIaaSソフトウェアへの変更更は不不要 – DC間接続⽤用ゲートウェイの設置は許容 • Multi-‐‑‒tenancy – 複数のIaaSに対してサービスを提供可能 – 特定のIaaSソフトウェアに⾮非依存 • Secure isolation – IaaS管理理者からHaaS DCの物理理ネットワーク （コントロールプレーン）を隠蔽 13
- 14. Iris: Inter-‐‑‒cloud Resource Integration System • HaaS資源管理理システム Iris (Inter-‐‑‒cloud Resource Integration System)の開発 – 既存クラウドOSのCloudStackに変更更を加えること なく、要求に応じた計算資源提供が可能 – ⼊入れ⼦子型仮想化技術、OpenFlowの利利⽤用 Irisはギリシャ神話で 「虹の⼥女女神」 14
- 16. Irisネットワーク仮想化 • OpenFlowによるエッジオーバレイNW構築 – IaaS毎にDC内ネットワークを隔離離 – オーバレイNW内ではVLANを使⽤用可能 • DC間はL2トンネリングで接続 HaaS DC Intra-‐DC GRE IaaS DC GW GW Inter-‐DC GRE GWを含むL0計算機で vSwitchが動作 16
- 18. Irisコントローラの動作（２） 〜～HaaS DC内のARP処理理〜～ 各VMの IPアドレス、 MACアドレス、 およびトポロジ 情報 Iris controller management registry (2) PacketIn (3) lookup (4) PacketOut (ARP reply) vSwitch (1) send ARP request vSwitch (5) receive ARP reply VM VM 18
- 19. Irisコントローラの動作（３） 〜～IaaS DC内のARP処理理〜～ 各VMの IPアドレス、 MACアドレス、 およびトポロジ 情報 Iris controller management registry (2) PacketIn vSwitch (1) send ARP request (3) lookup HaaS DCに存在 しないARP リクエスト (4) PacketOut (ARP request) GW (vSwitch) VM 19
- 20. VMマイグレーション（１） Iris controller (3) lookup & management update registry (4) FlowMod vSwitch VMのフロー エントリをクリア (2) PacketIn vSwitch (1) send RARP request VM (0) migration VM 20
- 21. VMマイグレーション（２） Iris controller management registry (3) lookup (4) FlowMod vSwitch VMのフロー エントリを設定 (2) PacketIn vSwitch (1) send IP packet VM VM 21
- 22. Irisの実装 • インタークラウド資源管理理ミドルウェア GridARSの⼀一部として実装 • ⼊入れ⼦子型仮想化技術 – Nested KVM – KVM on LPAR (Virtage) – KVM on LXC • OpenFlow – Open vSwitch – Floodlightベースコントローラ 22
- 23. 実験構成 • 計算サーバ 6台 – Intel Core2 quad-‐‑‒core Q9550/2.83 GHz、メモリ8GB、 ギガビットイーサネットNIC – Ubuntu 12.04 • IaaSクラウド管理理ソフトウェア – CloudStack 4.0.0-‐‑‒beta IP network (LAN) Cluster 1 (HaaS) Cluster 2 (IaaS) control plane HaaS UVM LXC/ KVM data plane HaaS UVM LXC/ KVM host2 host1 IaaS UVM GW head0 IaaS UVM GW head3 host4 host5 23
- 24. ユーザVMのデプロイ時間 • 管理理ポータルからユーザVMのデプロイに要する 時間を計測（3回の平均時間） – デプロイ時間にOSの起動時間 は含まない – システムVMのデプロイ時間 • ユーザVMのデプロイ時間への影響は限定的 – DC間遅延10ミリ秒以内であれば許容範囲 （単位は秒） IaaS UVM HaaS (L) UVM HaaS (K) UVM 15.81 15.82 15.96 24
- 25. BYTE UNIX benchmark （単位はBMに対する相対性能） IaaS UVM HaaS (L) UVM HaaS (K) UVM Dhrystone 54.96 54.99 44.27 Whetstone 97.91 97.8 82.73 Execl throughput 34.46 35.11 3.05 File copy 256 67.65 67.35 56.9 File copy 1024 70.36 69.6 58.5 File copy 4096 71.17 79.67 64.77 Pipe throughput 59.02 59.15 48.75 110.33 13.02 Context switching 108.71 Process creaXon 25.89 26.34 1.96 Shell scripts 25.18 25.71 2.42 System call 40.86 40.82 34.33 25
- 26. ⼊入れ⼦子型仮想化 • Nested VMX: VMX命令令のtrap & emulate – L2 VM exitを処理理するために、L1 VMでは多くの処理理が必要： VMCSの読書き、割込みの禁⽌止、ページテーブル操作など – 1回のL2 VM exitに対して、10〜～100回のL1 VM exitが発⽣生 • 上記のVM exitは、⼤大幅に削減できる⾒見見込み – EPT shadowing (VMMの拡張) – VMCS shadowing (Haswell以降降) L2 L1 L0 ..... VM Exit VM Entry Single level Two level 26
- 27. BYTE UNIX benchmark （単位はBMに対する相対性能） HaaS (Virtage) UVM HaaS (KVM) UVM Dhrystone Whetstone Execl throughput EPT shadowingの効果に より、Virtage上のL2 VMの 性能はL1 VMに匹敵 File copy 256 File copy 1024 File copy 4096 Pipe throughput Context switching Process creaXon Shell scripts System call 実⾏行行環境 ・⽇日⽴立立 BladeSymphony 2000 ・L0: Virtage ・L1: RHEL 6.2 ・L2: CentOS 5.5 27
- 28. まとめ • IaaS事業者からの要求に対して、ネットワーク 越しにハードウェア資源を貸し出すHaaSサービ スモデルを提案 • HaaS資源管理理システムIrisを実装し動作を確認 – 広域環境（〜～10ミリ秒遅延）でもVMデプロイ時間は ⼗十分⼩小さい – 現時点で⼊入れ⼦子型仮想化はオーバヘッドが⼤大きいが、 改善の⾒見見込み 28
- 31. 「新世代ネットワークの実現に向けた 欧州との連携による共同研究開発」 • 課題ア モノのネットワークとクラウドを融合するネッ トワークサービス基盤の研究開発 実時間性が要求される IoT サービスをクラウドにより実現するた めのサービス基盤の構築 • 課題イ ネットワークテストベッドを活⽤用した⽇日欧にお ける実証的共同研究 認証やリソース制御等のネットワーク制御プレーンや実運⽤用シナ リオを前提とした実験ネットワークを⽤用いた実証実験 • 課題ウ コンテンツ指向ネットワーキングによる省省エネ ルギーコンテンツ配信の研究開発 ⼤大容量量化するコンテンツ配信おいて必須となる低消費エネルギー 化技術の研究開発 31
- 32. FELIX FEderated Test-‐‑‒beds for Large-‐‑‒scale Infrastructure eXperiments FELIX SDN 連携フレームワーク * 資源管理理 実験制御 スライスモニタ NSIで制御さ れた ネッ ワーク ト OCF OCF wiLab BELNET NEC 1Gbit/s 1Gbit/s e ach Expedient LDAP t NFS DNS VPN 40× 1Gbit/s xenserver Oper ation & Gove rnan ce OMF MySli ce Nepi SDNマネージャ OCF OMF firewall 10Gbit/s 新世代ネッ ワーク ト 実験環境 SFAに基づく 連携 PL-‐Lab Access System myPLC SFA IIP Network Administartors pen Lab Request reservation PL-LAB User ... AAA Resource Management Service Schedules and co-allocates appropriate resources. VPN HUBS PL-LAB Access Management Service Virtual Wall i2CAT OFELIA and FIBRE islands (EXPERIMENTA) 5 xenservers iMinds OFELIA island Wire d Wirel ess Mobi lity iMinds OpenLab testbed Provisioning Module PL-LAB Access Portal xenserver xenserver Resource Management Module Monitoring Module TopH at Alcatel 10× 1Gbit/s GridARS Receive monitoring information Monitoring Service Provides filtered monitoring information. PL-LAB Access AAA Service EICT OFELIA island PSNC PlanetLab Testbed GÉANT NSI domains PL-LAB Resources PL-LAB Access Monitoring Service PSNC PL-‐Lab Testbed GLIF NSI domains Provisioning Service Constructs a virtual Infrastructure. Virtual Infrastructure Computing Domain D1A Network Domain D1N D2C D2N D1B D2D Japanese S DN Testbed, R ISE JGN-‐X NSI domain s テスト ド ベッ 間でNSIにより 動的なネッ ワーク ネク ンを提供する ト コ ショ ネッ ワーク ト インフ ラ *集中制御もし は個々のテスト ド く ベッ の制御フレームワークと 統合さ れた分散制御を⾏行行う 32
- 34. FELIXの⽬目的 • ⽇日欧のテストベッドの相互接続 – ⾼高度度な研究や実験のためのより複雑な環境を構築す ることで、⽇日欧の研究者の相互利利益を促進 – テストベッドの地理理的な分散により、新たな実験の 機会をつくる • 新世代ネットワークのための共通フレームワー クを構築 – ⽇日欧の統合SDNテストベッドの構築 – インタードメインネットワーク要求I/F標準のOGF NSIの活⽤用 – IT+ネットワーク基盤管理理技術の新たな標準策定に おける⽇日欧連携の促進 34
- 35. 産総研の提案するユースケース： IaaSマイグレーションによる災害復復旧 • 災害発⽣生時にIaaS全体を遠隔データセンタへ移送 – IaaS：管理理ノードを含むVMの集合 • CloudStackやOpenStack等で管理理 • 物理理資源を抽象化するHaaS (Hardware as a Service)層を⽤用いて実現 IaaS user A IaaS user C IaaS user B IaaS A (e.g., CloudStack) HaaS 1GB x 10000VM = 10TB (100G : 13.3 min) IaaS user D IaaS B HaaS Physical machines + OFS Physical machines + OFS site A site B 35
- 36. FELIX実現に向けた産総研の取り組み ① OGF Network Services Interface (NSI)の標準化 ② インタークラウド資源管理理 技術 インタークラウド ②インター 資源管理理 GridARS資源管理理システムの開発 DC資源管理理 ③ HaaSモデルの実現 Iris仮想インフラ構築システムの 開発 ①NSI NW資源管理理 クラウド 資源管理理 DC資源管理理 専用回線 ③HaaSモデル 36
- 37. 今後の予定 • FELIX基盤を活⽤用した⽇日欧実験に向けて – ⽇日欧の統合SDNテストベッドの構築 – ユースケースとして、Irisを⽤用いたIaaSマイグレー ションの実現 謝辞：本研究成果の⼀一部は、独⽴立立⾏行行政法⼈人情報通信研究機構（NICT） の委託研究「新世代ネットワークの実現に向けた欧州との連携による 共同研究開発 課題イ ネットワークテストベッドを活⽤用した⽇日欧に おける実証的共同研究」により得られたものです。 37