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

Conference smurf::ase

Title:ase
Moderator:SMURF::GROSSO
Created:Thu Jul 29 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2114
Total number of notes:7347

1706.0. "FWD fiber extenders ?" by SPANIX::JULIANR (ALPHAbet = Our bet on ALPHA) Tue Nov 05 1996 09:21

T.RTitleUserPersonal
Name
DateLines
1706.1XIRTLU::schottEric R. Schott USG Product ManagementTue Nov 05 1996 13:245
1706.2The fibre extender program is alive and well.FIEVEL::FILGATEBruce Filgate SHR3-2/W4 237-6452Mon Feb 03 1997 10:5633
 Eric's short answer was a little too short perhaps.

 The extenders pick up the FWD SCSI and bridge it to Fibre channel PP
 which is optically coupled to another bridge for the reverse.  We have
 had a set of these running at a large bank for a couple of months in
 a test.

 DECsafe was never designed to be extended over a wider area than a 
 computer room.  The use of SCSI-Fibre bridges would allow a physical
 extension over miles.  But just because something could be physically
 connected, does not mean that it should be connected, and especially it
 does not mean that it should be sold!

 The technical reason for not extending DECsafe is that the product
 relies very much on the communications lines between the hosts, there
 are many scenarios in an extended configuration that could potentially
 lead to a network partition.  In a partition, both portions of the 
 configuration may be led to operate as if they owned the surviving portion
 of the network. [by way of a simple example, this class of failure would
 allow an airline reservation system to book the same seat for each of
 the partitions in the network].

 Bottom line, DECsafe depends on some properties of network and storage
 interconnects, distance abrogates this dependency and leads to a
 potential reliability problem.

 Updates/status of the bridge are on the DEC intra-net are at

        http://osfsrv.shr.dec.com/abc_se/s2f/

 
 Bruce
1706.3SMURF::KNIGHTFred KnightMon Feb 10 1997 13:3111
The other reason the Extenders don't work is an honest to goodness
technical reason.  The extenders use store and forward, and there
are situations when you have hosts on both ends where some particular
bus sequences will cause bus hangs.  This then leads to a partitioned
cluster which leads to data corruption.

Sometimes we say something isn't supported just because we haven't
tested it.  Sometimes it's not supported because it doesn't work.
In this case, it's because it doesn't work!

	Fred
1706.4how about LSM to mirror local and remote disks?TROOA::MSCHNEIDERmartin.schneider@tro.mts.dec.comTue Feb 11 1997 15:412
    Ok let's forget about DECsafe.... can we use this stuff to have local
    and remote disks and use LSM to mirror the data?  Is this supported?
1706.5KITCHE::schottEric R. Schott USG Product ManagementTue Feb 11 1997 16:4425
Once the scsi extender is available, yes you can use LSM to
mirror across it.  You should note a few things:

  - there are configuration rules of how the scsi extender will have
    to be setup...storage will provide these when announcing any product
    along this line.

  - The performance is not the same as the local bus...this has to
    be considered in the configuration.


  - Finally, you should note that if something happens to the
    local site, the remote site may not have all its mirrors in
    time sync to each other...this could cause you to have difficulty
    in restarting lets say a database....this is why remote mirroring
    does not mean you have disaster tolerance...because you could
    have a set of mirror copies at a site that are not in time
    sync with each other...data integrity can be a real nightmare
    in this situation.

It would be helpful to state what is the customers goal, rather than
the technical solution...I'm not saying your solution is wrong, just
that I don't know how to measure good vs not good.


1706.6more dataTROOA::MSCHNEIDERmartin.schneider@tro.mts.dec.comWed Feb 12 1997 12:1141
    Here's the problem we're trying to address
    
    Current customer situation:

    - customer has two data centers in 2 of their buildings that are
      less than 500m apart
    - 2 HP servers, 1 in each data center
    - HP-FL storage (max 500 meters from host)
    - HP failover solution (not sure if it is MC/ServiceGuard or its
      predecessor)
    - application is Sybase DB and related applications
    - this is an steel making environment so the customer is concerned 
      that an industrial accident could cause the shutdown of the primary
      data center
    - customer is unhappy with HP-FL performance (max 5 MB/sec according
      to HP specs
    
    We came to this customer to give them a presentation on StorageWorks
    and from this they also asked us to prepare a systems quote as they are
    about to upgrade their old HP servers.  We are bidding AlphaServer 4x00
    systems.
    
    We are stymied in our inability to provide a solution that allows us to
    place the 2 servers in 2 separate datacenters.  The CSS FC solution looks
    interesting, but it is still in its infancy.  The customer is willing
    to consider a manual switchover solution where the 2nd server is only
    connected to the disks mirrored from the main datacenter upon a
    failure.  This is why I presumed SCSI extenders to be a solution.
    
    Customer has mentioned EMC solution that HP is no doubt bringing to the
    table.  Also our business partner has talked to his IBM storage buddies
    and they apparently also have a solution (SSA I presume) to deal with
    the distance issue.
    
    We're also trying to address the problem in another fashion by
    suggesting that the customer consider locating a small datacenter in
    another building on the site that is not close to the steel plants and
    place a DECsafe solution there rather than in the plants.  This is a
    real stretch as I don't imagine their interested in relocating their
    facilities to accomodate our inability to deliver a solution to meet
    their needs.
1706.7More resources to look at...NETRIX::"horn@kitche.zk3.dec.com"Steve HornThu Feb 13 1997 14:1420
Depending on the timeframe one potential use of the SCSI Extenders would be to
use the Controller based mirroring that is being worked on in storage combined
with the SCSI Extenders.  Then depending on the size and volatility of the
database decide on what you need to mirror.  

Take a look at the DT web page for some explanation of the issues, and the
questions you need to ask.  One in particular you haven't answered is the
Data Loss question.  If they can deal with 5 minutes lost data you may be able
to avoid the whole mess and use Sybase Rep Server!  At this point, with
Sybase,
the only way to be 'DT Safe' would be synchronous mirroring of either the
whole
database or the undo-redo logs.  Asynchronous Controller based mirroring
does not mix well with databases!

Steve


[Posted by WWW Notes gateway]
1706.8The DT web page is at...NETRIX::"horn@kitche.zk3.dec.com"Steve HornThu Feb 13 1997 14:197

http://www-unix.zk3.dec.com/www/dt.html


-Steve
[Posted by WWW Notes gateway]
1706.9any DT solution has a two edge sword working against itFIEVEL::FILGATEBruce Filgate SHR3-2/W4 237-6452Sun Feb 16 1997 16:0316
 Since light and electricity travel at a finite speed, the loop delay
 between a remote and local site is non-zero.  Since several loop cycles
 must be taken for fully interlocked communication, a large delay gets
 associated with each IO.

 If we want to be sure the data coherency is maintained between the local
 and remote sites, we must accept a performance penalty.

 If we want high performance, we must cheat the full interlocking that
 provides the assured coherence, and risk data loss/confusion.

 While I don't like either edge, we don't have good way to push
 the signal propagation rate past the speed of light.

 Bruce  (storage DT)