TWS Licensing

TWS Licensing can be performed (based on the needs):

1. Using PVU (Processor Value Unit) licensing  - recommended for a high number of jobs.
2. Using per jobs licensing - recommended for a high number of servers where the jobs needs to run

   1. PVU (Processor Value Unit) licensing it is a unit of measure by which the program can be licensed. The number of PVU entitlements required is based on the processor technology defined by processor value, brand, type, and model number in other words it is based on the CPU cores available to the machine (server) physical / virtual where TWS is deployed and runs jobs, a detailed list can be found on IBM site in PVU table.
e.g. An AMD Opteron: 1 socket with 8 cores per socket has a PVU value of: 1 x 8 x 50 = 500
An Oracle/Sun SPARC M6: 8 sockets with 6 cores per socket has a PVU value of: 8 x 6  x 120 = 5760

Also TWS PVU Licensing supports Sub-Capacity (Virtual) Licensing, in some cases, which in short words you only need to license the cores assigned to a virtual machine rather then the whole cores of the physical one (more details can be found on IBM Passport Advantage Virtualization Capacity (Sub-capacity) Licensing page).
e.g. In you have a Linux farm of 64 physical cores and a virtual machine with 8 cores assigned and it is running TWS you can licence only 8 cores.

!!!!!! Important For Sub-Capacity (Virtual) Licensing iLMT (IBM License Metric Tool) needs to be deployed on each of the systems for which you want to apply the Sub-Capacity licensing.

!!!!!! Important For TWS For Applications the Sub-Capacity (Virtual) Licensing doesn't apply, always you need to license the physical cores on the machine (be careful where you deploy TWS for Apps)

   2. Per jobs licensing in other words you will licence the number of jobs ran (aka 10 MONTHLY JOBS License).
e.g.
Number of daily executed jobs: 500
Number of monthly executed jobs (multiply by 31 ): 15,500
Number of groups of 10 jobs: 1,550 (divide by 10 as the part is per 10 Monthly Jobs)
List price of IBM Workload Automation for 10 jobs equals: X
List price is calculated at 1,550 job packs of 10 jobs multiplied by X.


Additional details about Standby or backup systems — For programs running or resident on backup machines, IBM defines three types of situations: cold, warm and hot. In cold and warm situations, a separate entitlement for the copy on the backup machine is normally not required and typically no additional charge applies. In a hot backup situation, the customer needs to acquire other licenses or entitlements sufficient for that server.

• Cold: A copy of the program may reside, for backup purposes, on a machine as long as the program is not started. There is no additional charge for this copy. 
• Warm: A copy of the program may reside for backup purposes on a machine and is started, but is idling, and is not doing any work of any kind. There is no additional charge for this copy. 
• Hot: A copy of the program may reside for backup purposes on a machine, is started, and is doing work. The customer must acquire a license or entitlement(s) for this copy and there will generally be an additional charge. Doing work includes, for example, production, development, program maintenance, and testing. It also could include other activities such as mirroring of transactions, updating of files, synchronization of programs, data, or other resources (for example, active linking with another machine, program, database or other resource, and so on), or any activity or configurations that would allow an active hot switch or other synchronized switch-over between programs, databases, or other resources to occur. In the case of a program or system configuration that is designed to support a high availability environment by using various techniques (for example, duplexing, mirroring of files, or transactions, maintaining a heartbeat, active linking with another machine, program, database, or other resource), the program is considered to be doing work in the hot situation and a license or entitlement must be purchased. 

!!! Note: For TWS masters, if they run only TWS application jobs e.g. FINAL, the licence is not required.

Examples of calculation:
A TWS env. as in the picture below:

And the current price for both cases:

The licence calculation will be:
1. Using PVU licensing:

• ERP Server: Oracle/Sun SPARC M6: 8 sockets with 6 cores per socket PVU usage: 8 x 6 x 120 = 5,760
• Warehouse: AMD Opteron: 2 sockets with 8 cores per socket PVU usage: 2 x 8 x 50 = 800
• ETC: Intel Xeon 7500: 1 socket with 6 cores per socket  PVU usage: 1 x 6 x 120 = 720
• TWS Master doesn't run jobs no PVU usage.

For 1 year the TWS PVU licence and support will be: (5,760 + 800 + 720) x 40.5 = 294,840 USD

2. Using per jobs licensing:

• ERP Server: running 500 jobs / day, in a month 500 x 31 = 15,500, divide by 10 as the part is per 10 Monthly Jobs is 1,550 groups
• Warehouse: running 50 jobs / day, in a month 50 x 31 = 1,550, divide by 10 as the part is per 10 Monthly Jobs is 155 groups
• ETC: running 10 jobs / day, in a month 10 x 31 = 310, divide by 10 as the part is per 10 Monthly Jobs is 31 groups
• TWS Master doesn't run jobs no PVU usage.

For 1 year the TWS per job licence and support will be: (1,550 + 155 + 31) x 56.25 = 97,650 USD.

So in this particular case TWS per job licence will be the best fit as it costs ~67% less.

TWS & TDWC MS AD integration

In this post I will describe how to set-up a MS AD (Microsoft Active Directory) users integration for TWS & TDWC directly using WebSphere (for Windows machine there is another way using the OS capabilities).

Prerequisites: A MS AD (Microsoft Active Directory) account (service account preferred) that will be used to connect to MS AD and read its repository.
For both TWS and TDWC the set-up is identical (if they both run on the same WebSphere it needs to be performed only once).

To set-up the TWS / TDWC and MS AD integration:
   

   1. Login to WebSphere admin page:

• Directly: https://:31124/ibm/console/secure/securelogon.do?action=force (this si the default link)
• From TDWC:

                    

   2. Go to Security -- Global Security, and under User account repository set Current realm definition as Standalone LDAP registry (to use a single repository, e.g. MS AD only) or Federated  repositories (to use multiple repositories, e.g. MS AD, Local Server Account).

!!!!! Important: If the account name is not unique across Federated  repositories the user WILL NOT be authenticated, be very very careful with this.  

 
   3. Then go to Configure ... -- Manage repositories (Under Related Items) and click Add

   4. On LDAP server under Directory type select Microsoft Windows Active Directory and fill in the data as:

• Repository identifier -- just a display name
• Primary host name -- your Microsoft Active Directory (MS AD) domain controller server name (DNS name) or fully qualified domain name (FQDN) or  IP address
• Port -- the server port that will be used to connect to MS AD in order to get users data (default: 389)
•  Bind distinguished name -- specify the distinguished name for the application name to use when binding to the MS AD repository 

e.g. CN=user_name,OU=IT,OU=TM,OU=RO,DC=europe,DC=ad,DC=company_name,DC=com

• Bind password -- specify the password for the application server to use when binding to the MS AD repository (in short: the password for user_name on the Bind distinguished name field)

Press OK and if you opted for Standalone LDAP registry go to the last step (8).

   

   5. Go to Global Security -- Federated  repositories -- Repositories in the realm: -- Add Base entry to Realm...

   6. On Repository reference select:

• Repository -- The one you created at step 4.
• Distinguished name of a base entry that uniquely identifies this set of entries in the realm -- specify the distinguished name of a base entry that uniquely identifies this set of entries in the realm

e.g. DC=ad,DC=company_name,DC=com

Press OK

   7. Press Apply and Save directly to the master configuration.

   8. Restart the WebSphere.

Now the users authentication is performed using MS AD (only MS AD or and MS AD). Also you may use MS AD groups or DL (distributions lists) to grant rights in TWS and / or TDWC.

Multiple-masters domain enSwFaultTol set-up

The multiple-masters domain (e.g. containing back-up / DR masters and/or "FULLSTATUS ON" FTA's) biggest challenge is to make sure there is no loss on jobs details (messages) in case the primary master is out of order and we need to promote another master or "FULLSTATUS ON" FTA's to primary master.

There is a global variable called: enSwFaultTol enable or disable the fault-tolerant switch manager feature which basically does changes the flow of communication inside TWS environment:

 enSwFaultTol / sw = NO The FTA's are connected and are sending the jobs data to primary master and other masters and / or "FULLSTATUS ON" FTA's are getting in sync with primary master.

enSwFaultTol / sw = YES The FTA's are connected and are sending the jobs data to each master and / or "FULLSTATUS ON" FTA's independently.

Below is  a diagram representing only the communication channels that are impacted by the above variable.

Default is NO but my recommendation is to change it to YES, even if IBM recommends NO (I've had several meetings with IBM support on this topic but they did not convince me to use it as NO).

Why?

• enSwFaultTol / sw = NO biggest downsize is that in case of primary master being in a freeze state you will lose all the jobs messages sent to it by FTA's until the new primary master promotion. It happened to me several times and we lost up to several hours worth of data. 
• enSwFaultTol / sw = YES the above scenario won't happen as all the other masters or "FULLSTATUS ON" FTA's are receiving all the jobs messages but its small disadvantage is an increase network traffic as the data is sent to multiple servers. 

 My strong recommendation, even is it against IBM one, is to use enSwFaultTol / sw = YES on a multiple-masters domain.