Donabe - Basic Models/Technology


Published on

Donabe is a multi-tier Application Container Service and a top level orchestrator that will provision/deploy complex apps. These slides were presented at the Openstack Essex Design Summit in Boston.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Donabe - Basic Models/Technology

  1. 1. Donabe<br />Debo~ Dutta (dedutta), Rick Clark (rickclar) @cisco<br /><br />
  2. 2. Conjecture: Applications are all that really matter to the end user! <br />
  3. 3. Anecdotal evidence: A CIO never sits around lamenting about infrastructure<br />"I wish I had more servers so we could manage our customer relationships better“<br />"SugarCRM's social media features would help our sales force be more responsive to the needs of our customers. How can I have that tomorrow?"<br />
  4. 4. Donabe is a multi-tierApplication Container Service and a top level orchestrator that will provision/deploy complex apps. <br />Use case: e.g. ruby/rails guy: cares for 1) a scalable ruby tier and 2) scalable mysql tier network segments. <br />Scalable<br />Ruby/Rails <br />Container <br />scalable<br />MySQL<br />container<br />
  5. 5. Whats new?<br />LB<br />Apache<br />passenger<br />Scalable<br />Ruby/Rails <br />Container <br />scalable<br />MySQL<br />container<br />Mysql<br />master<br />Stdby<br /> master<br />Mysql slaves<br />
  6. 6. Rails <br />container<br />LB<br />LB<br />Apache<br />passenger<br />Apache<br />passenger<br />Mysql<br />master<br />Stdby<br /> master<br />Mysql<br />master<br />Stdby<br /> master<br />Mysql slaves<br />Mysql<br />container<br />Mysql slaves<br />
  7. 7. Rails <br />container<br />LB<br />Apache<br />passenger<br />A collection of widgets?<br />interconnected … <br />Bunch of configs?<br />Bundled in a profile …<br />N-tier apps?<br />Flexible app profiles?<br />…….. And more?<br />Mysql<br />master<br />Stdby<br /> master<br />Mysql<br />container<br />Mysql slaves<br />What is Donabe (again!)?<br />
  8. 8. What should we focus on first?<br />
  9. 9. Applications have requirements<br /><ul><li>Compute
  10. 10. Logical Network (including topology!)
  11. 11. Security
  12. 12. Availability
  13. 13. Data
  14. 14. Storage
  15. 15. Spending boundries and triggers(Cloud specific)
  16. 16. Service assurance</li></li></ul><li>A simple thought<br />Donabe –abstract container model – (mimics a network of widgets)<br />Abstraction of resources <br />Infrastructure<br />Apps (bundles)<br />Nested containers/widgets<br />Each container has ports (widget level ports?)<br />for connecting to other containers<br />Ways to connect nested containers<br />Wont delve into policies here!<br />Container definition will point to policy object<br />
  17. 17. API<br />Resources<br />Container<br />Name<br />Type<br />(contains) List of containers<br />Relationships of lower level containers (aka sub-widget graph)<br />Policy <br />Policy <br />Opaque, known only to the SPs who implement containers<br />Separate template from instance<br />Templates need a specification language <br />Our choice: Declarative Languages<br />Thus API will have a manifest property<br />
  18. 18. Declarative Domain-Specific-Language<br />We need a DSL to declare the relationships between the containers and declare requirements that are not specifically owned by a container.<br /><ul><li>In prelim talks with puppet folks to extend the puppet manifest language for this purpose</li></li></ul><li>The language needs to be declarative, because we want to be done, but not how to do it. <br />I should be able to say I need a 2Gb/s connection between this point in container 1 and this point in container 2,<br />without knowing anything about the networking devices or the commands and values that need to be supplied to accomplish my request.<br />
  19. 19. Container Types<br />Compute <br />VMs, clusters, processes <br />Network <br />Virtual Network Segments<br />L2 container (like Quantum)<br />Storage<br />Objects, files, blocks, blobs<br />App – higher layer <br />Abstracts workloads<br />
  20. 20. Compute Containers<br />Generic VMs or lightweight VM containers. <br />Encompasses current VM semantics<br />Can be used for openVZ or LXC<br />Connected via virtual or real switches <br />A server connected to an access<br />Blade server/chassis (cisco, hp, ibm etc)<br />Connects to the same access switch<br />Simple example: <br />apache container has a nested compute container<br />This container specifies a VM or a LXC container to run <br />
  21. 21. Network containers<br />Forms the pipes/segments used by other containers to talk to each other. <br />Refine attachment points/ports semantics <br />VMs  vNIC<br />Quantum/L2 network  ports<br />Apps  socket/ports <br />Widgets  in/out ports<br />Can support point-point or multipoint communication<br />Services containers can be injected using a filter path/graph model e.g. a bump-in-the-wire chain <br />E.g. Quantum is a good L2 network container …. <br />
  22. 22. Key work areas for Essex<br />Model/APIs <br />Agreement of models needed for 1st phase. <br />Declarative languages <br />Puppet network additions<br />Integration with OVF 2.0 profiles<br />Widget library/container template design<br />Orchestration (stretch)<br />Scheduling<br />
  23. 23. Who is doing something similar?<br />In openstack - ? … <br />Heroku?<br />Cloudscaling?<br />Opscode?<br />