What you suggest will work at first glance, but consider all you have done
with that procedure is maintained the OS and any OEM products in place.
From scratch: Loading LIC and initializing drives takes a bit of time since
it's serial and you already have RAID turned on (don't turn it off)
Loading the OS/Licpgm's 2 maybe three hours. PTFs another hour
Restore user profiles
Restore configuration
Loading the OEM stuff, could be a few hours but we can't guess since we
don't have a list.
Now you have a fresh system with the disk you want configured the way you
want it, and all the foibles of the old system gone, and this has fewer
steps and most likely faster.
Keep the old if you will, but consider a build from scratch gives you a
clean slate.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Wednesday, June 29, 2016 2:16 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using
virtualized SSD from Production LPAR
Jim,
My current ASP1 is 24 571gb 10k spinny, Raid5 , two parity sets, no hot
spare.
My current ASP2 is 30 100gb virtual SSD.
What I really like to do, is flip flop them.
Future ASP1, including load source, 30 100gb virtual SSD Future ASP2, 24
571gb 10k spinny, Raid5 , two parity sets, 1 hot spare.
Not easily achievable.
Majority of my R&D data is easily restorable from Production save.
So I was thinking of deleting all the R&D user data libraries.
Reconfigure the current SSD virtuals from ASP2 to ASP1.
Using STRASPBAL, move remaining data from physical to virtual SSD.
IPL and Migrate the load source.
Remove the 24 physical from ASP 1
Add 24 physicals back in to ASP2.
RSTLIBRM all user libraries to ASP1 or ASP2 as needed.
End result would be R&D load source, i5/OS, LLP, other 3rd party utilities,
and selected R&D libraries that need performance on virtual SSD.
All remaining non-performance libraries would be placed in ASP2 (24 571gb
10k spinny, Raid5 , two parity sets, 1 hot spare) via RSTLIBBRM RSTASP = 2.
This could be done without a complete system restore and possibly only 1
IPL.
Any thoughts from the group?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Oberholtzer
Sent: Wednesday, June 29, 2016 2:46 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using
virtualized SSD from Production LPAR
Build your load source as needed.
Build the other storage devices to the size you need (remembering more
storage devices are better than fewer with 6 as the absolute minimum)
Now the trick to avoid unpleasant issues with the unmatched sizes: Now stop
allocation to the large drive. Life will go on just fine with that one
being read only and all the read write activity on the other storage
devices.
Or my preferred method: Create the partition with the sizes/quantities you
want. Save Restore it into the new environment.
A) It gets it set up the way you want it
B) Tests your recovery plan
C) Sets up all the shared access paths better
D) gives you a chance to clean house a bit.
Downside: takes a while.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Wednesday, June 29, 2016 1:33 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using
virtualized SSD from Production LPAR
I've been informed that if I decide to migrate my load source from current
10k spinny to virtual SSD, I should make the virtual SSD the same size as
my 10k spinnys, which are 571gb.
for performance reasons, all disks in the ASP should be of the same size.
Currently, R&D ASP1 has 24 571gb 10k spinny, Raid5 , two parity sets, no hot
spare.
I would create 1 additional virtual SSD, 571gb, and add it to ASP1.
Bit of a waste of virtual SSD for a load source.
Any thoughts from the group?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Monday, June 27, 2016 10:59 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny) by using
virtualized SSD from Production LPAR
Preliminary performance numbers.
A complicated batch process taking 2 hours on 10k spinny took 53 minutes on
R&D with virtual SSD, equaling or exceeding Production LPAR times.
5 NWSD with 6 100gb NWSSTG each, 30 NWSTG total.
My manager asked if I could somehow improve our R&D test runs to be closer
to Production run times.
I knew the 10k spinny were the issue.
I had extra SSD on Production LPAR which was purchased for a project that
was later cancelled.
I virtualized 3tb of SSD from Production LPAR to R&D LPAR.
The R&D LPAR has a large amount of cold data, 8TB, which would be hard to
cost justify 100% SSD.
On the R&D LPAR, using RSTLIBBRM, restoring to ASP2 , (5 NWSD with 6 100gb
NWSSTG each, 30 NWSTG total). which is the virtual SSD on the client R&D
LPAR, I can control by library which R&D environment needs performance.
I had some other posts about trying to virtualize the 10k load source, but
at this time I do not think this will be necessary.
I've seen this many times over the years with improvements to the DASD
subsystem.
Majority of the time, DASD improvements will result in the largest savings
when it comes to large batch processing.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Holger Scherer
Sent: Monday, June 27, 2016 1:44 PM
To: Midrange Systems Technical Discussion
Subject: Re: Improve R&D LPAR poor disk performance (10K spiiny) by using
virtualized SSD from Production LPAR
For performance - at least 6 NWSSTG per system, max 16 (32?) NWSSTG per
NWSD.
for performance comparison HDD/SDD - absolutely same config (# NWSSTG / NWSD
/ Disk size)
If performance is not *that* issue -> one big NWSSTG is ok ;-)
-h
Am 27.06.2016 um 19:41 schrieb Rob Berendt <rob@xxxxxxxxx>:
I just remember something about 6 or more storage spaces per nwsd.
And if you have a few storage spaces it's better to also have more nwsd's.
Like, instead of maxing out the storage spaces per nwsd, create more
nwsd's.
--
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
