LVM Mirroring and Serviceguard

[AndyMueller]

I currently have a 2 node Serviceguard cluster running on Itanium Superdome (11.23). We currently use LVM mirroring but due to some performance concerns on the application side, we'd like to break this mirror. Will I have to do anything special as it pertains to ensuring this mirror remains broken in the event of a failover and the application switching to that node. I presume not, but just wanted to me sure.
Thanks in advance, Andy

[Steven E. Protter · Accepted solution]

Shalom,

No you will have no problem.

I'm not up to date on Superdome, but lower end servers have hardware based raid. This eliminates the drag of update/ux software mirroring on system performance.

I'd have a good backup, your performance problem may not be due to mirroring but other issues that could complicate this process.

SEP

[melvyn burnard]

Serviceguard is unaware of the mirroring, as this is handled by LVM.
The main issue is to make sure that LVM sees the split on both nodes.

[AndyMueller]

Melvyn, can you clarify your second sentance for me.

[melvyn burnard]

I am just saying you should verify that after the split, you test to make sure that package will start ok on the second node.
Rather than wait until a failure occuurs, the package moves, and then you have an issue.

[Michael Steele_2]

Hi Andy:

Yes you will have a problem if you want to reference the new lvols.

Do you want to reference the new lvols?

The reconfiguration involved after you break the mirrors in a MCSG environment will be in the package.cntl files. In order to see these new lvols you'll have to update this package files, rerun cmcheckconf and cmapplyconf, update both nodes and verify everything with cmgetconf and cmcheckconf.

That is if you want to see the new lvols.

If you just want to see the old lvols then there isn't any work involved. They will still be intact and referenced in the package.cntl file.

Review your package.cntl files under /etc/cmcluster/PACKAGE/ to find your mounted filesystems and the logical volumes.

Also read the man page on 'lvsplit' and note the -s option. This is the option needed to name the newly split lvol. They will be created under either the default name or the name you provide.

Note: I liked to know more about why your application people are asking you to split your mirrors? This is raid1 going to no raid and yes no raid is faster than raid 1 but no raid is only used when your data is temporary and you can be afford to loose it.

Are the files updated constantly?

Are they multiplex elsewhere?

Here's a nice oracle discussion on raid levels and reccommendations.

http://www.oracle-base.com/articles/misc/RAID.php

[AndyMueller]

Michael,

we will be using the old lvols' so disk devices will not change (otherwise you are correct, we'd have to change the package control files).

We are not running Oracle, we are running Epic Cache Databases (Healthcare EMR system). The Epic application keeps all writes in the buffer, then every 80 seconds those writes get flushed to disk. We are seeing times twhere these write cycles do not finish within the 80 secs. SAN is 2 XP 12000 Disk arrays ....

[Ivan Krastev]

if you have 2x 12000 SAN disk arrays, what is the exact mirroring - do you have Raid Manager and Metro cluster, do you have mirror for every lvol over 2 SANs?


regards,
ivan

[Michael Steele_2]

Like to see your HBA and auto path set up. Sounds like your sending everything over a primary HBA and the alternate is getting anything. This can be fixed.

Can you attach your vgdisplay -v report?

ioscan -funC td (* or other fc HBA class *)