Presentation resource manager™utility package for st9990 and st9985 storage...
Apache CloudStack's Plugin Model: Balancing the Cathedral with a Bazaar Adding Hyper-V Support
1. Apache CloudStack's Plugin Model:
Balancing the Cathedral with a Bazaar
Adding Hyper-V Support
donal.lafferty@citix.com
Feb 26th, 2012
プレゼンテーションをダウンロードする
場合は、ノートが日本語に翻訳されてい
ることがわかります。
3. The Call For Submissions sets the context
• “Open Source Community Leadership Drives Enterprise-Grade Innovation”
ᵒCloudStack‟s plugin model permits enterprise-grade adaptions
• “Apache initiatives play a key role in powering today's Cloud”
ᵒPlugin model allows cloud to adapt to compute loads (not the other way around)
• “particular focus on those [talks] demonstrating real-world experience of
solving specific problems.”
ᵒCase study of adding Hyper-V support as a newcomer
4. Innovators Need the System to be Disaggregated
CloudStack WebServices API
OAM&P API End User API AWS API Pluggable Service API Engine
Business Logic Provisioning
Resource
Capacity
Accounts
Mgr
Update
Mgr
Rules
Mgr
Mgr
Mgr
HA
Security Mgr
Events Manager
Adapters
XenServer
Orchestration
VMWare
Usage Manager
OVM
KVM
Network Guru
Template Mgr
Network Mgr
VM Manager
Storage Mgr
Domain Manager
Snapshot
Manager
Network Element
Deployment
Account Mgr Planner
Limits Manager Hypervisor Guru
Framework
Agent Manager Cluster Manager Data Access Layer
6. Disaggregation Started with Hardware Management
CloudStack Orchestration Adapters CloudStack Provisioning
Plugins
Network Guru
Snapshot Manager
Template Manager
Network Manager
Storage Manager
VM Manager
XenServer
HypervisorGuru
VMWare
OVM
KVM
Etc…
Framework
Agent Manager Cluster Manager Data Access Layer
7. Understand that the Plugin serves two masters
• Server Component:
Rest API ᵒJava
ᵒAdapter APIs
Plugin API
Implementation ᵒDAO
ᵒRESTful API
Data Access Layer
• ServerResource:
ServerResource
- Optional. Required if Plugin needs to be co-
ᵒAgent Proxy, e.g. KVM
located with the resource • „Message Bus‟ of JSON over TCP
- Implements translation layer to talk to resource
- Communicates with server component via JSON ᵒDirect connect, e.g. XenServer
9. Follow the process for new features
• https://cwiki.apache.org/confluence/display/CLOUDSTACK/Adding+new+features+and+design+documents
• Announce over mailing list
- Attempt to get consensus: awareness & acceptance
• Publish Functional Spec & Design
• JIRA ticket for feature
• Setup a Dev Environment
• Branch on github, use your own (public) branch
• Submit changes to Review Board
- post-review for large packages of changes.
• Decide on the wiki you want
• Incubator wiki cleaner, simpler view
- http://incubator.apache.org/cloudstack/develop/developer-faq.html
• CloudStack wiki for in depth development
- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
• Avoid the pre-Apache wiki (http://wiki.cloudstack.org/dashboard.action)
10. Simpler Steps Make it Easier to Learn CloudStack
CloudStack Manager CloudStack Manager
Hyper-V Types Hyper-V Types
Phase 1: Phase 2:
Plugin Server Component Plugin Server Component
Proxy ServerResource ServerResource
Message Bus WS-Management
Connected Agent
WMI (or PowerShell) WMI
Hyper-V Server 2012 Hyper-V Server 2012
XenServer Cluster Hyper-V based
(System VMs) System VMs
11. Reuse and repurpose rather than rewrite
Phase 1
Remote WMI via
Python
Agent
Server Resource (KVM)
Agent Message Bus
AgentShell
O/S
12. ServerResource commands are easier to log and replay
public interface HypervisorResource extends ServerResource {
StartAnswer execute(StartCommand cmd);
StopAnswer execute(StopCommand cmd);
RebootAnswer execute(RebootCommand cmd); }
@Test
public void TestCreateCommand() {
String sample = "{"volId":10,"pool":{"id":201,"uuid":""+testLocalStoreUUID+"","h
","path":"+testLocalStorePathJSON+","port":0,"type":"Filesystem"},"diskCharact
""tags":[],"type":"ROOT","name":"ROOT-9","useLocalStorage":true,"recreatab
""volumeId":10,"hyperType":"Hyperv"},"templateUrl":"+testSampleTemplateURLJ
…
13. CloudStack is evolving, it may fix your problem
• Storage disaggregated
• SystemVM creation broadened & simplified
XenServer Cluster Hyper-V based
(System VMs) System VMs
14. Make advance preparations for IP clearance
# Copyright (c) 2010 Cloud.com, Inc
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
• http://www.apache.org/licenses/
ᵒhttp://www.apache.org/legal/src-headers.html
ᵒhttp://apache.org/licenses/LICENSE-2.0.html#apply
15. Bonus Tips – Read at your leisure
• SystemVMs have logs
ᵒConnect form hypervisor console, user:root, password: 6m1ll10n.
• Avoids SSH over 3392 with management server RSA keys
• Import Maven projects into Eclipse using m2e
• Maven debuggable task paused waiting for Eclipse to attach:
export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -
Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=y
- See http://www.mojavelinux.com/blog/archives/2007/03/remote_debugging_with_jetty/
• Expand Log4j logging
ᵒChange Threshold from INFO to TRACE
• :%s/INFO/TRACE/g
16. Summary
• Innovators Need the System to be Disaggregated
• Disaggregation Started with Hardware Management
• Understand that the Plugin serves two masters
• Follow the process for new features
• Simpler Steps Make it Easier to Learn CloudStack
• Repurpose rather than rewrite
• ServerResource commands are easier to log and replay
• Keep an eye out for evolving solutions
• Make advance preparations for IP clearance
17. “It is not the strongest of the species that
survives, nor the most intelligent that
survives. It is the one that is the most
adaptable to change.”
– Charles Darwin
17
18. References
• Theory behind plugins http://www.youtube.com/watch?v=FMM-YgK1jmg
• Disaggregating CloudStack
ᵒhttp://www.slideshare.net/buildacloud/cloudstack-collaboration-conference-12-
refactoring-cloud-stack
ᵒhttp://www.youtube.com/watch?v=iGk3s68Meh0
• Hyper-V Plugin Wiki
ᵒhttps://cwiki.apache.org/CLOUDSTACK/hyper-v-2012-30-support.html
Notes de l'éditeur
タイトルがよく分からない場合は…Eric S. Raymond のソフトウェア工学に関する本を参照して下さい。
* 一連のスクリーンショットで置き換えてもよい。---では、始めましょう。最初に質問です。First question, is what do I need to know to understand this presentation. That is the context for the point the that I’m going to bring up, and the context is established by the call for submissions.講演のテーマを引用…本講演のテーマをみてみましょう。企業というのはソフトウェアを長期間に渡って使いたいものである、というのが私の考えです。そのためには次の2点が重要です。まずは、ソフトウェア自体が即座に変更可能であること。オープンソースについて言えば、ソフトウェアのオーナーの責任が軽く、開発プロセスが透明で、誰でも開発に参加できます。本スライドにタイトルにあるように、まさにバザール・モデルです。一方で私たちは、自分の加える変更が秩序だっていてほしいものです。もし加えた変更を残りのシステム全体から区別するようなインターフェースがあれば、たとえ下位のシステムが変わったとしても、その変更部分を正しく動かし続けるのが容易になります。また、私たちは変更を加えた際に前提とした仕組みが変わらないでいてほしいものです。これには限界があります。それには、利用できるインターフェースにのみ固執し、それを踏み越えないように縛りを加えることが必要ですが、秩序と規律へのこの欲求は、本講演のタイトルで言えば、伽藍について語る際に当てはまるものです。分かったこと: 企業品質のソフトウェアには秩序だった適用方法が必要である。Fork するやり方では十分ではなく、また、加えた変更を容易に発展できないようでも優れているとはいえない。そして、これこそが CloudStackのプラグイン・モデルが解決している問題なのです。次に、話題をこの方向に変えましょう。この方向というのは、どのようにして、です…今日の IaaSクラウドは異機種環境のデータセンターが非常に受け入れられている、というのが私の立場です。IaaSに対する本来の究極目標は、「電力、ネットワーク帯域、運用、ソフトウェア、ハードウェアのコストをそれぞれ独立に削減する」ことです。[2] しかし、アプリケーションをハード障害への耐性をつけるには書き換えが必要です。典型的なクラウドOSであるAmazon Web Servicesは、使用している安価なマシンの障害を前提として、ダウンすることが折込済みの仮想マシンを提供しています。よって、旧来のIaaSでは、ハードとソフトはその IaaSが想定するモデルに則って利用しなければならず、これの回避策はありません。これとは反対に、企業では既存のシステム稼働に見合ったクラウドの形態を望んでいます。すなわち、柔軟かつ、計測可能であり、待機リソースが用意されている状況です。しかしながら、この既存のシステム稼働を、コモディティ・ハードで用意するという純粋な IaaSの考えに沿って実現するのは困難です。仮想デスクトップについて考えてみましょう。ユーザーは既存のライセンスに見合ったハードウェアを専有し、特別なストレージを必要とするような高品質のデータ・サービスを求めています。誰も自分のデスクトップ・マシンを手放したいとは思いません。ここで分かったことは、今日のクラウドと呼ばれるものはそれなりの性質を備えているが、既存のハードやシステムの利用形態と共存できるものではない。これがCloudStackのプラグイン・モデルが解決する問題の更なる詳細です。これによって、多種多様なデバイスをサポートすることができます。最後に、ApacheConこのカンファレンスで望んでいたのは…Focus を引用というわけで、ケーススタディを使ってプラグイン・モデルを説明していきます。そのケーススタディというのは、CloudStackにHyper-Vサポートを追加する際の問題です。「CloudStackには同一ゾーンでXen, VMWare, KVM, OVMといった複数のハイパーバイザーをサポートできるという強力な優位性があります。Hyper-Vが自身をVMWareの公認のライバルと表明している以上、私たちとしてもそれをサポートのリストに加えていく必要があります。ですので、Hyper-Vのサポートというのは、例としては興味ある格好の題材です。今から説明する経験内容は本当に真実味があるといえます。なぜなら、私はCloudStackに対しては完全に新参者だったからです。既存の開発者が持っているような知識は全くありませんでした。さらに、作業はリモートで行いました。私はタイムゾーンも地域もCitirxの同僚から遥か離れているのです。また、オリジナルのCloudStack開発メンバーでもありませんでした。私はおそらく新参者が遭遇しうるあらゆる障害物を行き当たってきたといえるでしょう。それでもなお、プラグインの PoCを実施できたのです。ここで分かったことは、私が示した点は、CloudStackの新規プラグインを作るという実体験に基づいているということです。9 分
次に取り上げるのは、分割について、つまりCloudStackをいくつかのピースにばらして、ハードの管理をhard started with hardware management.CloudStackは1つのAPIコールの中で、データセンターのリソースの制御をいくつかのステップに分割します。プロビジョニングにより検知されるハードウェア管理プロビジョニングによってCloudStack APIコールの特定のステップは一連のハードウェアの操作となります。この部分のステップだけを取り出したものが、オーケストレーションと呼ばれます。CloudStackのオーケストレーションはデータセンターをVM、ボリューム、テンプレート、NIC、ネットワークといった観点で扱うことができ、それらの基盤技術が何であるかについてあまり考える必要はありません。DeployVirtualMachineAPI を例に取ってみましょう。これはクラウド内にVMを生成するものです。使用する管理モジュールを列挙するステップ。Network managerがネットワーク設定を受け持ち、template manager がテンプレートをハイパーバイザーに展開し、storage managerがVMのrootボリュームのローカルコピーを作成します。 VM managerはVMを構成し、テンプレートをrootデバイスとしてアタッチします。適切なネットワークにNICを割り当てる役目もあります。処理と管理モジュールの順番がちょっと違っていますが、要点は分かったと思います。こうしたステップがオーケストレーションを構成するのです。その一方、あるハードウェアへの具体的な処理は、関連するプロビジョニング・プラグインによって実装されています。実際にデータセンターを更新しているのはプロビジョニング・プラグインです。分かったこと: データセンターの制御はプロビジョニングであり、これはオーケストレーションAPIとは独立しています。[Split into separate slide]こうした分割の仕組みにより、CloudStackではシステム起動時にいくつでもプロビジョニング実装を呼び出すことができます。プラグインは実現する機能に相当するアダプターを実装します。アダプターはデータセンターの性質やデバイスに応じたカテゴリに分かれて存在します。このスライドで挙げているのはその中の数個のアダプターに過ぎません。ネットワークとハイパーバイザーのアダプターです。図の通り、HypervisorGuruアダプターではKVMやVMWare, Xen, OVMのプラグインを実装しています。分かったこと: 一連のアダプター内に新しい技術を活かす仕組みを組み込んでいます。プラグイン・モデルによりソフトウェアは今ある制約を乗り越えて発展していくことができます。新たなアダプターとして、T新ストレージ・モデルがありますが、これもプラグイン・モデルを踏襲しています。
プラグインには、サービス提供先に応じて、2つの主要コンポーネントに分かれています:CloudStack管理サーバーとデータセンター内のリソースです。管理サーバー側のコンポーネントは、管理サーバーの要求に応答し、また管理サーバーにサービスを依頼します。管理サーバーによってロードされるため、プラグインはJavaで記述されます。オーケストレーション・エンジンによって使用されるため、プラグインは必要な数のアダプターインタフェースを実装します。オーケストレーション・エンジンがストレージとハイパーバイザーを制御するなら、その2セットのアダプターを追加することになります。「セット」という言葉を使ったことに注意して下さい。これについては後に触れましょう。管理サーバー内で動作するため、下位のデータベースにアクセス可能です。DAO (Data Access Objects) によってデータベースからオブジェクトをロードしたり、更新したり、永続的なオブジェクトを生成することも可能です。例えば、ハイパーバイザーが最初に管理サーバーに接続する時、ハイパーバイザー・プラグインはhost ID等の自身の詳細情報を更新するかもしれません。プラグインはRESTfulなAPIを公開して、オーケストレーションをバイパスすることも可能です。今日はその話題に触れませんが、APIの公開は本質としては管理のための「フック」です。分かったこと:プラグインの片側半分は管理サーバー内で動作します。ServerResourceと呼ばれるリソースは、制御しようとしているデータセンター・リソースに合わせて実装されます。制御先デバイス上でエージェントとして実行することができます。KVM はLibvirtライブラリで制御されますが、これはリモートから起動をかけることができません。ですので、KVM ハイパーバイザーのServerResourceはエージェントとしてハイパーバイザー上で動作します。サーバー側のコンポーネントにもServerResourceはあるのですが、これは実際には単なるプロキシーです。コマンドはJSON でシリアライズされてTCP / IP でプロキシーからエージェントに転送されます。リモートアクセスが可能なら、ServerResourceから直接接続が可能です。XenServerプラグインがよい例です。これはリモートアクセス API を使用します。結果として、ServerResourcesはCloudStackデータベースに直接アクセスすべきではありません。分かったこと:ServerResourceはどこででも動作できるし、様々な言語で実装可能です。というわけで、われわれのプラグインは管理サーバーとデータセンター内のリソースをつなぐ架け橋となるものです。
今後実装される機能と、他の誰かが解決したMLでの開発問題に注目していて下さい。私たちの問題を解決するため進化するCloudStack私たちはストレージが構造的に分割されるまでの間の時間をかせぐため、ストレージについては暫定のソリューションを選択した。NFSベースのセカンダリ・ストレージはオブジェクトストアとイメージサービスの組み合わせで置き換えた。一つの選択肢はSwiftを使うことで、もうひとつは S3によるアプローチだった。これらはフットプリントを絞り込んだHyper-V Server 2012を使用した場合には有利です。なぜなら、そこには通常通りNFSを直接使用できるNFSクライアントがないからです。プライマリ・ストレージ・モデルはより多様な選択を許すようアップデートされている。Hyper-V Server 2012 はSMB サービスを探すので、私たちはハイパーバイザーにSMBストレージを自動的に追加するようしたかった。暫定ソリューションによってこうした手間を省いた。私たちはプライマリ・ストレージにローカルディスクを使った。つまりフェーズ1のプラグインは共有ストレージは手動でマウントする必要がある。私たちはSMBをNFSとして公開するのにWindows サーバーの機能を利用した。それによって、SMB共有ストレージをマウントしたHyper-V サーバーからセカンダリ・ストレージへのアクセスが可能になるでしょう。もし適切はストレージ設計ができれば、他の選択をしたでしょう。同様にSystemVMを作成するのは、各種のオファリングを提供し、作成を簡素化するための開発工数が必要でした。SystemVMはCloudStack管理サーバーに、イメージを保存するセカンダリ・ストレージ、IsolatedネットワークのNAT等のネットワークサービス、コンソールアクセスのサービスを提供します。各ハイパーバイザーには専用のSystemVMがあります。わかったこと、理想の設計をターゲットに据えると、即座に開発工数は増加します。というわけで、私がCloudStackの進化を有効活用したと言うとき、2つの問題に言及しています。私たちは廃止予定のAPIやデザインに開発が関わらないように気をつけました。2つ目は、私たちは他のプロジェクトに参加することで問題を先送りすることができます。同じ事はSystemVMについても言えます。CloudStackはストレージ・モデルを変えるべく一連の斬新な書き換えを実施中です。