AIX > Administrator > Systems Management

Storage Recommendations for AIX: What’s the Best LUN Size?

LUN Size
What’s the best LUN size? This is a tricky question and I think all of us have asked it once or twice in our careers. This is a really important question, taking into consideration that normally the storage administrator and the AIX administrator prefer to have fewer LUNS, which is easier to manage. In addition, we’ve lost some control over the storage configuration and the complexity with the SAN environment is increased because we are using software multipathing, FC switches, and storage servers with huge amount of cache memory, just to name a few. For all the above reasons, we normally prefer having fewer LUN devices. In this article, I’ll explain the most important considerations and recommendations when talking about the LUN size. In a future article, I’ll discuss the queue depth parameter and its performance impact.
A Hypothetical Situation
First of all, in order to answer that question, I want to say the answer to that question depends on the IOPS performance requirement. To illustrate, imagine that you’re going to need 10 Terabytes for your new database system. On the one hand, you could think: I’m going to create 10 LUNs and each of these LUNs are going to be 1 TB, and additionally I’m going to spread all the data over these 10 LUNs. The question here is: Is this configuration going to work? Probably yes. From the AIX standpoint, you wouldn’t have any kind of problem. Furthermore, if you’re using a XIV or V7000 storage servers, you’re going to be able to manage that amount of data per LUN. In this scenario, you can use 10 LUNs of 1 TB size each of them.
On the other hand, consider this: I’m going to use 50 LUNs with 200GB size each of these LUNs. The question again is: is this configuration going to work? Definitely, it’s going to work.
The key point here is that if you’re going to use more IOPS with more LUNs, since more LUNs will mean more hdisk drivers threads, which can have a performance impact. Therefore, if you’re going to need more throughput and more I/O operations, give thought to using more LUNs. Having more LUNs means more parallelism from the AIX OS standpoint.
One of most important recommendations when sizing your LUNs is to work in conjunction with your application vendor. For example, if I were installing a Db2 database server, one of the best strategies is to gather the application requirements and recommendations from my database administrator in regard to the LUN size. Eventually, the database administrator might tell me that he or she prefers to go with 50 LUNs with 200GB in size each of them, since the IOPS requirements for this new database are pretty high.
Another aspect that’s worth taking into consideration is to read the documentation for your storage server. From my experience, it’s beneficial to read the host attachment guide or host connectivity guide for the storage server that I’m using because they contain best practices and the suggested troubleshooting process between the storage server and the most common OSes, including AIX. Additionally, these documents may provide you some guidance on how to properly size your LUNs devices for the most common commercial application such as Db2. For instance, if you’re using a XIV storage server, try reading the IBM XIV Storage System: Host Attachment Redbook. In this document, you’ll find a Db2 best practice section to help you to size your LUNs and data layout recommendations for Db2.
Finally, it’s strongly suggested to work in conjunction with your storage vendor and gather information about your storage server resources. To illustrate, it’s not the same using a XIV latest generation storage server or using V7000 with flash disk technology than using an old DS4000 storage equipment. Moreover, it’s really important to gather recommendations in regard to the LUN size with storage administrator. For instance, the XIV storage server is able to manage 1 Terabyte LUN size with no problems, thanks to its grid architecture, this storage server is optimized to use all drive spindles for each volume. Therefore, the XIV can work properly with 1 TB LUN size. In this scenario, the storage administrator might prefer to have fewer LUNs, because my storage box is able to manage huge amount of data per LUN.
In conclusion, there’s no magical answer where there are two of choices: one large LUN or multiple smaller LUNs. The actual answer really depends on the application requirements and your storage settings. In any case, it’s always beneficial to work in conjunction with your application vendor and your storage vendor to gather recommendations about the LUN size and IOPs requirements. Keep in mind, more LUNs represent more IOPs and more kernel I/O threads from the AIX standpoint and additionally reduce the risks of getting QUEUE FULL status of the device. The queue_depth attribute and its performance impact is something that I want to discuss in a next article, due to the fact that this is one configuration parameter where we still have some control over the performance for the storage server platform and it dictates to some degree the maximum concurrency for each hdisk device.  
IBM System Storage DS8000 Performance Monitoring and Tuning
IBM System Storage DS8000 Host Attachment and Interoperability
IBM XIV Storage System Host Attachment and Interoperability
IBM FlashSystem A9000, IBM FlashSystem A9000R, and IBM XIV Storage System Host  Attachment and Interoperability
IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines

comments powered by Disqus



2018 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


How to Download Fixes


Understand your options for 12X PCIe I/O drawers

clmgr: A Technical Reference

PowerHA SystemMirror 7.1 introduces a robust CLI utility

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters
not mf or hp