Y; and L (a node alias for IP and Microsoft networking), which sees both disks. Thus, you can access disk Y through either server K or L, but in truth, K does all the work.
If both J and K have SQL Server running on them (currently possible with Digital Clusters for Windows NT, but not on the initial Wolfpack release), either one can access databases on the volumes they see. However, if K wants to access a database on disk X, it has to pass the request to server J, which performs the requested operations and passes the results back to K. This has serious consequences for load management.
Say there are 100 users on L, with 50 using an application on J and 50 on a K-based application, but all are accessing data on disk X. Remember, all X access has to go through J. In reality, J is doing everything for its 50 users as well as
all the file handling for an additional 50 users, while K is humming along with just the I/O for its 50 users to keep it busy. Server J could be seriously overworked, and response for all users would suffer as a result.
What happens if poor, overworked J can't take it and goes down? The clustering software instantly fails over and reassigns volume X to server K, which all of a sudden has to do some real work. The good news is that users will notice little degradation of service and little or no disruption in their applications; in the worst case, failover may look to them like a quick server reboot. Now, K may be in the same overworked and underpowered situation that J was just in. Load balancing this is not.
At the moment, only an Oracle-based cluster gets around this one-server-per-volume restriction. It does this by creating its own file and data structures.
i
llustration_link (7 Kbytes)
Both servers can access both disks--sort of.
Balancing Act
