If the backend config simply contains a DNS name for the mangement lif and one adds a new A record with the same hostname and additional IP, can both lifs/IP's be management lif's? Seems like this doesn't work, even if both lif's have the same net int service policy. I haven't found a specific answer anywhere else yet.
One probably doesn't need to use DNS to add an interface and IP as Trident will discover this, I guess.
#muiltiple management lifs
1 messages · Page 1 of 1 (latest)
usually the client OS caches DNS lookups quite extensively (especially positive lookups). You could try setting a very low TTL on the A record but even that is ignored by many DNS resolvers/caches. There's probably no foolproof way to do that. Is there any particular reason why you want to do that? I mean it's not like loadbalancing across the management LIFs gives you a huge performance boost or something
it was kind of a brainfart... just routine for CIFS SVM's... and i couldn't find anything that said it shouldn't work... it would still use both for data as well
it doesn't seem to like it as i'm getting authentication errors on the new lif ... probably just easier to rename the A record, let the duplicate name expire. Will trident discover the new data lif without a rollout-restart?
that I cannot answer, sorry
looks like it doesn't ... i see nfs clients connected to the new IP
but i'm not sure if that just a DNS result or an inventory discover result, hehe
so i don't really have a definitive answer to my test... just spurious authentication errors to both new and old mangement lifs... seems a bit too random
Is there anyway in the running Trident configuration to determine what data lifs have been discovered?
I don't know if I understand the code correctly, but it almost seems like lif discovery just takes the first one (and only one) data lif it finds... line 1517 ff. in ontap_common.go
// If they didn't set a LIF to use in the config, we'll set it to the first NFS/SMB LIF we happen to find
if you leave out the data LIF, you're basically letting Trident choose any LIF it wants, so using the first one it finds is perfectly fine.
If you want (or need) Trident to use a specific data LIF, you have to specify that LIF in the config.
my thought is multiple data lifs... still
if Trident doesn't discover all data lifs, then I'll have to setup DNS for data lifs with mulitple A records and hope that works... part of this autodiscovery of data lifs seems incomplete with the context...
I was talking about data lifs
if the servers are just going to use DNS anyway, it seems almost unnecesary for Trident to know anything more than just that there is at least one functioning data lif just as a sanity check
DNS doesn't change that. It will be looked up once and after that it will be cached and the IP used instead
even this doesn't have enough context... the PV resource should be host:/path ... not IP:/path ... and the host is abstracted by DNS on per server lookups with caching
it's even allowed to change data lif IP's, so it seems to be the way it works
well, from my experience with similar scenarios related to "ip address vs. hostname" in the past, there are two ways to tackle this. one is to insist on rfc-compliant and documented behavior, and be ready for a world of hurt when things don't work the way they should, and the other way is to choose the path with the least moving parts and just use an IP address, which might not be as neat and tidy but will work.
if i have 30 servers using the same SVM, then round-robin DNS will get me to distributed use of multiple lifs, but i though Trident did this internally, but I may have misunderstood the autodiscovery. I thought that I read that iSCSI, for example, did discovery of all iSCSI lifs...
iscsi requires multipath so it needs multiple LIFs
but is that just a sanity check? The actual OS has to establish the connections, but I haven't used iSCSI with Trident, so I haven't been able to observe the behaviour based on configurations
do you even need multiple LIFs? If, for example your network infrastructure is 40g or 100g anyway, why not just pragmatically put all LIFs on a single link? It's not like you would over-saturate a 100g link anyways
distribution of protocoll processing
you mean with iscsi? of course you need multiple sessions because otherwise you won't have redundancy
have you checked that this is even an issue in your scenario? or are you just guessing that it will overload the system if you do not distribute the load?
I mean, yeah, by all means, make it as complicated and over-engineered as you can, but I would always prefer the practical solution. And you can still later distribute the load by simply adding a second backend config that uses a different LIF, and creating new volumes on that one instead
i already know that i can't get workloads distributed evenly enough for what I have left of capacity... I've moved lifs and have to keep moving lifs around to keep things running
and DNS isn't complicated... and if DNS isn't working, not much else is.
yeah, in theory I agree, but apparently it's a hard problem in software development. And the dozens of caching layers (sssd, dnsmasq, glibc, kernel, etc.) don't help either
especially changes in DNS tend to take rather long to propagate to each and every client