An architectural explanation of OpenStack

OpenStack is both a community and a project and an open source software that provides an operational platform or toolset for deploying the cloud. Its purpose is to help organizations run the cloud as a virtual computing or storage service, providing scalable, flexible cloud computing for public, private, and Daisho-in, small clouds.
　 1. What is OpenStack?
OpenStack is both a community and a project and an open source software that provides an operational platform or toolset for deploying the cloud. Its purpose is to help organizations run the cloud as a virtual computing or storage service, providing scalable, flexible cloud computing for public, private, and Daisho-in, small clouds.
OpenStack includes a set of community-maintained open source projects, namely Openstackcompute (Nova), Openstackobjectstorage (Swift), and Openstackimageservice ( Glance).
OPENSTACKCOMPUTE[1], a controller for cloud organizations, provides a tool to deploy the cloud, including running instances, managing the network, and controlling user and other project access to the Cloud (thecloudthroughusersandprojects). Its underlying open source project name is Nova, which provides software to control the IaaS cloud computing platform, similar to AmazonEC2 and Rackspacecloudservers. In fact, it defines the driver that interacts with the potential virtualization mechanism running on the host operating system, exposing WEBAPI-based functionality.
OPENSTACKOBJECTSTORAGE[2], is an extensible object storage System. Object storage supports a variety of applications, such as copying and archiving data, image or video services, storing secondary static data, developing new applications for data storage consolidation, storing hard-to-estimate data, and creating cloud-based resilient storage for Web applications.
Openstackimageservice[1], is a virtual machine image storage, query and retrieval system, the service includes RESTFULAPI allows users to query the VM mirroring metadata through HTTP requests, and retrieve the actual image. VM mirroring is configured in four ways: a simple file system, a openstackobjectstorage-like object storage system, stored directly with Amazon ' Ssimplestoragesolution (S3), Indirect access to S3 with S3 with ObjectStore.
The basic relationships of three items are shown in 1-1:

1-1 the relationship of OpenStack three components

　2. Concept architecture for cloud service providers
OpenStack can help us build our own IaaS and provide services like Amazonwebservice to our customers. To achieve this, we need to provide several advanced features:
A) allow the application owner to register the cloud service to view usage and billing;
b) Allow developers/devopsfolks to create and store custom images of their application;
c) allow them to initiate, monitor and terminate instances;
d) Allow Cloudoperator to configure and operate the infrastructure
These four points are straight-click to provide the core of the IaaS, now suppose you agree with these four features, and now you can put them into the conceptual schema 2-1 as shown below.

2-1 OpenStack Conceptual Architecture

In this model, the author assumes that there are four user sets that need to interact with the cloud: developers,devops,ownersandoperators, and divides the functionality needed for each type of user. The architecture uses a very common layering method (presentation,logicandresources) with two orthogonal regions.
The presentation layer, the component interacts with the user, receives and renders the information. Webportals provides a graphical interface for non-developers to provide API endpoints for developers. In the case of more complex structures, load balancing, control agents, security, and name services will also be in this layer.
The logic layer provides logic (intelligence) and control functions for the cloud. This layer includes deployment (workflow for complex tasks), scheduling (Job-to-resource mapping), policies (quotas, and so on), mirroring registration of Imageregistry (metadata for instance mirroring), logs (events and metering).
Assume that the vast majority of service providers already have customer identities and billing systems. Any cloud architecture needs to integrate these systems.
In any complex environment, we will need a management layer to operate the environment. It should include an API Access Cloud management feature as well as some form of monitoring (forms). It is likely that the monitoring feature will be incorporated into an existing tool in the form of consolidation. The current architecture already includes monitoring and ADMINAPI for our virtual service providers, and in a more complete architecture you will see a range of support features such as provisioning and configurationmanagement.
Finally, the resource layer. Since this is a compute cloud, we need the actual compute, network and storage resources to supply to our customers. This layer provides these services, whether they are servers, network switches, NAS (networkattachedstorage), or some other resource.
　　 3. OpenStack COMPUTE Architecture
3.1 OpenStack COMPUTE Logic Architecture
In the OpenStack compute logical architecture, the vast majority of components can be divided into two custom-written Python daemons (custom written Python daemons).
A) Wsgi application for receiving and coordinating API calls (NOVA-API, GLANCE-API, etc)
b) The worker daemon that performs the deployment task (Nova-compute, nova-network, Nova-schedule, etc.)
However, there are two important parts of the logical architecture, neither custom-written nor Python-based, which are message queues and databases. Both simplify the asynchronous deployment of complex tasks (tasks that pass through messaging and information sharing).
The logical architecture Figure 3-1 looks like this:

3-1 OpenStack COMPUTE Logic Architecture

, we can sum up three points:
A) end users (DevOps, developers, and other OpenStack components) interact with OpenStack compute through and NOVA-API conversations.
b) The OpenStack compute daemon exchanges information between queues (behaviors) and databases (information) to execute API requests.
c) OpenStack Glance is essentially an independent infrastructure, and OpenStack compute interacts with it through the Glance API.
The individual components are as follows:
A) The Nova-api daemon is the hub of the OpenStack compute. It provides endpoints for all API queries (OpenStack API or EC2 API), initializes most deployment activities (such as running instances), and implements some policies (the vast majority of quota checks).
b) The Nova-compute process is primarily a worker daemon that creates and terminates virtual machine instances. The process is quite complex, but the rationale is simple: receive the behavior from the queue, and then execute a series of system commands to execute them when the state of the database is updated.
c) Nova-volume manage the creation, append, and cancellation of volumes mapped to computer instances. These volumes can come from many providers, such as iSCSI and AoE.
D) The Nova-network worker daemon is similar to Nova-compute and Nova-volume. It receives network tasks from the queue and then executes tasks to manipulate the network, such as creating bridging interfaces or changing iptables rules.
e) Queue provides a central hub to deliver messages to the daemon. Currently implemented with RABBITMQ. But in theory it could be any AMPQ message queue supported by Python ampqlib.
f) The vast majority of compile-time and run-time state in SQL database storage cloud infrastructure. This includes the available instance types, the instances that are used, the networks and projects that are available. In theory, OpenStack compute can support any database supported by Sql-alchemy, but the currently widely used database is sqlite3 (suitable only for testing and development work), MySQL and PostgreSQL.
g) OpenStack Glance, is a separate project, which is an optional part of the compute architecture, divided into three parts: Glance-api, Glance-registry and the image store. Where Glance-api accepts API calls, Glance-registry is responsible for storing and retrieving the mirrored metadata, and the actual image blob is stored in the image store. Image Store can be a number of different object stores, including OpenStack object Storage (Swift)
h) Finally, user Dashboard is another optional project. OpenStack Dashboard provides an OpenStack compute interface for application developers and DevOps staff-like APIs. It is currently implemented as a Django Web application. Of course, there are other Web front ends available as well.
　 3.2 Conceptual Mapping
By mapping the logical schema to the conceptual schema (as shown in 3-2), you can see what we are missing.

3-2 mapping of logical schemas to conceptual schemas

This type of coverage is not unique, but the author's understanding. The functional range is represented by overriding the OpenStack Compute logic components, glance and dashboard. For each overlay, there is a corresponding name for the logical component that provides the feature.
A) The biggest gaps in this coverage are logging and billing. At the moment, OpenStack compute does not have billing components that coordinate logging events, log logs, and create/render bills. The real focus is on the integration of logging and billing. This can be remedied in the following ways. such as code expansion, commercial products or services or custom log parsing integration.
b) Identity is also a point that may be added in the future.
c) Customer Portal is also a consolidation point. User Dashboard (see Running instances, starting a new instance) does not provide an interface to allow app owners to sign services, track their costs, and declare problematic tickets (lodge trouble tickets). Moreover, this is likely to be appropriate for the service providers we envision.
D) Ideally, the Admin API will replicate all the features we can do with the command line interface. It's better in Diablo release with admin API work.
e) Cloud monitoring and operation will be the focus of service providers. The key to good operating methods is good tools. Currently, OpenStack Compute provides nova-instancemonitor, which tracks the usage of compute nodes. We also need three-party tools to monitor the future.
f) Policy is an extremely important aspect, but it is very relevant to the supplier. From quotas to QoS, to privacy control is within its jurisdiction. There is a partial overlay on the current diagram, but this depends on the complex requirements of the vendor. For the sake of accuracy, OpenStack Compute provides quotas for instances, floating-point IP addresses, and metadata.
g) At present, the scheduling within the OpenStack compute is quite preliminary for large installations. The scheduler is designed as a plug-in that currently supports chance (random host allocation), simple (least load), and zone (random nodes in a usable area). A distributed scheduler and a scheduler that understands heterogeneous hosts are under development.
As you can see, OpenStack compute provides a good basis for our imagined service providers as long as the service providers are willing to do some consolidation.
　　 3.3 OpenStack Compute system Architecture
OpenStack compute is made up of a number of major components. The Cloud controller contains many components that represent the global state and interact with other components. In fact, it provides the NOVA-API service. Its function is to provide an endpoint for all API queries, initialize the vast majority of deployment activities, and implement some policies. The API server acts as a cloud Controller Web service frontend. Compute Controller provides Compute service resources, typically including Compute Service,object store component optionally providing storage services. Auth Manager provides authentication and authorization services, and Volume controller provides fast and durable block-level storage for compute servers. Network controllers provide virtual networks that enable compute servers to interact with each other and with the public network. Scheduler Select the most appropriate compute controller to manage an instance of (host).
OpenStack Compute is built on a non-shared, message-based architecture. Cloud controller interacts with the internal object store via HTTP and communicates via AMQP and scheduler, network controller, and volume controller. To avoid blocking each component while waiting to be received, OpenStack compute is invoked asynchronously.
To obtain a no-sharing attribute with multiple backups of one component, OpenStack Compute maintains all of the cloud system state in a distributed data store. Updates to the state of the system are written to this store, with a proton transaction if necessary.
Requests for system status are read from the store. In rare cases, the controller also caches the read results for a short time.
　 3.4 OpenStack Compute Physical Architecture
OpenStack Compute employs a non-shared, message-based architecture and is flexible enough to install each nova-service on a separate server, which means there are several possible ways to install OpenStack compute. The only federated dependency that may be deployed by multiple nodes is that dashboard must be installed on the NOVA-API server. Several deployment architectures are as follows:
A) Single node: One server runs all nova-services and also drives virtual instances. This configuration is intended only for the purpose of trying OpenStack Compute, or for development purposes;
b) Double node: A cloud controller node runs nova-compute all nova-services,compute nodes except Nova-compute. A client computer will most likely need to package the image and interact with the server, but it is not necessary. This configuration is primarily used for proof of concepts and development environments.
c) Multi-node: by simply deploying Nova-compute on an additional server and copying the nova.conf file to this new node, you can add more compute nodes on the basis of the two nodes to form a multi-node deployment. In a more complex multi-node deployment, you can also add a volume controller and a network controller as additional nodes. At least 4 nodes are best for running multiple instances of virtual machines that require a lot of processing power.
One possible OpenStack compute multi-server deployment (virtual servers in cluster networking may change) as shown in the following 3-3:

3-3 OpenStack Compute Physical Architecture One

If you notice that a large number of replication in Message Queuing raises performance issues, an optional schema is to add more messaging servers. In this case, an additional RABBITMQ server can be added, in addition to the ability to extend the database server. Any nova-service can be run on any server in the deployment, as long as the nova.conf is configured to point to the RABBITMQ server, and these servers can send messages to it.
3-4 is another multi-node deployment architecture.

3-4 Multi-node deployment Architecture II

　　3.5 OpenStack Compute Service Architecture
Because compute has multiple services, there may be multiple configurations, 3-5 shows the overall service architecture, and the communication system between the services.

3-5 OpenStack Compute Service Architecture

　　 4. OpenStack Image Service
The OpenStack Image service consists of two main parts, namely API server and registry server (s).
The OpenStack Image service is designed to be as suitable as possible for a variety of back-end warehousing and registration database scenarios. API Server (Running the "Glance API" program) acts as a communication hub. For example, a variety of client programs, the registration of mirrored metadata, the actual storage system that contains virtual machine image data is communicated through it. API server forwards the client's request to the mirror metadata registry and its backend warehousing. The OpenStack image Service is the mechanism through which virtual machine images are actually saved.
The back-end repositories supported by OpenStack Image service are:
A) OpenStack Object Storage. It is an object storage item that is highly available in OpenStack.
b) FileSystem. The default backend for the OpenStack Image Service store virtual machine image is the back-end file system. This simple backend writes the image file to the local file system.
c) S3. The backend allows the OpenStack Image Service store virtual machine to be mirrored in the Amazon S3 service.
d) HTTP. The OpenStack image Service can read the available virtual machine images over the Internet over HTTP. This storage method is read-only.
OpenStack Image Service Registry servers is a server that adheres to the OpenStack Image Service registry API.
Depending on the installation manual, the two services are installed on the same server. The image itself can be stored in the OpenStack Object Storage, Amazon's S3 infrastructure,filesystem. If you only need read-only access, you can store it on a single Web server.
　 5. OpenStack Object Storage
5.1 Key Concepts
A) accounts and account Servers
The OpenStack Object storage System is designed to be used by many different storage consumers or customers. Each user must identify themselves through the authentication system. For this purpose, OpenStack Object storage provides an authorization system (Swauth).
The nodes running the account service are different from the individual accounts. The account server is part of the storage system and must be configured with the container server and the Object Server.
b) authentication and Access Permissions
You must authenticate with the authentication service to receive the OpenStack Object storage connection parameters and authentication tokens. The token must be passed for all subsequent container/object operations. Typical, language-specific APIs handle authentication, token delivery, and HTTPS request/response communication.
By using X-container-read:accountname and X-container-write:accountname:username, you can perform access control for a user or an account against an object. For example, this setting allows any user from the AccountName account to read, but only the user username in the AccountName account is allowed to write. You can also grant public access to objects stored in OpenStack object storage, and you can restrict public access by Referer headers that block site-based content theft like hot links. The public container setting is used as the default authorization on the Access Control list. For example, X-container-read:referer:any This setting allows anyone to read from Container, regardless of other authorization settings.
In general, each user has full access to his or her storage account. Users must authenticate with their certificates, and once they are authenticated, they can create or delete container, as well as objects such as accounts. The only way a user can access the content of another account is to have an API access key or a session token provided by your authentication system.
c) Containers and Objects
A container is a storage compartment that provides you with a way to organize the data that belongs to you. It is more similar to a folder or directory. The main difference between container and other file system concepts is that containers cannot be nested. However, you can create countless containers within your account. But you have to have a container on your account because the data must exist in container.
The container naming limit is that they cannot contain "/" and are less than 256 bytes in length. The length limit also applies to the URL-encoded name. For example, the container name of Course docs is "course%20docs" after URL encoding, so the length of this time is 13 bytes instead of 11 bytes.
An object is a basic storage entity, and any optional metadata that represents a file that you store in an OpenStack Object storage system. When you upload data to OpenStack object Storage, it is stored as is, by a location (container), object name, and Key/value to any metadata that is composed. For example, you can choose to store copies of your digital photos and organize them into an album. In this case, each object can be album with metadata:
Caribbean Cruise or Album:aspen Ski trip to mark.
The only limitation on object names is that they are less than 1024 bytes long after URL encoding.
The maximum allowable size of the uploaded storage object is 5GB, and the minimum is 0 bytes. You can use the embedded large object support and the St tool to retrieve more than 5GB objects. For metadata, each object should not exceed 90 key/value pairs, and the total byte length of all key/value pairs should not exceed 4KB.
D) Operations
Operations is the behavior you perform on an OpenStack Object storage system, such as creating or deleting containers, uploading or downloading objects, and so on. A complete list of operations can be found on the development documentation. Operations can be executed through REST Web service APIs or language-specific APIs. It is worth emphasizing that all operations must include a valid authorization token from your authorized system.
e) Language-specific API bindings
Some popular language-supported API bindings are available in the Rackspace Cloud file product. These bindings provide a layer of abstraction on the underlying rest API that allows people to interact directly with the container and object models, rather than HTTP requests and responses. These bindings are free to download, use and modify. They follow the MIT license agreement. For OpenStack Object Storage, the currently supported API bindings are: Php,python,java,c#/.net and Ruby.
　　 how 5.2 Object storage works
A) Ring
The Ring represents the name of the entity stored on the disk and the mapping of their physical location. accounts, containers, and objects all have separate ring. Other components to do anything in one of these three, they all need to interact with the corresponding ring to determine its location in the cluster.
The ring uses zones,devices,partitions, and replicas to maintain the mappings, and each partition in the ring has a default of three replicas in the cluster. The location of the partition is stored in the map maintained by the ring. The ring is also responsible for determining which devices are succeeding in a failed scenario. (This is similar to the replication of HDFs replicas). A copy of the partition is guaranteed to be stored in a different zone. The ring's partitions are distributed across all the devices of the OpenStack Object Storage installation. When a partition needs to be moved, the ring ensures that the partition is moved at least once, and only one copy of the partition is moved at a time.
Weights can be used to balance the distribution of partitions on disk drives. The ring is used in proxy servers and some background processes.
b) Proxy Server
The proxy server is responsible for combining the other parts of the OpenStack Object storage schema. For each request, it queries the ring for the location of the account, container, or object, and forwards the request. Public APIs are also exposed through proxy servers.
A large number of failures are also handled by the proxy server. For example, if a server is not available, it will ask the ring to find the next server for it and forward the request there.
When objects flow into or out of Object Server, they are either streamed to the user through a proxy server or obtained from the user through it. Proxy servers do not buffer them.
Proxy server functions can be summarized as: query location, processing failure, transit objects.
c) Object Server
Object Server is a very simple BLOB storage server that can store, retrieve, and delete objects on a local disk, which is stored in a file system as a binary file, with metadata stored in the extended properties of the file.
Objects are stored in a path that originates from the hash of the object name and the timestamp of the operation. The last write always succeeds, making sure that the latest version will be used. Delete is also considered as a version of the file: This ensures that deleted files are also copied correctly, and older ones are not mysteriously disappearing due to failure scenarios.
d) Container Server
Its main job is to work with the object list, which does not know where the object is, just what objects are in a particular container. Lists are stored as SQLite database files, which are replicated in the cluster in a way similar to objects. Tracking statistics are also included, including the total number of objects, and the total amount of storage used in container.
e) Account Server
It is similar to container Server, except that it is responsible for the list of containers rather than the object.
f) Replication
The purpose of the replica design is to keep the system in a consistent state when faced with temporary error conditions such as network outages or drive failures.
The copy process compares the local data and each remote copy to ensure that all of them contain the latest version. The object copy uses a hash list to quickly compare the fragments of each partition, while the Containe and account replication use a combination of hash and shared high-watermark methods.
The updates to the replicas are based on push. For an object copy, the update is a remote synchronization file to peer. Account and container replication the entire database file via HTTP or rsync to push the missing record.
The copy also ensures that the data is purged from the system by setting the latest version of the tombstone.
g) Updater (updaters)
Sometimes, container or account data cannot be updated immediately, usually in the event of a failure or a high load period. If an update fails, the update is queued locally on the file system and the updater handles these failed updates. The Event consistency window (eventual consistency windows) is most likely to work. For example, suppose a container server is being loaded, a new object is being put into the system, and the proxy server succeeds in responding to the client, and the object is immediately readable. However, the container server does not update the object list, so the update enters the queue to wait for later updates. Container list, so it may not be included immediately.
In fact, the consistency window is just as large as the updater run, and may not even be noticed when the proxy server forwards the manifest request to the first container server of the response. The server under load may not be the one that the service follow-up checklist requests. One of the other two replicas may handle this list.
h) Auditors
Auditors will check the integrity of objects, containers, and accounts. If the file is damaged first, it will be quarantined and the good copy will replace the bad file. If other errors are found, they are logged into the log.
　　 5.3 OpenStack Object Storage Physical Architecture
Proxy services tend to be CPU and network I/O intensive, while Object services, Container services, Account services favor disk and networki/o intensive.
You can install all of the services on each server, and within Rackspace, they place proxy services on their own servers, and all storage services on the same server. This allows us to send a 10G network to the agent, 1G to the storage server, thus maintaining better management of load balancing on the proxy server. We can expand the overall API throughput by adding more proxies. If you need to get more throughput from account or Container services, they can also be deployed to their own servers.
When you deploy OpenStack Object storage, you can install a single node, but it is only for development and testing purposes. You can also install multi-server, which can obtain the high availability and redundancy required by the distributed object Storage System.
There is such a sample deployment architecture as shown in 5-1. A proxy node, running the proxy service, a auth node, running the authentication service, five storage nodes, running Account,container and Object Services.

5-1 Five storage nodes of the OpenStack Object storage physical Architecture

This article source: DOIT

Reference documents
[1] OpenStack Compute administration Manual.
Http://docs.openstack.org/cactus/openstack-compute/admin/content.
[2] OpenStack Object Storage Developer guide.http://docs.openstack.org/.

An architectural explanation of OpenStack