Been doing some google research and reading papers on Big Admin about
boot disk mirroring.  I've got a few nagging questions that around
vxvm and encapsulated boot disks.

The Sun approach to VXVM basically entails:

	- mirror the way veritas says
	- break the mirror
	- re-init the encapsulated boot disk
	- re-mirror it
	- run 'vxmkdspart' to make the partitions available 
   	- consider a contigency disk because VXVM isn't on the Solaris Media
       
I don't see how this really helps with serviceability.  Perhaps I'm
missing something.  You can lose a disk, drop in a new one (even the
encapsulated one) and run vxrootmirror and you're back in business
with redundant boot disks.    

I certainly see how it makes the configuration more consistent but not
much else beyond that.  

What am I missing when I read the doc?

Also, am I to udnerstand that if I don't run 'vxmksdpart' that I wouldn't
be able to do the following:

	
1)  boot of CD
2)  mount /dev/dsk/cot0d0s0 /a
3)  cd /a & edit /etc/system etc...to disable veritas??

Thanks,

Joe

joe@unix1.sncc.com wrote:
> Been doing some google research and reading papers on Big Admin about
> boot disk mirroring.  I've got a few nagging questions that around
> vxvm and encapsulated boot disks.
> 
> The Sun approach to VXVM basically entails:
> 
>        - mirror the way veritas says
>        - break the mirror
>        - re-init the encapsulated boot disk
>        - re-mirror it
>        - run 'vxmkdspart' to make the partitions available 
>        - consider a contigency disk because VXVM isn't on the Solaris Media
>       
> I don't see how this really helps with serviceability.  Perhaps I'm
> missing something.  You can lose a disk, drop in a new one (even the
> encapsulated one) and run vxrootmirror and you're back in business
> with redundant boot disks.    
> 
> I certainly see how it makes the configuration more consistent but not
> much else beyond that.  
> 
> What am I missing when I read the doc?
> 

joe@unix1.sncc.com wrote:
> Also, am I to udnerstand that if I don't run 'vxmksdpart' that I wouldn't
> be able to do the following:

> 	
> 1)  boot of CD
> 2)  mount /dev/dsk/cot0d0s0 /a
> 3)  cd /a & edit /etc/system etc...to disable veritas??

My understanding is that everything you suggest is correct... most of
the time.

I believe the big problem was with partitioned oses.  (separate /usr).
In such a case it was possible for the VxVM mirror process to not create
the visible slice for the usr volume.

Now, if you introduce a problem which affects VxVM running (librares,
etc) then you can't mount /usr without VxVM support, so disabling VxVM
doesn't help.

I understand that failure mechanism, but I have never seen it happen
personally, and I don't think there are any similar mechanisms in a
unified filesystem (no separate /usr).  The vxencap and vxmir scripts
will always create slice visibility for the rootvol.

I can understand also the administrative desire to make the two disks
"identical".  That doesn't appear to be necessary for recoverability or
operability (again in the single filesystem setup), but it does

*) make the disks look identical in VTOC and vxprint views
*) separate the private region from the public region
*) eliminate the misunderstood VTOC protection subdisk

so I don't mind going through the proces...

-- 
Darren Dunham                                           ddunham@taos.com
Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

joe@unix1.sncc.com wrote in message news:<hrSdnfp9L8x8rgaiU-KYvg@giganews.com>...
> Been doing some google research and reading papers on Big Admin about
> boot disk mirroring.  I've got a few nagging questions that around
> vxvm and encapsulated boot disks.
> 
> The Sun approach to VXVM basically entails:
> 
> 	- mirror the way veritas says
> 	- break the mirror
> 	- re-init the encapsulated boot disk
> 	- re-mirror it
> 	- run 'vxmkdspart' to make the partitions available 
>    	- consider a contigency disk because VXVM isn't on the Solaris Media
>        
> I don't see how this really helps with serviceability.  Perhaps I'm
> missing something.  You can lose a disk, drop in a new one (even the
> encapsulated one) and run vxrootmirror and you're back in business
> with redundant boot disks.    
> 
> I certainly see how it makes the configuration more consistent but not
> much else beyond that.  
> 
> What am I missing when I read the doc?

A while ago, I wrote an article discussing the unacceptability of 
"standard" rootdg disk recovery approach in a real production environment,
and suggesting an alternative. This happened right after an extremely 
stressful recovery excersise where I suddenly realised that "var" volume
on a failed boot disk is in fact composed of 2 non-adjacent disk areas.

Custom boot disk with VxVM package installed in root image, 
or Jumpstart with such package, is a great help in such scenarios.
http://www.mysunrise.ch/users/aryzhov/NetBootVX.html

Darren Dunham <ddunham@redwood.taos.com> wrote:

> I believe the big problem was with partitioned oses.  (separate /usr).
> In such a case it was possible for the VxVM mirror process to not create
> the visible slice for the usr volume.

Ahh...I see, that makes a lot of sense.  I took out /usr /var and just
about everything except for / & swap for most of our systems where
I can get away with it.

> I understand that failure mechanism, but I have never seen it happen
> personally, and I don't think there are any similar mechanisms in a
> unified filesystem (no separate /usr).  The vxencap and vxmir scripts
> will always create slice visibility for the rootvol.

Well, since I posted this message a sysadmin I work with actually told
me it happened to him twice.  System was badly damaged and he was
unable to mount /usr when he booted off the CD but was able to mount
/.  Veritas said there was a way around it but he didn't get too
far into it, opting instead to rebuild the sysem without /usr.

 

You didn't miss much in the doc.  Unless you are re-sizing var
or other root partitions, or in case you need access to a /usr
partition (do you even have a /usr partition??) you ain't gonna
gain much in resiliency by following those steps.

I only use / & swap (occalsionally systems need a /home) but I
still follow the steps outlined in that whitepaper to make my
disk configuration clean and consistent.  Also, a contigency
disk in addition to your mirrored drives in very mission critical
systems I believe is very helpful to have.

Personally, I plan on moving my boot disks to the SAN.  Each
system will have dual-hba's into the SAN fabric and the 
mirroring will occur on the Hitachi.  The contigency disk
will be there too and the servers will run with no internal
disks.

I know, what if the SAN goes down?  Well, if the SAN goes down
everything is f'd anyways in our architecture (that's like saying
what if the network goes off?).

I plan on testing this configuration soon enough to see how easy
it is to manage.  So far I've had a Brocade SAN in operation for
8 months with zero downtime on it.

Making everything off the SAN will also hopefully help me to
automate some provisioning (just snapshot the boot disk configuration
onto two new drives and update the luns on the new system, change
host names etc... and I should have a new system provisioned).

Has anyone encountered problems with this approach?


joe@unix1.sncc.com wrote:
> Been doing some google research and reading papers on Big Admin about
> boot disk mirroring.  I've got a few nagging questions that around
> vxvm and encapsulated boot disks.
> 
> The Sun approach to VXVM basically entails:
> 
>        - mirror the way veritas says
>        - break the mirror
>        - re-init the encapsulated boot disk
>        - re-mirror it
>        - run 'vxmkdspart' to make the partitions available 
>        - consider a contigency disk because VXVM isn't on the Solaris Media
>       
> I don't see how this really helps with serviceability.  Perhaps I'm
> missing something.  You can lose a disk, drop in a new one (even the
> encapsulated one) and run vxrootmirror and you're back in business
> with redundant boot disks.    
> 
> I certainly see how it makes the configuration more consistent but not
> much else beyond that.  
> 
> What am I missing when I read the doc?
> 

dfdashk@unix.com wrote:
> I know, what if the SAN goes down?  Well, if the SAN goes down
> everything is f'd anyways in our architecture (that's like saying
> what if the network goes off?).

I don't worry about that.  If the SAN is down, you probably have enough
problems that booting that machine can wait.  Or you say, the data's not
accessible, so who cares if the machine is up.

My fear would be having problems with the fiber drivers on the HBAs and
being unable to boot even though the SAN is up.  I'm sure I could do it
in testing, but I've never been able to trust it in production yet.
Tricky fiber drivers have caused me grief enough even when not booting
from them, but fortunately that hasn't happened in quite some time now.

Which HBA/driver will you be using?

-- 
Darren Dunham                                           ddunham@taos.com
Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Darren Dunham <ddunham@redwood.taos.com> wrote:

> My fear would be having problems with the fiber drivers on the HBAs and
> being unable to boot even though the SAN is up.  I'm sure I could do it
> in testing, but I've never been able to trust it in production yet.
> Tricky fiber drivers have caused me grief enough even when not booting
> from them, but fortunately that hasn't happened in quite some time now.
> Which HBA/driver will you be using?

I've used Emulex for access to EMC/Hitachi disks over Brocade with zero
problems on Solaris 7-9 with VXVM for the DMP.

To test booting off the SAN I'll use Emulex & also play around with JNI
since they appear to have very solid support for Solaris.