Choosing the Right Mass Deployment Strategy for Oracle Database 10g Software Sudip Datta Principal Product Manager Oracle Corporation.
Download
Report
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