RE: P7 V7R3 to P9 V7R3 migration recommendations / suggestions

["Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>]

I found the biggest problem on restores on our R&D LPAR is not disk, nor tape, but the rebuild of access paths for LF in x-lib.
We have many.
Normally these restores are done off hours, so  no impact to users.
But when done during 8-5, the programmers do see a large impact.
It will be an interesting test once the P9 is in place, how the idx path rebuilds perform.

Our current R&D P7 LPAR currently does have some NWS hosted from Production LPAR with no impact on production. 

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Thursday, November 01, 2018 4:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: P7 V7R3 to P9 V7R3 migration recommendations / suggestions

This might not be 100% true on a restore for a guest LPAR depending on how
a lot of stuff is configured.
- Is the tape drive configured directly to the guest by moving the card or
is the drive being provided by being virtualised. I am guessing the card is
being moved in this [particlar case as if there are four drives involved
and it's a library it can't be virtualised for the guest anyway.
- The disk being restored to is a storage space built over physical disk
and made available to the guest via PowerVM so there will be an overhead
for the hosting system serving the disk as well as the logical disk on the
guest. This overhead will be different to just writing to a physical disk
on a system.
- The NWSD might not perform as well as a physical adapter so it might be
worth assigning some memory and configuring a storage pool to help
performance, even if it's only for the restore. This needs to be done up
front as the memory can't be added to the NWSD dynamically. memory added to
an NWSD kind of acts a little like a dedicated cache as far as I understand
it.

I probably wouldn't host 3 LPARs in a production LPAR, but I have hosted
DEV LPARs in production systems in the past. if there is just one and it is
not too busy (i.e. not too much disk IO) then it generally works OK but the
devs on a really busy system will notice it and the prod users might too,
for instance during restore and things like PTF updates on the guest.

These are just thoughts, the CPU on the newer machines seems to brute force
a lot of pre-conceived concerns assigned if there is sufficient CPU and
memory.

On Fri, Nov 2, 2018 at 9:25 AM Rob Berendt <rob@xxxxxxxxx> wrote:

> Performance has five things involved:  disk, memory, processor and tape
> and the fifth being the cabling, SAN, I/O port going to the tape.  Let's
> assume that one saves access paths, it's been changed to the default many
> releases ago.
> In a restore the biggest constraint will be tape, then disk.  It takes an
> awful lot to stress the connection speed to the tape library.  Memory and
> processor concerns follow behind.
> We're talking about tape libraries with multiple drives in them.  One at a
> time or four at once should not matter to the tape library, since you have
> multiple drives.
>
> The biggest reason for the semi restricted state is that you don't want
> users on it trying to do stuff during a full system restore.  Not really
> to speed up the restore, but it probably helps.
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   "Musselman, Paul" <pmusselman@xxxxxxxxxxxxxxxx>
> To:     "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> Date:   11/01/2018 04:10 PM
> Subject:        RE: P7  V7R3 to P9  V7R3 migration recommendations /
> suggestions
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> What's the system overhead difference between a single-threaded restore in
> restricted state vs 4-at-a-time in mostly restricted?
>
> I know the system has to read the library header from the tape, then spend
> a lot of time allocating space.  In fully-restricted state it doesn't have
> to check for any kind of conflict, and just grabs space then restores
> data.  In mostly-restricted, you have 4 jobs grabbing for space.
>
> What's the tipping point between the two?
>
> Or has faster system hardware overcome the conflict?
>
> Paul E Musselman
> PaulMmn@xxxxxxxxxxxxx
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate
> link: https://amazon.midrange.com
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate
> link: https://amazon.midrange.com