Considerations for Advanced Availability

CA SDM advanced availability configuration provides higher availability, reduces down times, and supports rolling maintenance. Consider opting for the advanced availability configuration when any of the following factors in your CA SDM environment are true:
casm173
CA SDM advanced availability configuration provides higher availability, reduces down times, and supports rolling maintenance. Consider opting for the advanced availability configuration when any of the following factors in your CA SDM environment are 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 biggest difference between conventional (
Primary
/
Secondary
), and Advanced Availability (
Background
,
Standby
,
App servers
), is that in a conventional configuration, only the primary server talks to the database. However, in an Advanced Availability environment, each server independently talks to the database and has its own virtual database process and database agents for better performance.
CA SDM advanced availability configuration offers more resilience to server outages, higher application availability, and supports rolling maintenance with minimal end-user disruption. This configuration requires the following type of servers:
  • Database server for the MDB
  • One Background Server
    The Background server takes the place of the Primary server in the conventional mode. It handles all background transactions, for example, triggering events and notifications, checking for conditions, and so on.
  • One or more Standby Servers
    The Standby server is meant for standby purposes. During server failures and disruptions, the standby server is promoted as the background server when the original background server is revived and repaired.
  • One or more Application servers
    End-user traffic only hits the Application servers, on which you use an F5 load balancer to balance the load between two (or more) application servers. End-user traffic load does not affect the Background or Standby servers. Use the background server and log in to the CA SDM console to configure the standby and app servers.
When you opt for CA SDM Advanced Availability mode, you perform the following installation tasks:
  1. Install Background Server
  2. Install Application Servers
  3. Install xFlow Interface
  4. Install Search Server
Ensure that you have considered the following planning consideration before installing CA SDM Advanced availability configuration:
Login Permissions
Complete the following steps:
  • (Windows) Log in as an Administrator and have full Administrative permissions.
  • (Non-Windows) Log in as the root user and have the correct permissions to the root account.
  • Create the
    CA Service Desk Manager Server Privileged
    user before you begin the installation.
Installation Home Directory
Complete the following steps:
  • Determine the home directory in which you want to install the product. The default home directory for the product is
    C:\Program Files\CA\Service Desk Manager
    .
  • Determine the home directory in which you want to install the shared components that the product uses (for example, the Java Runtime Environment (JRE) and Apache Tomcat). The default home directory for the shared components is
    C:\Program Files\CA\SC
    .
Database Considerations
CA Service Management
supports both Microsoft SQL Server and Oracle databases. Select a database as per your environment requirement.
  • Microsoft SQL Server is only natively supported on the Windows platform. For example, if your implementation consists of servers with heterogeneous operating systems like Windows and Linux, select Oracle as the DBMS as Microsoft SQL Server is not supported on Linux. Obtain the following information:
    • The named instance of the server that is running Microsoft SQL Server.
    • The Microsoft SQL Server database user name and password.
    • The Microsoft SQL Server database port number.
  • To help ensure that you can configure the product and components on Oracle, obtain the following information:
    • Whether the Oracle database is local or remote.
    • Whether you are required to create tablespaces.
    • The Net service name.
    • The DBA user name and password.
    • The data and index tablespace name.
    • The complete path for the tablespace.
    • JDBC connection information, including the system identifier (SID) and listener port.
  • To configure a 64-bit Oracle 11g database on a 64-bit computer, do the following:
    • Install the Oracle 32-Bit Client on the server and while configuring the database point the system library path to the 32-bit Oracle libraries
      .
      This step is required for both configuration and runtime. Also, create a net service name on the Oracle client to point to the Oracle database server instance.
    • The structure
      $ORACLE_HOME/lib32
      exists when you install 64-bit executables on a system and that installation comes with both 32-bit and the default 64-bit libraries (pre Oracle 11g R2). The 64-bit libraries are placed into the
      $ORACLE_HOME/lib
      and the 32-bit are placed into the
      $ORACLE_HOME/lib32
      directories.
    • Starting from Oracle database 11gR2, 32-bit libraries are not being shipped with the 64-bit Oracle database server or 64-bit Oracle database client media. Hence after installing Oracle database 11gR2, you will not find lib32 folder inside
      $ORACLE_HOME
      . If you want the 32-bit libraries, you need to install the 32-bit client which is shipped as a separate media. This should be installed only on a new Oracle home. You should neither install it on 64-bit server home nor on 64-bit client home.
  • If you are using an Oracle database and you want to use an existing tablespaces, do the following:
    • Create a Data tablespace that is at least 400 MB, and an Index tablespace that is at least 100 MB before configuring CA SDM.
    • Increase the hardware configuration of the DBMS server. Each of the servers is directly connected to the database, leading to an increased resource contention at the DBMS level.
Advanced Availability Configuration Considerations
Planning Consideration
Checklist
General Advanced Availability Consideration
  • Additional hardware costs are expected as you require one background, at least one standby, and one or more application servers. The configuration of standby and background server must be identical.
  • You require a remote database server and a server to share knowledge tools index files, knowledge tools import/export files, archive purge output files, and attachment repositories. To allow the background and the standby server to access these files, a shared location is required. Linux installations can use NFS mounts. UNC support has been added for Windows installations.
  • The CA SDM performance is expected to remain the same even with the additional servers for background and standby operations. If you deploy more application servers, the performance can possibly improve.
  • Each of the servers is directly connected to the database, leading to an increased resource contention at the DBMS level. We recommend increasing the hardware configuration of the DBMS server.
  • Converting a conventional configuration to an advanced availability configuration is a manual effort. The larger implementations are more complex and you can engage CA Services for assistance.
  • Install the background and the standby server on the same network subnet to make ping times and latencies from different application servers similar.
  • Consider locating the background and the standby servers in a central location with a good network connectivity to all your users. The application servers can be located either centrally or they can be distributed across the globe.
  • An advanced availability configuration must always have
    one background server
    and at least
    one standby server
    .
  • (Recommended) Ensure that both background server and all other standby servers have similar configuration. During a failover when a standby server becomes the new background server, it functions exactly like the old background server.
  • Any number of standby servers can be configured. To increase the CA SDM availability, consider placing one standby server in your backup data center or the disaster recovery site.
  • The minimum advanced availability implementation requires one application server. We recommend you to have two application servers to increase the availability and a load balancer to direct web traffic.
  • Except for CA SDM administrators, no other users are allowed to log in to the background server. Also, no users are allowed to log in to the standby servers.
  • You can send email notifications from all CA SDM servers. There is no way to limit or configure this option. Every server in the advanced availability configuration must have a connection to the mail server.
  • An email notification resulting from an end user interaction is sent from the application server to which the user is connected.to.
  • An email notification resulting from any background processes (such as Animator processing an Attached Event) is send by the
    pdm_mail_nxd
    utility running on the background server.
  • During a background server failure, the queued emails are sent when the background server comes up as a standby server.
Failover Consideration
During failover of the background server to the standby server, consider the following:
  • New users cannot log in during a failover process.
  • For those users who are already connected, the following actions do not work during a failover. These actions must be repeated by the user after the failover is complete:
    • Creating the tickets with attachments.
    • Downloading the attachments.
    • Searching Knowledge documents.
    • Indexing the new knowledge documents.
    • Inbound emails.
    • The SLA events that are not triggered until the failover is complete.
If you have configured a third-party tool to enable auto-failover of CA SDM servers, you must disable the tool before performing a rolling maintenance.
Database Considerations
  • A direct connection exists from each of the servers to the other as well as to the database. If CA SDM server is within DMZ, you are required to open the firewall ports or implement a tunneling proxy technology for this connectivity. Also consider licensing arrangements with your DBMS vendor.
  • Ensure that you install the database client on all the CA SDM servers.
  • In advanced availability configuration, all the servers still connect to a single database. As the database can be a single point of failure, consider taking the advantages of database clustering to increase the availability of DBMS.
  • Microsoft SQL Server is only natively supported on the Windows platform. For example, if your implementation consists of servers with heterogeneous operating systems like Windows and Linux, select Oracle as the DBMS as Microsoft SQL Server is not supported on Linux.
System Configuration, Administration, and Operation
  • SOAP Web Services and RESTful Web Services are only supported on the application servers. Web directors can be configured on all CA SDM servers.
  • The application servers are independent of each other,, therefore, web directors can only service web engines running on the same application server. Web directors cannot service web engines across application servers.
  • Because the servers in the advanced availability configuration have a higher degree of independence, most command-line utilities function only on the local server.
    For example,
    pdm_status
    only shows you the CA SDM processes running on the server on which you are executing the command. The
    pdm_webcache
    utility only refreshes the form caches on the server on which it was issued.
  • Unlike conventional configuration, where you start and stop CA SDM processes by
    pdm_d_mgr
    running on the primary server, in advanced availability, processes on each server are controlled independently.
  • We recommend you to use the new pdm_server_control instead of pdm_halt command to shut down application servers. Before the shutdown, you can ask the active users to move to another application server. Notify the users using the
    quiesce
    option.
  • The pdm_edit utility has been replaced with a new graphical user interface, eliminating many manual configuration file changes required earlier.
  • Unlike conventional, in the advanced availability configuration, you can use the bopauth_host option from the Options Manager of the background server web UI to specify the authentication server details. You no longer make this configuration change in pdm_edit for the advanced availability configuration. Users cannot log in when the authentication server is unavailable.
    In the conventional configuration, you can use a secondary server to integrate CA SDM with an authentication system running on a different system or even on a different hardware platform.
  • To prevent rogue servers from joining the advanced availability configuration, all servers must be defined from the background server web UI, before they can be configured.
  • The role and other information for a server in the advanced availability configuration can be changed from the Administration tab. Stop the CA SDM services before attempting to change a server definition. The server reconfiguration is required for the changes to take effect.
  • You can change a server between the conventional configuration and the advanced availability configuration by running the configuration utility. Be sure to change all servers in the implementation. Your data remains unaffected, but the manual updates are required to change the settings.
  • Use the latest
    pdm_startup
    files when migrating to the latest release version. Do not use the files from previous versions of CA SDM. For example, files that are generated by the
    pdm_edit
    utility
    Do not change the
    Nx.env
    variable manually unless you are instructed to do so.
  • A new facility generates ticket numbers and numeric record keys. To avoid possible database corruption, never try to load or manually alter the
    Key_Control
    table.
  • You cannot move the Knowledge Tools daemons to another server in the advanced availability configuration. The
    kt_daemon
    runs on all servers. All other Knowledge Tools daemons run as singletons on the background server.
  • Knowledge Tools now support UNC file paths on Windows for the location of the EBR index files and input/output files that are used by the Knowledge Export Import facility. This feature is available for both the advanced availability and the conventional configurations.
    EBR Index Files path & KEIT Files path must refer to the same UNC credentials and the path must reside on the same server.
  • Version control distributes the files (for example,
    htmpl
    , .
    maj
    , .
    mod
    , and .
    sch
    ) that are configured in the
    server_secondary_custom.ver
    file from the background server. On startup, the standby or the application server runs the version control client to pull updated files from the background server.
  • Archive/Purge runs on the background server and supports UNC file paths on Windows for output files. This feature is available in the advanced availability and the conventional configurations.
  • Attachments on incoming emails are stored by
    pdm_maileater
    when the repository is on a remote server.
  • Ensure that you allow the daemon manager to modify the
    procsets
    and do not run the
    pdm_dmnmode
    command for this action.
General Web User Interface Considerations
  • A web server is required on all the servers of the advanced availability configuration.
  • When the background server is not available due to failover, a Delayed Server Response form is presented to the web users. Users are allowed to resume their work when the standby server is promoted to the background server.
  • The value of the web_cgi_url option must point to:
  • The load balancer if you have more than one application servers.
  • The application server, if you have only one application server.
Attachment Considerations
  • You can increase the availability of attachments by configuring multiple document repository processes to access a shared file repository.
Web Screen Painter Considerations
You can use the Web Screen Painter (WSP) only on the background server.
  • The virtual database layer daemons run on all servers. Install the CA SDM database customizations and object definitions on all the servers.
Reporting Considerations
CABI Jaspersoft can automatically retrieve data from alternate application servers. You can configure this feature to increase the availability of CA SDM reporting. For more information, see Install & Configure CABI JasperReports Server r6.4.3 for CA Service Management
Options Manager Considerations
  • You can install or uninstall options through Options Manager only from the background server web UI. Use the rolling maintenance procedure to propagate the changes to all servers in the configuration. For more details on performing the rolling maintenance, see the Performing Rolling Maintenance on the CA SDM Server scenario.
Web Services Considerations
  • You can configure web services only on the application servers.
  • The webservices_domsrvr option no longer exists in the Options Manager. You can configure NX_WEBSERVICES_DOMSRVR variable independently on each application server by modifying NX.env.
General Integration Considerations
  • The URL to the CA SDM web user interface must point to a properly configured application server. The ca_application_registration contains a URL to your CA SDM installation that is used by other CA products. This URL points to the CA SDM server that is configured first, which is most commonly the background server. Only the CA SDM administrators can change the value through the administration facility. If you are using a load balancer, point this URL to the load balancer instead of a single application server.
  • Most end-users interaction and integrations with other software products are done at the application server level. There is no failover for the application servers. If the application server is unavailable, the web services for the application server are also unavailable. To increase the application server availability, you can deploy a load balancer to route requests among different application servers
  • CA Process Automation can be installed on any of the application servers. If the application server goes down, workflow becomes unavailable..
Federated Search Considerations
  • To enable and use the federated search feature, select the federated search option while configuring the application servers.
CA SDM Configuration Conversion Considerations
Consider the following when converting the CA SDM server configuration mode:
  • You can convert the background server to a primary server only.
  • You can convert the primary server to a background server only.
  • You can convert the secondary server to a standby server or application server only.
  • You can convert the standby or an application server to the secondary server only.