Wednesday Aug 15, 2012

SPARC SuperDuperCluster

Hi Folks!

Some of you may have noticed that I've been a little quieter than usual in the last year.

Is it because I've lost interest in patching, maintenance best practices, and improving our customers' lifecycle experience ?  Not a bit of it.

It's because my team and I have been rather busy - to put it mildly! - on developing the installation configuration utilities and maintenance updates for SPARC SuperCluster.

SPARC SuperCluster is so good, and the feedback from the already substantial customer base has been so positive, that I'm lobbying Marketing to rename it SPARC SuperDuperCluster.

Available in half rack (2 T4-4s, 3 Exadata Storage Cells) or full rack (4 T4-4s, 7 Exadata Storage Cells) configurations, both of which have a general purpose 7320 ZFSSA (ZFS Storage Appliance) and 3 Infiniband Switches, SPARC SuperDuperCluster is the prime example of the integrated Oracle Red Stack at its best.

It is a true example of an Engineered System, engineered with enhancements at every layer of the Red Stack to improve performance, robustness, and quality, from the phenomenal performance of the SPARC T4 chips, through to the excellent LDoms (Logical Domains) virtualization layer, enhancements such as RDSv3 support in Solaris as well as all the other great feature of Solaris 11 (and 10), to leveraging the phenomenal performance of Infiniband, Exadata Storage Cells and the 11gR2 database.

Seemingly paradoxically, SPARC SuperDuperCluster is both a highly flexible General Purpose "app" consolidation platform and an Engineered System, offering a wide variety of optimized configurations with various combinations of 11gR2 database domains, Solaris 11 General Purpose "app" domains, and Solaris 10 General Purpose "app" domains.

But how can SPARC SuperDuperCluster be both an Engineered System and offer extremely flexible configurations at the same time ?  That's easy.  The hardware layer and cabling is fixed in an optimized fashion (Engineered).  But what apps a customer chooses to run on SuperCluster, on how many LDoms and what memory/CPU is allocated to each is up to them, optimized for their needs (Flexible), rather than a one-size-fits-none approach.

SPARC SuperDuperCluster is more than just the hardware and software.  It's also the extraordinary cross-organizational team that has been built around it.  From the absolute cream of Services, Support, and Sustaining, to the architects and management from Performance Technologies, to the cooperation and deep engagement between engineering teams for each layer of the Oracle Red Stack, to my own small but extremely dedicated install configuration utility and maintenance update team, it's the people behind SPARC SuperDuperCluster which ensure its success. 

Feedback from the rapidly growing customer install base worldwide is extremely positive.  To find out more, please see the SPARC SuperCluster resource page.  You'll be hearing lots more about SPARC SuperDuperCluster at Oracle Open World this year - wow, it's nearly that time of year again! - but, for once, I won't be presenting myself.

I will be there and available to meet/talk either about Solaris 10 Patching, Solaris 11 SRUs (Support Repository Updates), or SPARC SuperDuperCluster.  I look forward to seeing you there!

Best Wishes,

Gerry.

Tuesday Nov 24, 2009

Do not apply packages from one Update onto a system installed with a different Update

I'd just like to make the following clear to customers:

Customers who install packages from one Update release (e.g. S10U6) on a system installed with another release (e.g. S10U3) risk corrupting their system.

You must not install packages from one Update release onto a system installed with any other Update release.

The reason for this is that all available patches are pre-applied into all packages for each Update release.   Patches and packages have a many-to-many relationship.  That is, one patch can patch many packages.   One package can be patched by many patches.

If you install a package from an Update release onto a system installed with a different Update release, you completely compromise future patch dependency checking as you've introduced patch metadata from a later Update release.   This is likely to lead to system corruption as further patches are applied.

'patchadd' checks that dependencies are satisfied when installing a patch.  If 'patchadd' finds any installed package patched with a patch which satisfies the dependency, it assumes the patch is applied to all packages.  This is done for performance reasons.  Hence, if a package from a later release is installed on the system, it's pre-applied patches may fool subsequent 'patchadd' invocations into thinking that a hard code dependency has been satisfied for all packages on the system when this is not the case.   The patch application will be allowed to continue, potentially corrupting the system.

The converse is also true.   If a package from an earlier Update is applied to a system, the patch delta from that Update to the Update installed on the system plus any additional patches installed on the system would need to be applied to the package to avoid a mismatch in software levels between the packages on this system, which could lead to incorrect patch dependency resolution and hence to system corruption.  Since this is difficult to get right, adding packages from a different Update release onto an installed system is, in general, unsupported. 

There are two exceptions to the above rules, for Live Upgrade and encryption packages.

  • Live Upgrade: If you are upgrading from Solaris 8 or Solaris 9 to Solaris 10, you need to apply the Live Upgrade packages from the Solaris 10 system to your Solaris 8 or Solaris 9 system.  See document 1004881.1 on My Oracle Support (MOS), http://support.oracle.com, for details.
  • SUNWcry\* encryption packages: These weren't included in the Solaris distribution prior to Solaris 10 8/07 (Update 4).  For pre-Update4 systems, the recommended way to get these packages is to upgrade to a later Update release.  For the reasons outlined above, while not recommended, a possible alternative is to download the packages from the Sun Download Center (SDLC), install them, and then re-apply any patches that patch the SUNWcry\* packages which you have already applied to the system (\*\*). Also, for the reasons outlined above, it is not recommended to apply the packages from the media of a later Update release, as you would need to ensure that all the other packages installed on the system are patched to the same or higher patch level  (e.g. by installing the appropriate Solaris Update Patch Bundle available from My Oracle Support, http://support.oracle.com) to avoid completely compromising future patch dependency checking on the system.

\*\* A way to check which patches need to be re-applied in this scenario is as follows:

cd /var/sadm/patch
egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u

as in:

# cd /var/sadm/patch
# egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u
127127-11
137137-09
139555-08
141444-09
#

The above example is on a system installed with Soalris 10 11/06 (Update 3).  The user would need to re-apply the patches listed above and be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level.

Please note that if a package from the same Update is applied to a system, then any additional patches already installed on the system that patch the added package must be re-applied to bring that package up to the same software level as the rest of the system.  This is called "incremental patching".   This is supported, but care must be taken.  The easiest way to do this is to reapply all patches installed on the system (as listed by 'patchadd -p').  This will bring the added package(s) up to the same software level as the rest of the system.  Again, you need to be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level as the rest of the system.

Best Wishes,

Gerry Haskins,
Director, Software Patch Services

About

This blog is to inform customers about patching 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 Engineer

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
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