How to Install CA SDM
This topic contains the following information:
This topic contains the following information:
For a successful CA SDM implementation, you need to understand the CA SDM deployment model and the different configurations that are available.
You can deploy CA SDM using one of the following deployment models that best suits your requirement:
- Centralized– Installs and configures all product components on one server. This is the default installation. You can implement multiple Object Managers and web engines for load balancing and failover, however your business may outgrow this implementation.
- Distributed– Installs and configures product components on servers that are closer to the clients receiving the service. For example, a business with many subnets can have analysts that are using the Web Client. In this type of deployment you place an additional server at the branch location. This server performs caching and reduces the network traffic and response time between the branch location and the main server location. This type of implementation supports the implementation of multiple Object Managers and web engines for load balancing and failover.
- Global– Having two or more centralized or distributed implementations that are known as regions. The main server of a region replicates minimal information to and from a master region. Hence, a single region can have all necessary information about all other regions. An analyst is aware of tickets from all regions and can connect to a region when required. This type of implementation is useful when network bandwidth is too limited for a distributed implementation. For example, business locations in different countries with a slow link between them.
CA SDM Configuration
CA SDM Architecture for Conventional Configuration
The conventional configuration includes a primary server, a database, and one or more secondary servers. The secondary servers are optional; configure them to support a large number of concurrent users. Only the primary server can access the database directly. The secondary servers access the database through a central process that is available on the primary server. A secondary server can be removed from the configuration without disrupting other servers. Only the users connected to the specific secondary server are affected.
When to Opt for Conventional Configuration
Conventional is the default configuration and is suitable for smaller deployments. Choose the conventional configuration if you do not require any high availability. Be aware that with conventional configuration, the application is not available during maintenance or when a server crashes.
The Primary Server is the main server in a conventional configuration. In a single server CA SDM configuration, the server is the Primary Server. When CA SDM is distributed across two or more servers, one server is designated as the Primary Server. This server performs roles in the configuration such as accessing the database. There is always only one Primary Server.
A Secondary Server is configured when there are more than one CA SDM server in a configuration. In this scenario, all servers other than the Primary Server are configured as Secondary Servers. Secondary servers perform only a subset of the roles of the Primary Server. Secondary Servers are added to a configuration to scale CA SDM to handle more users.
The following diagram provides an example of the conventional configuration architecture:
CA SDM Architecture for Advanced Availability
The advanced availability configuration includes a background server, one or more standby servers, and one or more application servers. To reduce the single point of failure, each of these servers has a direct connection with the database. All the components of the architecture communicate using an internal CA protocol.
When to Opt for Advanced Availability Configuration
The advanced availability configuration provides higher availability, reduces down times, and supports rolling maintenance. Consider the advanced availability configuration when any of the following factors is true:
- You require a high degree of CA SDM availability.
- You require the CA SDM servers to be more independent and more resilient to failures.
- You require an ability to remove and return the CA SDM servers to service, without bringing down the entire CA SDM installation.
- You require near zero downtime during rolling maintenance.
The following diagram provides an example of advanced availability architecture:
The architecture is spread across three different locations A, B, and C. Location A has two application servers, serving users through a load balancer. The location B has an application server directly serving the users and the location C has the background server, the standby server, and the database. Each of the servers has direct connection to the database. The blue lines mark the flow to and from the database. The red lines identify the internal communication between the components.
The background server is the core of the advanced availability architecture. This server provides ancillary services to other servers and runs all singleton processes of CA SDM. A process can be is designated as singleton when only single copy of it can be active in any SDM installation. Only the users with the Administrator Access Type have access to the background server. To increase the availability, the standby server shadows the background server. You can switch the standby server as the background server in case of any failure or when performing rolling maintenance.
The primary function of the standby server is to act as a warm standby for the background server. The standby server has the same hardware and OS platform as the background server. The standby server can run all processes that run on the background server. The standby server stays idle during normal working of the system. However, it listens to the internal CA SDM system messages for database changes and updates the critical caches continuously. If the background server fails or requires rolling maintenance, you can promote the standby server to background server. When you promote the server, the application servers as well as the end users have minimal disruption. You can invoke a utility to perform this switchover.
The standby server is only running a small subset of the processes that normally run on the background server. You cannot log on to the web interface on the standby server.
The application server has all the CA SDM components necessary to serve the end users through various interfaces like web, SOAP, and RESTful web services. The application servers are independent of each other and resilient to the background server outages for short periods of time. Users access the application servers. You can individually remove the application servers and return to service by using the new Quiesce facility. The quiesce facility allows current users to complete their work and then sign in to an alternate application server.