Download presentation
Presentation is loading. Please wait.
1
Mix & Match: Resource Federation
Kristi Nikolla Massachusetts Open Cloud
2
The Massachusetts Open Cloud
Multiple Landlords: BU, MIT, Northeastern, Harvard, UMass Universities want to administer their own hardware Each university has their own auth framework, and will not trust a centralized Keystone So they will want to set up OpenStack themselves Open Cloud eXchange Competing service providers standing up services in their own OpenStack deployments Users can combine resources from different service providers: “mix and match”
3
Resource Federation Allow OpenStack services to consume resources from services in other OpenStack deployments Resources are volumes, images, snapshots, etc. Resource Federation is the first step towards OCX
4
Challenges Preserving API and user experience
Combine information from multiple providers Uniquely qualifying resources Authentication and authorization Security Scalability Performance And we had to solve some challenges, both on an architectural and implementation level. Preserving the API to preserve compatibility with Horizon and other clients, and still being able to combine information from multiple providers and allow users to perform targeted actions. An auth framework that crossed the OpenStack boundaries, without compromising security, but enhancing it. And do all of this in a scalable way without degrading performance. That’s a lot of challenges, so let’s go through them.
5
Combining information: Meta-Projects
Every resource is owned by a project Projects are mapped with each other to form a meta-project User is presented with combined view of all resources in meta-project Project: BigDataResearchCollab Boston University Northeastern University MIT volume1 volume2 volume1 img1
6
Uniquely Qualifying Resources
Everything in OpenStack is identifying by a UUID UUIDs are unique, even across multiple service providers We didn’t need to change the API to uniquely qualify the target resource We can combine without naming conflicts
7
$ openstack volume list
ID Volume Name Service Provider 3294C96D...831DBCCB1F73 volume1 Northeastern University AFB5236E...768B8BF5801C volume2 890DD196...C017D93E1AA3 MIT Project: BigDataResearchCollab Boston University Boston University Northeastern University MIT vm1 volume1 volume2 volume1 img1
8
$ openstack server add volume vm1 3294C96D...831DBCCB1F73
Project: BigDataResearchCollab Boston University Northeastern University MIT vm1 volume1 volume2 volume1 img1
9
Northeastern University
Crossing boundaries Boston University Northeastern University Keystone Keystone Nova Cinder mixmatch (Proxy)
10
Authentication and Authorization
Keystone-to-Keystone federation SAML2 assertion contains user attributes Keystone maps roles on projects based on those attributes We exploit this to implement the meta-project Northeastern University Boston University Keystone Keystone
11
Northeastern University
Boston University Northeastern University Keystone Keystone Nova Cinder mixmatch (Proxy)
12
Northeastern University
Keystone Boston University Cinder Keystone where? MIT Nova Keystone mixmatch (Proxy) Cinder
13
How It Works Every request in OpenStack is done through the REST API Resource UUID are a predictably located part of the URL Proxy analyzes URL for UUID Call Action GET w/o UUID Aggregate GET w UUID Find resource PUT/PATH w UUID DELETE w UUID POST Be more explicit? Header API to the proxy from the client
14
Finding Resources Search by broadcasting
→GET volume1 ←404 Not Found Search by broadcasting Proxy will query service providers until it finds the resource with the requested ID. Does not scale to many SPs BU NU →GET volume1 ←200 OK MIT volume1
15
Performance Improvements
Cache Tokens Local Token → Service Provider, Project ID, Remote Project Cache Resource Mappings in DB after finding resources Ideally, proxy should already know the location...
16
Finding Resources (part 2)
MIT Listen to notifications, and store in DB More scalable, requires more trust volume1 created in project mixmatch Agent Boston University Cinder mixmatch (Proxy) AMQP DB volume1
17
Data plane No performance degradation in data plane iSCSI Ceph/RBD
Just works™ Credentials for the volume are passed in API calls, so no more access is granted than needed. Ceph/RBD Works, however... All compute nodes must have all Ceph authentication keys This requires a high amount of trust between service providers We’re working with the Ceph developers to address these issues
18
Beyond Open Cloud eXchange
Adding experimental services to a production cloud Partial upgrade of cloud services—standing up multiple versions at once Defense in depth—limiting scope of a security breach As a user of an open-cloud exchange… As a cloud administrator, even if you don’t use the OCX model, you might want to
19
Future Work Deploying in production Security
More granular permission model for Ceph/RBD Limit information exposed from proxy agent Federation of networks across service providers Testing cross-attach with other Cinder backends Benchmarking the API overhead Becoming an official OpenStack project Check us out!
Similar presentations
