Planning › How to Plan for Advanced Availability › Considerations for Advanced Availability Configuration

Considerations for Advanced Availability Configuration

We recommend you to consider the following points before you decide to implement the advanced availability configuration:

General Considerations

All the planning considerations of the conventional configuration are valid for the advanced availability configuration. For more information about the conventional configuration planning, see the Implementation Guide.

• 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 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. For more information, check the system information.
• Converting a conventional configuration to an advanced availability configuration is a manual effort. The larger implementations are usually more complex and you may have to engage CA Services for the assistance.
• To migrate to the advanced availability configuration, upgrade to CA SDM r12.9 in the conventional configuration and then convert to the advanced availability configuration.
• 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. 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.
  • 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 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.
• We can send email notifications from all CA SDM servers. There is currently 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.
  • 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.

Failover Considerations

During a failover of the background server to the standby server, consider the following:

• The new users cannot log in.
• For the already connected users, the following actions do not work during the failover and must be attempted again by the user after the failover:
  • Creating the tickets with attachments.
  • Downloading the attachments.
  • Searching Knowledge documents.
  • Indexing the new knowledge documents.
  • Inbound email.
  • The SLA events that are not triggered until the failover has completed.
  • Important! If you have configured your third party tool to enable the auto-failover of the CA SDM servers, you must disable it before starting the rolling maintenance.

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 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.
• The pdm_isql utility works only on the application server.

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.
• 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.
• 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 shutdown application servers. Before the shutdown, you can ask the active users to move to another application server. This can be done by notifying 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.

  Note: 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 while migrating to CA SDM r12.9. Do not use the files from previous versions of CA SDM. For example, files that are generated by the pdm_edit utility.
• New environment variables have been added to NX.env to support the advanced availability and the system automatically maintains the variable values.

  Important! Do not change NX.env manually unless 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 now 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.

  Important! 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.

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.
• 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 the How to Customize Schema Using Web Screen Painter and How to Customize Web Interface using Web Screen Painter scenarios.
• The virtual database layer daemons run on all servers. Install the CA SDM database customizations and object definitions on all the servers.

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.
• BOXI 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.

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. For more information, see the Online Help.
• 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.
• You can integrate NSM only to a single application server as the IP addresses are involved. The NSM integration is unavailable when that server is down.
• CA Workflow must be installed on any of the application servers. If that application server goes down, the CA Workflow integration becomes unavailable.

Conversion Considerations

• 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.

Federated Search Considerations

• To enable and use the federated search feature, select the federated search option while configuring the application servers.