Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(schd): adding capacity weighted scheduler #266

Merged
merged 1 commit into from
Jan 7, 2021

Conversation

pawanpraka1
Copy link
Contributor

@pawanpraka1 pawanpraka1 commented Dec 28, 2020

The ZFS Driver will use capacity scheduler to pick a node
which has less capacity occupied by the volumes. Making this
as default scheduler as it is better than the volume count based
scheduling. We can use below storageclass to specify the scheduler

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: openebs-zfspv
allowVolumeExpansion: true
parameters:
 scheduler: "CapacityWeighted"
 poolname: "zfspv-pool"
provisioner: zfs.csi.openebs.io

Please Note that after the upgrade, there will be a change in the behavior.
If we are not using scheduler parameter in the storage class then after
the upgrade ZFS Driver will pick the node based on volume capacity weight
instead of the count.

fixes: #215

Explanation

ZFS Driver does not control the zfs pool, by checking volumes capacity on the node for a particular pool can get us close to balancing the volumes across the nodes. So let us say that we have three pools on 3 different nodes node1, node2 and node3, with initial volumes provisioned like this =>

node       -     node1    -     node2       -     node3 
volume     -     vol1     -     vol2        -    vol3
size       -     100G     -     5G          -    50G

Now, if we want to provision a volume a new volume, the driver will pick the node2 for provisioning the volume. It will keep on picking the node2 until the volume nodes are equally distributed capacity wise.

Signed-off-by: Pawan pawan@mayadata.io

@pawanpraka1 pawanpraka1 added enhancement Add new functionality to existing feature pr/hold-review hold the review. labels Dec 28, 2020
@pawanpraka1 pawanpraka1 added this to the 1.3.0 milestone Dec 28, 2020
The ZFS Driver will use capacity scheduler to pick a node
which has less capacity occupied by the volumes. Making this
as default scheduler as it is better than the volume count based
scheduling. We can use below storageclass to specify the scheduler
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: openebs-zfspv
allowVolumeExpansion: true
parameters:
 scheduler: "CapacityWeighted"
 poolname: "zfspv-pool"
provisioner: zfs.csi.openebs.io
```

Please Note that after the upgrade, there will be a change in the behavior.
If we are not using `scheduler` parameter in the storage class then after
the upgrade ZFS Driver will pick the node bases on volume capacity weight
instead of the count.

Signed-off-by: Pawan <pawan@mayadata.io>
@codecov-io
Copy link

Codecov Report

Merging #266 (5189408) into master (2e5e61d) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #266      +/-   ##
=========================================
- Coverage    1.11%   1.09%   -0.02%     
=========================================
  Files          11      11              
  Lines         899     912      +13     
=========================================
  Hits           10      10              
- Misses        889     902      +13     
Impacted Files Coverage Δ
pkg/driver/schd_helper.go 0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2e5e61d...cf0fc1d. Read the comment docs.

@pawanpraka1 pawanpraka1 removed the pr/hold-review hold the review. label Dec 29, 2020
// for the given pool
for _, zv := range zvlist.Items {
if zv.Spec.PoolName == pool {
volsize, err := strconv.ParseInt(zv.Spec.Capacity, 10, 64)
Copy link
Member

@kmova kmova Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this going to get the actual used capacity or reserved capacity?

For example, if the volumes are provisioned as follows on two nodes with 100GB pools:

  • v1 = 50G => node 1 (this volume writes only 5mb of data)

  • v2 = 50G => node 2 (this volume writes 1GB of data)

  • v3 = 50G

  • v4 = 50G

Will v3 and v4 go to node1 because it has occupied less capacity than node2?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is based on pv size. So ,in the above case v3 and v4 will go to different nodes (node1 and node2).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kiran, for Thick provisioned volumes does the actual space usage even matters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope. for thick provisioned, it doesn't matter. using based on PV size is good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Add new functionality to existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add capacity based scheduling in ZFS-LocalPV
4 participants