manila oversubscription enhancements
Partially-Implements: blueprint manila-oversubscription-enhancements Change-Id: I32093c998067c06427b427bc0a66193fc94e1859
This commit is contained in:
parent
207b716fc2
commit
53f01c08ae
|
@ -15,6 +15,16 @@ These specifications can be implemented over multiple releases.
|
||||||
|
|
||||||
specs/release_independent/*
|
specs/release_independent/*
|
||||||
|
|
||||||
|
Zed approved specs
|
||||||
|
==================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
specs/zed/*
|
||||||
|
|
||||||
|
|
||||||
Yoga approved specs
|
Yoga approved specs
|
||||||
===================
|
===================
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,193 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
====================================
|
||||||
|
Manila oversubscription enhancements
|
||||||
|
====================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/manila/+spec/manila-oversubscription-enhancements
|
||||||
|
|
||||||
|
About allocated_capacity_gb and provisioned_capacity_gb, allocated_capacity_gb
|
||||||
|
corresponds to shares_gb created on a storage pool via manila.
|
||||||
|
provisioned_capacity_gb is equal to the sum of allocated_capacity_gb add
|
||||||
|
shares_gb_created_manually (or another manila) on the same storage pool. It
|
||||||
|
implies that provisioned_capacity_gb greater than or equal to
|
||||||
|
allocated_capacity_gb. It is important for administrators to know these two
|
||||||
|
values in order to obtain information about back-end allocated capacity.
|
||||||
|
|
||||||
|
For a storage backend that supports thin provisioning,The following describes
|
||||||
|
the reported capacity information.
|
||||||
|
|
||||||
|
total_capacity_gb = Total physical disk capacity of the storage pool used by
|
||||||
|
Manila.
|
||||||
|
|
||||||
|
free_capacity_gb = total_capacity_gb - Used physical disk capacity of the
|
||||||
|
storage pool.
|
||||||
|
|
||||||
|
provisioned_capacity_gb = Total capacity allocated by all shares (include
|
||||||
|
shares created manually or other manila) in the storage pool.
|
||||||
|
|
||||||
|
allocated_capacity_gb = Total capacity allocated by all shares created by
|
||||||
|
current manila.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Problem One:
|
||||||
|
Here's an example. Storage pool pool_A physical disk capacity is 10G. There are
|
||||||
|
four shares in this pool.
|
||||||
|
Share A created by openstack O_A(current manila), share size is 5G. There is a
|
||||||
|
124MB file in this share.
|
||||||
|
Share B created by openstack O_A(current manila), share size is 4G. There is a
|
||||||
|
0MB file in this share.
|
||||||
|
Share C created by openstack O_B, share size is 3G. There is a 400MB file in
|
||||||
|
this share.
|
||||||
|
Share D created manually, share size is 2G. There is a 500MB file in
|
||||||
|
this share.
|
||||||
|
|
||||||
|
The total physical capacity in use is 1G(124MB+0MB+400MB+500MB), the result is:
|
||||||
|
total_capacity_gb = 10G
|
||||||
|
free_capacity_gb = 9G
|
||||||
|
provisioned_capacity_gb = 14G (5G+4G+3G+2G)
|
||||||
|
allocated_capacity_gb = 9G (5G+4G, only share A and B is created by current manila)
|
||||||
|
|
||||||
|
In fact, the storage back end doesn't know how many Manila services are using
|
||||||
|
the storage pool or whether the administrator has manually created shares in
|
||||||
|
the pool. So the allocated_capacity_gb reported by backend storage driver is
|
||||||
|
not correct. Only provisioned_capacity_gb reported by backend storage driver is
|
||||||
|
correct.
|
||||||
|
|
||||||
|
Currently, some drivers (inspur, huawei, netapp, qnap, zadara) report
|
||||||
|
allocated_capacity_gb and some drivers (infinibox, hpe_3par, nexenta)
|
||||||
|
report provisioned_capacity_gb, which is chaotic.
|
||||||
|
|
||||||
|
Problem Two:
|
||||||
|
About scheduler service supports Active/Active HA, The consume_from_share
|
||||||
|
function is executed each time a share is created or extend, in this function
|
||||||
|
allocated_capacity_gb and free_capacity_gb must be updated. Let's suppose 100
|
||||||
|
1gb shares are created, 50 of which are executed on node 1 and 30 on node 2
|
||||||
|
and 20 on node 3. Since allocated_capacity_gb is maintained in the memory of
|
||||||
|
the scheduling service. As a result, the allocated_capacity_gb values of the
|
||||||
|
three scheduling nodes are inconsistent. This is problematic. We need to
|
||||||
|
calibrate allocated_capacity_gb periodically.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
=========
|
||||||
|
* The administrator can view the capacity allocation of the back-end storage
|
||||||
|
by allocated_capacity_gb and provisioned_capacity_gb.
|
||||||
|
* Manila scheduler use provisioned_capacity_gb to filter and weigh back-end.
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
This spec proposes to:
|
||||||
|
|
||||||
|
* allocated_capacity_gb reported by driver may be correct if the driver is
|
||||||
|
capable of tracking it accurately, but allocated_capacity_gb calculated
|
||||||
|
from database must be correct. So for uniformity, allocated_capacity_gb
|
||||||
|
will use calculated by database rather than reported by driver.
|
||||||
|
* we strongly recommend that the driver report provisioned_capacity_gb, if
|
||||||
|
it is not reported, Manila is considered exclusive storage pool, will use
|
||||||
|
allocated_capacity_gb as the provisioned_capacity_gb value.
|
||||||
|
|
||||||
|
* for problem two, Add a periodic task in Manila Share to periodically collect
|
||||||
|
allocated_capacity_gb statistics from the database and record it in
|
||||||
|
self._allocated_capacity_gb(a member variable of class ShareManager). Read
|
||||||
|
self._allocated_capacity_gb and update allocated_capacity_gb in
|
||||||
|
share_stats[pools] when executing _report_driver_status. Because Manila
|
||||||
|
doesn't require very much real-time data for allocated_capacity_gb,
|
||||||
|
Therefore, the interval of periodic tasks can be set to 5 minutes to reduce
|
||||||
|
system and database pressure.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
The current model is an alternative, however, the calculation occuring in the
|
||||||
|
scheduler is problematic because it's happening in each scheduler process for
|
||||||
|
each backend and for each pool, which is inefficient and wrong
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
we'd be removing a huge performance bottleneck from the scheduler service!
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Drivers should update to report provisioned_capacity_gb instead of
|
||||||
|
allocated_capacity_gb.
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
haixin <haix09@chinatelecom.cn>
|
||||||
|
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Update share manager and scheduler's host manager.
|
||||||
|
* Update unittest.
|
||||||
|
* Update related documents.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
* Add the unit tests
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
The following OpenStack documentations will be updated to reflect this change:
|
||||||
|
|
||||||
|
* OpenStack Contributor Guide
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
None
|
Loading…
Reference in New Issue