Methods of deploying NAM Probes in VMware environments

There are three ways of deploying a NAM Probe on a virtual machine.

Deploy NAM Probe on VM within a production ESXi host (Virtual NAM Probe)

In this case, the NAM Probe shares resources with other production virtual machines. Its purpose is to monitor packets as they cross the virtual switches within the host. In this scenario, the NAM Probe monitors intra-host traffic between virtual machines and inter-host traffic entering and leaving the host.

Because the Virtual NAM Probe shares computing resources with other production virtual machines, these resources must be assigned carefully. Testing indicates that reasonable performance can be gained by using a virtual machine containing one or two vCPUs and 8 GB of memory. Each vCPU should be assigned a full dedicated core and the memory should be set to reserve 6 GB with a limit of 8 GB. To make efficient use of the resources assigned to the Virtual NAM Probe, only the intra-host traffic should be processed by the Virtual NAM Probe. All inter-host traffic that is visible to the Virtual NAM Probe should to be filtered out and left to either a physical NAM Probe or a Virtual NAM Probe deployed on a Dynatrace dedicated host.

This can create issues in very dynamic VMware environments where vMotion events are common. For example, when traffic is being monitored between two virtual machines on the same host with a local Virtual NAM Probe and with the filtering described above, the NAM Probe will continue to process the packets between the two virtual machines until a vMotion event moves one of those virtual machines to a different host. At this point, the traffic between the two virtual machines becomes inter-host traffic and is not only being processed by the external NAM Probe, but also by the internal local Virtual NAM Probe, resulting in duplicate packets and inefficiency.

To resolve this, the ability to recognize these events and to dynamically configuring the filters is a requirement. This could be accomplished by either having the local NAM Probe or its NAM Server query the VMware environment (either the vCenter server or ESXi host) directly for information on which virtual machines are local to which hosts.

Deploy NAM Probe on VM within a Dynatrace dedicated ESXi host (Virtual NAM Probe)

In this case, the NAM Probe shares resources with other Dynatrace products and does not impact resources dedicated to production applications. This method requires the use of either a virtual tap or a virtual distributed switch such as Cisco's Nexus 1000v or VMware's vDS for vSphere 5.0. These virtual devices provide the means of directing copies of packets out of the ESXi host and forwarding them to a NAM Probe configured on a Dynatrace dedicated ESXi host.

This approach has the benefit of not having to differentiate between intra-host or inter-host traffic. It also allows for a little more freedom in assigning compute resources because the only other virtual machines that the Virtual NAM Probe will compete with are those running other Dynatrace products. VMware also recommends this methodology over the previous one, because it is less intrusive to the production virtual machines and it is considered to be more efficient.

Attention must be given to the limitations of the virtual tap or virtual span capabilities of the virtual distributed switches. Only the traffic that is required to be monitored should be made available through the virtual span or tap. Care should also be taken to not exceed any bandwidth limitations.

Deploy NAM Probe on physical server (physical NAM Probe)

In this case, the NAM Probe has the use of all resources available on the server and does not impact production resources. This method also requires the use of either a virtual tap or a virtual distributed switch such as Cisco's Nexus 1000v or VMware's vDS for vSphere 5.0.

Other report and Database Server deployment methods

Other deployment methods may be appropriate for certain atypical environments, but each method has its pros and cons.

  • Report server and database server hosted on separate virtual machines within a single or multiple dedicated ESXes.

pro

Because it will not have to share resources with NAM Server processes, this method offers a potentially more powerful or dedicated environment for the database server, resulting in better performance of some database operations.

con

Using two virtual machines instead of one has a greater environmental impact and there is no option to use bulk inserts.

  • Report server or database server (or both) occupying the virtual machines co-hosted with other machines on the same ESX.

pro

Lower environment cost impact.

con

High performance impact on both the NAM software and database as well as potentially a negative impact on other machines co-hosted on the same ESX.

  • Report server or database server or both hosted on separate non-virtualized hardware.

pro

Because it will not have to share resources with NAM Server processes, this method offers a potentially more powerful or dedicated environment for the database server, resulting in better performance of some database operations.

con

Higher hardware impact; no possibility of using bulk inserts (in case of report server and database server separation); more configuration required from connectivity perspective to properly link NAM Probes and report servers; no deployment consistency.