Cinder System Architecture --- Cinder 系统架构

Cinder架构分析

The Cinder Block Storage Service is intended to be ran on one or more nodes. 

Cinder uses a sql-based central database that is shared by all Cinder services in the system. The amount and depth of the data fits into a sql database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, cinder will be moving towards multiple data stores with some kind of aggregation system.

Components

主要组件图

                                                 /- ( LDAP )
                             [ Auth Manager ] ---
                                    |            \- ( DB )
                                    |
                                    |
                   cinderclient     |
                  /             \   |
[ Web Dashboard ]-               -[ api ] -- < AMQP > -- [ scheduler ] -- [ volume ] -- ( iSCSI )
                  \             /   |
                   novaclient       |
                                    |
                                    |
                                    |
                                 < REST >

• DB: sql database for data storage. Used by all components (LINKS NOT SHOWN)
• Web Dashboard: potential external component that talks to the api
• api: component that receives http requests, converts commands and communicates with other components via the queue or http
• Auth Manager: component responsible for users/projects/and roles. Can backend to DB or LDAP. This is not a separate binary, but rather a python class that is used by most components in the system.
• scheduler: decides which host gets each volume
• volume: manages dynamically attachable block devices.

Introduction

After the April Essex release, there’s big change in planned for OpenStack‘s volume management; it is now called Cinder.

Cinder is a new service for OpenStack, one that separates storage management logic. Until now, in the Essex release, this logic was a part of Nova, and was called the nova-volume component. But, as often happen in software, logical interdependencies between components within Nova became more and more complex, so the project developers decided to make storage management logic separate from Nova and create Cinder.

In fact, this is one of the first instances  of OpenStack’s recent development policy of breaking all Nova components into smaller building blocks. Nova had become a bulky piece of software;  development in one area was too often contingent on knowledge of others. By decoupling Nova into smaller chunks and interfacing them, developers can focus on developing these chunks as long as they provide the proper API for other services to plug in. This allows a better focus on different areas of OpenStack.

OpenStack Cinder: feature list

For Cinder, the separation from Nova is mainly organizational in nature—the project is now literally a copy-paste version of old nova-volume code with a separate database. The main goal for Cinder in the Folsom release is to provide the same API and features as in the current nova-volume, plus prepare for further focused work on the topic  in future releases.

The bottom line is: in Folsom we are just getting our old buddy nova-volume; at the same time, the developers managed to put some cool new features in this release and also lay some groundwork for the future:

• “volumes from images” — this feature is addressed in the following two blueprints accepted for Folsom: creating volumes from images and efficient volumes from images. This feature allows for the creation of bootable volumes directly from glance images and is further used by the “boot from volume” feature of Nova.
• Still TBD:  “multi volume backend”, which will allow users to take advantage of different storage providers with a single installation of Cinder. It is addressed in this blueprint and is still undergoing code review.

One of the Cinder project’s main roles is serving as the abstraction layer for different storage devices. Currently the following list of storage backends is supported, directly through their respective native APIs:

• IBM Storwize V7000 unified storage system
• IBM XIV Storage System series
• NetApp onTap devices. Both the volume as a block device and the volume as a file on NFS are supported.
• SheepDog storage system
• SolidFire high performance SSD storages
• NexentaStor Appliance

Cinder structure

Cinder consists of three basic services—Cinder API, Cinder scheduler, and Cinder volume, plus the underlying dedicated database.

 

Cinder API is a web service (providing a RESTful interface) responsible for handling user requests. In an OpenStack cluster, there can be many hosts that run the Cinder volume component. In order to load-balance volume creation between Cinder volumes, there is a Cinder scheduler component that implements this logic. The Cinder volume service is basically an abstraction layer to the different storage backends listed above.

Connection with the old nova-volume API

Despite migrating volume functionality to the separate project, Nova still supports volume management as originally implemented in the nova-volume component. Which approach to use is up to you when you install, but keep in mind that the plan is to completely remove volume management from Nova. By default Nova will use nova-volume, but it can be easily switched to Cinder by setting a flag:

1	volume_api_class = nova . volume . cinder . API

The user is free to use the old, familiar “nova volume-*” commands, or can switch to the brand new “python-cinderclient.” These commands provide exactly the same behavior:

1 2 3 4 5

#creation of the volume sized 10 GB with python-cinderclient cinder create -- display_name vol0 10 #creation of the volume sized 10 GB with python-novaclient nova volume - create -- display_name vol0 10

Final observations

In sum, Cinder offers stability with respect to nova-volume features, but simplifies code maintainability. While that may be a disappointment to some who expect constant activity in new features, it’s really an important sign of maturity, as it opens the code base to broader innovation with greater depth in storage functionality.

Stay tuned for our upcoming post which will deal with high availability of API services in Openstack.