choosing the right mass deployment strategy for oracle database 10 g software sudip datta principal...
TRANSCRIPT
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