Considerations for Inventory Beacons

The inventory beacons in your network may be arranged in ways that meet your requirements. For example:
  • You may use a flat arrangement where each inventory beacon communicates directly with the central application server
  • You may arrange them in a hierarchy, where the top-level inventory beacon(s) communicate with the central application server, and further inventory beacons are arranged as 'children' that communicate with the inventory beacon(s) above them in the hierarchy.

There are no formal limits to the structure of this hierarchy. It may contain as many levels as you require. However, good network design typically means that your hierarchy has two or three (or rarely, four) levels.

The following considerations should assist in your network planning.

Fan-out

These are general guidelines. You should adjust expectations based on experience in your own environment:
  • Provide one inventory beacon for every 20,000 (or so) devices with the locally-installed FlexNet Inventory Agent. In general, policy downloads, and inventory and usage file uploads, place negligible demands on CPU, memory and disk space on the inventory beacon. However, you may be constrained by other network throughput limitations, and by factors such as network proximity of the installed FlexNet Inventory Agents to at least one local inventory beacon. Here are some typical network load figures per device interacting with an inventory beacon:
    Task Network load

    Inventory upload

    10-200 KB per upload (low range for desktops and the like, higher range for UNIX-like servers)

    Usage file uploads

    5-20 KB per day (or zero when you are not tracking usage)
    Policy update 10-100 KB per policy update (only occurs when policy is changed)
    Remember: You cannot specify particular allocations of devices to inventory beacons: the FlexNet Inventory Agent is a state-based tool that manages itself to match its downloaded policy, and as part of its self-management, it chooses which inventory beacon to use for data uploads and policy downloads. The default algorithm looks first for an inventory beacon in the same site as the inventory device, then for the best ping response time, with a randomizing tie-breaker. Therefore the above guideline is about the quantitative planning; and you should use other factors to determine the placement of inventory beacons. These other factors include your network topology, including placement of firewalls, or having multiple domains without cross-trust, and the like. Any isolated subnets or the like require a dedicated inventory beacon so that all installed FlexNet Inventory Agents have full network access to at least one inventory beacon.
  • An inventory beacon may also gather inventory from other systems, such as importing inventory gathered by Microsoft Endpoint Configuration Manager (previously Microsoft SCCM) or IBM's ILMT ('third-party inventory'). Since you control the schedule for the collection of third-party inventory, you can stagger the times for different kinds of inventory; and a result, one inventory beacon can easily handle multiple third-party inventory sources.
  • Similar considerations apply to the collection of any business information through an inventory beacon. Arrange the schedules for business importer operations to spread the load on the relevant inventory beacon.
  • If you are arranging a hierarchy of inventory beacons in a very large system, you should limit the fan-out from a parent inventory beacon to less than 100 child inventory beacons.

Minimum of one per subnet

It is best practice to deploy at least one inventory beacon into each separate subnet that contains target devices for which you may want an inventory beacon to execute discovery and inventory gathering. Being within the target subnet allows the inventory beacon to reliably use ARP or nbtstat requests to determine the MAC address of a discovered device (reliability of these results is reduced across separate subnets). If you do not place an inventory beacon in each subnet:
  • It is possible that, across subnet boundaries, only an IP address can be found for a device (that is, the device data is missing both a MAC address and a device name).
  • In this case, a central record is created for the discovered device, but because IP addresses may be dynamic (unreliable identifiers), this record is not matched (or merged) with more complete records (those which also contain either or both of the MAC address and a device name).
  • As a consequence, on data import you may produce multiple discovered device records with duplicate IP addresses:
    • One record may be complete (for example, automatically created by FlexNet Manager Suite from inventory when it could not find an existing, matchable discovery device record to link to the inventory device record)
    • One or more others may be discovery records that are missing identifying data as discussed.
  • Since these complete and incomplete records cannot be merged automatically, you are left with a manual task to clean up the incomplete duplicates.
  • What's worse, even after that manual clean-up, if the situation persists and an applicable discovery rule is re-run, the incomplete record is recreated.
You avoid all these risks by simply having a local inventory beacon in the same subnet as target devices. Being in the same target subnet means that the inventory beacon can provide both the IP address and the MAC address, which is sufficient for matching discovered device records. If you must do discovery across subnet boundaries without a local inventory beacon, ensure that there are full DNS entries visible to the inventory beacon for all devices you intend to discover. This allows the inventory beacon to report both an IP address and a device name or fully-qualified domain name (FQDN), which combination is again sufficient for record matching.

Bridging to IPv6 subnets

All inventory beacons can operate within subnets configured to use either IPv4 or IPv6 addressing; and FlexNet Inventory Agent can also handle all data transfers within either environment. However, the link to the central application server must use an IPv4 network protocol. The need to support the IPv4 protocol at the top level of the architecture, and the IPv6 protocol at the low level with the local FlexNet Inventory Agent, means that at least one inventory beacon must be a dual-stack server that provides the bridge between the two protocols, as shown in the following architectural sketch:
IPv6 architecture on-premises

Reading from top to bottom, this sketch shows:
  • Your application server (or in larger implementations, multiple servers) continue(s) to support HTTP or HTTPS communications over an IPv4 network layer.
  • Within IPv4 zones of your network, you may deploy as many inventory beacons as required, either as a flat layer where each communicates directly with the application server, or in a hierarchy, as dictated by your network requirements. Of course, these inventory beacons provide full functionality, supporting all forms of FlexNet inventory gathering from target inventory devices within the IPv4 network (for simplicity, these devices in the IPv4 zone are not shown in the sketch above).
  • At least one inventory beacon must be a dual stack device that supports both IPv4 and IPv6 network layers. It does not matter whether this is achieved using two Network Interface Cards (NICs) or a single configurable NIC. The IPv4 interface links upward to its parent (whether that be to another inventory beacon in the hierarchy or directly to the application server). The IPv6 interface links downward to those of its child devices that are in the IPv6 zone (of course, other devices in the IPv4 network could also communicate through this inventory beacon, given its dual stack architecture). As shown, these IPv6 children may optionally include a further hierarchy of inventory beacons (which child inventory beacons would then be operating entirely within the IPv6 network).
  • Eventually, target inventory devices within the IPv6 zone that have locally installed FlexNet Inventory Agents communicate with at least one inventory beacon in the same zone; or where the lightweight FlexNet Inventory Scanner has been run on a target device, this can also communicate with the inventory beacon.
There are further restrictions and requirements to add to these general sketches:
  • All inventory beacons operating within an IPv6 network (whether as single-stack IPv6 devices or dual-stack IPv4 and IPv6 devices) must utilize Microsoft IIS as the web service. The simple alternative self-hosted web server does not support the IPv6 protocol.
  • Inside an IPv6 network, an inventory beacon cannot import Active Directory details. However, a dual-stack inventory beacon that can communicate with a domain name server (DNS) over IPv4 can still import Active Directory data. Alternatively, an inventory beacon co-installed on your central application server (which by definition must have IPv4 available to it) can still access a DNS on IPv4 and import Active Directory data.
  • Inside an IPv6 network, an inventory beacon cannot do any of the following:
    • Import inventory from third-party sources
    • Import business data from other systems (such as your purchasing or HR systems)
    • Communicate with SAP systems in your IPv6 environment
    • Perform any inventory beacon-based discovery or remote inventory collection across the IPv6 subnet, including VMware host scans (such as required for special 30-minute scans for IBM PVU license management)
    • Adopt target inventory devices that can communicate only on an IPv6 subnet (instead, use third-party deployment to install the FlexNet Inventory Agent on target devices within an IPv6-only subnet).
    However, once again, a dual-stack inventory beacon that can communicate with a DNS over IPv4, and contact the various sources also exclusively over IPv4, still supports all the above functionality on the IPv4 side. This is also true of an inventory beacon co-installed on the application server.

Take these factors into account when planning the distribution of your inventory beacons around your network. More details are available in Update and Deploy Additional Inventory Beacons.