Re: Who is your go to person for virtual disks?

Patrick,

> If virtual disks of a secondary *OPSYS LPAR reside on a "normal" IBM i ASP, I see no need to have multiple virtual disks for that *OPSYS LPAR in the first place.

To quote captain Ramius of the Red October: "Your conclusions are all wrong..."

Your logic has merit, yes the data in that single virtual disk IS spread by the hosting LPAR. However IBM i was not designed to operate on a single disk unit. As such the I/O queues are not very deep. With just one disk unit you have set yourself up to have very poor performance when I/O begins to rise.

Example, some years ago a business partner who did not know IBM i (they were AIX People) set up a guest *OPSYS LPAR on one of my customer's machines. They built the machine as AIX with a single 1.5 TB disk unit. Performance was beyond horrible as soon as the system got into any workload whatever. A simple CLROUTQ could bring the system to its knees for the duration. I spent a VERY long weekend migrating them to have many virtual disks.

So the recommended configuration here is to start with 6 disk units at a minimum and for larger systems considerably more. Also add additional virtual controllers as I/O load rises.


> The ASPBAL of that hosting LPAR is spreading data evenly between physical disks. No need to have some CPU (IOP?) calculate spreading twice (for virtual and then real storage). It's all virtual.

Again the logic here is correct but the conclusions are again wrong. If you have disks that are very full and one that is very empty all new writes go to the empty one. That empty one then for the next period of time will be filling and filling with hot data and can easily become an I/O bottleneck for the same reason as above.

Add and Balance. Add and Balance. Add and Balance.

> Multiple virtual disks can happen if the ASP space of that said LPAR is filling up and the easiest countermeasure is to add another virtual disk. But even then, I see no need to do STRASPBAL on virtual storage besides "admin's feeling better".

See above answer and add that you should keep the virtual disk at the same size. If you created them as 70GB then continue that. Size doesn't much matter so long as they are the same. THis way I/O loads per disk are mostly kept even and queueing won't slow you down.

Add and Balance. Add and Balance. Add and Balance.

FYI ALL of this logic applies to SAN storage as well.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 3/23/2020 8:47 AM, Patrik Schindler wrote:

Hello Rob,

Am 23.03.2020 um 13:34 schrieb Rob Berendt <rob@xxxxxxxxx>:

I pointed out in a case that I have opened that STRASPBAL *USAGE is not supported on virtual disks and pointed them to this link to back it up:
https://archive.midrange.com/midrange-l/200907/msg00827.html
They replied that the information was from 2009 and therefore worthless.
They said that the TRCASPBAL must have shown little to no difference in usage so the STRASPBAL would have ended ONLY because of that.
I said that the IBM Performance team was on my system and said I needed to do this because the disks were out of balance.
They replied that the system must have balanced itself in the time between the IBM performance teams analysis and the TRCASPBAL.

If virtual disks of a secondary *OPSYS LPAR reside on a "normal" IBM i ASP, I see no need to have multiple virtual disks for that *OPSYS LPAR in the first place: The ASPBAL of that hosting LPAR is spreading data evenly between physical disks. No need to have some CPU (IOP?) calculate spreading twice (for virtual and then real storage). It's all virtual.

Multiple virtual disks can happen if the ASP space of that said LPAR is filling up and the easiest countermeasure is to add another virtual disk. But even then, I see no need to do STRASPBAL on virtual storage besides "admin's feeling better".

I don't know if this scenario applies to you, though.

I guess the same applies to VIOS hosting LPARs in a way, but since I've never used that before, I can't tell for sure.

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc