openebs / mayastor

Dynamically provision Stateful Persistent Replicated Cluster-wide Fabric Volumes & Filesystems for Kubernetes that is provisioned from an optimized NVME SPDK backend data storage stack.
Apache License 2.0
755 stars 109 forks source link

[introduction/quickstart/configure-mayastor]: [Resizing Volume] #769

Closed dev-wei closed 2 years ago

dev-wei commented 3 years ago

Are you reporting an issue with existing content? No

https://mayastor.gitbook.io/introduction/quickstart/configure-mayastor

Are you proposing new content, or a change to the existing documentation layout or structure?

Does it support resizing at MSV or PV/PVC level? It is not clear whether or not the Mayastor volume supports this feature or not. Also how it relates or constraints with the different schemes of resources in the pool.

GlennBullingham commented 3 years ago

Hi. No, at this stage in its development and for the proposed GA release later this year, we do not expect to support resizing of volumes. This is a limitation we've chosen to accept at this time in the interests of getting the core I/O engine ready and available and will undoubtedly be something which we look to address at a later stage.

If I understand the second part of your question correctly, there is no support at this stage for "differentiated storage tiers". Also, a single Mayastor Pool (MSP) has the limitation currently that it can have only a single block device as a member, contributing storage capacity to that pool The current control plane logic will permit a Mayastor volume to have replicas hosted on multiple pools, without checking the nature and characteristics of those pools e.g. for a volume with replication=2, one replica might be hosted on a pool backed by an SSD and another on a second pool which is backed by HDD. Mayastor won't thus prevent 'heterogeneous' situations itself. For single replica volumes, there is no mechanism at this time for forcing the selection of one pool over another, at least not when provisioning using the Mayastor CSI driver. Again, whilst these constraints exist at this time and for likely the mid-term, we're aware of the limitations they might represent to adoption in large scale production and potential solutions are under consideration for implementation at some point.

dev-wei commented 3 years ago

Thank you for the quick reply.

I want to confirm on the second part. What you described above matches with my experience. Currently, one Mayastor Pool can only accept one single block disk, even though the "disks" field itself takes an array as the input.

Also, I found a couple of other fields specd by the MSV

spec:
  limitBytes: 0
  preferredNodes: []
  protocol: nvmf
  replicaCount: 1
  requiredBytes: 524288000
  requiredNodes: []

Is perferredNodes impacting the way how a pool is selected for backing up the replicas? How does the requiredNodes work anyway in other cases?

Hopefully, someone could maybe layout a full in-depth document for all of configurable settings. Thank you!

GlennBullingham commented 3 years ago

You're welcome.

To my knowledge, those fields of the MSV CR aren't currently in use, which appears to be supported by the fact that they hold null values in your example output.

I'm not sure whether you may have seen it already or not but a "quickstart" guide for Mayastor can be found here.

Any configuration settings which are currently possible via CR are documented there. If it's not written, it's not possible/supported.

kellyhair commented 3 years ago

@GlennBullingham - I'm looking for the corresponding tracking issues in the limitations section. I looked around the GitHub issues & Jira but may have missed them.

Happy to put a PR in and/or add them if they are not called out directly.