[config-ref] Migrate section_block-storage-overview.xml to rst
Change-Id: I6f763f715106776960536b769a4feb3a5c06dbe0 Implements: blueprint config-ref.rst
This commit is contained in:
parent
a106988d4a
commit
b34f3dec5e
@ -1,3 +1,89 @@
|
|||||||
=========================================
|
=========================================
|
||||||
Introduction to the Block Storage service
|
Introduction to the Block Storage service
|
||||||
=========================================
|
=========================================
|
||||||
|
|
||||||
|
The Block Storage service provides persistent block storage
|
||||||
|
resources that Compute instances can consume. This includes
|
||||||
|
secondary attached storage similar to the Amazon Elastic Block Storage
|
||||||
|
(EBS) offering. In addition, you can write images to a Block Storage
|
||||||
|
device for Compute to use as a bootable persistent instance.
|
||||||
|
|
||||||
|
The Block Storage service differs slightly from the Amazon EBS offering.
|
||||||
|
The Block Storage service does not provide a shared storage solution
|
||||||
|
like NFS. With the Block Storage service, you can attach a device to
|
||||||
|
only one instance.
|
||||||
|
|
||||||
|
The Block Storage service provides:
|
||||||
|
|
||||||
|
- ``cinder-api`` - a WSGI app that authenticates and routes requests
|
||||||
|
throughout the Block Storage service. It supports the OpenStack APIs
|
||||||
|
only, although there is a translation that can be done through
|
||||||
|
Compute's EC2 interface, which calls in to the Block Storage client.
|
||||||
|
|
||||||
|
- ``cinder-scheduler`` - schedules and routes requests to the appropriate
|
||||||
|
volume service. Depending upon your configuration, this may be simple
|
||||||
|
round-robin scheduling to the running volume services, or it can be
|
||||||
|
more sophisticated through the use of the Filter Scheduler. The
|
||||||
|
Filter Scheduler is the default and enables filters on things like
|
||||||
|
Capacity, Availability Zone, Volume Types, and Capabilities as well
|
||||||
|
as custom filters.
|
||||||
|
|
||||||
|
- ``cinder-volume`` - manages Block Storage devices, specifically the
|
||||||
|
back-end devices themselves.
|
||||||
|
|
||||||
|
- ``cinder-backup`` - provides a means to back up a Block Storage volume to
|
||||||
|
OpenStack Object Storage (swift).
|
||||||
|
|
||||||
|
The Block Storage service contains the following components:
|
||||||
|
|
||||||
|
- **Back-end Storage Devices** - the Block Storage service requires some
|
||||||
|
form of back-end storage that the service is built on. The default
|
||||||
|
implementation is to use LVM on a local volume group named
|
||||||
|
"cinder-volumes." In addition to the base driver implementation, the
|
||||||
|
Block Storage service also provides the means to add support for
|
||||||
|
other storage devices to be utilized such as external Raid Arrays or
|
||||||
|
other storage appliances. These back-end storage devices may have
|
||||||
|
custom block sizes when using KVM or QEMU as the hypervisor.
|
||||||
|
|
||||||
|
- **Users and Tenants (Projects)** - the Block Storage service can be
|
||||||
|
used by many different cloud computing consumers or customers
|
||||||
|
(tenants on a shared system), using role-based access assignments.
|
||||||
|
Roles control the actions that a user is allowed to perform. In the
|
||||||
|
default configuration, most actions do not require a particular role,
|
||||||
|
but this can be configured by the system administrator in the
|
||||||
|
appropriate ``policy.json`` file that maintains the rules. A user's
|
||||||
|
access to particular volumes is limited by tenant, but the user name
|
||||||
|
and password are assigned per user. Key pairs granting access to a
|
||||||
|
volume are enabled per user, but quotas to control resource
|
||||||
|
consumption across available hardware resources are per tenant.
|
||||||
|
|
||||||
|
For tenants, quota controls are available to limit:
|
||||||
|
|
||||||
|
- The number of volumes that can be created.
|
||||||
|
|
||||||
|
- The number of snapshots that can be created.
|
||||||
|
|
||||||
|
- The total number of GBs allowed per tenant (shared between
|
||||||
|
snapshots and volumes).
|
||||||
|
|
||||||
|
You can revise the default quota values with the Block Storage CLI,
|
||||||
|
so the limits placed by quotas are editable by admin users.
|
||||||
|
|
||||||
|
- **Volumes, Snapshots, and Backups** - the basic resources offered by
|
||||||
|
the Block Storage service are volumes and snapshots which are derived
|
||||||
|
from volumes and volume backups:
|
||||||
|
|
||||||
|
- **Volumes** - allocated block storage resources that can be
|
||||||
|
attached to instances as secondary storage or they can be used as
|
||||||
|
the root store to boot instances. Volumes are persistent R/W block
|
||||||
|
storage devices most commonly attached to the compute node through
|
||||||
|
iSCSI.
|
||||||
|
|
||||||
|
- **Snapshots** - a read-only point in time copy of a volume. The
|
||||||
|
snapshot can be created from a volume that is currently in use
|
||||||
|
(through the use of ``--force True``) or in an available state.
|
||||||
|
The snapshot can then be used to create a new volume through
|
||||||
|
create from snapshot.
|
||||||
|
|
||||||
|
- **Backups** - an archived copy of a volume currently stored in
|
||||||
|
Object Storage (swift).
|
||||||
|
Loading…
Reference in New Issue
Block a user