Considerations for building your private cloud folsom update

Editor's Notes

• #2: Goal: To give ideas on how to build private clouds powered by OpenStack software This talk is to serve as a guide not and end all be all. Ultimately you’ll have to find the right solution for your company. Ask to hold questions till the end
• #3: Plan for these talks: We’ve been using and deploying Folsom Private Clouds for 6 months, next Summit, we’ll give a Grizzly Talk Grizzly is quite a different ...”beast”... I’ll focus on some of the Grizzly features at the end
• #4: Are you looking for a cheaper VMware or a truly elastic private cloud? OpenStack Can do both but it certainly isn’t a drop in replacement for VMware Private Clouds generally not multi-tenant where tenants are different companies. However they will most likely be Multi-application which is in a sense multi-tenant since different applications require different resources. Size for Talk: Less than 100 nodes Inbound Connectivity: Floating IPs or all instances get public IPs
• #5: Problem: don’t know how many virtual machines due to flavors CPU/RAM ratio way off, disk most likely under utilized
• #6: Problem: don’t know how many virtual machines due to flavors CPU/RAM closer
• #7: Problem: don’t know how many virtual machines due to flavors CPU/RAM ratio way off
• #8: You’re the service provider, you must plan for capacity. Similar issues as traditional virt but now users can spin up on demand without going through an ops team public model: limit flavors , can pre plan capacity easily private model: closely watch capacity trends since you can’t plan as well Don’t forget about network utilization
• #9: pre-quantum you cannot add/change you fixed network -- Some ability to add different networks but users MUST pass which network they want to use at instance boot time fixed range defines maximum number of IPs per “cluster”
• #10: Fixed network is the one thing you need to get right. tell why!! Assigning a floating IP completely changes the way inbound and outbound connectivity happens. I’m giving an entire talk about nova-network tomorrow at 11:50am
• #11: format - ISO can be used to create initial image with VNC with Raw - use fixed partitioning qcow2 - gain space saving benefits without losing too much performance over raw
• #12: Explain what glance is It’s hard to realistically guess how many images or size of images you’ll be using. Expect Users to snapshot It’s simpler to standardize on base images and use automation tools to configure services within the instances.
• #15: SIngle Controller - MySQL, rabbitmq-server, keystone, glance registry/api, nova-scheduler, nova-os-api-compute, nova-cert, nova-vncproxy, horizon Network utilization will be different. Understand your current usage and plan accordingly. If worried about nic saturation, break out your nova services (glance, nova services) to a separate network, Aggregate Bonds
• #16: Convey why to consider swift 100 nodes, 2000 instances (20 nodes per), any of them could be snapshotting. Will be a bottleneck frontend backend networks frontend for external connectivity backend for instance to instance, instance to non-openstack server (dedicated DB,
• #17: If you’re not using another system (Cinder, SAN, NetApp. etc) for additional storage, IO will need to a top consideration
• #18: As I mentioned when starting, every major slide on here could be an entire talk and most of these slides are “lessons learned”
• #19: nova calls for stats and instances on a hypervisor new image types, includes ISO policy.json allows you to define which role is allowed to make a specific API call Cells - Mainly used for large clouds (500+ nodes) Quantum - default network manager working LDAP/AD integration expected