Choosing the Right Mass Deployment Strategy for Oracle Database 10g Software

Sudip Datta

Principal Product Manager

Oracle Corporation

Agenda

Part 1– Software deployment challenges– Basic best practice operations– Operational entities-nuts and bolts

Part 2– Case study: Enterprise Manager 10g

Software Deployment challenges

Data center labor distribution

5 5

255

40

Backup/recovery

License/Doc/Training

Performance/Troubleshoot

Install/Upgrade/Patch

Security/Planning

Source: Giga Forrester research,2003

Life Cycle Management

Install andConfigure

Activate

UpgradeAndUpdateInstall

Configure

Activate

Operate

Clone

Upgrade

Patch

UninstallDeactivate

Wide distribution of hosts Variety of platforms and versions Different hardware and network topologies Too many moving parts for administration Security vulnerabilities-frequent interim patching

– According to a recent Aberdeen group study, patch handling costs businesses in excess of 2 billion dollars annually. For a leading service provider, the cost was reported to be as high as $14,400 per

server

All the above lead to high IT Management costs

Challenges

Basic best practice operations

10g database software ontology

Immutable Files– Original

Objects, classes, message files

– Derived Relinked executables, some library archives

Mutable files– Configuration files like init.ora, tnsnames.ora– Oracle inventory

Physical Cloning

Build a stage consisting of a base image optionally patched with a patchset and/or one-offs

Copy the stage as-is to other nodes Use secure transfer to make sure that bits

are distributed reliably Make target specific changes to

environment and inventory

Physical Cloning-Merits and limitations

Merits– Trusted and Scalable– Software can be tested at source and

deployed

Limitations– Multi NLS deployments– Multi-platform deployments

Logical cloning

Replay the operations as-is in the same order

Works on staged software components and not on final bits

Operations may consist of– Silent install– Silent upgrade– Silent patch

Logical Cloning-merits and limitations

Merits– Works for multi NLS environment– Works for a fragmented platform distribution

Limitations– More time consuming and less scalable– Results in less trusted deployments– Cannot deploy a fully patched software in one

go

Incremental operations

Checksum based approach– Propagate deltas

Logical approach– Use opatch at the targets– Frequent one offs not recommended

Hybrid model– Physical cloning for initial deployment– Logical operations for one-off

Operational entities-the nuts and bolts

Oracle software inventory

Hierarchical structure in every host– Central Inventory pointer

Central inventory Local Inventory within ORACLE_HOME

There can be multiple central inventories to support the hosted environments

Each central inventory contain pointers to a set of ORACLE_HOMEs

Local inventory contains components, versions and patches

Enterprise Manager host collection collects information from inventories

Inventory is updated during install,patch,upgrade

Oracle software Inventory (contd)

Central Central Inventory Inventory pointerpointer

Central Central Inventory Inventory pointerpointer

Central Central inventoryinventory

Central Central InventoryInventory

Oracle Oracle Home 1Home 1

Oracle Oracle Home 2Home 2

Oracle Oracle Home 3Home 3

Oracle Oracle Home 4Home 4

Interactive Install

GUI driven-requires X configuration on Unix

Single click enabled for database 10g on Windows

Can be invoked in recordmode to capture session variables in responsefiles.

– ./runInstaller –recordmode –responsefile <filename>

Not scalable in a large environment

Http based install

OUI supports software staged in a central application server

– More reliable and open than shared filesystem

Both interactive and silent install supports http install

– FROM_LOCATION should point to the products.xml file.

Supports firewalls between source and target

Silent Install

Supports different installation flows Scalable for mass deployment Can be scheduled from a job subsystem Can be chained with silent configuration

tools (dbca, netca etc) Used by third party vendors like Opsware,

HP, ASDIS among others Not suitable for deploying ‘patched’ and

‘tested’ bits

Patch engine

Opatch-the single patching interface from 9iR2 onwards

Pre-requisite checks include operating system, component and version

Conflict detection and superset handling Integrates with inventory via OUI APIS Callable from a job subsystem in silent

mode

Cloning

New Installer mode with OUI 10g, functionally equivalent to install

Retains ‘patched’ bits Makes context specific inventory changes The new installation can participate in

bigger system management Smaller footprint helps in cloning

Operation mappings

Data center operation

Oracle operation Backend Engine

First time install on sandbox

Interactive install

Silent install

OUI

Cloning EM cloning/ OUI cloning OUI clone mode

Logical large scale deployments

Silent install from http/NFS stage

OUI in silent mode

Interim patching EM patching via job subsystem

Opatch and job subsystem

Compliance tracking

Collection from inventories

OUI APIs

Case study: Enterprise Manager 10g

EM enabled practices

Enterprise Manager 10gR1 adopts a hybrid model

– Physical cloning– Logical incremental one off patching

Job subsystem can perform silent installation as well

Compliance tracking

EM Cloning - choose source

EM Cloning - provide source settings

EM Cloning – specify destination

EM Cloning – schedule job

Post deployment practices

“After a software system is packaged and released the software producer must have an effective mechanism to advertise the release in order to notify interested consumers of its existence. There is little benefit for the software producer if its customers, both current and potential, are unaware of its products and services.”- Ricahrd Scott Hall

[1] “Agent-based Software Configuration and Deployment” by Richard Scott Hall, B.S., University of Michigan, 1990,M.S., University of Colorado, 1993 

EM enabled practices

Set up Enterprise Policies Compliance checking

– Software version and patchsets– Patches– Configuration parameters– Database features

Corrective action against deviations

Compliance tracking via search

Overall configuration search

Compliance tracking through comparison

Compliance tracking through comparison

Compliance tracking through comparison

Compliance tracking through comparison

Compliance tracking through comparison

Summary

Build and clone method is the most scalable option

Deployment has to be tied with overall lifecycle management

Compliance has to be tracked Enterprise Manager 10g Grid Control

implements some of the best practices.

Thank you