SKU descriptions may include graphics processing unit (GPU) along with CPU and vCPU for the purpose of sizing/counting parity with other product SKUs, however actual product/component operating requirements need to be considered when determining where a component can be deployed.
Red Hat Application Services “everywhere”
Red Hat Application Services subscription licensing is very flexible. Subscriptions are licensed and supported across multiple OS and hardware platforms (see supported and tested configurations page) and across any mix of on-premise, private cloud, and public cloud deployment environments. Subscription entitlements also provide value throughout the full application development and deployment life cycle.
Core edition subscription licensing flexibility eliminates the need to purchase products for a particular deployment environment (e.g., public cloud), OS or container platform (e.g., Red Hat Enterprise Linux or Red Hat OpenShift), or lifecycle phase (e.g., development). No additional purchases are needed when you move from any one of these environments to another during the term of a subscription. However, keep in mind that cluster and bare-metal edition subscriptions are limited to deployment on Red Hat OpenShift. See the “Subscription rules” section of this document for details.
Subscription flexibility is further highlighted by packaging of multiple components for complete cloud-native architectures into Red Hat Application Foundations and Red Hat Runtimes. These products deliver the ability to flexibly deploy included components and the ability to change the usage combination of licensed components at any time during the term of a subscription. These subscriptions entitle a shared pool of units that can be used across the eligible and included components.
Deployment options include public cloud providers, such as Amazon Web Services, IBM Cloud, Microsoft Azure, Google Cloud, and Alibaba Cloud. This provides a flexible and holistic application environment across physical, virtual, and cloud deployments.
Cores for required external supporting capabilities, such as databases, should not be included in counts. Additionally, cores used for the following component-specific operations may be excluded from counts:
- Zookeeper for streams for Apache Kafka
- KRaft controller only nodes for streams for Apache Kafka (cores used for mixed nodes will be charged)
- API gateway instances for API Management
Red Hat Application Services subscriptions are to be counted using the same vCPU-to-core ratio that is used by the cloud provider to handle routine hyperthreading. This is commonly 2 vCPUs per core, but may vary with specialized processor hardware configurations. Each vendor describes this conversion. For an example, consult the AWS guide.
Non-OpenShift use guidelines
The following principles apply to noncontainerized subscription deployments, such as application services on Red Hat Enterprise Linux on a physical server in a datacenter.
Physical cores, virtual cores
- Physical cores are our standard unit of measurement.
- Physical cores may be deployed across multiple CPU sockets, CPUs, or servers.
- Virtual cores, or “virtual CPUS (vCPUs),” are physical cores used for individual virtual environments or virtual machines (VMs).
- Virtual cores and vCPUs can be counted, but need to align with physical cores.
- If physical cores can be counted when deploying in a virtualized environment, then these units will be counted.
- If you do not know which or how many physical cores in a CPU socket-pair use our software, then we charge for all of the cores in the CPU socket-pair.
- You need to count all cores or vCPUs in a CPU socket-pair unless they are using known core-limiting software that limits the use of our software within that socket-pair.
- For auto-scaling configurations, the subscription cores should be set to the limits of cores that may be used to ensure that the entitlement provides sufficient coverage.
Virtual machines
- You can create a variable-sized VM within a CPU socket-pair. VMs are built atop underlying physical cores. We count the physical cores that contain the VM.
- If use of our software is limited to a VM that only uses a subset of physical cores in the socket-pair, then we only count those physical cores associated with the VM.
- You need to count all cores or vCPUs within a VM unless you are using known core-limiting software that limits the use of our software within that VM.
Hyperthreading, vCPUs
- Hyperthreading creates more, but smaller, vCPUs across a fixed number of physical cores. The vCPU has become a common logical unit of measurement in cloud-based platforms. With noncompute intensive apps, customers can take advantage of the larger number of hyperthreaded vCPUs without expanding the physical core use.
- Hyperthreading does not change counting rules. Red Hat will continue to charge for the underlying physical cores, and when hyperthreading is actively used for Red Hat products, vCPUs can be counted using the common (2) vCPU-to-(1) core ratio.
- If you only know the vCPU count and not the physical core count, we will allow 2:1 if hyperthreading is being used. We will count 1:1 if hyperthreading is not in use.
On Red Hat OpenShift (containerized deployment) use guidelines
Unit counting on container platforms, such as Red Hat OpenShift, has some differences in comparison with noncontainer deployments.
Cluster editions
Application Services products with cluster editions are designed to provide consistency and flexible deployment across the entire Red Hat OpenShift environment. Red Hat recognizes that not all components will be used on each Red Hat OpenShift core across the entire environment and offers favorable pricing for cluster editions to provide customers with a cost-effective and flexible option to deploy any included component at any time during the term of the subscription on Red Hat OpenShift. The total core count for cluster editions must equal the total core count for Red Hat OpenShift during the entire subscription term. See Appendix 1 for details.
Bare-metal editions
Products with bare-metal editions may only be deployed machines using Red Hat OpenShift bare-metal products.
What is the same as noncontainer deployment?
- The vCPU/core remains the countable unit for entitlements and license tracking. Container platforms measure pods and nodes within a cluster. But, these are user-defined groupings of vCPUs/cores.
- For auto-scaling configurations, the subscription cores should be set to the limits of cores that may be used to ensure that the entitlement provides sufficient coverage.
What is different from noncontainer deployment?
- Red Hat OpenShift (or the container platform) automates the starting and stopping of application services workload instances. This simplifies Red Hat’s entitlements counting policy to charging only for cores or vCPUs that are concurrently running at any given time during the subscription period.
- Cores used for Red Hat component and product operators do not count against the subscription limits.
- It does not matter where the application services workload gets deployed within the overall cluster. As long as the concurrent use of cores remains at or below the level of the active subscription, no cores need to be added to a subscription.
- Core/vCPU sizes of container instances are individually tracked, logged, and summed together—even partial vCPU or subcore instances—for any given period of time. For billing purposes, this summary is rounded up to the nearest whole selling unit, with a minimum of 2 cores.
- Only the sum of all instances used at any given time needs to be rounded up to a multiple of SKU units. Any individual container instances can be measured in partial core sizes.
You may choose to set predefined limits on Red Hat Application Services workload sizing by limiting a workload to specific nodes in a cluster. This approach may offer certain advantages to a customer, but is not required by Red Hat for metering or counting purposes.
Note: If you purchase the same number of Red Hat Application Foundations cores as the number existing in your Red Hat OpenShift cluster, for example, there is no need to count the number of Red Hat Application Foundations cores running during any given period. The Red Hat OpenShift cluster can have unlimited Red Hat Application Foundations use within this cluster. This is a primary advantage of cluster editions, which equip you with the flexibility to deploy components across the Red Hat OpenShift cluster as needed at any time.
Metering of Application Services use on Red Hat OpenShift
Red Hat Application Services subscriptions are license-only enforcement. Red Hat does not deliver any tooling that restricts the deployment of application services products based on any subscription limits.
On public clouds: Use guidelines
We highlighted earlier in this subscription guide that Red Hat Application Services subscription licensing is very flexible. Subscriptions are licensed and supported across multiple OS and hardware platforms and across any combination of on-premise, private cloud, and public cloud deployment environments. This means that unit counting of cores and vCPUs on public clouds uses the same approach as on-premise (noncontainer deployments) or on Red Hat OpenShift (container deployments).