This documentation supports the 9.1 version of BMC Remedy ITSM Deployment.

To view the latest version, select the version from the Product version menu.



Remedy AR System server group deployment

Server groups are designed to work with Remedy Action Request System (AR System) in any type of supported environment that has more than one server. This includes large distributed setups that make use of hardware load balancers and the Distributed Server Option (DSO). The AR System server groups feature provides failover management for crucial operations, server scalability, application-level load balancing, and the sharing of floating licenses among the servers. A server group consists of two or more AR System servers that are managed separately. The servers share the same AR System database, but perform workflow and database updates independently from each other.

Note

The servers within a server group need not have the same operating system, but you should ensure that any workflow that interacts with the operating system will run on all operating systems within the server group.

AR System servers in a server group

A server group acts as a single AR System server to support applications running on multiple AR System servers. The individual servers in the server group are configured to spread the load of shared services, and to provide backup for each other to ensure that those services are always available. BMC applications that are based on AR System, such as the BMC Atrium CMDB and its related applications, as well as the Remedy ITSM suite of applications can be installed and configured to operate within a server group. 

To ensure high availability of AR System operations, a server group can be configured to provide failover protection by assigning rankings for specific AR System operations to the servers in the group.

Note

It is required to always use the exact same version and patch level for all BMC software applications on each server included within a server group. And, to always upgrade each application on each server within the server group at the same time.

Benefits of using a server group

You get the following benefits when you deploy Remedy Action Request System (AR System) in a server group:

  • Distribution of heavy user traffic across multiple AR System servers using a third-party load balancer.
  • Automatic server failover (if a server goes down the system seamlessly keeps running).
  • Ease of administration; it has only one database to manage and back up.
  • Sharing of all BMC software licenses among the AR System servers (except AR Server licenses).
  • One server designated as an administrative server. (When the workflow and applications are handled on the administrative server, the changes are automatically propagated to other servers in the group.)
  • Specific servers in the group can also be configured to handle reporting, reconciliation, and other tasks that can impact performance, freeing up the remaining servers in the group to handle user traffic.
  • Inexpensive servers can be added to a server group to increase the growth in users and workload without having to replace or upgrade a single server. The environment is easier and less expensive to scale.

Server groups also work in conjunction with hardware load balancers that direct user traffic to some or all servers in the group. For best performance and reliability, BMC recommends that you use a load balancer when implementing server groups. For specific details on using a load balancer, see the following topics on the Remedy AR System online documentation:

  • Configuring a hardware load balancer with BMC Remedy AR System
  • Using a load balancer with server groups

Example configurations

See the following examples of a simple and a complex AR system server group configurations.

Simple AR System server group deployment

In the simplest form, a server group can be setup with two AR System servers and a database server. Each of the AR System servers have all Remedy products installed. 

In this example, the first server installed should be configured to be the primary administration server. Then, using the AR System Server Group Operation Ranking form, the applications should be distributed evenly across both servers, so that each server handles about half of the load, and each server has the other server configured for failover on each of its applications. 

The exception to this is the Email Engine and the Flashboards server. In a simple configuration, those two items are installed on every system but can be configured for only one server. Configuring failover for those operations can be complex and may not be necessary in a simple configuration. 

The full text search feature should be configured on each server. Each server has the ability to read from FTS, but only one server can be set to write, which is the server that is set with a higher priority on the AR System Server Group Operation Ranking form. It is also recommended that the FTS collection directory (location where the search index files are stored) and FTS configuration directory (location where the search configuration files are stored) be located on the same computer. 

Complex AR System server group deployment

A more complex server group implementation contains three or more AR System servers. In this example we are using four AR System servers. The applications or components should be installed on every server in the group so that failover can be provided. 

Again, the first server installed should be configured to be the primary administration server. Then, using the AR System Server Group Operation Ranking form, the applications are distributed evenly across all four servers, so that each server handles about one quarter of the load, and each server has at least one other server configured for failover on each of its applications and components. 

In this case, even the Email Engine server and the Flashboards have a failover server assigned. Configuring failover for those operations is somewhat complex because it means that each server has to be specifically configured to handle those items, but the secondary server for each is suspended until the failover is activated. 

Note

The applications and components listed for the servers above are just the primary roles for each server. It is recommended that all applications and components be installed on each server. This is important because users could be accessing any components from any server in the group, and there are dependencies such as plug-ins and other binary files that could be called when a user opens certain forms, creates a new record, or modifies a record.

In this example, FTS is setup on all the servers so that failover is possible. The FTS feature should be installed on each server. It is also recommended that the FTS collection directory (location where the search index files are stored) and FTS configuration directory (location where the search configuration files are stored) be located on the same computer.

Planning where software is installed in a server group

When installing server groups, make sure you know exactly what products you plan to install, and determine which servers will be running each product. BMC recommends that you install all the Remedy products on all servers, and then to use the AR System Server Group Operation Ranking form on Email Engine and Normalization Engine to distribute the load; however, there are may different ways to do this and each decision is based on the specific implementation.

Create a list in a text file for each server and its IP address, as well as all accepted fully qualified names. This saves you time when configuring the other servers. Each server must have the same set of entries containing all resolvable names for each server. Include the IP address, short name, and fully qualified name for each server in the server group and the load balancer, if one is used. In the installation instructions, a two-system server group is used and the systems have the following information. (Ensure to obtain similar information for your implementation before you start the installation process.)

The following example uses a format that you can use the Centralize Configuration for all the servers in your server group. It includes the entire set of IP-Name entries for this example.

You use IP-Name to store different IP addresses for the current server. This validates if a given action needs to be performed on the current server or on the remote server. If the input value from the action matches the current server name, it is stored as “@” (current server in the database). Else it continues to be the given server name (remote server name). 

The following actions uses IP-Name:

  • Direct SQL call from active link
  • Run Process from active link
  • Expand menu
  • Call active link guide
  • Server specified in table field

AR System Server 1:
IP-Name: svr_grp_tst0
IP-Name: svr_grp_tst0.svgroup.com
IP-Name: svr_grp_tst0.test.svgroup.com
IP-Name: 92.161.135.31

AR System Server 2:
IP-Name: svr_grp_tst3
IP-Name: svr_grp_tst3.svgroup.com
IP-Name: svr_grp_tst3.test.svgroup.com
IP-Name: 92.163.169.2

Other Info Needed:
Server-Name (resolves to the load balancer name): RemedyServerGroup
Domain-Name: test.svgroup.com

Related topics

    Page not found for multiexcerpt macro.
The page: ._brid_NW_LinksLibrary v19.08 was not found. Please check/update the page name used in the 'multiexcerpt-include macro.

    Page not found for multiexcerpt macro.
The page: ._brid_NW_LinksLibrary v19.08 was not found. Please check/update the page name used in the 'multiexcerpt-include macro.


Was this page helpful? Yes No Submitting... Thank you

Comments