< Previous  | TOC | Index | Next  >

Best practices for setting up replication

• Create one RVG for each application, rather than for each server. For example, if a server is running three separate databases that are being replicated, create three separate RVGs for each database. Creating three separate RVGs helps to avoid write-order dependency between the applications and provides three separate SRLs for maximum performance per application.
• Create one RVG per disk group. Creating one RVG per disk group enables you to efficiently implement application clustering for high availability, where only one RVG needs to be failed over by the cluster package. If the disk group contains more than one RVG, the applications using the other RVGs would have to be stopped to facilitate the failover. You can use the Disk Group Split feature to migrate application volumes to their own disk groups before associating the volumes to the RVG.
• Plan the size and layout of the data volumes based on the requirement of your application. You must configure the Primary and Secondary data volumes with the same name.
• VVR supports VxVM ISP volumes. However, when planning to include these volumes as a part of the RVG make sure that all the volumes in the RVG are of the same type. VVR does not support a combination of ISP and non-ISP volumes in an RVG. If a volume set contains both ISP and non-ISP volumes, it cannot be associated to an RVG.

  You can however have RVGs with different types of volumes across hosts. For example, the Primary RVG may have VxVM ISP volumes whereas the secondary RVG may have VxVM non-ISP volumes.

• Plan the size of the network between the Primary and each Secondary host.
• Lay out the SRL appropriately to support the performance characteristics needed by the application. Because all writes to the data volumes in an RVG are first written to the SRL, the total write performance of an RVG is bound by the total write performance of the SRL. For example, dedicate separate disks to SRLs and if possible dedicate separate controllers to the SRL.
• Size the SRL appropriately to avoid overflow. For information on how to determine the size of the SRL, see the Veritas Volume Replicator Planning and Tuning Guide.

  ---

    Tip   The Veritas Volume Replicator Advisor (VRAdvisor), a tool to collect and analyze samples of data, can help you determine the optimal size of the SRL. For more information, see the Veritas Volume Replicator Advisor User's Guide.

  ---

• Include all the data volumes used by the application in the same RVG. This is mandatory.
• Provide dedicated bandwidth for VVR over a private network. The RLINK replicates data critical to the survival of the business. Compromising the RLINK compromises the business recovery plan.
• Use the same names for the data volumes on the Primary and Secondary nodes. If the data volumes on the Primary and Secondary have different names, see Mapping the name of a Secondary data volume to a differently named Primary data volume.
• Make SRLs of equal size and the same names within the same RDS because the Secondary SRL becomes the Primary SRL when the Primary role is transferred.
• Mirror all data volumes and SRLs. This is optional if you use hardware-based mirroring.
• The vradmin utility creates corresponding RVGs on the Secondary of the same name as the Primary. If you choose to use the vxmake command to create RVGs, use the same names for corresponding RVGs on the Primary and Secondary nodes.
• Associate a DCM to each data volume on the Primary and the Secondary if the DCMs had been removed for some reason. By default, the vradmin createpri and vradmin addsec commands add DCMs if they do not exist.
• If you are setting up replication in a shared environment, before you do so, determine the node that is performing the most writes by running the vxstat command on each node for a suitable period of time, and then after you set up replication, specify that node as the logowner.