A, cinder description:
Understanding Block Storage
Operating system to obtain storage space, there are two general ways:
-
Attached via a protocol (SAS, SCSI, SAN, iSCSI, etc.) bare hard disk, and then partition, format, creating a file system; or directly using raw data stored in a hard disk (database)
-
By NFS, CIFS and other protocols, mount remote file systems
The first method is called bare hard Block Storage (memory block), also commonly referred to each of the bare hard Volume (volume) is called the second file system storage. NAS and NFS server, and a variety of distributed file storage system provides all this.
理解 Block Storage Service
Block Storage Servicet provides management of volume from creation to delete the entire life cycle. From the point of view instance, mount each Volume is a hard drive. OpenStack Block Storage Service is provided Cinder, whose specific function is:
1. Provide REST API enables users to query and manage volume, volume snapshot and volume type
2. Provide scheduler scheduling request to create a volume, optimize allocation of storage resources
3. supports a variety of back-end (back-end) storage by driver architecture, including LVM, NFS, Ceph and others, such as EMC, IBM and other commercial storage products and solutions
Cinder architecture
The figure is a logic chart cinder
openstack endpoint list |grep cinder
cinder-api received HTTP API requests will be processed as follows:
1, check the client-human transmission parameters are valid
2, handle client calls cinder other sub-service request
3, the cinder other sub-service results returned by the serial number and returned to the client
cinder-volume
Management of service volume, and volume provider coordination, volume management lifecycle. Nodes running cinder-volume service is referred to as a storage node.
OpenStack is a distributed system, each sub service can be deployed anywhere, as long as the network can communicate. Whatever the node, as long as the above run the cinder-volume, it is a storage node, of course, on that node can run other OpenStack services.
In general, volume provider independent. cinder-volume communication driver provider and the volume used and coordination. So just to driver and cinder-volume put together on it. There are a lot of driver source code directory in the cinder-volume, support for different volume provider.
Two, Cinder design philosophy:
flow chart:
-
Customer (end-user can be OpenStack, may also be other programs) sends a request to the API (cinder-api): "Help me create a volume"
-
API request to do some necessary treatment, the Messaging (RabbitMQ) sent a message: "Let Scheduler to create a volume"
-
Scheduler (cinder-scheduler) obtained from Messaging API message sent to it, and then performing a scheduling algorithm, node A is selected from a plurality of storage count point
-
Scheduler to send a message to Messaging: "Let A storage node to create this volume"
View Service -openstack volume service list
(1) Disable Service
openstack volume service set --disable HOST_NAME BINARY_NAME
(2) to remove a node from the database
cinder-manage service remove BINARY_NAME HOST_NAME