T.R | Title | User | Personal Name | Date | Lines |
---|
743.1 | | MOVIES::WIDDOWSON | Rod OpenVMS Engineering. Project Rock | Thu Apr 17 1997 06:52 | 8 |
| I'm not sure whether this answers the question, but there is no
filesystem support for shared storage in NT. Images will need to be on
a filesystem. Oracle's OPS can place it's data on a raw partition.
Furthermore, NTFS cannot manage a readonly device, so you cannot have
the same disk mounted to two nodes even in read only mode...
Or was that not the question ?
|
743.2 | | MPOS01::naiad.mpo.dec.com::mpos01::cerling | I'[email protected] | Thu Apr 17 1997 11:09 | 11 |
|
No, that was not the question. The shared storage I was referring to
is the RAID Array xxx that is on the common SCSI between the two
systems. The information is stored in the NTFS, just like any of the
other types of things you would fail over between the two systems.
What I am getting at is a single copy of the binaries installed on
the common storage subsystem (is that better?) instead of having all
the space required for an Oracle install on two local disks.
tgc
|
743.3 | out of my depth | MOVIES::WIDDOWSON | Rod OpenVMS Engineering. Project Rock | Thu Apr 17 1997 11:19 | 1 |
| Is there a perf impact of not having the data locally ?
|
743.4 | failing app bins on shared/switched storage | MPOS01::naiad.mpo.dec.com::mpos01::cerling | I'[email protected] | Thu Apr 17 1997 11:27 | 12 |
|
Though performance is not the issue with the customer, I would guess
that it might even be a performance benefit to have some of that
information out on an HSZ-based controller instead of one that is
shared with the system drive.
The real question here, regardless of whether or not it is Oracle,
is "Is it possible to place application binaries on the switched
storage when that application is the application that is failing
over?".
tgc
|
743.5 | | LJSRV1::GOODMAN | | Thu Apr 17 1997 11:40 | 1 |
| This configuration is not supported for Digital Clusters or Wolfpack.
|
743.6 | An idle thought... | SNOFS1::HUMMERSTON | I COULD MURDER A CURRY | Thu Apr 17 1997 20:35 | 5 |
| Is the customer trying to get away with only 1 Oracle license for the
cluster? Since the application can only run on the system where the
disks are mounted, they only need 1 very expensive license and not 2.
Paul
|
743.7 | more clarification | MPOS01::naiad.mpo.dec.com::mpos01::cerling | I'[email protected] | Fri Apr 18 1997 10:27 | 23 |
| re: .5
As I stated in my base note, I expected it to not be supported. That
doesn't answer the question of whether or not it will work. I can't
think of any reason why it wouldn't, and I am curious. Of course,
that then begs the question of why shouldn't it be supported. Since,
in a failover environment, the first thing that has to happen is the
disk is made available, it stands to logic that the files needed to
be executed would now be available. How is that any different from
having the executables on a system disk?
re: .6
The customer is only trying to get away from having to eat up so
much disk space that is required for each install and to speed the
installation process. As I stated in the base note, this is a
procedure that he is doing for installs of Oracle right now. Rather
than go through a full install, he copies the files and updates the
registry. It just made sense to him that he could copy the files
to the shared storage and update the registry, making life for him
a little easier, and the storage requirements a little less. He is
not trying to bypass any licensing requirements.
tgc
|
743.8 | What about the registry? | DECWET::CAPPELLOF | My other brain is a polymer | Wed Apr 23 1997 14:18 | 13 |
| Putting your binaries on shared storage, and only running them on the
system where the disks are online SHOULD work. I have seen problems
with putting failover scripts on shared storage, but I don't understand
the cause. (Seems to be a problem of the script file still being open
when the shared storage is put offline during a manual failover.)
However, a big part of installation of modern programs on NT is setting
up entries in the registry, which is not shared between machines.
Putting your binaries on shared storage doesn't do anything to help
this problem.
Wolfpack will have a registry replication API that should address part
of this problem.
|