Remedy on-premises solution architecture
The Remedy solution consists of components in the Remedy stack that integrate with each other and other applications to support your business service model. Before designing a Remedy deployment solution to support your business service needs, you must understand the different architecture layers, the basic deployment model, and alternative deployment options available in Remedy.
Remedy solution architecture tiers
The Remedy solution architecture is a multi-tier, client/server architecture that consists of the client tier, the web tier, the server tier, and the data tier.
- The client tools in the client tier enable you to access, manage, and build applications.
- The applications in the web tier make web services accessible and enable you to access the server tier from a browser.
- The server tier enforces the business logic and runs the Remedy applications and workflows.
- The data tier holds data that applications can create, access, and manipulate.
The following illustration shows the Remedy solution architecture tiers:
The tiered architecture enables you to deploy applications such as Remedy IT Service Management, BMC Service Request Management, and BMC Service Level Management in a scalable and flexible manner.
You can use ITSM Suite to streamline and automate the processes around IT service desk, asset management, and change management operations. You can also link your business services to your IT infrastructure to manage the impact of technology changes on business and business changes on technology, in real time and into the future.
IT department and other business departments can use the BMC Service Request Management application to easily define available services, publish those services in a service catalog, and automate fulfillment of those services for the user community, enabling users to help themselves. BMC Service Request Management works with other applications, such as BMC Incident Management and BMC Change Management, to resolve user requests. BMC Service Request Management manages the entire process, from submission to completion.
IT department and other business departments can use the BMC Service Level Management application, to formally document the needs of its customers or lines of business by using service level agreements, and to provide the correct level of service to meet those needs. BMC Service Level Management also provides a means to review, enforce, and report on the level of service provided. It streamlines the most important task of all, which is the communication between a service provider and its customers.
Remedy solution architecture components
The following illustration shows the relationship among the components that reside within each of the functional environments of the Remedy deployment architecture, the architectural layers, and the layout of the applications in these layers.
The Remedy solution architecture consists of the following applications per tier:
The Client tier consists of client tools that help you access a service made available by a server. The tools in this layer are responsible for presenting services and displaying data to clients through various interfaces, which include the following:
The Web tier consists of applications that enable you to access the server tier from a browser and make web services accessible. The following applications are included in the Web tier:
The Server tier consists of applications and workflows that enforce the business logic. The following applications are included in the Server tier:
The Data tier holds data that applications can create and manipulate. The Data tier can use any of the following database platforms:
The following databases are included in the Data tier:
Basic deployment model for Remedy
The basic on-premises deployment model for Remedy demonstrates the possibility of deploying the applications in the web tier that can be co-located with each other in a single server.
The basic deployment model does not change or replace various alternative deployment options that were previously supported for high availability and other requirements.
Consider a basic deployment model, if you have the following requirements:
- If you are looking to deploy a small model.
- If your objective is to reduce the hardware footprint.
- If you want to reduce the overhead of hardware, OS, and application maintenance.
- If you do not have high availability requirements.
The basic Remedy deployment model includes applications that run in different designated tiers. It also includes web tier applications that run on different Tomcat servers within the same physical server. For example, Mid Tier and Smart IT can be deployed on the same server because all users logging on to these applications are ITSM users. When two applications are run on the same server, the user load is shared efficiently by these applications. However, in such a shared deployment, the biggest drawback can be the monopolization of the shared resources when an application misbehaves. Thus, to achieve a stable deployment, you must consider all aspects of business and technical requirements when deciding on a suitable deployment architecture.
This model represents the simplest way of deploying your Remedy applications. Based on your environment and system requirements, you can modify the deployment to support your organization's high availability and other needs. This basic model depicts a minimal deployment model. It has only one instance of each application. While this is a functionally complete model, it does not provide the high availability (HA) support that BMC recommends for an enterprise class application such as Remedy.
This basic model can be easily extended to provide HA by adding additional servers and application instances at each tier.
Sizing baselines for the basic deployment model
The sizing baselines in the following table are based on performance lab benchmark test results and real-world customer experience. For more information about performance tuning and configuration checklist, see the Knowledge Article 000114508.
The basic Remedy deployment model can support up to 800 concurrent users. Concurrent users indicate the number of users logged in and actively working on the system. If your organization is using a significant number of web-based clients (utilizing the mid tier) and the thick-based BMC Remedy client tool, you should calculate the totals for each and use the total number as the estimate for concurrent users.
The following table lists the configuration for the type of deployment:
|Type of deployment||Number of Remedy ITSM concurrent users||Number of Remedy Smart Reporting concurrent users||Number of Digital Workplace users|
The following table lists the sizing baselines for small deployment:
|Deployed components||Small deployment|
|Only Remedy ITSM stack|
12 CPUs, 36 GB RAM*
*(12 CPUs includes the CPU requirements of each component of the Web tier. 36 GB RAM is needed for deploying Remedy Mid Tier, Remedy Single Sign-On, Virtual Chat, and Smart Reporting on the same server. See the Knowledge Article 000114508).
12 CPUs * 32 GB RAM
8 CPU, 16 GB RAM
|Remedy ITSM stack with Smart IT|
16 CPUs, 48 GB RAM*
*(16 CPUs includes the CPU requirements of each component of the Web tier. 48 GB RAM is needed for deploying Remedy Mid Tier, Remedy Single Sign-On, Virtual Chat, and Smart Reporting on the same server. See the Knowledge Article 000114508)
16 CPUs * 48 GB RAM
8 CPU, 16 GB RAM
|Remedy ITSM stack with Smart IT and Digital Workplace|
24 CPUs, 64 GB RAM*
*(24 CPUs includes the CPU requirements of each component of the Web tier. 64 GB RAM is needed for deploying Remedy Mid Tier, Remedy Single Sign-On, Virtual Chat, and Smart Reporting on the same server. See the Knowledge Article 000114508).
DWP Catalog server with 8 CPU, 16 GB RAM
AR System server with 20 CPU, 64 GB RAM
16 CPU, 32 GB RAM
Deployment High Availability (HA) can be accomplished through standard horizontal scaling. The entire deployment model can be duplicated with the original resource allocation in place. The simplest HA can be achieved when the deployment is virtualized; that is, the entire deployment model is duplicated and enough resources are allocated to the VMs.
One example of enabling HA in your environment is that if you are using only the Remedy ITSM stack, configure two servers, each with 12 CPU and 36 GB RAM for the Web tier. One server is for primary use and the other is for HA. Therefore, as per the above sizing guidelines, if you have a single server with 12 CPU and 36 GB RAM for your base Web tier, you would have two servers with 12 CPU, 36 GB RAM in HA deployment.
For information about sizing baselines for medium and large deployments, see the Knowledge Article 000114508.
Alternative deployment models for Remedy
The basic layout for Remedy deployment is to deploy all the Web tier applications on the same physical server. However, the other options for deployment include Web tier applications that can be installed on different physical servers. An example would be to deploy Remedy Single Sign-On (RSSO) or Remedy Smart Reporting or BMC Digital Workplace separately on different physical servers.
The following illustration shows a deployment variation for the Remedy solution:
A practical approach in architecting a deployment solution is to ensure that you perform the following actions:
- Isolate the services that are common and can be re-used or consumed by other services.
- Separate the major services so that the service can be assigned dedicated resources.
- Duplicate the services that require high availability (HA).
With reference to the preceding deployment model, you should perform the following actions:
- Isolate the Remedy Single Sign-On (RSSO) service because RSSO is multitenant and can act as a shared service across multiple environments such as development, QA, and production.
Separate and deploy Remedy Smart Reporting on its own server because Smart Reporting is a major service and can consume considerable amount of resources for generating large reports. If Smart Reporting is deployed on the same server as that of Mid Tier or Smart IT, it might impact the performance of those application for end users.
If you have heavy Reporting usage, have a separate Reporting environment by using a separate database server.
For Smart Reporting that is run with other web applications, it is also possible to have a dedicated AR System server for Smart reporting application to isolate the reporting load.
- Use multiple AR System servers, a subset of which is used for user-facing activities and the rest of the servers are used for background processing tasks such as email, approvals, and assignment. This separation is done to ensure that the background activities do not impact the user-facing activities.
For information about the sizing baselines, see the Knowledge Article 000114508.
For information about the sizing baselines for a medium model deployment, see Hardware requirements.
For information about sizing baselines for Digital Workplace, see the Knowledge Article on BMC Communities.
Remedy Migrator memory usage and disk space requirements
Before installing Migrator, ensure that you have a Microsoft Windows server with a minimum of 2 CPUs, 4 GBs of memory, and 40 GBs of free disk space.
If you plan to use the Delta Data Migration (DDM) tool that is bundled with Remedy Migrator, BMC recommends that you install Remedy Migrator on a standalone Windows server. Install in the same LAN as the destination Remedy AR System server but not on the source (current production) or destination (production staging) AR System servers. If the Windows server resides outside of the LAN segment, BMC recommends that you deploy a separate server for the Delta Data Migration tool, and that you run that server on the same LAN segment as the current production and staging servers.
Alternatively, if you do not have an additional Windows server, you can use the mid tier server in the production staging environment as the host for Remedy Migrator and the Delta Data Migration tool. Ensure that the mid tier is disabled when you migrate your delta data.
To avoid performance issues, do not install any other application on the computer where the Remedy Migrator is installed.
Remedy security architecture
Encryption enables the Remedy Action Request System (Remedy AR System) server and its clients to communicate securely over a network by encrypting the messages sent between them. At the beginning of every client and server connection, a key exchange protocol negotiates shared encryption keys between the client and server. These keys encrypt all communication between the client and server, ensuring that the communication is secure and that third parties cannot decipher the messages in transit. Note that if you choose the encryption options during installation, it does not encrypt the communication between the browser and the Remedy Mid Tier. To enable the encryption between the browser and mid tier, you must install the X.509 certificate to be installed on the mid tier or on the load balancer depending upon your deployment and security requirements. Data encryption is invisible to users.
The following illustration shows the Remedy security architecture:
The Remedy AR System client libraries provide built-in encryption capabilities to enable and secure the connection to the AR System server. Higher levels of encryption are available from BMC if you need stronger encryption. Remedy AR System is also tested with database encryption products from your database vendor to ensure that this connection can be encrypted. The communication between the AR System server and the database are not natively encrypted. The encryption is subject to the capabilities provided by the database vendor.