Jump to: navigation, search

Proposal vDC


IaaS Provider defines Regions and Availability Zones to denote consolidated resource in Data Center(DC)s.
Then Tenant users create instances and volumes choosing Regions or Availability Zones.
However, there is no way for IaaS Providers to restrict available resources for some tenant.
This document proposes a method to control resources flexibly by making relationship between tenant and Regions and/or Availablity Zones.
The method proposed in this document also enables easy management of relationship between tenant and Regions and/or Availablity Zone in large systems, where a lot of AvailablityZones are created,
by introducing vDC concept, which combines Availability Zones into a group, into OpenStack

Problem description

That all users can utilize all of the resources has the following issues.

  • IaaS provider wants to manage to some infrastructures (ex.IaaS,PaaS,SaaS,NFV) from one openstack dashboard. but, at the same time,IaaS provider serves this openstack dashboard for IaaS as self-service portal.Then, IaaS Provider do not want to use resources for other services by tenant users of IaaS.
  • It is difficult for IaaS provider to manage the capacity of resources. because IaaS provider can not know that tenant users use of where the resources.
  • IaaS provider want to evaluate the new resources before publishing.but the new resources are adding and publishing at the same time.

Use Case

  • flexible resource assignment

IaaS Provider provides physical resources that exist among multiple data centers to tenant via OpenStack APIs. Then IaaS Provider would like to
assign physical resources flexibly according to contract to each tenant. Eg. higher level services and higher specification physical resources for some specific tenant,
or lower level services but reasonable price physical resources for all tenants.
It may be a good idea to share physical resources by some tenants to make good use of physical resources.

IaaS Provider defines various combinations of vDC and Availability Zones and assigns vDC to a tenant according to its contract.
The tenant assigned some vDC creates volumes and instances specifying Availability Zone in the vDC.
At this time, there is no need to specify Availability Zone if unnecessary.
If not specified, volumes and instances are created in the Availability Zone of assigned vDC.

  • Reseller UseCase

There may be Reseller Use Case in requirements from the customer. Reseller Use Case is the case where a Reseller buys resources in a physical data center from Iaas Provider and the Reseller sells to Tenants according to its own catalogs.
IaaS Provider does not want to allow Reseller to utilize all of the Availability Zones,
so IaaS Provider assigns vDCs to Resellers.
Reseller sells resources to Tenants within available resources. In case where Reseller needs additional vDCs,
Reseller requests IaaS Provider for new vDCs.
Reseller UseCase.jpg

  • Private Availability Zone

Tenants sometimes want to utilize physical resources without interfere from other tenants.
To meet the request, it is necessary to restrict use of Availability Zone to some specific tenants.
To do so, IaaS Provider creates some physical resource(Availability Zone) only for some specific and makes a relationship to vDC.
Then, by IaaS Provider making relationship between vDC and Project on request, tenant can utilize Availability Zone by itself.

  • Maintenance(Blocking Availability Zone)

There is a need for IaaS Provider to test Availability Zone when adding physical resources.
For this purpose, IaaS Provider creates tenant for testing and defines vDC for testing so that only testing tenant can access to the added Availability Zone.
Even in a system that is in operation, IaaS Provider can test physical resources by using the tenant for test without interference to other tenants.
After the test, by changing relationship of Availability Zone to the vDC in operation,
ordinary tenants can utilize the physical resources in the Availability Zone.

Proposed change


About vDC

Following figure shows relationship of vDC, Region and Availability Zone of OpenStack.

Proposal vDC OverView.jpg

vDC has following capabilities.

  • IaaS Provider may relate a Project to one or more vDCs(Project E) and a vDC to one or more Projects(vDC#2).
  • IaaS Provider may relate a vDC to one or more Availability Zone(vDC#3) and an Availability Zone to one or more vDC(AZ#6).
  • IaaS Provider may create a vDC over data center boundary in a Region.(vDC#1). However, Iaas Provider cannot create a vDC over Region boundary.
  • An instance created in vDC can access other instances within the same Region via Network(ProjectA). But, an instance created in vDC cannot access other instances in different Region via Network(Project E).
  • If virtual network is extensible using L2 for each Project on multiple Regions, it is possible to access other instances on different Region via Network(Project D), but this is the out of scope of this proposal.

Following figure is data model diagram.

Proposal vDC OverView-Datamodel.jpg

Relation of Component

Nova and Cinder manage relationship of vDC definition and AZ. New API and CLI should be introduced to manage vDC.
Keystone manages relationship of vDC and Project. vDC allocation function should be added to existing Project management API and CLI.
The scheduler of Nova and Cinder retrieves vDC related to Project from Keystone. Then it decides Availability Zone used to create instances and volumes.
Relationship of Horizon, Nova, Cinder and Keystone is shown as follows.

Proposal vDC Component-Relation.jpg

Data model impact

Relationship information of vDC is stored in the database of each component.
Proposal vDC Database.jpg

  • Nova, Cinder Database
    • (New)vDC-ID, vDC tables including vDC name
    • A table which relates (New)vDC and Availability Zone
  • Keystone Database
    • Project table extra column is used to store using “vdc_list_cinder” key and “vdc_list_nova”key.
      vDC information is stored in JSON string.
    • It is not allowed to specify "vdc_list_cinder" "vdc_list_nova" in "--property" option. Because they are reserved words.

The way to save relationship information of Project and vDC(AZ) in extra column may cause performance issue, because it is necessary to access all the extra column of all the Project to “show Project list which can use some vDC”. Considering performance, it may be better to introduce a new table as follows.

Proposal vDC Database2.jpg

REST API impact

  • Nova
    • vDC manipulation(Create, View, Update, Delete) API implementation
    • Manipulation API implementation to make relationship of vDC and Availability Zone
  • Cinder
    • vDC manipulation(Create, View, Update, Delete) API implementation
    • Manipulation API implementation to make relationship of vDC and Availability Zone
  • Keystone
    • Manipulation API implementation to make relationship of Project and vDC

Other Improvement

This proposal involves following improvements.

  • scheduler
    • vDCFilter is executed after AvailabilityZoneFilter and retrieve Availability Zones which can be used by the Project.

Proposal vDC VDCFilter.jpg

  • Horizon
    • [Admin]menu
      • vDC definition page to create, read, edit and delete of vDC
      • A page to make relationship between vDC and AZ on creation and edtion
    • [Identity]-[Project]menu
      • A page to make relationship between Project and vDC on creation and edtion
      • A page to show list of vDC assigned to a specific Project
    • [Project]menu
      • To change candidate Availability Zone listing to show related Availability Zone only
  • Development Step
    • Authors think introducing vDC requires new API in Keystone, Nova and Cinder and it puts tremendous impacts to the existing components.Thus authors propose to develop to assign Project to Availability Zone, not vDC.The way to do so is to manage vDC-ID in the Database as Availability Zone name.If this function is added, Nova and Cinder extract assigned Availability Zone through Keystone API and it satisfies the UseCase.But it puts some operational cost; that is, IaaS Provider must select proper Availability Zone on new contract and on addition of Availability Zone.


Alternative plan A

vDC is a concept to logically manage Availability Zones. Region is also a concept to manage multiple Availability Zones.

Instead of introducing new concept of vDC, it is possible to satisfy the Use Case to assign Regions to a Project.

Proposal vDC Architecture2.jpg

Under the idea to assign Rigion to Project, since we assign existing Region to Project, developing code volume is small and there are less changes to Database.
However, this idea depends on Region and there are some demerits as follows.

  • SI Cost

In typical operation, IaaS Provider is assumed to assign Regions to as many as from some thousands to some ten-thousands Projects.
In the case where assigning private resources to some specific tenant according to the contract, it costs too much because another Region(Controller) must be introduced.
On the contrary, vDC is a logical set of Availability Zones and reuires only one controller to assign resources to some tenant according to the contract and it costs less.

  • Maintenance(Blocking Availability Zone)

When IaaS Provider adds new physical resources to existing Availability Zone, it is necessary to test beforehand. Under testing, IaaS Provider must hide the adding resource from tenants. As tenants can use resources by Region, it is not possible to add new resources to the Region in operation.
Thus, IaaS Provider should create new Regions for adding resources and assign them to Tenant; or IaaS Provider should put some maintenance period and to test new resources during the period.
But these two ideas are not easy to take.
If we introduce vDC concept, vDC is assigned to Tenant; thus unassigned Availability Zone will never be used even in mistake.
IaaS Provider can test new resources without interfere the operation.
There is other merit in this idea, that is; by IaaS Provider temporary removing relationship information to vDC on Availability Zone failure, it is possible to hide the resources in trouble temporary.

  • Region Authentication

A tenant must specify what Region to access on multi-region configuration. In case we make relationship between Project and Region,
Keystone implementation should be changed to limit access to the project related to the Region in Keystone authentication.

Following above discussions, authors think we should take the idea to introduce vDC.

Alternative plan X

Authors wonder if we solve the proposing issue by using the filter described following URL. AggregateMultiTenancyIsolation