OceanStor V500R007 Performance Monitoring Guide
Understanding the LUN Performance
Information on LUN types and how they affect performance helps in the identification and location of problems in the storage system.
Performance Differences Between a Thin and Thick LUNs
Storage systems support SmartThin. When this function enabled, a thin LUN can be created. With a thin LUN, storage resources are dynamically allocated based on the host's utilization level. In contrast, a thick LUN will be allocated with the full amount of storage resource, regardless of the host's utilization level. A thin LUN and thick LUN differ in read and write performance.
Write Performance
- First write: At the first write, the performance of a thick LUN is higher than that of a thin LUN. A thick LUN is formatted immediately after it is created. Therefore, only host I/Os need to be written. When new data is written to a thin LUN, spaces are allocated at the same time, leading to a lot of metadata I/O read and write operations. In addition, the write process is longer, and disks face extra pressure. In this case, the performance of a thick LUN is better than that of a thin LUN.
- Overwrite: Both thin and thick LUNs receive pre-allocated spaces in the overwrite process. Therefore, no extra overhead is generated, and the two types of LUNs provide similar performance.
Read Performance
- Sequential read: A thin LUN provides storage resources on demand and its space allocation is not consecutive in terms of time. When a thick LUN is being created, storage resources are automatically allocated at a time based on the configuration, which ensures that space mapped to a disk is consecutive. The efficiency of sequential read on HDDs is higher. Therefore, a thick LUN provides a higher performance level than a thin LUN.
- Random read: In this scenario, the access addresses are not consecutive. Therefore, the two types of LUNs provide similar performance.
To query the LUN type, use OceanStor DeviceManager or run the CLI command.
- In OceanStor DeviceManager, go to the LUN property page to view the LUN type.
![]()
- On the CLI, run show lun general to query the LUN type.
admin:/>show lun general lun_id=0 ID : 0 Name : 000_Report_LUN001 Pool ID : 0 Capacity : 5.000GB Subscribed Capacity : 5.187GB Protection Capacity : 0.000B Sector Size : 512.000B Health Status : Normal Running Status : Online Type : Thick IO Priority : Low WWN : 6111545100326912061d0d4500000000 Exposed To Initiator : No Data Distributing : 97,3,0 Write Policy : Write Back Running Write Policy : Write Through Prefetch Policy : Intelligent Read Cache Policy : Default Write Cache Policy : Default Cache Partition ID : -- Prefetch Value : -- Owner Controller : 0A Work Controller : 0A Snapshot ID(s) : -- LUN Copy ID(s) : -- Remote Replication ID(s) : -- Split Clone ID(s) : 0 Relocation Policy : Highest Available Initial Distribute Policy : Automatic SmartQoS Policy ID : 0 Protection Duration(days) : 0 Has Protected For(h) : 0 Estimated Data To Move To Tier0 : 0.000B Estimated Data To Move To Tier1 : 0.000B Estimated Data To Move To Tier2 : 0.000B Is Add To Lun Group : No Smart Cache Partition ID : -- DIF Switch : No Remote LUN WWN : -- Disk Location : Internal LUN Migration : -- Progress(%) : -- Smart Cache Cached Size : 0.000B Smart Cache Hit Rage(%) : 0 Mirror Type : -- Thresholds Percent(%) : -- Thresholds Switch : --
Local Access to LUNs
To protect the system, ensure that LUNs can be accessed by the local controller.
Local Access
Local access to a LUN means that I/Os destined for a LUN are directly delivered to the owning controller of that LUN. As shown in Figure 4-7, a host is physically connected to controller A, the owning controller of LUN 1 is controller A, and that of LUN 2 is controller B.
- When the host attempts to access LUN 1, controller A directly delivers the access requests to LUN 1. Such a LUN access mode is called local access.
- When the host attempts to access LUN 2, the access requests are first delivered to controller A. Then, controller A forwards them to controller B through the mirror channel between controllers A and B. Finally, controller B delivers the access requests to LUN 2. Such a LUN access mode is called peer access.
The peer access scenario involves the mirror channel between controllers. The channel limitations affect LUN read/write performance. To prevent peer access, you must ensure that a host has a physical connection to both controllers A and B. If a host is physically connected to only one controller, set the owning controller of the LUN to the one connected to the host.
Ping-Pong Effect
In a clustered multipathing network environment, UltraPath is able to automatically switch over the working controller of a LUN. When two application servers attempt to access the same LUN whose owning controller is controller A:
- If a link connected to application server 1 fails as shown in Figure 4-8, the UltraPath running on application server 1 switches the working controller of the LUN to controller B.
- If the two links connected to application server 2 work properly, both controllers of the LUN are the same. The UltraPath of application server 2 will attempt to switch the working controller of the LUN to controller A, and then UltraPath of application server 1 will switch it back to B. As a result, the switching between the two application servers will continue to recur.
This is called the Ping-Pong effect, which reduces the LUN access performance and makes I/O timeout likely occur on application servers.
If the Ping-Pong effect occurs in a storage system, take the following measures:
- Disable the automatic LUN switchover function of UltraPath. For details, see the UltraPath User Guide of the corresponding version.
- Recover the interrupted link as soon as possible. Ensure that the link between each node and each storage controller is up.