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





The encryption is done in hardware (firmware) on the library (TS3500 w/18 LTO4 drives all fiber attached). This is not hitting the iSeries CPU. However, I can't totally rule out the overhead difference in not encrypting QSYS lib.


Douglas Hart - Principal Consultant






-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Massiello
Sent: Friday, October 01, 2010 11:28 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Backup Performance

It sounds like you are doing software Encryption, and that is VERY VERY CPU intensive. So, it would make sense that on your smallest partitions (those without a lot of CPW), it would improve the backup time.

Pete

Pete Massiello
iTech Solutions
http://www.itechsol.com

Add iTech Solutions on Facebook:
http://www.facebook.com/group.php?gid=126431824120
Add iTech Solutions on LinkedIn: http://www.linkedin.com/groups?gid=2206093


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Hart, Doug - EI
Sent: Friday, October 01, 2010 10:03 AM
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: Backup Performance





We have always done a full system save (like opt 21) on the weekends using BRMS. For sometime now we have been encrypting our tapes via our LTO4 tape
library. These were always done in Restricted State. Well we talked with
our auditors and got the OK to not encrypt the OS and other IBM ("Q...") libraries. This greatly helps simplify the restore of the system (we do practice D/R). We only need to encrypt our company's data. So we have modifyed our BRMS control groups again so now we save (encrypted) all of the *ALLUSR and IFS 1st. What I did differently is code (API) a step that ends all active subsystems EXCEPT QCTL for the encrypted save. Then we go restricted and get the remainder of the system.

OK, if you followed me so far here is the question. We have a number of LPARs on several systems. All at v5r4 and using fiber to the tape library.
Our backups are running faster and we're not sure why. The most dramatic
change has been on our smaller partitions, ones with little CPU and memory allocated. I'm talking ½ the outage window, 12 hours down to 6 hours. My 1st thought was maybe the difference in not going down to an actual Restricted State was the *SHRPOOL memory was being better allocated to the backup job. But this doesn't seem to be the case. Remember that only QCTL is running and BRMS is still doing the save.

I talked with Support Line work management and didn't get much. They suggested using the Flight Recorder to monitor the backups. They looked at this differently, saying that maybe the old procedure was slower than it should have been and we just corrected some long standing issue in our shop.
We have double checked the backups and we are getting everything, it's not like we are only saving half of or systems.

So, anyone out there want to offer a suggestion as to why our outage window is so much improved?








Douglas Hart - Principal Consultant





________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
--
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 ...

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.