Alright so this is more asking ahead for future me problems...
I've been recently digging into options for certain forms of fail-over and bonding, most specifically methods that span switches.
I found documentation (old and new) mentioning that each PVE Node in a cluster can have additional NICs/IPs added for the Cluster traffic (unsure if that's the most precise term, sorry), declaring each as an additional ring... thing... (wow precise terminology activate!)
From what I read each ring NIC/IP would need to be on completely separate networking from each other, per node. And I see how that works logically.
However there's a scenario that I can't really see being talked about. I don't know if it's a good... or bad... idea.
Whether it's an existing cluster, or a new PVE cluster... is there a way to do the Redundant Ring Protocol (or whatever the modern thing is that does the same) in such a way that only SOME PVE Nodes in a Cluster (the same cluster for all nodes in this question) have these multiple IPs/Rings, and other PVE Nodes do NOT have more than one NIC/IP/Bond used for Cluster traffic, and then have everything be happy/working?
In my head, the answer sounds a lot like "no". But I don't know if I'm accounting for something.
Some of the rationale that might happen to future me is that in one of the PVE Clusters I'm responsible for, there are some nodes that could hypothetically be reconfigured to have additional ring NICs/IPs/whatever, and then there are other nodes in the same PVE Cluster that look like they really would not be able to do that (limitation of # of NICs, Switches, etc).
So... is there any way to mix and match this aspect in a way that things can be happy, good, and not explode in the face of whomever is looking at the console ala Star Trek? Or is my gut saying "no, not ever, nope don't touch that" correct?
Or maybe... this is an area for innovation?
Any thoughts on this is appreciated, but I'd prefer that we try to have as much tangible detail/evidence as possible instead of speculation. We may not be able to avoid speculation, but I'd prefer to have birds in my hands instead of in my brain/bush.
Thanks for your engagement!
I've been recently digging into options for certain forms of fail-over and bonding, most specifically methods that span switches.
I found documentation (old and new) mentioning that each PVE Node in a cluster can have additional NICs/IPs added for the Cluster traffic (unsure if that's the most precise term, sorry), declaring each as an additional ring... thing... (wow precise terminology activate!)
From what I read each ring NIC/IP would need to be on completely separate networking from each other, per node. And I see how that works logically.
However there's a scenario that I can't really see being talked about. I don't know if it's a good... or bad... idea.
Whether it's an existing cluster, or a new PVE cluster... is there a way to do the Redundant Ring Protocol (or whatever the modern thing is that does the same) in such a way that only SOME PVE Nodes in a Cluster (the same cluster for all nodes in this question) have these multiple IPs/Rings, and other PVE Nodes do NOT have more than one NIC/IP/Bond used for Cluster traffic, and then have everything be happy/working?
In my head, the answer sounds a lot like "no". But I don't know if I'm accounting for something.
Some of the rationale that might happen to future me is that in one of the PVE Clusters I'm responsible for, there are some nodes that could hypothetically be reconfigured to have additional ring NICs/IPs/whatever, and then there are other nodes in the same PVE Cluster that look like they really would not be able to do that (limitation of # of NICs, Switches, etc).
So... is there any way to mix and match this aspect in a way that things can be happy, good, and not explode in the face of whomever is looking at the console ala Star Trek? Or is my gut saying "no, not ever, nope don't touch that" correct?
Or maybe... this is an area for innovation?
Any thoughts on this is appreciated, but I'd prefer that we try to have as much tangible detail/evidence as possible instead of speculation. We may not be able to avoid speculation, but I'd prefer to have birds in my hands instead of in my brain/bush.
Thanks for your engagement!