Post on 22-Nov-2014
description
transcript
1 ©2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
Jan Goode, Service Management Design Manager
Donna Lucas, Oracle DBA
HP Enterprise Services
HP Enterprise Services (formerly EDS): HP ServiceCenter to HP Service Manager data migration in a massive multi-tenant environment
2
SPEAKER: Jan Goode, HP ES
• Design Manager for HP Enterprise Service Management Engineering
• Architect for HP EDS Service Operations Management
• 15 years experience with ServiceCenter and Service Manager
• 11 years experience with Peregrine Professional Services
• 8 years experience with Managed Service Providers
SPEAKER: Donna Lucas, HP ES
• Oracle DBA for HP Enterprise Service Management Engineering
• 7 years experience with ServiceCenter and Service Manager
• 23 years experience as a Database Administrator
• Specializes in database conversion and migrations
3
HP Enterprise Services Service Management
Established, market-leading services breadth and depth
SC 6.1 Multi-tenant global deployment
3 regions – 7 instances
Vertically scaled
Sun Solaris + Oracle 10 RDBMS
Maximum users ~2000
Manages 380,000+ servers
Supports 3M+ desktops
Operates 180+ Data Centers
HP+EDS bring the industry’s broadest end-to-end IT services portfolio
#1 hardware services and infrastructure support services provider
SC 6.2.7 Multi-tenant global
deployment
3 regional instances
Three Application Servers with Load
Manager
HP UX + Oracle 10 RDBMS
All modules deployed
Average Maximum users ~1600
Max transactions/hr ~6000
9 Languages supported for customer facing screens
Service Manager 7.11
3 regional instances
Best practice ITIL workflows
Horizontally scaled applications serversWindows Platform,
Oracle 11g RAC
=
4
Consolidate Global Instances
5
Service Management Delivery Model
ClientApplications
andInfrastructure
ClientExperience
Portal
ClientService
ManagementSystems
GlobalServiceDesk
Service LevelReports
Self HelpCapacityReports
Data Center Services
Network Management
Workplace Services
Application Services
Service Exchange
6
HP ES Standard Reference Architecture ENTERPRISE
SERVICE PORTAL
Software License Mgmt. (HP LMS)
Run Book
Automation
(HP OO)
Service
Exchange
(BizTalk)
Event Management(HP OM, HP
NNM)
HP GLOBAL DATA CENTERS
End Users
Capacity
Database
(GDCPM)
AvailabilityManagement (HP PM, HP
BAC)
INFRASTRUCTURE
RetainedWorkflow
Data Consolidation &
Normalization (EIS)
SERVERS WINTEL/DESKTOP
Client IT
NETWORK
Reporting(Bus. Objects)
NSSR (Aries/Aldea)
Bulletins (Infoboard)
PW Reset (Hitachi PM)
RDM(ISCE/ VR)
SM 7 Web Client
Self Service Ticketing, Standard Requests,Order Management
Reporting DataWarehouse
(CRDW)
MAINFRAME
IT Asset Mgmt. (HP AM)
CMDB (ESL & Redfish2)
=> uCMDB
Asset Analytics
ON SHORE
HP GLOBAL DELIVERY TEAMS
NEAR SHORE
OFF SHORE
3RD PARTY SUPPLIERS
HP ACCOUNT TEAM
Capacity Management
(HP R/PM, HP PA, HP PI)
On-boarding(MDM)
Document Relay
Service
Service Bus
Business Rules
Automation Bus (AB)
Routing
Notification
JET
SM Consoles
Client Survey
SLM(Oblicore)
Service Manager 7
Knowledge Management
Service Request Management
Problem Management
Change Management
Release Management
Incident Management
InsertClient Logo
InsertClien
t Logo
DDMi
HP CAE
SCCMDDMi OM SPIs
HP SA BAC Site Scope
HP OO RASHP NA
NNM MDL
HPPM
CA OPSMVS
Main Frame Tools
3rd
Party Workflow
7
HP ES Fast Track Strategy
1 2 3 4Upgrade to SM 7.11 Deploy to Regions Migrate SRA SC Customers
Migrate LegacyCustomers
•Provide platform for go forward HP ES strategic architecture•Performed dual upgrade: SM 7.10 & SM 7.11
•Stand up ‘clean’ SM 7.11 in parallel to existing production systems
•Use Data Migration Tool to migrate existing SRA SC 6.2 customers to SM 7.11. •Initial pilot of 5 customers followed by phased migration based on complexity.
•Migrate all customers on legacy workflow tools (SC and SD) to strategic platform.•Provide Data Archiving Solution to archive customer data so legacy platforms can be switched off.
–HP ES Standard Reference Architecture (SRA) – architecture to support HP ES Outsourcing business based on HP BTO products
–HP ES currently supports two legacy environments both on ServiceCenter 6 – will converge to single Service Manager build as strategic solution
8
HP ES SM 7.11 Upgrade—Upgrade Approach
– Subtitle goes here
9
Why Upgrade?HP ES Benefits Tied to HP ITO FY 10 Goals– ITO Goal: Workforce Optimization and
Automation
• Template functionality for all modules
• Flexible Views
• Multi-select capability for list functions and Mass Update
• TO DO Queue
• Enhanced Page Controls
– ITO Goal: Service and Operational
Excellence
• Replace custom enhancements with Out of Box
• Extended Support Life
• KM: Improved index management, Adaptive Learning,
search within result set, Problem knowledge library
• Horizontal Scaling and Servlet Mode
• SM Application Patch Utility
• SM 7.11 quality based maintenance release
– ITO Goal: Portfolio Reinvigoration
• HP SW ITIL Best Practice enhancements
• Positioned for further BTO integrations (uCMDB,
Release Control)
• Enhanced Catalog Administration and
language/currency support
• SM 7 Approvals and Approval Delegation for
SRM available from ESS client
• Service Lifecycle Management with support for
Service CIs, Affected Services
• CI Relationship Visualization tool
• CI Attribute Management using Change
Management
• Change to Change relationships
• Additional language support
10
SM7 Upgrade Approach
Minimize impact to production environment
– Support existing customers
– Minimal impact to customer facing interfaces
– Minimize risk to production environments
Architect for the future
– Position for ES future end state
– Position for HP SW BTO product integration
Retain the best from the past while leveraging the best from out of box
– Support HP EDS processes
– Leverage SM 7.11 best practices
– Carry forward delivery efficiencies
11
SM7 Deployment Options– All upgrade strategies have risks and possible mitigations
– Several options were assessed and conclusion was to stand up a clean upgraded system
Migration/Reimplementation Upgrade in Situ Delta Upgrade Transition existing and new accounts to upgraded instance
Create a new production system from OOB and apply requirements
from existing capabilities
Use the upgrade utilities to create the new production
system and migrate production data in Situ
An approach to minimize downtime by performing the main upgrade offline and then
applying a delta.
Use upgrade utilities to create the new production system but standup in parallel
and transition accounts to the new instance.
Need to migrate production data – no standard utility
Can upgrade production systems in situ – upgrade tools
migrate all production data
Objective is to replace current production system with upgraded version in two step process
Creates a parallel instance during transition –customer data has to be migrated.
No migration of transaction data
No production outage but may need to swivel seat until all accounts migrated
Requires production outage during upgrade; outage
window depends on production data
Requires short production outage; major upgrade performed off line
No production outage but may need to swivel seat until all accounts migrated
Deploy on new hardware – allows upgrade of hardware
Upgrade on production hardware
Requires two additional systems to upgrade deltas Deploy on new hardware – allows upgrade of hardware or use of spare capacity
Need to support dual integration and monitoring environments
Integration environments will be upgraded (if needed) during
SM upgrade
Integration environments will be upgraded (if needed) during SM upgrade
Need to support dual integration and monitoring environments during transition
Easier to stay close to new OOB model Easier to maintain existing customization
Easier to maintain existing customization Easier to maintain existing customization
Need to create tools to migrate customer data (e.g. multiple Connect-It
scenarios) or re-onboard
Tools provided by HP SW Tools provided by HP SW but needs additional work to managed delta migration
Need to create tools to migrate customer data in phased approach
Need to maintain two systems until cutover is complete – experience is that it is difficult to migrate customer from
any legacy system
Legacy system replaced Legacy system replaced Legacy system not replaced immediately; new instance stood up and customers migrated as
stability established
Need to set up tailoring source system on same version as destination (data
stripped)
Upgrade utility will manage migration of code
Upgrade utility will manage migration of code Upgrade utility will manage migration of code
12
SM Deployment Strategy Benefits
– Decision made to stand up a Service Manager production instance to allow for
phased migration approach off SC instead of a traditional in situ upgrade.
– Traditional Custom Upgrade presented too much risk to ES business and would
require too much production outage
– Minimize customer risk and exposure to extended downtime
– Ability to pilot new features and quickly react to feedback before mass customers
impacted
– Enable longer lead time for agent training to be rolled out
– Ability to incorporate lessons learned from the migration process before more
sensitive customers are migrated
– Customer migration over period of time reduces risk
SC SMDecember 2009 CUSTA, CUSTB, CUSTC
January 2010 CUSTD, CUSTE, CUSTF
March 2010 CUSTG
13
SM7 Deployment Implications
– SC 6.2 and SM 7.11 systems are live in production in parallel
– Operators continue to use SC only to close tickets opened in SC
– All new tickets are opened in SM
– Maintenance of SC was reduced to critical issues only to focus
efforts on SM and to encourage quicker migration
– Management support of end of life for SC to minimize impact
to delivery teams during the cutover period
– Hardware/Capacity will be migrated to support the Service
Manager deployment and aligned with the customer migration
plans
– Companies are migrated from SC to SM in groups from least
complex to most complex
– New customers will be on-boarded onto the SM platform as the
default once the solution has been stabilized in production and
solution gaps found during the pilot phase are closed
Close tickets in SC
Use SM for all other work
14
HP ES SM 7.11 Upgrade—Data Migration Tool
– Subtitle goes here
15
SM7 Data Migration Design
– ServiceCenter 6.2 was the source, Service Manager 7.11 was the target
– All SC and SM tables were classified according to the type of data
– Tables and columns were compared between SC and SM to identify
• New columns
• Obsolete columns
• Data type and length differences
• Data transformations required
16
SM7 Data Migration Table Classifications
Classification Definition Data Migration
Action
Examples
SYSTEM Data should already exist in the
SM 7.11 clean copy for this table
as a result of the upgrade, data
will be the same for all regions
No action required DBDICTM1, FORMATM1, INFOM1,
OBJECTM1, PROCESSM1
TRANSACTIONAL Data is related to tickets, calls,
incidents, other transactional
customer data
Initial deletion of all
rows, no action required
for migration of
individual clients
ACTIVITYM1, CM3RM1, OCMLM1,
PROBSUMMARYM1
DELIVERY Data is common across clients
and must exist for initial client
and all subsequent clients, data
will be the same for all clients
within a region
Initial migration of all
rows, no action for
individual clients
CM3GROUPSM1, COMPANYM1,
KMGROUPM1, VENDORM1
CONFIGURATION
ITEMS
Data is related to configuration
items
Populated using ESL
tools, etc.
CIRELATIONSHIPM1,
COMPUTERM1, DEVICEM1
CLIENT-SPECIFIC Data is related to a specific client Migrated for individual
clients based on client
ID
DEPTM1, LOCATIONM1,
MODELM1, OPERATORM1,
SVCCATALOGM1
17
Sample SM7 Data Migration MappingSC 6.2 TABLE SC 6.2 COLUMN SC 6.2 TYPE SC 6.2 LENGTH COL DIFF TYPE DIFF LENGTH DIFF SM 7.11 TABLE SM 7.11 COLUMN SM 7.11 TYPE SM 7.11 LENGTH TRANSFORMATION
KMDOCUMENTM1 ID VARCHAR2 50 KMDOCUMENTA1 ID VARCHAR2 50
Filter where ID in (select ID from KMDOCUMENTM1 where
MS_COMPANY = '<company>') and CATEGORIES is not NULL
X X X KMDOCUMENTA1 RECORD_NUMBER NUMBER 22
KMDOCUMENTM1 CATEGORIES VARCHAR2 1000 X KMDOCUMENTA1 CATEGORIES VARCHAR2 60
Length changed from 1000 to 60 to match KMCATEGORYM1.ID,
Parse into KMDOCUMENTA1, delimited by :
KMDOCUMENTM1 ID VARCHAR2 50 KMDOCUMENTM1 ID VARCHAR2 50
KMDOCUMENTM1 TITLE VARCHAR2 255 KMDOCUMENTM1 TITLE VARCHAR2 255
KMDOCUMENTM1 SUMMARY VARCHAR2 190 KMDOCUMENTM1 SUMMARY VARCHAR2 190
KMDOCUMENTM1 DOCTYPE VARCHAR2 50 KMDOCUMENTM1 DOCTYPE VARCHAR2 50
KMDOCUMENTM1 CATEGORIES VARCHAR2 1000 X X X Parse into KMDOCUMENTA1, delimited by :
KMDOCUMENTM1 PROBLEM BLOB 4000 KMDOCUMENTM1 PROBLEM BLOB 4000
KMDOCUMENTM1 SOLUTION BLOB 4000 KMDOCUMENTM1 SOLUTION BLOB 4000
KMDOCUMENTM1 ERROR BLOB 4000 KMDOCUMENTM1 ERROR BLOB 4000
KMDOCUMENTM1 FIX BLOB 4000 KMDOCUMENTM1 FIX BLOB 4000
KMDOCUMENTM1 CAUSE BLOB 4000 KMDOCUMENTM1 CAUSE BLOB 4000
KMDOCUMENTM1 REFERENCE BLOB 4000 KMDOCUMENTM1 REFERENCE BLOB 4000
KMDOCUMENTM1 QUESTION BLOB 4000 KMDOCUMENTM1 QUESTION BLOB 4000
KMDOCUMENTM1 ANSWER BLOB 4000 KMDOCUMENTM1 ANSWER BLOB 4000
KMDOCUMENTM1 STATUS VARCHAR2 50 KMDOCUMENTM1 STATUS VARCHAR2 50
KMDOCUMENTM1 USAGE_COUNT FLOAT 22 KMDOCUMENTM1 USAGE_COUNT FLOAT 22
KMDOCUMENTM1 AUTHOR VARCHAR2 50 KMDOCUMENTM1 AUTHOR VARCHAR2 50
KMDOCUMENTM1 EXPIRATION_DATE DATE 7 KMDOCUMENTM1 EXPIRATION_DATE DATE 7
KMDOCUMENTM1 HOTNEWS CHAR 1 KMDOCUMENTM1 HOTNEWS CHAR 1
KMDOCUMENTM1 CHANGE_REQUEST_NUMBER VARCHAR2 40 KMDOCUMENTM1 CHANGE_REQUEST_NUMBER VARCHAR2 40
KMDOCUMENTM1 CREATION_DATE DATE 7 KMDOCUMENTM1 CREATION_DATE DATE 7
KMDOCUMENTM1 ID_ATTACH FLOAT 22 KMDOCUMENTM1 ID_ATTACH FLOAT 22
KMDOCUMENTM1 ASSOC_WC_DOC VARCHAR2 40 KMDOCUMENTM1 ASSOC_WC_DOC VARCHAR2 40
KMDOCUMENTM1 ASSOC_PUBLISHED_DOC VARCHAR2 40 KMDOCUMENTM1 ASSOC_PUBLISHED_DOC VARCHAR2 40
KMDOCUMENTM1 GENERATEDCATS VARCHAR2 1000 KMDOCUMENTM1 GENERATEDCATS VARCHAR2 1000
KMDOCUMENTM1 HOTNEWS_END_DATE DATE 7 KMDOCUMENTM1 HOTNEWS_END_DATE DATE 7
KMDOCUMENTM1 HOTNEWS_START_DATE DATE 7 KMDOCUMENTM1 HOTNEWS_START_DATE DATE 7
KMDOCUMENTM1 SYSMODTIME DATE 7 KMDOCUMENTM1 SYSMODTIME DATE 7
KMDOCUMENTM1 SYSMODUSER VARCHAR2 40 KMDOCUMENTM1 SYSMODUSER VARCHAR2 40
KMDOCUMENTM1 SYSMODCOUNT FLOAT 22 KMDOCUMENTM1 SYSMODCOUNT FLOAT 22
KMDOCUMENTM1 LINKS BLOB 4000 KMDOCUMENTM1 LINKS BLOB 4000
KMDOCUMENTM1 LEGACYID VARCHAR2 40 KMDOCUMENTM1 LEGACYID VARCHAR2 40
KMDOCUMENTM1 MS_MODULE_CATEGORY VARCHAR2 60 KMDOCUMENTM1 MS_MODULE_CATEGORY VARCHAR2 60
KMDOCUMENTM1 MS_MODULE_SUBCATEGORY VARCHAR2 60 KMDOCUMENTM1 MS_MODULE_SUBCATEGORY VARCHAR2 60
KMDOCUMENTM1 MS_MODULE_PRODUCT_TYPE VARCHAR2 60 KMDOCUMENTM1 MS_MODULE_PRODUCT_TYPE VARCHAR2 60
KMDOCUMENTM1 MS_MODULE_PROBLEM_TYPE VARCHAR2 60 KMDOCUMENTM1 MS_MODULE_PROBLEM_TYPE VARCHAR2 60
KMDOCUMENTM1 MS_SOURCE_MODULE_ID VARCHAR2 20 KMDOCUMENTM1 MS_SOURCE_MODULE_ID VARCHAR2 20
KMDOCUMENTM1 MS_IMPORT_DATA VARCHAR2 4000 KMDOCUMENTM1 MS_IMPORT_DATA VARCHAR2 4000
KMDOCUMENTM1 MS_IP_OWNER VARCHAR2 40 KMDOCUMENTM1 MS_IP_OWNER VARCHAR2 40
KMDOCUMENTM1 MS_COMPANY VARCHAR2 60 KMDOCUMENTM1 MS_COMPANY VARCHAR2 60 Filter where MS_COMPANY = '<company>'
KMDOCUMENTM1 MS_ORIGINAL_SYSTEM VARCHAR2 60 KMDOCUMENTM1 MS_ORIGINAL_SYSTEM VARCHAR2 60
KMDOCUMENTM1 LOCALE VARCHAR2 20 KMDOCUMENTM1 LOCALE VARCHAR2 20
X X X KMDOCUMENTM1 DVDCONDITION CHAR 1 Default = NULL
18
SM7 Data Migration Phases
– Installation of clean copy of SM 7.11 containing all code and all data
common to all regions
– Adjustment of counters for regional prefixes
– Installation of Data Migration Tool
– Migration of Delivery data common to all companies within a region
– Migration of CI, Client data for base companies HP, DEFAULT, NULL
– Iterative migration of Client data for sets of companies as defined by the
regions
Sample text
Clean Copy Delivery Data CI, Client Data
19
SM7 Data Migration Build
– SC 6.2 source was Oracle 10g, SM 7.11 source was Oracle 11g
– Created database link on source to access target
– Loaded table and column mappings into table on source
– Developed PL/SQL on source to perform migrations
– Selected data from source and inserted into target tables
– Generated inserts for most tables based on mappings
– Developed special handling code for transformations (e.g. single
column to array table, different keys between SC and SM)
– Developed UNIX scripts to execute and verify migrations
– Minor work had to be completed through the SM client
20
Sample SM7 Data Migration Verification
MAPPING COMPANY SC SM DIFF
--------------------------------------------- -------------------- ---------- ---------- ----------
CONTACTSM1 ==> CONTACTSM1 GEFA 77 77 0
DEPTM1 ==> DEPTM1 GEFA 19 19 0
DEVICE2A1 ==> DEVICE2A1 GEFA 68 285 217
DEVICE2M1 ==> DEVICE2M1 GEFA 68 285 217
DEVICEPARENTM1 ==> DEVICEPARENTM1 GEFA 65 65 0
LOCATIONM1 ==> LOCATIONM1 GEFA 6 6 0
OPERATORA1 ==> OPERATORA1 GEFA 39 39 0
OPERATORM1 ==> OPERATORM1 GEFA 38 38 0
SLAM1 ==> SLAM1 GEFA 1 1 0
SLOM1 ==> SLOM1 GEFA 96 96 0
SVCCATALOGM1 ==> SVCCATALOGM1 GEFA 1 1 0
SVCCATALOGM1 ==> SVCDISPLAYM1 GEFA 1 1 0
SVCCATPROFILEM1 ==> SVCCATPROFILEM1 GEFA 26 26 0
21
SM7 Data Migration Timings
– Most tables migrate in less than one second per company
– Delivery Data for EMEA migrated in a few minutes for 459,585 rows
– Largest tables and most complicated mappings take the most time
• contacts
• kmdocument
• svcCatalog, svcDisplay
• Template
– Operators for the EMEA HP company migrated in less than 5 minutes
• OPERATORM1 11,713 rows 262 seconds
• OPERATORA1 13,177 rows 3 seconds
• OPERATORA2 36,263 rows 4 seconds
– Set of 178 companies for EMEA migrated in 2.5 hours
22
Factors for a Successful OutcomeBuy-in to upgrade approach from stakeholders
Adequate, skilled resources committed to project 6 SC/SM engineers + DB engineer
1 Infrastructure engineer
Upgrade Factory consulting for planning
Upgrade Consultant full time
Design Partners – obtain buy-in from key contributors during reconciliation
Strong partnership with HP SW Product Management and Upgrade Factory
Performed detailed impact analysis – documented and reviewed
Revision Control for all reconciliation changes
Functional Review early in upgrade cycle
Migration of custom SC 6.2 operational efficiencies to SM 7.11
Low risk approach to migrating customers to Service Manager
Regional Engineering participation in testing prior to pilot
Phased migration of customers based on complexity of workflow
Communication at all stages – to all Stakeholders
…and lots of planning!!!
23
Service Manager Fast Track Status
Q4/10 +
– Deploy Data Archiving Solution using HP BTO Database Archive
– Migrate Legacy customers to SRA Service Manager
– Archive customer data prior to switching off ServiceCenter
Q3/10
– All SRA ServiceCenter customers migrated– First new customers deployed
Q2/10
Q1/10
– Service Manager stable in production– All regions in production– 200+ Customers migrated
– Deploy SM 7.11 to initial region– 5 pilot customers– Customers added in phases based on complexity
24
HP ES SM 7.11 Upgrade—Questions?
– Subtitle goes here
25 ©2010 Hewlett-Packard Development Company, L.P.
To learn more on this topic, and to connect with your peers after
the conference, visit the HP Software Solutions Community:
www.hp.com/go/swcommunity
26