Advanced Availability Additional Considerations

All the planning considerations that are applicable for CA SDM conventional configuration are valid for the advanced availability configuration too. Consider the following before you decide to implement an advanced availability configuration:
casm171
All the planning considerations that are applicable for CA SDM conventional configuration are valid for the advanced availability configuration too. Consider the following before you decide to implement an advanced availability configuration:
General Considerations
Review and implement the following considerations if you are opting for CA SDM Advanced Availability configuration:
  • 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. 
    This process ensures that during a failover when a standby server becomes the new background server, it can function exactly like the old background server. 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. 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 recover site.
  • 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.
  • 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.
  • 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 and Unix installations can use NFS mounts. UNC is supported for Windows installations.
  • We can send email notifications from all CA SDM servers. Every server in the advanced availability configuration must have a connection to the mail server.
  • 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 email notification resulting from an end user interaction is sent from the application server to which the user is connected.
  • An email notification resulting from any background processes (such as Animator processing an Attached Event) are sent 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.
System Configuration, Administration, and Operation Considerations
Consider the following before you implement CA SDM Advanced Availability Configuration:
  • SOAP Web Services and REST Web Services are only supported on the application servers. Web directors can be configured on all CA SDM servers. As the application servers are independent of each other, web directors can only service web engines running on the same application server. Web directors cannot service web engines across application servers.
  • Since 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.
  • In advanced availability, processes on each server are controlled independently. This is unlike conventional configuration, where you have to run 
    pdm_d_mgr
     on the primary server to start and stop CA SDM processes. 
    We recommend that you use the new
    pdm_server_control
    instead of
    pdm_halt
    command to shutdown application servers. Before the shutdown, you can move active users to another application server. This can be done by notifying users that are using the
    quiesce
    option.
  • 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. Users cannot log in when the authentication server is unavailable.
    The pdm_edit utility is 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 are configured.
  • The role and other information for an advanced availability server can be changed from the 
    CA SDM Console, 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 manual updates are required to change the settings.
  • New environment variables have been added to NX.env to support the advanced availability and the system automatically maintains the variable values.
    Do not change NX.env manually unless instructed to do so.
  • Use the latest 
    pdm_startup
     files while migrating/upgrading CA SDM. Do not use the files from previous versions of CA SDM. For example, files that are generated by the pdm_edit utility.
  • A facility generates ticket numbers and numeric record keys. To avoid possible database corruption, never try to load or manually alter the 
    Key_Control
     table.
    In Advanced Availability configuration, ticket numbers and numeric record keys, may be out of order. This is not an error. Other fields can be used for sorting based on timestamp such as Open Date for tickets.
  • 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 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 a same server to support this.
  • 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. Upon 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 now 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.
CA SDM Configuration Conversion
Consider the following before you start converting a conventional configuration to the advanced availability or vice-versa:
  • 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.
Failover Considerations
During a failover of the background server to the standby server, consider the following:
  • New users must not log in. For users who are already connected, the following actions will not work during the failover process and must be attempted again (retried) by the user after failover is complete:
    • Creating tickets with attachments.
    • Downloading attachments.
    • Searching Knowledge documents.
    • Indexing new knowledge documents.
    • Inbound email.
    • The SLA events that are not triggered until the failover process is complete. .
If you are using a third-party tool to auto-failover CA SDM servers, you must disable it before starting rolling maintenance.
Web User Interface and Web Server Considerations
Web User Interface
A web server is required on all servers having an advanced availability configuration. When 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.
Web Services
You can configure web services only on the application servers. The 
webservices_domsrvr
 option no longer exists in the 
Options Manager
. You can configure the 
NX_WEBSERVICES_DOMSRVR
 variable independently on each application server by modifying the 
NX.env
 file.
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 through different application servers.
  • CA SDM and Unified Self-Service Integration
    :
    • Ensure that you install both the products on different machines.
    • Before you install Unified Self-Service, download Liferay CE 6.1.2 GA3 edition zip file.
      Do not Install Liferay manually as the installer unzips the downloaded file and installs Liferay.
Database Considerations
A direct connection exists from each of the servers to the other as well as to the database. If the 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 servers 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 since Microsoft SQL Server is not supported on Linux.
    The 
    pdm_isql
     utility works only on the application server.
Reporting Considerations
CA Business Intelligence can automatically retrieve data from alternate application servers. You can configure this feature to increase the availability of CA SDM reporting. 
CA Business Intelligence is not integrated with the background server. For this reason, you cannot view reports from the background server web UI. An error message is displayed if you select the
Reports
tab from the background server web UI.
 For CA Business Intelligence ODBC services to start properly, export the library path, as follows:
(For Solaris/Linux) Export LD_LIBRARARY_PATH=$ LD_LIBRARARY_PATH:/opt/CA/SC/lib:<NX_ROOT>/lib
Example:
 Export LD_LIBRARARY_PATH=$ LD_LIBRARARY_PATH:/opt/CA/SC/lib:/opt/CAisd/lib
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 Screen Painter Considerations
  • You can use the Web Screen Painter (WSP) only on the background server.
  • Follow the recommended procedure to publish WSP form changes so that the updated forms are distributed to all the servers in the installation. For more information, see
     Web Interface Modifications
  • The virtual database layer daemons run on all servers. Install the CA SDM database customizations and object definitions on all the servers.