SITUATION 7
Schedule Upgrades to Your System
Problem: You would rather not spend all your nights and weekends upgrading your systems.
Solution: By putting your servers into a cluster group, you can manually fail over a
node during working hours. Remember, the users are still working on the remaining node. Now you can
apply a service pack, test it, and pray.
Once you are satisfied that the service pack changes are working, you can manually fail back
the node and the workload. Any NT clustering solution currently available will work in this
scenario.
SITUATION 8
Manually Load Balancing Your System
Problem: You have too many applications running on one server while another server is
barely used.
Solution: Ordinarily, you have to take down both servers, change their configuration,
and restart. If the servers are part of an active/active cluster group, you can manually fail over a
single application without taking down an entire node. This approach effectively moves the
application from one server to another.
You must make sure the solution supports application failover (as opposed to system
failover). Application failover lets you fail over a single application without taking down the
entire node, instead of failing over the entire system. For example, even though Octopus is
active/active, it supports only system failover today, which requires taking down the node. However,
soon after you read this article, Octopus SASO 3.0 will be shipping, and it supports
application-level failover.
SITUATION 9
Two SQL Servers
Problem: You need high availability for users accessing two independent SQL Server
databases, each running on a separate server.
Solution: You need an active/active application clustering solution so that both nodes
can be running SQL Server simultaneously. This requirement eliminates Wolfpack from your list of
choices, because it can run only one instance of SQL Server per cluster. However, Digital
Equipment's Wolfpack clustering add-on pack and NCR's LifeKeeper let you run two copies of SQL
Server in the same cluster, allowing each server to be the fallback for the other and thus
increasing availability.
SITUATION 10
Scaling Exchange
Problem: You want to scale Exchange to run faster and have high availability. You have a
dual Pentium Pro server.
Solution: Adding two CPUs to your server configuration would be nice, but
unfortunately, Exchange scales effectively to only two CPUs (for more information about Exchange's
ability to scale, see Joel Sloss, "Optimizing Exchange to Scale on NT," November 1996). In
fact, the next release of Exchange (version 6.0) has been dubbed the "performance release"
and will address this scalability problem. Wolfpack won't address scalability until phase 2, which
isn't due until 1998. So are we stuck?
Valence Research's Convoy Cluster claims to add availability and scalability for TCP/IP
applications and to provide load balancing among nodes in a cluster. This product is primarily aimed
at intranet applications. Convoy Cluster was not available when we tested solutions for this issue.
If this solution can scale, it will leapfrog Wolfpack by a year.
Future Trends
As these scenarios demonstrate, Wolfpack is not the appropriate solution in every case. Even so,
Wolfpack is having a huge effect on hardware and software vendors.
When Wolfpack phase 2 starts shipping in 1998, developers can use the Wolfpack APIs to create
applications that will let cluster nodes work in parallel. The issue of scalability will start a
heated debate among system vendors: Is a cluster of 4-way SMP systems better than 8-, 12-, and
16-way SMP systems? If the answer is yes, NT will never have to scale beyond four CPUs in a single
system. As long as you can cluster 4-way systems and scale performance, NT will have a price and
performance unrivaled in the marketplace.
In the early adoption phase, companies will want to buy complete cluster-in-a-box
configurations, hoping to eliminate as many problems as possible. However, as clustering moves
mainstream, users will demand the ability to mix and match components. Keeping up with NT's HCL is
hard enough, and keeping up with the WHCL will be even harder. Octopus has been on the leading edge
for more than two years, by letting users mix and match components easily. Other vendors will need
to do the same.
As more system vendors support Wolfpack, additional features will provide a competitive
advantage. For example, Digital supports Wolfpack, but also offers a cluster add-on package that
lets both nodes of a cluster run SQL Server and gives existing users of Digital NT Cluster a
migration wizard. Compaq, Tandem, and Dell will enhance their Wolfpack offerings by supporting
ServerNet, a high-speed interconnect. NCR supports Wolfpack, but also supports LifeKeeper, which
allows three-node clusters, compared with Wolfpack's two-node limitation.
Finally, look for other vendors to solve the scalability problem before Wolfpack. For example,
Oracle Parallel Servers lets two or more Oracle database server nodes work on the same database,
running queries in parallel on multiple nodes. Oracle will try to one-up Microsoft by shipping this
level of scalability on NT before Microsoft can release the parallel version of SQL Server (version
8.0).
Corrections to this Article:
- In Mark Smith's article, "Clusters for Everyone," we incorrectly reported that Stratus uses a proprietary interconnect. In fact, Stratus uses standard, redundant 100Base-T connections. Though Isis Availability Manager (cluster software) runs on only Stratus, Stratus hardware can run multiple clustering software solutions, including Microsoft's Wolfpack clustering software. Finally, Stratus uses mirroring technology rather than SCSI-switching as was originally reported. For more information, visit the Stratus Web site at http://www.stratus.com.