FAST VP in Unity Storage: How It Works

9 min


Today we will talk about an interesting technology implemented in Unity / Unity XT storage systems – FAST VP. If you first heard about Unity, then the link at the end of the article can be found on the characteristics of the system. As part of the Dell EMC project team, I have been working on FAST VP for over a year. Today I want to talk about this technology in more detail and disclose some details of its implementation. Of course, only those that are allowed to reveal. If you are interested in the issues of efficient data storage or just haven’t completely figured out the documentation, then this article will certainly be useful and interesting.


I must say right away about what will not be in the material. There will be no search for competitors and comparisons with them. I also do not plan to talk about similar technologies from open source, because a curious reader already knows about them. And, of course, I’m not going to advertise anything.

Storage Tiering. Goals and objectives of FAST VP

FAST VP stands for Fully Automated Storage Tiering for Virtual Pool. Is it complicated? Nothing, now we’ll figure it out. Tiering is a way of organizing data storage, in which there are several levels (tiers) where this data is stored. Each has its own characteristics. The most important: the performance, volume and cost of storing a unit of information. Of course, there is a relationship between them.

An important feature of tiering is that access to data is provided uniformly, regardless of what level of storage they are currently at, and the pool size is equal to the sum of the sizes of the resources included in it. There are differences from the cache: the size of the cache is not added to the total amount of the resource (pool in this case), and the cache data will duplicate some piece of data on the main medium (or will duplicate if the data from the cache has not been written yet). Also, the distribution of data by levels is hidden from the user. That is, he does not see what kind of data is located at each level, although he can influence it indirectly by setting policies (about them later).

Now let’s look at the features of the implementation of storage tiering’s in Unity. Unity distinguishes 3 levels, or tier’s:

  • Extreme performance (SSDs)
  • Performance (SAS HDD 10k / 15k RPM)
  • Capacity (NL-SAS HDD 7200 RPM)

They are presented in decreasing order of performance and price. Extreme performance includes exclusively solid state drives (SSDs). The other two tier’s are magnetic disk drives, which differ in speed of rotation and, accordingly, in performance.

Storage media from one level and one size are combined into a RAID array, forming a RAID group (RAID group, for short – RG); available and recommended RAID levels can be found in the official documentation. From RAID groups from one or several levels storage pools are formed (Storage pool), from which then free space is allocated. And already from the pool space is allocated for file systems and LUN’s.

Why do I need Tiering?

In short and abstract: to achieve greater results using a minimum of resources. More specifically, then the result is usually understood as a set of characteristics of storage systems – speed and access time, cost of storage, and others. By a minimum of resources is meant the least cost: money, energy, and so on. FAST VP just implements data redistribution mechanisms at different levels in Unity / Unity XT storage systems. If you believe me, you can skip the next paragraph. For the rest I’ll tell you a little more.

The correct distribution of data by storage levels allows you to save on the total cost of storage by sacrificing access speed to some rarely used information, and increase productivity by moving frequently used data to faster storage media. Here, someone may argue that even without tiering’s, the normal administrator knows where to put what data, what desirable characteristics of storage for his task, etc. This is undoubtedly true, but manual data distribution has its drawbacks:

  • It takes time and attention of the administrator;
  • It’s not always possible to “redraw” storage resources for changing conditions;
  • an important advantage disappears: unified access to resources located at different storage levels.

To make storage administrators less worried about job security, I’ll add that competent resource planning is also necessary. Now that tiering’s tasks are briefly outlined, let’s see what you can expect from FAST VP. Here is the time to return to the definition. The first two words – Fully Automated – literally translate as “fully automated” and mean that the distribution of levels occurs automatically. Well, Virtual Pool is a data pool that includes resources from different storage levels. Here’s what it looks like:

image

Looking ahead, I will say that FAST VP moves data only within one pool, and not between multiple pools.

Tasks FAST VP solves

Let’s talk abstractly first. We have a pool and some mechanism that can redistribute data inside this pool. Remembering that our task is to achieve maximum performance, we ask ourselves: in what ways can it be achieved? There can be several of them, and here FAST VP has something to offer the user, since the technology is something more than just storage tiering. Here are some ways FAST VP can increase pool performance:

  • Distribution of data by different types of disks, levels
  • Distributing data among drives of the same type
  • Pool expansion data distribution

Before analyzing how these tasks are solved, we need to know some necessary facts about the work of FAST VP. FAST VP operates with blocks of a certain size – 256 megabytes. This is the smallest continuous “chunk” of data that can be moved. In the documentation it is called: slice. From the point of view of FAST VP, all RAID groups consist of a set of such “pieces”. Accordingly, all I / O statistics are accumulated for such data blocks. Why is this block size chosen and will it be reduced? The block is large enough, but this is a compromise between the granularity of the data (smaller block size – more precisely the distribution) and available computing resources: under the existing strict restrictions on RAM and a large number of blocks, these statistics can take up too much, and the number of calculations will increase proportionally.

How FAST VP places data in a pool. Politicians

To control the placement of data in a pool with FAST VP enabled, the following policies exist:

  • Highest Available Tier
  • Auto tier
  • Start High then Auto-Tier (default)
  • Lowest Available Tier

They affect both the initial placement of the block (data was first recorded) and the subsequent redistribution. When the data is already located on the disks, the redistribution will be initiated according to the schedule or manually.

Highest Available Tier is trying to place the new unit at the most productive level. With a lack of space on it – at the next performance level, but then the data can be moved to a more productive level (if there is space or crowding out other data). Auto-Tier places new data at different levels depending on the size of available space, and they are redistributed depending on demand and free space. Start High then Auto-Tier is the default policy and also recommended. At initial placement, it works as the Highest Available Tier, and then data is moved depending on their usage statistics. The Lowest Available Tier policy seeks to place data at the least productive level.

Data transfer is carried out with a low priority so as not to interfere with the useful work of storage, however there is a setting “Data relocation rate”, which changes the priority. There is a peculiarity: not all data blocks have the same sequence of redistribution. For example, blocks marked as metadata will be moved to a faster level first. Metadata is, so to speak, “data about data”, some additional information that is not user data, but stores its description. For example, information in the file system about which block a particular file is in. This means that the speed of access to data depends on the speed of access to metadata. Given that metadata is usually much smaller in size, more is expected to benefit from moving to more productive disks.

Criteria that Fast VP uses in work

The main criterion for each block, if very rough, is the characteristic of the “demand” of the data, which depends on the number of reads and writes of the data fragment. This characteristic is called “Temperature”. There is hot data that is hotter than unclaimed. It is calculated periodically, by default with an interval of one hour.

The temperature calculation function has the following properties:

  • In the absence of I / O, the data “cools” over time.
  • With a load more or less the same in time, the temperature first rises and then stabilizes in a certain range.

Further, the policies described above and the free space on each tier’s are taken into account. For clarity, I will give a picture from the documentation. Here, red, yellow and blue colors indicate blocks with high, medium and low temperature, respectively.

image

But back to the tasks. So, we can begin to analyze what is being done to solve the problems of FAST VP.

A. Distribution of data by different types of disks, levels

Actually, this is the main task of FAST VP. The rest, in a sense, are derived from it. Depending on the policy selected, data will be distributed across different storage tiers. First of all, the placement policy is taken into account, then the block temperature and the size / speed of the RAID groups.

For Highest / Lowest Available Tier policies, everything is quite simple. For the other two, this is the case. At different levels, the data is distributed taking into account the size and performance of the RAID groups: so that the ratio of the total “temperature” of the blocks to the “conditional maximum performance” of each RAID group is approximately the same. Thus, the load is distributed more or less evenly. More demanded data is transferred to fast carriers, rarely used – to slower ones. Ideally, the distribution should be something like this:

image

B. Distribution of data among disks of the same type

Remember, at the beginning I wrote that information carriers from one or more levels are combined into one pool? In the case of a single level for FAST VP, there is also work. To maximize performance at any level, it is advisable to distribute data evenly between disks. This will allow (in theory) to get the maximum number of IOPS. Data inside a RAID group can be considered evenly distributed across disks, but between RAID groups this is far from always the case. In the event of an imbalance, FAST VP will move data between RAID groups in proportion to their size and “conditional performance” (in numerical terms). For clarity, I will show a rebalancing scheme among three RAID groups:

image

B. Distribution of data during pool expansion

This task is a special case of the previous one and is performed when a RAID group is added to the pool. So that the newly added RAID group does not stand idle, part of the data will be transferred to it, which means that the load on all RAID groups will be redistributed.

SSD wear leveling

By using wear leveling, FAST VP can extend the life of an SSD, although this feature is not directly related to Storage Tiering. Since we already have temperature data, the number of write operations is also taken into account, we can move data blocks, it would be logical for FAST VP to solve this problem.

If the number of records in one RAID group significantly exceeds the number of records in another, then FAST VP will redistribute the data in accordance with the number of write operations. On the one hand, this removes the load and saves the resource of some disks; on the other hand, it adds “work” for less loaded ones, increasing overall performance.

Thus, FAST VP takes on the traditional tasks of Storage Tiering and does a little more than that. All this allows you to effectively store data in the Unity family of storage systems.

Some tips

  1. Do not neglect reading the documentation. There are best practices, and they work pretty well. If you follow them, then serious problems, as a rule, do not arise. Other tips basically repeat or supplement them.
  2. If you configured and enabled FAST VP, it is best to leave it on. Let him distribute the data in the time allotted for him and a little more than once a year and having a serious impact on the performance of other tasks. In such cases, the redistribution of data may take a long time.
  3. Be careful when choosing a relocation window. Although this is obvious, try to choose the time with the least load on Unity and allocate a sufficient period of time.
  4. Plan your storage expansion, do it on time. This is a general recommendation, which is important for FAST VP as well. If the amount of free space is very small, then the movement of data will slow down or become impossible. Especially if you neglected paragraph 2.
  5. When expanding a pool with FAST VP enabled, you should not start with the slowest disks. That is, we either add all the planned RAID groups at once, or first add the fastest drives. In this case, redistributing data to new “fast” disks will raise the overall pool speed. Otherwise, starting with “slow” drives, you can get a very unpleasant situation. First, data will be transferred to new, relatively slow disks, and then, when faster ones are added, in the opposite direction. There are nuances associated with different FAST VP policies, but in general a similar situation is possible.

If you look closely at this product, then you can try Unity in business for free by downloading Unity VSA virtual appliance.

At the end of the article, I share a few useful links:

Conclusion

I would like to write a lot, but I understand that not all the details will be interesting to the reader. For example, you can tell more about the criteria by which FAST VP decides to transfer data, about the processes of analyzing I / O statistics. Also, the topic of interaction with Dynamic pools, and this draws to a separate article. You can even dream up on the development of this technology. I hope it was not boring, and I did not bore you. See you soon!


0 Comments

Leave a Reply