5/5/15 Meeting w/ IBM to discuss TWS
Attendees: M. Aphilpo (IBM), M. Bjorkman, J.Breslow, J.Bruno, P.Carey (IBM), J.Fanton, J.Holewa,
P.McGowan, T.Madigan (remote), S.Martino, M.Thomas, M.Reed
Meeting Purpose: To establish if TWS can meet Harvard’s (HUIT’s) requirements for job scheduling in
the cloud. Update from meeting: Based on our discussion, TWS can indeed meet HUIT’s needs in this
area; however, the specific implementation(s) that are appropriate in the short-term and long-term, as
well as the pricing methodology still need to be determined.
Overarching requirement: Harvard needs the ability to run jobs in the cloud and on-premise, with bidirectional dependencies, i.e. applications/jobs running on platforms in the cloud have dependencies
on applications/jobs running in Harvard data centers; and applications/jobs running in Harvard data
centers have dependencies on applications/jobs running on platforms in the cloud. In many cases, these
dependencies are complex, for example the case where Application A/Job A must wait for a future
condition to occur in Application B/Job B. A & B could span internal data centers and AWS.
Major Discussion Points:
1. Dynamic (TWS) Agent v. Fault-tolerant Agent (FTA). Harvard currently runs the FTA on its
internal (on-premise) infrastructure. The FTA has been around for approx. 20 years. The
Dynamic Agent represents IBM’s future direction; it’s where all new features and integration will
occur. Both the Dynamic Agent and the FTA will run on-premise and in the cloud.
2. Harvard is currently running TWS v8.6. TWS 9.2 is the latest version of TWS generally available.
3. Harvard job statistics:
a. Approx. 30,000 jobs per day – jobs range from small housekeeping/cleanup &
monitoring jobs to jobs that perform significant business functionality, e.g. Payroll.
b. Equals 900,000 jobs per month
c. Equals 11 million jobs per year
4. It was noted that many of the jobs that are run today are not relevant once applications are
moved to the cloud. How many jobs will be eliminated? What types of jobs will be eliminated?
5. There is a “pool” concept for TWS whereby multiple TWS (servers) Masters can be part of a
pool. If a server/master is down, jobs will be directed to another server/master in the pool –
appears to represent some level of fault-tolerance/high availability. Note: TWS pools are
separate and distinct from AWS pools.
6. Pricing options:
a. Processor Value Unit (PVU) – Pricing is based on the size of machine TWS is running on
(as measured by CPUs/Cores). This is what Harvard does today (w/ ILMT monitoring,
reporting, & auditing)
b. Price per Job – Pricing is based on the number of jobs run.
c. Unlimited license – some sort of (negotiated) Enterprise license
7. License compliance
1
a. The IBM License Monitoring Tool (ILMT) does not currently run on any cloud platforms.
b. License compliance (for TWS instances running on cloud platforms) is completely
manual.
8. An “experimentation” phase (six months was suggested) was discussed that would allow
Harvard to:
a. Implement one of the TWS implementation options (below) in an effort to: i) kick the
tires, and ii) meet the (short-term) scheduling requirements for the first several
applications that will be migrating to the cloud, while
b. Performing more due diligence around the implementation models and pricing options
in order to arrive at an optimal (future) state.
TWS Implementation Options (Note: There was not an extensive discussion about the pros/cons of each
option as it was determined more information around Harvard’s requirements is necessary to have a
productive discussion.)
1.
2.
3.
4.
On-premise Master+FTAs in the Cloud
On-premise Master+Dyanmic Agents in the Cloud
On-premise Master+Master in the Cloud
On-premise Master+(Backup) Master in the Cloud (w/ DataGuard replication from Master to
Backup) Note: this would require a full Oracle implementation in AWS as DataGuard replication
is not currently support on AWS/RDS.
5. Master in the Cloud+Agents in the Cloud and On-premise
6. TWS SaaS
a. Pricing is on a per job basis @ $70/1000 jobs/month
b. Based on Harvard’s current volume (as noted above) this translates to $63,000/month
or $756K per year (current Harvard cost to run TWS is approx. $200K)
Actions:
 IBM – Provide Harvard with details around how hostname communication between masters and
agents works (Note: a reliable hostname is required for communication.)
 IBM – Provide information on the ports that TWS uses to communicate.
 Harvard – Provide IBM with some detail around application migrations (after the next PI planning
session being held on 5/29/15)
 Harvard – Develop (at some point) a (future) operating model that specifies where/how jobs get run.
Note: Today’s model is that production jobs are controlled and run centrally (by Computer Operations
staff); customers have the ability to control jobs in lower environments using a web interface.
 Harvard (Magnus & Joel) – Develop a (future) profile for job scheduling that details, what jobs will be
eliminated [as applications migrate to the cloud] and what jobs will remain.
2
 Harvard (Magnus & Joel?) – Map the future job scheduling profile (from above) to the application
migration plan to show the number of jobs that will be reduced (and that will remain) based on the
(phased) migration plan/timeline.
 Harvard – Define the experimentation phase (see #8 in Discussion points, above) – applications, job
scheduling requirements/scenarios. Note: This will occur just after the next PI planning session (on
5/29/15).
3