VxVM lousy syncing rate

[Ralph Grothe]

Hello,

although my observation is drawn from a Solaris box which has root disks under VxVM control
and maybe thus not directly comparable to an HP-UX box with VxVM root disks.

Btw, is anyone of you using the latter at all?
I am very keen to hear about your experience with VxVM rootability under HP-UX because I have only access to this under Solaris.

I need to revise my recovery/backup scripts
as I am not satisfied with the performance
(although this may be a minor issue in that context)

Apart from using VxVM snapshots,
which unfortunately I cannot use because I haven't got enough free blocks from the free disk pool to create a snapshot volume that would hold the entire var volume,
the officially propageted procedure for taking online backups of mirrored volumes (i.e. in VxVM Admin Guide) is the following:

1. disociate the mirror plex from the volume to backup

# vxplex -g rootdg dis rootvol-01

2. make a temporary volume to associate the freed plex

# vxmake -g rootdg -U gen vol backvol plex=rootvol-01

3. start temporary volume

# vxvol -g rootdg start backvol

4. perform fs check
(n.b. Solaris allows only their UFS for root slices/volumes, so you would probably run an fsck -F vxfs here instead)

# fsck -F ufs /dev/vx/rdsk/rootdg/backvol

5. backup
(n.b. usually on Solaris you do an ufsdump to tape, but I don't have attached tape drives on these boxes why I dump to a remote host)

# ufsdump 0f - /dev/vx/rdsk/rootdg/backvol|remsh remhost 'cat >/var/tmp/rdump/dumpedhost_rootvol.20060828'

6. stop temporary backup volume

# vxvol -g rootdg stop backvol

7. also disociate plex from backvol

# vxplex -g rootdg dis rootvol-01

8. re-attach plex to original volume

# vxplex -g rootdg att rootvol rootvol-01

9. remove temporary backvol

# vxedit -g rootdg rm backvol


While this may work fine for the relatively small root volume the time the syncing requires between steps 8-9 (progress could be followed by vxtask) becomes prohibitive for large volumes.
And I am not sure whether the removal of the temporary backvol may take place before the syncing is finished.
I would assume yes because the plex'es content hasn't changed.

For instance the syncing for a 60 GB home volume took longer than 35 hours!!!
I have never experienced such a slow syncing with LVM.
This may of course be partly owed by the single root disk controller whith what the FSC hardware was shipped


# vxprint -dspvg rootdg
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dm rootdisk0 c0t0d0s2 - 143526328 - - - -
dm rootdisk1 c0t1d0s2 - 143526328 - - - -
sd rootdisk0-01 rootvol-02 ENABLED 4197952 0 - - -
sd rootdisk0-02 swapvol-02 ENABLED 4097720 0 - - -
sd rootdisk0-03 var-02 ENABLED 2098976 0 - - -
sd rootdisk0-04 opt-02 ENABLED 4197952 0 - - -
sd rootdisk0-05 home-02 ENABLED 125832432 0 - - -
sd rootdisk1-01 home-01 ENABLED 125832432 0 - - -
sd rootdisk1-02 opt-01 ENABLED 4197952 0 - - -
sd rootdisk1-03 rootvol-01 ENABLED 4197952 0 - - -
sd rootdisk1-04 swapvol-01 ENABLED 4097720 0 - - -
sd rootdisk1-05 var-01 ENABLED 2098976 0 - - -
pl home-01 home ENABLED 125832432 - ACTIVE - -
pl home-02 home ENABLED 125832432 - ACTIVE - -
pl opt-01 opt ENABLED 4197952 - ACTIVE - -
pl opt-02 opt ENABLED 4197952 - ACTIVE - -
pl rootvol-01 rootvol ENABLED 4197952 - ACTIVE - -
pl rootvol-02 rootvol ENABLED 4197952 - ACTIVE - -
pl swapvol-01 swapvol ENABLED 4097720 - ACTIVE - -
pl swapvol-02 swapvol ENABLED 4097720 - ACTIVE - -
pl var-01 var ENABLED 2098976 - ACTIVE - -
pl var-02 var ENABLED 2098976 - ACTIVE - -
v home fsgen ENABLED 125832432 - ACTIVE - -
v opt fsgen ENABLED 4197952 - ACTIVE - -
v rootvol root ENABLED 4197952 - ACTIVE - -
v swapvol swap ENABLED 4097720 - ACTIVE - -
v var fsgen ENABLED 2098976 - ACTIVE - -

[Alzhy]

Ralph,

I've never used VxVM rootability on Solaris (where I use Disksuite/SVM) or HP-UX (where I continue to use LVM). I only use VxVM on my non-OS/boot/root disks.

When we migrate to HP-UX 11.23 though - that will change.

Now to your topic at hand.

If you are experiencing synch (or plex attach)times of 30+ hours for a 60GB volume - then I will surmise (1) you've a very busy system (2) your volume is so active (3) your disks are just darn slow...

But the possibly glaring reason why it is that slow is your home volume being on the same disk as your OS...

If you've the extra budget and you want faster synch times -- you may want to invest on an add-on feature called FLashsnap (ersthwhile called FMR or Fast Mirror Resync)... What it does is your subsequent mirror resynchs will only synch blocks that have changed... We use this technology on our multi-terabyte Oracle split mirror backups instead of relying on hardware (array based) split mirrors or BCVs which locks us down to the array vendir. With this host based approach, we can kick out any array vendor from our datacenter and replace it with another and still keep our split mirror/FMR backup scheme the same.

[Ralph Grothe]

Hello Nelson,

it looks as if there isn't a license installed for FlashSnap.
The funny thing is, that when I got the
parcels with all the Vx software a doc
a couple of years ago,
that there was also this slim Admin Guide
for FlashSnap (still wrapped in celophane).
I hope I haven't forgotton to obtain a license key for FlashSnap as well those days.

# /sbin/vxlicrep -s|egrep 'Product Name|License Type'
Product Name = VERITAS Foundation Suite
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS Volume Manager
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS File System
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS SANPoint Control
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS Foundation Suite
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS Volume Manager
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS File System
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS SANPoint Control
License Type = PERMANENT_NODE_LOCK
Product Name = VERITAS Cluster Server
License Type = PERMANENT

[Ralph Grothe]

Ah forgot,
Nelson would you mind reporting on your experience with VxVM rootdisks under HP-UX,
once your migration to 11.23 is through?
I would like to find out if HP achieved a better OS integration than SUN.

[Alzhy]

Ralph,

I actually had several environments 11.11 rooted with VxVM a few years ago (2002 to be exact) and I must say VxVM integration within HP-UX is the best that I've seen..

The manuals on 3.5M under 11.11 are testament to how HP had planned VxVM to be its preferred Volume Manager.

The reason I stick with LVM is that there are already well entrenched LVM based OS disk recovery procedures that I did not want to risk overhauling -- specially that I was the only VxVM "expert" in the team...


Will let you know as soon as I'm done with my 11.23 adventures... and VxVM 4.1 which reportedly makes obsolete the requisite "rootdg" diskgroup...