Mailing List Archive: Linux-HA: Users

Fw: Help! Problems with IP address takeover on 2.0.36

Index | Next | Previous | View Threaded

alanr at bell-labs

Dec 8, 1998, 11:11 PM

Post #1 of 18 (1848 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36

Zenaan Harkness wrote:
>
> Can someone please briefly answer the following question, or point me to a
> URL that might describe the differences:
>
> What is 'shared-data'/'shared-disk filesystem'? (Most importantly, how does
> it differ from the standard 'file access accross a network' used in Windows
> and every other operating system.)

A shared disk configuration is one where one or more disk drives are
attached to multiple hosts, so that if one host goes down, one or more
other hosts can still access the data on the drives.

Some forms of disk sharing allow two or more systems to read and write
the a filesystem simultaneously. Others only allow one system to access
it at a time. I believe the discussion you were replying to was using
it to mean multiple hosts accessing the drives simultaneously.

The possibilities for a bad implementation resulting in hung filesystems
or scrambled data in such a configuration are awesome and
mind-boggling. Of course, that's why it's interesting :-)

CODA is a filesystem which implements a shared data concept without
having shared disk. It uses the network for replication in lieu of a
single disk farm with multiple host attachments.

>
> Thank you,
> Zen.

I'm pretty sure I got that right, but I know for certain that if I
didn't, that I'll be corrected pretty soon :-)

-- Alan Robertson
alanr [at] bell-labs

mjc at rodagroup

Dec 9, 1998, 3:35 AM

Post #2 of 18 (1817 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

On Wed, 9 Dec 1998, Zenaan Harkness wrote:

> Can someone please briefly answer the following question, or point me to a
> URL that might describe the differences:
>
> What is 'shared-data'/'shared-disk filesystem'? (Most importantly, how does
> it differ from the standard 'file access accross a network' used in Windows
> and every other operating system.)

At least as I use these terms, they refer to cluster designs in which
multiple hosts read and/or write to a given storage device simultaneously.
Such designs are rare right now at least in part because most disks are
connected to hosts using SCSI, and it is not easy using SCSI to connect
more than two hosts or so to a given string of disks.

If you go to Sun, IBM etc and order up a Unix cluster, instead you'll get
one that uses a 'shared-nothing' approach. That means that, at any given
time, a disk is owned by one host that accesses it exclusively. The disk
may be (typically will be) attached to two hosts, so that if the owning
host fails a backup host can get the data. However, at any point in time
only one host thinks that it is allowed to access the disk. So the disk
is not "shared", if you like.

VMS has a filesystem that was designed to allow multiple machines to
access a disk directly and simultaneously. That's a "shared-disk"
filesystem.

In contrast, when you use a network filesystem ("file access across a
network"), only one host, the server, talks to the disk. Other clients
send network requests to the server asking for files. In a VMS cluster,
other machines can actually read the files directly off the disks.

Michael

dlang at diginsite

Dec 9, 1998, 6:17 AM

Post #3 of 18 (1818 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----

I have now seen several people make the comment that SCSI does not allow
more then 2 machines to connect to it. where is this limit? As I
understand SCSI there is nothing that would prevent you from using wide
scsi to hook up 15 computers to one drive and, assuming they were all
accessing different partitions, they should even be able to access the
drive simultaniously.

David Lang

On Wed, 9 Dec 1998 mjc [at] rodagroup wrote:

> Date: Wed, 9 Dec 1998 02:35:39 -0800 (PST)
> From: mjc [at] rodagroup
> To: Zenaan Harkness <zen [at] getsystems>
> Cc: linux-ha [at] muc
> Subject: Re: Fw: Help! Problems with IP address takeover on 2.0.36
>
> On Wed, 9 Dec 1998, Zenaan Harkness wrote:
>
> > Can someone please briefly answer the following question, or point me to a
> > URL that might describe the differences:
> >
> > What is 'shared-data'/'shared-disk filesystem'? (Most importantly, how does
> > it differ from the standard 'file access accross a network' used in Windows
> > and every other operating system.)
>
> At least as I use these terms, they refer to cluster designs in which
> multiple hosts read and/or write to a given storage device simultaneously.
> Such designs are rare right now at least in part because most disks are
> connected to hosts using SCSI, and it is not easy using SCSI to connect
> more than two hosts or so to a given string of disks.
>
> If you go to Sun, IBM etc and order up a Unix cluster, instead you'll get
> one that uses a 'shared-nothing' approach. That means that, at any given
> time, a disk is owned by one host that accesses it exclusively. The disk
> may be (typically will be) attached to two hosts, so that if the owning
> host fails a backup host can get the data. However, at any point in time
> only one host thinks that it is allowed to access the disk. So the disk
> is not "shared", if you like.
>
> VMS has a filesystem that was designed to allow multiple machines to
> access a disk directly and simultaneously. That's a "shared-disk"
> filesystem.
>
> In contrast, when you use a network filesystem ("file access across a
> network"), only one host, the server, talks to the disk. Other clients
> send network requests to the server asking for files. In a VMS cluster,
> other machines can actually read the files directly off the disks.
>
> Michael
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBNm54XT7msCGEppcbAQFc9Af/V3e5avbl31Mu3jik3DwEafMp8uH9AbEq
6xqrSbY0p6eGZq/ldw/aHPBtLDTHQqN4tre1FCeOF12jX7+gBDzHLMQM7gzQgq5u
a51A4EyJUnPNtuHFY60QbsKpTSs+qWCJg4nGSMZHJNKWmrRKyrm4wwmoem1qIhK3
ZkF2q7mdXg38ojUwI9B3dGgEZLG3BHTbtXJXQhrl7G3uLaQo9sAMrlO0xCXuPpGO
6Hdbs2+lrMsANHCTcZ0raPq8pkeBFy0NWPerP0ksZ6DG5mI0h1RQENh7pfk776Bt
uF/JF/Axk1zdX4IJ6hjTVEEEywUzL1dDSj7JSJm8a0JLIkQQBVEgsw==
=dFdj
-----END PGP SIGNATURE-----

alanr at bell-labs

Dec 9, 1998, 7:58 AM

Post #4 of 18 (1810 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

David Lang wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> I have now seen several people make the comment that SCSI does not allow
> more then 2 machines to connect to it. where is this limit? As I
> understand SCSI there is nothing that would prevent you from using wide
> scsi to hook up 15 computers to one drive and, assuming they were all
> accessing different partitions, they should even be able to access the
> drive simultaniously.
>
> David Lang
>

You're right, at some level. The problem is cable runs, cable length,
etc. are usually problematic in practice. Fast SCSI has relatively
short cable length restrictions (though I can't recall what they are).
By the time you make neat cable runs, it's a problem. Also, SCSI is
difficult or impossible to hot-plug, so that if one machine comes down
to be replaced or significantly messed with, it may require the SCSI
activity on all the other machines to be stopped at least momentarily.

The number two probably dates back to 8-address SCSI, but is probably
pretty close to the practical constraint in faster SCSI, because the
cables have to be shorter, and things are more tricky.

-- Alan Robertson
alanr [at] bell-labs

lnz at dandelion

Dec 9, 1998, 10:55 AM

Post #5 of 18 (1807 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

Date: Wed, 9 Dec 1998 05:17:15 -0800 (PST)
From: David Lang <dlang [at] diginsite>

I have now seen several people make the comment that SCSI does not allow
more then 2 machines to connect to it. where is this limit? As I
understand SCSI there is nothing that would prevent you from using wide
scsi to hook up 15 computers to one drive and, assuming they were all
accessing different partitions, they should even be able to access the
drive simultaniously.

I do not believe there is any specific limit on the number of initiators. On
4-way Sequent clusters, there most definitely were 4 initiators and 12 target
devices on their differential SCSI buses.

Leonard

From Agent Tatum <josh [at] ai> Wed Dec 9 19:57:19 1998 [467]
From: Agent Tatum <josh [at] ai> (Agent Tatum)
Date: Wed, 9 Dec 1998 13:57:19 -0600 (CST)
Subject: SCSI questions.
In-Reply-To: <366E902E.E450EA22 [at] bell-labs>
Message-ID: <Pine.LNX.3.96.981209131730.3476A-100000 [at] ai>

On Wed, 9 Dec 1998 alanr [at] bell-labs wrote:

> David Lang wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > I have now seen several people make the comment that SCSI does not allow
> > more then 2 machines to connect to it. where is this limit? As I
> > understand SCSI there is nothing that would prevent you from using wide
> > scsi to hook up 15 computers to one drive and, assuming they were all
> > accessing different partitions, they should even be able to access the
> > drive simultaniously.
> >
> > David Lang
> >
>
> You're right, at some level. The problem is cable runs, cable length,
> etc. are usually problematic in practice. Fast SCSI has relatively
> short cable length restrictions (though I can't recall what they are).
> By the time you make neat cable runs, it's a problem. Also, SCSI is
> difficult or impossible to hot-plug, so that if one machine comes down
> to be replaced or significantly messed with, it may require the SCSI
> activity on all the other machines to be stopped at least momentarily.
>
> The number two probably dates back to 8-address SCSI, but is probably
> pretty close to the practical constraint in faster SCSI, because the
> cables have to be shorter, and things are more tricky.
>
>
> -- Alan Robertson
> alanr [at] bell-labs
>

I have personally set up 8-node single bus HACMP clusters attached to
various RAIDS (EMC, CLARiiON, etc.). AIX has a concurrent mode that, with
the use of a lock manager, allows as many nodes as you can fit on the bus
to write to a particular raw logical volume. The most frequent problem
that I've run into has been resets on the SCSI bus and how well the RAID
responds to them. When working properly and using Y-cables on the backs of
all of the nodes, I/O shouldnt stop but will quite possibly pause
momentarily (5-10 seconds) while the rejoining nodes initiates the
adapter/disks. Most RAIDs now days have several SCSI ports, all of which
can be configured to see all of the disks which. This allows for you to
even yank out and replace a bad cable without disturbing I/O on the other
nodes. Bringing down a system for maintence manually should not cause I/O
to stop unless you are also switching an application from the node being
swapped.

Unexamined faith is ignorance.
Bye
Josh

mjc at rodagroup

Dec 9, 1998, 1:22 PM

Post #6 of 18 (1808 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

On Wed, 9 Dec 1998, David Lang wrote:

> I have now seen several people make the comment that SCSI does not allow
> more then 2 machines to connect to it. where is this limit? As I
> understand SCSI there is nothing that would prevent you from using wide
> scsi to hook up 15 computers to one drive and, assuming they were all
> accessing different partitions, they should even be able to access the
> drive simultaniously.
>
> David Lang

I think I have several times said that SCSI makes it unattractive to put
more than about two hosts on a string. It's true that you could have 15
hosts and one drive, but you still face the line-length limitations and
bandwidth contention problems that SCSI has. In practice this has meant
that people tend not to put many initiators on SCSI strings. With
Digital's CI, it was not unheard-of to have a dozen hosts on the same
interconnect with tens of storage devices.

Michael

kland at land-5

Dec 9, 1998, 4:28 PM

Post #7 of 18 (1814 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

The cable limit can be resolved by using either Differential or LVD SCSI,
my suggestion for this application would be to use LVD, as it supports hot
swap and speeds of 80MB/Sec. It also supports 12 meters of length per
channel. The new technology would be Fibre Channel which goes to approx
300 meters and 126 devices. Additionally you could use a Fibre Channel
active switch.

Kris Land

At 12:22 PM 12/9/98 -0800, you wrote:
>On Wed, 9 Dec 1998, David Lang wrote:
>
>> I have now seen several people make the comment that SCSI does not allow
>> more then 2 machines to connect to it. where is this limit? As I
>> understand SCSI there is nothing that would prevent you from using wide
>> scsi to hook up 15 computers to one drive and, assuming they were all
>> accessing different partitions, they should even be able to access the
>> drive simultaniously.
>>
>> David Lang
>
>I think I have several times said that SCSI makes it unattractive to put
>more than about two hosts on a string. It's true that you could have 15
>hosts and one drive, but you still face the line-length limitations and
>bandwidth contention problems that SCSI has. In practice this has meant
>that people tend not to put many initiators on SCSI strings. With
>Digital's CI, it was not unheard-of to have a dozen hosts on the same
>interconnect with tens of storage devices.
>
>Michael
>
>
>
>

sct at redhat

Dec 10, 1998, 12:36 PM

Post #8 of 18 (1803 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

Hi,

On Tue, 08 Dec 1998 23:11:20 -0700, alanr [at] bell-labs said:

> Some forms of disk sharing allow two or more systems to read and write
> the a filesystem simultaneously.

> The possibilities for a bad implementation resulting in hung
> filesystems or scrambled data in such a configuration are awesome and
> mind-boggling. Of course, that's why it's interesting :-)

Well, you sure got _that_ right. <grin>

--Stephen

sct at redhat

Dec 10, 1998, 12:37 PM

Post #9 of 18 (1798 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

Hi,

On Wed, 9 Dec 1998 05:17:15 -0800 (PST), David Lang
<dlang [at] diginsite> said:

> I have now seen several people make the comment that SCSI does not
> allow more then 2 machines to connect to it. where is this limit?

There is no limit, but because each controller uses a different SCSI ID
and different IDs have different priorities, things get very unfair if
you have too many *simultaneous* controllers on the bus. Having one
active controller and several standby is just fine, and having several
active controllers just has performance problems, not functionality
problems.

--Stephen

bvaldivieso at ibm

Dec 10, 1998, 1:50 PM

Post #10 of 18 (1803 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

unsubscribe

bjorken at lucent

Dec 11, 1998, 3:48 AM

Post #11 of 18 (1817 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

David -

The only considerations with regard to multi-initiation are:

1. Does the driver conform to the SPEC?
2. Are there sufficient SCSI IDs to support the architecture?
3. Is there sufficent bandwidth to support the application and operating =
system (i.e. 20MB Fast etc.)?
4. Cable length considerations (25 meters for differential - FWD) and =
through-controller loss.
5. And yes, it's a good idea to maintain unique LUN or disk targets (not =
to be confused with SCSI ID targets in the case of LUNs supported by a =
storage sybsystem.

Wayne Bjorken

PS: You are correct with your eight ID statement. SCSI-I is the =
foundation for the standard extention. For arbitration purposes, ID 7 =
can preempt.

-----Original Message-----
From: alanr [at] bell-labs [SMTP:alanr [at] bell-labs]
Sent: Wednesday, December 09, 1998 9:59 AM
To: David Lang; Linux-HA mailing list
Subject: Re: Fw: Help! Problems with IP address takeover on 2.0.36

David Lang wrote:
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
>=20
> I have now seen several people make the comment that SCSI does not =
allow
> more then 2 machines to connect to it. where is this limit? As I
> understand SCSI there is nothing that would prevent you from using =
wide
> scsi to hook up 15 computers to one drive and, assuming they were all
> accessing different partitions, they should even be able to access the
> drive simultaniously.
>=20
> David Lang
>=20

You're right, at some level. The problem is cable runs, cable length,
etc. are usually problematic in practice. Fast SCSI has relatively
short cable length restrictions (though I can't recall what they are).=20
By the time you make neat cable runs, it's a problem. Also, SCSI is
difficult or impossible to hot-plug, so that if one machine comes down
to be replaced or significantly messed with, it may require the SCSI
activity on all the other machines to be stopped at least momentarily.

The number two probably dates back to 8-address SCSI, but is probably
pretty close to the practical constraint in faster SCSI, because the
cables have to be shorter, and things are more tricky.

-- Alan Robertson
alanr [at] bell-labs

h.milz at seneca

Dec 29, 1998, 1:48 PM

Post #12 of 18 (1799 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

Stephen C. Tweedie <sct [at] redhat> wrote:
> On Tue, 08 Dec 1998 23:11:20 -0700, alanr [at] bell-labs said:
>> The possibilities for a bad implementation resulting in hung
>> filesystems or scrambled data in such a configuration are awesome and
>> mind-boggling. Of course, that's why it's interesting :-)
> Well, you sure got _that_ right. <grin>

Hey we tried that with a shared FS on AIX HAGEO (something like the network
block devices, plus some admin stuff around it). Writing at both sides
gives _interesting_ results, mainly because there's no mechanism to keep
the two machines' FS writeback caches in sync... :-)

--
Good day for overcoming obstacles. Try a steeplechase.

h.milz at seneca

Dec 29, 1998, 1:53 PM

Post #13 of 18 (1818 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

mjc [at] rodagroup wrote:
> If you go to Sun, IBM etc and order up a Unix cluster, instead you'll get
> one that uses a 'shared-nothing' approach. That means that, at any given
> time, a disk is owned by one host that accesses it exclusively. The disk

"Shared nothing" more applies to "nothing is shared between nodes at any
given time". The multiple-node attached SCSI peripheral is no "shared
nothing" in this sense. "Shared nothing" rather applies to DB2 parallel
edition, which attached disk pools to nodes and accesses remote disk
content via the network (mainly on the RS/6000 SP, i.e. over the switch).

> only one host thinks that it is allowed to access the disk. So the disk
> is not "shared", if you like.

It is because it is attached to multiple nodes, and you have to take
precaution that no two nodes access the disks at any given time. As laid
out in the HA-HOWTO, you can simply do that in Linux by loading the
respective device drivers only when a node acquires a resource group.

Maybe we have to agree on a common terminology here, and I am willing to
incorporate that in the HA-HOWTO. Comments welcome.

--
"I can't complain, but sometimes I still do."
-- Joe Walsh

h.milz at seneca

Dec 29, 1998, 1:57 PM

Post #14 of 18 (1814 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

David Lang <dlang [at] diginsite> wrote:

> I have now seen several people make the comment that SCSI does not allow
> more then 2 machines to connect to it. where is this limit? As I

Cable length issue. All commercial HA solutions I know only allow for max 4
SCSI peripherals to be shared. This is with Fast/Wide/Differential. Ultra
SCSI has more constraints, and a 1.5 m cable only allows for 4 (?) SCSI
devices, including the adapters. This is why differential SCSI is badly
needed here.

> understand SCSI there is nothing that would prevent you from using wide
> scsi to hook up 15 computers to one drive and, assuming they were all
> accessing different partitions, they should even be able to access the
> drive simultaniously.

I'd rather go for architectures which are really designed for this e.g.
SSA.

On the other hand these "we support that many nodes in a cluster and that
many simultaneous SCSI attachments" is mostly marketing hype. Properly
designing and administering a cluster with more than, say, 4 nodes is a
pain in the neck. The biggest HACMP cluster in Europe AFAIK is still 5
nodes so don't hold your breath.

--
If only God would give me some clear sign! Like making a large deposit
in my name at a Swiss bank.
-- Woody Allen, "Without Feathers"

h.milz at seneca

Dec 29, 1998, 1:58 PM

Post #15 of 18 (1801 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

Kris Land <kland [at] land-5> wrote:
> channel. The new technology would be Fibre Channel which goes to approx
> 300 meters and 126 devices. Additionally you could use a Fibre Channel
> active switch.

Two of 'em? You don't want the switch to be a SPOF.

--
Of all possible committee reactions to any given agenda item, the
reaction that will occur is the one which will liberate the greatest
amount of hot air.
-- Thomas L. Martin

alan at lxorguk

Dec 29, 1998, 5:52 PM

Post #16 of 18 (1804 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

> Kris Land <kland [at] land-5> wrote:
> > channel. The new technology would be Fibre Channel which goes to approx
> > 300 meters and 126 devices. Additionally you could use a Fibre Channel
> > active switch.
>
> Two of 'em? You don't want the switch to be a SPOF.

Fibrechannel is a loop and yes you can have two of them. The Box Hill
fibrebox sitting here has

o 3 PSU's (runs on two)
o Extra fans
o Two fibrechannels across the 8 drivers with two ports per channel

So you can wire

Host===[two channels]===BOX======BOX=====BOX====[host]

and using fibreoptic I believe the hosts can be 10Km apart. Total bandwidth
100 Mbytes/second.

peo at hds

Dec 30, 1998, 5:25 AM

Post #17 of 18 (1813 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

Fibrechannel is "the network behind the server", and the future, many people
say. Everybody is talking about it and about the 100Mbyte/s and 126 devices per
loop, long distance, however there are some things that we need to be aware of
about Fibrechannel and FCAL:

The currently used protocol, FCAL (fibrechannel arbitrated loop), can only have
one (1) session (transfer) going on at any one time. This means that if you have
two servers sharing one loop with say four disk-devices these two servers
(initiators) will *share* the 100Mbyte bandwidth. Also the true flow of data is
not 100% of the 100Mbyte/s,
depending on protocol overhead and kernel/drivers performance in the Host
operatingsystem. I have
heard about NT servers with FCAL disks doing a sustained flow of as low as
17Mbytes/s, compared to with the same server 14 Mbyte for f/w SCSI,
(teoretically 20MB/s). Would have been nice to know what Linux on that same
hardware would do to performance. Probably faster, right ;-)

Also there are often two loops for redundancy. The most common (read simple) use
of FCAL is to have a point to point connection betwen host and disk (very
similar to a scsi connection, but allows for
longer distances. actually the "talk" between the devices are still SCSI) The
downside with this is that it is *very*
like SCSI in that when the loop is broken (to add another device for instance)
the loop will stop functioning all
together, which potentially means downtime. The good this is the extended
distance between server and disk.

To remedy this comes the introduction of the FCAL HUB. The ports of the hub
allows for insertion
of new devices and removal of others online, without disruption. Still one loop
performancewise.

The third step is to introduce switches that will adress the performance issue
by allowing for several sessions to can take place concurently. These are
currently expencive but probably the way things will be done in the future.
If I am not entierly mistaking these so called Fabrics are also another story
protocol-wise, i.e not the same as
fibre-channel-arbitrated-loop.

Another current fact about fibrechannel is the lack of administering standards
and tools, like network monitors, and security/zooning/management tools for this
new network. Does anybody know af any such projects in the free world?

The second problem that allways comes up is that the lack of support for FCAL on
a bootprom level in for instance a Sun box which makes it very cumbersome to
have the operating system out on FCAL. Not sure if this is the
same with e.g Linux/Intel/Adaptec-PCI-FCAL combination, but I do not think so...
Anyone?

Also there is to my knowledge no FC-bandrobots and tapedrives available. Would
be nice to have those on the
network behind the server to. For hubs, also check out gadzoox at
http://www.gadzoox.com

Now, do not let all of these problems stop you from using and thinking about
FCAL and fibrechannel; its
really the way to go, but please be aware of the things above when planning for
FCAL. Help to encourage Linux
developers do make the fastest FCAL drivers on the planet!

Thanks,
/peo

Alan Cox wrote:

> > Kris Land <kland [at] land-5> wrote:
> > > channel. The new technology would be Fibre Channel which goes to approx
> > > 300 meters and 126 devices. Additionally you could use a Fibre Channel
> > > active switch.
> >
> > Two of 'em? You don't want the switch to be a SPOF.
>
> Fibrechannel is a loop and yes you can have two of them. The Box Hill
> fibrebox sitting here has
>
> o 3 PSU's (runs on two)
> o Extra fans
> o Two fibrechannels across the 8 drivers with two ports per channel
>
> So you can wire
>
> Host===[two channels]===BOX======BOX=====BOX====[host]
>
> and using fibreoptic I believe the hosts can be 10Km apart. Total bandwidth
> 100 Mbytes/second.

alan at lxorguk

Dec 30, 1998, 5:29 AM

Post #18 of 18 (1808 views)
Permalink

Fw: Help! Problems with IP address takeover on 2.0.36 [In reply to]

> The second problem that allways comes up is that the lack of support for FCAL on
> a bootprom level in for instance a Sun box which makes it very cumbersome to
> have the operating system out on FCAL. Not sure if this is the
> same with e.g Linux/Intel/Adaptec-PCI-FCAL combination, but I do not think so...
> Anyone?

With the Qlogic card at least you appear to be able to boot from an FC array.
At least it seems to be in the BIOS settings

Alan

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads