From:
Craig Collins [EMAIL PROTECTED]
To:
LINUX-390@VM.MARIST.EDU
Date:
23/06/2008 17.36
Subject:
Synchronous remote copy FCP disk and DR
We're wondering if anyone has any experience with disaster recovery of
the
zLinux guests when using FCP disk. For a variety of reasons, we chose
to
use the NPIV FCP disk instead of CKD for our Linux guests, including
boot
...snip
Since the serial number for the remote subsystem is different from the
primary, when we split the pair and try to boot from the remote disk,
the
intial boot process starts but we eventually get 'Waiting for device
/dev/disk/by-id/scsi-x-part4 to appear:'
and
this references the boot LUN on the primary disk. It exits to the shell
at
that point.
...snip
Craig,
I had some sort of similar problem some times ago, even thought it was on
CKD
disk... anyway, I was able to bypass this problem, issuing following
command at
boot time, using CMS console:
#cp vi vmsg 1 dasd=xxx root=/dev/dasdyy
(where xxx is address of boot disk and root= references device)
Hope this helps.
Ciao.
_
Paolo Cacciari
IBM Italia S.p.A.
Business Continuity and Resiliency Services, IBM Global Services - South
Region, EMEA
Via Darwin 85, 20019 Settimo Milanese(MI) ? Italy - MISET001
The goal is to be prepared for a disaster not to continually plan for a
successful test
* [EMAIL PROTECTED]
( + 39 051 41.36799 Mobile: + 39 335 6287584
7 + 39 02 596.23288 Fax BO: + 39 051 406052
Please consider the environment before printing this e-mail notice
From:
Craig Collins [EMAIL PROTECTED]
To:
LINUX-390@VM.MARIST.EDU
Date:
23/06/2008 17.36
Subject:
Synchronous remote copy FCP disk and DR
We're wondering if anyone has any experience with disaster recovery of the
zLinux guests when using FCP disk. For a variety of reasons, we chose to
use the NPIV FCP disk instead of CKD for our Linux guests, including boot
LUNs. The disk is synchronously remote copied between data centers.
As part of our disaster recovery planning, we started to think about being
able to boot off of the mirrored copy of the LUNs. When we built our
guest
to test DR with, we make both the primary LUNs and what will be the remote
copy LUNs active to the guest and define them within Linux. We then made
the remote copy LUNs unavailable to the guest by synchronizing the primary
and remote copy LUNs. We made updates, shutdown the guest, split the
disk,
changed the switch zoning so that the primary disk was unavailable and
only
the disaster recovery disk was detected.
It appears that the fstab entries, zipl.conf, bootmapper, and likely other
configuration items, use the subsystem serial number as part of the
identification for the partitions on the FCP disk in SLES10.
Since the serial number for the remote subsystem is different from the
primary, when we split the pair and try to boot from the remote disk, the
intial boot process starts but we eventually get 'Waiting for device
/dev/disk/by-id/scsi-x-part4 to appear:'
and
this references the boot LUN on the primary disk. It exits to the shell
at
that point.
If anyone else has already gone through this and knows all of the
configuration items we need to update to make this work, we would
appreciate
the information so we don't have to reinvent the wheel. If not, we'll
keep
working through this and share what we figure out with the list if anyone
is
interested.
Craig Collins
State of WI
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI)
Cap. Soc. euro 361.550.000
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società con Azionista Unico
Società soggetta all?attività di direzione e coordinamento di
International Business Machines Corporation
(Salvo che sia diversamente indicato sopra / Unless stated otherwise
above)image/gif
