Vincent Hou 05f8a52301 Storwize: Implement v2 replication
Storwize supports three major types for volume replications:
split IO, global mirror and metro mirror.

This patch is dedicated to implement the replication for
the modes of global mirror and metro mirror. Mirror
establishes a Global/Metro Mirror relationship between
two volumes of equal size. The volumes in a Mirror
relationship are referred to as the primary volume and
the replica volume. The replication_mode in
replication_device must be set to global or metro.

The volume type needs to associate with the extra spec
with 'replication_enabled' equaling to "<is> True", and
'replication_type' equaling to '<in> global' or '<in>
metro'.

What is supported with replication:
* create volume
* create volume from snapshot
* clone a volume
When a volume is created and replication is enabled, the
replica volume is also created on the back-end enabled
for replicas.

What is not supported with replication yet:
* volume migration
* volume retype
The replica volume will not be created or moved after migration
or retype of a replicated volume. Admins should be aware,
when migrating or retyping a volume to a type with replication
enabled, that the replica will not be automatically created.

The replication can be configured via either multi-backend
on one cinder volume node, or on separate cinder volume
nodes.

Options to be put in cinder.conf, where the primary back-end
is located:

enabled_backends = sv1, sv2 (if enabling multi-backends)

[sv1]
san_login = admin
san_password = admin
san_ip = 192.168.0.11
volume_driver = cinder.volume.drivers.ibm.storwize_svc.\
                StorwizeSVCDriver
volume_backend_name = sv1
storwize_svc_volpool_name=cinder
replication_device = managed_backend_name:second_host@sv2#sv2,
                     replication_mode:global,
                     target_device_id:svc_id_target,
                     san_ip:192.168.0.12,san_login:admin,
                     san_password:admin,pool_name:cinder_target

Options to be put in cinder.conf, where the secondary
back-end is connected:

[sv2]
san_login = admin
san_password = admin
san_ip = 192.168.0.12
volume_driver = cinder.volume.drivers.ibm.storwize_svc.\
                StorwizeSVCDriver
volume_backend_name = sv2
storwize_svc_volpool_name=cinder_target

Partial-implements: blueprint ibm-storwize-v2-replication
DocImpact

Change-Id: I2ad5be69b2814d3b974c963828585fa15446d772
2016-02-08 21:03:34 -05:00
2016-02-08 21:03:34 -05:00
2016-01-08 11:05:44 -05:00
2012-05-03 10:48:26 -07:00
2013-06-14 14:02:17 +00:00
2012-05-03 10:48:26 -07:00
2012-05-03 10:48:26 -07:00
2012-08-10 11:56:00 -04:00
2015-06-11 17:19:19 +02:00
2015-01-12 14:02:24 +01:00
2015-09-18 16:37:17 +00:00
2016-01-21 14:17:34 +01:00

CINDER

You have come across a storage service for an open cloud computing service. It has identified itself as Cinder. It was abstracted from the Nova project.

Getting Started

If you'd like to run from the master branch, you can clone the git repo:

git clone https://github.com/openstack/cinder.git

For developer information please see HACKING.rst

You can raise bugs here http://bugs.launchpad.net/cinder

Python client

https://github.com/openstack/python-cinderclient.git

Description
OpenStack Block Storage (Cinder)
Readme 905 MiB
Languages
Python 99.7%
Smarty 0.3%