Back-end storage overviewBack-end storage is one of the key components of the IBM System Storage TS7650G ProtecTIER Deduplication Gateway (TS7650G) implementation. It consists of the storage subsystems that attach to the ProtecTIER Gateway nodes.
In contrast to the ProtecTIER Appliance models, which are preconfigured with disks, the ProtecTIER Gateway attaches to back-end storage subsystems that then contain the repository. This chapter lists the key factors and common configuration requirements for back-end storage that is supported by the TS7650G.
This chapter describes the following topics:
7.1 Overview
ProtecTIER back-end storage is a critical hardware component that holds the ProtecTIER repository. Three types of file systems make up the ProtecTIER repository:
Cluster database Single 1 gigabyte logical unit number (1 GB LUN) that holds the cluster configuration information. It is in a metadata Redundant Array of Independent Disks (RAID) group, and is seen as a metadata file system. This item is also called a quorum.
Metadata Stores all the aspects about the data that is backed up and indexed, but not the actual data. The references for restoring are kept in the metadata file systems. These file systems must be on RAID 10 arrays.
User data Stores the actual data that is backed up, and referenced by new generations of backups. These file systems must be on RAID 6 or RAID 5 arrays.
|
Tip: The cluster database or quorum has a storage requirement that can be fulfilled by allocating 1 GB of data. You do not need to perform a conversion to gibibytes (GiB) or allocate more than 1 GB.
|
The file systems are created on the LUNs of storage arrays, so the construction and layout of the LUNs influence the overall ProtecTIER system performance.
Figure 7-1 on page 101 shows an example of the ProtecTIER Performance Planner. This tool is primarily used by the IBM Pre-sales and IBM Business Partners. Based on the planner, to achieve 500 megabytes per second (MBps) and accommodate a 120 terabyte (TB) repository with a 10:1 HyperFactor ratio, the storage array should be configured as follows:
•Metadata
– 24 drives each of 300 GB 15,000 revolutions per minute (RPM) of Fibre Channel (FC)
– 3 x 4+4 RAID 10 groups
The number of RAID groups given in this example does not account for the file system to store the cluster database, which is 1 GB in size and does not require a separated RAID group. Therefore, you can build two LUNs of 1200 GB each, one LUN of 1199 GB, and one LUN of 1 GB to present to the ProtecTIER to use for metadata. Or you can build the three LUNs of 1200 GB, and do the arrangements for the Cluster database at a disk partition level on the ProtecTIER server.
•User data
– 176 drives each of 1 TB 7200 RPM of Serial Advanced Technology Attachment (SATA)
– 22 x 6+2 RAID 6 groups
You can build 22 LUNs of 6 TB each, and present them to ProtecTIER to use for user data.
Figure 7-1 Example of ProtecTIER Performance Planner
|
Important: The LUN layout is defined during the pre-sales cycle with the ProtecTIER Planner tools, based on customer capacity and performance requirements. Figure 7-1 shows the Performance Planner, and Figure 7-2 on page 102 shows the Metadata Planner. The outcome of a ProtecTIER planning session is used to size and configure
storage arrays. Review your storage array configurations with a trained ProtecTIER specialist before the ProtecTIER installation commences onsite. Only ProtecTIER trained specialists (IBM Pre-sales and IBM Business Partners) should validate sizing and planning.
All aspects of the storage disks, including configuration, monitoring, code updates, and repair actions, are the responsibility of the client in conjunction with a disk storage vendor.
|
Figure 7-2 shows an example of the ProtecTIER Meta Data Planner. Based on information that is shown in Figure 7-2, the requirements for the metadata are as follows:
•Four metadata file systems (including the 1 GB file system for the Cluster database).
•The minimum sizes required for file systems are: 1 GB, 1042 GB, 1049 GB, and 650 GB.
Figure 7-2 Example of ProtecTIER Meta Data Planner
|
Important: Always assign the full RAID array capacity to the LUNs that are used for ProtecTIER metadata and user data. The only exception to this rule is the Cluster database file system of 1 GB, which does not require a separate RAID group.
|
7.1.1 ProtecTIER Planner tool
|
Availability: The ProtecTIER Planner tool is an IBM internal tool that is available to trained ProtecTIER specialists.
|
The core component for any capacity sizing and subsequent configuration effort is the ProtecTIER Planner. The primary methodologies to accurately size the required capacity and configure the disk and file system infrastructure depend on the correct usage of this tool.
The primary function of the ProtecTIER Planner enables field engineers to perform key activities when they size and configure the physical disk systems that are connected as back-end storage of the ProtecTIER server. The process starts at a high level, where a general capacity sizing is performed, based on key variables in the organization's environment.
Another aspect of the sizing process is to understand how many metadata and user data file systems are required based on disk technologies and RAID configurations to ensure correct performance. The ProtecTIER Performance Planner aids in this process.
The ProtecTIER Metadata Planner enables the field engineer to understand how many metadata file systems are required to support a repository of a certain size and the size of the metadata file systems.
There are other utilities in the ProtecTIER Planner, such as upgrading from a previous version (with the import of historical user data), and customizing any disk performance information based on unique user scenarios when planning performance.
For more information about capacity planning for a TS7650 Appliance environment, see IBM System Storage TS7600 with ProtecTIER Version 3.3, SG24-7968.
The ProtecTIER Planner should be used for capacity and performance planning while manually adapting it to a many-to-many environment at an early stage before the ProtecTIER deployment. The parameters to be considered are the same ones that are used in any
replication deployment:
replication deployment:
•System workload. Both local backup and replication, including incoming and outgoing.
•Network bandwidth. Available and required between the PT nodes on the grid.
•Time frames. Backup and replication windows or concurrent operation.
7.2 Dependencies from a back-end storage subsystem view
Independent from the back-end storage subsystem, some general guidelines indicate how to lay out your storage for optimal usage of ProtecTIER.
Depending on whether you plan to deploy a small or large ProtecTIER gateway solution, be aware of certain limits and effects.
All storage subsystems come with multiple controllers. So, you must use at least two LUNs to distribute them across both controllers of a storage subsystem.
All IBM Storage Subsystems are based on standard hardware. For example, the IBM System Storage DS8000® is based on the IBM System p architecture, and the IBM Storwize® Family and SAN Volume Controller are based on the IBM System x architecture. With these architectures, the controller nodes of the storage subsystems tend to have multiple processors driving the input/output (I/O), and multiple cores per processor.
To use all of these resources, you must have multiple LUNs per controller at the same time. For example, with the IBM Storwize Family and SAN Volume Controller, you must have at least four arrays per controller to ensure the optimal usage of all computing cores.
Based on these calculations, assume that a minimum number of eight LUNs enables an optimal usage of the available resources. These are some more general assumptions. Your individual system might be fine with fewer than eight LUNs if sizing and planning were done for your individual requirements.
7.3 Dependencies from a ProtecTIER view
ProtecTIER uses a special method to write data to disk. ProtecTIER writes data to disk by creating data in or appending data to the repository structure. These are the two principal modes of operation. Data that can be expired from a ProtecTIER perspective is not overwritten. It is deleted by the maintenance processes and is reshaped by the defragger practices before it is used again by write or append operations.
This concept of data management directly benefits clients by having multiple file systems that ProtecTIER can work with at the same time. If your ProtecTIER repository enables backup speeds of 2500 MBps or more, you need at least 32 file systems in your back-end storage for ProtecTIER to work with.
If you aim for a medium performance solution, you can use fewer than 32 file systems. Again, these assumptions are more general ones, and your individual system will be fine if these assumptions are implemented according to your individual sizing and planning.
7.4 Smart storage subsystems
All of the current-generation storage subsystems offer some sort of technology that adds an additional layer of virtualization to the distribution of data across the storage.
On the IBM Storwize Family and SAN Volume Controller, this technology is called extent striping. If you create a VDisk with the -vtype striped parameter (which is the default), all managed disks in the managed disk group are used to create the virtual disk. The striping is at an extent level; one extent from each managed disk in the group is used. For example, a managed disk group with 10 managed disks uses one extent from each managed disk, and then it uses the 11th extent from the first managed disk.
On DS8000, this technology is called storage pool striping (SPS) or rotate extents. The storage pool striping function stripes new volumes across all ranks of an extent pool. A similar approach is also used with IBM Storwize Family and SAN Volume Controller.
So what is the benefit of performing striping? What benefits do extent striping, rotate extents, and so on, provide?
These features provide the following primary enhancements:
•The striped volume layout reduces workload skew in the system without requiring manual tuning by a storage administrator (hot spots).
•This approach can increase performance with minimal operator effort (high performance).
•You can extend your existing arrays relatively easily by adding more extents to the existing pools (easy expansion).
These striping features enable you to avoid “hot spots” in your storage, to allocate more turning spindles of the storage to drive your workload, and to enable easy expansion of your environment even for existing arrays and LUNs.
Because of the design method that ProtecTIER uses to write data to disk, ProtecTIER prevents creating a higher load on a single array only, while others stay idle. ProtecTIER does not benefit from automatic hot spot avoidance.
ProtecTIER needs multiple LUNs to work with. Some of these LUNs are used to store the metadata, which must be RAID 10 to drive the heavily random write I/O. Some of these LUNs are used to store the user data, which must be RAID 6 or RAID 5 to drive the random read I/O. ProtecTIER evenly distributes the load across the storage system, and across all of the available LUNs.
ProtecTIER also uses a special method to extend the back-end storage during the ProtecTIER repository expansion process. Depending on the amount of storage that you want to add, you can add or extend metadata, add user data, or both. Depending on how the initial deployment of ProtecTIER was done, increasing the metadata might be done by adding storage to existing metadata file systems (extend file system), or it might be done by adding some new metadata file systems and leave the existing ones untouched.
For the user data, because of the padding process that allocates all of the file system’s storage immediately during implementation, the repository growth includes adding new file systems. Expanding the ProtecTIER user data does not involve growing individual LUNs or file systems. To grow the ProtecTIER user data, more user data LUNs and file systems must be added.
If you compare these three major differences to a classical disk workload, it is obvious that the special way that ProtecTIER uses its back-end storage does not benefit from storage pool striping, rotate extents, or similar technologies.
It is, however, theoretically possible that the usage of storage pool striping or rotate extents might collocate multiple and popular deduplication candidates in the repository on a reduced number of spindles.
7.5 Key rules for a ProtecTIER server
A ProtecTIER server uses storage resources heavily. Therefore, the storage resources must be dedicated to the ProtecTIER server’s activities. The following list provides a list of key rules for configuring your back-end storage to use with ProtecTIER:
•Disk-based replication is supported only by request for product quotation (RPQ). Use the ProtecTIER native IP replication feature that is available in Version 2.5 and later. For more information about replication, see Part 4, “Replication and disaster recovery” on page 359.
•If you use a SAN switch to connect the TS7650G to the disk array, create dedicated zoning for ProtecTIER back-end ports. Do not mix the back-end ports with the front-end ports or any other SAN devices in the same zone.
•Dedicate the whole storage array to the TS7650G. If this configuration is not possible, make sure that the I/O requirements of ProtecTIER can be ensured and are not affected by other applications. Make sure that there is no congestion or oversubscription of resources because of other applications that might affect ProtecTIER arrays. Use zoning to isolate the TS7650G traffic from other applications. The TS7650G can never share RAID groups/arrays or LUNs with other applications.
•ProtecTIER creates a heavily random-read I/O pattern. About 80 - 90% of all I/O requests in a typical TS7650G environment are random reads. Because of the binary differential comparison, ProtecTIER creates this pattern even during backup traffic to ProtecTIER. The I/O pattern resembles the one for a database application. Therefore, implement suitable performance optimizations and tuning as suggest by the disk vendor for database I/O profiles.
•Because of the increased flexibility and the robustness to protect against cabling errors, use worldwide port name (WWPN)-based zoning (soft zoning). Direct attachment of back-end storage subsystems is supported for the Storwize and the DS8000
product families.
product families.
•RAID 10 must be used for metadata. Use RAID 6 for user data arrays with disk sizes larger then 900 GB. You can use RAID 5 for user data arrays with disks sizes of 900 GB or less.
7.6 Storage arrays configuration
The following section describes general requirements for configuring storage arrays in a ProtecTIER environment. This section also describes some guidelines for setting up RAID groups and LUNs to get optimal performance with metadata and user data. This section then describes guidelines for placing user data on SATA disks, and expanding your repository.
7.6.1 General requirements
This section describes some general requirements for configuring storage arrays in a ProtecTIER environment, including firmware levels, host mapping, and controller support.
Storage array firmware
The storage array firmware level should be equal to or greater than the firmware version listed in the IBM SSIC and ProtecTIER ISV Support Matrix. More details are in Appendix B, “ProtecTIER compatibility” on page 457.
Storage cache
You should have 8 GB for a storage cache for every 500 MBps of planned ProtecTIER performance.
Host mapping
The ProtecTIER server host type (host connectivity settings) must be tuned for a Red Hat Enterprise Linux (RHEL) device-mapper-multipath client. For example, you should map metadata LUNs and user data LUNs as LNXCLUSTER (which has Automatic Value Transfer (AVT) disabled) for host mapping.
In storage arrays with active-active controller support, where a LUN can be accessed from both disk controllers simultaneously, LUNs must be mapped to both controllers for the optimum load balancing and redundancy.
Storage arrays with only active-passive support
In storage arrays with only active-passive support, where LUNs can be accessed only by one disk controller at a time, LUN mapping must be interleaved between controllers to establish effective load balancing. Select the preferred path of the LUNs such that the following conditions are true:
•LUNs with even numbers are assigned to Controller A.
•LUNs with odd numbers are assigned to Controller B.
7.6.2 RAID considerations
It is critical to implement RAID for data protection and performance.
The RAID group size must be consistent, because a smaller RAID group inhibits the performance of a larger RAID group. For example, do not mix 4+1 user data LUNs with 7+1 user data LUNs. The same rules apply to metadata LUNs.
|
Important: To maximize reliability of the ProtecTIER system, always use RAID 6 for solutions with larger disk sizes. Use RAID 5 only with disk sizes of 900 GB max . Today‘s large disk drive capacities cause long rebuild times in case of drive failure. In RAID 5 design, this implies a significant threat for double disk failure during RAID rebuild.
Fine-tuning: RAID 5 and RAID 6 tend to cause the least performance penalty if created with even data spindles that are paired with additional parity spindles. For example, a 4+1 RAID 5 or an 8+1 RAID 5 is considered optimal. Arrays with odd data spindles tend to cause a more severe performance effect. For example, a 5+1 RAID 5 or a 5+2 RAID 6 is considered suboptimal.
|
Metadata
The following list includes the RAID considerations regarding metadata:
•The number of metadata RAID groups is defined with the ProtecTIER Planner Tool during the pre-sales cycle. This number should be 2 or more depending on repository size, the factoring ratio, and performance requirements.
•Use at least eight disk members in the group (4+4).
•Use RAID 10 with a layout that meets your planning requirements.
•Use FC drives or serial-attached SCSI (SAS) drives for metadata, even though SATA or nearline SAS (NL-SAS) drives are used for user data.
•If needed, metadata file systems can be grown during ProtecTIER repository expansion.
|
Important: Because the average SATA disk provides only a limited number of I/O operations per second (IOPS) in comparison to a SAS or FC spindle, the use of SATA drives for metadata has a negative effect on performance.
|
User data
The following list includes the RAID considerations regarding user data:
•With FC drives or SAS drives, use RAID 5 with at least five disk members (4+1) per group.
•With SATA or NL-SAS drives, use RAID 6 with eight disk members (6+2) per group.
•User data file systems are padded before initial usage, and therefore cannot be grown. Adding more capacity during ProtecTIER repository expansion is realized by adding user data file systems.
7.6.3 LUNs
Create only one LUN per RAID group. The only exception to this rule is the cluster database of 1 GB, which can be co-located with any metadata LUN together on the same array.
|
Important: Do not share LUNs with other applications. If possible, dedicate the storage array to the TS7650G.
|
Metadata
The following list includes guidelines for LUN creation regarding metadata:
•Metadata LUNs must be created on a different RAID group than user data LUNs.
•Create a 1 GB LUN for a cluster database on any RAID with a metadata LUN.
•The number and size of metadata LUNs are determined during the pre-installation discussion with a trained ProtecTIER specialist with the Metadata Planner (see Figure 7-2 on page 102).
User data
The following list includes guidelines for LUN creation regarding user data:
•As with metadata, the number of user data LUNs is determined during the pre-installation discussion with a trained ProtecTIER specialist. For optimal performance, create at least 24 LUNs.
•Having a repository with 24 or more LUNs is optimal for the best performance.
•The size of user data LUNs must be consistent.
|
Important: A high number of LUNs attached to ProtecTIER increases the length of boot time. Starting with ProtecTIER Version 3.2, the management of LUNs greater than 8 TB is improved. When ProtecTIER V3.3 works with LUNs greater than 8 TB, it splits them into logical volumes of a smaller size. Therefore, you can work with LUNs greater than 8 TB, but there is no benefit in performance in completing this action.
|
7.6.4 Expanding the repository
When you expand the repository, use the same spindle type and quality of RAID groups for metadata and user data. For example, if existing metadata LUNs were built on 4+4 RAID groups, then new metadata RAID groups must be at least 4+4. In this example, if 2+2 or 3+3 RAID groups are used, it degrades overall system performance because of an IOPS bottleneck.
7.7 Storage area network fabric
Directly connecting ProtecTIER nodes to hosts (backup servers) and storage arrays is possible. You also can connect the components into a SAN fabric. The connection between ProtecTIER nodes and hosts (backup servers) is referred to as a front-end connection, and the connection between ProtecTIER nodes and storage arrays is referred to as a back-end connection. For the updated list of supported SAN switches of ProtecTIER, see the IBM SSIC and ProtecTIER ISV Support Matrix. For more details, see Appendix B, “ProtecTIER compatibility” on page 457.
Figure 7-3 illustrates an example of SAN fabric and zoning.
Figure 7-3 Example of SAN fabric and zoning
7.7.1 Two Fibre Channel paths to each storage controller
Each ProtecTIER node has four FC ports on the back end for storage connectivity. You should use two paths per storage controller.
7.7.2 Dedicated zones
To connect a ProtecTIER node to a storage array, create dedicated zones (one zone per initiator) for the ProtecTIER back-end port. This configuration is also known as single-initiator zoning. For example, a zone that connects a ProtecTIER node with an IBM System Storage DS8000 should contain one single ProtecTIER back-end FC port and all DS8000 ports that are available in that fabric.
|
Important: Do not mix the back-end ports with front-end ports or any other SAN devices in the same zone.
|
7.7.3 Front-end zones
Create a dedicated zone for ProtecTIER front-end ports to the host (backup application). Do not mix this zone with other SAN devices. It should have only one initiator per zone (single-initiator zoning). For example, one port of your IBM Spectrum Protect (formerly Tivoli Storage Manager) server is zoned to all of the available ProtecTIER front-end ports. For more information about front-end connectivity to a host, see “Chapter 6, “Host attachment considerations for Virtual Tape Library” on page 79.
7.7.4 Back-end zones
Create one zone per initiator. For example, a dual-node cluster has eight initiators, so there are eight zones, and each zone includes the following ports:
•A single ProtecTIER back-end FC port
•Multiple storage arrays host ports, at least one from each storage controller of
the subsystem
the subsystem
The zoning topology that is shown in Figure 7-3 on page 109 is one example of front-end and back-end connectivity of a ProtecTIER server. For more information about front-end connectivity requirements, see Chapter 6, “Host attachment considerations for Virtual Tape Library” on page 79. For more information about back-end zoning of different storage systems, see Part 5, “Appendixes” on page 433.
7.7.5 SAN paths
Keep the number of SAN paths to a reasonable amount. Having 64 paths to a storage subsystem is not helpful. As a guideline, do not use more than eight paths per storage subsystem, with approximately four paths per storage subsystem controller.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.