OpenStack Latest Version Folsom schema resolution

Two years ago OpenStack based on the NASA Nova project and the Rackspace Swift Project merger, OpenStack has become a new star in the Cloud computing field, following the release of the Essex version in April 2012, At the end of September this year OpenStack 6th edition Folsom officially released, this article briefly analyzes the OpenStack Folsom architecture.

Folsom Logical Structure diagram

Object Store

Swift is distributed so that it can prevent problems on any single node and extend horizontally. It contains the following components:

Prox Server: It is responsible for accepting incoming requests by the OpenStack Object API, or directly accepting HTTP requests. Accepted requests have file uploads, modify meta data, and create container units. In addition, a list of files and Continer is provided for browsers. Usually we use an optional cache to improve its performance.

account Servers: they are responsible for managing accounts created by the object storage service. Container Servers: They are responsible for managing the containers (i.e., folder) mappings within the object storage service. Object Servers: They are responsible for managing the true objects on the storage node. (i.e. file)

There are usually a number of periodic processes on the server that are used to perform day-to-day tasks. The most important of these is replication services, which ensures consistency and usability through clustering. Other cyclical processes are: Auditors,updaters and Reapers.

The object store also serves static pages and objects through HTTP. In real time, the picture in this article is the SWITF service from Rackspace Cloud.

Image Store

Since the release of the Cactus version, the glance structure is relatively stable. The biggest structural change is probably the inclusion of authentication in the Diablo version. Let's take a quick look at the four main sections of glacnce:

GLANCE-API: She accepts the image API's discovery picture, retrieves the picture and the request that stores the picture. Glance-registry: She stores, processes, and retrieves meta picture meta data. (such as size, type, etc.) a database that stores picture metadata. Like Nova, you can choose your database based on your requirements. (But most people choose MySQL or SQLite) a picture library for storing actual picture files. In the image above, Swift is treated as a picture library and is configurable. In addition to swift,glance support for common file systems, Rados block devices, Amazon S3 and HTTP. One of the things you need to be aware of is that some of these choices have read-only limits.

As you can see in the conceptual structure above, glance is a central role in all IaaS image services. She accepts an API requests from a picture (or image metadata) from a terminal user or Nova component, and she can have her files in object storage Service (Swift).

Identity

Keystone integrates OpenStack Policy,catalog,token and authentication functions. Not only handles API requests, but also provides catalog,policy,token and identity services that can be configured.

Each Keystone feature has a plug-in background with a unique service that allows it to be used in different ways. Most functions support standard backgrounds, such as ldap,sql and key Value stores.

Receptacle

Quantum provides a network connection service between other interface devices OpenStack service management. She first allows users to create their own networks and then provide them with interfaces. Like other OpenStack services, Quantum uses a plug-in structure that allows him to be configured in detail. These plug-ins use different network devices and software. In this way, the structure and deployment are very flexible. In the structure above, a very simple Linux network is used.

Quantum-server: Accept API requests and then forward them to the appropriate quantum plugin for execution. Quantum Plug-ins and agents to perform plug-ins add or unload, create network or subnet and IP address assignment, and other practical operations. These plug-ins and proxies depend on different companies and use different technologies in a particular cloud service. Quantum loaded Plug-ins and agents are: Cisco's virtual and physical switches, Nicira NVP products, NECO openflow products, Open vswitch,linux bridging and rye network operating systems. Midokua also provides a plug-in for the Quantum integration service. The general agent in Quantum has L3,DHCP and custom proxy plug-ins. Most quantum devices use a message queue to forward information between Quantum-server and various agents, as well as a database that stores the status of each plug-in's own network. Quantum primarily interacts with Nova, and Nova provides networks and links to his examples.

Block Storage

Cinder separates some of the persistent block storage features from previous OpenStack compute into its own services. The OpenStack block storage API allows processing of volumes, volume types, and snapshots of volumes.

Cinder-api Accept API requests and forward them to cinder-volume for execution. Cinder-volume reads and writes requests to handle the maintenance state of the cinder database, interacting with other processes through Message Queuing and directly on a block storage device or software. Very similar to Nova-scheduler, background process Cinder-scheduler will choose to create volumes on the optimal block storage delivery node. Cinder deployments also uses Message Queuing to forward messages between cinder processes and uses a database to store the status information for these volumes. Similar to quantum, cinder primarily interacts with Noa, providing her with an instance of the volume needed.