Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XPDS16: Xen Orchestra: building a Cloud on top of Xen - Olivier Lambert & Julien Fontanet, Vates


Published on

Since its inception, the Xen Orchestra project which uses AGPLv3, always had a philosophy to listen and engage the community. User feedback shaped our initial concept, which first targeted system administrators. Eventually, our users drove us to support cloud-scale deployments supporting up to 2000 VM's. Retaining simplicity in usage and installation, while evolving Xen Orchestra to cloud scale posed many challenges. This led us to build many new features such ACLs, self-service, live charts, config drive management, and more, forced us to constantly evolve our architecture. First we will show how user needs changed our architecture, and how we implemented challenging problems such as user permissions, ACLs, Containers in a virtualized infrastructure and self service. We will conclude with a short demo, what is next and a lessons learned.

Published in: Technology
  • Login to see the comments

XPDS16: Xen Orchestra: building a Cloud on top of Xen - Olivier Lambert & Julien Fontanet, Vates

  1. 1. Xen Orchestra Building a Cloudon top ofXen 1 / 27
  2. 2. Introduction At first an easy to use administration tool (10s of VMs) Today still an administration tool (100s to 1000s of VMs) ;) self service portal backup solution basic load balancer Tomorrow more and more a simple cloud solution easy-to-use API to manage Xen Servers advanced load balancer 2 / 27
  3. 3. 3 / 27
  4. 4. History 2009 Initially created by Olivier as a student for personal use Based on xend Static pages generated by PHP 2013 Still no nice and easy Web UIs for XenServer Restarted in 2013 for internal use Still generating much interest from the community Initial server written in PHP 4 / 27
  5. 5. History (2) Mid 2013 Server rewritten using Node Initial single-page web application (based on Backbone.js then Angular.js) 2014 Not as much things as we wanted because not much time dedicated to the project! → Need to focus! 5 / 27
  6. 6. History (3) 2015 We are working exclusively on XO! 2016 UI entirely rewritten for performance and ease of use for big infrastructures (2000+ VMs) 6 / 27
  7. 7. 7 / 27
  8. 8. 8 / 27
  9. 9. 9 / 27
  10. 10. 10 / 27
  11. 11. Architecture Above pools 11 / 27
  12. 12. Architecture (2) Centralized server less connections cached data shared authentication no Xen Servers directly exposed 12 / 27
  13. 13. 13 / 27
  14. 14. 14 / 27
  15. 15. You saidCloud? Bring people a way to enjoy cloud-like features with their own hardware, without complexity: no complicated stuff to install on hosts (stay agent-less) leverage our current XO architecture (no need to rewrite everything) bottom to top approach, ie start small and add features step by step (opposite of OpenStack) Features ACLs (users/groups permissions) Self Service CloudInit 15 / 27
  16. 16. ACLs First step toward the cloud: permissions! Let users/devs make actions on their VMs: can only see VM state (viewer) power cycle (operator) remove (admin) avoid devs to ask for things they can do themselves sell your ressources to your customers 16 / 27
  17. 17. 17 / 27
  18. 18. Selfservice: going further Create a set of resources (max CPUs, RAM, disks, etc.) Assign this set to a group/user Let them play with it 18 / 27
  19. 19. 19 / 27
  20. 20. Cloud-Init (1) Cloud-init is the defacto multi-distribution package that handles early initialization of a cloud instance. How to? 1. Create a template where you install Cloud-init software (apt/yum/whatever) 2. Remove all root/user password 3. Transform your VM into a template 20 / 27
  21. 21. Cloud-Init (2) VM creation for Cloud-init templates During next boot, Cloud-init will: read the configuration passed by XOA apply it 21 / 27
  22. 22. Cloud-Init (3) Possibities deploy SSH keys and host name install software on boot (Apache, MySQL...) inject software configuration add extra repo, certificates, execute commands on boot, phone home when ready... mount points extend root partition size (if disk bigger than current FS) XO + Cloud-Init allows you to deploy generic but versatile templates in less than 20 secs 22 / 27
  23. 23. Quick recap (1) Before As an admin, everytime: 1. Install a VM (OS install, VM settings) 2. SSH into it with root/sudoer 3. Create basic configuration (automated or not) 4. Give your developer an IP address to SSH on As a developer: 1. Break your VM 2. Call your sysadmin 3. Wait for a manual operation (reboot/reinstall/whatever) 4. Go back to 1 23 / 27
  24. 24. Quick recap (2) Now As an admin, after creating a set of ressource and the right templates: 1. Nothing As a developer: 1. Break your VM 2. Remove it and recreate it in 20 secs 24 / 27
  25. 25. Future possibilities IP (manual) management with VIF locking (almost done) expose CloudInit templates directly in XO (with a public registry?) DHCP/DNS connectors (network automation) integrate XO with CI services (eg Jenkins) or Vagrant for devs 25 / 27
  26. 26. Conclusion XO architecture and Xen + XAPI allows powerful features combining XO Cloud features turns your own Xen hardware into a private cloud still some improvements possible In real life: Current usage for XO in a "local Cloud": VPS vendors (selling resources) companies with various devs teams (especially when Docker involved) 26 / 27
  27. 27. Thank you! Questions? Twitter: @xenorchestra IRC: #xen-orchestra (FreeNode) 27 / 27