Windows gateways

You can configure the Windows gateways in your TADDM environment.

Sufficient capacity for any Windows gateway server is an important component in the overall configuration of your TADDM discovery environment. Windows gateway processing is processor-intensive and can become a bottleneck to overall discovery throughput when sufficient capacity is not available. The following guidelines can be used to configure your Windows gateways:
  • Gateways can be configured as a shared pool for multiple discovery servers. This method ensures that all of the gateway servers can be used while discovery is running on any of the discovery servers.
  • Monitor the processor usage on the Windows gateway servers to determine whether sufficient capacity is available. You can use Windows Task Manager or any other tool available that monitors processor usage. If the processor usage on any of the Windows gateway servers runs at 100% for long periods of time, there is insufficient processor capacity on that gateway. Running at 100% use indicates that some of the TADDM sensors running through this gateway are waiting for available processor resources to do their work. This delay negatively affects the total elapsed time for the sensor to complete.
  • Different guidelines apply for queue lengths on multiprocessor systems. For busy systems (those having processor use in the range 80 - 90%) that use thread scheduling, the queue length acceptable range is 1 - 3 threads per processor. For example, on a four-processor system, the expected range of processor queue length on a system with high processor activity is 4 - 12. On systems with lower processor use, the processor queue length is typically 0 or 1.
  • Processor queue length, can be an indication that there is insufficient capacity on that gateway. Address this situation by completing one or more of the following actions:
    • Add additional processors to the gateway server.

      Large and enterprise deployments must have a minimum of four processors.

      The following table contains results of scale tests for which gateways with two, four, and six 2Ghz CPUs were used. Tests environment: VMware guest with dedicated resources, Windows Server 2012, Cygwin SSH server, dwcount property set to 96.
      Table 1. Results of scale tests which used a gateway with two, four, and six 2Ghz CPUs.
      Number of gateways Number of 2Ghz CPUs Performance improvement (%) CPU max usage (%) CPU max usage length reduction (%)
      1 2 - 100 -
      1 4 17 100 50
      1 6 20 60 80

      The results show that the more processors you use, the better performance you achieve.

    • Use gateway servers with faster processors, for example processors with a speed of 2.0 - 3.0 GHz.

      For large and enterprise deployments, use the highest speed processors available.

    • Add additional gateway servers to the pool.
      The following table contains results of scale tests for which various numbers of gateways were used. Tests environment: VMware guest with dedicated resources, Windows Server 2012, Cygwin SSH server, dwcount property set to 96.
      Table 2. Results of scale test which used various numbers of gateways.
      Number of gateways Number of 2Ghz CPUs Performance improvement (%) CPU max usage (%) CPU max usage length reduction (%)
      1 2 - 100 -
      2 2 7 100 60
      3 2 8 80 80
      The results show that with the same number of processors, the more gateways you use, the better performance you achieve. However, the preceding tests show that it is best to use more processors than more gateways.
Typically, users have 70 - 80% of their total distributed servers running the Windows operating system. Using this information, you can determine the number of Windows gateways needed, depending on the deployment size.
  • For small deployments: Two Windows gateways
  • For large deployments: Four Windows gateways
  • For enterprise deployments: Four Windows gateways
These categories are based on the total number of Windows servers being discovered, not the total number of servers in the environment.

You might have to add more gateways if you are not meeting your discovery throughput requirements.

Required software

Operating system requirements for gateway servers are the same as Windows operating system requirements for TADDM servers. For details, see TADDM server software requirements.

All Windows gateways must be running a supported version of Bitvise WinSSHD, Cygwin SSH daemon, Tectia SSH Server, or Remotely Anywhere. OpenSSH server, available as an installable feature in Windows Server 2019, is also supported.

Note: If you use anchors on the Windows operating system, the requirements are the same as for the Windows gateways.
The following is the list of supported versions of the software:
  • Bitvise: WinSSHD 4.06, and later.
  • For Cygwin, you must install the following packages:
    • From the admin category: cygrunsrv (version 1.17 - 1 or later).
    • From the net category: opensshd (version 4.6p 1 - 1 or later).
  • Tectia SSH Server: 6.4.4 or later.
  • Remotely Anywhere: 9.x, 11.x.
  • OpenSSH Server 7.7 (on Windows Server 2019)
Restrictions:
  • For Windows Server 2012, only Bitvise 5.59, Tectia 6.4.4 or later, Remotely Anywhere 11.x and Cygwin are supported.
  • Anchors and gateways are supported on Cygwin 64-bit edition on Windows Server 2012 x64. However, the discovery user and the user that starts the service must be the same. The discovery user must be a member of the Administrators group. These requirements must be fulfilled for successful discovery with the use of Cygwin SSH.
  • For Windows Server 2016, Bitvise 6.51, Tectia 6.4.13 or later, Remotely Anywhere 12.x and Cygwin are supported.
  • For Windows Server 2019, Bitvise 8.22, Tectia 6.4.13 or later, Remotely Anywhere 12.x, Cygwin are supported. OpenSSH Server, available as an installable feature in Windows Server 2019, is also supported.

For more information about availability, installation and configuration of the preceding software, see Configuring for discovery of Windows systems.

The following table compares the performance of the Cygwin and WinSSHD servers. Tests environment: VMware guest with dedicated resources, Windows Server 2012, dwcount property set to 96.
Table 3. Comparison of the Cygwin and WinSSHD servers performance.
SSH server Number of gateways Number of CPUs Performance improvement (%) CPU max usage (%) CPU max usage length reduction (%)
Cygwin 1 2 - 100 -
WinSSHD 1 2 11 100 50
The results show that in the test environment, in comparison to the Cygwin server, the WinSSHD server achieves better performance because of the lower CPU usage.

Running Windows gateways on virtual machines

You can run Windows gateways on virtual machines (VMs). The guidelines in the previous section are based on dedicated physical resources. For example, an enterprise-sized deployment requiring four gateways can use one of the following configurations:
  • An eight-way physical server into four 2-way VMs, with each VM used as one of the four gateways. This configuration is acceptable.
  • An eight-way physical server into eight 2-way VMs, with four of the VMs being used by TADDM as gateways, and the other four VMs used for other, non-TADDM usage.

    This server is over allocated, that is, eight physical processors and 16 virtual processors. This configuration might be acceptable if the four TADDM VMs are the only VMs running when a TADDM discovery is running.

    This configuration is probably not acceptable if all eight VMs are running while a TADDM discovery is running. Because the physical processor resources are over allocated, the processor resources that are required by TADDM are not available.

When using VMs for Windows gateways, any monitoring of the gateways for capacity must be done on the physical server. Performance information you see on the VM is not reliable or accurate.