kubernetes-sigs / aws-ebs-csi-driver

CSI driver for Amazon EBS https://aws.amazon.com/ebs/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Multi-attach for ebs io1 type

Neophyte12345 opened this issue · comments

Is your feature request related to a problem?/Why is this needed
csi-driver currently only supports multi-attach for io2, however io2 is not available in us-gov-west-1 which limits the use of the csi-driver in certain regions.

https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/1799/files#diff-71909558cff6a715e6ba7728d820e0605ec9dc7f28562ea0fc90004762d4901eR10

/feature

Describe the solution you'd like in detail
csi-driver to support provisioning of storage with multi-attach for io1

Describe alternatives you've considered
N/A

Additional context

https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes-multi.html

/kind feature

@Neophyte12345 Can you share your use case details requiring multi-attach with io1/io2 volumes?

@ksliu58 I guess the use case is for gov-cloud users who deploy their workloads in regions that do not offer ebs io2 type. Would be nice to enable the csi-driver to be able to provision ebs io1 with multi-attach capability enabled at provisioning. We have certain apps that require shared ebs volumes to be attached across nodes.

Sorry, I should be more specific. Multi-attach is a nuanced feature, because you will need IO fencing to protect against data corruption. I am curious of your use case that why it requires the volume to be simultaneously accessed by more than 1 node? What type of application will you be running? Do they operate as read/write many access mode?

@ksliu58 The application in question is polyspace access which deploys 2 pods that need a shared volume. 1 is an web server pod and the other is an etl pod which share a volume. We did implement podaffinity to have the pods co-run on the same node to circumvented some of the limitations but thought it would be nice to have a multi-attach ebs volume capability regardless of the node they get scheduled on because sometimes the nodes are not big enough to support all the pods based on resources and type. They operate using access mode RWO. Hope this helps.