Red Hat Ansible Automation 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.
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 it applies to Red Hat Ansible Engine and Red Hat Ansible Tower, managed nodes include any nodes that are indirectly managed by the software.
Examples of managed nodes that should be accounted for include (but not limited to) the following:
- SDN, Wireless, and other Networking Controllers
- Endpoints that sit behind front-end API endpoints
A detailed example:
Red Hat Ansible Tower is running playbooks using the Cisco ACI modules, and executing tasks against any number of Cisco ACI controllers. If a single Cisco ACI controller is managing 999 Cisco Nexus switches, one must purchase enough Red Hat Ansible Tower subscriptions for the Cisco ACI controllers as well as the end devices Cisco ACI is managing. In this case, 1000 Red Hat Ansible Tower subscriptions should be purchased for support and compliance. For further clarity, Client may not manage a total estate of more than the number of Managed Nodes procured by way of cycling, rotating, or otherwise pulling Managed Nodes through the Ansible Tower Software in subpart increments. For example, if Client has procured one thousand (1,000) Managed Nodes of Ansible Tower, Client may not utilize Ansible Tower to manage five thousand (5,000) Managed Nodes, regardless of pulling Managed Nodes through Tower in increments of one thousand (1,000) at a time, and must purchase the applicable number of Subscriptions covering five thousand (5,000) Managed Nodes.