Merge "Update Create Share from Snapshot in Another Pool"
This commit is contained in:
Zuul
Gerrit Code Review
commit
822c616f5c
@ -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,39 +205,34 @@ 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
|
||||
-----------------------
|
||||
|
||||
@ -246,19 +245,29 @@ considering that it may lead to a data copy between different pools or
|
||||
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
Block a user