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