Load balancing difficulties

[alan]

So did you apply the second patch before conducting the above tests?

I will comment on your feedback shortly.
_________________
~ Patronsoft Limited ~

[yherrebaut]

Yes I did, on both my servers.
It's weird that the patch does seem to work in the scenario when the DHCP service fails, when it doesn't in the other scenario's.
I did the tests several times to make sure that it wasn't pure coincidence, but each time I got the same results.

[alan]

1) So I assume DHCP crash works as expected

2) Please reproduce this problem, and issue the following commands from client PC and post the output here:

ping 10.20.10.1
ping 10.20.10.3
tracert www.apple.com

Note that you may need to wait 30 seconds or so before the switchover occurs.

3) For manual stop of FirstSpot, we don't really support this scenario. Instead, you should stop all FirstSpots and restart the one functioning FirstSpot with Load Balancing/Failover disabled.
_________________
~ Patronsoft Limited ~

[yherrebaut]

I've gathered the data you requested. I did 2 tests: one in which the DHCP service fails, and one in which the dispatcher service fails. Here are the results:

Test 1: DHCP
My laptop is now connected to server1 (10.20.10.1), which has high priority, and everything is working fine.
Now I stop the DHCP Service of server1. Server1 stops itself, and server2 becomes high priority.
After roughly 30 seconds I'm redirected to the login page. Logging in works fine, and after that browsing the web works just perfect.
Below is the data you requested (my apologies for the Dutch language in the screenshots, but I can't change that):

First of all, the IP configuration of my laptop:


Ping 10.20.10.1. It says that the destination host is unreachable, which is logical since this is the server that has stopped.


Ping 10.20.10.3. The ping succeeds, which is also logical because this is the only working gateway.


Tracert www.apple.com. This also succeeds. Just as browsing to any other web page.



Test 2: Dispatcher
The setup is exactly the same as in the previous test.
But now I stop the dispatcher service on server1 instead of the DHCP service.
Server1 shuts down and server2 becomes high priority.
Again, after more or less 30 seconds, I am sent towards the login page. Logging in works yet again fine, but then the problems start. When I try to browse the web, some webpages don't load at all, while others load very slowly, or only partially.

My IP configuration:


Ping 1: 10.20.10.1. In this case, the gateway is still reachable, but the FirstSpot server has stopped already...


Ping 2: 10.20.10.3. As expected, this gateway can be reached, since the active FirstSpot is running on this server.


Tracert www.apple.com. Reaching apple.com works for the moment.

However, when I execute tracert again only seconds later (without changing anything to the configuration of course), it fails:

In the first tracert, the ICMP packets were probably sent to the right gateway (10.20.10.3), while in the second tracert, they were probably sent to the wrong one (10.20.10.1).
This confirms my findings that both gateways are still being used when the dispatcher service fails, and only one is used when the DHCP service fails.

[alan]

2) How did you shutdown Dispatcher service? Note that if you shutdown the service in Windows Services Console, FirstSpot will treat as case 3. You need to kill the dispatchservice.exe in Task Manager instead.

If you still have problem, please post your firstspot_gw_srv_[timestamp].log under FirstSpot\log directory of your crash machine.

BTW, you can copy and paste the text in Command Prompt. Just click top left corner -> edit -> mark, and then copy.
_________________
~ Patronsoft Limited ~

[yherrebaut]

I have done my test again, but this time I killed the process through Task Manager like you suggested, and now it works perfectly!

My configuration is now complete, so I don't think I'll encounter any more problems. Thanks a lot for your assistance.