dual hosts on scsi bus
Kevin Wipond
I want to put 2 hosts and 2 scsi disks on a common scsi bus. Only one host
will ever be talking to the 2 disks at any one time. I may however from time
to time decide to switch which host is allowed to talk to the disks. Both
hosts will be sparc 10's running solaris 2.3.
What do I have to do? Is it as simple as connecting all the devices and
appropriately configuring the scsi id's? My local sun rep is evasive and
has referred me to a product from Openvison. Do I need it?
Thanks for any advice you can provide
kevin
Don Matthews
: I want to put 2 hosts and 2 scsi disks on a common scsi bus. Only one host
As long as you don't want the two hosts to talk to each other, I see no
reason why you can't just hook them up and go for it. Just be aware
that if you reset the bus from one host, then a Unit Attention condition
will be presented to the other host when it goes to access a disk.
But your hosts should be able to handle this.
Good luck!
--
Scott D. Scheufler
Kevin,
I doubt it's all this simple. With the caching mechanisms such as lazy
write, the OS would have to be awfully cautious to work in a multiple initiator
environment. And let's not forget the possibility of file system corruptio. I
know that you said two wouldn't be talking to the same drive at the same time.
If you mean wouldn't be mounted by more than one, I think it should work.
Sun probably hem-haws because it MAY work in certain circumstances, but
when customers BELIEVE that you support it, you'll have to and it's not trivial.
Maranatha!
Scott
Gary Field
>kevin
Hardware-wise that is basically all you would do as long as you had a way
to change the host adapter's ID on one of the systems.
However the big problem is that since Unix systems (and even DOS systems)
cache portions of the filesystem, both hosts will think they know the state
of the disks and one of them will be wrong. When the one that's wrong writes
to the disk all hell will break loose. :-)
In summary, DON'T DO IT!
Gary
--
--/* Gary A. Field - WA1GRC, Wang Labs M/S 019-72B, 1 Industrial Ave
Lowell, MA 01851-5161, (508) 967-2514, email: ga...@wiis.wang.com, EST5EDT
A waist is a terrible thing to mind! */
Don Matthews
: I doubt it's all this simple. With the caching mechanisms such as lazy
: write, the OS would have to be awfully cautious to work in a multiple initiator
: environment. And let's not forget the possibility of file system corruptio. I
: know that you said two wouldn't be talking to the same drive at the same time.
: If you mean wouldn't be mounted by more than one, I think it should work.
: Sun probably hem-haws because it MAY work in certain circumstances, but
: when customers BELIEVE that you support it, you'll have to and it's not trivial.
A very good point. But is UNIX so stupid that you can't tell it to use
write-through caching instead of write-back caching? What this means is
that cache coherency is maintained with the disk. As long is that is true
then both hosts can access the disks with no problems.
But if that is not true, and if one host accesses the disk before the other
gets around to flushing its cache, then I'd agree with you, it's a bad idea.
--
Alain Fauconnet
>I want to put 2 hosts and 2 scsi disks on a common scsi bus. Only one host
>will ever be talking to the 2 disks at any one time. I may however from time
[...]
>What do I have to do? Is it as simple as connecting all the devices and
>appropriately configuring the scsi id's? My local sun rep is evasive and
>has referred me to a product from Openvison. Do I need it?
No you don't. As long as you take great care that *only* one host will
mount every disk at a given time, you're ok. We have such a
configuration here. I must say that we have a *differential* SCSI bus
(DSCSI) so I don't know whether this will work with regular SCSI or not.
Oh yes, don't forget to change the SCSI id for the controller of one of
the two hosts (change scsi-initiator-id to something different from 7
in the EEPROM). Don't forget that this will change the SCSI id on
*every* scontroller this host has.
Hope this helps,
_Alain_
--
Alain FAUCONNET Ingenieur systeme - System Manager AP-HP/SIM
Public Health Research Labs 91 bld de l'Hopital 75013 PARIS FRANCE
Mail: a...@biomath.jussieu.fr (*no* NeXTmail !)
Tel: (+33) 1-40-77-96-19 Fax: (+33) 1-45-86-80-68
Adrie Koolen
>Scott D. Scheufler (sc...@wotangate.sc.ti.com) wrote:
>: I doubt it's all this simple. With the caching mechanisms such as lazy
>: write, the OS would have to be awfully cautious to work in a multiple initiator
>: environment. And let's not forget the possibility of file system corruptio. I
>: know that you said two wouldn't be talking to the same drive at the same time.
>: If you mean wouldn't be mounted by more than one, I think it should work.
>: Sun probably hem-haws because it MAY work in certain circumstances, but
>: when customers BELIEVE that you support it, you'll have to and it's not trivial.
>
>A very good point. But is UNIX so stupid that you can't tell it to use
>write-through caching instead of write-back caching? What this means is
>that cache coherency is maintained with the disk. As long is that is true
>then both hosts can access the disks with no problems.
Using a write-through cache is of course not enough to let two Unix kernels
concurrently use the same disk. Luckyly the original poster doesn't want to
throw two Unix systems to one disk, but if he did, turning off *all* caches,
in the drive as well as in both Unix systems, will not suffice. When
creating a file, an inode has to be selected, block bitmaps have to be
consulted and modified, etc. I think that it can be done (using the Unit
Reserve SCSI command) but not without Unix filesystem modifications.
Adrie Koolen (ad...@ica.philips.nl)
Philips Consumer Electronics, Eindhoven, the Netherlands
Guy Dawson
|> Scott D. Scheufler (sc...@wotangate.sc.ti.com) wrote:
|> : I doubt it's all this simple. With the caching mechanisms such as lazy
|> : write, the OS would have to be awfully cautious to work in a multiple initiator
|> : environment. And let's not forget the possibility of file system corruptio. I
|> : know that you said two wouldn't be talking to the same drive at the same time.
|> : If you mean wouldn't be mounted by more than one, I think it should work.
|> : Sun probably hem-haws because it MAY work in certain circumstances, but
|> : when customers BELIEVE that you support it, you'll have to and it's not trivial.
|>
|> A very good point. But is UNIX so stupid that you can't tell it to use
|> write-through caching instead of write-back caching?
The cacheing cannot be changed.
|> What this means is
|> that cache coherency is maintained with the disk. As long is that is true
|> then both hosts can access the disks with no problems.
Not it does not. There is no eqv. of snooping in this system which is
required to maintain consistency.
Machine 1 reads a block of data
Machine 2 reads the same block of data
Machine 1 modifys the data and writes it back directly to disk
Machine 2 modifys the data and writes it back directly to disk
Machine 1 mods are lost...
The applications running on the system can be considered caches for the
purposes of this prolblem.
DEC VAXen in VAXClusters allow disks to be shared between multiple systems
by putting locking into the system. In the same way that a RDBMS can lock
data records the VAX can lock disk blocks and coordinate this between all
the CPUs on the system. Not a trivial piece of software...
|>
|> But if that is not true, and if one host accesses the disk before the other
|> gets around to flushing its cache, then I'd agree with you, it's a bad idea.
See above re cache and application...
|>
|> --
|>
|>
|>
|>
Guy
-- --------------------------------------------------------------------------
Guy Dawson home : g...@cuillin.demon.co.uk
work : gu...@hoskyns.co.uk
4.4>5.4 4.4>5.4 4.4>5.4 4.4>5.4 4.4>5.4 4.4>5.4 4.4>5.4 4.4>5.4 4.4>5.4
Adrian Cockcroft - SMCC Technical Marketing
One other issue: to get higher availability you *first* mirror your disks,
on Sun this means using Online:DiskSuite. If you dual host a single
disk you will get rather upset when the disk fails...
Second you buy a UPS for the whole system.
If you want even higher availability you dual host the disks to two systems.
You then have an interesting problem:- if a failover occurs, which of the
mirrors is valid and which may be invalid. I think the OpenVision HA product knows
how to deal with DiskSuite. SunIntegration also have some consulting specials
to make this work properly.
If the whole point of the excercise was to make the system more available, the
last thing you want is a poorly implemented and tested hack put together by
someone who has never done it before holding the two systems together.
Pick any one of these - fast, cheap, safe
You can't have all three, if you try really hard you might get two.
I would recommend buying either OpenVision HA with two SS10's, or buying a single
machine that has higher availability like a two board SS1000. The SS1000 will
reboot even if some subset of its boards, CPUs and Sbus cards have broken.
Regards Adrian
---
Adrian Cockcroft - adrian.c...@corp.sun.com - Mailstop: UPAL1-431
SMCC Technical Marketing - Phone (415) 336 0615 - Fax (415) 336 0648
Sun Microsystems, 2550 Garcia Avenue, Mountainview, CA 94043, USA
Steve Harmon
Actually, this still won't work due to the fact that the accesses between the
hosts aren`t synchronized (i.e. read-modify-write operations to disk blocks
aren't indivisible by other SCSI accesses). However, if no two hosts are using
the same partition (in the Unix world) then there shouldn't be any problem
sharing the SCSI bus.
--
| Steve Harmon @ AT&T Tridom Marietta, Georgia.
| INET: s...@eng.tridom.com
| UUCP: ..gatech!emory!tridom!srh
| VOICE: (404) 426-4261
|
Mike Mueller
kwi...@DATAP.CA writes:
>I want to put 2 hosts and 2 scsi disks on a common scsi bus. Only one
host
>will ever be talking to the 2 disks at any one time. I may however from
time
>hosts will be sparc 10's running solaris 2.3.
I have been monitoring the net for discussions on this topic for a while,
have talked to our Sun Technical Support, and have run a test using 2 Sun
SS10 running SunOS 4.1.3. I seems you can do this without any additional
software if you make sure that both Sun's don't mount the same partition
on the same disk. The test that we ran actually mounted a separate
partition on a single disk for each host. While one host was reading or
writing, we would reboot the other host. The read or write operation
would be interrupted by the bus reset, but would continue where it left
off. Both hosts could also read or write to their separate partitions
simultaneous with the other host reading or writing to its partition.
>
>What do I have to do? Is it as simple as connecting all the devices and
>appropriately configuring the scsi id's? My local sun rep is evasive and
>has referred me to a product from Openvison. Do I need it?
The OpenVision product Open*HA and a product from Qualix called Watchdog
FMS are advertised to allow more robust sharing and failover of disks
between two servers. I have included a copy of a SunFlash about
Watchdog, but couldn't find one about Open*HA. I would like to hear
about anyone's experience using either products.
There is currently an ongoing discussion about dual host failover in
comp.arch.storage that you may enjoy reading.
-----------------------------------------------------------------------
----
The Florida
SunFlash
Third Party Products Announcements
SunFLASH Vol 60 #18 December
1993
-----------------------------------------------------------------------
----
60.18.B
Subject: Qualix offers Watchdog FMS, High-Availability for UNIX
From: Barbara C. Coll
Org: QUALiX GROUP, INC.
Address: 1900 So. Norfolk Street, #224 San Mateo, CA 94403
Phone: 1-800-245-UNIX 1-800-245-8649
Fax: 1-415-572-1300
E-mail: in...@qualix.com
Watchdog FMS
High-Availability for UNIX client-server environments
-----------------------------------------------------
In today's competitive business climate, up-time is critical. High
availability and the integrity of the network have become crucial
considerations for industries such as telecommunications, finance,
retail, government, and high technology. Users in these fields, along
with many others, cannot afford server downtime and are constantly
looking for cost-effective ways to increase network and data
integrity. Watchdog FMS is a high-availability solution that addresses
that need.
Product Overview
----------------
Watchdog FMS is a software product designed to protect your critical
information services by providing monitor, restart, and failover
capabilities to a pair of UNIX-based servers. It is a flexible product
designed to handle network and data integrity problems found in a
client/server environment. The most common use of this technology is
NFS, RDBMS, and communication gateways. The technology is not limited
to these services. Watchdog FMS provides you with a single
cost-effective solution for your services which require
high-availability. It virtually eliminates the cost of interruptions to
mission critical applications.
Benefits of Watchdog FMS
------------------------
Watchdog FMS offers many benefits for environments requiring
high-availability, including:
* Redundant (two-way) recovery from a system failure from either server
* Redundant watchdog daemons on each host, eliminating SINGLE POINT of
FAILURE
* Fault-resilient watchdog daemons, ensuring the Watchdog FMS software
will
not be the cause of a failure
* Automatic restart of services monitored by Watchdog FMS agents
* wdAgent source code for customer specific monitored and restart of
applications
* Full use of system resources. Both machines are available for critical
application use. Watchdog FMS implements symmetric failover as a default
* Custom-built recovery schemes for each service being monitored
* Integration with dual-ported IPI, SCSI, DSCSI, and RAID storage
technologies
* NFS monitoring and failover provided by default
How Watchdog FMS works
-----------------------
The standard configuration is two servers, and a set of disks
accessible by both servers. Watchdog FMS monitors the health of the
server pair. When it detects a failure it will automatically:
* Gain access to the application data off the failed server
* Restart all services associated with the failed server
When Watchdog FMS is used with application-specific agents a number of
configurable scenarios can take place if the agent determines the
monitored application has failed. In all cased the agent will attempt
to restart the application four times. If it is unsuccessful it will
perform one of the following tasks as determined by the system
administrator:
* Send a message to the sys admin notifying them that the service is down;
* Send an alert to SunNet Manager's console about the service being down;
* Reboot the entire system in an attempt to fix the problem; or
* Halt the system, in which case the alternate server will automatically
take over for the failed server, restarting all the applications.
In all cases of failover the alternate server impersonates the network
identity of the failed server allowing client applications to access
data and services with minimal user disruption.
Watchdog FMS software provides system integrity, reliability, and
continued system operations instituting redundant technology for
software recovery, restart, and failover.
System Requirements
-------------------
Equipment:
2 UNIX-based servers
a private Ethernet network requiring: 1 SCSI port on each server and cable
Sun SPARCstation IPX
Sun SPARCstation/server 10 family
Sun 6XXMP family of servers
Sun SPARCserver 1000
Sun SPARCcenter 2000
[Q194 HP 9000 700/800 series and IBM RS/6000 families will be supported]
Operating Systems:
SunOS 4.1.2, SunOS 4.1.3
Solaris 2.2
MOTIF/command line interface
Disk Technologies Supported:
SCSI: all vendors conforming to the SCSI-2 specification. This must
include support for multi-initiation.
IPI: Sun Microsystems drives on all Sun-supported servers. Sun OnLine:
Dual-Port software required.
DSCSI: Sun Microsystems drives implementing differential SCSI technology.
Software-based agent support (provided): NFS
Software source code provided: wdNFS and wdAgent (generic agent code)
Availability
------------
Watchdog FMS 2.0 will be available in December 1993.
Watchdog FMS will be distributed through the Qualix Group
(1-800-245-8649).
Evaluations
-----------
15-day evaluations of the product are available from Qualix at
no cost. Please contact for Qualix sales representative to qualify for
an evaluation copy of Watchdog FMS software.
Pricing
-------
Sun SPARC - SunOS 4.1.x version $10,500
Sun SPARC - Solaris 2.2 (2.3) version $11,500
Support pricing: ~20% of list price of product for installation, minor
and major upgrade support on a yearly basis
HOW TO ORDER
-------------
Qualix Group accepts MasterCard, VISA or a valid corporate
purchase order. Call us at 1-800-245-UNIX , 415-572-0200, or
send e-mail to in...@qualix.com to place an order or if you'd
like more information. (Our fax number is 415-572-1300.)
GUARANTEE
---------
We offer a 30-day money-back guarantee, so if you're not fully
satisfied, we'll refund your money.
CORPORATE DISCOUNTS
--------------------
Your company may have a Corporate Discount Agreement with us,
which will entitle you to special DISCOUNTS!
If your company has UNIX workstations, but doesn't have a
corporate discount in plan, call us to get more information on
how you can get the best UNIX software products at the best
price.
CALL US TODAY
--------------
Call us today (1-800-245-UNIX) or send e-mail to info@qualix to
learn more about the product we carry or to receive our FREE
UNIX SOFTWARE BUYER'S GUIDE. This guide is full of up-to-the
minute information on the products we carry.
=================================================================
Mike Mueller
Member of Technical Staff
Image Processing Applications and Development Section
Jet Propulsion Laboratory
Ronald Hasenberger
> kwi...@DATAP.CA (Kevin Wipond) writes:
>
>
>>I want to put 2 hosts and 2 scsi disks on a common scsi bus. Only one host
>>will ever be talking to the 2 disks at any one time. I may however from time
> [...]
>>What do I have to do? Is it as simple as connecting all the devices and
>>appropriately configuring the scsi id's? My local sun rep is evasive and
>>has referred me to a product from Openvison. Do I need it?
>
> No you don't. As long as you take great care that *only* one host will
> mount every disk at a given time, you're ok. We have such a
> configuration here. I must say that we have a *differential* SCSI bus
> (DSCSI) so I don't know whether this will work with regular SCSI or not.
I don't think that there is any difference between differential or
regular SCSI because the termination has to be correct in either version
and there may talk only one device at the bus at one time.
The physics are not the problem here; only such informatical things
like caches,... :-)
Ronald
-------------------------------------------------------------------------
Ronald HASENBERGER Hasen...@elin.co.at
ELIN-Energieanwendung GesmbH
A-1141 Vienna, Austria, Penzingerstr.76
Phone: +43 1 89100-3524 Fax: +43 1 8946046
Richard Croucher
|> In article <1994Mar29.1...@datap.ca> Kevin Wipond,
|> kwi...@DATAP.CA writes:
|> >I want to put 2 hosts and 2 scsi disks on a common scsi bus. Only one
|> host
|> >will ever be talking to the 2 disks at any one time. I may however from
|> time
|> >to time decide to switch which host is allowed to talk to the disks. Both
|> >hosts will be sparc 10's running solaris 2.3.
|>
|> I have been monitoring the net for discussions on this topic for a while,
|> have talked to our Sun Technical Support, and have run a test using 2 Sun
|> SS10 running SunOS 4.1.3. I seems you can do this without any additional
|> software if you make sure that both Sun's don't mount the same partition
|> on the same disk. The test that we ran actually mounted a separate
|> partition on a single disk for each host. While one host was reading or
|> writing, we would reboot the other host. The read or write operation
|> would be interrupted by the bus reset, but would continue where it left
|> off. Both hosts could also read or write to their separate partitions
|> simultaneous with the other host reading or writing to its partition.
|> >
|> >What do I have to do? Is it as simple as connecting all the devices and
|> >appropriately configuring the scsi id's? My local sun rep is evasive and
|> >has referred me to a product from Openvison. Do I need it?
In principle all you have to do is change the scsi-initiator-id on one of the two SUNS which are
going to share the same disk. This will give them the physical means to share the same SCSI bus.
It will obviously not solve the problems of concurrent access to a single filesystem, and I would
even avoid sharing the same drive cincurrently but accessing different partitions since each
SUN will be trying to optimise head movements without realising that another system is banging
it somewhere else.
See Eeprom(1) for details on changing the SCSI ID.
Has anybody actually tried this?
==========================================================================
Richard Croucher | EMAIL rc...@ccc.amdahl.com
| +44 252 346376
Any views, opinions expressed are my own and do not necessarily reflect
those of Open Systems Europe, or the Amdahl Corporation.
==========================================================================