When we set up a mirrored volume, a fundamental principle is to mirror our data to a different physical disk. This may seem obvious to most of us, but I thought I had better make sure we're all on the same wavelength . What isn't obvious to some people is that the second disk should: -
Be of the same speed and performance -
Use the same interface technology -
Use a different interface card/data path We are trying to ensure that when a write occurs to one half of the mirror, a parallel write occurs to the other half of the mirror and both writes occur as synchronized as we can possibly make them. We can set up a VxVM mirror configuration such that we have up to 32 copies of the data running simultaneously . There aren't many configurations I know of that require that level of sophistication, but there are a few. A mirror involves an additional plex associated with the volume. Here's a simple example of setting up a 5GB, two-way mirror using vxassist : root@hpeos003[] vxassist -g ora1 make chkpt1 5G layout=mirror nmirror=2 root@hpeos003[] vxprint -g ora1 -rtvps chkpt1 RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE DC NAME PARENTVOL LOGVOL SP NAME SNAPVOL DCO dm ora_disk1 c0t4d0 simple 1024 71682048 - dm ora_disk4 c4t13d0 simple 1024 71682048 - v chkpt1 - ENABLED ACTIVE 5242880 SELECT - fsgen pl chkpt1-01 chkpt1 ENABLED ACTIVE 5242880 CONCAT - RW sd ora_disk4-01 chkpt1-01 ora_disk4 0 5242880 0 c4t13d0 ENA pl chkpt1-02 chkpt1 ENABLED ACTIVE 5242880 CONCAT - RW sd ora_disk1-02 chkpt1-02 ora_disk1 3495264 5242880 0 c0t4d0 ENA root@hpeos003[] This takes some considerable time to complete even though there is no data in the volume. VxVM will ensure that it adheres to C2 level security pertaining to object-reuse ; if we create a volume, we need to ensure that there is no way that previously stored data is accessible. The only way to ensure this is to overwrite the new volume before enabling the volume for access. This is effectively the vxvol init zero <volume> command. As we can see from the vxprint output, VxVM has created two plexes on separate disks within the disk group . VxVM has chosen a disk on a separate controller. This is a good choice. We can control the creation of mirrors using options to vxassist that will control not only which disk is or isn't used but also which controller is or isn't used. When we are being precise about where our volumes and their associated mirrors exist, we would normally use either a sequence of commands in order to build up our volume or use ordered allocation (use the vxassist option “o ordered and then list all disks involved in the order you want them used). Here, I am creating a volume on a specific disk and then adding mirroring to the volume, as well as specifying which controller not to be used to host the mirror. root@hpeos003[] vxedit -rf rm chkpt2 root@hpeos003[] vxassist -g ora1 make chkpt2 100M dm:ora_disk4 root@hpeos003[] root@hpeos003[] vxassist -g ora1 mirror chkpt2 !ctrl:c4 root@hpeos003[] vxprint -g ora1 -rtvps chkpt2 RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE DC NAME PARENTVOL LOGVOL SP NAME SNAPVOL DCO dm ora_disk2 c0t5d0 simple 1024 71682048 - dm ora_disk4 c4t13d0 simple 1024 71682048 - v chkpt2 - ENABLED ACTIVE 102400 SELECT - fsgen pl chkpt2-01 chkpt2 ENABLED ACTIVE 102400 CONCAT - RW sd ora_disk4-02 chkpt2-01 ora_disk4 5242880 102400 0 c4t13d0 ENA pl chkpt2-02 chkpt2 ENABLED ACTIVE 102400 CONCAT - RW sd ora_disk2-02 chkpt2-02 ora_disk2 3495264 102400 0 c0t5d0 ENA root@hpeos003[] I could have specified the target for the mirror being a specific disk. In this instance, I don't really care which disk it is, as long as it's not on the same controller as the original plex. This configuration uses a layout policy known as mirror-concat . One other thing to notice from the above output is the volume line I have underlined . The third-from-the right column specifies the read policy adopted by VxVM. The read policy for a volume determines the order in which volume plexes are accessed during I/O operations. You can specify which plex VxVM should use to satisfy read requests by setting the read policy. VxVM has three read policies: -
Round robin : If you specify a round robin read policy, VxVM reads each plex in turn in " round-robin " manner for each non-sequential I/O detected . Sequential access causes only one plex to be accessed in order to take advantage of drive or controller read-ahead caching policies. If a read is within 256K of the previous read, then the read is sent to the same plex. -
Preferred plex : With the preferred plex read policy, Volume Manager reads first from a plex that has been named as the preferred plex. Read requests are satisfied from one specific plex, presumably the plex with the highest performance. If the preferred plex fails, another plex is accessed. -
Selected plex : This is the default read policy. Under the selected plex policy, Volume Manager chooses an appropriate read policy based on the plex configuration to achieve the greatest I/O throughput. If the volume has an enabled striped plex, the read policy defaults to that plex; otherwise , it defaults to a round-robin read policy. To change the read policy for a volume, we can use the vxvol command: root@hpeos003[] vxvol -g ora1 rdpol round chkpt2 root@hpeos003[] |