-
Notifications
You must be signed in to change notification settings - Fork 105
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
Conversation
95352c5
to
5189408
Compare
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 Report
@@ 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
Continue to review full report at Codecov.
|
// for the given pool | ||
for _, zv := range zvlist.Items { | ||
if zv.Spec.PoolName == pool { | ||
volsize, err := strconv.ParseInt(zv.Spec.Capacity, 10, 64) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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
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 afterthe 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 =>
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