[Doc] Add replication group support in doc for Storwize
Add replication group support for Storwize in document.
Closes-Bug:
@@ -27,6 +27,9 @@ operations:
- Manage an existing volume.
- Failover-host for replicated back ends.
- Failback-host for replicated back ends.
+- Create, list, and delete replication group.
+- Enable, disable replication group.
+- Failover, failback replication group.
Configure the Storwize family and SVC system
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -475,6 +478,9 @@ modify volume types, you can also change these extra specs properties:
Replication operation
---------------------
+Configure replication in volume type
+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+
A volume is only replicated if the volume is created with a volume-type
that has the extra spec ``replication_enabled`` set to ``<is> True``. Three
types of replication are supported now, global mirror(async), global mirror
@@ -500,6 +506,9 @@ mode. Default value is 300. Example syntax:
storage manually on the storage back end before replication
volume creation.
+Failover host
+<<<<<<<<<<<<<
+
The ``failover-host`` command is designed for the case where the primary
storage is down.
@@ -525,6 +534,49 @@ default as the ``backend_id``:
service driver will perform the synchronization and do the failback
after the synchronization is finished.
+Replication group
+<<<<<<<<<<<<<<<<<
+
+Before creating replication group, a group-spec which key
+``consistent_group_replication_enabled`` set to ``<is> True`` should be
+set in group type. Volume type used to create group must be replication
+enabled, and its ``replication_type`` should be set either ``<in> global``
+or ``<in> metro``. The "failover_group" api allows group to be failed over
+and back without failing over the entire host. Example syntax:
+
+- Create replication group
+
+.. code-block:: console
+
+ $ cinder group-type-create rep-group-type-example
+ $ cinder group-type-key rep-group-type-example set consistent_group_replication_enabled='<is> True'
+ $ cinder type-create type-global
+ $ cinder type-key type-global set replication_enabled='<is> True' replication_type='<in> global'
+ $ cinder group-create rep-group-type-example type-global --name global-group
+
+- Failover replication group
+
+.. code-block:: console
+
+ $ cinder group-failover-replication --secondary-backend-id target_svc_id group_id
+
+- Failback replication group
+
+.. code-block:: console
+
+ $ cinder group-failover-replication --secondary-backend-id default group_id
+
+.. note::
+
+ Option allow-attached-volume can be used to failover the in-use volume, but
+ fail over/back an in-use volume is not recommended. If the user does failover
+ operation to an in-use volume, the volume status remains in-use after
+ failover. But the in-use replication volume would change to read-only since
+ the primary volume is changed to auxiliary side and the instance is still
+ attached to the master volume. As a result please detach the replication
+ volume first and attach again if user want to reuse the in-use replication
+ volume as read-write.
+
Hyperswap Volumes
-----------------
