Veritas InfoScale™ 7.4 Solutions Guide - Linux

Last Published:
Product(s): InfoScale & Storage Foundation (7.4)
Platform: Linux
  1. Section I. Introducing Veritas InfoScale
    1. Introducing Veritas InfoScale
      1.  
        About the Veritas InfoScale product suite
      2.  
        Components of the Veritas InfoScale product suite
  2. Section II. Solutions for Veritas InfoScale products
    1. Solutions for Veritas InfoScale products
      1.  
        Use cases for Veritas InfoScale products
      2.  
        Feature support across Veritas InfoScale 7.4 products
      3.  
        Using SmartMove and Thin Provisioning with Sybase databases
      4.  
        Running multiple parallel applications within a single cluster using the application isolation feature
      5.  
        Scaling FSS storage capacity with dedicated storage nodes using application isolation feature
      6.  
        Finding Veritas InfoScale product use cases information
  3. Section III. Stack-level migration to IPv6 or dual stack
    1. Stack-level migration to IPv6 or dual stack
      1.  
        Migrating Veritas InfoScale products to support IPv6/dual-stack
  4. Section IV. Improving database performance
    1. Overview of database accelerators
      1.  
        About Veritas InfoScale product components database accelerators
    2. Improving database performance with Veritas Concurrent I/O
      1. About Concurrent I/O
        1.  
          How Concurrent I/O works
      2. Tasks for enabling and disabling Concurrent I/O
        1.  
          Enabling Concurrent I/O for Sybase
        2.  
          Disabling Concurrent I/O for Sybase
    3. Improving database performance with atomic write I/O
      1.  
        About the atomic write I/O
      2.  
        Requirements for atomic write I/O
      3.  
        Restrictions on atomic write I/O functionality
      4.  
        How the atomic write I/O feature of Storage Foundation helps MySQL databases
      5.  
        VxVM and VxFS exported IOCTLs
      6.  
        Configuring atomic write I/O support for MySQL on VxVM raw volumes
      7.  
        Configuring atomic write I/O support for MySQL on VxFS file systems
      8.  
        Dynamically growing the atomic write capable file system
      9.  
        Disabling atomic write I/O support
  5. Section V. Using point-in-time copies
    1. Understanding point-in-time copy methods
      1. About point-in-time copies
        1.  
          Implementing point-in time copy solutions on a primary host
        2.  
          Implementing off-host point-in-time copy solutions
      2.  
        When to use point-in-time copies
      3. About Storage Foundation point-in-time copy technologies
        1. Volume-level snapshots
          1.  
            Persistent FastResync of volume snapshots
          2.  
            Data integrity in volume snapshots
        2.  
          Storage Checkpoints
    2. Backing up and recovering
      1.  
        Storage Foundation and High Availability Solutions backup and recovery methods
      2. Preserving multiple point-in-time copies
        1.  
          Setting up multiple point-in-time copies
        2.  
          Refreshing point-in-time copies
        3.  
          Recovering from logical corruption
        4.  
          Off-host processing using refreshed snapshot images
      3. Online database backups
        1. Making a backup of an online database on the same host
          1.  
            Preparing a full-sized instant snapshot for a backup
          2.  
            Preparing a space-optimized snapshot for a database backup
          3.  
            Backing up a Sybase database on the same host
          4.  
            Resynchronizing a volume
        2. Making an off-host backup of an online database
          1.  
            Making an off-host backup of an online Sybase database
          2.  
            Resynchronizing a volume
      4. Backing up on an off-host cluster file system
        1.  
          Mounting a file system for shared access
        2.  
          Preparing a snapshot of a mounted file system with shared access
        3.  
          Backing up a snapshot of a mounted file system with shared access
        4.  
          Resynchronizing a volume from its snapshot volume
        5.  
          Reattaching snapshot plexes
      5. Database recovery using Storage Checkpoints
        1.  
          Creating Storage Checkpoints
        2.  
          Rolling back a database
    3. Backing up and recovering in a NetBackup environment
      1.  
        About Veritas NetBackup
      2.  
        About using NetBackup for backup and restore for Sybase
      3. Using NetBackup in an SFHA Solutions product environment
        1.  
          Clustering a NetBackup Master Server
        2.  
          Backing up and recovering a VxVM volume using NetBackup
        3.  
          Recovering a VxVM volume using NetBackup
    4. Off-host processing
      1.  
        Veritas InfoScale Storage Foundation off-host processing methods
      2. Using a replica database for decision support
        1. Creating a replica database on the same host
          1.  
            Preparing for the replica database
          2.  
            Creating a replica database
        2. Creating an off-host replica database
          1.  
            Setting up a replica database for off-host decision support
          2.  
            Resynchronizing the data with the primary host
          3.  
            Updating a warm standby Sybase ASE 12.5 database
          4.  
            Reattaching snapshot plexes
      3.  
        What is off-host processing?
      4.  
        About using VVR for off-host processing
    5. Creating and refreshing test environments
      1.  
        About test environments
      2.  
        Creating a test environment
      3.  
        Refreshing a test environment
    6. Creating point-in-time copies of files
      1. Using FileSnaps to create point-in-time copies of files
        1.  
          Using FileSnaps to provision virtual desktops
        2.  
          Using FileSnaps to optimize write intensive applications for virtual machines
        3.  
          Using FileSnaps to create multiple copies of data instantly
  6. Section VI. Maximizing storage utilization
    1. Optimizing storage tiering with SmartTier
      1.  
        About SmartTier
      2.  
        About VxFS multi-volume file systems
      3.  
        About VxVM volume sets
      4.  
        About volume tags
      5.  
        SmartTier use cases for Sybase
      6.  
        Setting up a filesystem for storage tiering with SmartTier
      7.  
        Relocating old archive logs to tier two storage using SmartTier
      8.  
        Relocating inactive tablespaces or segments to tier two storage
      9.  
        Relocating active indexes to premium storage
      10.  
        Relocating all indexes to premium storage
    2. Optimizing storage with Flexible Storage Sharing
      1. About Flexible Storage Sharing
        1.  
          Limitations of Flexible Storage Sharing
      2.  
        About use cases for optimizing storage with Flexible Storage Sharing
      3.  
        Setting up an SFRAC clustered environment with shared nothing storage
      4.  
        Implementing the SmartTier feature with hybrid storage
      5.  
        Configuring a campus cluster without shared storage
  7. Section VII. Migrating data
    1. Understanding data migration
      1.  
        Types of data migration
    2. Offline migration from LVM to VxVM
      1.  
        About migration from LVM
      2.  
        Converting unused LVM physical volumes to VxVM disks
      3. LVM volume group to VxVM disk group conversion
        1.  
          Volume group conversion limitations
        2.  
          Converting LVM volume groups to VxVM disk groups
        3. Examples of second stage failure analysis
          1.  
            Snapshot in the volume group
          2.  
            dm_mirror module not loaded in the kernel
          3.  
            Conversion requires extent movement on an LVM1 volume group
          4.  
            Unrecognized partition in volume group
      4. LVM volume group restoration
        1.  
          Restoring an LVM volume group
    3. Offline conversion of native file system to VxFS
      1.  
        About the offline conversion of native file system to VxFS
      2.  
        Requirements for offline conversion of a native file system to VxFS
      3.  
        Converting the native file system to VxFS
    4. Online migration of a native file system to the VxFS file system
      1.  
        About online migration of a native file system to the VxFS file system
      2.  
        Administrative interface for online migration of a native file system to the VxFS file system
      3.  
        Migrating a native file system to the VxFS file system
      4.  
        Backing out an online migration of a native file system to the VxFS file system
      5. VxFS features not available during online migration
        1.  
          Limitations of online migration
    5. Migrating storage arrays
      1.  
        Array migration for storage using Linux
      2.  
        Overview of storage mirroring for migration
      3.  
        Allocating new storage
      4.  
        Initializing the new disk
      5.  
        Checking the current VxVM information
      6.  
        Adding a new disk to the disk group
      7.  
        Mirroring
      8.  
        Monitoring
      9.  
        Mirror completion
      10.  
        Removing old storage
      11.  
        Post-mirroring steps
    6. Migrating data between platforms
      1. Overview of the Cross-Platform Data Sharing (CDS) feature
        1.  
          Shared data across platforms
        2.  
          Disk drive sector size
        3.  
          Block size issues
        4.  
          Operating system data
      2. CDS disk format and disk groups
        1. CDS disk access and format
          1. CDS disk types
            1.  
              Private and public regions
            2.  
              Disk access type auto
            3.  
              Platform block
            4.  
              AIX coexistence label
            5.  
              HP-UX coexistence label
            6.  
              VxVM ID block
          2. About Cross-platform Data Sharing (CDS) disk groups
            1.  
              Device quotas
            2.  
              Minor device numbers
        2.  
          Non-CDS disk groups
        3. Disk group alignment
          1. Alignment values
            1.  
              Dirty region log alignment
          2.  
            Object alignment during volume creation
      3. Setting up your system to use Cross-platform Data Sharing (CDS)
        1. Creating CDS disks from uninitialized disks
          1.  
            Creating CDS disks by using vxdisksetup
          2.  
            Creating CDS disks by using vxdiskadm
        2. Creating CDS disks from initialized VxVM disks
          1.  
            Creating a CDS disk from a disk that is not in a disk group
          2.  
            Creating a CDS disk from a disk that is already in a disk group
        3. Creating CDS disk groups
          1.  
            Creating a CDS disk group by using vxdg init
          2.  
            Creating a CDS disk group by using vxdiskadm
        4.  
          Converting non-CDS disks to CDS disks
        5.  
          Converting a non-CDS disk group to a CDS disk group
        6.  
          Verifying licensing
        7.  
          Defaults files
      4. Maintaining your system
        1. Disk tasks
          1.  
            Changing the default disk format
          2.  
            Restoring CDS disk labels
        2. Disk group tasks
          1.  
            Changing the alignment of a disk group during disk encapsulation
          2.  
            Changing the alignment of a non-CDS disk group
          3.  
            Splitting a CDS disk group
          4.  
            Moving objects between CDS disk groups and non-CDS disk groups
          5.  
            Moving objects between CDS disk groups
          6.  
            Joining disk groups
          7.  
            Changing the default CDS setting for disk group creation
          8.  
            Creating non-CDS disk groups
          9.  
            Upgrading an older version non-CDS disk group
          10.  
            Replacing a disk in a CDS disk group
          11.  
            Setting the maximum number of devices for CDS disk groups
          12.  
            Changing the DRL map and log size
          13.  
            Creating a volume with a DRL log
          14.  
            Setting the DRL map length
        3. Displaying information
          1.  
            Determining the setting of the CDS attribute on a disk group
          2.  
            Displaying the maximum number of devices in a CDS disk group
          3.  
            Displaying map length and map alignment of traditional DRL logs
          4.  
            Displaying the disk group alignment
          5.  
            Displaying the log map length and alignment
          6.  
            Displaying offset and length information in units of 512 bytes
        4.  
          Default activation mode of shared disk groups
        5.  
          Additional considerations when importing CDS disk groups
      5. File system considerations
        1.  
          Considerations about data in the file system
        2.  
          File system migration
        3. Specifying the migration target
          1.  
            Examples of target specifications
        4. Using the fscdsadm command
          1.  
            Checking that the metadata limits are not exceeded
          2. Maintaining the list of target operating systems
            1.  
              Adding an entry to the list of target operating systems
            2.  
              Removing an entry from the list of target operating systems
            3.  
              Removing all entries from the list of target operating systems
            4.  
              Displaying the list of target operating systems
          3.  
            Enforcing the established CDS limits on a file system
          4.  
            Ignoring the established CDS limits on a file system
          5.  
            Validating the operating system targets for a file system
          6.  
            Displaying the CDS status of a file system
        5.  
          Migrating a file system one time
        6. Migrating a file system on an ongoing basis
          1.  
            Stopping ongoing migration
        7.  
          When to convert a file system
        8. Converting the byte order of a file system
          1.  
            Importing and mounting a file system from another system
      6.  
        Alignment value and block size
      7.  
        Migrating a snapshot volume
    7. Migrating from Oracle ASM to Veritas File System
      1.  
        About the migration
      2.  
        Pre-requisites for migration
      3.  
        Preparing to migrate
      4.  
        Migrating Oracle databases from Oracle ASM to VxFS
  8. Section VIII. Just in time availability solution for vSphere
    1. Just in time availability solution for vSphere
      1. About Just In Time Availability
        1.  
          Getting started with Just In Time Availability
      2.  
        Prerequisites
      3.  
        Supported operating systems and configurations
      4.  
        Setting up a plan
      5.  
        Managing a plan
      6.  
        Deleting a plan
      7.  
        Viewing the properties
      8.  
        Viewing the history tab
      9.  
        Limitations of Just In Time Availability
  9. Section IX. Veritas InfoScale 4K sector device support solution
    1. Veritas InfoScale 4k sector device support solution
      1.  
        About 4K sector size technology
      2.  
        Veritas InfoScale unsupported configurations
      3.  
        Migrating VxFS file system from 512-bytes sector size devices to 4K sector size devices
  10. Section X. Reference
    1. Appendix A. Veritas AppProtect logs and operation states
      1.  
        Log files
      2.  
        Plan states
    2. Appendix B. Troubleshooting Veritas AppProtect
      1.  
        Troubleshooting Just In Time Availability

Converting LVM volume groups to VxVM disk groups

To convert LVM volume groups to VxVM disk groups

  1. Identify the LVM disks and volume groups that are to be converted. Use LVM administrative utilities such as vgdisplay to identify the candidate LVM volume groups and the disks that comprise them. You can also use the listvg operation in vxvmconvert to examine groups and their member disks, and the list operation to display the disks known to the system as shown here:
    # vxvmconvert
   .
   .
   .
Select an operation to perform: list
   .
   .
   .
Enter disk device or "all"[<address>,all,q,?](default: all) all
 
DEVICE        DISK        GROUP       STATUS
cciss/c0d0    -           -           online invalid
cciss/c0d1    -           -           online
sda           -           -           online
sdb           disk01      rootdg      online
sdc           disk02      rootdg      online
sdd           disk03      rootdg      online
sde           -           -           error
sdf           -           -           error
sdg           -           -           error
sdh           -           -           error
 
Device to list in detail [<address>,none,q,?] (default: none)

    The DEVICE column shows the disk access names of the physical disks. If a disk has a disk media name entry in the DISK column, it is under VM control, and the GROUP column indicates its membership of a disk group. The STATUS column shows the availability of the disk to VxVM. LVM disks are displayed in the error state as they are unusable by VxVM.

    To list LVM volume group information, use the listvg operation:

    Select an operation to perform: listvg
   .
   .
   .
Enter Volume Group (i.e.- vg04) or "all"
[<address>,all,q,?] (default: all) all

LVM VOLUME GROUP INFORMATION
Name         Type         Physical Volumes
vg02         Non-Root   /dev/sdf /dev/sdh1

Volume Group to list in detail
[<address>,none,q,?] (default: none) vg02
--- Volume group ---
VG Name                      vg02
VG Access                    read/write
VG Status                    available/resizable
VG #                         0
MAX LV                       256
Cur LV                       0
Open LV                      0
MAX LV Size                  255.99 GB
Max PV                       256
Cur PV                       2
Act PV                       2
VG Size                      16.95 GB
PE Size                      4 MB
Total PE                     4338
Alloc PE / Size              0 / 0
Free PE / Size               4338 / 16.95 GB
VG UUID                      IxlERp-poi2-GO2D-od2b-G7fd-3zjX-PYycMn
 
--- No logical volumes defined in "vg02" ---
 
--- Physical volumes ---
PV Name (#)                  /dev/sdf (2)
PV Status                    available / allocatable
Total PE / Free              PE 2169 / 2169
PV Name (#)                  /dev/sdh1 (1)
PV Status                    available / allocatable
Total PE / Free PE           2169 / 2169
 
List another LVM Volume Group? [y,n,q,?] (default: n)
  2. Plan for the new VxVM logical volume names. Conversion changes the device names by which your system accesses data in the volumes. LVM creates device nodes for its logical volumes in /dev under directories named for the volume group. VxVM create device nodes in /dev/vx/dsk/diskgroup and /dev/vx/rdsk/diskgroup. After conversion is complete, the LVM device nodes no longer exist on the system.

    For file systems listed in /etc/fstab, vxvmconvert substitutes the new VxVM device names for the old LVM volume names, to prevent problems with fsck, mount, and other such utilities. However, other applications that refer to specific device node names may fail if the device no longer exists in the same place.

    Examine the following types of application to see if they reference LVM device names, and are at risk:

    • Databases that access raw logical devices.

    • Backups that are performed on device nodes named in private files. Labeling of backups may also record device names.

    • Scripts run by cron.

    • Other administrative scripts.

  3. Select item 1 Analyze LVM Volume Groups for Conversion from the vxvmconvert main menu to see if conversion of each LVM volume group is possible.

    This step is optional. Analysis can be run on a live system while users are accessing their data. This is useful when you have a large number of groups and disks for conversion to allow for the optimal planning and management of conversion downtime.

    The following is sample output from the successful analysis of a volume group:

    Select an operation to perform: 1
   .
   .
   .
Select Volume Groups to analyze:
[<pattern-list>,all,list,listvg,q,?] vg02
 
vg02
 
Analyze this Volume Group? [y,n,q,?] (default: y) y
 
Conversion Analysis of the following devices was successful.
 
/dev/sdf /dev/sdh1
 
Hit RETURN to continue.

Second Stage Conversion Analysis of vg02 
 
Volume Group vg02 has been analyzed and prepared for conversion.
 
Volume Group Analysis Completed 
 
Hit RETURN to continue.

    If off-disk data migration is required because there is insufficient space for on-disk data migration, you are prompted to select additional disks that can be used.

    The analysis may fail for one of a number of reasons.

    The messages output by vxvmconvert explain the type of failure, and detail actions that you can take before retrying the analysis.

  4. Back up your LVM configuration and user data before attempting the conversion to VxVM. Similarly, you should back up the LVM configuration itself.

    Warning:

    During a conversion, any spurious reboots, power outages, hardware errors, or operating system bugs can have unpredictable consequences. You are advised to safeguard your data with a set of verified backups.

    Before running vxvmconvert, you can use the vgcfgbackup utility to save a copy of the configuration of an LVM volume group, as shown here:

    # vgcfgbackup volume_group_name

    This creates a backup file, /etc/lvmconf/volume_group_name.conf. Save this file to another location (such as off-line on tape or some other medium) to prevent the conversion process from overwriting it. If necessary, the LVM configuration can be restored from the backup file.

    The vxvmconvert utility also saves a snapshot of the LVM configuration data during conversion of each disk. This data is saved in a different format from that of vgcfgbackup, and it can only be used with the vxvmconvert program. With certain limitations, you can use the data to reinstate the LVM volumes after they have been converted to VxVM. Even though vxvmconvert provides this mechanism for backing up the LVM configuration, you are advised to use vgcfgbackup to save the LVM configuration information for each LVM volume group.

    Before performing a backup of the user data, note that backup procedures may have dependencies on the volume names that are currently in use on your system. Conversion to VxVM changes the volume names. You need to understand the implications that such name changes have for restoring from any backups that you make.

  5. Prevent access by applications to volumes in the volume groups to be converted. This may require you to stop databases, unmount file systems, and so on.

    vxvmconvert attempts to unmount mounted file systems before starting conversion. However, it makes no attempt to stop applications that are using those file systems, nor does it attempt to deal with applications such as databases that are running on raw LVM volumes.

    The LVM logical volumes to be converted must all be available to the vxvmconvert process. Do not deactivate the volume group or any logical volumes before running vxvmconvert.

    You can use the following command to activate a volume group:

    # vgchange -a y volume_group_name
  6. Start the conversion of each volume group by selecting item 2 Convert LVM Volume Groups to VxVM from the vxvmconvert main menu. The volume group is analyzed to ensure that conversion is possible. If the analysis is successful, you are asked whether you wish to perform the conversion.

    Convert one volume group at a time to avoid errors during conversion.

    The following is sample output from a successful conversion:

    Select an operation to perform: 2
   .
   .
   .
Select Volume Groups to convert:
[<pattern-list>,all,list,listvg,q,? vg02
 
vg02
 
Convert this Volume Group? [y,n,q,?] (default: y) y
 
Conversion Analysis of the following devices was successful.
 
/dev/sdf /dev/sdh1
 
Hit RETURN to continue.
 
Second Stage Conversion Analysis of vg02 
 
Volume Group vg02 has been analyzed and prepared for conversion.
 
Are you ready to commit to these changes?[y,n,q,?](default: y) y
 
vxlvmconv: making log directory /etc/vx/lvmconv/vg02.d/log.
vxlvmconv: starting conversion for VG "vg02" - 
Thu Feb 26 09:08:57 IST 2004
 
vgchange -- volume group "vg02" successfully deactivated
 
vxlvmconv: checking disk connectivity
Starting Conversion of vg02 to VxVM
fdisk ..
disksetup ..
dginit ..
make .
volinit ..
vxlvmconv: Conversion complete.
 
Convert other LVM Volume Groups? [y,n,q,?] (default: n)

    If off-disk data migration is required because there is insufficient space for on-disk data migration, you are prompted to select additional disks that can be used.

  7. After converting the LVM volume groups, you can use the list operation in vxvmconvert to examine the status of the converted disks, as shown in this example:
    Select an operation to perform: list
   .
   .
   .
Enter disk device or "all"[<address>,all,q,?](default: all) all
 
DEVICE       DISK         GROUP        STATUS
cciss/c0d0   -            -            online invalid
cciss/c0d1   -            -            online
sda          -            -            online
sdb          disk01       rootdg       online
sdc          disk02       rootdg       online
sdd          disk03       rootdg       online
sde1         vg0101       vg01         online
sdf          vg0201       vg02         online
sdg          vg0102       vg01         online
sdh1         vg0202       vg02         online
 
Device to list in detail [<address>,none,q,?] (default: none)

    The LVM disks that were previously shown in the error state are now displayed as online to VxVM.

    You can also use the vxprint command to display the details of the objects in the converted volumes (the TUTIL0 and PUTIL0 columns are omitted for clarity):

    # vxprint

Disk group: rootdg

TY NAME        ASSOC        KSTATE    LENGTH    PLOFFS   STATE
dg rootdg      rootdg       -         -         -        -

dm disk01      sdb          -         17778528  -        -
dm disk02      sdc          -         17778528  -        -
dm disk03      sdd          -         17778528  -        -

Disk group: vg01
 
TY NAME        ASSOC        KSTATE    LENGTH    PLOFFS   STATE
dg vg01        vg01         -         -         -        -
 
dm vg0101      sde1         -         17774975  -        -
dm vg0102      sdg          -         17772544  -        -

v stripevol    gen          ENABLED   1638400   -        ACTIVE
pl stripevol-01stripevol    ENABLED   1638400   -        ACTIVE
sd vg0102-01   stripevol-01 ENABLED   819200    0        -
sd vg0101-01   stripevol-01 ENABLED   819200    0        -

Disk group: vg02

TY NAME        ASSOC        KSTATE    LENGTH    PLOFFS   STATE
dg vg02        vg02         -         -         -        -

dm vg0201      sdf          -         17772544  -        -
dm vg0202      sdh1         -         17774975  -        -

v concatvol    gen          ENABLED   163840    -        ACTIVE
pl concatvol-01concatvol    ENABLED   163840    -        ACTIVE
sd vg0202-02   concatvol-01 ENABLED   163840    0        -
v stripevol    gen          ENABLED   81920     -        ACTIVE
pl stripevol-01stripevol    ENABLED   81920     -        ACTIVE
sd vg0202-01   stripevol-01 ENABLED   40960     0        -
sd vg0201-01   stripevol-01 ENABLED   40960     0        -
  8. Implement the changes to applications and configuration files that are required for the new VxVM volume names. (You prepared the information for this step in step 2.)
  9. File systems can now be mounted on the new devices, and applications can be restarted. If you unmounted any file systems before running vxvmconvert, remount them using their new volume names. The vxvmconvert utility automatically remounts any file systems that were left mounted.
  10. The disks in each new VxVM disk group are given VM disk media names that are based on the disk group name. For example, if a disk group is named mydg, its disks are assigned names such as mydg01, mydg02, and so on. Plexes within each VxVM volume are named mydg01-01, mydg01-02, and so on. If required, you can rename disks and plexes.

    Only rename VxVM objects in the converted disk groups when you are fully satisfied with the configuration. Renaming VxVM objects prevents you from using vxvmconvert to restore the original LVM volume groups.

More Information

Volume group conversion limitations

Examples of second stage failure analysis