11-30-2015 12:42 PM
We have a Linux master server running 7.6.0.2. It has a separate file system for /usr/openv. Recently, it had a spike in growth and was 99% utilized. File system at that time was 1.0 TB in size. Added 400 GB LUN to the file system to create a 1.4 TB file system and the space issue was alleviated. Unfortunately, the 400GB was on the slowest disks we have in the data center. Now, when we look at large image files that are 2 or 3 months old, the system slows to a crawl while the catalog data that is over 30 days old is uncompressed - iowait time goes to 40 to 50%. Our storage group is going to provide a new 1.4 TB LUN to use instead that has faster disks and a faster communication link, but it will require copying everything from the existing /usr/openv file system to a new file system using the faster disks. Had asked about doing a SAN replication, but the old and new file systems are using the same fabric so the replication option is not available. So, the plan is:
Should this work?
Solved! Go to Solution.
11-30-2015 08:58 PM
Hi,
I'm assuming you already used the volume management software on your server to expand your lun from 1 TB to 1.4 TB. You can use the same volume manage software to mirror your 1.4 TB volume (and file system) to the new 1.4 TB Lun/Disk.
No need to copy anything and it can be done online.
11-30-2015 08:24 PM
11-30-2015 08:58 PM
Hi,
I'm assuming you already used the volume management software on your server to expand your lun from 1 TB to 1.4 TB. You can use the same volume manage software to mirror your 1.4 TB volume (and file system) to the new 1.4 TB Lun/Disk.
No need to copy anything and it can be done online.
12-01-2015 12:23 AM
if you are using VxVM/VxFS is volume manger, yes you can do it online as Riaan suggest.
However, if you are using LVM it would use the steps you have outlined in the opening post.
But before copying everything over, ensure the disk are up to the job. A tool like Bonnie is a good tool candidate
http://sourceforge.net/projects/bonnie/
Example commands using Bonnie
http://www.jamescoyle.net/how-to/913-simple-bonnie-example
12-01-2015 12:53 AM
Nicolai,
Does LVM not handle mirroring well?
Seems straight forward.
Converts linear logical volume "vg00/lvol1" to a two-way mirror, using physical extents /dev/sda:0-15 and /dev/sdb:0-15 for allocation of new extents: lvconvert -m1 vg00/lvol1 /dev/sda:0-15 /dev/sdb:0-15 Converts mirror logical volume "vg00/lvmirror1" to linear, freeing physical extents from /dev/sda: lvconvert -m0 vg00/lvmirror1 /dev/sda
12-01-2015 07:16 AM
Riaan - talked to our Unix admins about your suggestion. They have rethought the way they want to do this and will use a similar plan to what you discussed. Will get our storage team to present the new block device to our VM and will add it to the existing volume group. Then run pvmove to move the data to the new device. When it is finished, run vgreduce to get rid of the old block devices. Any concerns that anyone can think of with this plan?
12-01-2015 10:19 AM
Hi
I don't see any issue with this, IMHO its the easiest and safest way to do it. Copying the files implies down time and you're doing it at file level, not block. With a block level operation NBU is not aware that anything is changing. Its still sees /usr/openv as it did previously.
These tools have been available for years so why not use them.
12-01-2015 11:48 AM
Sounds great. Appreciate the help!
12-07-2015 07:16 AM
Our UNIX admin is not too happy with LVM mirroring.