va7100 LUN creation

[Ernest Small]

I'm configuring a va7100 on an N-class. This will be used to analyze core dumps (very large). What would be the best LUN configuration for the va7100? Is there any optimal configuration to handle large files and directories. Also, I plan on using the full array (approx. 742 GB), what would be your optimal configuration for VG's and lvol's?

Thanks in advance!!

[Eugeny Brychkov]

You can create LUN(s) as large as possible (even one big), the question is will OS support it (and how to tune kernel variables to use this big one - q. to hpux section)? Use VA controller 1 as a primary path, C2 only for failover
Eugeny

[Michael Steele_2]

Bigger is usually better but this is one consideration in the overall scheme of things. File system block size for example can be made larger for faster through put, and a round robin PV Link scheme together with striping is often used.

I'm confused about Eugeny comment about C1 and C2. Eugeny, do you want all the reads and writes going through C1? Is this the two I/O port per one processor problem? Doesn't the best performance comes from properly load-balancing the I/Os across even and odd LUNs.

[Roger_22]

Hmmm, there is more to this than you would think. As far as the LUNs go, the array can reach maximum performance with a single LUN per RG. The 7100 has only one RG, so one LUN is ok??? assuming the application/system will generate sufficient concurrency on that LUN. For large sequential workload, a concurrency level of 2 or 3 will be sufficient. Normally, I???d suggest that if you???re unsure of your applications ability to create concurrency on a single LUN, then create multiple LUNs and stripe the LUNs. But, in this case I think it would be best if there were only one big LUN. If you do create multiple LUNs, concatenate them, don???t stripe them. That???s the easy part.

The issue will be with the large sequential write case. In AutoRAID mode, with the array close to full, you???ll either get good write performance, or really poor write performance. It???s hard to predict. The issue is with the log-structured writes. The VA, in the AutoRAID setting, will use log-structure RAID 5DP writes for a sequential write workload. Log-structured writes will provide good performance as long as there is contiguous free-space in the array. In theory, this workload will be ok. The free space will be created, as the data blocks are re-written (this is the reason I don???t want you to stripe the LUNs). The data will be allocated sequentially.

I???d also recommend you only allocate LUNs for 700GB. This will give the array more opportunity to have contiguous free space.

I also don???t think you???ll see much value in load balancing on the fibre channel/controllers.

Make sure you have HP18 firmware, and Prefetch Enabled (armmgr ???P On), and normal resiliency (armmgr -J Normal).

After the system is setup and running, look at the armperf ARRAY output. Verify that your system is using large >64K IOs. If not, track down why.

Let me know how it turns out.

[Vladimir Vybiral]

Hmm, there is even more to Roger than it seems - all correct. Just to answer shortly the load balancing no-better statement, and Redundancy groups - each LUN is owned by one redundancy group, which is controlled by one controller only (You don't want two controllers writing different data into the same disk block at the same time, right?). As it has been said , 7100 has one redundancy group only, so all writes that come into the C2 will be bypassed internally and processed by C1 anyway. The good news on the other side is, that C2 has a mirrored copy of cache in C1 and in the event of failure becomes RG1 "master" without any loss - that is why use failover...

[Ernest Small]

Thanks for all of your replys. I'm still unsure what would be the best route although it seems like creating 1 LUN per VG would be best. I was planning on making 2 vg's at about 350gb each, do you think 1 lun per vg would be best. As far as the applications and what the system will be used for, the core dumps will transfered using FTP. The core dumps will then be anaylyzed with tools such as Q4, kwdb, P4, etc. In talking to some people in my lab they suggest that large file blocks would be better for writing the data to disk but smaller block sizes would be better for reading data. Do I sacrifice one for the other or look for a happy medium? Thanks again for ll of your replies, they are very helpful.

[Roger_22]

Gee only 5 points for that last answer. I though it was worth at least 8??????

You want a direct answer, well ok. Here it is. It depends. It depends on characteristics of your workload that you haven???t described ??? and possible you don???t know. So, try a configuration, and see how it works. Then modify it if necessary. Try the one LUN plan. After you???ve run the real workload for a couple of weeks, look at the performance logs. They will tell you the information you need if you decide to modify the system.

[Vincent Fleming]

Since you are writing files that arriving via FTP, (ie: slow connection compared to FC), then smaller blocksizes sound appropriate because it would give you better read performance.

-Vince