https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# longhorn-storage
a
This message was deleted.
b
I think the LH storage class is still going to route it over the "network" for the backend read/writes
It's just that the network doesn't leave the box when it's local
but I could be wrong.
If you WANT to bypass that, you can not use longhorn, and just make a local storage class.
b
The latter part is understood. However, “doesn’t leave the box” may mean that it goes through the network stack, but not out the ethernet card, right? If so, then the gig link shouldn’t be limiting, right?
b
I'm gonna have to guess here, but I think that ther'e still bond/bridge interfaces that are created and they probably match the physical link speeds?
b
interesting. That’s a good lead. OK, how about making a “local storage class” in harvester for the VM. Is there a doc for that? I couldn’t find one.
b
I doubt it. But that doesn't mean you can't do it. The local storage is part of the upstream k8s bits... let me see if I can find you a link.
b
Alrighty, thank you
b
You'll need to get the kubeconfig or enable the builtin Rancher UI for Harvester to add those bits.
b
aye. already done
Just as a note of curioisity. The mgmt-br interface is actually running at 10G (even though the underlying 1G nics compose it). Hrm.
It doesn’t feel right that it would send the data over the link via strict-local, replica=1, however, I do see it saturate the harvester storage network metrics chart while I run it continuously. Isn’t that in general a very inefficient thing to do? I almost feel like something is misconfigured or I’m missing something obvious. Going through the bonded device and getting short circuited is one thing, but longhorn looks to be sending the data (or some metadata) over the wire and maxing the link out before confirming the write locally.
b
¯\_(ツ)_/¯
b
haha. Understood. I wonder if there is a longhorn dev that can chime in?
b
Give it 24 hours
b
👍
b
Unless you have a support contract
then open a ticket. 🙂
b
hehe. I do not.
b
actually, since it's the weekend already in parts of the world, I'd wait until Monday.
b
Absolutely. I appreciate all your feedback so far though!
b
Although, I just remembered something: I think I remember hearing that Longhorn, even though it's using it's own storage class, is actually using NFS under the hood for the read/writes from the pod to the disk. That's probably why it has to use the network and can't just "mount" the "disk image" directly into the pod that's on it's local host. I think your question is probably how to alleviate that 1G connection speed on the local host still though.
b
correct
2 Views
Open in Slack
PreviousNext
Powered by