druddle

If you administer/configure Solaris servers then what do you use for root mirroring ? Do you have Veritas Volume Manager too, if so do you use that for root mirroring ?

As far as i see it there are 3 options in that scenario:

1. Solaris purchased, so root disk is mirrored with SDS (or Solaris Volume Manager in S9).

2. Solaris purchased, VxVM purchased. SDS or SVM used for root mirroring, VxVM used for other volumes.

3. Solaris purchased, VxVM purchased. VxVM used for root mirroring and all other volumes.

Now people have different opinions of usinfg VxVM for mirroring root disks. I personally would use it as i have had no problems with it. I have seen problems where SDS is used for root mirroring and VxVM used for everything else, if there is no volumes in the Veritas rootdg.

Anyone have any opinions ?

Dave

^Qwerty^

Use SDS for root disk (or whatever it's name is this week)
Use Veritas for large volume stuff

If anybody encapsulates root disks with VVM, I chop their ***** off

druddle

Why dont you like to use VxVM for root disks Qwerty ?

Dave

^Qwerty^

1) Personal Choice
2) Ease of recovery/restore

However I always insist on having the root disk mirrored anyway, so all-out restores are full and far between.

Our JS server also mirror's (SDS) the root disks automagically, so using Veritas would just add another layer of complication IMO. Also for basic mirroring, why pay for Vertias?

3) Cost

I think a lot of it comes down to what your happy with. Be interested in other peoples thoughts on this, without getting into a emacs vs vi type slanging match

orbv

VxVM is fine for mirroring root disks if you know the product very well and are not just a GUI monkey. Would highly recommend that anyone who is going to mirror root tries DR a few times before going live. When running VxVM the first failed root disk is easy to recover from but 99% of people dont put partitions back on the drives so when another disk fails or you need to go back to underlying devices to upgrade etc, your in deep poo unless you know what your doing.

I agree with Qwerty in using SVM for root disk and VxVM for data is a good idea if you have a SA that knows both products. Just remember you must have a rootdg otherwise VxVM will not work or just put a couple of disks in it and use them for /var/crash etc. Its possible to make rootdg contain only a simple slice (only a slice and not hole disk) but this will give you problem when you have a failure and Veritas don't support it.

orbv

vi

stevencotton

Haha, gotta go with vi too Can't resist.

^Qwerty^

emacs in vi mode?

DrEvil

For what its worth, my thoughts...

VxVM root mirrors
- take a prtvtoc output of each root disk before performing root encapsulation under VxVM.
- Under new versions of VxVM apparently it is possible to keep the partition info intact under format even after root encapsulation, making prtvtoc info unnecessary... see http://www.sun.com/solutions/bluepri...00/vxvmref.pdf - I have not tried or read this doc in full, but our new contractor swears by(/at) it.

To be honest we use the SDS root mirror approach and VxVM for data areas, using the rootdg slice trick. BUT, a SDS gotcha is when their are only two disks under SDS control or rather with metadbs on them, then you will possibly experience the quorum issue. See this document for more info: http://www.sun.com/solutions/bluepri...17-0407-10.pdf

Sorry can't go into more depth at the moment, a bit busy.

I hope this helps, Alex

^Qwerty^

Not had that problem (if it's what I'm thinking... can't be arsed to read the pdf)

Putting three copies of the DB (-c3) on both disks seems to do the job. If one disk dies, then you normally have to boot into sum. Then remove the metadb on the dead disk.... reboot. Comes up as normal then on the one disk. Then replace with new disk.

Worked everytime for me (touch wood... so far)

BTW: If anyone is using Veritas NBU, I'd suggest you also try a FULL restore, and make sure you happy with how to do it; especially if you've used SDS to mirror the root disk.

DrEvil

Qwerty - that is the problem though, in a two disk config it won't always boot up automatically, this may OK for certain business requirements, but for Financial institutions this scenario is general unacceptable. Hence the work around described in the PDF, which is not a complete fix, but potentially gives you more chance of the system coming up first time - well, in my experience anyway.

Ultimately, it would be better to use three disks as a minimum config for metadbs.

IMHO, Alex