How are "managed nodes" defined as part of the Red Hat Ansible Automation Platform offering?
Red Hat Ansible Automation Platform is sold and supported by counting the number of "managed nodes" in the customer's environment. The following article defines what a managed node is, and what are the business rules surrounding this concept.
NOTE: The following is abstracted from official Red Hat Enterprise Agreements, specifically Appendix 1, Software Support and Subscriptions.
A "managed node" is defined as the following per Appendix 1 above:
Each Node managed by the Software. “Node” means a Virtual Node, Physical Node or other instance of software.
This definition is broad enough to apply to all Red Hat products, but as applied to Red Hat Ansible Automation Platform, managed nodes are any "Node" managed by the Red Hat Ansible Automation Platform software.
"Managed Node" refers to a Virtual Node, Physical Node or other identifiable* instance of Software and/or Configuration being directly or indirectly managed by Red Hat Ansible Automation Platform.
Examples of managed nodes that should be accounted for include but are not limited to:
-
Servers, Virtual Machines and other physical devices e.g. Storage Arrays
-
Containers, appliances, software instances (database, middleware, applications) and other virtual devices
-
SDN, Wireless and other Networking Controllers
Managed Node Use Cases:
-
For clustered technology platforms being directly managed, or managed indirectly via an API, each instance of technology within a managed cluster counts as a managed node.
-
For physical or virtual instances being directly managed by Ansible, where Ansible identifies and connects to the instance, each instance counts as a single managed node.
-
For identifiable* physical or virtual instances being indirectly managed by Ansible behind an API, each instance counts as a single managed node
-
For infrastructure or application software instances being directly managed or managed via an API, each instance counts as a managed node.
"Identifiable" is defined as a managed node that may not be directly known to the Ansible control node, but upon instruction, is indirectly known via device or instance name from an intermediate management controller.
Ansible may manage nodes from multiple different access paths based on the above use cases. In the event that this results in multiple host identifiers for a given host in Ansible inventory, it does not increase the required host entitlements for the customer. That is, a managed host is not "charged" multiple times based upon multiple automation actions or methods targeting that host.
Ansible Automation Platform users may not manage a total estate of more than the number of Managed Nodes entitled. Examples of this include cycling, rotating, or otherwise pulling Managed Nodes through the Ansible Tower / Automation controller Software in subpart increments or via removal or clearing of data from the Tower / controller Database.
