× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Kenneth,

I've had similar issues with CEC devices in the past, also not all hot swappable.
P5 hot swappable
P6 not sure.
P7 NOT hot swappable.
P8 has improved

The CEC imbedded controllers also always had a performance hit.

My current P7 CEC is empty, because of this.
I'm currently running dual 5913 for production (100% SSD), a second set of 5913 for R&D (100% 10k spinny),
I have the pair split in separate 5877, each 5877 on a different loops, for redundancy.
I just did a 100% production disk swap of 18 SSD (EXP24s 5887) to 13 775 SSD, migrated the load source, and added hot spare, minimal down time.
Load source can be in any slot in the EXP24S.
Load source placement rules for IBM i logical partitions

http://www-01.ibm.com/support/knowledgecenter/POWER7/p7hat/iphati5osloadsrcplacemnt.htm?cp=POWER7%2F1-8-2-2-5-3-2-0
http://www-01.ibm.com/support/knowledgecenter/POWER8/p8hat/p8hat_i5osloadsrcplacemnt.htm?cp=POWER8%2F1-7-1-2-1-5-3-2-0


I ditto everyone else's numbers for SSD performance.
Shutdown - 5 minutes.
IPL - 5 minutes.
PTF apply - 5 minutes.
V7R1 OS upgrade from an DSLO image - 30 minutes

All processes significantly faster, system saves, daily saves, large batch jobs, everything.

I only use the CEC for my "playground" LPAR, performance is terrible, base controller combined with 10 k spinny drives.

Paul





-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Monday, March 16, 2015 3:39 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Load Source Placement - Best Practices.

Kenneth,

You can add far more reliable devices at the controller and storage device layer to your list.
Also: SSDs are so much faster for the type of workload like an IPL or other OS layer operations. Larry and I both posted some stats earlier. Include in those operations SAVE operations. You could potentially cut the restricted state save operations by quite a bit by A) moving the load source to a controller that does not control the tape, and B) the speed of data transfer is higher. SAS will outrun SCSI most anytime.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Graap, Kenneth
Sent: Monday, March 16, 2015 1:43 PM
To: Midrange Systems Technical Discussion
Subject: RE: Load Source Placement - Best Practices.

Are you using VIOS?
Rob Berendt

Not at this time Rob. I'm just looking for some good reasons why it would be advantageous to have load source on SSD.

This is being driven due to a recent "incident" where one of the mirrored load source disk located in the CEC, failed. No big deal usually... but the second mirrored disk threw "noise" on the SCSI bus at the same time, resulting in the system shutting down to protect the data. A system crash occurred!

I want to move away from disk in the CEC. It will take some downtime to do this and I'm looking for IBM or industry leader testimony that it is a good idea to spend time and money on. This would make it easier to convince management that the downtime is justified...

What can I say... They won't take my advice alone on this matter. Further documentation, that it is the "best" thing to do would help my cause considerably...

Maybe Sue Baker could give her opinion (???)

My reasons:

1.) Faster access from SSD through modern controller technology (5813 for
example)
2.) Faster access to load source could decrease the IPL time resulting in less downtime.
3.) Dual path protection to the disk would provide better data protection.
4.) Moving away from the older MFIOP technology into newer SAS technology.




Kenneth


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


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.