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.
midrange.com
