[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decwet::winnt-clusters

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

612.0. "WinNT Clu only nonWan solution?" by SCASS1::WILSONM () Mon Feb 10 1997 20:19

    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.RTitleUserPersonal
Name
DateLines
612.1WAN support with V1.1MPOS01::naiad.mpo.dec.com::mpos01::cerlingI'm@witz.endTue Feb 11 1997 12:4022
	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.2What about NetBT???SCASS1::WILSONMTue Feb 11 1997 14:335
    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.3GUIDUK::HEALYAlan Healy @ZSOTue Feb 11 1997 14:565
    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.4IP socket failover in V1.1, NetBT maybeDECWET::CAPPELLOFMy other brain is a polymerTue Feb 11 1997 21:0910
    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.