Update Create Share from Snapshot in Another Pool
This patch update and move the spec Create Share From Snapshot in Another Pool or Back End to Ussuri. The spec updates were based on PTG discussions [1]. [1] https://etherpad.openstack.org/p/shanghai-ptg-manila-virtual Change-Id: Icbdaaf4c4d1063c6251de30a95283d9e08177b9d
This commit is contained in:
parent
19d03629ee
commit
74ad6da383
|
@ -53,12 +53,12 @@ option allows different results:
|
|||
This will certainly not work for any of the drivers in manila.
|
||||
|
||||
The main benefit from enabling this option is that the scheduler can select
|
||||
a different compatible back end to place the new share, even when the source's
|
||||
share has space enough to handle it. In order to have it working properly, we
|
||||
need to address the following:
|
||||
a different compatible back end to place the new share, even when the source
|
||||
share's back end has space enough to handle it. In order to have it working
|
||||
properly, we need to address the following:
|
||||
|
||||
* Guarantee that only compatible back ends will receive requests;
|
||||
* Guarantee that, when more that one compatible back end is available, the
|
||||
* Guarantee that, when more than one compatible back end is available, the
|
||||
scheduler will choose the best fit;
|
||||
* No regressions are inserted to the current behavior when the option is
|
||||
disabled.
|
||||
|
@ -88,7 +88,7 @@ shares from snapshot:
|
|||
ends will be weighed based on configured weigher classes.
|
||||
|
||||
2. **User provides the destination AZ.** The scheduler will filter out all back
|
||||
ends that does not belong to the user's specified AZ and all back ends that
|
||||
ends that do not belong to the user's specified AZ and all back ends that
|
||||
are not compatible with source share's pool. The list of compatible back
|
||||
ends will be weighed based on configured weigher classes.
|
||||
|
||||
|
@ -108,7 +108,7 @@ as expected:
|
|||
1. Change how the API handles the availability zone parameter, which is
|
||||
currently ignored when creating new shares from snapshots;
|
||||
|
||||
2. Modify the scheduler's filter ``ShareReplicationFilter``, to identify
|
||||
2. Create a new scheduler's filter ``CreateFromSnapshotFilter``, to identify
|
||||
compatible back ends;
|
||||
|
||||
3. Create a new weigher, to improve the scheduler's selection of the best
|
||||
|
@ -118,7 +118,10 @@ destination pool;
|
|||
snapshot. The driver interface for ``create_share_from_snapshot`` will be
|
||||
updated to return a model update when an asynchronous operation is needed.
|
||||
|
||||
5. Provide a proper configuration and guidelines for the feature.
|
||||
5. Create a new periodic task to track and update the status of shares that
|
||||
were created from snapshots.
|
||||
|
||||
6. Provide a proper configuration and guidelines for the feature.
|
||||
|
||||
The required changes are detailed in the following subsections.
|
||||
|
||||
|
@ -129,7 +132,8 @@ snapshot (potentially a bug, as it should return an error stating that a
|
|||
different AZ should not be specified). With the option
|
||||
``use_scheduler_creating_share_from_snapshot`` enabled, the API will need to
|
||||
forward the AZ parameter into the request sent to the scheduler, otherwise,
|
||||
the request will fail and the user notified about the reasons of the failure.
|
||||
the request will fail and the user will be notified about the reasons of the
|
||||
failure.
|
||||
|
||||
|
||||
Scheduler's Improvement
|
||||
|
@ -140,16 +144,16 @@ shares from snapshots in pools or back ends different than the source share's.
|
|||
This ability will be addressed by existing filters and the use of an already
|
||||
implemented property:``replication_domain``.
|
||||
|
||||
The replication feature are tightly related to the ability of creating a share
|
||||
in another pools. If two or more back ends are coupled for replication, they
|
||||
commonly have a fast data between each other, that can be used by some storage
|
||||
vendors to move, copy and replicate data among the back ends in the replication
|
||||
domain.
|
||||
The replication feature is tightly related to the ability of creating a share
|
||||
in another pool. If two or more back ends are coupled for replication, they
|
||||
commonly have a fast data link between each other, that can be used by some
|
||||
storage vendors to move, copy and replicate data among the back ends in the
|
||||
replication domain.
|
||||
|
||||
This spec proposes to modify the behavior of the ``ShareReplicationFilter``,
|
||||
that uses the property ``replication_domain`` to identify compatible storage
|
||||
back ends, to also identify pools and back ends capable of creating shares from
|
||||
snapshots in a efficient way.
|
||||
This spec proposes to create a new filter, ``CreateFromSnapshotFilter``,
|
||||
to use the property ``replication_domain`` to identify compatible storage
|
||||
back ends, i.e., remote pools and back ends capable of creating shares from
|
||||
snapshots in an efficient way.
|
||||
|
||||
In this proposal it is considered that back ends that can replicate data
|
||||
between each other should also be able to create new shares in an efficient
|
||||
|
@ -178,7 +182,7 @@ source share's location. If the source and destination hosts are located on:
|
|||
choice (e.g. 75 points)
|
||||
3. different back ends with the same AZ: the destination host is a good
|
||||
choice (e.g. 50 points)
|
||||
4. different back ends and AZ's: the destination host isn't so good choice
|
||||
4. different back ends and AZ's: the destination host isn't a good choice
|
||||
(e.g. 25 points)
|
||||
|
||||
Even so, this strategy still doesn't solve the used space balance use case at
|
||||
|
@ -201,64 +205,69 @@ working within the same AZ. But at the end, it is up to him/her to decide when
|
|||
a host should be filtered when creating shares from snapshot.
|
||||
|
||||
We can finally combine these approaches presented here and describe our
|
||||
proposed scheduling algorithm:
|
||||
proposed scheduling algorithm improvement:
|
||||
|
||||
1. We start by checking the source share's back end capabilities to obtain the
|
||||
scope of back end candidates that matches the specified AZ (or the source
|
||||
share's AZ if unspecified), which can be either:
|
||||
1. The scheduler request will be updated to include source share's host
|
||||
location needed by the new filter and weigher functions. It will be
|
||||
submitted through a list of scheduler filters, including the
|
||||
``AvailabilityZoneFilter`` which will exclude back ends that don't satisfy
|
||||
an availability zone restriction, if specified by the user during the share
|
||||
creation.
|
||||
|
||||
a. The same source pool or other pools in the same back end, if the AZ is
|
||||
unspecified or if the specified AZ is the same as the source share's
|
||||
one.
|
||||
b. Other back ends and respective pools that match the same string set
|
||||
in ``replication_domain`` and the specified AZ
|
||||
(or the same AZ as the source share's if unspecified).
|
||||
2. Alongside the scope of back ends determined by regular filters, we submit
|
||||
them through the ``CreateFromSnapshotFilter`` in order to filter
|
||||
incompatible back ends that don't fulfill at least one of the restrictions:
|
||||
|
||||
2. From the scope of back ends determined, we submit them through the
|
||||
``ShareReplicationFilter`` in order to filter incompatible back ends. After
|
||||
that, we submit them through the regular scheduler filters and weighers. If
|
||||
there are no valid weighed back ends, we error out with the usual
|
||||
``No valid host found`` message.
|
||||
a. Pools located in the same parent's share back end.
|
||||
b. Back ends and respective pools that match the same parent's share string
|
||||
set in ``replication_domain``.
|
||||
|
||||
3. In case there is more than one candidate and the source pool is among them,
|
||||
the new ``HostAffinityWeigher`` can be used, if enabled by the cloud
|
||||
administrator, to weigh hosts that belong to the same source's pool and/or
|
||||
back end.
|
||||
3. After that, we submit them through the regular weighers. If there are no
|
||||
valid weighed back ends, we error out with the usual ``No valid host found``
|
||||
message.
|
||||
|
||||
4. In case there is more than one candidate, the new ``HostAffinityWeigher``
|
||||
will be used to weigh hosts based on their proximity to the source's pool.
|
||||
|
||||
In this proposal, we assume that drivers that implement replication features
|
||||
between compatible back ends shall also be capable of creating new shares from
|
||||
snapshots in another pool or back end different from the source's share.
|
||||
|
||||
It is acknowledged that the proposed scheduler behavior for the operation of
|
||||
creating a new share from a snapshot are a departure from the conventional
|
||||
scheduler behavior of picking up all configured back ends, filtering and
|
||||
weighing them.
|
||||
|
||||
Share Manager's Updates
|
||||
-----------------------
|
||||
|
||||
When creating new shares from snapshots, the driver interface
|
||||
``create_share_from_snapshot`` is called and a string or a list of export
|
||||
locations is expected as return in a success scenario. However, by enabling the
|
||||
creation of shares from snapshot in another pool or backend can potentially
|
||||
creation of shares from snapshot in another pool or back end can potentially
|
||||
increase the time spent by the driver to complete the requested operation,
|
||||
considering that it may lead to a data copy between different pools or
|
||||
backends. To avoid performance impacts, the driver interface will be updated to
|
||||
back ends. To avoid performance impacts, the driver interface will be updated to
|
||||
work in an asynchronous way, by returning a model update, containing the status
|
||||
of the new share and a list of export locations, if available at share creation
|
||||
time. The share status returned can be one of the following:
|
||||
time. The driver can return one of the following status to indicate the current
|
||||
status of the share creation from snapshot:
|
||||
|
||||
1. **STATUS_AVAILABLE**: the share was already created on the destination pool
|
||||
and an export location should be available.
|
||||
|
||||
2. **STATUS_CREATING**: the share is in ``creating`` status and can take some
|
||||
time to be available to the user. The manager will need to periodically check
|
||||
the status of this share through driver periodic health check.
|
||||
2. **STATUS_CREATING_FROM_SNAPSHOT**: the share is in ``creating`` status and
|
||||
can take some time to be available to the user. The share manager will
|
||||
periodically check the status of this share through a new periodic task.
|
||||
|
||||
During the periodic driver stats check, the share manager will need to verify
|
||||
the shares that are in CREATING status and check with the driver if they are
|
||||
already available. The manager will apply all updates to the database and
|
||||
notify the user about it.
|
||||
For backward compatibility, the vendors can continue to suppress the share
|
||||
status from the returned dictionary, that the share will be considered as
|
||||
available to user.
|
||||
|
||||
A new intermediate status, ``STATUS_CREATING_FROM_SNAPSHOT``, will be added to
|
||||
assist share manager on filtering shares that are still working on copying data
|
||||
from a source snapshot. The new status will also be available to end users that
|
||||
request shares information through the API.
|
||||
|
||||
The share manager will have a new periodic task responsible for checking,
|
||||
using driver's interfaces, if shares that are in
|
||||
``STATUS_CREATING_FROM_SNAPSHOT`` state have an update in their status. The
|
||||
manager will apply changes to the database and notify the user about them.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
@ -288,7 +297,9 @@ and partially solve the use cases:
|
|||
Data model impact
|
||||
-----------------
|
||||
|
||||
None.
|
||||
A new ``progress`` field will be added to
|
||||
``manila.db.sqlalchemy.models.ShareInstance`` indicating the progress of a
|
||||
share creation.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
@ -305,13 +316,13 @@ API will return a HTTP 400, Bad Request.
|
|||
Driver impact
|
||||
-------------
|
||||
|
||||
There is no impact for drivers that does not support or want to support the
|
||||
There is no impact for drivers that do not support or want to support the
|
||||
proposed feature. If the cloud administrator enables the option
|
||||
``use_scheduler_creating_share_from_snapshot``, the scheduler filter will
|
||||
guarantee that unsupported back ends will not receive these kind of requests.
|
||||
Vendors that want to support this feature will need to change their drivers
|
||||
implementation to properly handle this use case. In order to have it working,
|
||||
some pre-requisites are needed:
|
||||
some prerequisites are needed:
|
||||
|
||||
1. Use the configuration option ``replication_domain`` and supply it to the
|
||||
scheduler together with the storage pool stats.
|
||||
|
@ -321,6 +332,14 @@ modified to accept a destination pool different from the source share's pool,
|
|||
and be prepared to return asynchronously if a slow copy operation is needed to
|
||||
complete the share creation.
|
||||
|
||||
3. Implement a new driver interface, ``get_share_status``, that will be used by
|
||||
the share manager to periodically check the status of shares created from
|
||||
snapshots. The driver will be able to provide the current status, the creation
|
||||
progress information in a percentage value, and the export locations for
|
||||
shares that become available. If omitted, the progress information will be set
|
||||
to **0%** for shares in ``STATUS_CREATING_FROM_SNAPSHOT`` and **100%** for
|
||||
shares in ``STATUS_AVAILABLE``.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
|
@ -341,15 +360,15 @@ Other end user impact
|
|||
---------------------
|
||||
|
||||
No changes to python-manilaclient are necessary. End users will be able to
|
||||
create new shares from snapshots in AZs other than the source share's using the
|
||||
current python-manilaclient.
|
||||
create new shares from snapshots in AZs other than the source share's using
|
||||
the current python-manilaclient.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
The performance impact should be minimal. The share manager will need to check
|
||||
in regular intervals whether the driver has finished the share creation for
|
||||
shares that remain with status equal to ``STATUS_CREATING``.
|
||||
shares that remain with status equal to ``STATUS_CREATING_FROM_SNAPSHOT``.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
@ -378,19 +397,20 @@ Work Items
|
|||
* Implement main patch for manila that includes:
|
||||
|
||||
* Share API adjustments to pass AZ parameter;
|
||||
* ShareInstance's new ``progress`` field will be included to provide the
|
||||
total progress of a share creation.
|
||||
* Scheduler's new weigher will be added to rate host based on their
|
||||
proximity to the source's share (only enable when creation from
|
||||
snapshot);
|
||||
* Scheduler's filter ``ShareReplicationFilter`` will be modify to filter
|
||||
out incompatible back ends, only when the source share's ``snapshot_id``
|
||||
is provided.
|
||||
proximity to the source's share;
|
||||
* Scheduler's new filter ``CreateFromSnapshotFilter`` will be added to
|
||||
filter out incompatible back ends, only when the source share's
|
||||
``snapshot_id`` is provided.
|
||||
* Share manager will introduce new periodic checks for asynchronous
|
||||
operations, update share's status in the database and notify users about
|
||||
share's status changes.
|
||||
share's status changes;
|
||||
* New driver interface to check for updates on shares that were created
|
||||
from snapshots in an asynchronous mode.
|
||||
|
||||
* Testing:
|
||||
* Implement enhancements to the devstack plugin to deploy a first party
|
||||
driver with multiple AZs;
|
||||
* Implement functionality in ZFSonLinux driver to validate correct
|
||||
scheduling and share creation from snapshot on different pools.
|
||||
|
||||
|
@ -412,10 +432,9 @@ given AZ different than the existing one. Negative tests will check if user's
|
|||
requested AZ is available and if the operation is compatible with the
|
||||
configured option ``use_scheduler_creating_share_from_snapshot``.
|
||||
|
||||
The new test will be run at the gate for the ZFSonLinux driver with Devstack
|
||||
plugin enhancements to set up multiple AZs. Vendors that implement support for
|
||||
the new capabilities in their drivers will be encouraged to run the test in
|
||||
their third party CI.
|
||||
The new tests will run at the gate for the ZFSonLinux driver configured with
|
||||
at least two AZs. Vendors that implement support for the new capabilities in
|
||||
their drivers will be encouraged to run the tests in their third party CI.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
|
@ -440,3 +459,4 @@ References
|
|||
|
||||
[1] https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018
|
||||
[2] https://etherpad.openstack.org/p/manila-ptg-train
|
||||
[3] https://etherpad.openstack.org/p/shanghai-ptg-manila-virtual
|
Loading…
Reference in New Issue