EMC SMI-S Agent ETL - Terminology and Computation Methods Simply Explained

Symmetrix and VNX systems terminology explained. Computation methods used by EMC SMI-S Agent ETL for BMC TrueSight Capacity Optimization.

Related Topics

Introduction

The storage terminology and computation methods used in the ETLs developed by Sentry Software for BMC TrueSight Capacity Optimization have been standardized to cover all the different storage manufacturers’ concepts. As a result, the information provided by EMC Unisphere and by the EMC SMI-S Agent ETL may differ.

The objective of this article is therefore to explain the differences in terminology for both Symmetrix and VNX systems and the computation methods used by EMC SMI-S Agent ETL for BMC TrueSight Capacity Optimization.

EMC Symmetrix - Terminology and Computation Methods Explained

This section describes the difference administrators may notice between the amount of storage configured for use and the amount the host can see for EMC Symmetrix storage systems.

From an Allocation Point of View

In this example, we have an EMC Symmetrix Storage System with 205TB of capacity. This value is reported in BMC TrueSight CO by the ST_CAPACITY metric and is the sum of the “Total Managed Space” in Disk groups.

To allocate storage, we first look at the three existing disk groups (ST_POOL_TYPE metric):

  • (1) SATA Disk Group with 100TB of capacity, of which 60TB are consumed and 40TB are available
  • (1) FC Disk Group with 50TB of capacity, of which 20TB are consumed and 30TB are available
  • (1) EFD Disk Group with 15TB of capacity, of which 5TB are consumed and 10TB are available.

Which means that:

  • 85TB are consumed capacity. This value is reported in BMC TrueSight CO by the ST_CONSUMED_CAPACITY metric and is the sum of the space consumed in the capacity allocated from storage pools. For Thin Pools, it corresponds to the Host used capacity (excluding RAID overhead); for Traditional Pools and Disk Groups, it corresponds to the System used capacity (including RAID overhead).
  • 80TB are available capacity in storage pools. This value is reported in BMC TrueSight CO by the ST_AVAILABLE_IN_STORAGE_POOLS metric and is the sum of the remaining managed storage space in the different disk groups.
  • 120TB are available capacity. This value is reported in BMC TrueSight CO by the ST_AVAILABLE_CAPACITY metric and is the sum of the capacity available in storage pools (ST_AVAILABLE_IN_STORAGE_POOLS) and for storage pools (ST_AVAILABLE_FOR_STORAGE_POOLS).

Disk groups are then split into Data Devices and RAID configuration is applied. In our example, we created RAID 1 and RAID 6 (6+2) data devices of 256GB each.

These Data Devices had later been combined to create the following thin pools:

  • (1) SATA Thin Pool of 29.9TB. This value corresponds to the Storage Pool Capacity
  • (1) FC Thin Pool of 16TB.
  • (1) EFD Thin pool of 4TB.

From a Host Usage Point of View

Now that storage has been allocated by administrators, let’s see how this configuration is seen at the host level.

In our example, two thin volumes have been created:

  • Thin Volume A which is bound to and allocated from the SATA Thin Pool
  • Thin Volume B which is bound to EFD Thin Pool but its capacity (10TB) is allocated from the three available thin pools. Indeed, a volume can be bound to a single pool and be allocated from several.

The "consumed capacity" and "available capacity" of a thin volume is equal to the amount of data (capacity) used by the host. For Thin Volume A, 2.4TB have been consumed from the 4TB visible capacity. For Thin Volume B, 6TB have been consumed from the 10TB visible capacity.

At the thin pools level, the capacity information can be represented as follows:

  • Because the pool to which the volume is bound gets the full “host visible capacity” for that volume included in its “subscribed capacity”, SATA Thin Pool has 4TB of subscribed capacity and 3.4TB of consumed capacity.
  • Because Thin Volume B is attached to Thin Pool EPD, its host visible capacity (10TB) corresponds to the subscribed capacity of the thin pool.

EMC CLARiiON/VNX - Terminology and Computation Methods Explained

This section describes the difference administrators may notice between the amount of storage configured for use and the amount the host can see for EMC CLARiiON/VNX storage systems.

From an Allocation Point of View

In this example, we have an EMC CLARiiON Storage System with 142TB of capacity. This value will be reported in BMC TrueSight CO by the ST_CAPACITY metric and is the sum of the "Total Managed Space" in RAID groups/Storage Pool and the capacity available for RAID Groups / Storage Pools. (ST_AVAILABLE_FOR_STORAGE_POOLS).

To allocate storage, we first combined groups of physical disks to form the following RAID Groups and Storage Pools:

  • (1) RAID-1 with 50TB of capacity, of which 30TB are consumed and 20TB are available
  • (1) RAID-5 (4+1) with 40TB of capacity, of which 16TB are consumed and 24TB are available
  • (1) RAID-5 (4+1) with 12TB of capacity, of which 4TB are consumed and 8TB are available

Which means that:

  • 50TB are consumed capacity. This value is reported in BMC TrueSight CO by the ST_CONSUMED_CAPACITY metric and is the sum of the space consumed in the capacity allocated from storage pools. For Thin Pools, it corresponds to the Host used capacity (excluding RAID overhead); for Traditional Pools and Disk Groups, it corresponds to the System used capacity (including RAID overhead).
  • 52TB are available capacity in storage pools. This value is reported in BMC TrueSight CO by the ST_AVAILABLE_IN_STORAGE_POOLS metric and is the sum of the remaining managed space in the different RAID groups/Storage Pools.
  • 102TB are available capacity. This value is reported in BMC TrueSight CO by the ST_AVAILABLE_CAPACITY metric and is the sum of the capacity available in storage pools (ST_AVAILABLE_IN_STORAGE_POOLS) and for storage pools (ST_AVAILABLE_FOR_STORAGE_POOLS).

Note: RAID overhead is added on creation of a RAID Group / Storage Pool. A RAID Group / Storage Pool of size 1TB of type RAID-1 will result in a 2TB reduction in ST_AVAILABLE_FOR_STORAGE_POOLS, a 1TB increase in ST_AVAILABLE_IN_STORAGE_POOLS and a 1TB reduction in ST_CAPACITY / ST_AVAILABLE_CAPACITY.

From a Host Usage Point of View

Now that storage has been allocated by administrators, let’s see how this configuration is seen at the host level.

In our example, four volumes have been created:

  • (1) Traditional Volume mapped to the RAID Group One. Its consumed capacity is equal to the Host visible capacity, including system overhead.
  • (1) Thin Volume A mapped to the RAID Group One.
  • (1) Thin Volume B mapped to the Storage Pool Two.
  • (1) Thin Volume NAS mapped to the Storage Pool Three.

Note: Thin Volumes must be mapped to a host for their capacity to be considered as “used”.

At the RAID groups and storage pools levels, the capacity information is represented as follows:

RAID Group/Storage Pool Capacity Information
  • Its Consumed Capacity (3.4 TB) is calculated by summing up the consumed capacity of the Traditional Volume 1 (1TB) and of the Thin Volume A (2.4TB).
  • Its Subscribed Capacity (5TB) corresponds to the host visible capacity of the Traditional Volume 1 (1TB) and the Thin Volume A (4TB).
  • Its Consumed Capacity corresponds to the consumed capacity of the Thin Volume B (6TB).
  • Its Subscribed Capacity corresponds to the subscribed capacity of the Thin Volume B (10TB).
  • Its Consumed Capacity corresponds to the consumed capacity of the Thin Volume NAS (2TB).
  • Its Subscribed Capacity corresponds to the subscribed capacity of the Thin Volume NAS (3TB).