Federation manager demo
1 like369 views
This document discusses several use cases for federation beyond just Keystone federation between OpenStack clouds. It describes using federation for hybrid clouds with different providers like OpenStack, AWS, and Azure. It also discusses using federation for component redundancy, scaling, non-disruptive upgrades/maintenance, providing geography-based services, tracking multiple clouds, templating deployments across clouds, persisting configurations, and disaster recovery. A model is proposed for a Federation Manager that would handle persisting configurations and images between clusters while applications are responsible for syncing runtime databases.
1 of 13
More Related Content
What's hot (20)
Ad
Viewers also liked (18)
Ad
Similar to Federation manager demo (20)
More from PLUMgrid (16)
Federation manager demo
- 2. Introduction • Federation as currently being discussed in Openstack needs to be broader in scope. • When we look at federation demands, it’s not limited to Keystone Federation or federated openstack clouds. • Let’s look at some of the use cases.
- 3. Hybrid clouds Cluster 2Cluster 1 Either cluster could be a CMS like Openstack, AWS, Azure, or even a physical networking element like a CE/PE router.
- 4. Why do I need Virtual Domain peering? For component redundancy Cluster 2Cluster 1 Web App LB DB DB
- 5. More Reasons you need Virtual Domain peering For scaling Cluster 2Cluster 1
- 6. Even More Reasons you need VD peering Non-disruptive upgrades / maintenance Cluster 2Cluster 1 Cluster 2Cluster 1 Cluster 2Cluster 1Cluster 2Cluster 1
- 7. Geography based services Cluster 1 Cluster 2 Cluster 3DNS Requests GSLB NAT FIP A NAT FIP B Inter-Zone Connector Inter-Zone Connector • GSLB returns FIP A or B depending on where client is. • Health checks from GSLB to servers
- 8. KEEPING TRACK OF YOUR CLOUDS
- 9. Template Templates for the multi cloud Create Patterns once, deploy many times Template Variable Values (e.g. Floating IPs) Cluster 2Cluster 1 Cluster 3 Cluster 4 Deploy
- 10. Persisting config • To have A/A or A/S clusters everything that makes a cluster tick needs to be synchronized. • This includes config for keystone, nova, glance, neutron. • This does *not* need to cover application data – applications already have ways to sync their databases with remote clusters.
- 11. A model for Federation Manager VM images, user accounts, compute, storage and networking config DB FM Top Half FM Bottom Half App DB App DB • FM takes care of persisting configs and images. • Apps are responsible for syncing run-time databases.
- 12. Disaster Recovery VM images, user accounts, compute, storage and networking config DB FM Top Half FM Bottom Half App DB App DB
- 13. Disaster Recovery VM images, user accounts, compute, storage and networking config DB FM Top Half FM Bottom Half App DB • Keystone data, glance images etc were already synced by FM. • App’s database had been setup to do remote replication. • No impact on your keystone, swift, etc architecture or backends. • The switch from one active zone to another can be done using a GSLB or LB.