The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
Building a Dev/Test Cloud with Apache CloudStack
1. Building a Dev/Test cloud with
Apache CloudStack
David Nalley
PMC Member Apache CloudStack
Member, Apache Software Foundation
ke4qqq@apache.org
Twitter: @ke4qqq
2. #whoami
• Apache Software Foundation Member
• Apache CloudStack PMC Member
• Recovering Sysadmin
• Fedora Project Contributor
• Zenoss contributor
• Employed by Citrix in the Open Source Business Office
3. Why use cloud?
From a dev point of view the process looks like:
• Start new project
• File ticket for resources....wait....wait....wait
• Get resources, that aren't configured....wait...
• Get network access.....get permission....wait
• Get things done.
4. Why use cloud?
• What IT Ops provides is not what developers want.
5. Get rid of the waiting!
●
Remove constraints - developers empowered to get
things done.
●
Agility
●
Enforce automated process instead of manual ones
6. What does a dev/test cloud look like?
●
Self-service - developers can provision their own
environments
●
Usage measurement - we worry about VM sprawl
●
Isolated networks - must not let dev/test interfere with
the real world.
●
Commodity - as cheap as practical
●
May also house production workloads
7. Self service
●
Provisioning manually doesn't add value
●
Can be completely automated
●
Do they need full control or just pushing pre-configured
environments?
14. Usage
● Jevons Paradox
● Plenty of waste possible as well - will developers always
destroy a machine when they are done with it?
● Important to show what projects and groups are
consuming resources as well as how they are using
those resources
15. Commodity Storage
● Commodity storage - this is dev/test environment - high
performance, resilient storage isn't needed.
● Local storage tends to be the best mix of cheap and
performant
● No failover, but it's dev/test - do you need it?
16. Commodity Networking
● Layer 3 isolation - (aka Security Groups)
● VLANs - (not as commodity, but still relatively cheap on
a small scale, but not at a large scale)
● Virtual routers (provide DHCP, DNS, LB, Firewall, PF,
NAT, etc)
17. Commodity Hypervisor
● KVM is my personal choice in this space.
● Easiest to consume - completely open source
18. Limiting Resources
● Limit the number of VMs, snapshots, IP addresses, etc.
● Use 'projects' to share resources
● This means most folks will never have problems, but
heaviest users will not be able to interrupt service for
others.