Difference between revisions of "MultiClusterZones"
| Line 23: | Line 23: | ||
There are a collection of Nova services that communicate together via AMQP (<code><nowiki>RabbitMQ</nowiki></code> currently). Each service has its own Queue for sending messages in. As a convenience, there are also a set of Service API stubs which handle the marshaling of commands onto these queues. There is one Service API per Service. The outside work communicates to Nova via one of the public-facing API's (currently EC2 and Rackspace/OpenStack over HTTP). Before a client can talk to the public-facing API it must authenticate against the Nova Auth Service. Once authenticated the Auth Service will tell the Client which API Service to use. This means that we can stand up many API Services and delegate the caller to the most appropriate one. The API service does very little processing of the request. Instead, it uses the Service Stub to put the message on the appropriate Queue and the related Service handles the request. | There are a collection of Nova services that communicate together via AMQP (<code><nowiki>RabbitMQ</nowiki></code> currently). Each service has its own Queue for sending messages in. As a convenience, there are also a set of Service API stubs which handle the marshaling of commands onto these queues. There is one Service API per Service. The outside work communicates to Nova via one of the public-facing API's (currently EC2 and Rackspace/OpenStack over HTTP). Before a client can talk to the public-facing API it must authenticate against the Nova Auth Service. Once authenticated the Auth Service will tell the Client which API Service to use. This means that we can stand up many API Services and delegate the caller to the most appropriate one. The API service does very little processing of the request. Instead, it uses the Service Stub to put the message on the appropriate Queue and the related Service handles the request. | ||
| + | |||
| + | This flow is shown in illustration below: | ||
| + | |||
| + | [[attachment:ZonesArchitecture_sm.png]] | ||
== Implementation == | == Implementation == | ||
Revision as of 13:46, 31 January 2011
- Launchpad Entry: NovaSpec:multi-cluster-in-a-region
- Created:
- Contributors: SandyWalsh
Summary
Older notes: http://etherpad.openstack.org/multicluster and http://etherpad.openstack.org/multicluster2
Release Note
Zones permit Nova deployments to separate groups of hosts into "Zones". Not all Zones need to contain Hosts, but rather, they may contain other Zones. This will permit finer-grained organizational structures. This proposal also allows for multiple root nodes (top-level Zones) so business units can partition the hosts in different ways for different purposes (i.e. geographical zones vs. functional zones).
Rationale
In order to scale Nova to 1mm host machines and 60mm guest instances we need a scheme to divide-and-conquer the effort.
User stories
Assumptions
Design
Let's have a look at how Nova hangs together currently.
There are a collection of Nova services that communicate together via AMQP (RabbitMQ currently). Each service has its own Queue for sending messages in. As a convenience, there are also a set of Service API stubs which handle the marshaling of commands onto these queues. There is one Service API per Service. The outside work communicates to Nova via one of the public-facing API's (currently EC2 and Rackspace/OpenStack over HTTP). Before a client can talk to the public-facing API it must authenticate against the Nova Auth Service. Once authenticated the Auth Service will tell the Client which API Service to use. This means that we can stand up many API Services and delegate the caller to the most appropriate one. The API service does very little processing of the request. Instead, it uses the Service Stub to put the message on the appropriate Queue and the related Service handles the request.
This flow is shown in illustration below:
attachment:ZonesArchitecture_sm.png
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
