Yes, but much more expensive than a Shuttle! Quotation from site
briQ w/PowerPC G3 (750) 500MHz, 256MB SDRAM, 10GB HDD - $1,499
briQ w/PowerPC G4 (7400) 500MHz, 512MB SDRAM, 20GB HDD - $1,999
We use NT 4 EE (Enterprise Edition) clusters, running Microsoft Cluster Services (MSCS) extensively, on primarily IBM x86 hardware. Clusters run Microsoft SQL Server 7 Enterprise Edition, which is "Microsoft Cluster Aware" as well as applications which are NOT cluster aware.
One co-worker has coined the clustering as a "glorified re-boot" because if Node A crashes, the SQL Server there really becomes totally unavailable for a short period of time before it starts up on Node B (which includes moving the IP Address[es], disk-drives, NetBIOS Name, SQL Server, etc. over to the other node). Maybe Win2k is better about having a "hot standby" or seamless failover.
One huge drawback, at least with NT4 EE and SQL Server 7, is updating (service-packing) SQL -- had to totally UNCLUSTER the whole cluster [a timely endeavor] just to get SQL 7 updated to Service-pack 3.
Another drawback is having applications which are "not cluster aware" and sort of "forcing" them into the MSCS cluster environment -- they don't always behave properly in a failover situation, especially if you have applications which normally require lots of user-interaction to startup and shutdown properly. However, this problem with cluster "unaware" applications is probably true with any cluster.
As others have posted, the key is defining what you want from your cluster and seeing how that matches to the definition of "cluster" put forth by the various vendors you're looking at using.
Slashdot Mirror
Yes, but much more expensive than a Shuttle! Quotation from site briQ w/PowerPC G3 (750) 500MHz, 256MB SDRAM, 10GB HDD - $1,499 briQ w/PowerPC G4 (7400) 500MHz, 512MB SDRAM, 20GB HDD - $1,999
Interesting to see that Microsoft has spies posting to Slashdot!
We use NT 4 EE (Enterprise Edition) clusters, running Microsoft Cluster Services (MSCS) extensively, on primarily IBM x86 hardware. Clusters run Microsoft SQL Server 7 Enterprise Edition, which is "Microsoft Cluster Aware" as well as applications which are NOT cluster aware.
One co-worker has coined the clustering as a "glorified re-boot" because if Node A crashes, the SQL Server there really becomes totally unavailable for a short period of time before it starts up on Node B (which includes moving the IP Address[es], disk-drives, NetBIOS Name, SQL Server, etc. over to the other node). Maybe Win2k is better about having a "hot standby" or seamless failover.
One huge drawback, at least with NT4 EE and SQL Server 7, is updating (service-packing) SQL -- had to totally UNCLUSTER the whole cluster [a timely endeavor] just to get SQL 7 updated to Service-pack 3.
Another drawback is having applications which are "not cluster aware" and sort of "forcing" them into the MSCS cluster environment -- they don't always behave properly in a failover situation, especially if you have applications which normally require lots of user-interaction to startup and shutdown properly. However, this problem with cluster "unaware" applications is probably true with any cluster.
As others have posted, the key is defining what you want from your cluster and seeing how that matches to the definition of "cluster" put forth by the various vendors you're looking at using.