Here's some advise: if you plan on using Veritas Volume Replicator with Red Hat Enterprise Linux, AVOID USING EXT3FS!
I've seen the combo just hang on sending updates to the remote secondary. It would just sit there when trying to drain the Storage Replicator Log (SRL); vxrlink status would just sit there and show it not being drained .
To remedy, we had to force the SRL to overflow into DCM logging by creating a big enough bogus file (mkfile or dd if=/dev/zero) to use vradmin to resync. Forcing it to clear the DCM would be the only way to make the problem go away and resume replication!
This problem would appear almost randomly and we eliminated the size of the volumes as a factor. One volume was in the terabytes while another was several gigabytes. Both exhibited this problem.
Both ext2fs and vxfs worked fine. To preserve file system journaling, we went with vxfs. We had no reason not to, we just went with ext3fs because there were performance questions in a past project on Solaris regarding vxfs. Being this new project was on RHEL, we found no reason to stop us from converting to vxfs.
So, stick to vxfs with vvr. YMMV, but it worked well for us.
Politics and Technology.
- ► 2009 (17)