QUESTION ON "DUPLICATE" HDISK DEFINED ON THE
ITEM: RTA000024657
QUESTION:
I have a customer who is sharing three 9333-010 disk drawers between
two RS/6000's. There is one aspect of this that we do not understand.
The 9333's are all in the rack of CPU A. When we power up CPU A all
of the serial link drives (12 of them) show up as being available.
The drives show up as being available on CPU B. When we take one
of the hdisks and create a volume group on CPU B, the disk appears
as defined on CPU A--and at the same time an additional hdisk
appear on CPU A. The "new" hdisk that appears on CPU a has the same
serial link address and device id as the one on which a volume group
was created on CPU B. The new disk also shows as defined on CPU A.
We now have two hdisks with the same serial link address.
Why are there two hdisks with the same characteristics on CPU A?
If we wished to
export the volume group on CPU B and import it on CPU A which of the
two hdisks that appear to have the same characteristics should we
choose?
---------- ---------- ---------- --------- ---------- ----------
A: The reason for the problem you're describing is something that we
often refer to as 'ghosting'. This is caused when the configuration
manager reads a bus (SCSI or SERDASD) 'sees' disk drives there that it
can identify by address, but is unable to address them because of a
SCSI RESERVE on the device. The SCSI RESERVE is a function of the
varyon process, and remains active even if the reserving machine is
powered off. The RESERVE/RELEASE architecture is valid for both SCSI
and SERDASD. Because the configuration manager can't get to the device,
it creates another one with the correct address, making it available,
and marks the actual instance of the drive as defined. This is
something that happens with twin-tailing because of the nature of the
beast. There are two things you need to think about to stop this from
happening.
First of all, when you are doing twin-tailing with either SCSI or
SERDASD disks, you need to define the volume group, logical volumes, and
file systems on your first system without doing anything on the second
system. When you are sure that you have them properly configured, vary-
off the volume group, and go to the second machine. Here, perform an
importvg command. This will take care of reading the VGDAs and updating
your ODM and /etc/filesystems files with a description of all of the
physical volumes, logical volumes, and filesystems. If you want the
shared data to be used on the first system, varyoffvg the VG on the sec-
ond system and varyonvg the same VG on the first machine. You may leave
the VG imported to each of the machines. This way, if you ever want to
make a change to the content of the volume group, export it from the
second system, make the changes on the first system, and import it again
on the second system -- the changes will all be recorded. To switch
between which machines have the drives, the process need only be a
varyoffvg on one machine and a varyonvg on the other.
The next problem is a little more difficult. If the first machine has
gone down, the only way that you will be able to varyon the volume group
on the second machine without getting ghosts is to send a RESET across
the bus. Like RESERVE/RELEASE mentioned above, this is nearly identical
in terms of operation to SCSI. The function differs, however. In SCSI
it is called SCIORESET; in SERDASD it's called SD_RESET. Once the
reservation is broken, the volume group may be varied on without creating
a 'ghost'.
The easiest way to do what you want to do would be to sell your customer
HACMP/6000. With this product, all of these processes are automatic.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
We are successfully sharing volume groups between two systems by
using varyonvg and varyoffvg. If we need to make changes to a volume
group we were instructed over the telephone to
1)varyoffvg on system A
2)exportvg on system A
3)varyonvg system B
4)make changes on system B
I believe this is a simple question, but we would like your insight
on this issue. Is there a problem with
1)varyoffvg on system A
2)varyonvg system B (just to make sure we could varyon the volume group)
3)exportvg on system A
4)make changes on system B
The objective is simply to avoid exporting a volume group from one
system before we make certain that there is no problem with the
varyon on the second system and avoid any circumstances in which
we might have a "lost" volume group.
---------- ---------- ---------- --------- ---------- ----------
A: You're right, you can export the volume group from system A at a
later step if you wish. It really doesn't matter when you export it,
as long as it is done before it is imported again. If it places you more
at ease about the method suggested to you, all an importvg does is to
read non-volatile data in the VGDA (volume group descriptor area) of the
disk drive(s) and record it in the ODM. If you varyonvg, this data is
read from the ODM instead of the VGDA(s). When you exportvg, the ODM
entries are removed, but can easily be re-read from the VGDA(s) until
the drives are made part of another VG or the VGDA is altered in some
other transaction.
Now, this is the procedure I would recommend instead:
1. With the shared volume group imported on both System A and
System B, and varied-on at System A, make all the logical
volume and file system changes required on System A.
2. Varyoffvg the shared volume group on System A. Run importvg
on System B (an export first is not required). The changes
will be recorded. You may now varyonvg which ever side you
want.
There is an alternate method that HACMP/6000 uses by default. That is to
varyonvg the shared volume group on System B with a -m2 flag. This tells
the system to re-read the VGDA(s) and record any changes in the ODM re-
quired.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q593024 BMCZH
Additional search words:
AHCMP BMCZH DASD DEFINED DISC DISKETTE DUP DUPLICATE GHOSTS HA HACMP
HARDWARE HA6000 HDISK IX QUESTION RISCOHW RISCSYSTEM SEP92 SERIAL
SERIALIZE SERIES SHARE SYS SYSTEM TAKEOVER 6000 9333
WWQA: ITEM: RTA000024657 ITEM: RTA000024657
Dated: 03/1996 Category: RISCHA
This HTML file was generated 99/06/24~12:43:09
Comments or suggestions?
Contact us