Data Domain: Access Group Best Practices

Access Groups Best Practices

Applies To:

• All Data Domain systems
• All Software Releases supporting VTL
• VTL and SAN Protocols
• Third-party Backup Applications such as NetWorker, Tivoli Storage Manager (TSM), and so forth

Purpose

This document provides information about proper configuration to avoid potential issues with access groups.

Solution

Things to consider in creating access groups:

• Clients and Operating Systems:
  • What OS is accessing the group? It is best to use one OS type per group, and ideally one client machine per group.
  • How many clients must access the same tape drives? If feasible, consider assigning a different set of drives to each client machine.
  • If the backup software does not have a "shared storage" option, it is best to make separate access groups for each client, with unique tape drives defined for each client.
• Drives and changer:
  • Avoid putting the changer into every access group. Generally, only the primary backup server should have access to the changer. (See TSM recommendations below)
  • Avoid putting more than one changer in the same access group. (See TSM recommendations below)
  • Avoid using "all" designation for primary or secondary ports when assigning the VTL Host Bus Adapter (HBA) ports to individual tape drives or changers. It is preferable to assign a single primary or secondary port per device. This avoids possible conflicting commands being issued to drives or changers. Unless a clear and tested failover plan exists, secondary ports should be none.
  • Avoid sharing the same tape drives or changers across multiple access groups. (See TSM recommendations below)
  • Do not use two or more different tape drive types in the same access group. (Example, avoid having IBM LTO3 and LTO-5 in the same group)
• LUN Addressing:
  • Usually, it is best to allow the VTL to assign LUN numbers automatically by not entering a LUN number when you create the access group. Also, there is no performance advantage to using out-of-sequence LUN numbering, and doing so can cause problems for certain OS types in communicating with the VTL. 
  • For access to NAS filers, use the same scheme as for LINUX machines. Generally, numbering should always start at LUN zero and maintain contiguous LUN numbering sequences from zero for every target port. Usually, use one primary path on the VTL HBA to the tape drives and changer.
• Application-specific notes:
  • Tivoli Storage Manager (TSM): For TSM servers or clients, assign only one specific primary port to a tape drive or changer. You can assign a secondary port if the SAN auto discovery feature is enabled in the TSM server. Also, the TSM primary server must have access to all libraries changers and tape drives. When TSM tells a changer to load a tape it reads the tape header, the primary TSM server must be zoned to all tape drives. TSM cannot read the tape label through a proxy/client thus the need for the primary server to be zoned to all changers and drives. The client machines for backup should not be zoned to the changer. When using the shared storage option in TSM, it is perfectly OK to share tape drives among various clients however avoid sharing tape drives across differing OS types. (example, do not share tape drives between AIX and HP-UX clients)
  • IBMi and AS/400: For IBMi installations, adhere to the same policy as for TSM, by assigning only one primary port to a tape drive or changer. You can use alternating ports for alternating Logical Unit Numbers (LUNs) so it is perfectly OK to use primary port 4a for LUNs 0, 2, 4, 6, 8 and primary port 4b for LUNs 1, 3, 5, 7. VIOS is supported for IBMi and VTL, not all IOA/IOP devices are supported for this check the Dell Compatibility Matrix for correct device types.
  • Consult your backup applications documentation to determine if your software has any of the following limitations:
    • Some backup software may have limitations in the number of devices it can recognize being attached to a client or server.
    • Some backup software may have a limit on the number of slots it can accommodate in a library.
    • Some backup software cannot arbitrate multiple clients accessing common resources so those require unique tape drives in each access group and a single server/client per group.
• OS-specific notes:
  • Linux: When assigning access to Linux machines, always use LUN zero as the first LUN in the data path, and use contiguous LUN numbers starting at zero with no gaps in the sequence. For example, assigning LUNs 0, 1, 2, 3, 4 is correct, assigning LUNs 0, 2, 4, 5 is incorrect.
  • Solaris: For Solaris you can spread out the primary paths among the LUNs, as Solaris does not have to see a LUN zero on every path. For example for LUNs 0, 2, 4, 6, you can assign primary port 4a and primary port 4b for LUNs 1, 3, 5, 7. (At this time, Ultrium-5 tape drives are not supported on Solaris 11)
  • Windows: You can use the same port assignments for Windows as described for Solaris, above.
  • IBMi systems andAS400: Some customers want to use a single library across multiple LPARS or systems, or to use multiple HBAs on the IBMi system. In these cases, follow these guidelines: The library and drive access can now be controlled from the WRKMLBSTS level on the IBMi system. The customer can control how the library is accessed by varying on and off the individual instances of the library on the IBMi.
    1. Split the drives across multiple access groups each addressing a single IBMi HBA. (No drive sharing)
    2. Add the changer to each group. The changer is visible over multiple paths, and the library appears with multiple names on the IBMi system.

References

• Data Domain: Virtual Tape Library Best Practices Guide