IBM SG24-4576-00 Server User Manual


 
Consequently, clients only receive reply packets from the primary servers
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) servers IOEngine begins advertising that it knows the
route to the primarys 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 IIIs
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 servers 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 servers 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