Successfully Modeling and Simulating Systems, Part 2 Page 3 -

Successfully Modeling and Simulating Systems, Part 2 Page 3

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

Phase Two

The second part of the modeling processes is ensuring that the model is accurate. As part of this process, the modeler needs to develop and/or work with someone to develop a methodology for testing the model. This process is commonly known as model calibration. The person developing the tests must have a detailed understanding of how the hardware and/or software work. Take a simple host bus adapter (HBA) as an example. If someone wanted to create a generalized model of a Fibre Channel HBA, they would have to take into account:

  1. 1 Gbit or 2 Gbit interface
  2. Latency through the HBA based on distance to the switch
  3. The number of commands that can be queued in the HBA
  4. How the commands are processed:
    1. Sorted or non-sorted
    2. Number of buffer credits needing writes
    3. Size of the command queue
  5. Number of targets that will be processed in the HBA (LUNs the HBA will be writing to)
  6. Failover issues

As you can see, for a fairly simple piece of hardware you have a great deal of work ahead of you just in modeling the HBA. Add to this the issues to consider for the software stack to the HBA, which include:

  1. Application and type of I/O being done
  2. C library if applicable
  3. System calls
  4. Operating System settings and tunables
  5. File System cache, layout settings, and tunables
  6. Volume manager layout settings and tunables

You can easily see that the complexity of what to test and how to test the various components of the model can be difficult and requires significant expertise.

Developing the tests that can measure each of the individual activities is often very difficult given the interactions that happen within the system between the various hardware and software components parts and services. In most cases, you cannot test a single device by itself; for example, when testing an HBA, even using just the raw device, you will also be testing a disk or RAID.

What I have found works best are reducing the variables and using different hardware. So, for example, when testing an HBA, it might be wise to set up a LUN about the same size as the RAID cache, and tune the cache to try to keep all of the data in cache. This way you reduce the effect of the disks and the RAID performance, and will likely have a more accurate representation of the HBA performance as a result. You can also change the RAID to another RAID type to see if the performance is different.

So in general, it is best to start with the characterization of the smallest and simplest pieces of hardware and software, and then move on to the more complex parts. The key to any characterization project is an understanding in reasonable detail of how the component being characterized works. In most cases, you really do not completely know how it is going to work, so you can expect to have a few surprises from the model, and you can expect to gain a great deal of insight into the inner workings of the project.

Page 4: Phase Three - Model Maintenance

Page 3 of 4

Previous Page
1 2 3 4
Next Page

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Storage Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that may send you ENTERPRISEStorageFORUM offers via email, phone and text message, as well as email offers about other products and services that ENTERPRISEStorageFORUM believes may be of interest to you. ENTERPRISEStorageFORUM will process your information in accordance with the Quinstreet Privacy Policy.

Thanks for your registration, follow us on our social networks to keep up-to-date