Consequently, clients only receive reply packets from the primary server′s
IOEngine; this is the same IOEngine to which they sent the original request
packet. The clients view the mirrored server as any other NetWare server.
Clients send a single request packet and receive a single reply packet from the
same address. The duplication of requests to the secondary IOEngine and
synchronization of events to both server engines happens transparently to
network clients.
When the primary server fails and the secondary server takes over, network
clients view the switch over as a simple routing change. The new primary
(formerly the secondary) server′s IOEngine begins advertising that it knows the
route to the primary′s MSEngine internal network. The primary server sends a
special packet to network clients, informing them of the new route. The primary
server now sends response packets to clients rather than discarding them as it
did when it was the secondary server.
This works in exactly the same way it would with regular NetWare if a route fails.
The establishment of the new route is transparent to the client workstations and
in the case of SFT III, to the MSEngine as well.
When SFT III switches from the primary to the secondary server, clients may
detect a slight pause, but server operations will continue because of SFT III′s
failure handling capabilities.
If a hardware failure causes the primary server to shut down, the secondary
becomes the primary and immediately notifies clients on the network that it is
now the best route to get to the MSEngine. The client shell recognizes this
notification and the route change takes place immediately.
IPX packets can be lost during the switch-over process, but LAN communication
protocols are already set up to handle lost packets. When an acknowledgment
packet is not received by the client, it simply does a retry to send the packet
again. This happens quickly enough that the connection to the clients is
maintained.
The following scenarios describe in more detail how SFT III failure handling
works:
Scenario 1. Hardware fails in the primary server:
Because the MSL times out
from inactivity and no response is heard over the LAN, the secondary server
infers that the primary server is down.
The secondary server displays a message on the console screen notifying the
system administrator that the primary server is down and that the secondary
server is taking over the primary server′s role.
The secondary server sends a message to each client informing them that it is
now the primary server.
Client packets are rerouted to the new primary (formerly the secondary) server.
SFT III keeps track of any disk changes following the server′s failure.
The operator resolves the problem and restarts the server that has failed. The
two servers synchronize memory images and begin running mirrored.
50 NetWare Integration Guide