IBM container licensing – new rules

Image by Julius Silver from Pixabay

IBM have recently announced new rules for licensing their software in containers, a growing technology that makes up part of almost any IT environment. Here we look at some of the terminology involved as well as the new requirements from IBM.

Terminology

There are several new terms with which to become acquainted to understand Container licensing. IBM have listed several here but I want to look at some of them now – as understanding these terms is key to understanding the rest!

Worker Node – this provides an environment for the container to run inside. These sit within a cluster, and more worker nodes can be added to help increase performance. Worker node capacity is measured in virtual cores or physical cores and is reported by the Kubernetes platform.

Pod – this is an instance of an application and could be running on one, or several, containers.

Cluster – Each cluster has one “Master” machine which controls one, or more, worker nodes.

Kubernetes – This is the leading tool for managing containers – it looks after load balancing, scaling, moving containers, restarting containers etc.

Container – This is a small image that contains the software being used.

CPU limit – A Kubernetes setting restricts each container to use a certain amount of CPU resources.

Licensing terms

The next version of the IPAA (v11) will include container licensing terms as standard but for V10 or earlier, a container licensing addendum is required. The addendum can be download via the IBM link below.

It’s important to realise that to be eligible, you must be using Kubernetes-based orchestration – if not, you cannot use this new licensing model. Also, it currently only supports Linux containers.

Counting methodology

It is the vCPU capacity that is being measured.

Every container has a CPU limit – bear in mind, this can be less than 1. The CPU limit of all the containers within a pod will be added together and that is the “vCPU limit of the pod”.

Then, the totals for all the pods within a cluster will be added together, with any fractional values being rounded up to the nearest whole number.
Where the total vCPU capacity of all the pods on a worker node totals to more than the physical capacity of the server, the physical capacity is used as a cap.

Example

You have 4 pods running on a 12-core machine.
You have 12 containers in each pod, and each has a CPU limit of 0.3. The vCPU limit of the pod is 12 * 0.3, which is 3.6.
There are 4 pods so 4 * 3.6 = 14.4 cores, which is then rounded up to 15, and that is your total vCPU capacity. However, it is capped at the physical capacity of 12 cores.

New tool – IBM License Service

In a very IBM move, there is a specific tool which must be used to track all this – “IBM License Service”- not using IBM License Service means you will be charged for all the cores in the cluster. No 3rd party tools are currently permitted, and IBM do not allow manual reporting.

The tool will check the available vCPU capacity at least every 30 minutes and the maximum value will be taken as your available vCPU total. If you have multiple clusters, IBM License Service must be installed and “kept healthy” in each one. As with ILMT, once you have deployed an eligible product, you have 90 days to deploy IBM License Service. You must create quarterly reports, retain them for 2 years and make these available upon request by IBM/auditor. You can obtain IBM License Service by talking to product support or emailing talk2sam@us.ibm.com.

Finally, IBM are keen to stress that IBM License Service does not replace ILMT. If you have both sub-capacity (PVU/RVU) and container environments, you will need to run both tools.

Conclusion

At first sight, this can seem confusing. However – once you understand the new container related terminology – it’s about on a par with traditional IBM licensing. While that’s not exactly simple, it does show that managing containers and their licensing is simply an extension of existing ITAM practices.

Once you’ve got to grips with the info in this article – and containers in general, go and talk to the relevant teams within your organisation. Find out what they’ve deployed already + what they’re planning to deploy, and start to work out the licensing from there.

Further reading

IBM container licensing
IBM FAQ
Kubernetes
Looking into containers (podcast)
ITAM in complex environments – containers