Shulou(Shulou.com)06/01 Report--

Recently, I learned about Dell Compellent series storage and made some notes.

Generally speaking, this is an enterprise storage, which is suitable for a variety of application scenarios. However, by looking up some information on the Internet, it is found that the white wall of this series of storage is slightly flawed, which can be summarized in the following aspects:

RAID Scrub (RAID error correction)

Distortion may occur when data is written to disk or after it is stored on disk. Therefore, all storage will run background processes to correct data errors. This is the RAID Scrub mechanism: the controller reads the disk data block periodically, uses the check data to check the correctness of the disk data block, and if the data block error is found, the storage will automatically correct it. In the process of error correction, the read IO of the disk will be very high. On the other hand, the running priority of the RAID Scrub background process of Dell Compellent is higher than that of the business end, that is to say, no matter how busy the business is, RAID Scrub needs to be given priority. In many cases, there is a conflict between the business IO request and the RAID Scrub process, and the delay of the business IO is very large. Moreover, the run time of Dell Compellent's RAID Scrub process cannot be intervened by users, which is an important reason for the poor performance of Dell Compellent.

Data layering (Data Progression)

Data layering is a good mechanism to improve performance, but Dell Compellent data layering also has an important defect. When the on-demand (on-demand) tiering policy is enabled, when some HDD data is accessed massively by the host, the data will become hot data, and the hot data blocks will be migrated to SSD. However, during the migration process, the host side is also waiting for the access result of these data. Because the priority of the hierarchical migration is higher than the business side access, the host side access can only wait for the migration to be completed.

Multipath mechanism

The multi-path mechanism of storage front-end controller determines the read-write performance and reliability of storage to some extent. The existing front-end controller multi-path mechanisms can be roughly divided into three categories: A/A-S (Active/Acivie-Symmetric), ALUA and Active/Passive.

A/A-S (Active/Acivie-Symmetric) mechanism, for a particular LUN, the target ports of multiple storage controllers are in an active / optimized (Active/optimized) state in its path. High-speed interconnection communication between multiple controllers is realized through PCIe or Infiniband. After sending an IO from the host side to the controller side, multiple controllers can participate in IO processing at the same time; the storage system will automatically load balance, when a controller is busy or the business pressure is high, the storage system can automatically achieve load balancing without the participation of multi-path load balancing software on the host side. This mechanism is widely used in high-end storage.

For the ALUA (Active/Active-Asymmetric) mechanism, in the path group of the controller, only the target port group of one controller is in the active / optimization (Active/Optimized) state, and the target port group of the other controllers is in the active / non-optimization (Active/Unoptimized) state. At a certain time, a specific LUN only belongs to a preferred controller. With the cooperation of multi-path, the IO sends the IO from the preferred control IO group (Active/Optimized), and the multi-path will not send the IO of the LUN to other controllers. Generally, by assigning the LUN A to the controller An and assigning the LUNB to the controller B to achieve load balancing on both sides, the attribution operation can be completed manually or automatically. This mechanism is used in mid-and high-end storage.

Another is the Aamp P (Active/Passive) mechanism, which is generally used only in low-end dual-active storage arrays. This kind of architecture is rare these days. For a specific LUN, the target port of only one controller is active / optimized (Active/Optimized) in the corresponding storage path, and the target port of the other controller is standby or not working at ordinary times, and its load balancing is similar to that of ALUA (that is, determined by the preferred controller), but because multipaths and storage do not know each other (multipaths do not know which paths are preferred) It is difficult for IO to choose a suitable path. It can be said that the distribution of IO depends entirely on the mood of the upper layer of multipath. The solution is to provide self-developed multipath to cooperate with array routing, and to match IO to the preferred path through private protocols. Dell's Compellent uses this mechanism, which brings performance problems. In a four-path physical environment, there are only two paths that can be found for LUN.

If there is a situation where all host ports on Compellent storage fail, but the controller continues to work, then all LUN belonging to that controller will be inaccessible. Because the controller is normal at this time, the storage will not switch the LUN to another controller. At the same time, because the ALUA mechanism is not supported, the host side cannot access these LUN through another controller. A simple way to test this situation is to unplug all the host port cables on a Compellent controller. At this time, some LUN cannot be accessed. Although this situation is relatively rare, it can still happen.

The above part is summarized through online information, I do not have the conditions to demonstrate, so posted to the Internet, if there is any inaccurate please correct.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.