Common Use Cases

Note: StorNext File Systems prior to version 4.3, which are configured to utilize affinities on the HaShared file system, will need to reapply affinities to directories in the HaShared file system after the upgrade to version 4.3 completes.

In some instances customers have seen improved performance of the HaShared file system by separating I/O to database and metadata archive directories through the use of multiple stripe groups and SNFS stripe group affinities. The specific improvements are dependent on the overall system utilization characteristics.

When using Affinities on the HaShared file system, the AffinityPreference setting should be enabled in the file system configuration. This setting will allow files to be allocated to other available stripe groups (with non-exclusive affinities) when the stripe groups of their affinity do not have sufficient space. This will prevent unnecessary out-of-space errors occurring on the HaShared file system.

The following section describes options for configuring affinities in the HaShared file system.

Note: Configuring an HaShared file system with multiple stripe groups, but no affinities will still have the advantages of distributing file I/O across each of the underlying disks. For many this simplified approach may be preferable.

For configurations utilizing two data stripe groups in the HaShared file system, key database files should be assigned to one affinity and key metadata files should be assigned the other affinity. If more than two stripe groups are configured in the HaShared file system, the individual MySQL directories can be broken out into their own stripe groups with the appropriate affinity set.

WARNING: Ensure that each stripe group is provisioned appropriately to handle the desired file type. See the snPreInstall script for sizing calculations. Failure to provision stripe groups appropriately could result in unexpected no-space errors.

1. Configure HaShared file system to use multiple data stripe groups.
   • If this is the initial configuration of the HaShared file system, it is recommended that an exclusive metadata & journal stripe group be created along with each of the data stripe groups. Each affinity should be assigned to the desired data stripe group prior to creating the file system.

   • If the HaShared file system already exists, any additional stripe groups should be added and the desired affinities should be added to the data stripe groups. If the MDC pair has already been converted to HA, then the MDCs must be put into Config Mode before making configuration changes to the HaShared file system.

     The number of data stripe groups should be equal to, or greater than the number of affinities desired. Do not configure any of the data affinities as exclusive.

2. If the MDC pair has not yet been converted to HA, do so at this point.
   • After the HA conversion completes, put the MDC pair into Config Mode.
3. Stop Storage Manager.

4. Assign the desired affinity to each of the directories and move data to the appropriate stripe group using the following commands:

   # find <directory> -exec cvaffinity –s <affinity key> {} \;
   # snfsdefrag –m 0 –k <affinity key> -K <affinity key> -r <directory>

   Note: Beginning with StorNext 6, use the sgoffload command instead of the snfsdefrag command. The sgoffload command moves extents belonging to files that are currently in use (open). The sgoffload command also informs the client to suspend I/O for a time, moves the data, then informs the client to refresh the location of the data and resume I/O.

5. Start Storage Manager.

6. Exit Config Mode.

   Note: Any active metadata archive files will not be migrated at the time these steps are run, as open files will not be relocated. Once the next StorNext backup runs, subsequent metadata archive files will be allocated on the desired stripe group.

To segregate audio and video files onto their own stripe groups:

One common use case is to segregate audio and video files onto their own stripe groups. Here are the steps involved in this scenario:

• Create one or more stripe groups with an AUDIO affinity and the exclusive attribute.
• Create one or more stripe groups with a VIDEO affinity and the exclusive attribute.
• Create one or more stripe groups with no affinity (for non-audio, non-video files).
• Create a directory for audio using ‘cvmkdir -k AUDIO audio’.
• Create a directory for video using ‘cvmkdir -k VIDEO video’.

Files created within the audio directory will reside only on the AUDIO stripe group. (If this stripe group fills, no more audio files can be created.)

Files created within the video directory will reside only on the VIDEO stripe group. (If this stripe group fills, no more video files can be created.)

In this use case, high-speed disk usage is reserved for and limited to only critical files. Here are the steps for this scenario:

• Create a stripe group with a FAST affinity and the exclusive attribute.
• Label the critical files or directories with the FAST affinity.

The disadvantage here is that the critical files are restricted to using only the fast disk. If the fast disk fills up, the files will not have space allocated on slow disks.

To work around this limitation, you could reserve high-speed disk for critical files but also allow them to grow onto slow disks. Here are the steps for this scenario:

• Create a stripe group with a FAST affinity and the exclusive attribute.

• Create all of the critical files, pre allocating at least one block of space, with the FAST affinity, or move them using snfsdefrag after ensuring the files are not empty.

  Note: Beginning with StorNext 6, use the sgoffload command instead of the snfsdefrag command. The sgoffload command moves extents belonging to files that are currently in use (open). The sgoffload command also informs the client to suspend I/O for a time, moves the data, then informs the client to refresh the location of the data and resume I/O.

• Remove the FAST affinity from the critical files.

Alternatively, configure the AffinityPreference parameter. For additional information see Configure Affinities.

Because files allocate from their existing stripe group even if they no longer have a matching affinity, the critical files will continue to grow on the FAST stripe group. Once this stripe group is full, they can allocate space from other stripe groups since they do not have an affinity.

This scenario will not work if new critical files can be created later, unless there is a process to move them to the FAST stripe group, or an affinity is set on the critical files by inheritance but removed after their first allocation (to allow them to grow onto non-FAST groups).