MirrorDisk/UX and System Disks

[Steve Slade]

Hi,

I have recently been told that if you mirror a system disk and the system disk fails, then the system has to be rebooted for the mirror to come into play. (They were not sure whether the system automatically re-booted, or whether it was a manual step.) I have tried to confirm/negate the statement via documentation & old forum messages, but have found nothing conclusive.

My understanding of the MirrorDisk product was that it provided a copy of whatever you 'Mirrored'. The main advantage of this being that if your original lvol, partiiton, disk died for some reason, then the mirror should kick in and you should see no lose in servive, (providing that it was on another disk).

The reasoning they gave was that it was because the kernal has links to various files on the system disk, and therefore cannot cope when the disk fails.

Is this correct? Personally, I think its wrong - but too afraid to put it to the test. As anybody else experienced anything like this?

Steve

[Alexander M. Ermes]

Hi there.
We run systems with mirrored system disks for several years now. If you mirror the boot disk, pls ( if possiblle ) mirror it to another scsi interface and disk. So if the SCSI inetrface dies, you still can boot from the alternate path. That saved our lives a few times in the last years. We could then replace the faulty disks, sync it to the copy and could go on with no loss of production.
One thing : the /tmp mountpoint should not be linked to some place else than / directory.
Rgds
Alexnder M. Ermes

[Shahul]

Hi

I have not faced this problem till now. So I can't give U a solid answer for this. But I think U will have to reboot the system through the mirrored disk.

For non-root HDDs reboot not rqd. But it will give error that so on so HDD is not responding.

Best of luck

Shahul

[Pedro Sousa · Accepted solution]

Hi Steve,
I think the system will not reboot if the boot disk fails, although, I cannot test it right now.
So, I've been looking for some doc, and I found this:
http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90672/B2355-90672_top.html&con=/hpux/onlinedocs/B2355-90672/00/00/74-con.html&toc=/hpux/onlinedocs/B2355-90672/00/00/74-toc.html&searchterms=mirroring%20the%20root&queryid=20010709-014904
"Once you have created mirror copies of the root logical volume and the primary swap logical volume, should either of the disks fail, the system can use the copy of root or of primary swap on the other disk and continue. When the failed disk comes back online, it will be automatically recovered, provided the system has not been rebooted.

If the system is rebooted before the disk is back online, you will need to reactivate the disk and update the LVM data structures that track the disks within the volume group. You can use vgchange -a y even though the volume group is already active."

hope this helps.

[vtpaulson]

Hi Steve,

If your mirror PE's are properly distributed in 2 disks then there is absolutely no problem. Even if one disk fails system will use the mirror PE's and work absolutely normal. Use 2 different controllers that will save you even if one controller fails!...


Regards,

Paulson

[Thierry Poels_1]

Hi,
if *everything* on that failing system disk is mirrored to another disk or more disk, the server will keep on running without any problem. Maybe you don't even notice that a disk has failed!! (check regularly on staled lvol's)
Only rebooting will give you some trouble because the primary boot path will fail.
regards,
Thierry.

[Victor BERRIDGE]

Hi Steve,
I went through changing a system disk in beinning june on a D220 with hot swap disks (a must for me..), The only reason I see for a reboot is to boot fron the new disk you just changed, to test it is bootable, that means you can plan the downtime, if you configured properly mirror-ux on you system disks and these are hot swap you can change the faulty disk with the system running in production (well I had no choice...), but I agree with Alexander on having separate scsi interface, I would suggest a variant since my last issue, if you have external disks for you soft/data DONT use the same interface as the system disk if possible, I explain: before realizing it was a disk going wrong, till we changed it and seen it resolved the problem, we were not sure what was going on, I had in april 4 system crash with system panic the message were memory fault, then we had scsi i/o errors but these we always seem to have because the external RAID5 subsystem was much faster than what the OS normally deals with and we had network errors I coulnd explain... I remembered in May that I moved the swap on the subsystems because of its performance, the system stopped crashing but people were complainig about network problems beeing regulary disconnected etc... I had some time to spare and decided to investigate and discussing with HP it could have been memory more likely the scsi interface and last a system disk. The subsystem loggs its activity: more than 3000 scsi resets in 3 months! But no errors.
So we decided with HP to change the disk and have with us a spare scsi in case and see...
What was going on? a system disk went wrong switching itself on/off/on... thus the resets.. and affected all the disks on the same controller...


All the best

Victor

[Steve Slade]

Thanks to everyone for your quick replies. It all seems much clearer to me now.

We had a production system crash, (I manage dev envs), and were told that it was due to the system failing, and the 'features' of MirrorDisk/UX.

However, it also turned out that they had not mirrored the boot partition. So when they manually reset the box, they could not reboot - and so began a long comedy of errors.

I think now that the problem was due to them not mirroring the boot partition, (I cannot remember what that exactly contains), but I guess some of it must stay resident in memory at run time, and when it went, the box had a problem.

Thanks

Steve

[Tim D Fulford]

Hi

This is what I do to make sure our m/c can boot

say vg00 is wholly contaned on /dev/dsk/c1t6d0
you want to mirror onto /dev/dsk/c2t6d0
# pvcreate -B /dev/dsk/c2t6d0
# lvextend vg00 /dev/dsk/c2t6d0
# lvextend -m 1 /dev/vg00/lvol1 /dev/dsk/c2t6d0
# < do same for all other LV's >
** Make surre you mirror lvol1, lvol2, lvol3 in that order else you'll still not be able to boot. The other lvols do not need to be in a particular order.

put the lif area onto the mirror
# mkboot -l /dev/dsk/c2t6d0
<-l is for LVM layout>

change the auto file
# mkboot -a "hpux -lq" /dev/dsk/c1t6d0
# mkboot -a "hpux -lq" /dev/dsk/c2t6d0

I usually add diags to both disks, if they are installed
# cd /usr/sbin/diag/lif
# mkboot -b ./updatediaglif -p ISL -p AUTO -p HPUX -p LABEL -p PAD /dev/dsk/c1t6d0
- repeat above for /dev/dsk/c2t6d0
Check out LIF area
# lifls /dev/dsk/c1t6d0
ISL AUTO HPUX .....etc....
# lifcp /dev/dsk/c1t6d0:AUTO -
hpux -lq
Repeat on mirror disk

Now set primary & altnerte boot paths
# ioscan -funCdisk
Note HW path to primary & alt boot paths
# setboot -p
# setboot -a
# setboot -b on
Check this
# setboot

HP do have some caveats on what you can boot from (i.e SCSI disks, no fiber...), but I have found the above works in general

From the above you can see it is not juat a case of mirroring up the disks. You need quite alot of other things aswell [prepare the mirror disk, set up the LIF area, make sure the boot sequence is correct...]

I think the above steps will help you check out any other hp server you have.

One other thing, DO A TEST BOOT from the mirrored disk. This will require an outage, but then you will know if it truly works.

Tim