Start a Conversation

Solved!

Go to Solution

2147

March 18th, 2022 11:00

Proper way to increase timeouts for PowerMax CSI driver?

Hi,

I've been working with an under-powered PowerMax storage system (or perhaps just too much historical junk), and the CSI driver on my OpenShift cluster keeps timing out with `context deadline exceeded`. There are good days and bad days, but to work on the code for functionality, I wonder if I can make my CSI driver more forgiving for slower responses from the Unisphere.

I've seen it happen when getting the initiators list, renaming the host, mounting an already-bound PV for a pod, and more. I'd love to clean up or add more RAM to the PowerMax/Unisphere and make it more performant, but if that can't happen, can somebody here suggest a proper way to make my CSI driver/attacher more forgiving/lenient with slowness?

 

thanks, - Hiro

1 Message

March 29th, 2022 12:00

@miyamotoh ,

The access mode cell for powermax has 2 lines for 2 different types of the volume type. The first one is for Mount volumes and the second one is for the RAW block as enclosed by "()".
So for the Mount Volumes, we only have RWO (v2.2 and earlier) and RWOP (latest v2.2).

Regards,
Utkarsh

March 21st, 2022 01:00

Hi Miyamotoh,

 

Thanks for reaching out to us. This is a known issue and we have documented the same.

https://dell.github.io/csm-docs/docs/csidriver/release/powermax/

The workaround is to remove the stale/unused entries from the array to get improved performance.

 

Regards,

Yamuna

March 21st, 2022 02:00

Hi @miyamotoh,

With respect to increasing the timeouts, Please change the default timeout for X_CSI_UNISPHERE_TIMEOUT in the line mentioned below, 

https://github.com/dell/csi-powermax/blob/6219379aafc44d1d2f9eb347c3ad78712a908de8/helm/csi-powermax/templates/controller.yaml#L378

As an option, you can provide the same value in values.yaml as well which will be taken precedence if supplied.

 

Regards,

Yamuna

 

14 Posts

March 21st, 2022 09:00

Thanks, Yamuna. I tried with `X_CSI_UNISPHERE_TIMEOUT=15m`, and am not sure if that's helping or it's just a "good day," but I'm getting past `GetInitatorList` and finding "valid initiator"!

However, my test pod is failing to mount the volume if created with `ReadWriteMany.` If the PVC is `ReadWriteOnce`, my pod can mount it and start up fine.

 Mount volumes do not support AccessMode MULTI_NODE_MULTI_WRITER

 This is not a "slowness" issue, is it? Could you point me what to check?

March 29th, 2022 01:00

Hi @miyamotoh ,

Good Day. Glad that your timeout issue has been now resolved.

CSI driver for PowerMax doesn't support Multi-Node Multi-Writer for Mount Volumes.

Please have a look at the supported capabilities.

https://dell.github.io/csm-docs/docs/csidriver/#csi-driver-capabilities

Please let me know if you have any further queries.

Regards,

Yamuna

14 Posts

March 29th, 2022 09:00

Well, the table shows "RWX" in the PowerMax column for Access Mode, without any side note, doesn't it? Could you clarify @YamunadeviS ?

14 Posts

March 30th, 2022 07:00

Ah, that's a little hard to read out of the table, but thanks for clarifying!

No Events found!

Top