This is the fourth part of the series covering the process of creating a Disk Magic model for open systems. This post will provide a deeper discussion on the modeling of the target solutions that are under consideration.
At this stage, it is assumed that a good base for the intervals of interest have been created, and this is where we actually start making predictions for how the target solution will behave when put into the customer's environment.
The first step to create your models is to identify the configurations you desire to make predictions against. Then use Capacity Magic to provide a good overview of the target configuration in terms of usable capacity.
Disk Magic is a performance prediction tool, so capacity requirements don't have to be very restrictive as in Capacity Magic. However, the actual active spindle count, raid type and size is very important. The same applies to interface counts and speeds.
Depending on the level of detail desired, you may also need to have a plan for how the available disks will be deployed – pool layouts, and which workloads profiles go to each pool.
Also, keep in mind that when modeling the workloads, all the disk magic assumptions and limitations come into play. To mention some of the most common things to consider:
Disk Magic does not model the impact of Flash Copy
Disk Magic does not model cross site replication directly (need manual workaround to do so)
Disk Magic assumes that all workloads are evenly spread across the resources allocated to them.
If the specifications for the systems defined, you can use the main dialog to select the desired disk system model from the supported hardware. This can be easily done through the dialog pictured below.
Remember that for some disk systems - V3700, V5000, XIV and DS8000 - you may need to adjust the cache size as well the amount of FC ports via the interface and Open Disk tab.
The additional details about the simulated disk system can be completed through the other tabs and buttons in this dialog. The workload profile will be the same used to create the base of this model. Disk Magic will automatically adjust the cache and other workload parameters that are affected by the new Disk System choice once you click on the Solve Button.
When all the disk system configuration have been inputed into Disk Magic, just click on the Solve Button and Disk Magic will update the numbers to match the results predicted in the configuration being simulated. Next click the History Button and rename the new entry with a title that will be easy to identify.
Once all the configurations under consideration are simulated, you can go back to the History Button and identify the options that will be documented and generate the results charts. The other options can be deleted to simplify the documenting step in the process.
That sounds simple, however, there are considerations to be taken into account when modeling some scenarios which use some disk systems and/or functionalities.
Let us take a look at some specific scenarios that can be tricky to model in Disk Magic:
XIV with SSD Read Cache:
The SSD read cache technology in the XIV disk systems allows great improvement in the response time and scalability of the XIV systems when compared to a system that does not include the SSDs. But keep in mind that the SSD cache is designed to improve small random read I/O – up to 64KB. It does not provide additional benefit for other types of I/Os.
Typically, when modeling a solution that ingested utilization data coming directly from a Disk System, all I/Os in the system are averaged out into a single I/O profile. When this happens, it is quite common for the average block size of the MB/s peak interval to be bigger than 64K. Then any XIV simulations will not indicate any benefits for the use of SSDs during these intervals.
A few ways to work around this potential problem is:
Look for the highest throughput interval that the block size is smaller than 64K and model it in addition to the usual intervals models. Keep in mind that odds are that your predictions for the intervals with I/Os bigger than 64K are extremely conservative in this case, and looking at the extra interval can be useful to give you an idea on the full potential of the SSDs for the big blocks intervals.
If early enough in the process, consider using server side data – this is potentially harder to capture than Disk system level. This way you will have a workload profile for each server, and you will be able to better understand the impact of the SSD in the models, specially for the throughput peak.
Disk Magic allows the creation of models that take advantage of EasyTier for the systems that support the technology. However, there are some considerations when modeling a solution that will leverage Easy Tier.
The impact of Easy Tier in a model depends highly on how skewed the workload distribution is. A heavily skewed workload has a large number of I/Os on a small portion of the data, which means that even moving a few extents onto faster hardware will greatly improve performance. For lightly skewed workloads, there is a much smaller difference in the intensity on the busiest extents versus the least active extents, which yields a much smaller performance improvement.
Disk Magic represents this skew as a number called the Skew Level. The Skew Level can be determined in several ways. Unfortunately, most of the time the process to determine the Skew Level requires specific Disk Systems to be installed alongside matching tools to be in place during data capture.
The consequence for the analysis is that most of the time you will use the the predefined Skew Levels in your simulations. These predefined Skew Levels can be related to the fraction of the I/O allocated to the fast tier in comparison to the capacity of sad tier. The picture below indicates the five predefined Skew Levels ratio of I/O percentage X Capacity percentage
In the chart above, the Intermediate skew curve (the green one) indicates that for a fast tier capacity of 20% Easy Tier would move 79% of the I/Os to the fast tier. These skew curves are developed by IntelliMagic – the developers of Disk Magic. The parameters of the curves and the predefined Skew Levels were chosen after researching data from medium and large sites.
To enable Easy Tier you just have to click on the Easy Tier Settings button from the General tab where you will be presented with a dialog that will allow you to enable Easy Tier and choose the Skew Level – if you have a calculated value, you can use it. As a rule of thumb, if you can not get enough details about the workload skew to match the workload characteristics to one of the predefined curves, we recommend using the default value presented to you by Disk Magic. As a rules of thumb, IBM recommends to specify between 3 to 10% of total usable capacity in SSD for the Easy-Tier Pool.
Once you have defined your workload and activated Easy-Tier for your model, you can quickly generate a graphic in Disk magic to simulate each Skew based on your actual config. By creating this graphic, you will visualized the impact of Easy-Tier Skew level and how critical this field can affect your customer proposal. Choosing the wrong skew level can provide result that may vary up to 800% and more.
To create such a graphic, just select the option “For each predefined Easy-Tier Skew Level”, select the right configuration from your History list and Plot your graphics.
The generated graphic will look like this one.
Last but not least, using the Report button in the General tab allows you to visualize the I/O assigned to each tier in your model. The result will be something similar to:
Real Time Compression:
Current version of Disk Magic supports Real Time Compression (RtC) for both V7000 and SVC environments with Version 7.1 and 7.2 of the code. To enable RtC in you model go to the General Tab and activate the check button.
However, you want to keep in mind that the current implementation of RtC modeling in Disk Magic is an All or Nothing approach. In other words, it is not possible to select only a fraction of the workload to be compressed and have the rest uncompressed.
Additionally, not all workloads are friendly to compression. Details about good candidates to RtC can be found in the following paper Real-time Compression in SAN Volume Controller and Storwize V7000 (http://www.redbooks.ibm.com/abstracts/redp4859.html?Open). Disk Magic assumes that the workload being modeled is Compression friendly.
Another important parameter of the RtC modeling process is the Compression percentage. It is a number that indicates how compressible the data is – 0% represents um-compressible data, while 99% indicates that each 1GB of data will only take 10MB of actual physical storage. The default value is 50%, however it is pretty easy and quick to obtain a good estimate by running the Comprestimator utility (http://www-304.ibm.com/webapp/set2/sas/f/comprestimator/home.html).
It is a good idea to avoid modeling RTC for environments that only have a 50% compression ratio or lower since it will tax some resources very heavily. It is also recommend to isolate indiviudal workloads and start compression with workloads that have a high compression ratio as a the first steps of implementation.
Next, how to document your results.