| Title: | WinNT-Clusters |
| Notice: | Info directories moved to DECWET::SHARE1$:[NT_CLSTR] |
| Moderator: | DECWET::CAPPELLOF |
| Created: | Thu Oct 19 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 863 |
| Total number of notes: | 3478 |
I was reading the Clustering Solutions for NT Datapro report. In
a comparison matrix there is a question "Must clients be on same
LAN as server for auto reconnect".
The data is;
Compaq Online Recovery Server NO
LifeKeeper for Windows NT NO
Octopus for Windows NT with ASO NO
Digital Clusters for Windows NT YES
The info would imply that our client is the only one that has a problem
in supporting a WAN connection. Is this true?
The report doesn't get too specific but under strengths for NCR
LifeKeeper "All clients automatically reconnected, regardless of type
or location".Octopus "Connects servers via LAN or WAN" under its
strengths.
Do we care? Are we going to address this? When will we address this? Do
we hope customers aren't smart enough to figure it out? What is the
plan?
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 612.1 | WAN support with V1.1 | MPOS01::naiad.mpo.dec.com::mpos01::cerling | I'[email protected] | Tue Feb 11 1997 09:40 | 22 |
For version 1.1, we will be able to say the same thing, that is, clients do not need to be on the same LAN to auto-reconnect. That will be for the IP failover capability. Looking at Compaq's documentation, it looks like you can write applications to their API to accomplish this; we avoided exposing our API. Reading NCR's documentation, it looks like they are providing IP failover; just what we will be doing in V1.1. Octopus, well I'm not quite sure on them. They replicate their data across the LAN/WAN. I wonder how the guarantee that an update written to the current server is correctly applied to each backup server. The old problem of the two-phased commit. They might couch their solution in a statement that some work might have to be redone to come up to the status of the system that just disappeared. So, we can talk about WAN support with V1.1. However, it all may be moot 8-12 months from now or whenever we switch to Wolfpack as the solution. As a stockholder, I would question whether the expense of adding LAN share failover to a product with a short lifetime is something that would make a significant return on our investment. tgc | |||||
| 612.2 | What about NetBT??? | SCASS1::WILSONM | Tue Feb 11 1997 11:33 | 5 | |
Thanks for the info. My concern and question is about NetBT. The other
products and the study imply they can accomplish file/print over a WAN
and V1.1 will not address this with automatic failover. Does anyone
know if these other products are able to provide failover for a file
service over a WAN, a subnet segmented WAN?
| |||||
| 612.3 | GUIDUK::HEALY | Alan Healy @ZSO | Tue Feb 11 1997 11:56 | 5 | |
Is it not true that most of the competitive solutions work only for
database systems, not file shares? Therefore, they don't have the
problem because they don't have the capability to expose file shares.
Al
| |||||
| 612.4 | IP socket failover in V1.1, NetBT maybe | DECWET::CAPPELLOF | My other brain is a polymer | Tue Feb 11 1997 18:09 | 10 |
We're working on getting file share failover via NetBT to work for
V1.1. Depends on NT Service pack updates from Microsoft, as NetBT
never knew about changing addresses before.
As a previous reply indicated, failover of client TCP/IP socket
applications will work over a WAN in Digital Clusters v1.1, so we'll be
equal to the other guys.
I seriously doubt whether any of the other vendors provides file-share
failover on a WAN, based on our experience.
| |||||