Oracle Solaris 11 Customer Maintenance · PDF file Gerry Haskins Director, Software Lifecycle...

<Insert Picture Here>

Gerry HaskinsDirector, Software Lifecycle EngineeringOracle Solaris Systems

Oracle Solaris 11Customer Maintenance Lifecycle

2© 2011 Oracle Corporation DOAG 2011

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It 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 for Oracle’s products remains at the sole discretion of Oracle.


Solaris 11ist hier!


Agenda

• Image Packaging System (IPS)• Solaris Maintenance Overview

– Solaris 10 Maintenance– Solaris 11 Maintenance

• Solaris 11 Maintenance Policies• Q&A


Image Packaging System (IPS)

• Single tier packaging architecture– Replaces old SVR4-based 2-tier packaging and

patch architecture used in Solaris 10 and earlier– Designed to eliminate the deficiencies of the old

architecture• No hand crafted pre- or post-install scripts• Solaris developers use what customers use

– Leverages ZFS Root snapshots• ‘beadm’ can be viewed as enhanced,

integrated Live Upgrade– Only change delta applied

• Download from package Repository or ISO image from My Oracle Support


Solaris Maintenance Overview



• Proactive Maintenance– Time for pre-deployment testing

• Identify interactions with 3rd party & home grown apps• Identify configuration specific issues

– Major Proactive Maintenance Windows• Typically every 2 years or so• Typically associated with hardware roll-out, major upgrades

– Minor Proactive Maintenance Windows• Bug fix updates• Prevention is better (and much cheaper) than cure

• Reactive Maintenance– Break/fix situations or to address security vulnerabilities– Little time for pre-deployment test

• Implies customers want discrete change to minimize risk



• All changes made to Solaris tip-of-tree– Implies that the more proactive maintenance a

customer does, the smaller the change is likely to be in reactive maintenance situations

• Solaris Updates typically released once or twice a year– Hardware support– Software enhancements– Includes all available bug fixes

• Bug fixes released frequently• Interim Diagnostics & Relief (IDRs)

– Provide issue diagnostics or interim relief until final bug fix available



Solaris 10 Maintenance Overview

• Solaris 10 Updates typically released once or twice a year– Intensely tested– Some significant enhancements delivered:

• NewBoot, Trusted Extensions, ZFS, OPL, Secure By Default, Zones enhancements

– Large Kernel patches associated with each Update• Kernel patch “rejuvenation” provides discrete

change between Updates– Solaris Updates include all available bug fixes– Provide high quality stepping stones to new and

improved functionality



• Recommend customers:– Install latest Update release in Major Proactive

Maintenance Windows– Install Solaris OS Recommended Patchset in

Minor Maintenance Windows– Install specific patches in Reactive Maintenance

• But customers can apply any combination of patches in both Proactive and Reactive Maintenance situations– Such mix-and-match patching leads to unique

software combinations– Lack of discrete Baselines on which customers run

implies issues may be unique– Results in a sub-optimal customer experience



• Solaris 11 Updates forecast to be released once or maybe twice a year– Intensely tested– Some significant enhancements may be delivered

• Hardware support• Software enhancements

– Existing packages updated– May introduce new packages– Solaris Updates include all available bug fixes– Provide high quality stepping stones to new and

improved functionality




• Plan to release Support Repository Update (SRU) containing bug fixes monthly– Equivalent to Solaris OS Recommended Patchset– Want to avoid replacing mix-and-match patching

with mix-and-match packaging• Customers should update Solaris using an SRU

in Proactive Maintenance windows– Provide limited number of Solaris Baselines

• Issues less likely to be unique• Better customer experience - “safety in

numbers” effect– Customers may still minimize systems



– Plan to rename every third SRU as a quarterly Critical Patch Update (CPU) in line with Oracle policy• Similar to renaming of Solaris OS Recommended

Patchset as quarterly CPU • Publication of security vulnerabilities coincides

with CPU release schedule– CVE & CVSS scores provided

• CPUs released for each layer of the Oracle stack on the Tuesday closest to the 15th of January, April, July, and October

• Provides scheduled release cycle on which customers can align Proactive Maintenance windows



• Recommend customers:– Install latest Update release in Major Proactive

Maintenance Windows– Install SRU/CPU in Minor Maintenance Windows– Install specific packages in Reactive Maintenance

• Want to ensure customers return to a Solaris Baseline– Intensely tested by Oracle prior to release– Tried and tested by other customers post release -

“safety in numbers effect”• Less likely that customers will encounter unique

issues– Improved customer experience

• Lower TCO


Solaris 11 Maintenance Policies


Solaris 11 Maintenance Policies

• Proactive Maintenance– Update Solaris using an Update/SRU/CPU Baseline in

scheduled maintenance windows• e.g. Every 6, 9, 12, or at a minimum every 24 months• Well defined, intensely tested Baselines

• Reactive Maintenance– Need to be able to install finer grained updates in break/fix

situations or to address security vulnerabilities due to the short pre-deployment test time• Permit installation of indivisible “core” Solaris or other

individual packages + dependencies– Limited mix-and-match package application

– Want to bring customers back onto Solaris Baseline over time, so that Baseline concept doesn’t unravel


Solaris 11 Granularity

• Indivisible “core” Solaris– Defined as: Every package in the “osnet-incorporation” which

does not have a version lock facet in the “osnet-incorporation” manifest

– Subset of the core Solaris Operating System & Network including Kernel, libc, libxml, ssh, core network drivers needed to access Repository, but not ssl, etc.

– Includes those parts of the core Operating System & Network with private interfaces between them, e.g. libc and libxml• Similar in scope to Kernel patches

– Even in Reactive Maintenance situations, this “core” Solaris is indivisible, similar to a Kernel patch



• Solaris Baseline– Defined as any of the following:

• The initial Solaris 11 release, an SRU, CPU, or Solaris 11 Update

• Really only concerned about the bits Solaris itself relies upon, such as the indivisible core, Apache, perl, python, *sh, Java, etc.

• Don’t care if customers want to keep other FOSS, Userland, or Desktop components at different levels – e.g. Thunderbird, Mozilla, Open Office, etc.



• Solaris Baseline– In Proactive Maintenance Windows

• Solaris Baseline should be updated as a unit, with all key components kept at a single well tested Baselines– Limited number of Baselines– Baseline granularity is at the Update/CPU/SRU release level,

customers should update all key Solaris Baseline components to a single Update/CPU/SRU release level

• Customers can still minimize the system– Package dependencies must be satisfied– Minimizing reduces maintenance windows as less to update



• Non Core Solaris– FOSS and Userland Components

• Plan to keep in sync with community as far as possible• Userland components which Solaris uses, such as Apache,

Perl, Java, Python, *sh, etc., are considered part of the Baseline

– Desktop• Plan to keep in sync with Oracle Linux

– Can update *Office, Thunderbird, Mozilla, Gnome, etc. independent of “core” Solaris & each other


Solaris 11 Policies - Proactive Maintenance

• Recommend customers update to a Solaris Baseline at least every 12 months– Well defined, intensely tested Baselines– Baseline granularity is at Update/CPU/SRU release level– SRUs/CPUs for an Update cease when the next Update is

released• Customers must be on a Solaris baseline within 24

months of current to get discrete IDRs or packages for bug fixes in Reactive Maintenance situations– The 24 month limit recognizes that some customer legitimately

have proactive maintenance cycles lasting more than 12 months


Solaris 11 Policies – Reactive Maintenance

• Recommend customers update to a Solaris Baseline at least every 12 months– Plan to create IDRs on any Baseline within 12 months of current

• Customer gets discrete change if policy followed – Carrot• For S10, 86% of IDRs are based on patches less than 12

months old(see appendix for details)

• IDR will be recreated on request for subsequent Update/CPU/SRU if required due to customers’ Proactive Maintenance cycles


Solaris 11 Policies – Reactive Maintenance

• All packages released will depend upon 24 month old Solaris Baseline– Applying an IDR, indivisible “core” Solaris, or any other package

auto-updates the Baseline if it’s more than 24 months old• Ensures customers are on a Baseline < 24 months old

– Customers on a Baseline between 12 and 24 months may apply individual package(s) + IDRs in Reactive Maintenance situations

– If customer on a Baseline older than 24 months, issues will still be analyzed

Reactive Maintenance granularity of change for IDRs:• Relief IDR (Baseline <12 months old)• Package + Relief IDR (Baseline >12 & <24 months old)• Baseline + Relief IDR (Baseline >24 months old)• Diagnostic IDR (any level)


Solaris 11 Policies – Reactive Maintenance• Fixes are putback to top-of-tree

– Customers on baseline < 24 months old can install just the indivisible “core” Solaris or other individual package(s) + dependencies in Reactive Maintenance situations• The more the customer keeps up to date with Proactive Maintenance, the

more discrete the change in Reactive Maintenance situations – Carrot– Customers on a Baseline > 24 months old will be auto-updated to 24

month old Baseline level• Can then apply the indivisible “core” Solaris or other individual package(s) +

dependencies

• Proactive Maintenance Policy means customers return to a Solaris Baseline in due course


Example 1: Assume “today” is a year after Solaris 11 releasesCan still get discrete IDR for any Baseline

S11 S11U1

D DNON A JJMAMFJDAJJMAMFJ S O N A SD DNON A JJMAMFJDAJJMAMFJ S O N A S

Dec SepAugJulJunMayAprMarFebJan

CPUCPUSRUSRUCPUSRU

Nov

SRUSRUSRU

Oct

CPU

Dates and update intervals are for illustrative purposes only and are not indicative of any roadmap

IDR


Example 2: Assume “today” is 2 years after Solaris 11 releasesCan get discrete IDR for any Baseline less than a year oldCan get pkg + IDR for any Baseline

S11U2

S11

S11U3

S11U1



CPUCPUSRUSRUCPUSRU

Nov

SRUSRUSRU

Oct

CPU

Dec Jan Feb Mar Apr May Jun Jul Aug Sep OctNovCPUSRU SRU SRU CPU

SRU CPU SRU SRU CPU

Pkg+IDR

IDR



Example 3: Assume it’s 26 months after Solaris 11 releaseCan get discrete IDR for any Baseline less than a year oldCan get pkg + IDR for any Baseline less than 2 years oldUpdate Baseline + IDR if current Baseline > 2 years old

S11U4

S11U2

S11

S11U3

S11U1



CPUCPUSRUSRUCPUSRU

Nov

SRUSRUSRU

Oct

CPU

Dec Jan Feb Mar Apr May Jun Jul Aug Sep OctNovCPUSRU SRU SRU CPU

SRU CPU SRU SRU CPU

Nov Dec

SRU

Pkg +IDR

IDR

UpdateBaseline



IPS IDR Delivery Process

• Plan to publish IDRs on My Oracle Support• Each IDR is designed for specific customers on specific

Baselines– Only the customer(s) for whom it is designed can install the IDR– Maintains safety as IDRs may be toxic to other customers

• IPS enables IDRs to be auto-superseded when a fix is available in an SRU/CPU/Update– No need to manually remove the IDR – IPS will do it for you


Key Reactive Maintenance Use Case: “Give me all Security fixes only”

• Plan to maintain a Security package for non-core components– The Security package with specify optional dependencies on all

non-core packages which deliver new security fixes– Applying the Security package auto-updates all installed non-

core packages with the latest available security fixes– Can be applied without need to reboot

• For “core” Solaris, update to the indivisible core in the appropriate Baseline– Requires a reboot to activate– If desired, can use the IPS “freeze” or “unlock” options to keep

other packages at current level


Q&A


For More Information / Try Out Today

• Product overview and download– oracle.com/solaris

• Oracle Technology Network– oracle.com/technetwork/server-storage/solaris11

• System administrators community– oracle.com/technetwork/systems

• Gerry Haskins’ Blog– blogs.oracle.com/patch

• @ORCL_Solaris• facebook.com/oraclesolaris• Oracle Solaris Insider

31


Reduce Deployment Time with Training

• Expert-led training to support your adoption of Oracle Solaris 11

• Learning paths for new and experienced system administrators

• Flexible training formats to save you time and money: In-class, virtual-class or self-study

Key Courses Available for:

• Transition to Oracle Solaris 11• Oracle Solaris 11 System Administration• Oracle Solaris 11 Advanced System Administration

Oracle University: Oracle Solaris TrainingPrepare Your Organization for Success

Overview

oracle.com/training/solaris11

Exclusive Offer For Premier Support Customers:

• Save 20% on Training. Details at education.oracle.com/renewaloffer

http://my.oracle.com/site/mktg/creative/creative


Appendix


-120 - -90 60 - 90 240 - 270 420 - 450 600 - 630 780 - 810 960 - 990 1140 - 1170 -30 - 0 150 - 180 330 - 360 510 - 540 690 - 720 870 - 900 1050 - 1080 1230 - 1260

1320 - 1350

0

50

100

150

200

250

300

350

# of IDRsSum percent

Age of patches on which S10 IDRs are based – 80% less than 9 months old

Oracle Solaris 11 Customer Maintenance · PDF file Gerry Haskins Director, Software Lifecycle...

Documents

Transcript of Oracle Solaris 11 Customer Maintenance · PDF file Gerry Haskins Director, Software Lifecycle...