Available from
9.2.22.
You can install License Metric Tool based on the BigFix® platform or use disconnected scanners managed by
Ansible. Review the comparison of both approaches and choose the one that is most suitable for your
environment and needs.
In large-scale environments, environments in which the majority of computers run on Windows or if
you already use BigFix for other purposes, it is
recommended to use License Metric Tool with BigFix. License Metric Tool better integrates with BigFix than with Ansible. For example, BigFix can be preinstalled by using the License Metric Tool installer. BigFix also provides better automation and usability when
compared to the basic Ansible solution that is based on the command-line.
Ansible can be a good choice for environments in which the majority of computers run on Linux or
UNIX or if you already use Ansible for other purposes.
A mixed environment with both BigFix and
Ansible is also supported. In this case, Ansible is usually used on the computers on which the
BigFix client cannot be installed.
Total cost of ownership and serviceability
Table 1. Total cost of ownership and
serviceability
|
BigFix |
Ansible |
Solution overview |
- BigFix is a platform that acts as the core
part of the global IT infrastructure. For more information, see: BigFix platform.
|
- Ansible is an open source platform for remote computer management used mainly for IT automation.
For more information, see the Ansible website.
|
Support |
- BigFix is fully supported by IBM when it is
used for License Metric Tool.
|
- Ansible is an open source project and does not have official specialized support.
- Official Ansible support is provided by Red Hat if you use Red Hat Ansible Tower. For more
information, see the Red Hat Ansible Tower website.
- IBM provides support for problems with playbooks that are delivered with License Metric Tool. However, it does not provide support for problems
that are related to the configuration of Ansible. For information how to report issues related to
Ansible, see: Reporting bugs and requesting features.
|
Security
Table 2. Security
|
BigFix |
Ansible |
Required rights |
- Root or administrator rights are always required.
|
- To use Ansible to collect scan results that are generated by the disconnected scanner, root or
administrator rights are not required. In this case, the disconnected scanner must be installed
independently and root or administrator rights are necessary during its installation.
- To fully manage the disconnected scanner with Ansible (install, upgrade, configure, and
uninstall the disconnected scanner) root or administrator rights are required.
- The root or administrator rights are required during the scans. For the rest of the time, no
background processes that require these rights are running on the endpoint.
|
Direction of communication |
- Communication is two-way: from the endpoint to BigFix server and from the BigFix server to endpoints.
- It is possible to configure one-way communication: from the endpoint to the BigFix server. However, it is not advised due to usability
and performance reasons.
|
- Communication is always one-way: from the Ansible control node to the managed nodes.
|
Port exposure |
- It is not required to expose any ports on the endpoint. The endpoint only needs to have network
visibility of the BigFix server or BigFix relay if it is used.
- Communication from the endpoint to the BigFix
server by default goes through port 52311.
|
- All endpoints need to expose some port over the network to be visible to the control node.
Usually, it is SSH port 22 on Linux and UNIX, and HTTPS WinRM port 5986 on Windows.
- In order for the Ansible control node to connect to the endpoints, the list of managed inventory
needs to be created. The list includes information about the connection method and credentials (user
and password or user and the SSH key). Such a list needs to be stored on the file system of the
control node.
|
Scalability and performance
Table 3. Scalability and
performance
|
BigFix |
Ansible |
Scalability |
- License Metric Tool with BigFix can support up to 250000 endpoints.
- To support a large number of endpoints, a BigFix relay needs to be set up for each 5000 endpoints.
|
- Ansible can be used to deployments of up to 125000 endpoints.
- In case of large-scale deployments, it might be necessary to use more than one Ansible control
node to distribute the workload.
- AWX or Red Hat Ansible
Tower are required in medium-sized and larger deployments to manage the endpoints
reasonably.
|
Hardware requirements |
- The amount of resources that is required on the endpoints is noticeable.
- The BigFix client always runs in the
background and thus consumes resources such as CPU and RAM.
|
- Due to the agentless nature of Ansible, there is no Ansible-related performance overhead on the
endpoints when Ansible playbooks are not running.
- The scanning overhead is comparable in both Ansible and BigFix approaches.
- Ansible documentation does not describe the exact amount of hardware resources that is required
for the control node. However, there is a general rule that the more managed nodes, the more
hardware resources are required. For more information, see: Ansible Performance Tuning.
|