Top Tips for Updating Solaris 11 Systems

We now have quite a bit of experience of IPS and Repositories under our belt. 

Feedback from customers has been extremely positive.  I recently met a customer with 1000+ Solaris servers who told me that with Solaris 10 it took them 2 months to roll out a new patchset across their enterprise.  With Solaris 11, it takes 10 days.

That really helps lower TCO.

As with anything, experience teaches us how to optimize things.  Here's a few Top Tips around IPS / Repo management which I'd like to share with you from my experience with SuperCluster:

  • To avoid most IPS dependency resolution errors, keep your main local Repository populated with all Solaris Updates and SRUs up to and including the version you wish to apply.  A sparsely populated Repo is much more likely to result in copious IPS dependency resolution errors.
  • Keep any IDRs (Interim Diagnostics or Relief) in a separate Repo local to the Boot Environments (BEs) for which they are relevant.  For example, if you have an IDR to address an issue with 11gR2 RAC on Solaris 11.1.7.5.0 (Solaris 11.1 SRU7.5), keep it local to the relevant BEs running 11gR2.  This avoids IDRs being unnecessarily propagated to LDoms or Zones for which they are irrelevant.
  • Before upgrading, check to ensure that the issues addressed in any IDRs you are using are fixed in the Solaris version to which you are updating.  If they are, IPS will automatically supersede them - that is, unlike in Solaris 10, there's no need to manually remove them.  You can check this by looking in the Support repository, or the relevant Repo ISO image, for packages whose base name is the IDR number, that is 'idr<number>'.  If such a package exists, then the IDR has been superseded and the issues it addresses are fixed in that SRU.  If the issues are not fixed in the Solaris version to which you are updating, you may need to ask Support for new IDR(s) for that Solaris version.
  • Zone creation in Solaris 11 works differently to how it did in Solaris 10.  In Solaris 11, effectively a manifest is taken of the Global Zone and then Non-Global Zones (NGZs) are constructed from that using the Repo(s).  Therefore, your Repo(s) must be up to date with all Solaris software installed on your global zone, including any IDRs.  You can have multiple Publishers specified, so that multiple Repos can be used (e.g. main local Repo for the Solaris Updates / SRUs, BE specific Repo for IDRs).

I hope you find these tips useful.

My colleagues, Glynn Foster and Bart Smaalders, will be presenting on "Oracle Solaris 11 Best Practices for Software Lifecycle Management [Con3889]" @ Oracle OpenWorld next week.  The Oracle Sun "Systems" sessions are in the Westin this year.  This particular session is on Tuesday, Sept 24 @ 5:15pm in the "City" meeting room in the Westin and will have lots more tips and best practices.

Other colleagues, Rob Hulme and Colin Seymour, are presenting on "Best Practices for Maintaining and Upgrading Oracle Solaris [CON8255]" on Monday, Sept 23 @ 10:45am in the Westin San Francisco, also in the "City" meeting room.

And there's lots of other good stuff on Solaris and SuperCluster.  For example, the "Deep Dive into Oracle SuperCluster [CON8632]" on Tuesday, Sept 24 @ 5:15pm in the Westin, Metropolitan II.

I'm not presenting this year, but if you would like to meet up with me @ OpenWorld to discuss anything about Solaris / Systems / SuperCluster Lifecycle Maintainence, whether it's ideas you'd like to see implemented, what's keeping you awake at night, issues you want me to look at, etc., I am more than happy to do so.  Just ping me at Gerry.Haskins@oracle.com.

Best Wishes,

Gerry.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog is to inform customers about Solaris 11 maintenance best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. Gerry Haskins, Director, Software Lifecycle Engineering

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today