Difference between revisions of "Obsolete:Overview"
(talk) |
|||
| Line 2: | Line 2: | ||
= Architecture Overview = | = Architecture Overview = | ||
| − | The diagram below represents the | + | The diagram below represents one of the proposed architectures. It uses a distributed hierarchical approach, as opposed to a peer-to-peer approach. |
All green boxes represent pieces of software we either must write or use off the shelf. For example, the Message Queue may be Rabbit MQ, but we'll most likely need to write our own host and guest agents. | All green boxes represent pieces of software we either must write or use off the shelf. For example, the Message Queue may be Rabbit MQ, but we'll most likely need to write our own host and guest agents. | ||
| Line 8: | Line 8: | ||
All red boxes represent some form of data storage. The only persistent storage will need to be on the Hosts for account/VM information. All other tables in the Pod Controller and Public API Servers are simply caches of a subset of the Host table data needed to make informed decisions such as where to route API requests. | All red boxes represent some form of data storage. The only persistent storage will need to be on the Hosts for account/VM information. All other tables in the Pod Controller and Public API Servers are simply caches of a subset of the Host table data needed to make informed decisions such as where to route API requests. | ||
| − | Note that only | + | Note that only Cluster Controllers talk to the Public API Servers (via the message queue), Host and Guest agents should never talk directly to the API servers. Connection aggregation such as this should be used wherever possible (Guests->Host, Hosts->Cluster Controller, Cluster Controllers->Public API Servers). |
The image cache and source will most likely leverage the existing technology such as the ibacks and Cloud Files, but should be kept generic so other (possibly external) image sources are supported. | The image cache and source will most likely leverage the existing technology such as the ibacks and Cloud Files, but should be kept generic so other (possibly external) image sources are supported. | ||
| Line 14: | Line 14: | ||
The original Open Office Draw file can be found at: [[attachment:cloud_servers_v2.odg]] | The original Open Office Draw file can be found at: [[attachment:cloud_servers_v2.odg]] | ||
| − | + | [[Image:Overview$cloud_servers_v2.png]] | |
Revision as of 18:57, 9 July 2010
Architecture Overview
The diagram below represents one of the proposed architectures. It uses a distributed hierarchical approach, as opposed to a peer-to-peer approach.
All green boxes represent pieces of software we either must write or use off the shelf. For example, the Message Queue may be Rabbit MQ, but we'll most likely need to write our own host and guest agents.
All red boxes represent some form of data storage. The only persistent storage will need to be on the Hosts for account/VM information. All other tables in the Pod Controller and Public API Servers are simply caches of a subset of the Host table data needed to make informed decisions such as where to route API requests.
Note that only Cluster Controllers talk to the Public API Servers (via the message queue), Host and Guest agents should never talk directly to the API servers. Connection aggregation such as this should be used wherever possible (Guests->Host, Hosts->Cluster Controller, Cluster Controllers->Public API Servers).
The image cache and source will most likely leverage the existing technology such as the ibacks and Cloud Files, but should be kept generic so other (possibly external) image sources are supported.
The original Open Office Draw file can be found at: attachment:cloud_servers_v2.odg
