Mix&Match Federation

 

Overview

We are proposing a new set of use cases for OpenStack and a set of changes to enable a multi-landlord cloud model, where multiple service providers can cooperate (and compete) to stand up services in a single cloud, and users can federate resources between various services in various ways—“mix and match.” This page describes the model and our plan for the Newton and Ocata cycles.

MixMatch NENS Poster

MOC Workshop ’16 Slides: Mix & Match: Resource Federation


Motivation

Currently, all clouds are stood up by a single company or organization, creating a vertically integrated monopoly. Any competition is between entire clouds and is limited by the customer’s ability to move their data over the connectivity between clouds. We think an alternative model is possible, where different entities can stand up individual services within the same data center and the customer (or intermediaries acting on their behalf) can pick and choose between them. We call this model of having multiple landlords in a cloud an Open Cloud eXchange (OCX).

The OCX model would enable more innovation by technology companies, enable cloud research and provide more choice to cloud consumers. We are developing this model in a new public cloud, the Massachusetts Open Cloud (MOC), at the Massachusetts Green High Performance Computing Center (MGHPCC) data center, which is shared between Boston University, Harvard University, the Massachusetts Institute of Technology, Northeastern University and the University of Massachusetts. Some use cases being explored in the context of the MOC illustrate the potential of this model:

  • Harvard and MIT both stand up their own OpenStack cloud for students, but provide resources on-demand to the MOC that can be used by researchers that collaborate between the universities and by external users.
  • A storage company stands up a new innovative block storage service on a few racks in the MGHPCC, operates it themselves and makes it available to users of the MOC and/or the individual university clouds. The storage company is in total control of price, automation and SLA for the service; users can choose if they want to use the service.
  • A company stands up a new compute service with innovative hardware (e.g., FPGAs, crypto accelerator) or pricing model. A customer with a two Petabyte disk volume can switch to using that compute without having to move the data.
  • A research group from Boston University and Northeastern University develops a highly elastic compute service that can checkpoint thousands of servers into SSD  in seconds and broadcast provision a distributed application to allow an interactive medical imaging application that wants thousands of servers for a few seconds.
  • A security sensitive life sciences company exploits software from the MACS project to distribute their data across two storage services from non-colluding providers. The data is accessed from a Nova compute service running on a trusted compute platform developed collaboratively with Intel. Since all services are deployed in the same data center, the computation is efficient.
  • Students in a cloud computing course offered by Northeastern University and Boston University faculty develop and stand up an experimental proxy service for open stack services that provides users of the MOC a Swift service that combines the inventory of multiple underlying Swift services.

We believe solutions to the problems of the OCX model will improve OpenStack generally from a security and reliability perspective. Solving the problems of multiple providers/landlords that don’t trust each other also brings defense in depth for a single provider cloud; potentially preventing an exploit of one service from compromising an entire cloud.


Architecture

We are building on a feature added in the Kilo release of OpenStack called Keystone-to-Keystone federation.  With this feature, Keystone A can act as an identity provider for Keystone B, providing the user in the former with a SAML assertion that describes the user’s identity and permissions. Keystone B consumes this assertion and produces a token with which the user can query the services to access the resources.

Storage

The use case we are currently focusing for now, is to allow Nova to access volumes, images and snapshots in a service provider with Keystone-to-Keystone federation. For this, we have built a new OpenStack service that will act as a proxy to Cinder and Glance. Our new service will transparently forward API calls to the correct service provider after resolving the location of the resources queried, and performing the SAML exchange to get a token for the remote service.

Proxy_User
(1) User authenticates to Keystone and receives a token. (2) User asks nova to attach a volume. (3) Nova asks the Cinder endpoint (proxy) for the volume. (4) Proxy asks Keystone for a SAML assertion, which it uses (5) to receive a token for the remote cloud. (6) Finally the proxy forwards the request to the remote service.

Network

Work is planned towards allowing VMs in different clouds to connect to each other as if they had been launched on the same private network (without the need the need to assign public IP addresses to the instances). We’re currently evaluating SDN solutions such as OpenContrail and MidoNet to accomplish this. The proposed architecture will likely use router peering to forward private address traffic between clouds.


Project Team

Core Project Team

  • Kristi Nikolla (Boston University)  
  • Eric Juma
  • Jeremy Freudberg 

Contributors

  • Sean Perry (HP)
  • Jon Bell (Boston University)
  • Davanum Srinivas (Mirantis)
  • Adam Young (Red Hat)
  • Minying Lu (Boston University)
  • George Silvis III (Boston University)
  • Wjdan Alharthi (Boston University)

Timeline

2017

  • January through June: External testing in production deployments for storage
  • May through August: Work on network federation implemented as a PoC

2016

  • July: Discussion with upstream Nova team about solution architecture
  • July through October 2016: Implementing proxy service
  • October: Presenting our solution in a vBrownBag lightning talk at the Ocata OpenStack Summit in Barcelona
  • December: First release of the proxy as an upstream OpenStack project

Planning and Getting Involved

To get involved, email (mail:team@lists.massopen.cloud) or join the #moc IRC channel on freenode.  You can also look at our current status on Trello, at https://trello.com/b/BQQFdyLx

Code is available at https://github.com/openstack/mixmatch

Documentation is available at http://mixmatch.readthedocs.io

Leave a Reply

Your email address will not be published. Required fields are marked *