3 ms·
If the connection tracking state is really not required I don't understand how Katran works. How does it deal with the set of live backends changing? Using Magl
by lmb 8y ago
If the connection tracking state is really not required I don't understand how Katran works. How does it deal with the set of live backends changing? Using Maglev hashing gives you "minimal disruption", not no disruption.
- justinsaccount 8y agoI haven't looked at the code, but this is what they say: > Katran uses an extended version of the Maglev hash to select the backend server. A few features of the extended hash are resilience to backend server failures, more uniform distribution of load, and the ability to set unequal weights for different backend servers. GLB also does the same thing with caching: > The hashing to choose the primary/secondary server is done once, up front, and is stored in a lookup table, and so doesn’t need to be recalculated on a per-flow or per-packet basis. GLB has that primary/secondary thing which seems to be how it better handles backends coming and going.
- lmb 8y agoOk, I've looked at the code, and based on that I think what I said in my original post is correct. GLB is more complex, but will maintain connections in more circumstances.
- tehnerd 8y agoconnection tracking could be turned off. but yeah, but default it uses it (for cases where you need to drain a host w/o distruption of existing connections). it's easy to make katran behave the same way as glb (by disabling connection tracking + writing host module which is doing more or less the same as what glb's agent is doing)