Best practice: Have the Attachment Repository on a separate server to the CA SDM application

book

Article ID: 130083

calendar_today

Updated On:

Products

SUPPORT AUTOMATION- SERVER CA Service Desk Manager - Unified Self Service KNOWLEDGE TOOLS CA Service Management - Asset Portfolio Management CA Service Management - Service Desk Manager

Issue/Introduction

On a CA Service Desk Manager (ITSM) system with a high volume of Attachments, it is recommended that the Attachment Repository be on a different server to the CA SDM application server.

This achieves two goals.
  • The Attachment data may be backed up independently of the CA SDM application. The former changes frequently, while the latter does not.
  • The servers can be optimised for their different roles.


Environment

Release: SDSAAS99000-12.9-Service Desk-On Demand
Component:

Resolution

If the CA Service Desk Manager server is using a large amount of disk space, then investigate what is generating this volume.

The CA SDM /log and /mail folders should not be generating large volumes of data.

However, the Attachment Repository (under /site) may generate a lot of folders and files, and take a considerable amount of space on a large and busily used Attachment system.


RECOMMENDATIONS 
================================ 

1) Running the Archive and Purge routine will remove any Attachments from Purged tickets. This should be a regularly scheduled (daily) Administration task, in order to keep the system performance orderly. 
The first time it run on a large system, be prepared that the task will not be able to complete in one run, and so it is best to schedule it out of hours, and it will take many passes to go through the backlog. 
Note that the Archive and Purge routine WILL create large text files in the target location, so be prepared for these. You don't save space until the Archive and Purge routine is run, and the files are a target drive which is OFF the CA SDM application server. 

2) It is typically recommended that if there are a lot of Attachments on a system, that the CA SDM Attachment Repository be on a DEDICATED FILE SERVER, and not on the CA SDM application server. This ensures that both systems can be optimised for the task at hand. 

See your hardware team for a RAID configuration or other setup that may assist with this. Even at a minimum, a plain old regular server without any tuning will give you better performance, if the CA SDM and Attachment Repositories are on different servers. 
 
  • The CA SDM server depends on having sufficient memory and multiple CPUs in order to handle the application. 
  • The file server may have a different configuration, optimised to file read/write speed, with preferably a backup system added. 


Note that you may move the CA SDM /site/Attachment folder from one server to another, provided that you update the path to the new location within CA SDM. 

3) It is recommended that within CA SDM that you set a limit to the size and type of files that may be uploaded. For example, the current upload size is unlimited. This should be set to a large, but still generous, value. You may also wish to exclude certain file types. Both of these settings are per business requirements. 

4) Review the Attachments that have been uploaded to see if there are only a few very large Attachments that have been uploaded recently, or if there has been simply a very large number of files over time that have consumed space. A tool such as "FolderSize" can help visually with this. Although as we know that most of the folders are in a single directory called "Attachments", sorting by size and visually inspecting the worst offenders may be a quicker way to see what is going on with how the load is distributed. 

5) It is ***NOT*** recommended to simply delete Attachment rep_ folders. This can be done in an *emergency only,* by moving the older folders off the drive. But they should be put back in at some point so that orphan entries are not created. It is better to go through the Purge routine at (1) after the files are back. 


Note that there may be other sources of high disk space use.
 

However, the performance rule of thumb is the same - heavily used parts of the system should be isolated from other parts if required, such as the database, application, web services, knowledge, reporting and so on.

Additional Information

CA Service Desk Manager recommended architecture for different size environments:
https://docops.ca.com/ca-service-management/17-2/en/installing/ca-service-management-17-2-solution-architecture/ca-service-desk-manager-product-architecture