325001045c
As per the community goal of migrating the policy file format from JSON to YAML[1], we need to do two things: 1. Change the default value of '[oslo_policy] policy_file'' config option from 'policy.json' to 'policy.yaml' with upgrade checks. 2. Deprecate the JSON formatted policy file on project side via warning in doc and format releasenotes. 1st item if already done by cinder in Stein so this commit only cover the 2nd item. Since oslo.policy 3.6.0, by default oslo policy will fallback to existing policy.json file to give operator some time to migrate it to new default policy.yaml. But cinder already changed the default value to policy.yaml long back since Stein so no need to fallback to default JSON file. To do that it disable this fallback via flag to oslo.policy. Also convert the tests/unit/policy.json to policy.yaml file. Additionally, made some corrections to outdated documentation when removing references to a "policy.json" file. [1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html Co-Authored-By: Brian Rosmaita <rosmaita.fossdev@gmail.com> Change-Id: Iaf8a454e60d1e4b66981b61175f89203cc15e439
5.5 KiB
Volume multi-attach: Enable attaching a volume to multiple servers
The ability to attach a volume to multiple hosts/servers simultaneously is a use case desired for active/active or active/standby scenarios.
Support was added in both Cinder and Nova in the Queens release to volume multi-attach with read/write (RW) mode.
Warning
It is the responsibility of the user to ensure that a multiattach or clustered file system is used on the volumes. Otherwise there may be a high probability of data corruption.
In Cinder the functionality is available from microversion '3.50' or higher.
As a prerequisite new Attach/Detach APIs were added to Cinder in Ocata to overcome earlier limitations towards achieving volume multi-attach.
In case you use Cinder together with Nova, compute API calls were switched to using the new block storage volume attachment APIs in Queens, if the required block storage API microversion is available.
For more information on using multiattach volumes with the compute service, refer to the corresponding compute admin guide section.
How to create a 'multiattach' volume
In order to be able to attach a volume to multiple server instances you need to have the 'multiattach' flag set to 'True' in the volume details. Please ensure you have the right role and policy settings before performing the operation.
Currently you can create a multiattach volume in two ways.
Note
For information on back ends that provide the functionality see Back end support.
Multiattach volume type
Starting from the Queens release the ability to attach a volume to
multiple hosts/servers requires that the volume is of a special type
that includes an extra-spec capability setting of
multiattach=<is> True. You can create the volume type
the following way:
$ cinder type-create multiattach
$ cinder type-key multiattach set multiattach="<is> True"Note
Creating a new volume type is an admin-only operation by default. You
can change the settings in the cinder policy file if needed. For more
information about configuring cinder policies, see policy-configuration.
To create the volume you need to use the volume type you created earlier, like this:
$ cinder create <volume_size> --name <volume_name> --volume-type <volume_type_uuid>In addition, it is possible to retype a volume to be (or not to be)
multiattach capable. Currently however we only allow retyping a volume
if its status is available.
The reasoning behind the limitation is that some consumers/hypervisors need to make special considerations at attach-time for multiattach volumes (like disable caching) and there's no mechanism currently to update a currently attached volume in a safe way while keeping it attached the whole time.
RO / RW caveats (the secondary RW attachment issue)
By default, secondary volume attachments are made in read/write mode which can be problematic, especially for operations like volume migration.
There might be improvements to provide support to specify the attach-mode for the secondary attachments, for the latest information please take a look into Cinder's specs list for the current release.
Back end support
In order to have the feature available, multi-attach needs to be supported by the chosen back end which is indicated through capabilities in the corresponding volume driver.
The reference implementation is available on LVM in the Queens
release. You can check the Driver Support Matrix <driver_support_matrix>
for further information on which back end provides the
functionality.
Policy rules
You can control the availability of volume multi-attach through
policies that you can configure in the cinder policy file. For more
information about the cinder policy file, including how to generate a
sample file so you can view the default policy settings, see policy-configuration.
Multiattach policy
The general policy rule to allow the creation or retyping of
multiattach volumes is named volume:multiattach.
Multiattach policy for bootable volumes
This is a policy to disallow the ability to create multiple
attachments on a volume that is marked as bootable with the name
volume:multiattach_bootable_volume.
Known issues and limitations
- Retyping an in-use volume from a multiattach-capable type to a non-multiattach-capable type, or vice-versa, is not supported.
- It is not recommended to retype an in-use multiattach volume if that volume has more than one active read/write attachment.
- Encryption is not supported with multiattach-capable volumes.