Transcript Choosing the Right Mass Deployment Strategy for Oracle Database 10g Software Sudip Datta Principal Product Manager Oracle Corporation.

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
40
25
5
5
Backup/recovery
License/Doc/Training
Performance/Troubleshoot
Install/Upgrade/Patch
Security/Planning
Source: Giga Forrester research,2003
Life Cycle Management
Upgrade
Clone
And
Update
Install
Configure
Upgrade
Activate
Patch
Uninstall
Deactivate
Activate
Operate
Install and
Configure
Challenges





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
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
Inventory
pointer
Central
Inventory
pointer
Central
inventory
Central
Inventory
Oracle
Home 1
Oracle
Home 2
Oracle
Home 3
Oracle
Home 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