Configuring the Distributed Server Option service for a hub and spoke system

The Distributed Server Option (DSO) is the mechanism used for transferring data between hub and spokes. The DSO service is automatically licensed when you install  BMC Helix ITSM. You do not need to perform any additional licensing steps to enable the DSO service.

Before you begin

• Refer to Configuring a single reverse proxy server for hub and spoke.
• Create the following two entries:
  • Hub — Provide the physical and logical names of the hub server. This entry is identical on each spoke server.
  • Spoke — Provide the physical and logical names of the spoke server you are currently working on. This entry is different for each spoke server in your system.

Configuration best practices

• When the DSO service is installed, the installer assigns RPC port number 390625 to the DSO Filter plugin. The RPC port assignment for the DSO Filter plugin is recorded in the following file: Program Files\BMC Software\ARSystem\pluginsvr\pluginsvr_config.xml. If another plugin is already using this RPC port number, the conflict can create performance issues.
• Scan the following file after installing the DSO service to determine whether another plugin uses this RPC port number: Program Files\BMC Software\ARSystem\Conf\ar.conf. If you find a conflict, assign a new number to the plugin in conflict with the DSO Filter plugin. For a list of valid RPC port numbers, see  Assigning an RPC program number to DSO .
• When you perform the Polling Interval and the Distributed Mapping Cache Refresh Interval configuration procedures, use all of the default settings.

• Configure DSO to use a private queue. Using a private queue isolates DSO interaction from interactive traffic and provides dedicated bandwidth for DSO processes. Configure the queue with multiple threads (three or four should be enough) to provide sufficient threads for hub and spoke traffic to run in parallel.

• Configure failover chains for the DSO process so if the main DSO processing server stops, DSO processing shifts to another server. Regular monitoring of the DSO environment for errors or failures can help to reduce the likelihood of the DSO server stopping.

• If you also use DSO on the spoke server for purposes other than to support the hub and spoke topology, configure DSO Pools so that you can isolate DSO hub and spoke traffic on one pool and traffic for the other DSO operation on one or more of the other pools. If you configure DSO pools, increase the number of threads proportionately so that there are one or two threads over the number of DSO pools you configure.

• You set up all connections between the Mid Tier and the hub and spoke servers with the Hypertext Transfer Protocol Secure (HTTPS) protocol.

• Each AR System server spoke environment must have its own, dedicated Mid Tier server.
  

• The application permission models on the spoke server must be the same as those on the hub server.
  

• The name must be reachable:

  • By the spoke mid-tier server
  • From the hub (the hub must be able to use the DSO service for sending information to the spoke)
  • Use consistent names to identify the spoke servers. For example, if you identify the spoke server by its long name when you register it on the hub server, do not later use the spoke server's short name or its IP address when identifying it to the mid-tier server.

To configure DSO for the hub and spoke servers

You perform the DSO service configuration from the hub server and then from the corresponding spoke server. As an administrator, you configure DSO each time you add a spoke server to the hub and spoke system. You must perform the DSO service configuration locally on each hub server and on each spoke server.

Where to go from here

When you finish configuring the DSO service, map the servers' logical and physical names. For more information, see Mapping the servers' logical and physical names.