Conference smurf::ase

 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

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

    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?

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.

    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.

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]

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


-Steve
[Posted by WWW Notes gateway]

 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)