Collecting Information
The purpose of collecting information is to help understand and pinpoint what is causing the performance problem in the storage side. For example, details about I/O characteristics help analyze the CPU performance of a controller more accurately and efficiently. Information that needs to be collected includes the types of services served by the storage system, I/O characteristics, and storage resource plan.
Service Types and I/O Characteristics
- Service types include Oracle database OLTP and OLAP, VDI, and Exchange mail services. Analyzing service types helps determine whether you should pay attention to the IOPS or bandwidth and whether a low latency is required.
- I/O characteristics include the I/O size, read/write ratio, cache hit ratio, and hotspot data distribution. You can use SystemReporter to observe I/O characteristics. Analyzing I/O characteristics helps understand whether the current service mainly involves sequential or random I/Os, large or small I/Os, and read or write I/Os.
Storage Resource Plan
You can use OceanStor DeviceManager or the Information Collection function of SmartKit to collect information about the storage resource plan. In addition to the product model and software version of the storage system, a storage resource plan includes the following:
- Interface modules
For example, the number of interface modules and front-end and back-end port connections must be basically the same for each controller. This ensures load balancing among multiple controllers, preventing the situation where one controller is overloaded but other controllers have light loads.
- Types and number of disks
SSDs provide the highest random small I/O performance and they do not outperform HDDs in the bandwidth capability. In a resource plan, SSDs are used to serve applications that involve random small I/Os, and SAS or NL-SAS disks are used to serve applications that involve large I/Os or bandwidth-sensitive applications.
- Number of front-end and back-end interface modules and number of connections
In a bandwidth-sensitive scenario, the number of modules on the back-end interface must adequately support the bandwidth capacity required by those at the front-end interface, to enable optimal performance.
- Allocation of disk domains and storage pools, including the number of disks in each disk domain, the owning relationship of storage pools, and the stripe size
Resource allocation must be in direct proportion to the service pressure. The storage pool with the heaviest load must be created and borne in the disk domain that consists of the most number of disks. That is, there are the same types or similar configuration ratios among the disks. In other words, SSDs must be allocated to the disk domain that has the heaviest load. In a storage pool that contains multiple tiers, the LUN that has the heaviest load must be allocated to the high-performance tier or the performance tier. If SmartPartition is configured, sufficient cache resources must be reserved for the LUN that has the heaviest load.
- LUN properties and space distribution, such as whether a LUN is thin or thick, its working controller, and the pertaining capacity percentage on each layer
- Value-added feature configuration, for example, whether snapshot, clone, remote replication, and SmartTier are configured
Value-added features involve more performance processes. On the one hand, a large number of metadata operations (such as initial LUN space allocation and formatting) are performed. On the other hand, a lot of non-host I/Os may be generated (for example, remote replication records and deletes data differences).