CloudStack Build A Cloud Day (SCaLE 2013)


Published on

Slides from th

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

CloudStack Build A Cloud Day (SCaLE 2013)

  1. 1. C LO U D STAC K Clayton Weise cweise@iswest.netIRC: iswcin #cloudstack on freenode
  2. 2. LICENSING This presentation and it’s contents unless otherwise noted are released under a Creative Commons Attributions, Share-Alike 3.0 unported license.
  3. 3. H I STO RY Original company formed - 2008 (VMOps) Project open sourced as CloudStack – May 2010 Acquired by Citrix – July 2011 Dropped open core – August 2011 Release of Acton (3.0) – Real soon now
  4. 4. W H AT I S C LO U D STAC K ?Open Source Infrastructure as a Service platform thatsupports multiple hypervisors, complex network, firewall,load balancer and VPN configurations, high availability, in amulti-tenant environment.
  5. 5. W H AT D O ES I T R EA L LY D O ? Provide separation for the varied tenants Allocate compute resources in a deterministic manner Expose to the end user the ability to provision various computing services in a controlled manner (VLAN allocation, firewall rules, load balancer deployment, VM creation, etc) Manage High Availability Massively Scalable Permit the placement of resource limits to be applied Measuring usage over time
  6. 6. M U LT I P L E H Y P E RV I S O R S U P P O RT KVM XenServer Xen Cloud Platform VMware (via vCenter) Oracle VM Bare Metal
  7. 7. M U LT I - T E N A N T S E PA R AT I O N Largely built around abstraction from an end-user POV  No interaction with hypervisor directly  No knowledge of underlying storage Networking separation  Every account has at least one dedicated/isolated VLAN (Tagged Networking)  Layer 3 isolation aka Security Groups for untagged networking Option to use dedicated hardware
  8. 8. N E T WO R K I N G CloudStack has a number of network models They are generally broken down by:  Method of isolation (VLAN, Security Groups)  Physical hardware or virtual CloudStack largely manages network infrastructure
  9. 9. N E T WO R K I N G Services managed by CloudStack  DHCP  VLAN allocation  Firewall  NAT/Port forwarding  Routing  VPN  Load Balancing
  10. 10. N E T WO R K I N G CloudStack can also manage physical network hardware (or the virtualized alternatives)  F5-Big IP  NetScaler  Juniper SRX Additionally you can ‘mix and match’ some network elements as service offerings.
  11. 11. S EC U R I T Y G RO U P S Traditional isolation has been via VLAN VLANs isolate well, but have some problems scaling  Standard has a hard limit of 4096 VLANs  Hardware that can actually keep up with 4096 VLANs is VERY expensive.  Regardless people tend to not like having arbitrary limits on what they can do. Amazon and others use layer 3 isolation (Security Groups)
  12. 12. S EC U R I T Y G RO U P S Assumption of a quasi-trusted Layer 2 network Typically will only have hypervisors directly connected to that network. Filtering/isolation occurs at the bridge device (from a Linux perspective – think ebtables) Deny by default
  13. 13. S EC U R I T Y G RO U P S
  14. 14. S EC U R I T Y G RO U P S
  15. 15. H I G H AVA I L A B I L I T Y RFMTTR – but apparently HA looks better in marketing slicks and is used that way across the virtualization industry. CloudStack is not a magical solution for HA – but might be a useful tool in the process to increase availability. CloudStack will watch for HA-enabled VMs to ensure that they are up, and that the hypervisor it’s on is up – and will restart on another hypervisor if it goes down. Redundant router
  16. 16. A L LO C AT I O N A LG O R I T H M S How do you place VMs?, allocate storage, etc. CloudStack ships with a number of options:  First Fit  Fill first  Disperse  Create your own Tags OS Preference
  17. 17. U SAG E Not billing per se – but does give you something to bill against. Usage stats show VM count, CPU usage, disk allocation and usage, network usage; all over time. Lots of integration and howto’s - from Excel spreadsheets to Ubersmith, Amysta, and Cloud Portal.
  18. 18. H I G H L E V E L A RC H I T EC T U R A L OV E RV I E W © Copyright David Baird and licensed for reuse under this CC-BY
  19. 19. S ECO N DA RY STO R AG E Used for storing templates and snapshots Historically NFS – just added the option of object storage  Technically Swift, but Caringo, GlusterFS and others should work. Managed by Secondary Storage VM – manages moving templates and snapshots from/to primary storage, aging snapshots out, etc.
  20. 20. P R I M A RY STO R AG E In the UI we support NFS, iSCSI, and CLVM. We can also make use of local storage  No HA, no live migration, etc. Shared mountpoint  Anything that all the hypervisors can mount and write to.
  21. 21. R ES O U RC E D I V I S I O N We have some somewhat arbitrary divisions of resources within CloudStack  Zones • Pods – Clusters
  22. 22. ZO N E In general practice this is used to designate a specific geographic location. Shares secondary storage resource across the entire zone Single network model for the entire zone
  23. 23. POD In general practice – this is used to refer a rack of machines or a row of racks. Shares guest network
  24. 24. C LU ST E R This is typically a max of 8-15 machines per cluster and homogenity is enforced:  Same hypervisor (and same version of the hypervisor)  Same CPUs  Same networking (i.e. /dev/eth0 is connected to the same network across all machines) Primary storage is cluster specific
  25. 25. P L E T H O R A O F N E T WO R KS Management Network: Where the hypervisors and management server communicate Private Network: Default network for system VMs. (virtual router, secondary storage VM, Console proxy VM) Public Network: The public (often internet-facing network) Guest Network: The network that VMs are provisioned on. Link-local network: The RFC 3927 network used for communication between hypervisor and system VMs.
  26. 26. M A N AG E M E N T S E RV E R UI/API pieces are stateless (state is stored in a MySQL database. All UI functionality is an API call
  27. 27. API RESTful API interface  Unauthenticated API interace on 8096 (for localhost)  Authenticated API interface natively on port 8080  Responses in XML or JSON  AHqgRmZzdiXMfaROyK35P_dXxS517WSa9Tmy1Hg&comm and=deployVirtualMachine&serviceofferingid=1&template id=291&zoneid=1&signature=eXW%2fxfqx%2fhu%2frMreF ksVsp3cT4M%3d
  28. 28. UI Go play with the UI
  29. 29. Q U EST I O N S ASK!
  30. 30. CO N TAC T Docs: IRC: #cloudstack on Freenode Twitter/ @cloudstack Mailing Lists   Forums