Slow booting on Lenovo server(SR630) due to metal3 suse chart tls enforcements #164
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
During provisioning of a Lenovo server for a baremetal provisioning we noticed that the booting of the node using mounted virtual media(during introspection) takes around 23 minutes.
Doing a deep analyze we noticed that on a Dell or HP server this issue does not happen, so we have eliminated a potential network issue for our environment.
Deep diving on the details, I noticed that the number of chunk of the data per second retrieved between a Dell and Lenovo is very huge.
For a Lenovo we have only 3 chunks of data, while for Dell we have arround 15 chunks/second.
See bellow logs from Lenovo server:
In order to be able to have a full control of all the parameters for ironic-metal3, which is based on apache I replicated the same design, by downloading the image from ironic, create an endpoint on apache and provide this URL on the iBMC and boot from this image. I noticed again the same behavior.
After this I changed the boot URL from
https
tohttp
and the server started in less than 5 minutes which was the desired behavior, but doing this is not anymore available with metal3 suse chart.Seeing this I have started looking for potential bugs on Lenovo booting over TLS and I have noticed this one:
https://support.lenovo.com/in/en/solutions/tt1086-virtual-media-mounted-over-https-may-have-slower-transfer-speeds-than-expected-lenovo-thinksystem-sd650-v37d7m-sr630-v37d72-7d73-7d74-sr650-v37d75-7d76-7d77
So I started playing with TLS setting and I defined the following options on my apache:
The values where taken from Apache recommendation as being speed-optimized ciphers .
https://httpd.apache.org/docs/2.4/en/ssl/ssl_howto.html#page-header.
After this settings defined in my apache config everything went fine also over TLS:
So in order to be able to control SSL setting we need a metal3 chart evolution to support such options.
Thanks for the report @daniel.lupescu - I see you also reported this at https://gitlab.com/sylva-projects/sylva-core/-/issues/2409 where @nbelouin shared some thoughts - I suggest we close this issue so we can focus the discussion in one place on the Sylva issue.