Hi Jeff,
I didn't see a response to my previous request. It's not clear to us what you
are looking for here. Having a single netname for multiple nodes sounds similar
to a SOFS configuration. We use DNS to enumerate the IP addresses.
Windows uses witness for the following:
- If networking interface on the server has changed then hint client
about that so it can query list of new interfaces sooner than default 10
minutes poling interval.
Do you mean the witness GetInterfaceList() call or the
FSCTL_QUERY_NETWORK_INTERFACE_INFO used for smb3 multichannel?
- If cluster node is down then notify client about that so it can
disconnect from the downer and connect to some other node, before TCP/IP
timeout expires. Would work only of cluster can detect downer faster than
TCP/IP timeout.
I'll refer to this below with RESOURCE_CHANGE.
- If cluster has asymmetric storage (one node can process IOs faster than
the others) then hint client that it should move to that node. In Windows if
Direct IO is possible then storage connectivity is considered symmetrical and
we prefer load balancing clients across all cluster nodes. If we are in File
System Redirected IO (same blog) then storage connectivity is asymmetrical and
client is advised to move to the node that has file system mounted to avoid
double hop..
I'll refer to this below with CLIENT_MOVE_NOTIFICATION.
All notifications are advisory.
Could you clarify your expectations for the doc and tell us more about what
you're trying to accomplish?
I'll try...
This is in regards to your question:
Question 9:
Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY, but there's no specification on how the individual witness registrations handle specific notification events.
E.g. based on the different posibilities for RESOURCE_CHANGE.ResourceName
So far I found this in my testing:
A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_UNAVAILABLE will trigger
a reconnect,
but the RESOURCE_CHANGE.name content is completely ignored, currently I'm
sending the ip address string
that's no longer available, it's mainly in order to make it easier to read
wireshark traces or logs.
It could also be "SoME RandOM-StriNg!!!".
A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_AVAILABLE also doesn't
have any notable effect.
I think this should be documented somewhere.
If needed I an create network captures for it.
Is a CLIENT_MOVE_NOTIFICATION a better choice when using a single
InterfaceGroupName for all nodes?
The line/question above is no longer useful, as I found how to get the client
react
on RESOURCE_CHANGE with WITNESS_RESOURCE_STATE_UNAVAILABLE.
But by testing I found that a CLIENT_MOVE_NOTIFICATION is ignored if the list
of ip addresses
if the also contains the ip address that was given to the Register[Ex]() call.
I have only tested the case where all ip addresses have IPADDR_ONLINE set,
but I haven't tested if it's needed or what happens with IPADDR_OFFLINE or
when the given ip address if not part of the set that is resolved by dns
and/or isn't available.
I think this should be documented somewhere.
If needed I an create network captures for it.
I'm ready to file document change requests to explain the processing, but I
don't fully understand your example question.
I hope the above makes it clearer.
Resource Change notifications are used when resources such as disks change
status
The point is that as noted above it seems RESOURCE_CHANGE.name seems to be
completely ignored.
while Client Move notifications are used when a node has gone down and the
client needs to move to another node.
Yes, I found what I needed, but these details should be documented somewhere
in order to let server implementers know how to drive a windows client to
a desired/expected behavior.
They aren't interchangeable. Could you clarify your question?
I got it thanks!
metze
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
