VVR Administration
Saturday, January 5, 2008 at 3:34 PM |
Contents


Introduction

This document describes how to configure and administer VVR. VVR is Veritas Volume Replicator - the binaries are automatically installed as part of VxVM (Veritas Volume Manager). To activate VVR an appropriate Veritas License Key needs installing onto all the systems using VVR.

VVR allows the contents of a set of volumes within specified disk groups to be replicated across TCP/IP to one or more remote hosts. One Primary host must exist with at least one Secondary host although more remote hosts can be configured. The data on the secondary host cannot be unless it becomes the Primary host, either by taking over the role (if the Primary host is down) or by migrating the Primary host role to the Secondary host.

VVR can be integrated into VCS with a VVR agent and Global Cluster Manager (GCM - another Veritas product) can then be used to manage the failover of clusters from site to site.


VVR Terminology

Data Change Map (DCM) - An object containing a bitmap that can be optionally associated with a data volume on the Primary RVG. The bits represent regions of data that are different between the Primary and the Secondary. DCMs are used to mark sections of volumes on the primary that have changed during extended network outages in order to minimize the amount of data that must be synchronized to the secondary site during the outage.

Data Volume - Volumes that are associated with an RVG and contain application data.

Primary Node - The node on which the primary RVG resides.

Replication Link (RLINK) - RLINKs represent the communication link to the couterpart of the RVG on another node. At the Primary node a replicated volume object has one RLINK for each of its network mirrors. On the Secondary node a replicated volume has a single RLINK object that links it to its Primary. Each RLINK on a Primary RVG represents the communication link from the Primary RVG to a corresponding Secondary RVG, via an IP connection.

Replicated Data Set (RDS) - The group of the RVG on a Primary and its corresponding Secondary hosts.

Replicated Volume Group (RVG) - A component of VVR that is made up of a set of data volumes, one or more RLINKs and an SRL. An RVG is a subset of volumes within a given VxVM disk group configured for replication to one or more secondary systems. Data is replicated from a primary RVG to a secondary RVG. The primary RVG is in use by an application, while the secondary RVG receives replication and writes to local disk. The concept of primary and secondary is per RVG, not per system. A system can simultaneously be a primary RVG for some RVGs and secondary RVG for others. The RVG also contains the storage replicator log (SRL) and replication link (RLINK).

Storage Replication Log (SRL) - Writes to the Primary RVG are saved in the SRL on the Primary side. The SRL is used to aid in recovery, as well as to buffer writes when the system operates in asynchronous mode. Each write to a data volume in the RVG generates two write requests: one to the Secondary SRL, and another to the Primary SRL.

Secondary Node - The node too which the primary RVG replicates.


Installation

VVR is installed with VxVM, follow instructions for installing VxVM.

Install the VVR licence using vxlicinst and entering the licence key when prompted.


Configuring VVR

Create Disk Groups and Volumes

Primary Node
  • Create a disk group for each RVG.
  • Create all required volumes.
  • Create a volume for the SRL, sized according to the amount of data to be replicated.
  • Optionally create DCMs for each volume.
  • create the filesystems as appropriate.
  • Mount the filesystems - this is not a requirement to configure VVR but will not prevent configuration.

Secondary Node
  • Create a disk group for each RVG, using the same disk group names as the Primary Node.
  • Create all required volumes, using the save volume names as the Primary Node. The volumes must be the same size as on the Primary Node but do not require the same underlying disk structure.
  • Create a volume for the SRL, as per the Primary Node.
  • Optionally create DCMs for each volume.
  • DO NOT create the filesystems, these will be replicated from the Primary Node.

Create the RVG

Secondary Node

Firstly the Secondary Node must be given permission to manage the disk group created on the Primary Node. To do this add the diskgroup ID into /etc/vx/vras/.rdg. The diskgroup ID is the value of dgid in the output of vxprint -l on the Primary Node.

Primary Node

Create the Primary RVG with the vradmin command:

vradmin -g <diskgroup> createpri <rvgname> <vol1,vol2...> <srlname>

Where:
  • <diskgroup> is the VxVM diskgroup name
  • <rvgname> is the name for the RVG, usually diskgroupnamervg
  • <vol1,vol2...> is a comma separated list of all volumes in the diskgroup to be replicated.
  • <srlname> is the name of the SRL volume


If VVR is being configured in conjunction with VCS then the Service Group name should be used as the localhost name rather than the hostname. To set this enter the following:

vradmin -g <diskgroup> set local_host=<primaryhost>

Where:
  • <diskgroup> is the VxVM diskgroup name
  • <primaryhost> is the VCS Service Group name (IP address must be resolvable from this name)


Now the Secondary Nodes are configured from the Primary Node - perform this task for each Secondary Node:

vradmin -g <diskgroup> addsec <rvgname> <primaryhost> <secondaryhost>

Where:
  • <diskgroup> is the VxVM diskgroup name
  • <rvgname> is the name of the RVG created on the Primary Node
  • <primaryhost> is the hostname of the Primary Node, this could be a VCS ServiceGroup name
  • <secondaryhost> is the hostname of the Secondary Node, this could be a VCS ServiceGroup name


Configuring Replication Mode

VVR supports both asynchronous and synchronous replication. To configure the mode of replication set the attribute synchronous to one of the following:

  • off - sets replication mode to asynchronous
  • override - sets the replication mode to soft synchronous. During normal operation replication is synchronous but if the RLINK becomes inactive then replication temporarily becomes asynchronous, storing all transactions in the SRL. When the RLINK becomes available the SRL is drained and repliction switches back to synchronous.
  • fail - sets replication mode to hard synchronous. During normal operation replication is synchronous and if the RLINK becomes inactive VVR failes new updates to the Primary Node.


To set the appropriate mode of replication enter the following:

vradmin -g <diskgroup> set <rvgname> <secondaryhost> synchronous=<value>

Where:
  • <diskgroup> is the VxVM diskgroup name
  • <rvgname> is the name of the RVG
  • <secondaryhost> is the hostname of the Secondary Node
  • <value> is the synchronous attribute value as listed above


Synchronising & Starting Replication

When the RVG has been configured replication can be started. When replication is started for the first time a full synchonisation takes place. The time taken to synchronise will depend on the volume of data. On the Primary Node enter the command:

vradmin -g <diskgroup> -a startrep <rvgname> <secondaryhost>

Where:
  • <diskgroup> is the VxVM diskgroup name
  • <rvgname> is the name of the RVG
  • <secondaryhost> is the hostname of the Secondary Node



Checking the Configuration

There are many ways of looking at how VVR has been configured. The following sections highlight the main commands and options but is not extensive. Refer to the man pages and Veritas documentation for further informtion.

VxVM Records using vxprint

The output of vxprint -Aht will show rv and rl records associated with more traditional v, pl and sd records:
# vxprint -Aht
rv intrarvg     1            ENABLED  ACTIVE   primary  2         intranet-srl
rl rlk_sv1202_intrarvg intrarvg CONNECT ACTIVE sv1202   intra1dg  rlk_sv1201_intrarvg
v  unix-intranet intrarvg    ENABLED  ACTIVE   25165824 SELECT    -        fsgen
pl unix-intranet-01 unix-intranet ENABLED ACTIVE 25176456 STRIPE  3/128    RW
sd loa0101-01   unix-intranet-01 loa0101 0     8392072  0/0       c2t0d0   ENA
sd loa0102-01   unix-intranet-01 loa0102 0     8392072  1/0       c2t1d0   ENA
sd loa0103-01   unix-intranet-01 loa0103 0     8392072  2/0       c2t2d0   ENA
pl unix-intranet-02 unix-intranet ENABLED ACTIVE 25176456 STRIPE  3/128    RW
sd loa0105-01   unix-intranet-02 loa0105 0     8392072  0/0       c3t0d0   ENA
sd loa0106-01   unix-intranet-02 loa0106 0     8392072  1/0       c3t1d0   ENA
sd loa0107-01   unix-intranet-02 loa0107 0     8392072  2/0       c3t2d0   ENA
pl unix-intranet-03 unix-intranet ENABLED ACTIVE LOGONLY CONCAT   -        RW
sd loa0102-03   unix-intranet-03 loa0102 11789424 64    LOG       c2t1d0   ENA
pl unix-intranet-04 unix-intranet ENABLED ACTIVE LOGONLY CONCAT   -        RW
sd loa0106-03   unix-intranet-04 loa0106 11789424 64    LOG       c3t1d0   ENA
v  unix-netlink intrarvg     ENABLED  ACTIVE   10187667 SELECT    -        fsgen
pl unix-netlink-01 unix-netlink ENABLED ACTIVE 10192104 STRIPE    3/128    RW
sd loa0101-02   unix-netlink-01 loa0101 8392072 3397352 0/0       c2t0d0   ENA
sd loa0102-02   unix-netlink-01 loa0102 8392072 3397352 1/0       c2t1d0   ENA
sd loa0103-02   unix-netlink-01 loa0103 8392072 3397352 2/0       c2t2d0   ENA
pl unix-netlink-02 unix-netlink ENABLED ACTIVE 10192104 STRIPE    3/128    RW
sd loa0105-02   unix-netlink-02 loa0105 8392072 3397352 0/0       c3t0d0   ENA
sd loa0106-02   unix-netlink-02 loa0106 8392072 3397352 1/0       c3t1d0   ENA
sd loa0107-02   unix-netlink-02 loa0107 8392072 3397352 2/0       c3t2d0   ENA
pl unix-netlink-03 unix-netlink ENABLED ACTIVE LOGONLY  CONCAT    -        RW
sd loa0101-03   unix-netlink-03 loa0101 11789424 64     LOG       c2t0d0   ENA
pl unix-netlink-04 unix-netlink ENABLED ACTIVE LOGONLY  CONCAT    -        RW
sd loa0105-03   unix-netlink-04 loa0105 11789424 64     LOG       c3t0d0   ENA
v  intranet-srl intrarvg     ENABLED  ACTIVE   2097152  SELECT    -        SRL
pl intranet-srl-01 intranet-srl ENABLED ACTIVE 2101552  CONCAT    -        RW
sd loa0104-01   intranet-srl-01 loa0104 0      2101552  0         c2t3d0   ENA
pl intranet-srl-02 intranet-srl ENABLED ACTIVE 2101552  CONCAT    -        RW
sd loa0108-01   intranet-srl-02 loa0108 0      2101552  0         c3t3d0   ENA

This example shows three striped and mirrored volumes, called unix-intranet, unix-netlink and intranet-srl contained within the RVG called intrarvg with an RLINK called rlk_sv1202_intrarvg

RVG Configuration

The following command will display the configuration for every RVG, or the one specified:

# vxprint -Pl [ <rvgname> ]

Disk group: intra1dg

Rlink:    rlk_sv1202_intrarvg
info:     timeout=500 packet_size=8400 rid=0.1367
          latency_high_mark=10000 latency_low_mark=9950
state:    state=ACTIVE
          synchronous=off latencyprot=off srlprot=autodcm
assoc:    rvg=intrarvg
          remote_host=sv1202 IP_addr=10.38.3.116 port=4145
          remote_dg=intra1dg
          remote_dg_dgid=1065010978.1277.sv1202
          remote_rvg_version=10
          remote_rlink=rlk_sv1201_intrarvg
          remote_rlink_rid=0.1254
          local_host=sv1201 IP_addr=10.96.103.19 port=4145
protocol: UDP/IP
flags:    write enabled attached consistent connected asynchronous


Node Configuration

To display information about the Primary and Secondary Nodes enter the command:

vradmin -g <diskgroup> printrvg <rvgname>

Where:

* <diskgroup> is the VxVM diskgroup name
* <rvgname> is the name of the RVG

# vradmin -g intra1dg printrvg intrarvg

Primary:
        HostName: sv1201       
        RvgName: intrarvg
        DgName: intra1dg
        datavol_cnt: 2
        srl: intranet-srl
        RLinks:
            name=rlk_sv1202_intrarvg, detached=off, synchronous=off
Secondary:
        HostName: sv1202
        RvgName: intrarvg
        DgName: intra1dg
        datavol_cnt: 2
        srl: intranet-srl
        RLinks:
            name=rlk_sv1201_intrarvg, detached=off, synchronous=off


Check Replication Status

Check RVG Replication Status

To check the replication status of an RVG enter the following command: 

vradmin -g <diskgroup> repstatus <rvgname>

Where:

* <diskgroup> is the VxVM diskgroup name
* <rvgname> is the name of the RVG

# vradmin -g intra2dg repstatus intrarvg

Replicated Data Set: intrarvg
Primary:
  Host name:          sv1201
  RVG name:           intrarvg
  DG name:            intra1dg
  RVG state:          enabled for I/O
  Data volumes:       2
  SRL name:           intranet-srl
  SRL size:           1.00 G
  Total secondaries:  1

Secondary:
  Host name:          sv1202
  RVG name:           intrarvg
  DG name:            intra1dg
  Data status:        consistent, up-to-date
  Replication status: replicating (connected)
  Current mode:       asynchronous
  Logging to:         SRL


The key bits of information here are Data status and Replication status.

Check RLINK Replication Status

To check the replication status of an RLINK enter the command:

vxrlink -g <diskgroup> status <rlinkname>

Where:
  • <diskgroup> is the VxVM diskgroup name
  • <rlinkname> is the RLINK name


# vxrlink -g intra1dg status rlk_sv1202_intrarvg

Thu Oct 16 12:13:43 BST 2003
vxvm:vxrlink: INFO: Rlink rlk_sv1202_intrarvg has 37197 outstanding writes, occupying 537631 Kbytes (51%) on the SRL

...

Thu Oct 16 14:23:01 BST 2003
vxvm:vxrlink: INFO: Rlink rlk_sv1202_intrarvg is up to date


Changing The Primary Node

Migrate the Primary Node to a Secondary Node

If the Primary Nodes needs to be swapped to one of the Secondary Nodes and both Nodes are operational then the replication must be migrated. This performs a tidy closedown of replication and starts it up at the other end. The application must be stopped before migration can be performed, this includes unmounting the filesystems.

  • Stop the application.
  • Unmount the filesystems.
  • Check replication is complete, wait for it to complete if it is not.
  • Migrate


This process can be used to test that the Secondary Node is configured correctly to run the application.

To migrate the Primary Node enter the command:

vradmin -g <diskgroup> migrate <rvgname>

Where:
  • <diskgroup>: is the VxVM diskgroup name
  • <rvgname> is the name of the RVG to migrate
  • <destinationnode> is the Node to which the RVG is being migrated


Takeover the Primary Node from a Secondary Node

A takeover of the Primary Node would be used if the Primary Node is not available for any reason, including a disaster.

Firstly replication must be upto date on the Secondary Node, that is the SRL must be empty. On the Secondary Node that is to become the Primary Node enter the command:

vradmin -g <diskgroup>: takeover <rvgname>

Where:
  • <diskgroup>: is the VxVM diskgroup name
  • <rvgname> is the name of the RVG to takeover


Revert to the Original Primary Node

To revert to the Primary Node after a migration, simply migrate back.

To revert to the Primary Node after a takeover refer to the VVR Administration Guide. There are two methods to revert depending on the state of the data replication:

  • Fast Failback - The DCMs are used to keep note of all changes to the data volumes, these are copied to the Primary Node and replayed to apply all the changes to the original data volumes.
  • Difference Based Failback - This method uses checkpointing to apply the changes to the original data volumes based on the differences with the Secondary data volumes.
Posted by JAUGHN Labels:

0 comments:

Post a Comment

Visit the Site
MARVEL and SPIDER-MAN: TM & 2007 Marvel Characters, Inc. Motion Picture © 2007 Columbia Pictures Industries, Inc. All Rights Reserved. 2007 Sony Pictures Digital Inc. All rights reserved. blogger template by blog forum