tws common upgrades and migration reasons and … - nov2014 - … · tws common upgrades and...
TRANSCRIPT
TWS common upgrades and
migration reasons and methods
Probal Sil, Elyzium Limited
13th November 2014
TUG – TWS Track
1
PURPOSE OF THE SESSION
This presentation is
designed for scheduling
architects and
administrators who are
looking to extend their
distributed Tivoli
Workload Automation
usage.
Design
Implementation
Testing
The outcome of the session will
give attendees a high level overview for TWS upgrades and migrations.
2
INTRODUCTION: WHY DO THIS?
Single Pane of Glass view of end to end scheduling
Cost reduction by consolidating products and internal support costs
Reduce risk of future upgrades across multiple products
Provide a robust and resilient workload automation platform
Provide an API to application development teams
Common Strategic Objectives for Workload Automation:
3
REASONS FOR UPGRADE OR MIGRATION
• When running a vendor unsupported version
• Similar to data center move with a transition and transformation plan
• Server consolidation project
• e.g. SAP upgrade
Application Upgrade
Data centerMove
ComplianceChanging
Outsourcer
4
1. TWS Infrastructure
2. TWS Scheduling
A single pane of glass to manage and monitor
heterogeneous Job Scheduling.
Components include:
Jobs, Job Streams, Calendars, Event Messages
TWS Infrastructure consists of the following
components:
Managers -
Master (MDM), Backup Master (BDM), Domain
Managers (DM) and Console (TDWC)
Agents –
Fault Tolerant Agents (FTA), Standard Agents
(SA), Extended Agents (XA)
BASELINE:
WHAT IS TIVOLI WORKLOAD SCHEDULER?
5
PVU
PJP
Cloud
DESIGN
TWS Infrastructure
Mainframe Centric v Dual Centric
Licensing PVU
PJP
Cloud Based PJP
Network & Database Resilience & Performance
Sub capacity Licensing
ILMT is a prerequisite
Scheduling Considerations
Where is the source of jobs?
Native Schedulers
Third Party products
Job Dependencies
6
LICENSING OPTIONS: PVU or PJP?
PVU
Positives• One time cost
Negatives• Too expensive to run on all
servers so only critical servers
have TWS
PJP
Positives• Lower cost of entry
• Ideal for servers requiring a
small number of jobs
Negatives• Increased administration in
generating reports
7
HOW TO CALCULATE PVU’s
• In TWS/d 8.5.1 introduced wscanhw at part of CIT
• /opt/tivoli/cit/bin/wscanhw
• c:/program files/tivoli/cit/bin/wscanhw
OUTPUT:
<PhysicalProcessor …>
<Manufacturer>Intel</Manufacturer>
<Family>Pentium 4</Family>
<Type>3.20EGHZ</Type>
<Brandname>Intel(R) Pentium(R) 4 CPU
3.20GHz</Brandname>
<ActiveProcessorCount>2</ActiveProcessorCount>
<ActiveCoreCount>1</ActiveCoreCount>
</PhysicalProcessor>
PVU Count:
• 2 procs x 1 core x 50 proc type = 100 PVU
8
HOW TO CALCULATE PJP
By default TWS will only
hold job information for
10 days.
• Optman chg sh=400
Now wait for 30 days to
gather minimum data
• SELECT year(job_run_date_time) AS Year, month(job_run_date_time) AS Month, (cast (count(job_run_date_time) AS smallint)) AS JobNbr FROM mdl.job_history_vGROUP BY year(job_run_date_time), month(job_run_date_time)
Put it in a
spreadsheet
9
IMPLEMENTATION
Manager
deployment or
upgrade
• Add or Increase
functionality
Agent
deployment or
upgrade
• Usually to the
same level as the
manager
• Including fix pack levels
Handling
exceptions
• Unsupported OS
• Upgrade OS
• Older agent
• Ring fence
• Remote Access only
• Agentless
10
INFRASTRUCTURE UPGRADE OPTIONS
Direct Upgrade
Advantages
• No additional hardware required
Disadvantages
•Multiple agents upgrades
•Agent downtime required or multiple agents
•Support issues at older version
•Limited testing can be performed to minimise downtime
Parallel Upgrade
Advantages
•Minimal disruption to batch
•Failback to old environment
•User testing of the batch can be performed without affecting the current batch
Disadvantages
•Involves some manual configuration steps
•Additional support requirements with two infrastructures
11
SCHEDULING MIGRATION
There are two methods for scheduling migration:
Infrastructure upgrade will
dictate approach
By environment gives minimal
disruption
No Cross application scheduling
dependencies will be affected
by this approach
Scheduling testing will be mainly on Pre-
Prod & Prod
Training usually on Dev
Environment
By environment By application
12
TESTING
Involve stakeholders early
• Agree the test plan as part of the design
TWS Infrastructure Testing
• Dual agent running
• Consider bind requirements
TWS Scheduling Testing
• Dual schedule running
• Forecast mode for new jobs
13
SUMMARY
DO have a strategy for Workload Automation
DO consider the license impact of your design
DO have a thorough Test Plan
DON’T discount the Cloud
DON’T be scared of risk
DON’T forget to call Elyzium ☺
14
