• Introduction to pools

    PDF

    Introduction to pools

    About pools

    A pool is a set of disks that provide specific storage characteristics for the resources that use them. For example, the pool configuration defines the types and capacities of the disks in the pool. For physical deployments, the pool configuration also defines the RAID configurations (RAID types and stripe widths) for these disks.

    You choose which pool to use when you create a new storage resource.

    Before you create storage resources, you must configure at least one pool. You cannot shrink a pool or change its storage characteristics without deleting the storage resources configured in the pool and the pool itself. However, you can add disks to expand the pool.

    Pools generally provide optimized storage for a particular set of applications or conditions. When you create a storage resource for hosts to use, you must choose a pool with which to associate the storage resource. The storage that the storage resource uses is drawn from the specified pool.

    If there are multiple disk types on the system, you can define multiple tiers for the pool. In physical deployments, each tier can be associated with a different RAID type.

    Storage tiers

    The storage tiers available for both physical and virtual deployments are described in the table below.

    • For physical deployments, the storage tier is associated with the physical disk type.
    • For virtual deployments, the storage tier is associated with the virtual disk's underlying characteristics and must be manually assigned.
    • For both types of deployments, if FAST VP is installed on the system, you can create tiered pools to optimize disk utilization. A tiered pool consists of multiple disk types, such as SAS Flash 2 disks and SAS disks.
    SAS Flash 3 disks must be used in a homogeneous pool.
    Table 1. Storage tier descriptions
    Storage tier
    Disk types
    Description
    Default RAID configuration (physical deployments only)
    Extreme Performance tier
    Solid state extreme performance disks. The following types are supported:
    • SAS Flash 2
    • SAS Flash 3
    Provides very fast access times for resources subject to variable workloads. For example, databases can achieve their best performance when using SAS Flash disks. SAS Flash disks are more expensive than SAS disks per GB of storage.
    Only SAS Flash 2 disks can be used in the FAST Cache and with FAST VP.
    RAID 5 (4 + 1).
    Performance tier
    SAS - Rotating performance disk
    Provides high, all-around performance with consistent response times, high throughput, and good bandwidth at a mid-level price point. Performance tier storage is appropriate for database resources accessed centrally through a network.
    RAID 5 (4 + 1).
    Capacity tier
    NL-SAS - Rotating capacity disk
    Provides the highest storage capacity with generally lower performance. Capacity storage is appropriate for storing large amounts of data that is primarily static (such as video files, audio files, and images) for users and applications that do not have strict performance requirements.
    For data that changes or is accessed frequently, capacity tier storage has significantly lower performance.
    RAID 6 (6 + 2).

    Optimizing disk performance using the FAST Cache and FAST VP (supported physical deployments only)

    The FAST (Fully Automated Storage Tiering) Suite includes features that enable you to:

    • Leverage SAS Flash 2 drives as additional read/write cache for improved performance (FAST Cache).
    • Dynamically tier data across different types of disks (FAST VP).
    Comparison of FAST Cache and FAST VP

    The following table describes the differences between the FAST Cache and FAST VP features:

    Table 2. Differences between the FAST Cache and FAST VP features
    FAST Cache
    FAST VP
    Enables SAS Flash 2 drives to be used as an additional read/write cache for the storage system.
    Leverages pools to provide sub-LUN and file system tiering, which moves data to the appropriate tier based on the FAST VP tiering policy.
    Caches 64-KB data chunks for higher performance.
    Relocates 256-MB data chunks based on the FAST VP tiering policy and I/O activity.
    Copies data from Hard Disk Drives (HDDs) to Flash drives when the data is accessed frequently.
    Moves data between different storage tiers based on the FAST VP tiering policy.
    Adapts continuously to changes in workload.
    Uses a data relocation process to periodically make storage tiering adjustments. The data relocation schedule is configurable, and the data relocation can take place once a day or on an ongoing basis throughout the day.
    Interoperability considerations

    You can use FAST Cache and FAST VP functionality together to yield high performance and improve Total Cost of Ownership (TCO) for the storage system. EMC recommends that you:

    1. Use available SAS Flash 2 drives for the FAST Cache first, because this can benefit all storage resources in the storage system.
    2. Supplement performance as needed by adding additional SAS Flash 2 drives to pool tiers for use by FAST VP.

    For example, in scenarios where limited SAS Flash 2 drives are available, you can use SAS Flash 2 drives to create the FAST Cache, and you can apply FAST VP on a one- or two-tier pool (SAS and NL-SAS). From a performance point of view, FAST Cache dynamically provides performance benefits to bursts of data, while FAST VP moves "hotter" data to performance disks and "colder" data to capacity disks. From a TCO perspective, FAST Cache, with a small number of Flash drives, serves the data that is accessed most frequently, while FAST VP optimizes disk utilization and efficiency.

    The FAST Cache feature is storage-tier-aware and works with FAST VP to make sure that the storage system resources are not wasted by unnecessarily copying data to FAST Cache, if it is already on a Flash disk. If FAST VP moves a chunk of data to the Extreme Performance Tier on a pool, the system will not copy that chunk of data into FAST Cache, even if FAST Cache criteria is met for promotion. This ensures that the storage system resources are not wasted in copying data from one Flash disk to another.

    Pool best practices

    Create multiple pools to:

    • Separate workloads that have different I/O profiles. For example, create one set of pools for workloads that are mostly sequential and another for workloads that are mostly random.
    • Separate pools for block and file storage resources.
    • Dedicate pools to meet specific performance goals.
    • Vary pool parameters, such as enabling the FAST Cache on one pool but not on another pool.
    • Minimize failure domains. For example, although unlikely, loss of a RAID group in a pool can compromise the total capacity of that pool. As a result, for physical deployments, you may want to create multiple smaller pools rather than use the total available capacity in a single pool.
    Capacity considerations

    It is recommended that you leave free physical space in a pool to accommodate data services, as described in the following table.

    Table 3. Pool capacity considerations
    Service
    Recommendation
    Snapshots
    Maintain about 10% free space to buffer snapped writes.
    FAST VP
    Maintain at least 10% free space to accommodate the fastest rebalancing.
    Snapshots and FAST VP together
    10% free space will meet the requirements of both.
    File systems
    File systems share pool space with their snapshots. They also share space with LUNs, if the pool is shared. Follow these recommendations:
    • Do not oversubscribe space in a pool that contains file systems.
    • Ensure that the pool has sufficient capacity to cover the maximum size of all file systems, their snapshots, and the LUNs sharing the pool.

    Best practices for configuring storage tiers

    The number of tiers required in a pool is influenced by performance requirements, capacity requirements, and the knowledge of the skew between active and inactive capacity. (Skew is when a small percentage of the total storage capacity in a storage system is the target for the majority of the IOPS served by the system.) Best performance is achieved when the entire active dataset can be contained within the capacity of the Extreme Performance (Flash) and Performance (SAS) tiers.

    If the skew is known, the capacity per tier should be sized accordingly. Otherwise, follow these general guidelines for configuring storage tiers:

    • When the FAST Cache is available, use a 2-tier pool comprised of SAS and NL-SAS disks. Enabling the FAST Cache as a cost-effective way of realizing Flash performance without dedicating Flash to the pool. You can add a Flash tier later if the FAST Cache does not fully capture the active data.
    • Using a 2-tier pool comprised of Flash disks and SAS disks as an effective way to provide consistently good performance. You can add NL-SAS disks later on, if there is uncertainty about the active data fitting in the Flash tier. Avoid using a 2-tier pool of Flash and NL-SAS if there is uncertainty about the active data fitting in the flash tier.
    • For a 3-tier pool, start with 5% Flash, 20% SAS, and 75% NL-SAS. This works on the assumption that less than 25% of the used capacity will be active and relocations from the lowest tier will be infrequent. You can expand the tiers later, if needed.
    • The Performance tier provides a buffer for active data not captured in the Flash tier. It provides modest performance, as well as a quicker promotion to Flash when relocations occur.
    • Add a Flash tier to a pool with thin LUNs so that metadata is promoted to Flash disks. This improves overall performance.

    Spare disk policy (physical deployments only)

    The storage system uses permanent hot sparing to replace a disk that has failed or faulted. Any unused disk in the system with the appropriate disk technology and size can be used to replace a failed or faulted disk in a pool. Most of the disk configurations require the use of hot sparing, except for the following:

    • If the system has only 8 disks in total, and they are of the same type, you can configure RAID 6 (6+2) with no hot spare.
    • If the system has only 12 disks in total, and they are of the same type, you can configure RAID 6 (10+2) with no hot spare.
    When you create or expand pools for a disk configuration, the system prevents you from configuring all available disks, so as to leave some disks as spares.

    The spare disk policy follows these rules to determine how many disks are left as spares:

    • In general, the system reserves one spare disk for every group of 1-30 disks that have the same type, capacity, and rotational speed (or Flash type). For example, if there are 40 300-GB, 15K-RPM SAS disks in the system, the system reserves two of those disks as spares.
    • The system does not reserve a spare disk for:
      • The FAST Cache.
      • A system disk, unless it has user data on it.
    • Any unused non-system disk can become a spare disk.
    • A system disk that does not contain user data can be a spare disk for a failed system disk that has user data.
    • A spare disk can be used to replace a failed or faulted disk in the FAST Cache.
    • When a spare disk swaps into a pool, it becomes a permanent member of that pool and cannot be used in another pool.
    • When a broken disk is fixed or replaced, it can be a candidate for a spare disk or used in another pool.

    Refer to the compatibility and interoperability documentation on the support website for a listing of basic platform and component support for the storage system, including capacity limits.

    Automatic snapshot deletion

    Automatic snapshot deletion is a space management feature used to automatically manage the number of snapshots in a pool. This feature is triggered when the total pool consumption or pool consumption by the snapshots reach a high threshold you define. The system automatically starts deleting old and expired snapshots until the pool space reaches a set threshold.

    Expired snapshots are deleted first. If deleting the expired snapshots does not still result in reaching the thresholds, the system starts deleting the detached oldest snapshots with the automatic deletion option enabled. Automatic deletion does not apply to snapshots attached to hosts, including attached groups of snapshots on a consistency group. It also does not apply to system snapshots used for replication.

    You can set a snapshot of a storage resource for automatic deletion when the snapshot expires (by setting a snapshot expiration date) or the associated pool reaches the auto delete threshold settings. The following table explains the automatic snapshot deletion options:

    Table 4. Automatic snapshot deletion options
    Options
    Description
    Pool
    Applies to snapshots of storage resources and pools. When the pool reaches a certain threshold, the system automatically deletes the snapshot.
    Expiration time
    Applies to snapshots of storage resources. This is the time when the snapshot expires.

    About RAID groups (physical deployments only)

    Redundant array of independent disks (RAID) is a method for providing high levels of storage reliability by arranging disks in groups, and dividing and replicating data among the disks in a group.

    A RAID group is a set of disks with the same capacity and redundancy on which you create one or more storage resources. For example, when you create a storage resource in a RAID 5 group, data is distributed equally across the disks in the RAID group. The following illustration shows a five-disk RAID 5 group with three LUNs:

    Figure 1. Five-disk RAID 5 group with three LUNs
    An illustration that shows a five-disk RAID 5 group with three LUNs.

    RAID groups usually have the characteristics of parity, striping, or both:

    • Parity provides redundancy for blocks of data on the disks. Depending on the RAID type, this provides the ability to continue to operate with the loss of one or more disks.
    • Striping provides a mechanism for processing data that allows the comprehensive read/write performance of a RAID group to exceed the performance of its component disks.

    You select disk types and RAID configurations (RAID types and stripe widths) for a pool. The system then creates one or more RAID groups for the pool, based on the specified configuration. For example, assume there is one storage tier in the pool. Using the five-disk RAID 5 example shown above, the system would create the pool with a single RAID 5 (4+1) RAID group. If you want to create the pool with more than five disks, you must do so in increments of five. Alternatively, you can select the Maximum Capacity option, which optimizes based on number of disks selected and may create multiple RAID groups of the same RAID type but different stripe widths.

    If there are unused disks of different types, you can configure multiple storage tiers for the pool and can specify a different RAID configuration for each tier.

    Once a pool is configured, you cannot change the RAID type of a tier. However, you can add a new tier with a different RAID type.

    The system supports RAID 5, 6, and 1/0 (also called RAID 10).

    RAID configurations (physical deployments only)

    Pool tiers are built using a set of one or more individual disk groups based on the tier's RAID type and stripe width. The RAID type determines the performance characteristics of each disk group. The stripe width determines the fault characteristics of each disk group.

    For example, a RAID 5 disk group can still operate with the loss of one disk. A RAID 5 (4+1), 5 disk configuration has less risk of multiple disk faults than a RAID 5 (12+1), 13 disk configuration.

    For best performance from the least number of drives, match the appropriate RAID level with the expected workload. The following table describes the supported RAID types for the intended storage usage:

    Table 5. Supported RAID levels
    RAID level
    Description
    RAID 1/0 (also called RAID 10)

    Best suited for applications with fast or high processing requirements, such as enterprise servers and moderate-sized database systems. Provides both high performance and reliability at medium cost, while providing lower capacity per disk.

    RAID 1/0 requires a minimum of two physical disks to implement, where two disks are mirrored together to provide fault tolerance. A RAID 1/0 configuration can continue to operate as long as 1/2 of each mirrored disk pair is healthy.

    For example, if you have a RAID (2+2) configuration, you can lose two disks, as long as they are not the source and mirror of the same mirrored pair. If you lose both the source and mirror of the same mirrored pair, you must immediately replace the disks and rebuild the array.

    • RAID 1/0 (1+1): A minimum of two disks can be allocated at a time to a pool, with one used strictly for mirroring. One disk out of every two is an exact duplicate of the other, and the usable disk capacity for every two-disk group is approximately one disk (50%). This RAID configuration is equivalent to RAID 1.
    • RAID 1/0 (2+2): A minimum of four disks can be allocated at a time to a pool, with two used strictly for mirroring. Two disks out of every four are exact duplicates of the other, and the disk usable disk capacity for every four-disk group is approximately two disks (50%). In addition, this configuration is striped to improve I/O performance.
    • RAID 1/0 (3+3): A minimum of six disks can be allocated at a time to a pool, with three used strictly for mirroring. Three disks out of every six are exact duplicates of the other, and the disk usable disk capacity for every six-disk group is approximately three disks (50%). In addition, this configuration is striped to improve I/O performance.
    • RAID 1/0 (4+4): A minimum of eight disks can be allocated at a time to a pool, with four used strictly for mirroring. Four disks out of every eight are exact duplicates of the other, and the disk usable disk capacity for every eight-disk group is approximately four disks (50%). In addition, this configuration is striped to improve I/O performance.
    A failure of a mirrored pair in a RAID 1/0 disk group will render any storage in the RAID group unavailable until the failed disks are replaced and the data is restored. This may cause data loss since the last backup of the pool.
    RAID 5

    Best suited for transaction processing and often used for general purpose storage, as well as for relational database and enterprise resource systems. Depending on the disks used, this RAID type can provide a fairly low cost per MB while still retaining redundancy.

    RAID 5 stripes data at a block level across several disks and distributes parity among the disks. No single disk is devoted to parity. Because parity data is distributed on each disk, read performance can be lower than with other RAID types.

    RAID 5 requires all disks but one to be present to operate. If a disk fails, it will reduce storage performance and should be replaced immediately. Data loss will not occur as a result of a single disk failure.

    • RAID 5 (4+1): A minimum of five disks can be allocated at a time to each pool. The usable capacity for every five-disk group is approximately four disks (80%).
    • RAID 5 (8+1): A minimum of nine disks can be allocated at a time to each pool. The usable capacity for every nine-disk group is approximately eight disks (89%).
    • RAID 5 (12+1): (Not for general use) A minimum of 13 disks can be allocated at a time to each pool. The usable capacity for every 13-disk group is approximately 12 disks (92%). This configuration should only be used when lower data protection characteristics are acceptable.
    A failure of two disks in a RAID 5 disk group will render any storage in the RAID group unavailable until the failed disks are replaced and the data is restored. This may cause data loss since the last backup of the pool.
    RAID 6

    Best suited for read-biased workloads, such as archiving and backup to disk.

    RAID 6 is similar to RAID 5, but includes a double parity scheme that is distributed across different disks and thus offers extremely high fault- and disk-failure tolerance. RAID 6 also provides block-level striping with parity data distributed across all disks.

    The pool will continue to operate even when up to two disks fail. Double parity provides time to rebuild the RAID group, even if another disk fails before the rebuild is complete.

    • RAID 6 (6+2): A minimum of eight disks can be allocated at a time to each pool. The usable capacity for every eight-disk group is approximately six disks (75%).
    • RAID 6 (8+2): A minimum of 10 disks can be allocated at a time to each pool. The usable capacity for every ten-disk group is approximately eight disks (80%).
    • RAID 6 (10+2): A minimum of 12 disks can be allocated at a time to each pool. The usable capacity for every 12-disk group is approximately 10 disks (83%).
    • RAID 6 (14+2): A minimum of 16 disks can be allocated at a time to each pool. The usable capacity for every sixteen-disk group is approximately fourteen disks (88%).
    A failure of three disks in a RAID 6 disk group will cause data loss and render any storage in the RAID group unavailable until the failed disks are replaced and the data is restored. This may cause data loss since the last backup of the pool.
    Mixed RAID configurations

    If FAST VP is installed on the system, you can create a pool with multiple storage tiers. Each tier can have its own RAID type. Only one RAID type can be used within a tier, but the tier can have different stripe configurations. For example, you can mix RAID 5 (4+1) and RAID5 (8+1) in a tier. To do this:

    • Select the Maximum Capacity RAID configuration when you create the pool. This configuration might mix RAID types in the pool.
    • Expand the pool using a different stripe width than currently exists in the pool.

    Disk IOPS by RAID type (physical deployments only)

    Front-end application workloads translate into different back-end disk workloads based on the RAID type in use. For front-end reads, there is no impact by RAID type: 1 front-end read I/O equals 1 back-end read I/O.

    The following table shows the impact by RAID type for random front-end writes.

    Table 6. IOPS by RAID type for front-end writes
    RAID type
    IOPS per 1 front-end write I/O
    RAID 1/0
    2 back-end write I/0s
    RAID 5
    2 back-end reads and 2 back-end writes
    RAID 6
    3 back-end reads and 3 back-end writes